開発の終盤で「なんかイメージと違う」と言われた経験は、エンジニアにもPMにも一度はあるはずです。これは仕様書の精度の問題ではなく、「そもそも何を合意しておくべきか」の設計ミスです。
なぜ「仕様書通りなのにちがう」が起きるのか
PMとエンジニアの間で繰り返される認識ズレには、共通した構造があります。
仕様書は「何を作るか（What）」を記述するものですが、多くの場合「なぜ作るか（Why）」と「誰が使うか（Who）」が抜け落ちています。エンジニアは与えられたWhatを忠実に実装します。しかし、WhyとWhoが共有されていないと、細かな判断局面——ローディング中の表示、エラーメッセージの文言、ボタンの配置——でPMとエンジニアの判断基準がズレ始めます。
ある調査では、開発プロジェクトの手戻りの約60%が「認識の不一致」に起因すると言われています。仕様書に書かれていないことは、各自の「当たり前」で補完されるからです。
仕様書だけでは埋まらない「言語化されていないゾーン」
エンジニアが「仕様通り」に実装し、PMが「それじゃない」と感じる——その間には、言語化されていないゾーンが必ず存在します。
このゾーンは、役割分担を明確にすれば解決するわけではありません。むしろ「PMが決める」「エンジニアは実装する」という分業が、互いの思考を見えにくくさせることがあります。PMが仕様を書く前に思い描いているユーザーの動き、エンジニアが実装中に感じた違和感——こうした情報は、意識して共有する仕組みがなければ伝わりません。
認識ズレを減らす3つの実践
PMとエンジニアの協業で効果的だった3つのアプローチを紹介します。
① キックオフでユーザーストーリーを一緒に書く
PMが一人でユーザーストーリーを書くのではなく、エンジニアと声に出しながら作ります。「○○な状況の△△が、〜したいために□□する」という形式で合意するだけで、互いの前提のズレが驚くほど早く浮かびます。
② 着手前に「完成の定義（Definition of Done）」を合意する
タスクに着手する前に、「何ができたら完成か」を箇条書きで3〜5項目合意しておきます。「完成」の解釈が人によって異なることは珍しくありません。この一手間が、後工程の手戻りを大幅に減らします。
③ スプリント中に小さく見せ合う習慣をつくる
2週間後にまとめてレビューするのではなく、3〜4日ごとに途中経過を確認し合います。早い段階での「あ、そういうことか」は、リリース前の「なんかちがう」を防ぎます。
さいごに
PMとエンジニアの協業の本質は、役割分担の明確化よりも「同じ絵を描けているか」を確認し続けることです。仕様書を精緻にする前に、まず一度、ユーザーストーリーを二人で書いてみてください。そこから見える景色が変わります。
開発チームの協業文化や働き方に興味があるエンジニア・PMの方は、ぜひ一度お話しさせてください。