コスト最優先で力量が定かでないSIベンダーにシステム開発を発注。結果としてベンダー側の経験/技術不足がたたり，システム・テストで「レスポンスが5分以上も返ってこない」「バッチ処理が異常終了する」などのバグが多発した──（某メーカーの人事システム）

　いい加減なフィット＆ギャップ分析しかせず，どんぶり勘定で開発費を見積もりプロジェクトをスタートさせたことで，10億円以上の追加負担が発生。ユーザー側の猛抗議にあい，追加コストの大半はベンダー側が負担するはめに──（某金融業のERPシステム）

　ベンダー側の担当SEが立て続けに2回交代。担当者間でRFP（提案依頼書）の内容や合意事項が全く引き継がれておらず，度重なる手戻りで稼働時期が7カ月も遅延──（某製造業の生産管理システム）

繰り返されてきた失敗プロジェクト

　システム開発の現場では，今日もまた失敗が繰り返されている。その原因の本質を突き止めたい──そんな思いから日経システム構築は特別取材班を編成し，これまで30を超える失敗プロジェクトを取材。プロジェクトの当事者からその原因や失敗に至った経緯を詳しく聞き，その実態を『なぜ繰り返すのか 失敗プロジェクト』という連載コラムで報告してきた。冒頭の事例は，そこからの抜粋である。

　何を「失敗プロジェクト」と定義するかは難しい問題だが，代表例は当初計画していたQCD（品質・コスト・納期）を満たすことができないケースであろう。冒頭で紹介した3つの事例がそれに該当する。

　たとえ表面上はQCDが満たされていても，成功とは言えないプロジェクトもある。

　とある情報システム子会社に所属するSEのA氏は，プロジェクト・マネジャ（PM）が独断専行したオフショア開発が難航し，眠れない日々が続いていた。委託先から納品されたプログラムは，単体テストも通らないほど品質が劣悪。その尻拭いでA氏の時間外労働は毎月160時間を超えていた。休日出勤が常態化していたA氏がようやく取得した代休日に，突然PMから呼び出しがかかる。出社した先でPMの口から出たのは，オフショアを強行した自分の責任を棚に上げ，作業が遅延していることへの叱責。この瞬間，A氏の心はポッキリと折れ，医師からうつ病の診断が下されてしまった。

　現場のエンジニアが疲弊して体調を崩してしまったり，退職するまで精神的に追い込まれたりしたケースも「失敗」の1つと言えよう。

当事者意識が足りない

　なぜ，プロジェクトの失敗は繰り返されるのか。経験豊富なPMにその理由を尋ねると，「（失敗したプロジェクトの大半は）WBSなどの工程管理手法を取り入れていない，取り入れていても機能していない」と，失敗の原因はマネジメントの不備にあると指摘する。確かにPMは，リスクの洗い出しや管理の手腕が問われる。だが「PMの力不足」の一言で責任を押し付けて終わりでは，その原因の本質を見誤ってしまいかねない。

　本質を探るため，失敗プロジェクトに参画したメンバーの言動や行動を分析したところ，現場にはびこる問題点が見えてきた。その1つが「ステークホルダーとしての自覚の無さ」である。

　システム開発プロジェクトには，「情報システム部門」「SIベンダー」「ユーザー部門」「PM」「経営陣」といったステークホルダーが集う。失敗に至った事例では，ステークホルダー間で役割分担のコンセンサスが取れていなかった。互いに「自分の役割ではない」と当事者意識が足りない開発現場がとても多い。当事者としての意識が希薄であれば，失敗の兆候を見つけることは難しい。

　ある事例では，ユーザー部門間で要件の取りまとめが難航した際に，「ほかの仕事で手一杯だから」と情報システム部門の担当者がプロジェクトから去ってしまった。急きょ，ベンダーSEが各課の担当者の意見を集約したが稼働予定に間に合わず，一部機能を先送りする事態にまで追い込まれた。ステークホルダーとしての自覚のない情報システム部門がベンダーに仕事を丸投げしたことで，プロジェクトの「遅延」を招いた例といえる。

軌道修正の声が届かない

　誰かが失敗の兆候に気がつき，軌道修正のプロセスが正常に機能すれば，プロジェクトは危機的な状況を脱することができる。ところが，失敗プロジェクトの現場では，誰かが失敗の兆候に気づいて声を上げても，その声が伝えるべき人に“届かない”実態が明らかになった。

　声が届かない理由は様々だ。例えば，「誰かが古い常識に固執したとき」。ある事例では，ユーザー数が倍増する見込みのアプリケーションで性能不足を補うため，100万円程度のサーバー増設で乗り切ろうとSEが進言したが，上長である担当役員は「性能不足はチューニングで何とかするものだ」と頑なに提案をしりぞけた。急場はチューニングで凌いだものの根本的なリソース不足は解消されない。上長はITコンサルタントに相談費用を60万円も支払った挙げ句に，結局サーバーを増設するはめに陥った。

　この例では，対策の緊急性やハードウエアの価格を考慮すると現場のSEの判断は妥当だった。ところが上長は，ハードウエアが高価な時代の常識に固執したことで判断を誤ってしまった。このほか，プロジェクトのメンバーが失敗の兆候を指摘しても，「高をくくって真剣に受け止めない」ことで失敗に至った事例も数多くある。声が届かず軌道修正できないことも，失敗が繰り返されてきた原因の本質といえる。

同じゴールを目指すから“チーム”

　失敗の兆候を見逃したり，その兆候を糸口に適切な対処ができなければ，プロジェクトは破綻へと突き進む。失敗プロジェクトを生み出す要因は「当事者意識の欠如」と「軌道修正の機会の見過ごし」にあった。プロジェクト・メンバーが“他人任せ”を改め失敗の兆候を見つけだし，チームで危機感を共有し軌道修正を図れば，失敗の悪循環を断ち切れる。

　日経システム構築 8月号特集では，失敗の危機に直面しながらも，上記ポイントを実践することでプロジェクトを完遂させた事例を取り上げた。危機を脱したプロジェクトに共通していたのは，「メンバー全員がプロジェクトの成功を願っている」こと。“良いシステムを作り上げる”という同じゴールを目指しているからこそ，誰かが動き出すのを待つのではなく，自ら率先して手をさしのべる。詳細は本誌に譲るが，PM1人がプロジェクトの成功を願うのでなく，チーム全体の共通目標と据えることで，彼らは遅延や疲弊といった危機を乗り越えていた。

（菅井　光浩＝日経システム構築）