不注意や単純ミスに端を発するシステム障害が後を絶たない。その背景にあるのは、仕様の誤解や機能の漏れを防ぐ「レビュー」が形骸化しているという問題だ。システム・トラブルが経営に与えるダメージは極めて大きい。今こそ、レビューの機能不全がトラブルの根本原因であることを認識し、効果的なレビューのやり方を見いだすべきだ。

　今年1月26日。全国の金融機関を震え上がらせるトラブルが起こったのは記憶に新しい。金融機関のATM（現金自動預け払い機）をつなぐ「統合ATMシステム」に不具合が発生。ほぼ終日、金融機関をまたぐ提携処理が成立しにくくなった。原因は、たった1カ所の設計ミスである。

　統合ATMは重大な決済インフラであるだけに、担当ベンダーのNTTデータは慎重に慎重を期して開発作業を進めた。稼働の3年以上前から要件の検討を始め、テストだけでも1年以上費やした。それにもかかわらず、テストで検出できなかった一つのミスが1700以上の金融機関、10万台以上のATM（現金自動預け払い機）に影響を与えるトラブルにつながった。

　こうしたトラブルを引き起こしてしまうこと自体、確かに大きな問題である。ただし今回に関して言えば、大トラブルの割に復旧は早かった。NTTデータなどは当日中に設計ミスの究明と修正を終え、翌日には事態を収拾できたからだ。

図1●システム・トラブルや稼働延期に見舞われる背景には、レビューの機能不全がある

　統合ATMシステムで発生したトラブルでより深刻なのは、「すぐ直せるようなミスを、3年以上に及ぶプロジェクトの途中で見つけることができなかった」ことにある。その理由を、単なるテストの不備で片付けてはならない。問題の根はもっと深い。

　その裏には、「レビューが本来の役割を果たしていない」という根本的な問題が横たわっている（図1[拡大表示]）。あるITベンダーの幹部は、「設計の細部までレビューを徹底していれば、今回のような問題は起こらなかったはず」とみる。

工程ごとに依頼者の視点でチェック

　システムの新規開発や再構築、修整、統合などのプロジェクトでは、必ず「レビュー」と呼ぶ作業を実施する。

　レビューは作業を依頼する側が主体的に行うべきもので、「頼んだとおりにシステムが作られているかを確認する作業」を指す。要件定義や基本設計のレビューであれば、システム部門が作成した設計書をユーザー部門がチェックする。詳細設計や実装段階でのレビューでは、ITベンダーの作成した成果物をシステム部門が検証する。作り手と依頼側だけでなく、品質管理担当者など第三者が参加して、成果物の品質をチェックすることもある。

図2●ユーザー企業がシステム開発プロジェクトで実施すべきレビューの概要。プロジェクトの開始段階と終了段階におけるレビューの重要性が、特に高まっている

　レビューの最大の役割は、「ミスを含んだまま次の工程に進まないように最終的なチェックを実施することだ」（JTBの野々垣典男 営業企画本部経営企画室IT企画担当部長）。通常は、システム開発における要件定義や設計などの各局面で実施する（図2[拡大表示]）。

　レビューによって仕様書や設計書に問題がないことを確認できれば、その開発工程は完了したことになり、プロジェクトは次の工程に進む。もしもレビューで問題が見つかれば、どこが問題なのか、どう直すのかを作り手と依頼側が話し合い、その方針に基づいて手直しをして、その結果を再度レビューする。問題がすべて解決する、もしくは解決のメドが立つまで、この作業を繰り返す。

　レビューは確固たる方法論があるわけでなく、進め方は各社各様だ。レビューを実施するレビュアは自分の知識と経験に基づき、成果物を評価する。「参加者全員で仕様や機能に漏れがないかをチェックする“気づき”の場を提供する役目も果たす」（富士通の合田治彦ソフト・サービス共通技術センターPMO・SI技術統括部アプリケーション品質部部長）。

「機能不全」に陥る企業が続出

　ユーザー企業にしてもITベンダーにしても、システム開発プロジェクトでレビューをやらないことはまずあり得ない。以上で説明したように、レビューが本来の役目を果たしているなら、問題を事前に洗い出し、トラブルを未然に防ぐことができるはずだ。

　ところが現状では、レビューが本来の役割を果たさず、「機能不全」に陥るケースが少なくない。以下の四つは、いずれも実話である。

ケース1：要件定義の段階で、IT専門用語がわからないユーザー部門と業務を十分理解していないシステム部門との間で意思疎通ができないまま、プロジェクトが設計段階へと進んだ。要件に関する誤解が残っていたが、レビューではそれに気づかなかった。

ケース2：システム開発を発注したITベンダーから、ダンボール箱に詰められた大量の詳細設計書が納品された。レビューを担当するユーザー企業は、中身を読まずに承認のハンコを押した。

ケース3：システムの稼働後にレビューが不十分だったために機能漏れが発覚した。ITベンダーに抗議したところ、「ドキュメントに書いていない」と冷たくあしらわれた。

ケース4：「プロジェクトの進捗が遅れている」という理由で、ITベンダーがレビューの実施を省略した。

　すべての企業でこうした事態が発生しているわけではないにしても、レビューを“軽視”する傾向があるのは否めない。これではトラブルの芽を早期に見つけることはできない。結果的にテストで不具合が見つかり、手戻りを引き起こす。手戻りの修整にかかる余分な費用と時間が、貴重なIT投資コストを圧迫する。例えばケース2の場合、受け入れテストで機能の不備が大量に見つかり、システムの稼働が9カ月遅れて開発費用が膨らんだ。ケース3では機能漏れにもかかわらず、ITベンダーから開発費用を追加請求された。

　それでもテストで問題が見つかればまだマシだ。最悪の場合、冒頭に挙げた統合ATMシステムのトラブルのように、システムの稼働後にミスが顕在化してトラブルが起こり、システムが使えなくなる。顧客サービスに支障を来し、ユーザー企業の収益に悪影響を及ぼす。企業イメージも悪化する。レビューの機能不全は、特にユーザー企業にとって致命傷につながる事態を引き起こしかねない。

　システム・トラブルを“対症療法”でしのぐのにも限界がある。今こそ、レビューのあり方を見直してトラブルの根本原因を絶つ時期が来ている。

手戻り・漏れ・誤解を防げ

図3●効果的なレビューは、手戻り・機能の漏れ・仕様の誤解といったシステム開発における大敵の退治につながる

　レビューの見直しに取り組むユーザー企業やITベンダー約30社の動きをまとめた結果、理想とするレビューの姿が浮かび上がってきた。「システム開発の大敵である手戻り・漏れ・誤解を退治するレビュー」というのがその姿である（図3[拡大表示]）。

　誤解や漏れを防げば、ミスによるトラブルは減る。手戻りもなくなり、プロジェクトが遅れることは少なくなる。レビューをうまくこなすユーザー企業は、常にこの三つのポイントのいずれかを意識しながら、具体的な取り組みを実施している。

　三井生命保険やカブドットコム証券、コニカミノルタは、要件定義や設計・開発などの各工程で問題を先送りせずにレビューを徹底することで手戻りを防いでいる。三井生命の小野氏は、「問題の先送りは将来への背信行為」と言い切る。

　要件や機能の漏れをレビューで見つけ出す具体的な取り組みを実施しているのが、東京海上火災保険やJTB、積水化学工業だ。大和証券や清水建設は、目に見えないシステムを可視化することで誤解を防ぐ。