仕組みの運用i-Willink
ミスを反省で終わらせず1行のルールにする
長い反省文は、次に同じ作業をするとき誰にも読まれません。私たちはミスの記録を、経緯を厚く残す保管庫と、毎回読む1行のルール集に分けています。責めずに仕組みを問う振り返り方と、ルールを太らせない決めごとをまとめます。
ミスの記録は2つに分けます。何が起きたかの経緯は保管庫に厚く残し、毎回読むルール集には「次にどう動くか」を1行だけ足します。
ミスの反省文は、書いた瞬間から読まれなくなります。次に同じ作業をするとき、長い振り返りを読み返す人はいません。AIも同じです。
私たちは、実務の多くをAI（Claude Code）に任せています。人を増やして教育や引き継ぎで補うことができないので、失敗の学びが文書のどこかに埋もれた瞬間、同じ穴にまた落ちます。この記事では、失敗を「次に必ず読まれる1行」に変える運用を、実際の行の例とあわせて書きます。
この記事の要点
- 1振り返りの問いは「誰がやったか」でなく「なぜその操作が通ってしまったか」。直せる場所にたどり着く
- 2経緯は保管庫に厚く、毎回読むルールは1行だけ。1行には、してはいけないこと・代わりにすること・踏んだ痛みを入れる
- 3ルール集は太らせない。1本足すなら1本退役させ、機械で止められるものは機械に任せる
反省文はなぜ効かないのか
長い振り返りは次の作業のときに読み返されず、毎回読むファイルに入れると、そのファイルが太って肝心のルールが埋もれます。
ミスが起きると、何が起きて、なぜ起きて、次はこうする、という長い振り返りを書きたくなります。けれど分量が多いので、次に同じ作業をするときには誰も通して読みません。学びは書いた本人の満足で終わり、行動は変わりません。
もう1つの問題は、毎回読むファイルが太ることです。私たちには、作業の前に必ず読み込むルール集があります。AIにとってこれは毎回の前提として読む文書なので、そこに経緯まで書くと、判断に要らない情報が毎回まざり、肝心のルールが探しにくくなります。読む前提の文書を長くすることは、読まれない文書を作ることと同じでした。
問いを「誰が」から「なぜ通ったか」へ
「なぜミスをしたのか」ではなく「なぜその操作がそのまま通ってしまったのか」を問うと、答えが直せる場所に向きます。
失敗が起きたとき、いちばん自然な反応は「誰がやったか」を探すことです。けれど責めると、失敗は減らずに、失敗の報告だけが減ります。見えなくなった失敗は直しようがありません。責める相手が自分だけでも同じで、自分を責めていると、失敗を正直に書き残すのが嫌になります。
だから問いの立て方を変えました。「なぜ、そんなミスをしたのか」ではなく、「なぜ、その操作がそのまま通ってしまったのか」を問います。前者は「うっかり」で終わりますが、後者は「危ない操作の手前に止める仕掛けがなかった」「確認が記憶頼りだった」といった、直せる場所にたどり着きます。
この考え方は、大規模なシステム運用の世界で積み上げられてきたものです。Google の SRE 本は、関わった人はその時点の情報の中で最善を尽くしたと考え、原因を人でなく仕組みや手順に求める振り返りを紹介しています。規模はまるで違いますが、小さな会社にもそのまま効きました。
経緯は保管庫に、ルールは1行に分ける
何が起きたかの経緯は保管庫に厚く残し、毎回読むルール集には次の行動を1行だけ足します。
ミスの記録は2つに分けています。1つは、作業の前に必ず読む現役のルール集です。ここには行動のルールだけを、原則1行で置きます。もう1つは保管庫で、詳しい経緯、時系列、退役した古いルールを全部入れます。2026年11月5日時点で、ルール集は45行、保管庫は1,700行を超えています。
新しいミスが起きたら、経緯は保管庫に書き、ルール集には「次にどう動くか」の1行だけを足します。背景を知りたいときだけ保管庫を開けば済みます。学びを捨てずに、毎回読む文書を軽く保てます。
この分け方は、責めないための工夫でもあります。経緯には「やってしまった」という感情がにじみます。それを毎日目にする場所に置くと、読むたびに自分を責めてしまいます。手前に置くのは、未来向きの1行だけにします。
1行の書き方: してはいけないこと・代わり・痛み
1行には、してはいけないこと、代わりにすること、実際に踏んだ痛みを入れます。抽象的な戒めでなく、次の一手を書きます。
実際の行をいくつか紹介します。
- 「空の出力は『不明』。0件と混ぜない」。コマンドが何も返さなかったとき、それを0件と読まず、終了の状態とエラーの出力を見る。取得に失敗しただけなのに0件と読んで、誤った報告をしかけたことから生まれた行です
- 「文書は計画、今の状態は実物で測る」。状態を報告する前に、必ず1回その場で測る。文書に書かれた状態をそのまま今の状態として報告し、実際にはとっくに変わっていた、という失敗を何度か繰り返して生まれました
- 「取り込んだことと、公開に出たことは別」。変更を取り込んだら、実際に公開先へ反映されたかを確かめるまで完了と言わない
根拠のない禁止は破られますが、実際に落ちた穴の記憶が付いていると守られやすくなります。1行に収めるという制約が、かえって本質だけを残す力になりました。「これは1行にできるか」と考えること自体が、ミスの本質を言葉にする練習にもなっています。
ルール集を太らせない決めごと
1本足すなら1本退役させ、退役したルールは消さずに保管庫へ移します。機械で止められるものは、ルールでなく機械に任せます。
運用で油断すると、ルール集に経緯を書き足したくなります。そこでルール集の冒頭に、「経緯は保管庫へ、ここには1行だけ」「1行は120字以内」「足すなら1本退役させる」と、運用そのものを縛る決めごとを書いています。
退役したルールは消さず、保管庫へ移します。もう使っていない戒めでも、なぜやめたかは将来の判断材料になるからです。
もう1つ大事にしているのが、機械で止められるものは機械に任せることです。たとえば、作業の履歴を強制的に消すような危ない操作は、ルールに書くだけでなく、実行の前に機械が止める仕掛けにしています。人もAIも、読んだルールをいつか忘れます。止める仕掛けがあれば、忘れても通りません。
まとめ: 失敗を、次の一手を軽くする道具に
経緯は重く、ルールは軽く。主語を人から仕組みに移し、次に引っかからない一手を1行で残します。
失敗はゼロにできません。だからこそ、失敗を次にどう活かすかの設計が効きます。私たちのやり方は、経緯は保管庫へ、行動のルールは1行だけルール集へ、という分け方を守るだけです。
何かをやらかしたら、落ち込む前に「これは、どんな仕組みがあれば防げたか」と問い、答えを1行にして残してみてください。この1行のルールを積み上げる運用は、私たちが公開している運営の雛形 ai-coo-starter にも入れています。
よくある質問
ミスの経緯を消して1行だけ残すのではだめですか？
経緯は消さずに保管庫へ残します。1行のルールだけだと、時間がたつと何を防ぐためのルールだったかが分からなくなり、外してよいかの判断もできなくなるからです。
1人で仕事をしていても、責めない振り返りは意味がありますか？
あります。自分を責めていると、失敗を正直に書き残すのが嫌になり、記録が残らなくなります。「どんな仕組みなら防げたか」を問うと、次に使える答えが出やすくなります。
ルールが増えすぎたらどうしますか？
1本足すなら1本退役させる、という上限を決めています。退役したルールは保管庫に移します。機械で止められるものは、ルールでなく実行前に止める仕掛けにして、ルール集から外します。
1行にまとめきれない複雑な失敗はどうしますか？
経緯と分析は保管庫に詳しく書き、ルール集には「次に何を確かめるか」だけを1行で置きます。まとめきれないときは、1つの失敗から複数の1行が出ることもあります。
参考・出典
- Google SRE Book: Postmortem Culture: Learning from Failure（個人を責めず、原因を仕組みや手順に求める振り返りの考え方）
- ai-coo-starter（GitHub）（この記事のミスの記録の運用を含む、私たちが公開している運営の雛形）