2026.07.10|実践|✍️ i-Willink

ミスを責めない—仕組みを直すという運用

ミスが起きたとき、人を責めると隠すようになります。私たちは経緯をアーカイブに、行動ルールは1行だけ現役に分け、責任追及でなく仕組みの修正に向ける形にしています。その理由を書きました。

ミスが起きたとき、犯人を探しても、同じミスは減りませんでした。減るのは、報告される失敗の数だけ――つまり、隠れるのが上手くなるだけです。

うちは社長 1 名と、AI（COO 役の Claude Code）だけの一人会社です。失敗するのも、その後始末をするのも、基本は同じ場所。

だから、早い段階で決めたことがあります。失敗を「誰のせいか」で扱うのを、やめました。

代わりに向けるのは、仕組みのほうです。責めないミスログ、という運用の話を書きます。

🫥責めると、失敗は消えない。隠れるだけ

人を責める文化のいちばんの副作用は、ミスがなくなることではなく、報告されなくなることです。見えない失敗は、直しようがありません。

失敗が起きたとき、いちばん自然な反応は「誰がやったか」を探すことです。でも、これを続けると何が起きるか。人は、責められないように振る舞い始めます。

つまり、失敗そのものは減らないのに、失敗の報告だけが減る。危なかった瞬間も、小さなしくじりも、表に出てこなくなる。見えなくなった失敗は、直しようがありません。次に、もっと大きくなって戻ってきます。

一人会社なら、責める相手は自分だけです。それでも同じことが起きました。自分を責めていると、失敗を正直に書き残すのが、だんだん嫌になる。だから私は、「責める」と「直す」を切り離すことにしました。

同じ失敗を防ぎたいなら、問うべきは「なぜやったのか」ではなく「なぜそれが通ってしまったのか」でした。答えの向きが、まったく変わります。

失敗を振り返るとき、私は問いの立て方を変えました。「なぜ、そんなミスをしたのか」ではなく、「なぜ、その操作がそのまま通ってしまったのか」を問う。

前者は人を追い詰めますが、答えは「うっかり」で終わってしまう。後者は仕組みを問うので、「危ない操作の手前に、止める仕掛けがなかった」「確認が人の記憶頼りだった」といった、直せる場所にたどり着きます。

たとえば、まとめて処理したときに関係ないものまで巻き込んでしまったことがありました。ここで「注意不足」と結論づけたら、次も同じです。代わりに「巻き込みが起きない操作の仕方」に運用を変えた。人を責めても再発は防げませんが、仕組みを一段だけ変えると、同じ失敗の道が塞がります。

感情や言い訳を含む長い経緯と、次に効く一行のルールは、置き場所を分けています。責めないためにも、この分離が効きました。

うちのミスログは、二つに分けて残しています。一つは、何が起きてどう対処したかの詳しい経緯。こちらはアーカイブに置いて、普段は開きません。もう一つは、そこから絞り出した「次にどう動くか」の一行ルール。こちらだけを、日々読み返す現役リストに載せます。

この分け方は、身軽さのためでもありますが、責めないための工夫でもあります。経緯には、どうしても「やってしまった」の感情がにじみます。それを毎日目にする場所に置くと、読むたびに自分を責めてしまう。だから感情の残る記録は奥にしまい、手前に置くのは未来向きの一行だけにする。

こうすると、失敗の記録が「反省文の山」ではなく、「行動を変えるための道具」になります。ログを軽く保つことは、ログを責めの道具にしない、ということでもありました。

障害の振り返りを人ではなくシステムに向ける、という考え方は、大規模なサービス運用の世界で積み上げられてきました。一人会社にも、そのまま通じます。

失敗を人でなく仕組みに向ける、という考え方は、私たちが発明したものではありません。大規模なシステム運用の世界では、Google の SRE 本が「Postmortem Culture（障害の事後検証の文化）」として、個人を責めず、原因をシステムやプロセスに求める姿勢を紹介しています。

大事な前提は、関わった人は、その時点の情報の中で最善を尽くしたと考えること。その上で、「では、どんな仕組みなら防げたか」を探す。責任追及ではなく、再発防止に照準を合わせる考え方です。

規模はまるで違いますが、一人会社の私にも、この姿勢はそのまま効きました。自分を裁く時間を、仕組みを直す時間に振り替える。それだけで、同じ場所で転ぶ回数が、目に見えて減っていきました。

失敗したら、まず一呼吸。「誰が悪いか」ではなく「何を変えれば次は防げるか」を一行書く。責めない習慣は、そこから始められます。

明日から試せることを、一つだけ。何かをやらかしたら、落ち込む前に、こう自問してみてください。「これは、どんな仕組みがあれば防げたか?」主語を、人から仕組みへ移す。それだけで、振り返りが前を向き始めます。

そして、出てきた答えを、短い一行にして残す。長い反省はいりません。次の自分が引っかからない一手だけで十分です。責めない、というのは失敗を甘やかすことではなく、失敗を、ちゃんと学びに変えるための姿勢でした。

あなたのチームでは――あるいは自分自身に対しては、失敗が起きたとき、犯人を探していませんか。その視線を、少しだけ仕組みのほうへ向けてみてください。隠れていた失敗が、直せる課題として、表に出てくるはずです。

開発パートナーを探していますか？

最短1週間でMVPを開発。アイデアの検証から本番リリースまで、i-Willinkがフルサポートします。まずはお気軽にご相談ください。