ADR / Pitch / キックオフメモの実装ガイド ─ 「なぜ書くか」から運用設計まで

• 想定読者： ADR・Pitch・キックオフメモを導入したい EM・テックリード・PMO
• 前提知識： 「組織のコンテキスト供給能力を整える実装ガイド」STEP 4 の概要
• 所要時間： 通読 約20分／要点把握 約7分

概要

ADR（Architecture Decision Record）、Pitch document（Shape Up）、プロジェクトキックオフメモ——これらは独立に語られがちだが、組織のコンテキスト供給能力という上位目的から見ると 同じ目的の異なる粒度 だ。

本記事は、姉妹記事「組織のコンテキスト供給能力を整える実装ガイド」STEP 4 を独立記事として深掘りする。3つの文書タイプを Diátaxis フレームワーク的に整理し、「なぜ書くか」「どこに置くか」「いつ廃止するか」「検索可能性をどう保つか」を一貫した実装ガイドとして扱う。

3文書の役割と粒度

文書	粒度	主目的	起源
ADR	点の判断（1ファイル1決定）	過去の意思決定の文脈と理由を残す	Michael Nygard 20111
Pitch document	提案の輪郭（着手前）	やる前の検討の証拠	Basecamp Shape Up 20192
キックオフメモ	実行の合意（着手時）	関係者の役割と成功条件の明確化	Stripe 等の企業実践3

3つは時系列的にも補完関係にある：

Pitch (着手前検討) → キックオフメモ (実行合意) → ADR (途中の判断記録)

ADR の実装

# ADR-NNN: <意思決定のタイトル>
## Status: proposed / accepted / deprecated / superseded by ADR-MMM
## Context: 何を決めなければならない状況か
## Decision: 何を決めたか
## Consequences: 良い影響 / 悪い影響 / トレードオフ / フォローアップ

ADR の運用原則

• 1ファイル1決定。複数を混ぜない
• 連番で不変。過去の ADR を編集せず、新しい ADR で superseded を記録
• コードと同じリポジトリに置く。プルリクエストでレビュー
• “やらない” 決定も書く（「Kafka を採用検討したが採用しない」も貴重）
• ビジネス側の意思決定（BDR：Business Decision Record）にも転用できる

ADR が増えすぎる問題への対処

ADR が数百件に達すると検索性が落ちる。対処：

• タグ付け（領域・状態・関連プロジェクト）
• 半年に1度の棚卸し で deprecated を明示
• 重要度ラベル（critical / important / informational）
• C4 model や arc42 などのアーキテクチャ文書体系と組み合わせる

Pitch document の実装

# Pitch: <提案名>
## Problem: 誰のどんな問題か。具体事例1つ
## Appetite: 何週間（fixed time）かければやる気があるか
## Solution: 解決の輪郭（詳細実装ではなくユーザー体験の流れ）
## Rabbit holes: 詳細に入ると危険な箇所。事前の方針
## No-gos: 範囲外（次の cycle に回す）

Pitch の本質

Basecamp / Ryan Singer² の Pitch document の核心は fixed time, variable scope：「何週間（appetite）かければやるか」を先に決めて、scope はそれに合わせて変動させる。これは多くの組織の暗黙の運用（scope を固定して期間が伸びる）と逆の発想だ。

書くこと自体が「考え抜いた証拠」になる。書けないということは、まだ着手すべきでないというシグナルだ。

Shape Up を採らない組織でも使える

Shape Up の方法論全体（6週 cycle / cool-down / betting table）を採らなくても、Pitch document は単体で使える。「やる前に書く」「Rabbit holes と No-gos を明示する」「fixed appetite を宣言する」は普遍的に有効だ。

キックオフメモの実装

## プロジェクト名 / 開始日 / 想定終了
## Problem statement
## 成功条件（測定可能）
## 失敗条件（撤退ライン）
## 関係者と役割（DRI / Reviewer / Informed）
## マイルストーン
## オープンクエスチョン（決まっていない論点）

「失敗条件」の重要性

特に 「失敗条件」「撤退ライン」を最初に書く ことが、後で「サンクコストだから続ける」状態を防ぐ。これは Defensive Pessimism⁴ のロジックと一致する：悪い結果を事前にシミュレートし、対応行動を準備する。

Stripe の文書化文化との接続

Stripe の元社員 Brie Wolfson³ が証言する Stripe の文書化文化：プロジェクトキックオフメモ、retrospectives 用 Google Group、”state” メール、shipped/unshipped カタログ。Stripe CTO の引用「明確で精密な書面でアイデアを伝えるために追加で時間を投資すれば、書く側より読む側が圧倒的に多いため、不釣合いな成果が得られる」が、書面文化の本質を言い当てている。

Diátaxis フレームワークとの関係

Daniele Procida の Diátaxis⁵ は技術文書を4つに分類する：

• Tutorial：学習者を導く（learning-oriented）
• How-to guide：問題解決のステップ（task-oriented）
• Reference：仕様と事実（information-oriented）
• Explanation：理解を深める（understanding-oriented）

ADR / Pitch / キックオフメモは Diátaxis のどこに位置づくか：

文書	Diátaxis 該当
ADR	Explanation（なぜこの判断か）
Pitch	Explanation（提案の輪郭） + How-to の入口
キックオフメモ	Reference（事実と合意の記録）

これらは 新人向けチュートリアル にはならない（curse of knowledge⁶ のリスク）。新人オンボーディングは別の Tutorial / How-to ドキュメントが必要だ。アーキテクチャ全体像を俯瞰したい場合は arc42⁷ のような体系的テンプレートが補完として有効。

検索可能性こそ命

ADR / Pitch / キックオフメモの最大の価値は 後から検索できること だ。

• 1つのリポジトリ／Wiki に集約。フォルダを decisions/ pitches/ projects/ に分けるだけでよい
• ファイル名に 日付＋スラッグ
• タグ付け（プロジェクト名・領域・ステータス）
• 半年に1度の棚卸し：deprecated を明示する

各ドキュメントに owner と “next review” 日付 を必須化（review されないと自動 stale マーク）。読まれた回数（access log） を可視化し、低アクセスは廃止候補にする。

アンチパターン

パターン	何が起きるか	対処
ADR が抽象的すぎ	後で読み返しても文脈不明	Context に具体名・具体数値を必ず書く
Pitch が長文化	書く動機がなくなる	1〜2ページ厳守
「全部の決定を ADR に」と強要	形骸化	「3ヶ月後に判断材料になりそうか」を基準に
検索しづらい場所に保管	書いても誰も見ない	コードと同居 or Wiki ルートに集約
ADR 件数を KPI 化	Goodhart 暴走で空洞化	量ではなく参照回数を見る
キックオフメモに失敗条件を書かない	サンクコストで撤退できない	失敗条件・撤退ラインを必須項目に
Pitch document を Shape Up 全体採用の前提と勘違い	採用ハードルが高すぎ	Pitch は単体でも使える

まとめ

• ADR / Pitch / キックオフメモは時系列で補完関係：Pitch（着手前）→ キックオフ（合意）→ ADR（途中の判断）
• 1文書1目的、検索可能性が命
• ADR：1ファイル1決定、連番不変、コードと同居、”やらない” も書く
• Pitch：fixed time / variable scope、書けないなら着手すべきでない
• キックオフメモ：成功条件と 失敗条件・撤退ライン をセットで
• Diátaxis の Explanation / Reference に位置づき、新人 Tutorial は別途必要
• 量を KPI にしない（Goodhart 暴走）

関連記事

• 組織のコンテキスト供給能力を整える実装ガイド ─ 直視から、修復へ - 本記事の親記事
• ドキュメンテーション・シアター ─ 大量に書いて全部死んでいる組織 - ドキュメンテーションのライフサイクル
• WOOP の組織応用 ─ 個人技法を組織意思決定に制度化する - キックオフメモと WOOP の組み合わせ
• Goodhart の法則 ─ 文書化を KPI 化した瞬間に空洞化する - ADR 件数 KPI 化の暴走

参考資料

1. Documenting Architecture Decisions - Michael Nygard, Relevance / Cognitect (2011-11-15). 【信頼性: 高】 ↩︎

2. Shape Up: Stop Running in Circles and Ship Work that Matters - Ryan Singer, Basecamp (2019). 【信頼性: 中〜高】 ↩︎ ↩︎²

3. From kickoffs to retros and Slack channels — Stripe’s documentation best practices with Brie Wolfson - First Round Review (2023). 【信頼性: 高】 ↩︎ ↩︎²

4. Defensive Pessimism: Harnessing Anxiety as Motivation - Julie K. Norem, Nancy Cantor, JPSP, vol. 51, no. 6 (1986). DOI: 10.1037/0022-3514.51.6.1208。【信頼性: 高】 ↩︎

5. Diátaxis: A systematic framework for technical documentation authoring - Daniele Procida (継続更新). 4分類フレームワーク（Tutorial / How-to / Reference / Explanation）。【信頼性: 中〜高】 ↩︎

6. The Curse of Knowledge in Economic Settings: An Experimental Analysis - Colin Camerer, George Loewenstein, Martin Weber, JPE, vol. 97, no. 5 (1989). DOI: 10.1086/261651。【信頼性: 高】 ↩︎

7. arc42 Template - Gernot Starke (継続更新). アーキテクチャ文書体系。【信頼性: 中〜高】 ↩︎