git pushしたらテストされてきちんと正しい挙動のアプリケーションがデプロイされる。みたいな仕組みは割と当たり前だと思って生きてきた。ただ世の中にはまだEC2に入ってgit pullしてsystemcltで再起動して最新のアプリケーションコードを反映するみたいなことが必要なシステムはある。gitがあればまだ良くてzipとかをメールで共有してpatchコマンドを当てる運用なんかも存在している。
嘘だろと思うかもしれないが私はここ2~3年でそういったシステムのお手伝いを3回くらいやっている。又聞きではあるが他の人たちからも聞くので超レアな話ではなさそうだという感じである。さらにこれが10年来のシステムでメンテナンスがされてこなかったとかであればそうかとなるのだがどうやら新規構築でこういったフローのサービスに出会ったりもするから不思議である。
AIがあって簡単に運用が楽なシステムが組めるならそれでよくないかと思ったりする。実際にClaude Codeにsshしてpullするデプロイで組めないかを聞いてみるとその方法は推奨されなくてモダンな仕組みが提案されてくる。なので今このフローを組むにはモダンな提案をしてくるAIを拒否しながら実装を進めていく必要がある。これにメリットはあるのだろうか。
もちろん、すべてのシステムに立派なプラットフォームや複雑なデプロイ基盤が必要だとは思わない。小さなサービスなら、シンプルな構成でよい。ただ、シンプルであることと、手作業に依存することは違う。シンプルなCI/CD、シンプルなロールバック、シンプルな監査ログは作れる。
では、なぜそれでも手作業に依存する構成が選ばれるのか。「学習しないで知っていることでなんとかしようとする」という力が強いんじゃないかなと思っている。SSHして git pull する方法は、多くのエンジニアにとってすでに理解している操作で完結する。一方でCI/CDは、パイプライン、アーティファクト、権限、失敗時の挙動など、いくつかの概念をまたいで理解する必要がある。この差は思っている以上に大きい。
結果として、「すぐ動く既知の方法」が選ばれ、「後から整える」という意思決定がなされる。(そして多くの場合、その「後」は来ないがw)興味深いのは、AIがこの状況を変えきれていない点だ。AIはモダンな構成を提案してくるし、実装のハードルも下げてくれる。それでもなお、既知のやり方に寄せる選択がされるのは、「知らないからできない」のではなく、「学習する意思決定をしていない」からだと思う。
こう考えると、「なぜそんな運用が存在するのか」という問いに対しては、「合理的な理由がある」というより、「合理的に見える小さな選択の積み重ねの結果そうなっている」と捉える方がしっくりくるのかもしれないなとなった。
「今ある知識でなんとかするか」か「少し学習してより良い方法を選ぶか」
どちらを選んでもその場は進む。ただ、その差は時間が経つほど大きくなる。
AIがあっても、この構造自体は変わらない。むしろ良い選択肢が簡単に手に入るようになった今だからこそ、それを取りに行くかどうかの意思決定がより重要になっているのかもしれない。やはり、学習していくことは大事だなと改めて感じた。最近本を読むとかインプットへのモチベーションが減っていたけどちゃんと学んでいこう。
