プログラミングが好きなやつはエンジニアに向いてないんだよな。

エンジニアの仕事はあくまでITによる課題解決。

極論だが、スクラムでDDDでクリーンアーキテクチャでGoでRustでと作っても、ユーザーが使ってくれなきゃただの自己満足にすぎない。

プログラミングはあくまで手段。自分のプログラミングにこだわるのではなく、ユーザーにとって何が重要かを一番に考えるべき。

別に多少アーキテクチャがベストプラクティスじゃなくても、モダンな言語じゃなくても、ユーザーが満足して使ってくれればそれでいいのだ。 December 12, 2025

Googleさんのハイパースケーラーのインフラ技術と設計は真似できない的な話が流れてきたけど、GoogleさんだけじゃなくてAmazonも、きっとわからないけどMSさんも多分真似するのは至難だと思います。

エッセンスを持ってくることはもちろんできるけど、ほんとうの意味で真似する事は難しい。
なんならNetflixやUber、Dropboxみたいな大規模な技術スタックを持ってる会社についても同じ事が言えると思う。

要するに「技術は課題の形をして」る。

Googleの分散システムはGoogleの課題の形をしてるし、NetflixのChaos EngineeringはNetflixの課題の形をしてて、これは汎用的なベストプラクティスじゃなく、自分たちの固有のペインを解決するために出てきたものだったりします。

だから真似するのは難しくて、形だけ持ってきても自社の課題にはフィットしないわけです。課題の形が違うので。
逆に言えば、OSSとして公開されているエッセンス（KubernetesやKafka、Chaos Monkeyとか）は、課題の形をある程度汎用化したもので、それはそれで価値があるけど、本質的には同じ問題へ対処するための何かではなくなってるかもしれない。

その技術を生み出したのは、同じ課題に向き合い続けてきた組織で、技術と組織は一緒に進化し、Googleのインフラ技術はGoogleのエンジニアリング文化と切り離せないし、Amazonのマイクロサービスは、作りたいアーキテクチャに合わせて組織を切り分けた結果であり、Netflixが本番で障害を意図的に起こせるのは、それを学びに変える組織があるからである、と。

技術だけ移植しても、組織だけ真似しても、それを運用し進化させ続ける土壌がなければ根付かないし、その形は組織ごとに違うんだよなぁ、ってツラツラ思いました。 December 12, 2025