SDDでPMとエンジニアの対立が減る仕組み

SDD(仕様駆動開発)は人間関係を改善する手法ではないが、結果として衝突は減る

開発現場でよく起きる摩擦があります。
PM（プロダクトマネージャー）は「仕様通りに作ってほしい」と言い、エンジニアは「その仕様では作れない」と言います。

この対立は、能力や性格の問題ではありません。
仕様の扱い方の問題です。

SDD(仕様駆動開発)を導入すると、この衝突が目に見えて減ります。
それはチームワークが良くなるからではなく、争点が変わるからです。

なぜPMとエンジニアは衝突するのか

典型的な会話を見てみます。

• PM「ユーザー登録で確認メールを送りたい」
• エンジニア「非同期処理が必要です」
• PM「それは分からないが、とにかく必要」
• エンジニア「期限内に無理です」

この時点で双方は違う話をしています。

PM	求めているもの
結果	ユーザーが登録できること

エンジニア	考えているもの
実装	どう作るか

つまり、片方は振る舞い、片方は実装を議論しています。
議論が噛み合わないのは当然です。

従来開発における仕様の位置

多くのプロジェクトでは、仕様は要件定義書に存在します。
しかし実際には次の状態です。

• PM：機能の説明
• エンジニア：設計の解釈
• QA：テスト観点

同じ文書を見ても、役割ごとに意味が変わります。
そのため、合意したはずなのに実装後に問題が発覚します。

よくある摩擦

• 「思っていた動きと違う」
• 「仕様書に書いてある」
• 「そこまでは想定していない」

この議論は、どちらも間違っていません。
仕様が曖昧なため、双方が正しいのです。

SDDにおける仕様の定義

SDDでは仕様を「振る舞い」として定義します。
文章ではなく、実行結果で定義します。

例：

POST /users

201: 登録成功
409: メール重複
400: 形式不正

この段階で決まるのは、作り方ではありません。
何が起きるかです。

PMは期待する結果を確認でき、
エンジニアは必要な実装量を把握できます。

衝突が減るメカニズム

対立の多くは「あとからの発見」で起きます。

• 実装後に仕様が変わる
• テストで未定義挙動が見つかる
• リリース直前に要件追加

SDDではこれが前倒しされます。
仕様レビューの時点で議論が発生します。

このときの議論は次の形になります。

• PM「このケースはどう扱う？」
• エンジニア「この仕様だとこの処理が必要」
• QA「この状態もテスト対象になる」

争いではなく設計になります。

責任の所在が明確になる

従来の開発では、問題発生時に責任が曖昧になります。

• 実装の問題か
• 設計の問題か
• 要件の問題か

SDDでは基準が単純です。

仕様に合っているかどうか

状態	判断
仕様違反	実装修正
仕様不足	仕様修正

人ではなく成果物が基準になります。
ここが感情的対立を減らす最大の要因です。

見積もりが現実的になる

PMとエンジニアの摩擦の大きな原因が見積もりです。

• PM：機能単位で見積もる
• エンジニア：実装量で見積もる

SDDでは仕様が細分化されるため、両者の認識が一致します。

例：
「ユーザー登録」ではなく、

• メール検証
• 重複チェック
• 失敗時メッセージ
• 再送処理

具体的な作業単位になります。
その結果、見積もり精度が上がります。

注意点：仕様をPM任せにすると失敗する

よくある誤りがあります。
「仕様はPMが書くもの」という考えです。

SDDではこれは成立しません。
仕様は共同作業です。

• PM：期待する結果を定義
• エンジニア：実現可能性を確認
• QA：検証可能性を確認

誰か一人が書くと、必ず抜けが出ます。

導入初期に起きること

最初は議論が増えます。
仕様レビューで細部まで決める必要があるためです。

ただしこれは摩擦ではありません。
衝突の前倒しです。

後工程の手戻りが減るため、結果的に負担は減ります。

まとめ：対立は性格の問題ではない

PMとエンジニアの衝突は、立場の違いではなく、
判断基準の不一致が原因です。

• PM：価値基準
• エンジニア：実装基準

SDD(仕様駆動開発)はこの間に「仕様」という共通基準を置きます。
人が相手ではなく、仕様が相手になります。

その結果、議論は対立から検討に変わります。
SDDは人間関係を改善する手法ではありませんが、
開発における争点を整理する手法です。

争点が整理されると、対立は自然に減っていきます。