ここ最近、ソーシャルメディアやブログでの発信が少なかったように思われるかもしれませんが、そのとおりです。Liz、Austin、George、そして私は4月か5月から『Observability Engineering』第2版の執筆に追われています。私自身は5月以降、執筆に75〜80%の時間を費やそうと努めてきました。

その目標を達成できているか？ いいえ。それでも努力は続けています。進捗は出ています。あと数週間ほどでドラフトを終え、編集フェーズに移り、来年5月頃には皆さんの手に届くようにしたいと考えています。

2019〜2022年に初版を執筆して以来、世界は大きく変わりました。初版には「observability engineering teams」というフレーズすら登場しないことをご存じでしょうか？ 探してみてください — 見つかりません！ 「observability teams」という表現も、巻末近くまで出てこず、そこでも自社で観測可能性ツールをゼロから構築する少数のチームを指しているだけです。

最近では、observability engineering teamsはいたるところに存在します。そのため、新たに「Observability Governance」というかなり大きなセクションを追加します。このガバナンスのセクションでは、こうしたチームをどのように人員配置するか、組織図のどこに位置づけるか、優れたツールをどのように購入するか、どのように統合するか、コストをどのように管理するか、上級幹部に対してどのようにビジネスケースを説明するか、大規模なスキーマやセマンティック規約をどのように管理するかなど、さまざまなトピックを扱います。

問題は、私自身がこれまでソフトウェアを本格的に購入した経験がほとんどないことです。真に大規模でソフトウェアを購入する企業で働いたこともありません。そのため、次のような質問に対して十分な助言をすることができません：

  • どのように選択肢を比較検討するか？

  • ベンダーを変えるべきサインとは何か？

  • 良いPOC（概念実証）とはどのようなものか？

  • ステークホルダーは誰か？ 彼らの懸念事項は何か？

  • 数百万ドル（そして数千人のエンジニアの業務体験）がかかっている中で、どのように合意形成を図るか？ その文脈で「合意」とはどのような意味を持つのか？

  • 意思決定時に第一に考慮すべき点は何か？ 第二に考慮すべき点は何か？

私は、すでに何度もこのプロセスを経験したプリンシパルエンジニアが、初めて経験するスタッフエンジニアに与えるようなアドバイス、または何度も経験したVPが、初めて経験するディレクターに与えるようなアドバイスを求めています。

これは、Leiaのシニョンをつけて、空に向かってユニコーン型の虹のバットシグナルを発信しているようなものです。皆さんからのアドバイスはありますか？ 『Observability Engineering』第2版の読者に対して、どのような指針を示すべきでしょうか？

ご自身のアドバイスをメールでお送りください。宛先は honeycomb dot io の私のファーストネーム宛、件名は「Buying Software」としてください。会社やエンジニアリング組織の規模、購入プロセスにおけるご自身の役割についても、関連する文脈を記載していただけると助かります。

さらに質問をさせていただく場合や、リアルタイムでの会話が可能かどうかを確認する場合があります。ただし、皆さんからいただいた内容を引用する場合は、事前に許可を求め、署名入りのリリースを取得します。ベンダー名（良い評価・悪い評価を問わず）は一切記載しません。

私はHoneycombの顧客や購入者を募集しているわけではありません。Honeycombを試したことがなく、関心がない方が大多数だと理解していますし、それは 全く問題ありません。 これはHoneycombのプロジェクトではなく、O’Reillyの執筆プロジェクトです。ただ、ソフトウェア購入に関する良質なアドバイスを集め、優れたエンジニアたちに還元したいと考えています。

ご協力いただけますか？ 皆さんの業界が皆さんを必要としています！ <3

Discussion about this post

Ready for more?