Fix the System, Not the Person: What Bad Infrastructure Reveals About Great Engineering

まず、あなたの失敗は本当に「能力不足」だろうか

コードを書いているとき、同じミスを何度も繰り返すことがある。権限設定を忘れる。環境変数を壊す。手順を間違える。レビューで何度注意されても、気がつくとまた同じところでつまずく。

そのとき多くの人は、原因を人間の注意力に求める。もっと丁寧にやれ。もっと気をつけろ。もっと学べ。だが、ここで立ち止まって考えたい。本当に直すべきなのは、人間の注意力なのか、それとも失敗を量産する仕組みなのか。

ある開発者は、何度も自分やチームがミスをしているなら、直すべきなのは銃だと言う。つまり、撃ち方を教えるより先に、そもそも誤射しやすい武器を取り上げろという発想だ。これは乱暴な比喩に見えて、実はソフトウェア開発の核心を突いている。特にインフラが絡む場面では、この問いがさらに鋭くなる。苦手意識のある領域に入るたび、人は能力の不足を感じるが、実際には複雑すぎる道具、曖昧すぎる責任分界、失敗しやすい手作業が人間を追い詰めていることが多い。

この話の本質は、個人の技術力の話ではない。**「人が間違える前提で、どう設計するか」**という、より大きな設計思想の話である。

---

なぜインフラはいつも「自分のせい」に見えるのか

バックエンドは書ける。アプリのロジックも分かる。けれど、インフラになると急に不安になる。VPC、IAM、CDK、デプロイ、権限、ネットワーク。ひとつひとつは理解できそうなのに、つながった瞬間に全体像がぼやける。ここで多くの人は、「自分はインフラに向いていない」と結論づけてしまう。

しかし、これはしばしば誤診だ。苦手なのはインフラそのものではなく、失敗が起こりやすい形でインフラを扱わされていることかもしれない。たとえば、手元で動くコードと本番環境の差が大きい。設定が散らばっている。どこで何が決まるのか見えにくい。誰が何を変更したのかも追いにくい。こうした環境では、熟練者でさえミスを避けきれない。

ここで重要なのは、インフラの難しさを「知識の量」だけで説明しないことだ。難しさの半分以上は、認知負荷の高さにある。人間は、同時に多くの状態を保持しながら正確な判断を続けるのが苦手だ。つまり、問題は「分かっていないこと」ではなく、「分かっていても事故が起きる構造」にある。

人は間違える。だから本当に賢いシステムは、人が間違えないことを期待しない。

この視点に立つと、インフラに対する苦手意識は個人の欠点ではなく、設計上の警告になる。理解できないのではなく、理解していても安全に扱いにくいのだとしたら、解くべき課題は学習法ではなく、システムの形である。

---

「頑張ればできる」より「間違えにくい」が強い

ソフトウェアの世界では、しばしば努力が美徳として語られる。手順を暗記する。設定を手で書く。何度も確認する。もちろん努力は必要だが、努力だけに依存する設計は脆い。なぜなら、疲労、焦り、割り込み、コンテキストスイッチは避けられないからだ。

たとえば、毎回AWSの設定をコンソールで手作業しなければならないとしよう。最初は学びになるかもしれない。しかし、変更のたびにクリック手順を思い出し、権限を確認し、依存関係を頭の中で追ううちに、ミスの確率は急上昇する。人間の脳は、手順を実行するより、例外を処理するのが苦手だ。つまり、作業が複雑になるほど、注意深さは解決策ではなく、ボトルネックになる。

ここで発想を変える必要がある。目指すべきは「ミスしない人」を育てることではなく、ミスしても壊れにくい仕組みを作ることだ。たとえば、インフラをコード化する、設定を一元化する、レビューできる形にする、デフォルト安全側に寄せる、破壊的変更を段階的に適用する。これらは単なる便利機能ではない。人間の弱さを前提にした、組織の免疫システムである。

このとき、優れたツールの価値は「できることを増やす」だけではない。失敗のコストを下げることにある。Amplify Gen2 のような道具が注目されるのも、まさにこの点だ。インフラが苦手でも、完全に分からないまま危険な手作業を続けるより、より高い抽象度で安全に扱えるなら、その方が前進できる。重要なのは、ツールを神格化することではなく、人間が背負うべき認知負荷を適切なレベルまで下げることである。

車の運転を考えると分かりやすい。初心者は、ハンドル、ブレーキ、ミラー、標識、周囲の車を同時に処理するだけで精一杯だ。そこで本当に必要なのは、根性ではなく、良い道路設計、明確な標識、衝突しにくい車、そして失敗したときに致命傷になりにくい交通ルールだ。ソフトウェア開発も同じで、良いインフラとは、優秀な人が頑張らなくても事故が起きにくいように組まれた道路網のようなものだ。

---

失敗が多いチームは、たいてい「学習」ではなく「設計」を直すべきだ

「もっと勉強しよう」は、短期的には正しいように見える。だが、チーム全体で同じタイプの事故が繰り返されるなら、問題は学習不足ではなく、設計ミスである可能性が高い。ここでいう設計は、コードの設計だけではない。プロセス、権限、責任分担、レビュー、運用、ツール選定まで含む。

たとえば、インフラの変更を誰でも自由にできるが、影響範囲は広く、ロールバックも難しいとしよう。これは「自由で速い」ように見えて、実際には事故の温床だ。逆に、変更がテンプレート化され、差分が明確で、プレビューできて、必要ならすぐ戻せるなら、未経験者でも安全に関わりやすい。ここではスキル差よりも、システムが失敗を吸収できるかどうかが効いてくる。

この発想は、個人の成長を否定しない。むしろ逆だ。良い仕組みは、学習を加速させる。なぜなら、失敗しても致命傷にならず、何が起きたかを観察できるからだ。学べない環境は、たいてい失敗が高くつきすぎる。人は痛みが大きすぎる場所では挑戦を避ける。すると経験が積めず、苦手意識だけが強化される。悪循環の完成である。

ここで有効な考え方は、**「人を鍛える」のではなく「行動を安全にする」**ことだ。たとえば、変更前にプレビューを必ず見せる。危険な操作には明示的な確認を入れる。環境差分をコードで管理する。手順書ではなく実行可能な定義にする。これらは地味だが強い。チームの事故率を下げるだけでなく、初心者を即戦力に変える土壌にもなる。

強いチームとは、優秀な個人の寄せ集めではない。失敗しやすい個人でも、全体として正しい方向へ進める仕組みを持つチームだ。

---

良い抽象化とは、現実を隠すことではなく、扱える大きさに切ること

ここで一つ、誤解しやすい点がある。システムを簡単にするとは、現実を単純化しすぎることではない。むしろ逆だ。現実は複雑で、ネットワークは壊れ、権限は漏れ、依存は絡み合う。だからこそ、良い抽象化が必要になる。

良い抽象化とは、複雑さを消すことではない。人間が同時に扱える単位まで複雑さを分割することだ。たとえば、CDK のような構成管理は、インフラをコードとして扱えるようにすることで、感覚的な操作を減らし、差分を追跡可能にする。さらに、その上に高レベルな仕組みが乗れば、細部を毎回意識しなくても安全にデプロイできる。これは怠慢ではなく、賢さだ。

抽象化が悪くなるのは、内部が見えず、失敗したときに原因にたどり着けないときだ。だが、良い抽象化は、普段は簡単に扱え、必要なときだけ深く潜れる。つまり、**「普段は薄く、問題が起きたら深く」**という二層構造を持つ。これは開発だけでなく、運用や組織設計にもそのまま当てはまる。

この二層構造があると、初心者は上の層で安全に仕事ができる。経験者は必要に応じて下の層に潜り、問題を診断できる。重要なのは、下の層を完全に隠さないことだ。ブラックボックス化しすぎると、トラブル時に誰も助けられなくなる。したがって理想は、安全に始められて、深く理解もできることだ。これが、難しい領域を実用的にする鍵である。

---

Key Takeaways

1. 同じミスを繰り返すとき、最初に疑うべきは人ではなく仕組みです。 注意不足を叱るより、誤りやすい手順や設計を直した方が効果が大きい。
2. インフラの難しさは知識不足だけではなく、認知負荷の高さにあります。 複雑な変更を手作業で扱うほど、熟練者でも事故は増えます。
3. 良いツールは、できることを増やすだけでなく、失敗のコストを下げます。 プレビュー、コード化、差分管理、ロールバック容易性はすべて安全装置です。
4. チームを強くするのは、個人の根性ではなく、失敗を吸収できる設計です。 初心者でも安全に触れられる仕組みは、学習速度も上げます。
5. 良い抽象化は複雑さを消しません。扱える単位に切り、必要なら深く掘れるようにします。 これが、実務で本当に使えるシンプルさです。

---

結論: 直すべきなのは、あなたの注意力ではなく、あなたが戦っている戦場だ

多くの人は、ミスをすると自分を責める。もっと慣れればいい。もっと集中すればいい。もっと理解すればいい。だが、何度も同じ場所でつまずくなら、そこには個人の努力を超えた構造的な問題がある。

本当に成熟したエンジニアリングとは、気合いで失敗を減らすことではない。失敗を前提に、失敗しても致命傷にならないように作ることだ。インフラが苦手だと感じるとき、それは未熟さの証拠ではなく、むしろ改善余地のあるシステムが見えているサインかもしれない。

だから次に何かでつまずいたら、こう自問してほしい。私は今、スキルを磨くべきなのか。それとも、もっと間違えにくい道具、もっと見通しのよい設計、もっと安全な変更手順を作るべきなのか。

答えが後者なら、あなたは自分に厳しすぎたのではない。ただ、壊れやすい銃を抱えて戦っていただけだ。