トップページ | 2015年12月 »

2015年11月

2015年11月30日 (月)

対テロ対策

人気ブログランキングへ にほんブログ村 IT技術ブログ

今月、フランスで同時テロが起きました。心からお見舞い申し上げます。

 

こういうことがあると、すぐ考えてしまうのは、「自分は大丈夫か?日本は安全か?」ということです。大きな爆弾を持ち込むことは無理でも、小さく簡単な爆弾を日本国内に持ち込むことは全く不可能ではないでしょう。サーバーマシンの様な大きな筐体に仕掛けられたとしたら?やっぱり、他人事ではないですね。そのサーバーが電車の信号機制御システムだったり、政府の諜報部門のシステムだったりしたら、社会不安に陥ります。現に、私が学生だった頃、電車の信号システムがテロに遭い、まる1日電車が動かなかったことがありました。そのときは、通信ケーブルを切断されたのだったと記憶しています。ITと言えばソフトウェアを思うかべがちですが、ハードウェアが狙われた時の対処も考えておくべきです。たとえば、非常電源とか、マシンやケーブル類の多重化などが考えられます。

 

もちろん、ソフトウェアのセキュリティ対策も考えておきましょう。当たり前のことですが。あのテロ組織は自爆テロだけが武器ではないです。コンピュータを使うことも心得ている人がいるようです。テロ組織はあそこだけではないです。北朝鮮のハッカー養成組織は有名で、アメリカや韓国が被害にあっています。インターネットがこれだけ発達しているので、もうコンピュータ上は国境がないと考えるべきです。

 

(文:エメラルド優子)

 

2015年11月29日 (日)

職場での人間関係

人気ブログランキングへ にほんブログ村 IT技術ブログ

中級のIT技術者ともなると、後輩や部下の面倒を見ることになっている人もいるのでは?「話を聞いてくれない」とか「どうやって接したらいいのかわからない」とかの悩みがある方が少なからずいると聞いています。今まではコンピュータだけを相手にしていたのが、人間の面倒を見る。たいへんな変化ですね。

どうしたらいい? 残念ですが、答えは一つではありません。人間が100人いれば、100通りの答えがあります。相手と接し、観察して模索していくしかないのです。私は占い師ではありませんから、会っても話してもいない人のことはわかりません。突き離して申し訳ないですが、がんばってください。

これだけは言っておきますが、あなたにも人格があるように、相手にも人格があるということだけは覚えていてください。セクハラをはじめとする「○○ハラスメント」は数が増えてきています。部下は歯車の一つのような捉え方はもう古いのです。もし、相手の人格を無視して接していれば、訴えられることもめずらしくなくなっています。中には自意識過剰の人もいるでしょうから、自分ではそんなつもりはなくても、傷つく人もいます。言い返してくれればまだわかりますが、じっとだまっていてある日突然キレる人もいます。

世の中、たいへんですね。がんばってください。 (文:エメラルド優子)

2015年11月28日 (土)

どのハードウェアで動かすか

人気ブログランキングへ にほんブログ村 IT技術ブログ


顧客からあるシステムを受注したとき、まず決めるのはどのハードウェアでそのシステムを動かすか、ということだと思います。病院のカルテシステムの場合、サーバの規模、端末の種類と数、ネットワークのキャパシティ、などが決める内容となります。Webページを構築するときも、そのページを見るのはパソコンを想定していればよいか、スマフォも含めるか、ガラケーはどうする、を考えなければいけません。脱線しますが、日本の携帯電話の半数以上はガラケーだって知っていました?例えば市役所のWebページを作るときに、ガラケーで見られなくなってしまったら、困る人はたくさんいます。配慮する必要があります。

 

 

 

閑話休題。

 

 

 

まあ、どのハードウェアで動かすかを決めるのは、最終的に顧客でいいと思うんです。例えばカルテシステムの場合、端末を操作するのは主に医師ですから、その医師が使いこなせないような端末だったら、本末転倒ですよね。でも、発注する側の人はハードウェアのプロフェッショナルではないことがほとんどでしょうから、あなたがアドバイスして最良の選択ができるようにしてあげなければいけません。パソコンだったとしても、どのOSを積んだパソコンがいいか「あなたが」細かく分かっていなければいけません。ネットワークを組むときでも、そのネットワークを流れるデータを分析して顧客に説明する能力がないといけません。

 

 

 

ハードウェアの話が出たので、お勧めしておきたいのは、情報処理試験です。あれを取るための勉強をすると、ハードウェアの基本が身につきます。ソフトウェアのプロのみなさんがハードウェアも身につくと、自信がつきます。ゆくゆくは転職を、と考えている方!ぜひぜひ。

 

 

 

(文:エメラルド優子)

2015年11月27日 (金)

開発環境の決め方

人気ブログランキングへ にほんブログ村 IT技術ブログ

モノを作るとき、なにを作りたいかイメージがあるんだけど、開発環境をどうすればいいか、決めるのが難しいことがありますよね。料理もそうです。どの材料をどの器具で作るか決めるのは難しいことがあります。私がカレーを作るとき、最初にオイルににんにくと生姜のすりおろしを入れるのですが、これに他の材料を入れて炒めているときに、にんにくや生姜が焦げやすくて困ってしまったのです。そこで、考えて、カレー用のアルミ鍋ではなく、テフロンのフライパンで材料を炒めるところまですることにしました。そこから、鍋に炒めた材料を入れて煮込むようにしたのです。それでおいしいカレーができました。

 

 

 

ソフトウェアを作るときもそんなことありませんか?スマフォ用のアプリはスマフォでは作りませんよね。おそらく、パソコンだと思います。スーパーコンピュータに乗るようなソフトウェアでも、最初からスーパーコンピュータで開発したりしないのではないかと思います。専用の端末か、パソコンでパーツを作って組み立てていくのでは。

 

 

 

ただここで気をつけたいのは、開発環境と動作環境が違うので、ある程度はハードウェアのことが分かっていないといけないということです。スマフォのアプリを作ったのはいいが、いざスマフォで動かすと重すぎて使いものにならなかった、ということもありえます。やたら通信パケット量の多いアプリもダメです。ミドルウェアを作っている方はプロですから慣れているでしょうが、どんなソフトウェアも、なんらかのハードウェアの上で動いているといことを忘れないようにしましょう。

 

 

 

かくいう私も、開発ではないんですが、Windows7マシンにWindows10をインストールしたところ、重くなって困っています()

 

 

 

(文:エメラルド優子)

2015年11月26日 (木)

要件定義とは

 <a href="http://blog.with2.net/link.php?1797303">人気ブログランキングへ</a>
<a href="http://it.blogmura.com/ranking.html" target="_blank">にほんブログ村 IT技術ブログ</a>

ごめんなさい、筆者は「要件定義」という言葉を知りませんでした。筆者はそれを「機能仕様」と呼んでいたからです。中身は一緒です。要は、顧客が「これこれこういうものを作って欲しい」と言ったものを文書化する作業と、その文書のことをいいます。

 

IT業界の要件定義は、規模も技術も様々です。スマートフォンや携帯電話のアプリのような規模が小さく、開発環境もきっちり決まっているようなものから、電車の信号制御システムのような、大規模でシステムの環境も様々考えられる(サーバー環境で済むか、スーパーコンピュータが必要か)ものまであります。目がまわるでしょ?もちろん、ソフトウェアの規模も様々です。

 

例え話で要件定義の大まかな雰囲気を掴んでいただきましょう。SEが大病院に呼ばれたとします。

医院長「うちのカルテを電子化したい」

SE「医師の数と、今後増やす予定があれば、最大何人くらいになる可能性があるか、教えて下さい。」

医院長「今いるのは○○人で、増えても△△人くらいになると思います。」

SE「診察予約の自動化は必要ですか?」

医院長「必要です。」

SE「診察料の計算自動化は必要ですか?」

医院長「もちろんです。うちは、処方薬も医院内で出しているので、薬剤料も自動化してください。」

SE「この病院では、検査も充実していると思いますが、検査予約、検査結果の医師への返信も自動化しますか?どの検査項目を自動化しますか?」

医院長「血液検査、眼底検査、X線検査、MRIの自動化をお願いします。」

SE「血液検査の検査項目数と、眼底検査・X線・MRIの画像の画素数と枚数を教えて下さい。これは、すぐには決められないと思いますので、医師・検査技師と意見をまとめていただけると助かります。

これだけ大きな病院で患者さんも多いと思いますので、サーバーとなるコンピュータの規模はかなり大きくなると思います。ですので、これは弊社に持ち帰って見積もらせていただきます。」

 

まだまだこのようなやりとりは続きます。コンピュータに詳しい方は、SEがどうして色々な質問をしたか、おわかりでしょう。まずはハードウェアの数・容量や、法令改正によるアップデートが必要なソフトウェアがあるかどうかを決める材料としているのです。この他にも、医院内ネットワークの速度・規模や、セキュリティだって考えなければならないでしょう。何度もSEは病院に通い、要件定義は決まっていくのです。

(文:エメラルド優子)

2015年11月25日 (水)

人が書いたプログラムは読みたくない

人気ブログランキングへ にほんブログ村 IT技術ブログへ
にほんブログ村

私がシステムの開発をしていたとき、上司や同僚と手分けしてプログラムを書く事はよくありました。出来上がったプログラムを合わせてテストしたらうまく動かず、私がそのソースを合わせてデバッグすることになったのです。これはよくあることです。しかし、人の書いたプログラムというものは、ちんぷんかんぷんのコードであることがたまにあり、難航しました。変数名やプロシジャ名、開発者が思い思いにつけていたり、インデントを利用しないで全部1カラム目に書いていたり、1行に2つ以上の文が続けて書いてあったり。

 

 

 

一人で全体を把握して、全部最初から最後まで作るなら、こんなこと気にしなくていいのでしょうが、みんなで手分けして作るときは、そのメンバの誰が見てもすぐわかるプログラムを書く必要があります。どうすればいいか、箇条書きにしてみましょう。

 

 

 

(1) 変数名などの名前は、規則性を持たせる。

 

(2) インデントは必ずつける。1行に1文のみ。

 

(3) 規則をやむを得ず破るときは、コメント文をつける。

 

(4) プログラム仕様書を書く。

 

 

 

学校などでプログラム開発を学んだ人は、当たり前のことのように思うかもしれませんが、私のように学校で学んだことがない人は、知らないものです。一緒に開発する人数が多い場合ほど、重要になってきます。まして、プログラム開発を複数の会社で分業する場合など、ますますわけがわからなくなります。

 

 

 

プログラム仕様書は書かない、という会社さんと仕事したことがありますが、「2度と一緒にやりたくない」と思いましたね。いちいち、これはなんだ、説明してくれ、と聞くのは、骨が折れました(苦笑)

 

            (文:エメラルド優子)

2015年11月23日 (月)

勤労感謝の日

人気ブログランキングへ にほんブログ村 IT技術ブログへ
にほんブログ村


そうです、今日は勤労感謝の日、祝日です。みなさん、ちゃんと休めてますか?まあ、ITの世界では24時間誰かが監視していないといけないシステムが多いので、休日出勤という方も少なからずいるでしょうね。お疲れ様です。ネットワーク管理者、セキュリティ管理者は特にカレンダー関係なく働いていることでしょう。頑張ってください。

 

 

 

でも今日は勤労感謝の日です。勤労している人は感謝されるべき日なのです。主に家族に感謝されるのかな?私は幼いとき、働き手の父に「感謝しろよ!」と言われていたのを思い出します。

 

 

 

なのに、世の中、仕事しなければいけない状況でなくても、休みの日に職場に出てだらだらと仕事だか遊びだかわからないことをしている人たちがいます。私がサラリーマン時代もそうでした。そんな上司が私にも休日出勤しろと強要したこともありました。その上司は、コンピュータの仕事をしているにもかかわらず、自分でキーボードを使って文字を打つことができない人でした。びっくりですよね。まあ、今は文系の大学生だってパソコンでレポート提出する時代ですから、そんな人はいないでしょうが。その上司のためにワープロ要員として私は休日出勤させられたのです。

 

 

 

そうやって人に迷惑をかけたりかけなかったりしながら、だらだらと休日も仕事して、ろくに代休も取らない人は、私に言わせれば自己マネージメントができていないのだと、思っています。仕事だけが命、休日にする趣味もない、そんな人が定年退職後に何をして生きていくのでしょう?若い人は「そんな先のこと」と思うかもしれませんが、今の時代、定年まで働ける人も減っているのです。

 

 

 

私も、仕事が忙しくて毎日午前様、休日出勤もして、たいへんなこともありました。でも、その仕事が終わったとたん、1週間のたまった代休をとって、能登半島をゆっくりとレンタカーで周り、帰りはのんびり寝台列車に乗るというリッチな遊びもしたのです。このような暮らしを「濃い」と言うのではないでしょうか?メリハリのある生活というものです。

 

 

 

今回、なにを言いたかったというと、不要不急の休日出勤はNG、休む時は休んで仕事以外のことをしましょう、と言いたかったのです。でないと、体を壊すか、退職後に寂しい思いをしますよ!

 

       (文:エメラルド優子)

2015年11月22日 (日)

開発とは

にほんブログ村 IT技術ブログへ
にほんブログ村 人気ブログランキングへ

「開発」という言葉を聞いて、みなさんは説明できますか?単に、プログラムを書くこと、と思っていませんか?広義でいうと、「自然にあるもの、あるいは古い技術に、人間が手を加えて新しい価値を生み出すこと」といえばわかりやすいでしょうか。野原を造成して住宅地にすることは「宅地開発」ですし、新しい電車を作ることも、「機械開発」です。

 

 

 

IT業界では、多くの場合、プログラム開発者は何を作るのかを、顧客または上司から依頼されて設計・コーディングすると思います。プログラム開発者は「自分こそがこのプログラムの開発者だ」と独り占めしようと思ってしまうかもしれません。ですが、顧客や上司がその仕事を持ってくるときも「開発」しているのですよ。それが、「ニーズ開発」です。ニーズ開発とは、世の中こんな道具や技術があったら喜ぶ人がいる、買ってくれる人がいると気がついてモノ作りの現場に持ってくることです。ニーズはじっとパソコンの前にいるだけでは生まれません。いろんな人に会ったり、いろんなものを見たり、本を読んだりしてひらめくものです。それをプログラム開発者のところへ持ってくる頃には、特許明細書が書けるくらいの努力と時間をかけているのです。

 

 

 

少し脅かしてしまいましたが、しかし、プログラム開発だけでもりっぱな開発です。設計やコーディングを細かいところまでバグの出ないように緻密に行うのもたいへんなことと思います。そんなとき、「副産物」ができてしまうことはありませんか?間違えたコーディングをして、違う用途のプログラムができてしまったとか。それは単純に訂正や削除するのではなくて、こっそりとっておきましょう。そして、顧客や上司に「こんなこともできるんですけど」と提案するもよし、じっと温めておいて自分で「ニーズ開発」するもよし、その「副産物」はプログラム開発者の肥やしになると思います。

 

 

 

プログラム開発者の仕事でもう一つ重要なのは、テストですね。いわゆるバグ取りです。詳しくは後日書きます。お楽しみに。

        (文:エメラルド優子)

2015年11月21日 (土)

知的所有権とTPP

今まで、日本の企業は日本の法律によって、外国から守られて来ました。知的所有権(特許権、著作権など)もそうです。もし、同じ日に同じ内容の特許明細書が複数、特許庁に提出されたら、日本に住んでいる人が有利になるようにできていました。また、自分の特許権、著作権の権利が侵害されたら、その権利を持っている人が申告しなければ、侵害した人を裁かないというゆるい法律になっていました。

 

 

 

しかし、今般のTPP合意により、厳しくなってくる可能性があります。まだ法整備が済んだわけではないので、確かなことは言えませんが、日本での特許取得等にかかる期間が長いことなどを考えると、今から対策を考えておく必要があります。

 

 

 

まず、特許についてです。IT技術の世界でも最早、特許を取らなければ物を売ることができないのは当たり前になっています。みなさんはいつ、特許明細書を書いていますか?プログラムがほぼ出来上がったら?それではもう遅いです。受注したら、すぐ書きましょう。要件定義書もないのに書けない?では、特許明細書を要件定義書だと思って書けばいいのです。要件定義こそがあなたのオリジナリティなんですよね。オリジナリティを思いつけば、それが特許になるのです。もちろん、既に世の中に出ている他社技術も調査しなければなりません。もし、他社と同じものを作ってしまえば、こちらが特許侵害になるのです。要件定義以後に思いついたアイデアがあれば、書き加えて新たな特許になることも覚えておきましょう。

 

 

 

なぜ、そんなに急いで特許明細書を書かなければならないかというと、今までは日本国内の他社を気にすればよかったのが、TPP参加国全体に広がるのです。敵が何倍にも膨れ上がるのです。1日でも早く特許申請しなければ、太平洋地域の誰かが、先に申請してしまう可能性が高くなって、特許が取れなくなってしまいます。たいへんですね。

 

 

 

著作権についてですが、IT分野で著作権と言えば、まずプログラム、文字の羅列ですね。皆さんもプログラムの先頭に、自分の会社の名前を書いて、著作権を主張していますよね。してない?簡単なコメント文を入れるだけなのに、著作権表示をしていない会社もあるのを私は知っています。下請けでプログラムを書いている会社などがそうみたいですね。ここで、TPP合意によって、著作権の侵害の摘発は権利を持っている人が気がつかなくても、警察が摘発できるようになります。プログラムの著作権で問題なのは、同じ機能を作りたいとき、他の人が作ったものをコピー&ペーストしていませんか?もしコピーでなくても、偶然同じものができてしまったとき、後から作った人は著作権侵害でないことを証明しなくてはいけなくなるのです。だから、下請けであろうと、著作権表示は大事になります。これは、顧客や、何社かで分担してプログラムを書くとき、慎重にならなくてはいけないことです。プログラム文書の出来上がった時刻を記録しておくのも忘れないようにしましょう。もちろん、写真や図などの他の著作物も同じです。

 

著作権表示って何?という方、しょうがありませんね。見本を書きますから、参考にしてください。この文章も私の著作物ですから、私の著作権を書きましょうかね。

 

copyrightYuko Teranishi All rights reserved.

 

プログラム中で絵文字は使えない場合は、(c)で代用してもいいです。All rights reserved.は省略可能になってきたようです。 

 

IT産業は輸出してもしなくても、知的所有権上、素早く対応、キツく対応が求められているようです。

 

             (文:エメラルド優子)

2015年11月20日 (金)

要件定義(1)~何が嬉しいの?

いきなりつっけんどんな言い方かもしれませんが、新しい仕事の企画書なり、要件定義書なりを上司や同僚に見せたとき、「この技術ってさ、何が嬉しいの?」ってよく訊かれたものです。筆者はソフトウェアの研究をしていたので、職場の独特な言い方なのかもしれませんね。

 

「付加価値がある」ってことですが、「嬉しい」って言い方が人間味があって筆者は好きです。

 

この言葉は、別にIT分野に限って有効なわけではありません。電車の生産分野では、「電車の揺れが軽減される」「使う電力がX%削減できる」「つう好みの車体フォルム」、アイスクリームの生産分野では、「カロリーY%カット」「新食感」「添加物削減」「高級感」などなど。これ全部、誰かが「嬉しい」ことです。

 

誰かが?

 

では私たちは誰が嬉しいものを作ればいいのしょう?「そんなの顧客に決まっている」と即答したあなた!大丈夫ですか?もちろん、顧客が嬉しくなければ、お金を払ってくれないですから、顧客の満足いくものを作るのはみんなやることです。

 

でも、作ったはいいけど、同業他社の特許にひっかかって、多額の特許料を払うはめになったら、作っているあなたの会社の儲けにはなりませんよね。ちゃんと自社も嬉しくならなければいけません。まあ、特許に関しては、特許料払ったほうが自社に嬉しいこともあるんですけどね。

 

あと他に「嬉しく」なったらいい存在はないですか?

 

それは、社会、動物、植物、自然、地球、宇宙。

 

ずいぶんと話が壮大になってきましたね。「うちはそんなことに関係ない分野だから」とか考える方がいたら、大きなビジネスチャンスを逃しているかもしれません。

 

もう今は、町の中小企業が人工衛星を作ったり、趣味でアマチュア無線をやっている人がISS(国際宇宙ステーション)の宇宙飛行士と交信できる時代です。一方、エボラ出血熱やテロで苦しんでいる人たちもいます。刻々と世界の情勢は変化していきます。それをビジネスチャンスだと捉えるのは、不謹慎だと思う方もいるかもしれません。でも、IT技術という武器を持っているあなたがたは、少しでもその技術で貢献していくことができれば、いいと思いませんか?

 

要件定義をするとき、自問自答してください。「何が嬉しいの?」

           (文:エメラルド優子)

はじめに

ここは、SEさん、プログラマさんなど、ITの分野で活躍している人のちょっと迷った時に読むブログです。IT初心者のためのWebページは数あるけれど、中級者ともなると、参考になるページがなかなかないって思っていませんか?そういうとき、それから電車などの移動時、コーヒーブレイクの時などにここに来てみてください。少し参考になるかも?

 

私は大手電機会社の研究所で主にソフトウェアの研究をしていた者です。今はリタイアしていますが、その頃の経験や辞めてからも考えていたこと、などなどをつらつらと書いていきます。

 

よろしくお願いします。

 

       (文:エメラルド優子)

トップページ | 2015年12月 »