ストーリー
田
田中VPoE
技術標準の「中身」は設計した。次は「どうやって標準を決めるか」というプロセス自体を設計する
あなた
上から「これが標準だ」と決めるのではなく、プロセスを通じて決めるということですか？
あ
田
田中VPoE
その通りだ。トップダウンで押し付けた標準は必ず反発を受ける。RFC（Request for Comments）プロセスを導入し、全エンジニアが標準の策定に参加できる仕組みを作る
あなた
RFCってインターネットの標準化プロセスで使われている手法ですよね
あ
田
田中VPoE
そうだ。IETF のRFCプロセスをエンジニアリング組織に応用する。「提案→議論→合意→採択」というフローを公式化することで、技術的意思決定の透明性と民主性を確保する
RFCプロセスとは
基本概念
| 項目 | 内容 |
|---|---|
| 正式名称 | Request for Comments（コメント要求書） |
| 目的 | 技術的な提案に対してオープンな議論と合意形成を行う |
| 対象 | 組織横断で影響がある技術的意思決定 |
| 参加者 | 全エンジニア（提案・コメントの権利を持つ） |
RFCが必要な場面
| 場面 | 例 | RFCの必要性 |
|---|---|---|
| 新技術の導入 | 新しい言語・フレームワークの採用 | 必要 |
| 標準の変更 | テクノロジーレーダーの更新 | 必要 |
| 横断的な設計変更 | APIバージョニング方式の変更 | 必要 |
| 大規模移行 | データベースの移行計画 | 必要 |
| チーム内の改善 | チーム内のテストフレームワーク変更 | 不要 |
| バグ修正 | セキュリティパッチの適用 | 不要 |
RFCのライフサイクル
RFCのライフサイクル:
1. Draft（下書き）
└── 提案者がRFCを作成
2. Proposed（提案）
└── レビュー対象として公開
└── 最低レビュー期間: 1週間
3. Discussion（議論）
├── 全エンジニアがコメント可能
├── 提案者はフィードバックを反映
└── 必要に応じてミーティング開催
4. Final Comment Period（最終コメント期間）
└── 3営業日の最終確認期間
5. Accepted / Rejected / Withdrawn
├── Accepted: 承認。実装に進む
├── Rejected: 却下。理由を記録
└── Withdrawn: 提案者が取り下げ
6. Implemented（実装済み）
└── 実装完了。ADRとして記録各フェーズの詳細
| フェーズ | 期間 | 責任者 | アクション |
|---|---|---|---|
| Draft | 制限なし | 提案者 | テンプレートに従ってRFCを作成 |
| Proposed | 1日 | 提案者 | PRを作成し、レビュアーを指名 |
| Discussion | 1-2週間 | 全員 | コメント、質問、代替案の提示 |
| Final Comment | 3営業日 | 承認者 | 最終確認、未解決課題の整理 |
| Decision | 1日 | 承認者 | Accept/Reject/Request Changes |
RFCテンプレート
推奨テンプレート
# RFC-NNNN: [タイトル]
## メタ情報
| 項目 | 内容 |
|------|------|
| RFC番号 | RFC-NNNN |
| タイトル | [提案のタイトル] |
| 提案者 | [名前] |
| ステータス | Draft / Proposed / Accepted / Rejected |
| 作成日 | YYYY-MM-DD |
| 最終更新 | YYYY-MM-DD |
| 関連RFC | RFC-XXXX（あれば） |
## 概要
[1-2段落で提案の要約を記載]
## 動機（Motivation）
[なぜこの提案が必要か。現状の問題点を記載]
## 詳細設計（Detailed Design）
[提案の技術的な詳細を記載]
## 代替案（Alternatives Considered）
[検討したが採用しなかった代替案とその理由]
## 影響範囲（Impact）
[この提案が影響するチーム、サービス、プロセス]
## 移行計画（Migration Plan）
[既存システムからの移行方法]
## リスクと懸念（Risks and Concerns）
[想定されるリスクとその緩和策]
## 未解決課題（Open Questions）
[議論中に解決すべき課題]RFCの運用ルール
提案のルール
| ルール | 説明 |
|---|---|
| 誰でも提案可能 | ジュニアからシニアまで、全エンジニアが提案できる |
| テンプレート準拠 | テンプレートに従って記述する。代替案の検討は必須 |
| スポンサー制度 | 大きな提案にはシニアエンジニアのスポンサーが必要 |
| PR形式 | GitHubのPRとして管理し、コメントはレビューコメントで行う |
レビューのルール
| ルール | 説明 |
|---|---|
| 建設的なコメント | 批判ではなく改善提案を行う |
| 期限内のレビュー | レビュー依頼から5営業日以内に初回コメント |
| 技術的根拠 | 「好き嫌い」ではなく技術的な根拠で議論する |
| 合意形成 | 全員一致は不要。「反対意見を記録した上で承認」も可 |
承認の基準
| 基準 | 内容 |
|---|---|
| 技術的妥当性 | 提案の技術的な根拠が十分か |
| 組織への影響 | 影響範囲が適切に評価されているか |
| 実現可能性 | 現実的なリソースとスケジュールで実現可能か |
| 代替案の検討 | 十分な代替案が検討されているか |
| コンセンサス | 重大な反対意見が解消されているか |
RFCの管理
ディレクトリ構造
rfcs/
├── README.md # RFCプロセスの説明
├── template.md # RFCテンプレート
├── accepted/
│ ├── RFC-0001-typescript-primary.md
│ ├── RFC-0002-structured-logging.md
│ └── RFC-0003-api-versioning.md
├── rejected/
│ └── RFC-0004-graphql-adoption.md
├── withdrawn/
│ └── RFC-0005-monorepo-migration.md
└── draft/
└── RFC-0006-grpc-service-mesh.mdRFCの番号管理
| 項目 | ルール |
|---|---|
| 採番 | 連番（RFC-0001, RFC-0002, …） |
| 欠番 | Withdrawn/Rejectedも番号は保持 |
| 参照 | ADRからRFC番号で参照可能 |
「RFCプロセスは民主主義の仕組みだ。全員に発言権がある。だが多数決ではない。技術的な根拠に基づいた合意形成を目指す」 — 田中VPoE
まとめ
| ポイント | 内容 |
|---|---|
| RFCの目的 | 技術的意思決定の透明性と民主性の確保 |
| ライフサイクル | Draft → Proposed → Discussion → Final Comment → Decision |
| テンプレート | 概要、動機、詳細設計、代替案、影響範囲、移行計画 |
| 運用ルール | 誰でも提案可能、建設的なコメント、技術的根拠で議論 |
チェックリスト
- RFCプロセスのライフサイクルを理解した
- RFCテンプレートの構成要素を理解した
- 提案・レビュー・承認のルールを理解した
- RFCが必要な場面と不要な場面を判断できる
次のステップへ
次は「ADR（アーキテクチャ決定記録）の実践」を学びます。RFCで合意した決定を永続的に記録するADRの運用方法を身につけましょう。
推定読了時間: 30分