技術は変わるが開発の失敗原因は変わらない：情報マネージャとSEのための「今週の1冊」（55）

クラウドサービスが進展し、「ITは利用する時代になった」などと言われ始めて久しい。だが、システム開発の基本はどんな時代になっても決して変わらない。

ヒューマン・コミュニケーションで成功する情報システム構築

・著=桐谷恵介／網谷真／石坂博之
・発行=中央経済社
・2011年7月
・ISBN-10：4502687901
・ISBN-13：978-4502687907
・2800円＋税
※注文ページへ

　クラウドサービスやパッケージ製品が充実し、企業にとってますます情報システムを利用しやすい環境になっている。だがシステム構築の現場では、「毎日のように徹夜したり、出社拒否となった部下の説得に自宅に赴いたり、身体を壊して入院したり……」。なぜいつもプロジェクトは予定通りに進まないのか、なぜシステム構築が失敗するリスクは高いのだろうか。それはシステム構築で求められるものが「あいまい」になりがちなためだ――。

　本書「ヒューマン・コミュニケーションで成功する情報システム構築」は、プロジェクトの失敗要因として、開発関係者間のコミュニケーションの在り方に着目した作品である。冒頭で挙げた「求められるものがあいまい」というのは、システムは「ある意味、どのようにも作れる」という意味だ。よって、「どんな機能のものをどう作るかは、人対人のやり取りの中で決めていく」必要があるのだが、往々にして「開発者同士」「発注者と受注者」「担当者と管理者」のコミュニケーションが十分ではない。本書では、これがほとんどの失敗プロジェクトの原因であるとして、多数の失敗パターンを挙げつつ、システム構築を成功に導くコミュニケーションの方法を具体的に紹介しているのである。

　例えば、コミュニケーション不足の典型例として「要件定義が終わった気になる」ことを挙げている。本来なら、まずは「対象となる業務を俯瞰して全体像を把握」し、「業務の規模感、問題点や課題が潜在している場所、合意形成しなければいけない利害関係者などを明らかに」する必要がある。

　だが、「目先の検討課題にばかり目が向かってしまい、その都度場当たり的な解決策を抽出してしまう」。また、要件の具体化に当たり、「解決しやすい業務課題や構築しやすい業務機能にばかり目が」向いてしまう。この結果、確かに要件定義書は作るのだが、「全体として整合性が取れた解決策を」見出せていなかったり、「本質的な業務改善に結びつかない」ものになっていたりして、結局は失敗するというわけだ。

　筆者はこれに対して、「情報システム構想で定義した全体概要をもとに全社でウォークスルーを実施し、業務機能に漏れがないか、課題抽出に偏りはないか、利害関係者は正しく抽出されているかを確認する」べきだと述べる。これによって漏れや不備が検知された場合、即座に軌道修正しなければ、利害関係者の反発や不信を買い、「合意を得るための膨大な戻り作業や追加作業が発生するか、場合によってはプロジェクトの破綻を招いてしまう可能性もある」ためだ。

　「やった気になるテスト」も失敗の代表例だという。ご存じの通り、テストには「不具合を検知するためのテスト」と「品質を保証するためのテスト」がある。前者は「単体の機能に不具合はないか」「機能間の結合に不具合はないか」といった観点からシステムの動作を検証し、後者は「業務機能や他システム間連携の整合性は確保されているか」「業務運用に耐え得るシステムとなっているか」などを確かめる。

　だが現実には、納期に追われて、こうした目的の違いを認識し、それに応じた観点や検証基準をきちんと設定しないまま、ただ漫然とテストを行ってしまう。加えて「開発とテストは相反する役割」であるにもかかわらず、開発者がテストを兼務することも多く、これが余計にテストが軽視される一因となっている。著者はこうした現状に対し、重要な問題を見落として後で大幅な手戻りが生じることのないよう、テストについても関係者間でコミュニケーションを取り、「システム構想の中で、どのように品質を保証していくのか、テストの基準とやり方を十分吟味」するべきだとして、その具体的な方法を紹介するのである。

　興味深いのは、プロジェクトで起こりがちな事象だけではなく、“人”にも失敗原因を見出している点だろう。例えば、優先順位付けの考え方がなく、「できます」「頑張ります」といった声を重視する「体育会系のノリ」のプロジェクトマネージャ、「担当範囲ではない」などと言って業務現場からのコミュニケーションを拒絶するシステムエンジニア、要求に一貫性がなく思いつきで要求を挙げてしまう業務現場担当者、そして「改革を掲げることで満足し、情報システム構築が開始されれば、全て現場の担当者に丸投げしてしまうような経営者」などだ。著者は「こんな関係者がいると必ず失敗する」とばっさり切り捨てている。

　本書ではこうした見解を基に、「コミュニケーションは場を作ることから始まる」として、全関係者を同じ方向に向かわせるための目標設定や役割分担、ルール作成の在り方などを詳しく解説。 また、的確な結論を導き出す議論の方法や協力関係の築き方、ツール活用も含めた円滑なコミュニケーションのテクニック、そしてプロジェクトの礎となる人間関係構築の重要性など、開発成功に求められる要件を全方位的に網羅している。

　ただ、本書の大きな特徴は、セオリーと呼べるような基礎的な問題解決策・回避策にフォーカスした教科書的な仕上げとしている点だ。よって、開発・運用の現場経験が長い人にとっては、すでに知っているか、体験済みの話ばかりかもしれない。だが、そもそも開発失敗の最大の要因は、多忙な日々に流されて、ありがちな事象・問題を見過ごしてしまうこと、言い換えれば、基本をないがしろにしてしまいがちな姿勢にある。その点、本書をその時々の状況に応じてひも解けば、今プロジェクトが失敗パターンに陥りかけていないか、明確に気付かせてくれるのではないだろうか。

　またもう一つ、本書が示唆する重要なことは、典型的な失敗パターンは決してテクノロジにひも付いたものではないということだろう。すなわち、テクノロジのトレンドは時代とともに移り変わっても、人間がシステムを構築する限り、その基本的な失敗パターン、成功パターンは変わらないのだ。経営目標を基に、システムで実現したい要件を考え、絞り込み、計画期間内でシステムに落とし込む。このためには、関係者間の密接なコミュニケーションが不可欠になるというごく当たり前の事実を、本書を通じてもう一度見直してみてはいかがだろうか。