だいたい以下のような話をしてきました。分断って何?「コンウェイの法則」というのをご存知でしょうか?システム(広義に定義)を設計するあらゆる組織は、組織のコミュニケーション構造をコピーした構造を持つ設計を生み出す。生み出すすべてのデザインにおいて、自分自身のイメージを刻印することになる。組織が大きくなればなるほど柔軟性は低下し、この現象は顕著になる。"サイロ化"、"縦割り"、表現する言葉は様々ですが、分断が生じることは組織の宿痾です。それは容易にデザイン(設計)に転移するものなのですね。2020年頃に大きなシステム刷新を果たしたVOCEウェブサイトもまたこの現象に陥っていたと言えます。あったとはいえず、それがシステムの実装にも刻印されていました。ログに記録するかが定まっていなかったり......。いった種類の落ち度が運用段階に入って以降、次々と顕在化してきました。業務の境界がシステムの境界となり、その境界をまたいだ情報流通に不便を生じさせている......。コンウェイの法則そのままですね。問題にどう取り組んだか?ここでスクラムの話。コンウェイの言葉をもういちどよく読んでみましょう。ないときの話をしていますね。あれば、組織の生み出すデザインは組織と似ないのですよ。ここでちょっと話を飛躍させて、スクラムの話をします。期待されるのが一般的でしょう。これは私見ですが、スクラムは俊敏さの実現を最終目的としたプラクティスではないです。俊敏さが欲しいのなら、その案件によく通じた担当者ひとりかふたりに任せ切るのが一番です。それで問題が無いならそれに越したことはない。状態を持続できるかというと、それはまた別の話なわけです。対してスクラムというのは言うなれば、情報とそのやりとりを透明化することを目的とした、コミュニケーションのためのフレームワークです。そのシステム開発・運用にかかわるすべての事柄がチーム全員で共有され議論されること。これが我々にそれまで欠けていたことでした。VOCE開発チームはすべてをスクラムに則ってすすめることにしました。それがいまから2年ほど前の話。我々にとってのDatadogの位置づけVOCEの各サブシステム・各モジュールの出力する情報をまとめて可視化するために、ログやシステム統計をすべてひとつのツール上に集約する、というイシュー。いえいえ、もちろんそんなことはないです。よる監視に較べると、明らかに使いやすいです。使いやすさとは何か?という議論はここでは省きます。問題は「使いやすさ」にどれくらい重きを置いて価値判断すべきかということ。その答えは、「めいっぱい重きを置いて判断しよう」です。我々の求めていたのは監視&分析ツールであると同時に実は、コミュニケーションツールだからです。(極論するなら、スクラムやその思想の実践者にとっては、すべてのツールはコミュニケーションツールなのかもしれません。)たとえば、Datadogではすべての画面のすべての状態にURLが振られ、そのURLにアクセスすれば必ず同じ画面が再現できます。これはまさにコミュニケーションのための機能です。Datadogは「レポートを作成する担当者と、それを待つ上役」などというユーザー像は想定していないのでしょうね。「みんなDatadogにログインして画面を見ろ、見ながら会話しろ」という思想が見て取れます。そりゃあ使いやすくなければ勝負にならないですよね。いう状態に自らを追い込んでプロダクト開発を頑張っているわけだ。開発者として敬意を表します。Datadogは必ずしも安価ではないので、「高いお金を払っているんだから使わなくちゃ」という気持ちが作用するのは確かです。その結果、ツールに関する評価が高くなるバイアスがかかっているかもしれません。やってシステムの、ひいては自分たちの事業全体のオブザーバビリティへの関心を高めることは、どんな開発現場にとっても正常進化であるはずです。その進化をドライブするものは実はツールなのかもしれませんよ。ある必要があるのですが。まとめ以上、VOCEでのDatadog導入・利用経験について、というより、そのバックボーンとなる考えを述べました。あなたの開発現場でDatadogの(あるいはその他のなんらかのツールの)導入判断するにあたって、いくらか参考になってくれるとよいなと思ってます。