簡単に見える時ほど注意せよ

最初は簡単そうに見えた仕事だったが、やってみると意外と難しかった、ということがある。

例えば、「CSV ファイルを読み込むプログラムを作ってくれ」という依頼があったとしよう。初心者プログラマにありがちなことだが、CSV なんて読み込んだ文字列をカンマで分割するだけだ、などと簡単に考えてしまうことがある。

しかし、実際にプログラムを作って動かしてみると、うまく動かない。いくつかの考慮が欠けていたのだ。例えば、

・値の中にカンマを含む場合はどうするか。
・値の中に改行を含む場合はどうするか。
・カンマの前後の空白は値に含むか。

といったことである。

よくあるルールに従う（例えば、Excel が出力するような）場合には、既存のライブラリ等を利用して簡単に実装できるかもしれない。しかし、独自のルールが必要だとしたら、ちょっとした手間がかかる。

★

あるいは、「文字列検索機能を作ってほしい」という依頼を受けたしよう。単純な完全一致検索や部分一致検索を想定して、安請け合いしてしまうかもしれない。

しかし、依頼者の頭の中にあったのは、日本語の単語単位できちんと検索してくれるプログラムかもしれない。つまり、「京都」で検索して「東京都」が出てきては困るというわけだ。こうした要望に対応するには、形態素解析のような高度な技術や適切な辞書データが必要になってくる。

★

ここに挙げたような例は、ある程度の経験を積んだプログラマや SE であれば、すぐに頭に浮かぶような話である。彼らは、仕事が依頼された時に、その場で質問し、上記のような問題はクリアにするだろう。

「安請け合い」しないために肝心なのは、仕事を依頼されたその時に、どこまで踏み込んだ質問ができるか、ということだ。経験が浅い人には難しいかもしれないが、そういう意識を持っていれば、そのうちできるようになるだろう。

★

一方、ベテランの技術者でも難しいのは、依頼者しか知らないような独自の要件（業務ロジック）に関することである。

特に、顧客から「ここのデータは、単に××コードで引っ張ってくるだけですよ」なんていう、いかにも「簡単でしょう？」といった感じの説明があった場合は注意したほうがよい。意識的であるかどうかは別として、必要な情報が隠されていることがあるのだ。プロジェクトの後の方になって、「いや、通常のケースはそれでいいんですけど、こういった場合はこうなって、ああいった場合はああなって・・・」などと「例外」がどんどん増やされたりする。

依頼者からすれば、細かい例外的な条件などは、大したことではないと思っているのかもしれない。システムにとっては、「通常」だろうが「例外」だろうが、処理が必要なのであれば同等なのだが。

何か仕事を頼まれたときには、簡単そうに見えることほど警戒したほうがよい。安請け合いをする前に、なるべく多くの情報を聞き出すことである。

応援のクリックお願いします →

ソフトウェア見積り―人月の暗黙知を解き明かす

posted with amazlet on 07.03.21

スティーブマコネル Steve McConnell 田沢恵溝口真理子久手堅憲之
日経BPソフトプレス (2006/10)
売り上げランキング: 2407

おすすめ度の平均:

アートとしての見積もり

Amazon.co.jp で詳細を見る

成功する要求仕様失敗する要求仕様

posted with amazlet on 07.03.21

アラン・M・デービス萩本順三安井昌男高嶋優子
日経BP社 (2006/11/02)
売り上げランキング: 49741

おすすめ度の平均:

要求マネジメントの良書

Amazon.co.jp で詳細を見る

本来の目的を思い出そう

「面倒くさいこと」に書いたように、繰り返し行うような単純作業はコンピュータにやらせた方が効率的だ。プログラムを作る時間が掛かったとしても、長期的にみて利益が大きいならそうすべきである。

しかし、逆に、人間がやった方が効率的な仕事までコンピュータにやらせようとして、失敗することも少なくない。苦労してデータを入力しても、それに見合うだけの恩恵を与えてくれないようなシステムを見かけたことがないだろうか。

コンピュータに限らず、道具というものは、適した所に適した形で使わなければ効果がない。「システム化」といっても、何でもかんでも電子化してコンピュータで管理すればいいというものではないのである。

「システム化」というと、業務の一部をコンピュータ・システム（機械系）に移すことが目的であるかのように聞こえる。しかし、本来の目的は、業務を改善することである。機械系だけではなく、人間系を含めた広い意味での「システム」を再構築しなければ、その目的を果たせない場合も多い。

★

本来の目的が見失われてしまうという状況は、この業界ではよく見かける（もっとも、他の業界でもそうかもしれないが）。

例えば、プログラミングに集中しすぎたプログラマが、本来の「要件」を忘れてしまうことがある。技術を追求しすぎて、そのシステムに必要のない機能を作りこんでしまったり、過剰な性能を追求してしまったりするのだ。もちろん、ソフトウェアの機能が多く、高性能だというのは良いことだ。しかし、過剰な実装のために費やした作業時間は、本来なら別のことに使えたはずであり、そういう意味では損失である。

SEO（検索エンジン最適化）の場面でも、そうした状況が見られる。本来は「サイトを多くの人に使ってもらうこと」が目的のはずなのに、「検索エンジンの上位に表示されること」が目的であるかのように錯覚されることがあるのだ。そうなると、コンテンツ（サイトの内容）の充実に使うべき労力を、小手先の SEO ばかりに使ってしまう（※）。

あるいは、情報セキュリティに関しても見受けられる。本来、「情報漏洩を防ぐこと」が目的のはずなのに、「社内ルール」のようなものを守ることが目的になってしまうことがある。ルールが完璧ならそれでもいいのだが、中途半端だと危険だ。例えば、「コンピュータにはログイン・パスワードを設定すること」というルールがあるとしよう。しかし、そのパスワードを付箋に書いてモニターに貼っていたのでは意味がない。確かに、ルールは守っているのかもしれないが、本来の目的からすると意味がない。

★

このように、本来の目的が見失われてしまうと、無駄な労力を使うことになったり、無用な危険を招くこともある。特に、技術者が注意したいのは、どうしても技術寄りの視点にとらわれてしまいがちなことだ。目の前の技術的な問題に取り組んでいると、ついつい視野が狭くなってしまう。自分がやっていることの本来の目的は何かということを、時々、意識的に思い出すようにしたいものである。

応援のクリックお願いします →

※検索エンジンが目指しているのは、「検索者にとって有用なサイトを見つけてあげること」だろう。彼らはそのためにランキング等の仕組み作り、改良を続けている。つまり、SEO の王道があるとすれば、「有用なサイトにする」ということなのである。

■関連記事
・デザイナーの屈辱
・YAGNI ～予想でモノを作るな
・うちの社員は信用できません

IT失敗学の研究―30のプロジェクト破綻例に学ぶ

posted with amazlet on 07.03.11

不条理なコンピュータ研究会日経コンピュータ
日経BP社 (2006/02)
売り上げランキング: 22896

おすすめ度の平均:

システム構築の世界は難しいのだが･･･

システム開発者自身を映し出す「鏡」

すべてのプロジェクトは大なり小なり不条理な側面を持っている

Amazon.co.jp で詳細を見る

ザ・ゴール ― 企業の究極の目的とは何か

posted with amazlet on 07.03.11

エリヤフゴールドラット三本木亮
ダイヤモンド社 (2001/05/18)
売り上げランキング: 2395

おすすめ度の平均:

値段以上の価値が宿る本

日本の製造業の凄さを再認識

小説でＴＯＣ理論（経営工学の制約理論）を学ぶ

Amazon.co.jp で詳細を見る

プログラマが学ぶ機会

プログラマの評価というのは、かなり早いうちに定まる。新人プログラマが現場に配属されてから数日から数週間のうちに、リーダー達は、彼らをスキルの高いグループとそうでないグループに分けてしまうだろう（もちろん、会社組織としての正式な評価ではなく、自分の頭の中で、という意味だが）。

そして、スキルが高いグループには、比較的難易度の高い仕事が与えられ、そうでないグループには、単純で簡単な仕事が与えられる。

幸運にも工期や工数に余裕のあるプロジェクトに参加できれば、スキルの低いプログラマも、色々と指導してもらえるかもしれない。しかし、それも新人と呼ばれる間だけである。２、３年経ってもまだ芽が出ないということになれば、諦められてしまうだろう。

★

開発プロジェクトのリーダーは、スキルの低い人材が自分のプロジェクトに参加することをひどく恐れている。「仕事が遅い」というだけならまだいいが、「ミスが多い」とされる人には仕事を頼みたくない。特に、余裕のないプロジェクトにそういう人材が投入された場合、リーダーが考えるのは、彼らにやらせてもミスが出ないような「無難」な仕事をどうやって捻出するか、ということである（※）。

納期や品質が最優先される開発現場では、「学ぶ機会の平等」などないと思ったほうがいい。スキルの高い人はどんどん伸びていき、そうでない人との差は開いていく一方だ。

プログラマのスキルは、個人差が非常に大きい。人によって才能や素質の違いが大きいのも確かだが、こうした環境の影響も無視できなさそうだ。

★

この業界、スキル不足の人材は多い。しかし、さすがに「お前は足手まといだ」などと直接言ってくるような上司は少ないと思う。もし、自分のスキルがどの程度か知りたいなら、いつも自分にどんな仕事を与えられているか、ということを考えてみればいい。

もし、他の人に比べて単純な仕事しか与えてもらえていないなら、注意が必要だ。「簡単な仕事ばかりでよかった」なんて思っている人は一生そのままである（そのままでいいのなら、もはや何もいうことはない）。むしろ、「学ぶ機会を与えられていない」と認識すべきである。

自分のスキルに自信があるのなら、「もっと高度な仕事をさせてくれ」と主張すべきだろう（もっとも、自信だけでも困るのだが・・・）。自信がないなら、「学ぶ機会」は自分で作るしかない。それは業務時間外になってしまうが、仕方がない。「低スキルのグループ」から抜け出すまでの辛抱である。

応援のクリックお願いします →

※「簡単な仕事を探す難しさ」を参照。つまり、私自身がそういうリーダーなのである。ただ、こうした問題について、ペアプログラミングはよい解決策かもしれないとは思う。

ソフトウエア開発の必修スキル―プロジェクトを成功に導く

posted with amazlet on 07.02.26

日経ITプロフェッショナル
日経BP社 (2005/05)
売り上げランキング: 174505

おすすめ度の平均:

助かった

「一冊要領よくまとまったものを」という方にオススメ

Amazon.co.jp で詳細を見る

金子流 ITエンジニアのための勉強の法則

posted with amazlet on 07.02.26

金子則彦
技術評論社 (2006/01)
売り上げランキング: 187196

おすすめ度の平均:

対象読者の設定が外れている

新人や経験浅い人へ勉強方法を示すのによいかも

資格撃破術（必勝法）の本ではない

Amazon.co.jp で詳細を見る

人とプログラムの価値観の違い

あるシステムで管理している会員データが、別の会員に繋がって出力されるという報告があった。Ａさんのデータを開いているのにＢさんのデータが表示され、Ｂさんのデータを開いているのにＣさんのデータが表示されるというのだ。枯れたシステムだったのでプログラムのバグが原因だとは思えなかったが、個人情報の漏洩にピリピリしている近頃のこと、システムの開発担当である私の所にも連絡が届いた。

調査の結果、そもそもユーザーが一括登録したデータが、間違っていたことが分かった。おそらく、Excel 等でデータを加工する時に、コピーし間違えたのだろう。会員の「氏名」の列が１人（１レコード）ずつずれていたのだ。

データとしては、会員特定する「会員ID」を管理していたが、そちらはズレていなかった。つまり、正確には、会員のデータが誤って繋がっていたのではなく、会員の「氏名」が別の会員の氏名で更新されていたのである。

システム的には「会員ID」がキーであり、「氏名」はそこにぶら下がっている属性のひとつに過ぎない。しかし、普通の人から見ると、やはり「氏名」こそがその会員を特定するキーなのだ。つまり、システムには「氏名」がズレていると見えるのだが、ユーザーにとっては「会員ID」がずれているように見えるのである。

★

こんなメールアドレスを採用している会社がある。

山田太郎 <a10123401@example.co.jp>
鈴木花子 <a10123402@example.co.jp>

メールアドレスというものは、メールを送受信するプログラムにとっては非常に重要なものだ。しかし、人間にとっては必ずしもそうではない。特にこのような無機質なアドレスを覚えようという人は少ないだろう。人間にとって重要なのは、むしろ、プログラムにとっては何の意味のない「山田太郎」や「鈴木花子」といった文字列の方である。

例えば、あなたがこのようなメールを受け取ったとしよう。

Subject: 資料を送ってください


   From: 鈴木花子 <a10123401@example.co.jp>





鈴木です。


至急、「○×資料」を送ってください。

あなたは急いでこのメールにそのまま返信してしまうのではないだろうか？　そうすれば、当然、「○×資料」は鈴木さんではなく山田さんに送られてしまう。

★

このように、プログラムと人間との「価値観の違い」は、時として危険である。コンピュータに詳しくない人ほど、そのことに気がつかないだろう。そのギャップを埋めてやることも、システム開発者やシステム管理者の仕事なのかもしれない（例えば、最初の例では、「一括登録機能」に氏名の重複を検出して警告を出すようなシステムも作れるろう。後の例では、もっと人間に親しみやすいメールアドレスを発行することができるだろう）。

応援のクリックお願いします →

■関連記事
・セキュリティを確保せよ
・情報求む
・オブジェクトの気持ち

情報セキュリティ読本―IT時代の危機管理入門

posted with amazlet on 07.02.18

情報処理推進機構
実教出版
売り上げランキング: 56564

おすすめ度の平均:

基本的なことが書いていていいです！

Amazon.co.jp で詳細を見る

ITセキュリティカフェ見習いコンサルの事件簿

posted with amazlet on 07.02.18

岡田仁志高橋郁夫島田秋雄須川賢洋
丸善
売り上げランキング: 107592

おすすめ度の平均:

内容はとても良い。

ＩＴセキュリティの入門に最適

Amazon.co.jp で詳細を見る

設計が過去に引きずられる

最近、古いクライアント・サーバー（C/S）型のシステムを、Web システムとして作り変えるという仕事が多い。現在の機能をそのままに、Web ブラウザから使えるようにしてくれ、という依頼である。

こういった場合に注意すべきは、新しいシステムの設計が既存のシステムの設計に「引きずられてしまう」ことである。この問題は、特にユーザー・インターフェースについて顕著だ。既存のシステムを使い慣れたユーザーからは、「今と同じ使い勝手にしてくれ」という注文がなされる。また、設計者の中にも、既存のシステムとなるべく同じ設計しようとする人がいる。そのほうが全く新しい「画面」を設計するよりも、楽だからだ。

★

しかし、プラットフォームが違えば、一般的な操作性も変わる。C/S で使われているファットクライアントな設計が、必ずしも Web システムで使いやすいとは限らない。むしろ、従来の設計をそのまま Web に持ち込むと、不自然な操作性になってしまうことも多い。既存のユーザーは満足するかもしれないが、新しいユーザーにとっては、むしろ使いにくく感じられるだろう。

また、この「不自然な設計」は、一般的に、実装（プログラミング）の手間を増やす。C/S では簡単にできていたことが Web ブラウザでは実現できない、ということも多く、リッチクライアントと称されるような拡張的な技術（例えば Ajax や Flex のような）を導入せざるをえないからだ。最近では、そうした技術もかなり普及し、開発効率もよくなってはいるが、それを使わない場合よりも工数が増加することには変わりない。

★

このように、システムを全面的に作り直す際には、旧システムの設計を単純に流用するのではなく、いったん、要件定義まで立ち返って考え直すべきだろう。

旧システムを参考にする場合も、その構造がどうなっているかということよりも、旧システムが作られた理由、即ち、そのシステムが解決すべき問題が何であるかということに注目すべきだ。そして、その問題を解決するためのシステムを新しいプラットフォームで作ったらどうなるか、ということを改めて考えるのである。

つまり、それは全く新規のシステムを作るのと同じことである。システム開発者にとって、何も特別なことではないだろう。しかし、旧システムが存在しているとなると、どうしても、人はそれに引きずられてしまいそうになる。そういう意味では、全く新しいシステムを作るよりも、既存のシステムを作り変えることのほうが難しいことなのかもしれない。

応援のクリックお願いします →