失敗プロジェクト─解決に向けての第一歩─

2006.11.30

　前回は，要求仕様の不備がプロジェクトの後半における仕様変更の発生につながり，失敗プロジェクトにつながることを述べた。今回は，失敗プロジェクトにおける，仕様策定の進め方について問題点を分析し，解決のための方策について考えてみる。

従来の要件定義の進め方＝そこに問題があった

　これまで行っていた要件定義の方法は，以下のようなものであった。

ユーザーに新システムの概要についてヒアリングする
大まかな業務フローについて確認する
機能一覧と機能仕様書を提示し，合意を得る

　実はユーザーは，この合意時点で，そのシステムを使用した業務の具体的なイメージまでは想像できていなかった。

この機能仕様で問題なく業務が流れるか
想定される人的リソース（人数やスキル）で，想定時間内に業務が遂行できるか
そもそも自部門の目標達成に向けて，方向性が合っているのか

　これらは重要な観点であるが，要件定義時点では把握できておらず，問題がある場合には，動作確認や検収テストの段階で，実際に動く機能を目の前にして初めて顕在化する場合が多かった。

ユーザーサイドの事情＝投資効果への責任，ラインからの突き上げ

　ユーザーのIT担当者は，業務変革という使命をおび，企画と予算獲得，ライン担当者の取りまとめといった役割を担っている。財務部門に費用対効果について説明を求められるし，新システムによる新しい業務の導入に際しては，ライン担当者からの風当たりも強いだろう。

　開発中に要求仕様（要件）の不備が発覚し，開発サイドへ要件変更を依頼することになったとすれば，財務部門に追加費用を認めてもらわなければならない。財務部門から費用の超過について糾弾され，場合によっては予算の追加が認められない場合もある。

　逆に，そのまま要件を変更しなければ，新システムによる業務が機能しないなど，ライン担当者から新システムの利用自体拒否される可能性もでてくる（それでなくても，既存の業務に習熟しているライン担当者にとっては，業務の変更そのものに抵抗を感じる場合が多いのだから）。

　このような板ばさみの状況から，なかば自衛手段のような理由で，「要件を最初から明確には決めない」という風潮が生まれていた。

開発サイドの問題意識＝ユーザーが悪いのか？

　一方，開発サイドでは「業務仕様はユーザーの責任」「無理な仕様変更を要求するユーザーが良くない」「自分たちの責任範囲は，与えられた要件に基づき正しく動作するシステムを提供するまで」と考えていた。

　ユーザーの知恵と知識と経験をうまく引き出すための努力や，仕様策定の方法に問題があるとの意識はなく，その結果，状況が改善されることはなかった。最終的には，使われないシステムができあがったり，納期やコストが超過した失敗プロジェクトにつながったりと，悲しい結果につながってしまう。

　ユーザーの責任といってしまえばそれまでだが，このままではお互いに不利益な関係になってしまうことが懸念された。

解決に向けて＝WIN-WINの関係構築のために

　この状況を打開するには，最初の要求仕様（要件）の精度を上げるしかないと筆者は考えた。しかし，プロジェクト初期の段階で仕様を詳細なレベルまで強引に決定し，厳格な要求管理によって仕様変更を抑えるだけでは問題の解決にはならない。

　プロジェクト収支は守れたとしても，使われないシステムが出来あがり，顧客満足度が落ちては意味がないからだ。ユーザーとWIN-WINの関係を構築するためには，業務目的に合致した，正しいシステム要件をプロジェクトの早い段階から定義し，不必要な仕様変更を元から抑える必要がある。

　システムを業務の一部として捉え，開発サイドとユーザーサイドの双方が参画して，その目的を達成する仕組みを互いに協力しながら定義しなければならないと考えた。

　最上位の方針となる経営戦略，IT戦略をベースに，BSC（balanced scorecard）やKPIの手法によって，ビジネス価値に基づいた「業務システム」を定義する。これを可視性が高く，実際の業務をリアルにイメージできるドキュメント（システムの使用イメージを含んだ業務フローや，ユーザー・インタフェースのモックアップなど）を使用して，開発サイドとユーザーが共通の認識を基に，協力して仕様を検討する。

　実際に動くシステムができあがる前に，考え方の相違や，業務の現実性を阻害する要因を顕在化させ，早期に対応する。以上のことが重要と考えたのである。

　これを確実に実行すれば，ユーザーは，以下のメリットを得ることができるはずである。