「RFCは全員の賛成を得る仕組みではない」と佐藤CTOは明言した。「構造的に意見を集め、反対意見を尊重した上で、責任者が判断を下す仕組みだ。『Disagree and Commit』が大事だ。」
1. RFCテンプレート
# RFC-XXXX: [提案タイトル]
## メタ情報
- 起案者: [名前]
- ステータス: Draft / Review / Accepted / Rejected / Withdrawn
- レビュー期限: [日付]
- DACI: D=[名前] A=[名前] C=[チーム] I=[チーム]
## 背景と動機
なぜこの変更が必要なのか。現状の問題点。
## 提案
何をどのように変更するか。技術的な詳細。
## 検討した代替案
選択しなかった案とその理由。
## トレードオフと影響
- パフォーマンスへの影響
- セキュリティへの影響
- 運用への影響
- コストへの影響
## 段階的導入計画
Phase 1, 2, 3 のマイルストーン。
## 未解決の問題
まだ決まっていないこと。今後検討が必要な事項。2. レビュープロセス
Draft（1-2日）→ Review（5営業日）→ 議論/修正 → 決定
↓ ↓ ↓
起案者が作成 関係者がコメント Approverが判断
Accepted / Rejectedレビューガイドライン
| 良いフィードバック | 悪いフィードバック |
|---|---|
| 「このアプローチではX障害時にY問題が発生しないか？」 | 「これは駄目だと思う」 |
| 「代替案Bの方がZ点で優れているのでは？根拠は…」 | 「前の方が良かった」 |
| 「Phase 1でのリスクを軽減するためにPoCを提案する」 | 「うまくいかない気がする」 |
3. 合意形成のファシリテーション
Disagree and Commit
合意形成のレベル:
1. 全員賛成 → 稀。待ち続けてはいけない
2. 大多数の合意 + 少数の反対意見を記録 → これを目指す
3. Approverの判断 + Disagree and Commit → 健全
4. 平行線 → タイムボックスを切って決定異議への対応
| 異議の種類 | 対応 |
|---|---|
| 技術的な懸念 | データで検証（PoC/ベンチマーク） |
| スコープの懸念 | Phase分割で段階的に対応 |
| リソースの懸念 | 優先順位とトレードオフを明示 |
| 原則的な反対 | ADRに反対意見を記録し、Approverが判断 |
4. RFC文化の醸成
■ RFC文化のベストプラクティス
- 小さなRFCから始める（大きな提案は分割）
- レビューの敷居を下げる（カジュアルにコメントできる雰囲気）
- 良いRFCを社内で共有し、テンプレートとして活用
- RFC of the Month を表彰して文化を育てる
- 新メンバーのオンボーディングにRFCリストを活用まとめ
| トピック | 要点 |
|---|---|
| RFCテンプレート | 背景・提案・代替案・トレードオフ・計画を構造化 |
| レビュープロセス | 5営業日、建設的なフィードバック |
| 合意形成 | Disagree and Commitで決断力を保つ |
| 文化醸成 | 小さなRFCから始め、良い事例を共有 |
チェックリスト
- RFCテンプレートを使って提案を構造化できる
- 建設的なフィードバックの書き方を理解した
- Disagree and Commitの原則を説明できる
- RFC文化を組織に導入する計画を立てられる
次のステップへ
RFCプロセスを学んだ。次は テクニカルメンタリングとナレッジ共有 を学ぼう。
推定読了時間: 30分