トラップだらけのシステム開発──『動かないコンピュータ』読書感想文
社内のエンジニアさんに勧められた本。
「動かないコンピュータ」とは、開発内容が当初の目的を達成できていなかったり、開発後に事業に支障が出るほど不具合が多く生じてしまった情報システムのことを指す。
2002年刊行。書かれていることの本質的な課題感は、20年経っても変化していないように見受けられる。
それだけ人間と人間とがより集まって新たな仕組みを構築するという行為は「難しい」ということなんだろう。技術の進化により、つくるものがさらに複雑化し、関与する人間が増え、それぞれの専門性はどんなにがんばってもそれぞれにしか見えない部分がある。
動かないコンピュータを防ぐことは永遠の課題である。
〜中略〜
動かないコンピュータを防ぐ特効薬はない。解決への第一歩は、問題の所在を正しく認識することである。企業の経営者や幹部、社員など、情報システムの専門家以外の方々が、情報システム構築の難しさを知り、動かないコンピュータを自分自身の問題としてとらえる。ここからしか解決への道は開けない。
そもそも本書に取り上げられる事例のようにたくさんの失敗例があってなお、システム開発の難易度の高さについての認知が一向に浸透しないのはなんでだろうと疑問が湧くのだが──いったんそれは置いておくにしても「開発着手前にリスクをすべて見通すのは無理」だと、まずはそれを念頭におくべきではないかと思う。
「潜んでいるリスクをなるべく早く、そして正しくプロジェクト全体に認識させる」体制やコミュニケーションといったプロジェクト根本部分の設計が肝になるのだろう。
動かないコンピュータが生まれる時
動かないコンピュータが生まれる理由は、多様で複合的だ。
以下に、現場あるあるだなあと感じた点を挙げていく。
要件定義が進まない
情報システムは見かけ上、コンピュータとその中で動くプログラムにすぎない。しかし、先に見たようにさまざまな業務部門の担当者たちが、このシステムを利用する。したがって、各部門がどんな仕事をして、どのような情報をやり取りすると仕事が効率よく進むかを、全員で検討する必要がある。この最初の作業が何よりも重要である。この段階ではコンピュータの技術的なことは細かく検討しなくてもよい。残念ながら、この電機メーカーは要件定義をうまくやりきれなかった。
経営・マーケ・システム・事業部……さまざまなステークホルダーの多数の意見を束ねて、最適なシステムを提案する。もちろんそれをまとめるだけでも難易度が高い作業なので、開発側の実力不足などが遅延に影響することもあるが、一番の要因は“政治”が絡み、それに押されがちになることではないかと思う。
本来は、「ここはコンピュータで処理するところ、ここは手作業でやるところ、ここは仕事そのものをなくしてしまうところ」といったように、業務を整理していく必要があった。しかし、「これまで通りにしてほしい」と業務担当者に言われてしまうと、情報システムは、「ノー」と言えないものである。
そういう現場を、よく目にも耳にもする。
コミュニケーションコスト増とコミュニケーションロスの構造
システム開発の世界には、多段階の下請け構造がある。
〜中略〜
複雑業務要件を、かき集められた技術者たちが解釈して、プログラムを書いていく。ばらばらに開発されたプログラムを最後に合体して、当初に定義した要件通り動くかどうか確認する。これが情報システムの開発作業である。ちょっとやそっとでは、うまくいかないやっかいな仕事であることがお分かりだろう。
したがって、要件定義、設計・開発と並ぶ重要な作業は、「進捗管理とテスト」である。計画通りに開発が進んでいるか、要件通りのものが作られているかを確認する作業である。
設計・開発までは誰の目にも必須工程として見えやすいから予算も通りやすいし順当な工数を確保しやすい。
しかし慎重で精度の高いテストの重要さや、地道で粘り強い進捗管理がプロジェクトの成功を決めるのだということはなかなか見えづらいのは事実だと思う（アジャイル開発などでテスト・進捗管理・コミュニケーション工数が実工数の半分以上を占める提案をした場合、果たして初期からクライアントは理解を示してくれるだろうか？）。
事業戦略上の都合
あるコンサルタントは「当時の品質は、ソフトが完成する前の試用品レベルだった。本来なら正式発表や出荷を丸一年遅らせてでも、もっとしっかりした製品を出荷すべきだった」とまで言う。
そうしなかったのは、「マーケティング上の判断だろう」とこのコンサルタントは見る。
ビジネスなんだから、ビジネス都合はもちろん最優先だ。
だが、その“都合”が近視眼的でないかは冷静になって一度考えてみる必要がある。長期的影響を鑑みたら、今遅延を判断する方が“都合が良くないか”。
使い勝手を重視しすぎる
通信するデータの量が見積もりの十倍以上に膨れてしまった大きな原因は、使い勝手のよい画像表示機能を備えたシステムの通信量を予測しきれなかった点にある。
〜中略〜 広告代理店は始めから、現場のだれもが使いやすいシステムにしたかった。従来の端末にあった、「操作方法が分かりづらい」、「コード値を入力するのが煩わしい」といった問題点を、直感に訴えるグラフィカルな操作画面を使って解決しようとしていた。だが、使い勝手を追求すると、通信するデータ量がふくらんでしまう。
この例にしろ、「ユーザーの使い勝手を向上する」という一側面だけ見ると誤った判断をしていないように見えるのがまた恐ろしいところだと思う。
開発だけでなく、ビジネスはトレードオフの関係値にある事象にあたることが多い。「全部優先したい」は心情として理解できるが、納期も予算もある上でそれを容れることは不可能だし、そういう無理な要望が通る事態が罷り通る現場が、動かないコンピュータを生む原因そのものでもある。
この事態の改善には、開発側が説得スキルを上げること、それから説得を諦めないことが絶対に必要だ。そしてその際に、乗り越えねばならない三つのポイントがあると私は思っている。
まず一つ目は、要件定義の段階で技術・開発面に明るいエンジニアの参画が薄いことが多いため、計画のリスクに気づいてきちんと伝えられる体制がないということ。
のちのち不具合修正で再開発するに等しい額の損失を出すくらいなら、要件定義の初めから優秀な設計担当エンジニアを参画させておく方が断然安上がりだと思う。
二つ目のポイントは、技術者のコミュニケーションスキルの課題。
理路整然と説得力のある言葉を紡ぎ出せるプロマネ・コンサル職に比べ、技術者は背景の文脈などを汲まずにあくまで事実ベースで話す人が多い印象を受ける。目の前に出された要件のみに対して、確かに正しいが最適解でないものを回答する傾向にあるように見える（もちろんすべての人には当てはまらない）。
三つ目のポイントは、クライアントと開発側の意見をすり合わせて説得力のあるストーリーとして束ねられる人材の不足。クライアントの説得には、開発優先度の整理と共に、クライアントと同等またはそれ以上のシステムの未来像を開発側が描ける必要がある。
「この要件を入れると、将来このような場合にこのようなリスクが生じる可能性がある」とストーリー立てて伝えられるか。
……こうまでしても話が通じないことも現実には多いと思うが、いずれにしても要件定義の段階でクライアントとの合意形成をオンスケで、現実的かつ（絶対にある追加要件に備えて）汎用性ある内容でできるかが大きな鍵を握っていると思う。
何が「動かないコンピュータ」のリスクを低減するのか
動かないコンピュータ問題は、経営者、業務部門、情報システム部門、コンピュータ・メーカー、システム構築会社、そしてコンサルタントの全員で立ち向かうしかない、ということである。
開発というもののどこにリスクがあるのかを、お互いの専門性を超えて──専門性が異なるからこそツッコミ合い、一つの目標に向かい協力して邁進していく。
そんな開発の体制は理想だが、大規模になればなるほど難しい。さらに、実現したとして、それでもなおリスクは至る所に潜んでいる。
優秀なチームが組めたところで、業務を属人化しすぎると今度は代替が効かないので体制の堅牢性という面ではリスクになる。
システム開発というのは、こうも難しい。
