「これで完璧なはずだ…」
何度も推敲し、詳細まで書き込んだ要件定義書。あなたは自信を持ってエンジニアに渡したはずです。しかし、返ってきたのは「これじゃ作れません」「結局、何がしたいんですか？」という、予期せぬ言葉と困惑の表情…。
良かれと思って努力した結果が、手戻りの多発、プロジェクトの遅延、そしてチーム内の気まずい空気。上司とエンジニアの板挟みになる「調整地獄」の中で、「もしかして、自分の能力が低いのだろうか…」と、自信を失いかけてはいませんか？
もし、あなたが今、そんな苦しい状況にいるのなら、まずこれだけはお伝えさせてください。
それは、あなたの能力不足や努力不足が原因ではありません。
その問題の根底には、PM（プロジェクトマネージャー）とエンジニアの「思考様式の根本的な違い」という、ほとんどの人が気づいていない、しかし非常に根深い壁が存在するのです。
何を隠そう、私自身も元々は、あなたが今まさにコミュニケーションに苦労しているエンジニアの一人でした。そして今は、皆さんと同じPMとして、さらには事業責任者として、日々究極の板挟みを経験しています。
だからこそ、私には両者の「言葉」と「痛み」を翻訳することができます。この記事では、なぜあなたの熱意が空回りしてしまうのか、その根本原因を解き明かし、明日から現場で使える具体的な「処方箋」をお渡しします。
【私の失敗談】完璧な要件定義書でプロジェクトを大混乱させた話
PMになりたての頃の、今でも忘れられない苦い経験をお話しさせてください。
私のキャリアの原点は、大手鉄鋼メーカーの製造現場です。そこでは「図面は絶対」「仕様書は完璧であるべき」という文化が染み付いていました。その価値観をITの世界に持ち込んだ私は、最初のプロジェクトでとんでもない過ちを犯します。
「ドキュメントさえ完璧なら、すべてはうまくいく」
そう信じ込んだ私は、細部に至るまで仕様を網羅した（つもりの）50ページにも及ぶ要件定義書を書き上げました。週末を返上して作り上げた大作です。「これで完璧だ。エンジニアも迷わず開発できるだろう」と、意気揚々とチームに共有しました。
しかし、その後のミーティングは、私の想像とは全く違う「質問の嵐」に見舞われました。
- 「この機能は、なぜ必要なんですか？ビジネス背景が分かりません」
- 「要件が膨大ですが、結局何が一番重要なんですか？」
- 「この通りに作ると、単純計算で半年はかかりますが…」
完璧だと思っていたドキュメントは、エンジニアにとって「意図の分からない指示書の山」でしかありませんでした。結果、認識のズレが多発し、プロジェクトは序盤から大炎上。私は、この手痛い失敗から、「何を（What）」を伝える前に「なぜ（Why）」を共有すること、そしてドキュメントの完璧さよりも、対話によるコンテキスト（文脈）の共有こそがプロジェクトの命運を分けるのだと、骨身にしみて学んだのです。
根本原因：PMが見る「森」とエンジニアが見る「木」
なぜ、あんなにも丁寧に書いたはずの要件定義が伝わらないのでしょうか？
それは、PMとエンジニアでは、見ている景色が全く違うからです。例えるなら、PMは「森」全体を見ており、エンジニアは一本一本の「木」を見ているのです。
- PMが見る「森」：ビジネス上の目的（Why）を達成するために、どのような価値をユーザーに届けるべきか（What）という全体像を見ています。「どのルートで山を越えれば、目的地にたどり着けるか」を考えているのです。
- エンジニアが見る「木」：PMが示した「What」を実現するために、具体的にどう作るか（How）という詳細を見ています。「そのルートを通るために、どんな橋を、どんな素材で、どんな手順で架けるか」を考えているのです。
あなたが「山を越えたい」という目的（Why）を伝えずに、いきなり「ここに、この素材で橋を架けてくれ」と詳細な指示書（What）だけを渡したらどうなるでしょう？
エンジニアは「なぜここに橋が？」「もっと効率的なルートがあるかもしれないのに…」と疑問に思うでしょう。彼らはあなたの目的を知らないため、より良い「How」を提案することすらできません。
要件定義が伝わらないのは、どちらかが悪いわけではないのです。ただ、見ている視点と思考様式が、これほどまでに違う。この構造的な問題を理解することこそが、解決への第一歩となります。
エンジニアとの壁を壊す5つの処方箋
では、どうすれば「森」と「木」の視点を繋ぎ、円滑なコミュニケーションを実現できるのでしょうか。ここからは、私が数々の修羅場を乗り越える中で見つけ出した、具体的な5つの処方箋をお渡しします。
処方箋1：完璧なドキュメントを目指すな。「対話の叩き台」を作れ
まず、マインドセットを根本から変えましょう。要件定義書は「完成された成果物」ではありません。それは、「関係者全員で認識を合わせるための、対話の叩き台」です。60点の完成度で構いません。むしろ、余白を残しておくことで、エンジニアが「ここはこうした方が良いのでは？」と意見を言う隙が生まれます。
処方箋2：「Why（なぜ作るのか）」から始めよ
仕様を一行書く前に、まずこのプロジェクトの「Why」を、あなたの言葉で情熱を持って語ってください。「この機能で、ユーザーのどんな悩みを解決したいのか」「これが成功すれば、ビジネスにどんなインパクトがあるのか」。このコンテキストの共有こそが、エンジニアを単なる「作業者」から、共に課題解決を目指す「パートナー」へと変える魔法です。
処方箋3：「What（何を作るのか）」は言葉だけでなく「絵」で伝えよ
複雑な業務フローや画面遷移を、文章だけで伝えようとしていませんか？それは、最も伝わらない方法の一つです。
かつて私が担当したプロジェクトで、どうしても仕様が伝わらず困り果てたことがありました。その時、私は専門用語を一切使わず、手書きレベルの簡単な図（パワポの箱と矢印だけ）で「ユーザーの体験の流れ」と「ビジネス上の目的」を1枚に描いて説明しました。
すると、ベテランエンジニアがこう言ったのです。
「なるほど、やりたいことはこれか！それならもっと良い方法がありますよ」
あの瞬間、「指示されたものを作る」関係から、「一緒にゴールを目指す」関係へと変わったのを、今でも鮮明に覚えています。ポンチ絵で十分です。見た目より、意図が伝わることを優先してください。
処方箋4：専門用語を捨て、「共通言語」を探せ
特に非エンジニア出身のPMが陥りがちなのが、エンジニアに寄り添おうとするあまり、付け焼き刃の技術用語を使ってしまうことです。これはかえって混乱を招き、信頼を失う原因にもなりかねません。
無理に背伸びする必要はありません。あなたが使うべきは、ユーザーの言葉、ビジネスの言葉です。それが、チーム全員が等しく理解できる「共通言語」となります。技術的な判断は、信頼するエンジニアに任せれば良いのです。
処方箋5：一度に全てを渡すな。「小さく作って、すぐ見せる」を繰り返せ
50ページの要件定義書を一気に渡すような、ウォーターフォール的な進め方は、序盤の小さな認識のズレが、終盤で巨大な手戻りとなって返ってくるリスクを常に抱えています。
そうではなく、機能を小さく分け、「ここまで作ってみたので、認識が合っているか確認しましょう」というサイクルを高速で回しましょう。これにより、ズレを早期に発見し、手戻りを最小限に抑えることができます。
あなたは、もう一人じゃない
要件定義がエンジニアに伝わらない苦しみは、「技術コンプレックス」を抱える非エンジニア出身PMにとって、特有の深刻なペインです。しかし、今日お話しした通り、その原因はあなたの能力ではなく、構造的なコミュニケーションギャップにあります。
大切なのは、完璧なドキュメントを作ることではありません。
要件定義とは、「関係者全員で『共通のゴール』を理解し、納得するためのコミュニケーション・プロセスである」と捉え直すことです。
Whyを語り、対話を促し、共にゴールを目指す。その姿勢こそが、エンジニアの心を動かし、強固な信頼関係を築き、プロジェクトを成功へと導きます。
私も、元エンジニアとして、そして現役のPMとして、皆さんと同じ道を通り、数え切れない失敗を乗り越えてきました。この記事が、あなたの現場の「調整地獄」を少しでも和らげ、明日への一歩を踏み出すための助けとなれば、これほど嬉しいことはありません。