pitch-packager

ピッチ資料パッケージャー

レビュアーは、作成者が最初に抱えていた未知の点に加え、専門家が検証するであろう失敗要因を作成者が考慮しているかどうかも知らない状態でレビューを始めます。優れたピッチ資料なら、1回読むだけでその両方を解消できます。

手順

1. 成果物を集めます。仕様書または計画書、プロトタイプまたはデモ、実装メモ、差分です。ユーザー向けの動作に変更があった場合は、デモの録画またはスクリーンショットも依頼し、まずそれを提示します。
2. 懐疑的な読者向けに、読む順番に沿って資料を構成します。
   • デモ — まず、実際に動作している様子を示します。GIFやスクリーンショットのほうが文章より効果的です。
   • 課題と採用した方針 — 最大2段落で、何を解決するのか、ほかの選択肢ではなくこのアプローチを選んだ理由を説明します。
   • 専門家が尋ねること — この分野のレビュアーが提起する、難しい質問を3〜5個挙げます（エッジケース、規模、障害モード、移行など）。「対応していない。現時点で問題ない理由はこれです」も含め、それぞれに正直に答えます。
   • 計画からの逸脱 — レビューで予想外の点が見つかると信頼を損なうため、実装メモからそのまま抜き出します。
   • 今回の変更に含まれないもの — スコープの境界を示し、レビューが際限なく広がらないようにします。
3. 1ページに収めます。仕様書、メモ、差分は本文に埋め込まず、リンクします。
4. 提示する場に合わせて形式を選びます。Slackに貼り付けられる文書、PRの説明、または単独のHTMLページです。不明な場合は、どの形式がよいか尋ねます。

注意事項

• 決して誇張しないでください。既知の弱点を隠すピッチは、1回の承認と引き換えに、信頼を永久に失わせます。
• 「専門家が尋ねること」のセクションが資料の要です。簡単に書けるなら、質問が十分に難しくありません。
• 作業が実際にはまだ準備できていないなら、正直なピッチは進捗報告です。そう伝えることも、このスキルの一部です。