ITエンジニアの心得

一般的なソフトウェアを作ること自体は、実はそれほど難しくない。ちょっとしたWebサービスやスマートフォンのアプリをエンジニアが個人で作成して公開することなど珍しいものではなく、それこそ知識のない初心者が一般に出回っている書籍やインターネット上の情報を頼りにとりあえず動くものを作り上げるのも可能だ。

しかし、その難しくないはずのシステム開発のおよそ7割は失敗に終わると言われる。 なぜか。結局、難しいのは作り上げることそのものではなく、そもそも何を作るのかを決定することなのだ。

ソフトウェアは現実の問題を解決するために作られる。重要な要件を顧客自身が把握しているとは限らず、業界の常識として当然とされることなど一々開発側に共有されるとも限らない。潜在的なニーズを掘り出し、微妙な言葉の綾による企画側と開発側の認識のズレを適宜修正していくことは必須だ。

また、技術的な実現性のみを考慮すれば良いわけではない。所定の時間と人手という制約の中で難しいと判断したら、優先度の低い要望を切り落としたり、納期と費用の追加を交渉することも求められる。相手の言うことを唯々諾々と聞いているだけの無能には務まらない。

相手と密なコミュニケーションを取りながら最適解を導く営業的なセンスも必要になるのだ。受託開発において、ただ作るだけではなく、顧客へのコンサルティングにも踏み込むことが求められる所以でもあろう。ただコンピュータを操ることに秀でただけのオタクには担えない、泥臭く属人的な人間相手の商売なのである。曖昧模糊とした人間の自然言語を、杓子定規な人工言語へ翻訳することは決して容易くない。

下記の紹介図書の筆者は裁判所でIT関係の紛争を専門に扱う調停委員だ。実際にシリアスな裁判沙汰になった際に、法律家がどう言った判断基準を持っているかが紹介図書から伺える。これに目を通すことで、最悪の場合に備えて、受託開発の要所でどういった意思決定をすべきか示唆を与えてくれる。主にSIerにおけるシステムエンジニアの仕事に焦点を当てているが、Web系の企業においても受託開発を生業とするのであれば参考にすべき点は多々あろう。

多少の不備があろうと許容範囲内であれば完成とみなす、システム開発は開発側だけではなく発注側との共同作業として顧客にも一定の責任を要求するなど、他の業界から見れば異質と言える考え方が綴られている。開発ベンダーへの丸投げを戒めており、エンジニアでなくとも発注担当者も読む価値がある書籍だ。

もちろん、共同作業であるからこそ、開発側も不足や懸念を顧客に提示し、必要であれば相手にアクションを促すことが求められている。決して、「言われた通りに作ってさえいれば、後は顧客の責任」といったベンダーの怠慢な態度を認めるものではない。

その他、架空の事例を題材に、実際的な開発プロジェクト管理のノウハウについて語られている。全てを実践することは現実的には難しいであろうが、開発組織のマネージャーにとって幾ばくかのヒントにはなるはずだ。

ところで、悲しいかな、実際のSIerの開発現場では書籍中に登場するようなプロジェクト管理用資料や設計書などのドキュメント至上主義に陥り、手間に見合うかどうかを考えない大量の書類作成がなされることも珍しくない。現場を顧みない計画経済によって、時にデタラメに近いような設計書類が形式的に量産される、何と不毛なことか。

なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術