はじめに
自社プロダクトの運用に関わっていると、お客様の問い合わせから派生して手を動かすことがよくあります。本記事では具体例として、Webサービス運用でありがちな仮想ケースを使って説明していきます。たとえば「特定のユーザーだけ画面の表示が古いまま残っている」「バッチが想定外の状態で止まっている」「設定変更を個別に反映してほしいと依頼された」といったものです。
こういう依頼に手をつけるとき、毎回ゼロから判断するのは思ったより重い作業です。「とりあえず直す」はそのお客様には早く返せますが、同じ困りごとが別のお客様にも起きます。「根本から直す」は提供まで工数がかかりますが、その後は同じ事象でお客様が困らずに済みます。
同じ判断を毎回ゼロからやっていると時間がかかります。考える順番を決めておけば、その分だけお客様に届く改善のサイクルが早く回るようになります。それがこの記事で紹介する ROAD マインドセット(Root-fix → Operationalize → Automate → Distill の頭文字)です。「実装前に立ち止まる原則」というよりは、お客様への改善を素早く積み上げていくための思考の道筋として使っています。
想定読者は、自社プロダクトの運用と開発を兼ねているエンジニアです。SRE / プラットフォーム / バックエンドのいずれでも、コードを書く側の人を念頭に置いています。
ROAD マインドセットの4ステップ
問い合わせの一次対応が終わって、コードや手順に手をつけ始める手前で、上から順に4つの問いを自分へ投げます。
- Root-fix(そもそも根本から直して、この問い合わせを起きなくできないか)
- Operationalize(直接データを書き換えず、運用に乗った仕組みで済ませられないか)
- Automate(残った手順を、人手を介さず動く形にできないか)
- Distill(できあがった仕組みから、余分を削いでもっとシンプルにできないか)
順番が大事です。上から順に効果が大きく、上の問いをクリアできれば下の問いを考える対象自体が減ります。生産工学の ECRS と同じ構造になっています。
| 順 | ROAD | ECRS | 問い |
|---|---|---|---|
| 1 | Root-fix | Eliminate | そもそも問い合わせ自体を消せないか |
| 2 | Operationalize | Combine | 直接編集せずに既存の運用経路に乗せられないか |
| 3 | Automate | Rearrange | 手順を人間から外せないか |
| 4 | Distill | Simplify | できあがった仕組みから余分を削れないか |
ECRS が製造現場の改善原則であるように、ROAD は問い合わせ対応の改善に特化させた版です。Google SRE 本の Toil 削減や ITIL の Problem Management の発想にも近いものがあります。新しい考え方というよりは、それらを自分の現場用に4ステップで整理し直したものです。
以下、冒頭で挙げた「特定のユーザーだけ画面の表示が古いまま残っている」という仮想ケースを通して、各ステップを順に見ていきます。
R — Root-fix(そもそも問い合わせを消せないか)
最初の問いは「この問い合わせ自体を起きなくできないか」です。
問い合わせには大きく分けて2種類あります。
- 個別事象の問い合わせ — そのユーザーだけ起きている、データの不整合や設定誤り
- 構造的な問い合わせ — 仕様や UI の作りが原因で、別のユーザーからも繰り返し来る
後者の場合、目の前の1件だけ手当しても、また来ます。次に同じ問い合わせが届いたとき、自分かチームの誰かが同じ調査を繰り返します。同じ構造原因から繰り返し発生していると見えてきたら、そこは Root-fix の機会です。
具体的には、以下のような選択肢を並べてから着手の判断をします。
- バリデーションを追加して、不整合データが入らないようにする
- UI の文言を変えて、誤解を招く操作ができないようにする
- バッチの異常終了を検知し、人間が問い合わせを受ける前に直す
Root-fix は提供までの工数が大きい代わりに、その後はお客様が同じ事象で困らずに済みます。繰り返し発生している構造原因を1度直しておけば、これからサービスを使う方は最初から正しい体験になります。長く使ってもらうサービスほど、Root-fix の見返りはお客様側にも積み上がります。
「画面の表示が古いまま残っている」仮想ケースなら
同じ問い合わせが過去にも来ていれば、表示更新のロジックやキャッシュの仕組みなど構造原因を疑います。同種の事象が繰り返し見えてきたら、表示ロジック自体を直します。直しておけば、これから同じ画面を開くお客様にも正しい状態で表示されます。今回が初めての事象なら、まず1件としてしっかり対応した上で、同種事象が継続的に観測されたタイミングで構造改善を判断します。
逆に、本当に「特定の1人のユーザーだけに起きた偶然の事象」なら、根本解決の余地はありません。次のステップに進みます。
O — Operationalize(運用に乗った仕組みで済ませられないか)
2番目の問いは「DB を直接 UPDATE したり、ファイルを直接書き換えたりせずに、運用経路に乗せて対応できないか」です。
問い合わせ対応で一番怖いのは、本番 DB に対する手作業の操作です。本番 DB の手作業操作は不可逆な影響を残しやすく、運用上のリスクが大きい性質のものです。だからこそ、運用に乗った仕組みを介して対応することが大事になります。
Operationalize では、以下のような選択肢を考えます。
- 管理画面に「再計算」「ステータスの修正」のような操作機能を作る
- ユーザー自身が画面から再操作できる導線を用意する
- 既存のバッチを再実行するだけで状態が直るようにする
- 一度きりの修正でも、レビュー可能なマイグレーションスクリプトとしてリポジトリに残す
「管理画面に機能を作る」は提供まで工数がかかりますが、一度作ればお客様への対応リードタイムが大きく短縮されます。お客様自身が画面から再操作できる導線にできれば、待ち時間なしに解決できる場面も増えます。
さらに、管理画面の操作はログに残り、誰が・いつ・何をしたかを追跡できます。お客様のデータを扱う以上、追跡できる経路で対応できることは信頼の土台です。
「画面の表示が古いまま残っている」仮想ケースなら
「再計算」ボタンを管理画面に追加するのが定石です。一度作ってしまえば、対応者の手順が短くなり、お客様への返信までの時間が短縮されます。さらにお客様自身が押せる位置に置ければ、画面を開いたその場で解決でき、問い合わせを送る手間そのものが減ります。
A — Automate(人手を介さず動く形にできないか)
3番目の問いは「この手順を、次回からは人間が触らずに済むようにできないか」です。
Operationalize で運用経路に乗ったあとの操作も、いくつかのコマンドや管理画面操作で構成されているなら、まだスクリプト化や自動化の余地があります。スクリプトにできれば、次に同じ問い合わせが来たとき「まずこのスクリプトを叩いてください」で済みます。
自動化の候補は意外と多いです。
- 問い合わせ受付時の状況確認(該当ユーザーの最近のログを抽出する等)
- 影響範囲の調査(関連レコードを SQL で集計する等)
- 修正後の動作確認(ユーザー画面に正しい状態が表示されているかを確認する等)
完全自動化までいかなくても「スクリプト化して 1 コマンドで済む」だけで十分価値があります。手順書を Markdown で残すよりも、実行可能なスクリプトとして残すほうが腐りにくいです。
「画面の表示が古いまま残っている」仮想ケースなら
「再計算」ボタンを押す前の調査 SQL を、1コマンドで叩ける形にしておきます。さらに上位の自動化として、不整合検知のバッチを定期実行し、検知時に自動で再計算をかける形まで持っていければ、お客様の画面に常に正しい状態が保たれやすくなります。お客様に手間や心配をかけずに済む状態が一番の理想です。
ただし、Automate は Root-fix と Operationalize のあとに来る問いです。問い合わせ自体が来なくなれば、自動化する対象もそもそも存在しません。順番を間違えると「使われない自動化」を作って終わりになります。
D — Distill(余分を削いでもっとシンプルにできないか)
最後の問いは「上の3つを終えたあとで、できあがった仕組みからもう一段、余分を削れないか」です。
Distill は「蒸留する」「本質だけ抽出する」という意味で、ここでは Simplify とほぼ同じ役割で使っています。選択肢や設定項目を減らして「使う側が考える余地」を削ぎ落とす方向のニュアンスを込めています。
たとえば管理画面の操作機能を作ったとして、「3つのチェックボックスと2つのプルダウンを正しく組み合わせなければ正しい状態にならない」UI ができたら、それは新しい問い合わせの種です。
- チェックボックスを1つ減らす
- デフォルト値で正しい状態に倒す
- プルダウンを廃止して常にその挙動にする
選択肢はいくつかありますが、いずれも「使う側が考えなくていい状態」に近づけることが目的です。
「画面の表示が古いまま残っている」仮想ケースなら
「再計算」ボタンを残しつつ、本当はこのボタンが必要になる前に自動再計算が走るようにし、最終的にはボタン自体を撤去します。お客様の目に触れる画面が一段シンプルになり、操作で迷う場面が減ります。
Distill は仕上げの工程です。先の3ステップを終わらせた前提で、できあがったものをもう一段わかりやすくできないかを最後に問います。
なぜ R から順に効果が大きいのか
ROAD は ECRS と同じく、上のステップほど後工程を不要にします。
- Root-fix できれば、Operationalize を考える対象すらなくなる
- Operationalize できれば、Automate する手順は管理画面の操作だけで済む
- Automate できれば、Distill する対象は自動化されたフロー1本だけになる
逆に、いきなり Distill から始めると、複雑な手順を「わかりやすくしただけ」のままで残してしまいます。Automate から始めると、本来は不要だった手順を自動化して、メンテナンス対象を増やしてしまいます。
順番を守ると、最終的に手元に残るものが少なく、シンプルになります。お客様に届ける改善のスピードが上がるのはこのためです。毎回「どこから手をつけるか」で悩む時間が消えれば、その分を実装に回せます。
いまの使い方
正直に書くと、いまは頭の中で4ステップを順に問うているだけです。問い合わせを受けて手をつけ始める手前で「これは Root-fix できないか」「Operationalize に倒せないか」と順に確認するのを、習慣として続けています。チェックリストとして紙やドキュメントに落とした状態ではありません。
それでも、毎回ゼロから考えていた頃と比べて、判断にかかる時間は明らかに減りました。順序が決まっているという、それだけで効きます。Root-fix から順に問うので、上のステップで答えが出ればそこで止まります。下のステップに無駄に時間を使わなくて済むのも大きいです。
自分もまだ頭の中で運用しているだけなので、チェックリスト化や Claude Code の CLAUDE.md への組み込みを試している方がいたら、その運用例をぜひ教えてもらえると嬉しいです。
適用しないケース
ROAD は「即時の障害復旧やセキュリティ対応以外の、計画的に改善できる対応」を主な対象にしています。以下のケースには適用していません。
- インシデント対応(障害) — まず復旧優先。ROAD は鎮火後のふりかえりで使う
- 新規機能開発 — そもそも問い合わせ起点ではないので別の判断軸
- セキュリティインシデント — 専用のフローを優先
緊急度の高い場面では、立ち止まって4ステップを問うこと自体が判断の遅れになります。
おわりに
問い合わせ対応はどうしても受け身の仕事になりがちですが、毎回「この4つの問いを順に考える」を挟むだけで、少しずつ先回りの仕事に倒れていきます。お客様から見れば、同じ困りごとに二度当たらない、対応が早く返ってくる、操作で迷わない。問い合わせ対応はそういう積み上げに変わっていきます。
ROAD は自分の現場用に整理した道筋です。気に入ったら、チームに合う名前で呼び替えて使ってもらえれば嬉しいです。
「Root-fix できないか」と毎回自問するようになっただけでも、自分の場合は似た問い合わせの再発が減ったと感じています。
目の前の1件だけでなく、これから使ってくださる方の体験まで含めて、サービスの質を一段ずつ上げていく。ROAD を意識するようになって、問い合わせ対応の1件1件をそういう温度で扱えるようになったのが、自分にとっての一番大きな変化でした。
Discussion