『入門 監視』のカーゴ・カルトの話
きっかけ
最近『入門 監視』(オライリー・ジャパン)を読んだ。結構前に出版された本かなと思うが、良書というのは聞いていた。
監視についての基本的な考え方やノウハウが載っていてとても良かった。ただ監視とは別の観点の話がとても良かったのでメモ。
「監視のアンチパターン:ツール依存」の章なのだけど、「有名な企業が使ってるから」「あの強いチームが成功してるから」という理由でツールを選ぶということを 「カーゴ・カルト(積荷信仰)なツール選定」 と呼んでいて、この考えの危険性を警告していた。
「他社の成功 = ツールの成功」ではない
本書の主張はシンプルです。
あのすごいチームが成功したのは、そのツールがあったからではない。彼らが直面した課題を解決するために試行錯誤した結果、そのツールや手順が生まれ、たまたま彼らの環境にフィットしただけ。
つまり、成功の本体は ツールそのものじゃなくて、そこに至るまでの試行錯誤(コンテキスト) 。
他所のチームが辿った背景を無視してツールだけ真似しても、自分たちの環境で同じ成功が再現できるわけがない、と。言われてみれば当たり前だが、新しいツールのキラキラした事例を見るとつい忘れがち。
推奨してるプロセス
本書が推奨しているのは、ざっくりこんなプロセス。
- 「なぜそのツールが作られたのか」を調べる。 どういう課題を解決するために開発されたのか、という開発背景を理解する
- 盲信せずに、自分たちで評価する。 他人が良いと言っているからではなく、自分たちのインフラ、アプリケーション、組織のスキルセットに本当にフィットするかを実際に試してみる
個人的に刺さったのは1つ目。ツールが生まれた背景(コンテキスト)を調べると、「これはうちの課題と同じ問題を解こうとしているのか?」が自ずと見えてくる。逆に、背景が全然違うなら、どんなに評判が良くてもうちには合わない可能性が高いと考えることもできる。
これって、ツール依存から抜け出して「自分たちのシステムに必要な監視をデザインする」という本書全体の一番大事な教訓の核。
そして、監視ツールに限った話じゃない
そして、この考え方は監視ツールだけじゃなくて、フレームワークやライブラリの選定にもそのまま応用できる と思う。
「Next.jsが流行ってるから」「あのメガベンチャーがGraphQLを採用してるから」で技術選定すると、まさにカーゴ・カルトになりかねない。その技術がどんな課題を解決するために生まれたのかを知って、自分たちのプロダクトが同じ課題を抱えているかを見る。この順番が大事なんだと思う。
あと、技術選定のときってどうしても メリットばかりに目が行きがち だが、「開発された背景を調べる」というのは、自分たちの開発環境に適しているかどうかを判断する材料を探す一つの観点 としても使える。メリットの裏には必ず前提条件があって、その前提が自分たちに当てはまらなければ、メリットもそのまま享受できないわけ。