Why Good Engineers Fix the Gun Before They Aim Better

事故は「注意不足」より、たいてい「設計不足」から始まる

何度も同じミスをする人に必要なのは、もっと強い注意力だろうか。それとも、ミスをしやすい環境そのものを変えることだろうか。

多くの現場では、失敗が起きるたびに「次から気をつけます」で片づいてしまう。だが、もし同じ種類のつまずきが繰り返されるなら、それは個人の不注意というより、失敗が起きるように作られた仕組みが残っている可能性が高い。ここで重要なのは、問題をする人の能力ではなく、問題を生む構造を見ることだ。

この視点は、ソフトウェア開発でも、インフラでも、チーム運営でも驚くほど効く。コードを書くのが得意でも、インフラが苦手であれば、その苦手さを個人の努力で埋めるのではなく、そもそもインフラの複雑さに飲み込まれにくい仕組みを選ぶべきだ。逆に、インフラに詳しい人でも、運用のたびに人手の判断が必要な設計を放置すれば、いつか必ず同じ穴に落ちる。

つまり本当に問うべきなのは、「どうすればもっと慎重になれるか」ではない。どうすれば慎重でなくても壊れにくいかだ。

---

問題は人ではなく、撃ちやすい銃である

「足を撃ちまくっているなら、銃を直せ」。この比喩が刺さるのは、失敗の本質を端的に言い当てているからだ。多くの組織は、ミスが起きるたびにユーザー教育、レビュー強化、チェックリスト追加で対処しようとする。しかし、撃ちやすい銃がそのままなら、どれだけ注意喚起しても事故は減らない。

たとえば、デプロイのたびに複数の設定ファイルを手で更新し、環境ごとの差分を頭の中で管理しているとする。このときの事故は、うっかりミスとして表面化する。けれど本当の問題は、人間の短期記憶と注意力に依存しすぎた構造にある。人は疲れるし、忘れるし、文脈を取り違える。だから、失敗しないように祈るより、失敗しにくい形に変えるほうが強い。

これは怠慢ではない。むしろ逆で、成熟した設計思想だ。航空機のコックピットが何重もの確認機構を持つのは、優秀なパイロットを信じていないからではない。優秀な人間でも、限界があることを前提にしているからだ。ソフトウェアも同じで、運用の正しさを個人の集中力に委ねる瞬間に、設計はすでに負け始めている。

ここで一つのフレームワークが役に立つ。失敗の原因を見つけるときは、次の三層に分ける。

1. 個人のミス: 確認漏れ、入力ミス、理解不足。
2. 作業の摩擦: 手順が多い、用語が曖昧、切り替えが多い。
3. システムの誘因: ミスをしたほうが早い、複雑さを避けると前に進めない。

ほとんどの組織は1で止まりがちだが、改善の本丸は2と3にある。とくに3が残っている限り、人は「気をつける」という名目で、壊れやすい仕組みを毎日なぞり続けることになる。

失敗を減らす最短ルートは、失敗する人を鍛えることではなく、失敗しなくても済む構造を作ることだ。

---

苦手な領域ほど、抽象化された足場が必要になる

インフラが苦手なバックエンド開発者が、インフラを避け続けるのは自然だ。VPCやEC2を少し触ったことがあるだけで、CDKは未経験。こうした状況では、インフラの世界は「難しい」ではなく、「どこから理解すればいいか分からない」になりやすい。だから頼れる人に任せる。これは合理的な回避だ。

しかし、ここには落とし穴がある。苦手だから触らない、触らないから慣れない、慣れないから毎回お願いする。その結果、苦手領域が組織のブラックボックスとして固定化される。すると、少しの変更でも関係者が増え、待ち時間が増え、意思決定が遅くなる。やがて、苦手を避けること自体が、別の場所で大きなコストを生む。

ここで有効なのが、複雑さを一気に飲み込むのではなく、認知負荷を下げる足場を使うことだ。たとえば、手書きでクラウドの細部を全部組み立てるのではなく、一定の型を持った仕組みを使う。抽象化されたツールは、詳細を隠すだけではない。本質的には、次に何を考えればよいかを明確にする装置だ。

料理でいえば、毎回包丁の鋭さや火力の癖をゼロから学ぶ必要がある厨房と、レシピと器具の配置が標準化された厨房では、同じ料理でも失敗率が違う。インフラの抽象化も同じで、目的は「裏側を完全に理解しなくてよい」ことではなく、裏側の複雑さに押しつぶされずに前へ進めることだ。

このとき大切なのは、抽象化を怠けの口実にしないことだ。抽象化された道具は、責任を消すのではない。むしろ、責任の置き場所を変える。細部を手で持つ責任から、適切なレールを選ぶ責任へと移る。だから本当に問われるのは、「自分は全部理解しているか」ではなく、「理解の深さが足りなくても安全に扱える構造になっているか」だ。

---

強いチームは、慎重さを美徳にしすぎない

多くのチームは、優秀さを「ミスしないこと」と誤解する。だが、現実の複雑な仕事では、ミスゼロは幻想に近い。必要なのは、ミスを絶対にしない人材ではなく、ミスが起きても致命傷にならないシステムだ。

ここで逆説が生まれる。個人の注意力を上げることに全力を注ぐチームほど、実は脆い。なぜなら、そのチームの安定性は、疲労、異動、属人化、心理的プレッシャーに弱いからだ。一方で、仕組みを整えるチームは、個々の能力差を吸収しやすい。新人でも一定の成果を出しやすく、ベテランも雑務に消耗しにくい。

これはインフラだけの話ではない。レビュー文化にも当てはまる。レビューを「間違い探し」にすると、人は萎縮し、責任は分散し、学習は遅くなる。だがレビューを「壊れやすい箇所を設計の段階で見つける場」と捉え直せば、会話の質が変わる。何を見落としたかではなく、何が見落とされやすい構造になっているかを議論できるからだ。

同じことはオンボーディングにも言える。新しい人が入るたびに、口頭説明と暗黙知で凌ぐ組織は、毎回同じ摩擦を再生産する。逆に、知識が手順化され、操作が文書化され、エラーが起きやすい地点にガードレールがある組織は、新人の学習も速い。つまり、わかりやすさは親切ではなく、生産性のインフラなのだ。

優れたチームは、メンバーのミスを減らすのではなく、ミスの影響範囲を狭める。

この視点に立つと、「誰が悪いか」より「どこが壊れやすいか」に会話が移る。そこから初めて、継続的な改善が始まる。

---

何を直すべきか: 技術より先に、失敗の経路を直す

では、実際にどう考えればいいのか。ポイントは、問題を「知識不足」と「構造不足」に分けることだ。知識不足は学習で改善できる。しかし、構造不足は学習だけでは直らない。むしろ、学べば学ぶほど複雑さに慣れ、危険な手順を当たり前にしてしまうことすらある。

そこで、次のような診断をしてみるとよい。

• その作業は、一回のミスでどれだけ壊れるか。
• その作業は、同じ人が何度やってもブレやすいか。
• その作業は、新しい人でも手順通りに再現できるか。
• その作業は、手でやる理由が本当にあるか。
• その作業は、失敗したときに自動で止まる仕組みがあるか。

この問いに答えるだけで、多くの「気をつければ済む問題」が、実は設計の問題だと見えてくる。たとえば、設定変更をコード化する、定型作業をテンプレート化する、危険な操作に二段階確認を入れる、デフォルト値を安全側に寄せる。どれも派手ではないが、事故の起点を減らす力がある。

そして、苦手な領域を扱うときほど、この考え方は重要だ。得意な人は、頭の中の補完でなんとかできてしまう。だからこそ、失敗の構造が見えにくい。だが、苦手な人にとっては、その補完が効かない。抽象化された足場、明確な手順、再現可能な構成があって初めて、前に進める。つまり、苦手な人でも進める設計は、たいてい全員にとって良い設計だ。

ここに普遍性がある。設計とは、最上位の達人を助けることではなく、平均的な人が安全に働けるようにすることだ。達人はどんな環境でもある程度やれるが、組織は達人だけで回らない。だから優れたシステムは、才能の差を前提にしつつ、誰でも足を撃ちにくいように作られている。

---

Key Takeaways

1. ミスが続くなら、まず人ではなく仕組みを見る。 失敗は注意不足ではなく、失敗を誘発する構造から生まれていることが多い。
2. 苦手領域は、根性ではなく足場で攻略する。 抽象化されたツールや標準化された手順は、理解を放棄するためではなく、理解の負荷を下げるためにある。
3. 優れた設計の目標は、ミスをゼロにすることではない。 ミスが起きても致命傷にならないよう、影響範囲を小さくすることが重要。
4. レビューやオンボーディングは、知識伝達ではなく構造改善の場にする。 「何が悪いか」より「どこが壊れやすいか」を見る。
5. 手でやっている作業には必ず理由を問う。 その作業が人間の記憶と注意に依存しているなら、まず自動化や標準化を疑う。

---

足を撃たない組織は、慎重な人ではなく、賢い銃を持つ

私たちはつい、優秀さを個人の緊張感や努力量の問題として考えてしまう。だが本当に強い組織は、人に「もっと気をつけろ」と言う代わりに、気をつけなくても壊れにくい道を作る。そこでは、苦手な人が無理に熟練者の真似をする必要がない。むしろ、苦手な人がつまずかずに進めること自体が、その仕組みの良さを証明する。

結局のところ、成熟とは完璧になることではない。人間がミスをする存在だと認めたうえで、ミスが自然に増幅しない形へ変えていくことだ。足を撃たない人間を育てるのではなく、足を撃ちにくい仕組みを持つ。その発想に切り替えた瞬間、設計も学習も、チームも、ずっと前に進みやすくなる。