仕様書の書き方とエンジニアリングへの引き継ぎ: 後戻り作業ゼロを目指す方法

前回の仕様書は8ページありました。エンジニアリングは月曜日に一度開き、見出しをざっと見て、二度と開きませんでした。木曜日までに、エクスポートにアーカイブ済みのレコードを含めるべきかどうか誰もわからなかったため、2つのストーリーが止まっていました。次の sprint レビューまでに、作業の40%がやり直しになっていました。仕様書の肥大化はあなたのせいにされました。読まなかったエンジニアリングのせいにされました。誰もシステムを改善しませんでした。

これが繰り返されるループです。これがその断ち方です。

前回の仕様書が読まれなかった理由

この状況が過去1年で3つのチームで展開されるのを目の当たりにしました。スタックも担当ドメインも異なりましたが、パターンは同じでした。PMが長い仕様書を作り、エンジニアリングが長い sprint を回し、書かれたものと作られたものの差がやり直し作業で埋められます。

40%というやり直し率はアンケートの数字ではありません。実際に数えたチームが見つけた数字です。前回の sprint のチケットを引き出し、スコープが変わったストーリー、フォローアップチケットが発生したストーリー、「わかっていなかった」に起因する既知のバグでリリースされたストーリーにマークをつけてください。それがあなたのやり直し率です。正直にこの作業をしたほとんどのチームは30〜50%の間に着地します。

仕様書だけがこれを引き起こしたわけではありません。しかし、仕様書は修正するにはもっともコストが低い場所です。コードの書き直しは高くつきます。ドキュメントの書き直しは無料で、1ページのドキュメントは8ページのものより何倍も書き直されます。

これが長文ドキュメントの代替手段です。

1ページの仕様書

7つのセクション。それぞれが存在理由を持っています。実際の役割を果たさないセクションは入れません。

# [機能名]

**問題**
ユーザーにとって何が壊れているか、何が欠けているか。1文。実在するユーザー、実在するペイン。「ユーザーはXができない」ではなく、「営業担当者は1on1の前にパイプラインをマネージャーと共有するためにエクスポートできないので、スクリーンショットを撮ってSlackに貼っている」のように。

**仮説**
[何か]をリリースすれば、[理由]によって[アウトカム]が起きる。1文。これが私たちが賭けていることです。

**成功指標**
勝ちを知らせる1つの数字。3つではなく。具体的に。「リリースから14日以内にパイプラインを閲覧した営業担当者の30%がエクスポートを使用する。」遅行指標の読み取りに時間がかかりすぎる場合は先行指標を追加します。

**スコープ**
含まれるもの。箇条書き、最大7項目。各項目はユーザーができること、または見えるものです。

**アンチスコープ**
含まれないもの。誰かが必ず聞いてくる内容でも。箇条書き。具体的に。「カスタムエクスポートテンプレート: v1には含まない。スケジュール済みエクスポート: v1には含まない。CSV列の並べ替え: v1には含まない。」これが sprint を守るセクションです。

**エッジケース**
今考えておかないと崩れる5つのこと。空の状態、エラー、大規模データセット、権限、同時編集。この機能に実際に該当するものをリストアップします。

**未解決の問い**
まだ答えのない判断事項。担当者名を添えて。「エクスポートにアーカイブ済みの商談を含めるか? @raviが水曜日までにセールスオペレーションに確認。」

以上です。1ページ。これが仕様書の全体です。

最大のポイントはアンチスコープです。多くのPMはこれを省略します。ネガティブに感じるか、「明らかにXはやらない」と思っているからです。しかしエンジニアリングには決して明らかではありません。デザインにも明らかではありません。金曜日に「なぜ自分の要望が入っていないのか」とDMを送ってくるステークホルダーにも明らかではありません。アンチスコープは、sprint の途中で誰かが作業を拡大しようとしたときに指し示すセクションです。これがなければ記憶から議論することになります。これがあれば、2週間前に全員が承認した一行を指し示せます。

アンチスコープなしで機能をリリースし、最初のバージョンがフィルタリングされていないデータを前提にしていたため、2回目は保存済みフィルターに対応するために後付けで修正することになった経験があります。エンジニア2人、3週間。90秒で書けるアンチスコープ4項目で全部防げました。

プレスペックエンジニアレビュー(15分)

仕様書はあなたのラップトップからJiraへ直接行きません。まず15分のエンジニアレビューを通過します。完成したドキュメントではなく下書きを持参します。

セットアップ:

• 参加者: テックリード、シニアエンジニア1人、あなた。以上です。デザイナーはまだいません。PMの同僚もいません。マネージャーもいません。
• タイミング: 仕様書を他の誰かに見せる前。デザインが始まる前。ステークホルダーが意見を言う前。
• 持参するもの: 「DRAFT」と記した1ページの仕様書。問題と仮説のセクションは確定です。それ以外はすべて検討材料です。
• 得られるもの: 見落としたエッジケースのリスト、工数の大まかな感覚、そしてアプローチが間違っている場合の「このアプローチは違う」という早期の指摘。

付箋1枚に書けるアジェンダ:

0〜2分:   問題と仮説(あなたが話す)
2〜8分:   エンジニアリングがスコープとエッジケースの穴を突く
8〜12分:  エンジニアリングが2〜3つの実装の方向性を提案
12〜14分: 未解決の問い、各担当者
14〜15分: 「方向性は合っているか?」 yes/no/maybe

答えが「no」または「maybe」なら、仕様書をさらに書き足すのではなく、問題のフレーミングかアプローチを修正します。仕様書の問題のほとんどは、別の姿をしたフレーミングの問題です。

これが機能する理由: 半完成の仕様書をレビューするエンジニアリングは、守りに入る前に最高の思考を提供してくれます。仕様書が「完成」した後のレビューは、あなたの仕事への批評に変わります。下書きの段階では、共同制作しています。Jiraに12コメントの厳しいフィードバックを書いていたはずの同じエンジニアが、代わりに「既存のエクスポートエンドポイントにフラグを追加するだけではどうか?」と言って、1週間を節約してくれます。

キックオフドキュメント

1ページの仕様書がプレスペックレビューを通過し、デザインが意見を出したら、キックオフドキュメントを書きます。これがチームチャンネルにピン留めされるものです。これは契約書です。

4つのセクション、それぞれ短く:

RACIテーブル: 役割ごとに1名

委員会は責任を持てません。1人の名前が責任を持てます。

Accountableの行に1人の名前を入れられないなら、プロジェクトを開始する準備ができていません。

日付付きのマイルストーン

3〜4つのマイルストーン。実際の日付。「sprint の終わり」ではなく。

• 3月14日: デザイン完成、開発開始
• 3月21日: フィーチャーフラグで保護されたバックエンドエンドポイント、ステージングでの内部テスト
• 3月28日: 10社の顧客とのベータ
• 4月4日: デモデー(非交渉)
• 4月11日: GA

デモデー: 非交渉

日付を決めてください。チームに伝えてください。ステークホルダーに伝えてください。その日に存在するものをデモすると自分に言い聞かせてください。たとえ見栄えが悪くても。

動くデモデーは、デモデーではありません。それは希望です。持っているものをリリースしてください。機能の半分しかできていないなら、半分をデモして残りを説明してください。そうやって信頼が築かれます。粗削りでも2週間ごとにデモするチームは、仕上がったときだけデモするチームより常に速く進みます。

停止基準

誰も書きたくないが、誰もが必要とするセクションです。

「次の場合は構築を停止します: ベータ顧客がアクティベーションから7日以内にエクスポートを使用しない場合、またはテストデータセットのp95でバックエンドのレイテンシが800msを超える場合、またはベータ期間中に2人以上の顧客がデータの正確性の問題を報告する場合。」

3つの条件。具体的。計測可能。事前にコミット済み。

停止基準がなければ、すべての機能が永遠に生き続けます。あれば、チームは判断を下すための後ろ盾を持ちます。この18ヶ月でこのセクションを使って2つの機能の開発を停止しましたが、どちらの場合もエンジニアから感謝されました。うまくいっていないことにさらに3週間費やしたい人はいません。事前に書面で設定した許可が必要なだけです。

Loom > ミーティング(ほとんどの場合)

仕様書についてエンジニアリングに30分かけて説明するハンドオフミーティング? スキップしてください。代わりに4分のLoomを録画してください。

Loomに入れるもの:

1. 画面に1ページの仕様書を表示し、読み上げながら説明する。
2. 2つのデモフロー: ハッピーパスとエッジケース1つ。
3. 最もよく聞かれると予想される3つのこと。
4. 最後にひと言: 「スレッドに質問を入れてください。本日中に回答します。」

これで得られるもの: エンジニアリングは自分の準備が整ったときに1.5倍速で視聴でき、あなたのカレンダーの都合ではありません。質問はスレッドに入るため、同じことを3つのSlack DMで説明し直すのではなく、全員が一度回答を見ることができます。2週間後にプロジェクトに参加する新しいエンジニアは、誰かを捕まえて説明してもらう代わりに同じLoomを視聴します。

Loomが機能しないとき: プロジェクトが真に曖昧で、チームが声を出して議論する必要があるとき。信頼が低く、非同期がPMが隠れているように見えるとき。部屋が必要な本当の戦略的トレードオフがあるとき。それらの場合はミーティングを行ってください。それ以外はLoomです。

「完了」の定義

「ユーザーがログインできる」という受け入れ基準は受け入れ基準ではありません。希望です。

Given / When / Then を使ってください。具体的な例、実際のデータ、実際の状態。

悪い例:

ユーザーがパイプラインをエクスポートできる。

良い例:

Given 私はパイプラインへの表示アクセス権を持つ営業担当者であり、 And 自分が担当し、ステージが「交渉中」の商談のみを表示するフィルターを適用しており、 When エクスポートをクリックしてCSVを選択すると、 Then pipeline-2026-04-28.csv という名前のファイルがダウンロードされ、フィルター適用後に表示された商談のみが含まれ、列は「商談名、ステージ、金額、クローズ日、担当者」となる。

エッジケース(結果なし): フィルターで商談が0件になった場合、「エクスポートする商談がありません」というトーストを表示し、ファイルをダウンロードしない。

エッジケース(大規模データセット): フィルターで10,000件を超える商談が返された場合、エクスポートをキューに入れてファイルの準備ができたらメールで送信する。「エクスポートをキューに登録しました。メールでお送りします。」というトーストを表示する。

追加で2分の作業です。節約できる議論は3日分です。QAエンジニアはこれを読んでテストを書きます。バックエンドエンジニアはこれを読んでエンドポイントの仕様を把握します。カスタマーサクセスのリードはこれを読んでベータ顧客に何を伝えるか把握します。1つの成果物が4つの仕事をします。

エッジケースを省略しないでください。エッジケースはやり直し作業が潜む場所です。

リリース後のレトロテンプレート

20分。5つの問い。GA後1週間以内にチームのSlackチャンネルに投稿します。

**[機能名], リリース後のレトロ**

1. 仕様書で不明確だったことは何か?
   (各自1項目、議論なし、列挙のみ。)

2. スコープで見落としたことは何か? 計画外に出てきたことは?
   (工数、リスク、依存関係、その他すべて。)

3. どんなやり直しが発生し、その理由は何か?
   (具体的に。「フィルターの保持をURLかローカルストレージかを早い段階で決めなかったため、フィルターの保持を2回作り直した。」)

4. どのエッジケースが問題になったか?
   (初日から仕様書にあればよかったと思うもの。)

5. 次の仕様書に何を入れるか?
   (テンプレートまたはプロセスへの具体的な1つの変更。)

, 金曜日までにスレッドで返信してください。まとめて月曜日に次の仕様書への変更を投稿します。

目的は責任の追及ではありません。テンプレートを進化させることです。次の仕様書に1つの改善が加わります。その次にもう1つ。6ヶ月後、チームの仕様書プロセスは出発点より実質的に改善されており、誰も90分のレトロに参加しなくて済みました。

spec-improvements.md という名前のファイルで、レトロごとに1項目を記録しています。1年後で2画面分の長さになっています。自分が持つ中でもっとも価値あるドキュメントです。

よく見られるアンチパターン

繰り返し現れるパターンがいくつかあります。気づいた瞬間に声に出して名前をつけてください。名前をつけると消えます。

• 「デザインが投げ込んで終わり」のハンドオフ。 デザインが完成し、仕様書にFigmaのリンクを投稿して姿を消します。エンジニアリングはモックが対応していないインタラクションで行き詰まり、デザインに尋ねると「判断に任せる」と言われます。3日後、間違った形でリリースされます。修正策: デザインがキックオフに参加します。RACIの行は担当者名付きの「Consulted」です。最初の sprint 中のインタラクションの問いに対応できる状態にあります。

• sprint 中に拡大する仕様書。 火曜日にステークホルダーからDMが届きます。「このリリースにXも追加できますか?」断ることが政治的に難しいのでYesと言います。金曜日にチームは遅れています。修正策: アンチスコープ。それを指し示します。「Xはv2に入れます。記録しました。」以上です。

• アンチスコープの欠如。 エンジニアリングが機能を構築した後、「アーカイブ済みのレコードはどうしますか?」と尋ねます。「良い質問ですね、追加しましょう」と言う。それはアンチスコープがトロイの木馬的な問いとして戻ってきたものです。修正策: アンチスコープは初日から仕様書に入ります。スコープのリストにないものは、デフォルトでスコープ外です。

• デモデーの不意打ち。 デモデーが来ます。PMは月曜日以来ビルドを見ていません。フローの半分が仕様書の通りに動いていません。ステークホルダーは混乱して帰ります。修正策: PMがデモデーの24時間前にエンジニアリングリードと非公開でウォークスルーを行います。まだ修正できる段階でズレを把握します。

まとめ

仕様書は論文ではなく、契約書です。

1ページの仕様書が短いのは、短い仕様書が読まれるからです。プレスペックエンジニアレビューが15分なのは、それ以上長いと誰も参加したくないミーティングになるからです。キックオフドキュメントに役割ごとに1名しか入れないのは、委員会は責任を持てないからです。LoomがウォークスルーMTGの代わりになるのは、非同期の書き物はスケールし、ミーティングのカレンダーはスケールしないからです。Given/When/Thenが存在するのは、「ユーザーがログインできる」という書き方によって千のバグのあるログイン機能がリリースされてきたからです。

アンチスコープと停止基準は、多くのPMが省略してその後後悔する2つのセクションです。省略しないでください。買える中でもっとも安い保険です。

短く、鋭く、全員に承認された。それがすべてです。

関連ガイド

• プロダクトマネージャーの求人票
• だらだらしないスプリントプランニングの進め方
• クロスファンクショナルチームへのRoadmapコミュニケーション
• デザインとの連携: PMとデザイナーのハンドオフ