これを読むとなにが変わる？
仕様が決まらないとき、「仕様設計を頑張ること」をいったん止めて、目的・成功条件・トレードオフ（判断基準）を先に言語化するほうへ意識を向けると視座を上げられるようになります。
仕様迷子は、能力不足というより「トレードオフを決め切れていないだけ」ことも多く、そこに気づくと手戻りの質が変わります。
この記事の3行まとめ
- 仕様が決まらないのは、仕様の詰めが甘いからではなく「決めるための材料（要件・トレードオフ）」が言語化されていないから起きやすい
- 特に厄介なのは「要件は把握している“つもり”」で、判断基準がないまま仕様設計に至ると手戻りが増える
- 迷子になったら、目的・成功条件・トレードオフを先に固定してから仕様に入るのが近道
こんにちは。テレシーでデータサイエンスエンジニア兼データエンジニア兼PdMをしている ohyan です。
今年から新しいプロダクトの企画・開発を始めており、私もPdMとして関わっています。 ただ、立ち上げ期にいちばん苦しかったのは、「会議で意思決定したはずなのに、実際には意思決定に至っていない」 という状態の繰り返しでした。
次の週になると前提が揺れたり、関係者から別の論点が出てきたりして、手戻りが増える。ドキュメントも議論も積み上がっているのに、なぜか前に進んでいない感覚が続きました。
当時の私は、これを「会議体が悪い」「合意形成が遅い」「仕様の詰めが甘い」と“進め方”の問題として捉えていました。今振り返ると、そう見えてしまうのも無理はないのですが、少なくとも自分のケースでは、問題の根っこはそこではありませんでした。
意思決定が成立しないのは、意思が弱いからではなく、“決めるための材料（ビジネス要件・トレードオフ）が揃っていない” から。
無知の知は「知らない」より「知ってるつもり」に潜む
「材料が足りない」ことに気づくのは、思っていた以上に難しいです。なぜなら、材料不足は表面上「仕様が難しい」「議論が煮詰まっている」「合意形成が遅い」みたいに見えてしまうからです。私もかなり長い間、そこに引っ張られました。
今回の経験でいちばん厄介だったのは、知識不足というより
自分はビジネス要件を把握している“つもり”になっている
という状態でした。
「把握しているつもり」というのは、要件が整理されているわけではなく、頭の中で断片的な情報がそれっぽく繋がっていて、
だいたい分かってる。あとは仕様を決めるだけ
というモードに入ってしまうことです。
でも、要件が“頭の中にあるだけ”だと、意思決定の場でこういう現象が起きます。
- 仕様の選択肢は複数あるのに、選ぶ基準が言語化されていない
- 決めたあとに「それって何のため？」が戻ってきて、前提から揺れる
- どこまでやるか（MVP）が切れず、議論が細部に吸い込まれる
- 結果として「決めたはずが決まっていない」状態が続く
私は長い間、上記のような状況に引っ張られました。結論から言えば、「仕様が決まらない」というより、そもそも 仕様を決められる状態（判断基準が揃った状態）になっていなかったんですね。これに気づけたことは、今回の自分にとって“無知の知”でした。
「わかっているつもり」を壊す：目的・成功条件・トレードオフ
反省として、私は「仕様を詰める」ことに労力を寄せすぎていました。 先にやるべきだったのは、仕様の前提になる判断基準を作ることです。
私が次に同じ状況になったら、仕様の議論に入る前に、最低限この3つを固定します。
- 目的：誰のどんな課題を解くのか（1文）
- 成功条件：何が起きたら成功か（指標・期限・目標値）
- トレードオフ：何を捨てて何を取るか（優先順位のルール）
この3つのどこかで詰まるなら、仕様ではなく要件の未確定さがボトルネックです。
成功条件を全部引き出す
成功条件がないと、仕様の良し悪しを判定できません。 判定できないと、その場の空気で決まったように見えても、後から簡単に覆ります。
成功条件は、少なくとも次の3つを意識して全部出します。
- ユーザー価値：何ができるようになったら価値が出たと言える？
- 事業価値：それは何に効く？（売上、継続、工数削減、意思決定速度…）
- 失敗回避：何が起きたら失敗か／壊してはいけないものは何か
そして最後に、それらに優先順位をつける。ここが肝です。
会議で使うなら、私はこう聞きます。
- 今回のフェーズで“絶対に落とせない成功条件”は何ですか？
- 成功を測る指標は何ですか？（数字で）いつまでに？
- それ以外はどこまで妥協できますか？
- 逆に、何が起きたら失敗ですか？
トレードオフを全部洗い出す
成功条件が揃っても、まだ仕様は決まりません。新規プロダクトは全部は取れないので、何を優先するか(トレードオフ)を決める必要があります。
- スピード vs 品質
- 柔軟性 vs 運用負荷
- 粒度 vs コスト
- 安全 vs 使いやすさ
このあたりの軸について「今回はどれを優先するか」を決めると、仕様の迷いどころで立ち戻れる基準ができます。
さらに私が良くなかったのは、決定が覆ったときに「なぜ覆ったのか」が整理されていなかったことです。なので次からは 覆る条件 を先に書きます。
- 今回のフェーズで一番優先するのは何ですか？
- そのために何を捨てますか？
- 捨てたことによる痛みは誰が引き受けますか？
- この判断が覆るのは、どんな情報が出たときですか？（覆る条件）
決めるための前提を1枚にする（頭の中から出す）
最後に、頭の中の理解を「1枚岩」にして言語化します。 これをやらないと、自分の中で分かった気になっても、他の人にとっては判断基準が存在しない状態が続いてしまいます。
- 目的（1文）：
- 成功条件（KPI/期限）：
- トレードオフ（今回優先する軸）：
- 未確定（今わかっていないこと）：
- 次アクション（誰が/いつまでに）：
未確定（今わかっていないこと）が出てくるのは正常なことです。大事なのは、未確定を「宿題」にして次に繋げることです（ここも自分の反省点です）。
PdMとして自信を持って説明できるようになれ
ここまでやると、議論が「雰囲気」から「基準に沿った意思決定」に変わります。 そしてPdMとしても、説明がしやすくなります。
- 目的に沿っているからこの仕様を選ぶ
- 成功条件（KPI）に効くからこの順番でやる
- トレードオフとして今回はこれを捨てる
- 覆る条件が出たら再検討する
最後に、自分の中で迷子のサインも決めておくと早めに立て直せます。
- 決めたはずが翌週ひっくり返る
- 「何のため？」が毎回戻る
- MVPが切れない
- 優先順位が個々人の好みで決まる
これが出たら、仕様を頑張るのではなく、目的・成功条件・トレードオフに戻る。自分はこれに気づくのが遅かったので、次は早めに切り替えたいと思っています。
おわりに
仕様迷子は、能力不足というより判断基準の未確定さが原因です。 迷子になったら無知の知。「自分は分かっているつもりだったけど、決める材料が言語化されていない」と認めて、判断基準を先に作る。
目的・成功条件・トレードオフを固定し、1枚岩に落としてから仕様設計に入る。自分はこれを痛い目を見て学んだので、同じところでハマっている人の参考になれば嬉しいです。
