要件定義フェーズでシステムに盛り込む機能要件を固める際、できることを承認してもらうだけではいけない。その要件でユーザーに承認を得たとしても、受け入れテストでユーザーから「このままだと業務では使えない」と指摘が入り、大きな手戻りになることが少なくないからだ。

PMに抜擢された若手有望株、Yさんのケース

　より具体的なケースを示そう。中堅SIベンダーの若手の中でも有望株のYさんのケースだ。基幹系システム開発を数多く手掛けた実績を評価され、メーカーE社の基幹系システム開発プロジェクトのPM（プロジェクトマネジャー）として抜擢された。その時のプロジェクトのことだ。

　プロジェクトの要件定義フェーズ、設計フェーズ、開発フェーズは予定通りに進んだ。ところが要件定義フェーズでYさんは、できることをユーザーに承認してもらうだけにとどめていた。

　その結果、受け入れテスト初日で波乱が巻き起こった。最も基本的な受注伝票登録の機能からテストを始めたところ、ユーザーから思わぬ指摘を受けたのだ。

ユーザー「伝票登録しようとしたら、“商品番号を入力してください”と表示されてエラーになったぞ」
Yさん「商品番号は必須項目となっていますので、項目がブランクだと登録できないようになっています」
ユーザー「商品番号の入力が必須なのは分かるが、商品番号が決まってない商品もある。その場合は、自動で商品マスターを登録してくれるんじゃないのか？既存システムはそうなっているぞ」
Yさん「いやそれはちゃんと押さえています。ですが、要件定義レビューの際に、“商品番号は必須で、商品マスターが登録されている事が前提でいいですね” と確認させていただいたはずですが・・・」
ユーザー「そんなこと言っていたか？あんたらもプロだろ。既存システムでその機能があることを知っていたのなら、なぜその機能がなくなると、ちゃんと言ってくれないんだ。この機能がないと業務では絶対に使えんぞ！」
Yさん「いや・・・。そう言われましても、要件定義のレビューでご説明させていただいているのですが・・・」

　「過去の基幹系システムプロジェクトの経験が生かすことができた。受け入れテストはキモだが、ユーザーとの関係性も良好だし、今まで一つひとつ要件を詰めてきているから大きな問題にはならないだろう」と思っていたYさん。彼にとってこの出来事は青天の霹靂だった。結局、その場で受け入れテストは中断。要件を再調整する大きな手戻りが発生してしまった。