リスクを嗅ぎつける想像力

こまつ みつのり(Mitsunori Komatsu) 2007-12-01 11:33:54

ソフトウェア開発においては腕力以外の様々な能力が必要となってきますが、本当に重要なのは「想像力」だと思うようになってきました。特に「問題をイメージしリスクを嗅ぎつけることができるかどうか」という点で。

まず、プログラミングを例にとってみたいと思いますが、一口にプログラミングといってもプロジェクトや組織によって範囲が広い。

既に詳細設計書がガチガチに書きあがっていてその通りにコーディングするケースもあれば、ソフトウェアのデザインから設計しプログラミングを進めるケースもあるので、それぞれ「想像力」の重要度も変わってくると思います。当然、前者のほうは後者に比べると「想像力」の出番がなさそうです。でも実はとても大切な仕事があります。

「設計が間違っているのではあるまいか?」というスタンスに立ち、設計書に書いてあるロジックをイメージし徹底的に疑う、ことです。

基本中の基本は、「この設計通りにコーディングを行って仕様を満たせるのか?」です。昔の話ですが結構目にしました…

更に可能であれば、入力値チェックはXXXXだけどこの文字列を入れたらSQLインジェクションが成立してしまうのではないか?TCP/IPサーバーでlistenしてaccept&forkしているけどこのケースではゾンビプロセスが残ってしまうのでは?などなど。

自分が設計している場合、意外と甘くなってしまいがちですが、情けを捨てて脳内攻撃を行うことが必要です。また、コーディングを進めていくにつれ信号を発し始める問題もあるので忙しさにかまけて見逃さないようにする必要があります。

設計者だって人間ですから当然ミスがあります。常に完全な設計というのはありえません。自分のところに流れてきた情報を頭の中で想像してあげることで、問題を見つけてあげることができれば品質とスケジュールに貢献できて皆が幸せになれます。

逆に「設計書に書いてある処理を信じて疑わず、コードに書き写すだけ」の作業は、「自分で考える」ということを放棄しているも同然で、ちょっとしたコードジェネレーターができる作業をコストをかけて行っていることになります。自分の頭で考えない限り成長しませんし、何よりもそんな無味乾燥な作業って面白くないでしょう?

テストを行う場合は正に上記(「プログラムを例に〜〜〜」の箇所)の「想像力」が必要になりますし、要求定義の場合には「明文化されていない要求(しかも高難度で必須のもの)が隠れている」可能性を想像しリスクをつぶさなければなりません。プロジェクトマネジメントを行う場合は、常にプロジェクトが発生しうる問題を脳の中から一滴残らず搾り出し先手を打っていけるかどうかがプロジェクトの成否に関わるでしょう。経営層に近くなれば、現在のビジネスモデルが破綻していくイメージを、顔を背けずに想像していく必要があるのかもしれません。新規サービスの立ち上げはそれ以上に「想像力」が必要になりそうです。

最近の偽造問題も、発覚したらお客様がとても悲しむだろうし企業としても致命的なダメージを受けるのでは?とイメージできる程度の「想像力」があれば、起こらなかっただろうなぁと考えてしまいます。

と、ここまで偉そうに書いてきましたが、私自身、相手の気持ちを想像せずに叱ってしまうことがたまにあります…本当に「想像力」を鍛える必要があるのは私だったりして。

そもそも想像力ってどうやって鍛えるんでしょうねぇ。何かいい手は無いかしら…?

※このエントリはZDNetブロガーにより投稿されたものです。朝日インタラクティブ および ZDNet編集部の見解・意向を示すものではありません。

SpecialPR