先月、このスペースで助けを求めるちょっとした懇願を投稿し、ソフトウェアの購入に関する良いアドバイスや強い意見をメールで送ってほしいと呼びかけました。

何が返ってくるか全くわかりませんでしたが — 困った時は思い切った手段 — 皆さん、本当に応じてくださいました。時間を割いて経験や専門知識を書き、質問やドラフトのやり取りまでしてくださった皆さん、そしてネットワーク内の専門家に私の問い合わせを転送し、代わりに助けを求めてくださった皆さんにも✨ありがとうございます✨。

この執筆過程で、ソフトウェアの購入やベンダーとの関係管理について本当に多くのことを学びました。正直、この章は本の第2版で最も楽しみにしている部分の一つになりそうです。

懐疑的な表情で片眉を上げて読んでいる姿が想像できます。「本当に、Charity…『ソフトウェアの買い方』なんて、エンジニアリングの最高峰の腕前とは言えないでしょ」

いやいや、皆さん。私は、ベンダーエンジニアリングは深い専門知識の最も微妙で強力な実践的応用の一つであり、エンジニアができる最もレバレッジの高い仕事の一つだと信じるようになりました。何百人、何千人ものエンジニアの労働を、1ドルあたり何セントという単位で活用できる判断を下せる機会はどれくらいあるでしょうか？ 皆さんが下す判断のうち、同僚の全エンジニアの仕事のしやすさや、全顧客の体験に影響を与えるものはどれくらいあるでしょうか？

大げさだと思われるかもしれませんが、これは初歩的な話です。本の中では、私が今まで一緒に働いた中で最高のエンジニアの話と、彼が自分とは何のつながりもない複数の企業の軌道を、数回の会話だけで変えた様子を記しています。それで、エンジニアが大きな力を振るうとはどういうことかについての私の世界観は完全に覆されました。

この仕事をうまくやるには、技術的な深さと幅の両方に加え、システム思考とビジネスへの理解が必要です。これは、スタッフプラスエンジニアがインディビジュアルコントリビューターのままで、エグゼクティブレベルのコミュニケーション、戦略、実行力を身につけられる数少ない方法の一つです。

何年も前からこのテーマについて書きたいと思っていました。えーっと、話が逸れてしまいました。今回はその話をするつもりではなかったのですが、つい興奮してしまいました。本題に戻ります。

皆さんからいただいた丁寧な回答から非常に多くを学べたので、時すでに遅しとならないうちに、もう少し運を試して宇宙に質問を投げかけてみようと思いました。

これらの質問は、私の執筆が少し弱かったり、情報が不足していたり、「3本の柱」モデル（別名マルチピラーまたはo11y 1.0）を使っていて満足している人々の世界からかけ離れていたりする領域を対象としています。そうした人々を私はほとんど（全く？）知りません。これはかなり強い選択バイアスを示唆しています。

誰にもすべての質問に答えていただくつもりはありません。1つか2つでも響くものがあれば、それについて書いてください。残りは無視して結構です。聞くべきだったのに聞かなかったことがあれば、それに答えてください。以前私が書いたことで、気になったことや繰り返してほしくないことがあれば、教えてください！ もう時間はほとんどありません⌛ 持っているものをください。🙌

📈 これまでに、あるobservabilityベンダーから別のベンダーへ移行したことはありますか？ もしあれば、何を学びましたか？ 一番難しかったこと、予想外だったことは何ですか？ 最初に戻って自分に伝えたいことは何ですか？

📈 大規模な移行やツール変更に関わった場合、どのようにプロセスを構成しましたか？ チームごと、サービスごと、プロダクトごとでしたか？ プレイブックはありましたか？ 楽しくしたり、組織の惰性を打破したりするために何をしましたか？ どのくらいの期間がかかりましたか？

📈 Datadog、Grafana、Chronosphere、またはその他の従来の3本の柱アーキテクチャを使用している組織の場合、コスト削減と管理のアプローチをどのように説明しますか？ プロのTipsや包括的な戦略があれば教えてください。

📈 または、実際に従ってみて効果があったブログ記事があれば、リンクを送っていただけますか？

📈 ソフトウェアエンジニアに対し、どのデータをどこに送信するか — メトリクス、ログ、トレース、エラー/例外、プロファイリングなど — をどのように指導していますか？ カーディナリティはどのように管理していますか？ 柱同士を同期させるためにどのように取り組んでいますか？ データソース間でリンクしたりジャンプしたりするための特別なTipsやトリックはありますか？

📈 持続可能な状態に到達した後、コストの管理・維持に必要な継続的なエンジニアリングサイクルは何回程度ですか？

（特に複数の事業部を持つ大企業で働く方へ — ただし他の方も歓迎です！）:

  • コスト管理のためにサービスのティア分けをしていますか？ どのように定義していますか？

  • 新しいツールはどのように試用されますか？（CTOオフィスが新しいものを自由に試し、組織全体のために評価する場合など）

  • テレメトリパイプラインはどのように活用していますか？

📈 Observabilityチームがある場合、チームの規模はどれくらいですか？ 組織のどの部分にレポートしていますか？ そのチームがサポートするエンジニアの人数は概算でどれくらいですか？

📈 Observabilityチームがない場合 — エンジニアが300人以上いる場合 — observabilityのオーナーシップは誰が持っていますか？ Platform？ SRE？ その他？

📈 Build vs Buy: 自社でobservabilityツールを構築した場合、その理由は何ですか？ 何ができるツールですか？ 今日同じ判断をしますか？

📈 OpenTelemetry: OTel採用のprosとconsを検討した結果、技術的または哲学的な理由（「忙しい」以外）で採用しないと決めた場合、その理由は何ですか？

📈 Instrumentation:エンジニアの認知的負荷を軽減するためにどのような取り組みをしていますか？ どの程度まで自動化・魔法のようにできていて、どこで魔法が失敗していますか？

📈 Consolidation: ツールの統合とツールの増殖についてのご意見をお聞かせください。これは主に経営陣が推進しているものですか、それとも技術ユーザーも気にしていますか？ コスト懸念、使いやすさ、それとも別の要因が主なドライバーですか？

2025-10-15追記… あ、しまった、もう一つ質問を追加します：

📈 オープンソース: オープンソースのobservabilityツールを使用していますか？ もしそうなら、それらは主要なツールですか、それとも包括的なツール戦略の一部ですか？ 後者の場合、その戦略を教えてください。

ご意見や回答は、honeycomb dot ioの私のファーストネーム宛てにメールでお送りください。件名は「Observability questions」としてください。

いただいた内容を参考にさせていただく場合、お名前を記載してもよろしいですか？（「このテーマに関する私の考えに寄与してくれた方々、abc xyzなど」といった形で）。雇用主や勤務先については一切触れませんのでご安心ください。

1週間以上経ってから送っていただいた場合、恐らく使用できません。ああ、6月に思いついていればよかった！ #ragrets

これは非常に時間のかかるお願いであることは承知しています。どれだけ感謝しているか言葉では表せません。

P.S. タイトルはもちろんBuffyのミュージカルへの言及です。1ヶ月以内に2度目のblegをするにあたり、皆さんに少し楽しい読み物を提供したかったのです（今でも「bleg」って言うんですか？）。

6 Musical Episodes of TV Shows That Deserve an Encore

P.P.S. 文法クイズ: タイトルは「opinions ABOUT observability」にするべきか、「opinions ON observability」にするべきか？？

素晴らしい質問です — 実は、選ぶ前置詞は思った以上に多くのことを表すかもしれません。

「About」は幅広い、漠然とした、またはおおよその意味で話題や主題を導入する際に使われ、「on」はより詳細で、具体的で、形式的または真剣な主題（および物理的な物体）を示す際に使われます。「夕食について話しましょう」対「彼女はAIが赤ちゃんを殺そうとしている理由についての講義を行った」。

あるいはXanderが言うように、「読書は私たちの英語を良くする」。

地球は終わりだ、
~charity

Discussion about this post

Ready for more?