一つの漏れもなく実装したのに「これじゃない」と言われた ― 「価値」の原則が教える本当の成功基準

要件定義書のとおりに、一つの漏れもなく実装した。テストも通り、品質は文句のつけようがない。それなのに利用部門の反応が鈍い——私が実際に経験した「完璧な的外れ」の話です。この記事では、その案件で何がズレていたのかから始めて、PMBOK第7版の原則④「価値」が言う本当の成功基準を考え直します。

この記事でわかること

仕様の完成度と、現場の満足がズレる理由
「価値」の原則が言う、本当の成功基準
要件の背後にある「誰のどんな価値か」を言葉にする方法

SIerで開発案件のPMをしている筆者が、PMP学び直しのノートを現場の反省と一緒に記事にしています。

価値の原則が言うのは、プロジェクトの成功は、予定どおり納品することではなく、利用者やビジネスに価値を生むことだということです。作ったものが実際に「誰かの役に立った」「業務が楽になった」——そこまで届いて初めて、プロジェクトは価値を生んだと言えます。視点を「成果物」から「その先の効果」へずらすのが、この原則の核心です。

完璧な実装が、現場の役に立たなかった
「要件どおり=価値」だと信じていた頃
なぜ「約束どおり」が価値から遠ざかるのか
意識するようになった3つのこと
よく聞かれること
まとめ
関連記事

完璧な実装が、現場の役に立たなかった

まだPMを任されるようになって日が浅い頃、業務システムの照会画面を刷新する案件でのことです。要件定義書は詳細に作り込まれていて、私たちはそのとおりに、一つの漏れもなく機能を実装しました。テストも通り、品質面では文句のつけようがない出来だと思っていました。

ところが、利用部門に使ってもらうと反応が鈍い。よく聞くと、「必要な情報は全部あるけれど、実際に使う場面で、見たい情報が一目で入ってこない」というのです。仕様に書かれた項目はすべて揃っている。でも、現場が本当に欲しかったのは「項目が揃っていること」ではなく「一目で判断できること」でした。仕様の完成度と、現場が求める価値が、静かにズレていたわけです。

この経験から、要件定義の段階で一つルールを足しました。機能ごとに「この機能で、誰の、どんな業務が、どう楽になるのか」を一文で書き出すのです。たった一文ですが、これを書こうとすると「あれ、これは何のための機能だっけ?」という空白が事前にあぶり出されます。作る前に価値の輪郭を確かめる。それだけで、「これじゃない」を大きく減らせるようになりました。

「要件どおり=価値」だと信じていた頃

かつての私は、「要件定義書に書いてある=価値がある」と暗黙に信じていました。書かれているのだから、作れば喜ばれるはずだ、と。

でも、要件はあくまで「手段の記述」であって、「目的そのもの」ではありません。書かれた要件の背後には、必ず「本当はこうしたい」という目的があります。そこを確認せずに文字面だけ実装すると、完璧な「的外れ」が出来上がります。「何を作るか」の前に「なぜ作るか」を一度たしかめる。この一手間が、価値と仕様のズレを防ぎます。