あなたはGoogleではない（You Are Not Google）
(blog.bradfieldcs.com)多くのソフトウェアエンジニアは、技術選定において必ずしも合理的ではない。新しい技術を選ぶとき、実際の必要性や問題定義がないまま、単にGoogleやAmazonのようなビッグテック企業が使っているという理由で追随してしまうことが多い。たとえば、MapReduceやHadoopは大規模データ処理のために生まれたが、実際にはそこまでのデータ規模がない企業が導入することで、かえって不要なI/Oコストや機能面での損失を被る。これは単なる「技術崇拝（cargo cult）」現象だ。
記事では、このような無批判な模倣を避けるために、UNPHATというチェックリストを提示している。
Understand – 問題を十分に理解する。
eNumerate – さまざまな候補を列挙する。
Paper – 技術の根拠となる論文やホワイトペーパーを読む。
Historical context – 開発された歴史的文脈を確認する。
Advantages – 長所と短所をバランスよく比較する。
Think – この技術が本当にその問題に適しているのか、自分で考える。
記事では、Cassandra、Kafka、SOA（Service-Oriented Architecture）のような技術が、実際のユースケースに合わない状況で無批判に導入された例も挙げている。たとえばKafkaは、1秒あたり数百万件のメッセージを処理するLinkedInのために作られたが、1日に数十件のトランザクションしかない小規模企業で使われることもある。
著者はまた、GoogleでさえMapReduceがもはや適切ではないと判断したときには利用をやめたことを強調している。結局重要なのは、技術そのものではなく、自分が解こうとしている問題が何かを正確に理解し、それに合った技術を選ぶことだ。
最後に著者は、Pólya、Hamming、Rich Hickeyらも同じメッセージを繰り返し伝えてきたと述べ、核心はシンプルだとする。
「考えよ。そして本当の問題を理解せよ。」
15件のコメント
Googleのおすすめにたまたま出てきたので読んでみましたが、この記事はあまりにもGeekの視点で書かれた記事です。事業的な観点では、まったく的を射た話ではありません。なぜでしょうか。
Big Techが使う大きなツールは専門家を見つけやすいです。
Big Techに入社するために学ぶ人も多いですし、Big Techが選んだからと勉強する人も多いです。当然、これを知っている人を見つけるのも簡単で、経験者や専門家を採用するのもしやすいです。では、初めて見るツールならどうでしょうか。これを集中的に掘り下げた人がまったくいないわけではないでしょうが、そういう人を見つけるのはBig Techのツールの専門家よりはるかに難しいはずです。
Big Techが使っている大きなツールは、リファレンスや資料が豊富です。
多くの人が使う大きなツールは、問題解決のための資料やGoogle検索結果が豊富です。ほとんどの問題は、他の人も経験したことがある場合が大半で、簡単な検索で容易に問題を把握できます。しかし、初めて見るツールの問題はリファレンスを見つけにくく、問題が発生した場合は原因の特定にかなりの時間がかかる可能性が高いです。これも全部コストです。この問題は新しく導入した小さなツールの問題なのでしょうか。それとも別の側の問題を誤解しているのでしょうか。
むしろBig Techのほうがこうしたものを切り替えやすいのです。膨大なデータ処理規模のため、わずかなI/Oの改善が大きな利益になる企業だからです。そして、Big Techが採用したという理由だけで勉強しようとする人も多いです。しかし中小規模の企業では、比較的小さなデータ規模のため、わずかなI/Oの改善はそこまで大きな利益ではない一方で、上の問題は非常に深刻です。中小規模企業が採用したソリューションを学ぼうという人も少ないです。ですから中小規模企業の経営者であれば、Geekのようにこういう点を細かく比較するより、Big Techのツールを真似したほうが、かえって経済的だという結論になることが多いです。
原文を読んでみると、2017年に書かれた文章ですね。
その後8年が経ちましたが、この内容が今でもなお当てはまるのは驚きです。
上の内容にはかなり同意します！
ただ、規模の小さい企業でオーバーエンジニアリングが起きる場合は、大企業を目指す人たちが小さな企業でそうしたツールの経験を積むためでもあると思います。
もちろん、代表はあまり好まないでしょうけどね（笑）
大企業のニーズに合わせて作られたツールを、小規模な企業でもそのまま使うことになる理由の8割はこれではないでしょうか。それをコントロールすべきなのはCTOのはずですが、そのCTO自身が大企業への転職を考えていることもあるので。
やることがあまりないと、つい無駄なことをしてしまうものですよね（笑）
簡単な問題でもわざわざ難しく解けば、何かやった感を出せますし。簡単にやると、それが簡単なことだと思い込む人も多いですしね……（笑）
小さく作ったものを後で大きく作り直すのが怖くて、最初から大きく作ってしまうことが…
K8sにも当てはまる文章だと思います。『保守しにくいコードを書く方法』という本を思い出しますね。笑
結局のところ、技術が解決しようとしている問題と、その技術が生まれた文脈を理解する必要があります。記事に出てきた例としては、次のようなものがあります。
それらが解決しようとしている問題と、自分が解決しようとしている問題が本当に一致しているのかを、よく見極めるべきだと思います。
ああ、共感します。大学生やジュニアの方々をメンタリングするときに、技術の歴史を理解してみるよう助言していたことを思い出しました。
技術は道具であって目標ではない、ということを時々忘れている人が本当に多いように見えます。
ビッグテックで検証されているから、最近よく使われているから……こうしたことが技術選定の主要条件になった瞬間、不必要なコスト増加が自然とついてくるのです。
韓国ではSpringのカーゴカルトが強いですね。
Springは人材を確保しやすいので…
韓国のSpringは、崇拝というよりは…
政府の無能さと開発者の面倒くさがりが多く混ざったハイブリッド…
とても共感します。Springも結局は問題を解決するためのツールなのですから。
ブレインストーミング、マインドマップ、ディープラーニング、研究作業の時間が減り、長期的に効果があります