第11章 現場に持ち込むためのレシピ — 小さく始めて育てるRML
現場に持ち込むためのレシピ — 小さく始めて育てるRML
『The Worlds of Distributed Systems』第11章（実務導入ガイド）
「いい話だったけど、明日から何をすればいいんだっけ？」
10章まで読んで、世界観としてはしっくりきたとしても、
- まず何からやるのがいいのか
- どこまでやると「やりすぎ」なのか
- どのチームと、どう話せばいいのか
で少し迷うと思います
この第11章は、本編というより レシピ集／導入ガイドです
- 「いきなり全部は無理」
- 「でも、ちょっとずつ現場に持ち込みたい」
という前提で、スモールステップの導入パターンをまとめておきます
1. 明日からできる「5つの小さな導入」
まずは、1人でもできるレベルの超小さいステップから
1.1 会話の中で「world」という単語を出してみる
設計レビューやインシデント振り返りで、一度だけこう聞いてみてください
「これ、いま話してるの RML-1 / 2 / 3 のどれだっけ？」
答えが出なくてもOKです
「世界を意識する」というスイッチを入れることが目的です
1.2 バックログの1行に「RML」カラムを足してみる
JIRA やスプレッドシートでも、好きなツールでいいので、
- 試しに1つのエピック／機能一覧にだけ
-
RMLというカラムを追加し - 自分の判断で 1 / 2 / 3 を書いてみる
だけやってみてください
後でチームで見直すときの、いい「ツッコミどころ」になります
1.3 新しく書く例外クラスに world を1個だけ足す
言語は何でもいいですが、たとえば
class RmlError extends Error {
world: "RML1" | "RML2" | "RML3";
constructor(args: { world: "RML1" | "RML2" | "RML3"; message: string }) {
super(args.message);
this.world = args.world;
}
}
くらいの軽さで構いません
最初は実際のハンドリングまでやらなくても、
「この throw はどの world を前提にしているか？」
をコードに書き込むだけでも、認知が変わります
1.4 直近インシデントの1件にだけ「RMLタグ」を付けて振り返る
いきなり全インシデント運用を変えようとすると重いので、
- 直近の1件だけ
- タイムラインに
worldを書き足してみる
というやり方がおすすめです
「この時点までは RML-2、ここで初めて RML-3 に上がったよね」
と話しながら線を引くだけでも、かなり見え方が変わります
1.5 Runbook と Playbook を1枚ずつだけ書いてみる
第9章で出てきたように、
- Runbook = RML-2（技術操作）
- Playbook = RML-3（組織判断）
でした
まずは代表的なシナリオを1つずつ選んで、
- 「決済ゲートウェイが落ちたときの Runbook（技術手順）」
- 「金銭的な誤請求が出たときの Playbook（誰がどう決めるか）」
という2枚だけ作ってみると、チーム内での共通イメージが一気に揃います
2. ロール別「これだけやる」
RML を組織に持ち込むとき、役割ごとにやってくれると嬉しいことをざっくり分けておきます
2.1 アプリケーションエンジニア
- 例外クラスに
world/actionを追加する - 重要な外部呼び出しに Idempotency Key を付ける
- 機能バックログに「この機能のRMLは？」と1回だけ質問する
目標：
「RML という概念が、ソースコードと設計レビューに顔を出すようにする」
2.2 SRE / プラットフォームエンジニア
- ログやメトリクスに
rml.world/rml.actionのタグを足す - RML-3 エラーのメトリクスからアラートを1個だけ作る
- 代表的なインシデント種別に対して Runbook / Playbook を用意する
目標：
「RML が運用ダッシュボードと Incident Flow に流れ込むようにする」
2.3 プロダクトマネージャー / PO
- バックログに RML カラムを入れることを許可（or 推奨）する
- 「この機能は RML-3 に昇格させる？」という議論をロードマップに組み込む
- RML-3 インシデントのコスト（返金・クーポンなど）をざっくり把握する
目標：
「RML をプロダクト戦略とPLの話に接続する」
2.4 法務 / コンプライアンス
- RML-3 に該当する事案の定義を、エンジニア／ビジネスと一緒に決める
- ToS（利用規約）の障害時補償条項と、RML-3 の運用方針をすり合わせる
- インシデントポストモーテムに最低でも1回は参加してみる
目標：
「History World への踏み込み方を、言葉のレベルで揃える」
3. RMLキックオフMTGのサンプルアジェンダ
組織として RML を導入するなら、1〜2時間のキックオフミーティングを1回やっておくと楽です
3.1 アジェンダ例（90分）
-
イントロ（10分）
- 「RMLって何者か」というざっくり紹介
- この会社ではどういう名前で呼ぶか（RMLのままでもOK）
-
事例共有（20分）
- 最近のインシデント or ヒヤリハットを1〜2件共有
- ホワイトボードにタイムラインを書きながら
「ここまでは RML-2、ここから先は RML-3」と線を引いてみる
-
役割ごとの視点（20分）
- エンジニア視点：ロールバック／再実行の話
- ビジネス視点：顧客体験とブランド
- 法務視点：契約・規制・PLへの影響
-
この組織のRMLルールのたたき台（30分）
- 「デフォルトで RML-3 とする事案」を列挙
- 「迷ったときはこうする」原則を1〜2行で決める
- RML-3 インシデントのときの Playbook オーナーを決める
-
次の一歩（10分）
-
まずは
- どのサービス／機能から RML ラベリングを始めるか
- どのインシデント種別から事件簿テンプレを適用するか
-
今日決めたことを簡単にメモして終わり
-
「完璧に決める」のではなく、「とりあえず動き出せる最低限」を決める場として割り切るのがコツです
4. FAQっぽいもの
Q. うちのサービス、全部RML-3な気がするんですが？
金融／医療／公共系などだと、「扱っているドメイン的には全部 RML-3 では？」となりがちです
その場合でも、
- 処理単位としての world
- 責任の取り方としての world
を分けて考えると整理しやすくなります
例：
- 「診療予約の候補表示」→ RML-1（提案だけ）
- 「予約枠の確保」→ RML-2（院内オペで調整可能）
- 「診療記録・請求・カルテ」→ RML-3（法的な履歴）
「ドメインとして RML-3 だけど、その中にも RML-1/2 的な層がある」という見方ができると、設計の自由度が上がります
Q. RMLラベルを誤って付けたら、それ自体がリスクでは？
運用初期は、間違っていても構いません
- ラベル自体は可変である
- インシデントや運用の反省を通じて「昇格」「降格」もありうる
という前提で、
「RML ラベルは、現時点でのベストな仮説」
くらいに扱うのがおすすめです
むしろラベルがない状態の方が、「どの世界の話かよく分からないまま進む」リスクが高いです
Q. うちは小さなスタートアップで、そこまでの体制は…？
むしろ小さい組織だからこそ、
- 「どの世界まで責任を持つか」を早く決めておく
- 「そこから外の世界は、別サービスに任せる」と割り切る
ことが重要だったりします
RML の導入も、最初は本当にミニマムで良いです
- 「決済まわりだけ RML-3 をちゃんと見る」
- 「それ以外は基本 RML-2 までで割り切る」
といった線引きを、小さいうちに決めておくと、後から世界を拡張しやすくなります
5. ここまで読んでくれた人への小さな宿題
最後に、読者への宿題をひとつだけ
「自分の現場にとっての、RML-3 っぽい出来事」を3つ書き出してみる
過去のインシデントでも、「もし起きたら嫌だな」という想像上のものでも構いません
- 何が起きて
- 誰に影響して
- 誰が責任を取り
- どんな歴史として残るのか
を、箇条書きでいいので書いてみてください
その3つが、この本の内容を
**あなたの現場バージョンの「Worlds of Distributed Systems」**に変換する
最初のページになるはずです
これで、この本としての主要なコンテンツはおしまいです
あとはそれぞれの現場で、
- 章を削ったり
- 名前を変えたり
- まるごと別の世界観にリファクタリングしたり
自由に遊んでもらえたら嬉しいです
Discussion