トラップだらけのシステム開発──『動かないコンピュータ』読書感想文

社内のエンジニアさんに勧められた本。
「動かないコンピュータ」とは、開発内容が当初の目的を達成できていなかったり、開発後に事業に支障が出るほど不具合が多く生じてしまった情報システムのことを指す。

2002年刊行。書かれていることの本質的な課題感は、20年経っても変化していないように見受けられる。
それだけ人間と人間とがより集まって新たな仕組みを構築するという行為は「難しい」ということなんだろう。技術の進化により、つくるものがさらに複雑化し、関与する人間が増え、それぞれの専門性はどんなにがんばってもそれぞれにしか見えない部分がある。

そもそも本書に取り上げられる事例のようにたくさんの失敗例があってなお、システム開発の難易度の高さについての認知が一向に浸透しないのはなんでだろうと疑問が湧くのだが──いったんそれは置いておくにしても「開発着手前にリスクをすべて見通すのは無理」だと、まずはそれを念頭におくべきではないかと思う。
「潜んでいるリスクをなるべく早く、そして正しくプロジェクト全体に認識させる」体制やコミュニケーションといったプロジェクト根本部分の設計が肝になるのだろう。

動かないコンピュータが生まれる時

動かないコンピュータが生まれる理由は、多様で複合的だ。
以下に、現場あるあるだなあと感じた点を挙げていく。

要件定義が進まない

経営・マーケ・システム・事業部……さまざまなステークホルダーの多数の意見を束ねて、最適なシステムを提案する。もちろんそれをまとめるだけでも難易度が高い作業なので、開発側の実力不足などが遅延に影響することもあるが、一番の要因は“政治”が絡み、それに押されがちになることではないかと思う。

そういう現場を、よく目にも耳にもする。

コミュニケーションコスト増とコミュニケーションロスの構造

設計・開発までは誰の目にも必須工程として見えやすいから予算も通りやすいし順当な工数を確保しやすい。
しかし慎重で精度の高いテストの重要さや、地道で粘り強い進捗管理がプロジェクトの成功を決めるのだということはなかなか見えづらいのは事実だと思う（アジャイル開発などでテスト・進捗管理・コミュニケーション工数が実工数の半分以上を占める提案をした場合、果たして初期からクライアントは理解を示してくれるだろうか？）。

事業戦略上の都合

ビジネスなんだから、ビジネス都合はもちろん最優先だ。
だが、その“都合”が近視眼的でないかは冷静になって一度考えてみる必要がある。長期的影響を鑑みたら、今遅延を判断する方が“都合が良くないか”。

使い勝手を重視しすぎる

この例にしろ、「ユーザーの使い勝手を向上する」という一側面だけ見ると誤った判断をしていないように見えるのがまた恐ろしいところだと思う。

開発だけでなく、ビジネスはトレードオフの関係値にある事象にあたることが多い。「全部優先したい」は心情として理解できるが、納期も予算もある上でそれを容れることは不可能だし、そういう無理な要望が通る事態が罷り通る現場が、動かないコンピュータを生む原因そのものでもある。

この事態の改善には、開発側が説得スキルを上げること、それから説得を諦めないことが絶対に必要だ。そしてその際に、乗り越えねばならない三つのポイントがあると私は思っている。

まず一つ目は、要件定義の段階で技術・開発面に明るいエンジニアの参画が薄いことが多いため、計画のリスクに気づいてきちんと伝えられる体制がないということ。
のちのち不具合修正で再開発するに等しい額の損失を出すくらいなら、要件定義の初めから優秀な設計担当エンジニアを参画させておく方が断然安上がりだと思う。

二つ目のポイントは、技術者のコミュニケーションスキルの課題。
理路整然と説得力のある言葉を紡ぎ出せるプロマネ・コンサル職に比べ、技術者は背景の文脈などを汲まずにあくまで事実ベースで話す人が多い印象を受ける。目の前に出された要件のみに対して、確かに正しいが最適解でないものを回答する傾向にあるように見える（もちろんすべての人には当てはまらない）。

三つ目のポイントは、クライアントと開発側の意見をすり合わせて説得力のあるストーリーとして束ねられる人材の不足。クライアントの説得には、開発優先度の整理と共に、クライアントと同等またはそれ以上のシステムの未来像を開発側が描ける必要がある。
「この要件を入れると、将来このような場合にこのようなリスクが生じる可能性がある」とストーリー立てて伝えられるか。

……こうまでしても話が通じないことも現実には多いと思うが、いずれにしても要件定義の段階でクライアントとの合意形成をオンスケで、現実的かつ（絶対にある追加要件に備えて）汎用性ある内容でできるかが大きな鍵を握っていると思う。

何が「動かないコンピュータ」のリスクを低減するのか

開発というもののどこにリスクがあるのかを、お互いの専門性を超えて──専門性が異なるからこそツッコミ合い、一つの目標に向かい協力して邁進していく。
そんな開発の体制は理想だが、大規模になればなるほど難しい。さらに、実現したとして、それでもなおリスクは至る所に潜んでいる。
優秀なチームが組めたところで、業務を属人化しすぎると今度は代替が効かないので体制の堅牢性という面ではリスクになる。

システム開発というのは、こうも難しい。