implementation-plan

実装計画

計画の目的は、あらゆることを考慮したと証明することではありません。変更に費用がかからないうちに、変更可能ではあるものの変更コストが高い決定事項をユーザーに提示することです。計画は作業順ではなく、後から調整される可能性の高さに沿って並べます。

手順

1. 3行の要約から始めます。何を構築するのか、どのアプローチを選んだのか、そして最もリスクの高い前提を1つ示します。
2. セクション1 — おそらく調整したくなる決定事項。 データモデルの変更、新しい型インターフェース、API の形状、ユーザー向けの要素などが対象です。それぞれについて、採用した選択肢、検討した代替案、後から変更する場合のコストを示します。
3. セクション2 — 判明している不確定要素と、それを計画に織り込む方法。 曖昧さが残る箇所では、採用するデフォルトと、方針転換のきっかけとなる兆候を明記します。不確定要素を認める計画は実際の状況に直面しても持ちこたえますが、そうでない計画は気づかれないまま破綻します。
4. セクション3 — 機械的な作業。 リファクタリング、接続、移行、テストが対象です。ユーザーはこの部分を信頼しており、確認に注意を割くのは無駄なので、簡潔にまとめます。
5. 最後にレビュー依頼を記載します。着手前に「はい／いいえ」での回答、または選択を求める具体的な項目を2〜4件挙げます。
6. 計画が1画面分を超える場合、またはユーザーが視覚的な成果物を好む場合は、単一で自己完結した HTML ページとして提示します。セクションは折りたたみ可能にし、調整可能な決定事項は先頭に固定します。

ガードレール

• 計画の途中で本当に優れたアプローチが見つかった場合は、方針転換を独立した決定事項として提示します。黙って計画を立て直してはいけません。
• 数分で確認できる分量に収めます。読むのに長すぎる計画は流し読みされ、流し読みされる計画では誤った決定が見過ごされます。
• 計画には実装中の柔軟な対応の余地を残します。詳細を詰め込みすぎた計画は、現実が想定と食い違う場面でこそ破綻します。