失敗に名前をつけると再発が減る

🏷️なぜ「気をつける」ではなく「名前」なのか

「気をつける」は、次に思い出せない。名前は、同じ場面に立ったときに向こうから浮かんできます。

失敗の直後は、誰でも反省します。ところが、その反省は次に同じ場面が来たときに思い出せない。これが問題でした。反省文は長いし、どこにしまったかも忘れる。だから同じ穴に、また落ちます。

名前がついていると、話が変わります。似た場面に立ったとき、 その一言が向こうから浮かんでくる。長い経緯を思い出さなくても、 名前が「あ、これはあのパターンだ」と教えてくれます。

私たちは、失敗の詳しい経緯はアーカイブに厚く残し、 現役の注意書きには行動ルールを短く 1 行だけ足す、という運用をしています。 その「1 行」の見出しが、実質的に失敗の名前になっています。

🗂️私たちが実際に使っている失敗の名前

抽象的な標語ではなく、痛い目を見た具体的な場面から生まれた名前です。だから思い出せます。

いくつか、実際に使っているものを挙げます。どれも、一度やらかしてから生まれた名前です。

「マージ済みは、公開済みではない」。コードを本流に取り込んだ（マージした）ことと、それが本番サイトに反映されたことは別物だ、 という戒めです。取り込んだだけで安心して「対応済み」と言いかけたことがあり、 実際にはデプロイが走っていなかった。以来、本番に反映されたかは実物を見るまで「済み」と言わない、と決めています。

「空っぽ ≠ ゼロ件」。コマンドが何も返さなかったとき、それを「 0 件」と読まない。 認証が切れていただけ、取得に失敗しただけ、ということが起きます。 空の出力は「ゼロ」ではなく「不明」として扱う、という一言です。

「文書は計画、ライブは現実」。ドキュメントに「完了」と書いてあっても、それは書いた時点の意図にすぎない。 今そうなっているかは、実際のコマンドや画面で測るまで別物だ、という線引きです。

⚡名前があると、判断が速くなる

名前は、毎回ゼロから考え直す手間を省きます。呼び出した瞬間に、次の一手まで決まっている。

名づけの効き目は、再発防止だけではありません。判断が速くなるのです。「これはマージ済みは公開済みではない、のケースだね」と一言言えば、 次にやるべきこと——本番を実際に確かめる——まで、その場で共有できます。

名前がなければ、毎回ゼロから「今回は本当に大丈夫か?」と考え直すことになります。 名前は、過去に一度きちんと考えた結論を、呼び出すだけで再利用できる形にしたものです。だから速い。

AI に仕事を任せる場面では、これがさらに効きます。 長い注意書きを毎回読ませるより、短い名前で「あのパターンに注意」と渡すほうが、 こちらの意図が伝わりやすい。名前は、人と AI の共通言語にもなります。

✂️いい名前には、条件があります

短く・対比の形で・次の行動が浮かぶこと。この 3 つを満たすと、名前は本当に使われるようになります。

やってみて分かった、使われる名前の条件を 3 つだけ挙げます。

短いこと。一息で言えないと、口に出されず、忘れられます。標語ではなく、合言葉の長さに。

対比の形にすること。「マージ済み ≠ 公開済み」「空っぽ ≠ ゼロ件」のように、 取り違えやすい 2 つを並べると、どこが罠かが一目で分かります。

次の行動が浮かぶこと。名前を聞いた瞬間に「じゃあ実物を見よう」と手が動くなら、その名前は生きています。 逆に、良い教訓でも、次の一手につながらない標語は、だんだん読み飛ばされていきます。

🧭名前は、共有の語彙になる

繰り返す問題に名前をつけて共有する、という発想自体は昔からあります。私たちはそれを失敗に応用しているだけです。

繰り返し現れる状況に名前をつけて、チームで共有する。この考え方自体は、 私たちの発明ではありません。ソフトウェアの世界では、よくある問題と解き方に名前を与える「デザインパターン」という文化が古くからあり、その大きな効用のひとつが「共通の語彙が生まれること」だと語られてきました。

私たちがやっているのは、それを解き方ではなく、失敗のほうに応用しているだけです。よくある落とし穴に名前を与えて、チーム（うちの場合は人と AI）で共有する。 それだけで、同じ穴を避けやすくなります。

もちろん、名前をつければ失敗がゼロになる、なんてことはありません。 新種の失敗はこれからも出ます。でも、一度名前をつけた失敗は、二度目が明らかに減る。私たちにとっては、これで十分でした。

あなたのチームで、何度も繰り返している失敗はありませんか。 もしあるなら――まずその一つに、短い名前をつけてみてください。 次に同じ場面が来たとき、その名前が、きっと先に浮かんできます。