「仕様書を渡したのに、上がってきたものが全然違う」——開発現場でこの経験をしたPMやエンジニアは少なくないでしょう。原因を個人の能力や熱量に帰しがちですが、ほとんどの場合、構造的なプロセス設計の問題です。
PMとエンジニアの間で何が起きているか
PMは「なぜ作るか」を知っていて、エンジニアは「どう作るか」を知っている。この二者が協業するとき、最もよくある失敗パターンが「ドキュメントを渡しただけで認識が揃ったとみなす」ことです。
あるチームの計測では、スプリント終了時に「PMが期待した動作」と「エンジニアが実装した動作」に乖離があったケースが全スプリントの約40%に達していました。コードの品質は高く、テストも通っている。でも「欲しいものではない」——この状態が開発の巻き戻しを生みます。
認識齟齬が起きる3つの構造的な原因
① ゴールではなく「画面」を渡している
ワイヤーフレームや仕様書は「何を作るか」を伝えますが、「なぜそれが必要か・誰のどんな問題を解くか」まで書かれていないことが多いです。エンジニアはゴールを知らないまま実装するため、仕様に書かれていない判断場面でPMの意図と正反対の選択をします。
② レビューが「完成後」にしかない
設計フェーズと実装フェーズの間にフィードバックポイントがないチームは、完成してから初めて認識のズレに気づきます。1週間の実装が全部巻き戻るのは、「中間確認の欠如」が主因です。
③ 質問しにくいコスト感がある
「また細かいことを聞いていいのか」というプレッシャーがあると、エンジニアは曖昧なまま進めます。新しいプロジェクト・新しいメンバーの組み合わせで特に起きやすいパターンです。
協業を機能させる3つの設計ポイント
ゴールを一行で書く：仕様書の冒頭に「この機能で〇〇が△△できるようになる」を1文添える。エンジニアが判断に迷ったとき、この一文が意思決定の基準になります。
着手前5分レビューを習慣化する：実装に入る前に、エンジニアが「こう理解しました」と言葉で説明する5分を設ける。PMが確認するのではなく、エンジニアが話す形にすることで、齟齬の多くがここで見つかります。
「確認してくれてよかった」を声に出す：質問を歓迎するカルチャーは宣言だけでは生まれません。リーダーが「それを確認してくれてよかった」と明示的に伝えることで、チーム全体の質問コストが下がります。
さいごに
PMとエンジニアの協業が機能しているチームに、特別に優秀な人が揃っているわけではありません。「ゴールの共有」「中間確認の習慣」「質問しやすい関係設計」——この3つがあるだけで、開発の巻き戻しは明らかに減ります。
あなたのチームで、最後に「なぜ作るか」を全員で確認したのはいつですか。
開発組織のカルチャーや働き方に共感してくださった方は、カジュアル面談をお気軽にどうぞ。