■技術選定はカタログショッピングではありません

最近Webページで話題の技術を取り上げて、メリデメ表をそれっぽく作って、「技術選定しました (｀・∀・´) ！」

って言われてもさ。

その取り上げた技術は、正しく目的に合致するモノなのか？

他に技術は存在しないのか？

なぜその比較項目を選んだのか？

点数つけて合計点で比較してるけど、重み付けとか存在しないのか？

疑問が山積み。

そのメリデメ表、典型的なカーゴカルト。

技術選定ってそもそも、どういうプロダクトになるか考えて、それに合致する技術を探すか作るかするモノであって、こうやってカタログショッピングする類のものじゃぁねぇんだが。

技術選定してからプロダクトのトポロジというかアーキテクチャを決めるんじゃなくて、プロダクトのトポロジというかアーキテクチャが先だろ？

技術ブログ見たら、笑顔で腕組みした写真載せてそういうキラキラした技術で新しいシステムに入れ替えました！ みたいなのがゴロゴロしてるけど、その記事書いた現場の実際なんて、新規機能追加に手間取るし、そもそもローカル開発環境構築に3日から1週間かかるとか、DockerDesktopがパンパンとか、おかしいことになってるって気づかんか？ って状態になってんのよ。

みんな、引き返せないところまで来てんの。

1日1日、底なし沼にじっくり沈んでいってんの。

初回リリースから1年、1年半も経てば、停滞し始めてるよ。

そういうところで、システムがプロフィットセンターになってるところは、キャッシュフローが細って炎上する。コストセンターになってるところは無駄金貪って、キャッシュがガンガン燃える。

おいらはその前者によく入ってたから、こういう技術選定するような「イケてるエンジニア」の知らん現実をたくさん見てきてる。

後者だってよく知ってる。

でも、「新しいシステムは失敗してます。運用とか地獄です」って笑顔で腕組みした写真撮って、技術ブログなんて書けないでしょ？

最新のイケてる技術駆使してる、イケてる現場。できるエンジニアってブランディングしてるんだから。

クラウドの利点は、ロードバランサによるルーティング、増減可能な小さいコンピュートリソース(ElasticBeanstalkが本来はこれ)、メッセージング基盤、永続化層を、疎結合、軽量に組み合わせて大きなサービスを構築できることなのに、なぜそんな拡大版ピタゴラスイッチみたいなうんこの塔をありがたがるのか、理解に苦しむ。

「同じことが実現できるなら、よりシンプルな選択肢を」

ってのはエンジニアリングの原則中の原則だろ？　

ProtocolBuffers on gRPC を盲目的にありがたがってるのとかも。

10倍効率的なんですってよ。

10倍！

いや、ネットワーク転送減らしゃいいだけじゃんよ。

とかね。

この手のカタログスペック厨、なんとかならんのかね？ と思うんだけど、理解できてない筋にはすごくできるエンジニアに見えるようだね。

勘弁してほしい。

そういうの、オンプレSIerでやってくれって。

Permalink | 記事への反応(2) | 00:43

ツイートシェア