KODANSHAtech エンジニアの堤です。
去る2024年3月8日に、Datadog社の事例紹介セミナーに弊社の長尾と天重が登壇し、KODANSHAtechでのDatadog導入事例を紹介させていただきました。
監視&分析サービスであるDatadog、導入したのは、講談社の美容・コスメ誌であるVOCE (https://i-voce.jp/) WEBサイトです。
発表資料はこちら↓
この資料をパラパラとめくっていただくと分かると思うんですが、Datadogの話、あんまり出てきてません！！ 何しに行ったの？ まあ聞いて下さい。だいたい以下のような話をしてきました。
分断を乗り越える。分断って何？
「コンウェイの法則」というのをご存知でしょうか？
システム（広義に定義）を設計するあらゆる組織は、組織のコミュニケーション構造をコピーした構造を持つ設計を生み出す。
ある組織がそのコミュニケーション構造において完全に柔軟でない限り、その組織は 生み出すすべてのデザインにおいて、自分自身のイメージを刻印することになる。 組織が大きくなればなるほど柔軟性は低下し、この現象は顕著になる。
これはどなたにも見聞きしたり実際に経験したことがあるでしょう！ "サイロ化"、"縦割り"、表現する言葉は様々ですが、分断が生じることは組織の宿痾です。そしてそれは容易にデザイン（設計）に転移するものなのですね。
2020年頃に大きなシステム刷新を果たしたVOCEウェブサイトもまたこの現象に陥っていたと言えます。
開発段階において「このサブシステムは協力会社A社さんが開発します、こっちのサブシステムは協力会社B社さんが担当します」という体制を前提としていた故にか、 "コミュニケーション構造において完全に柔軟" であったとはいえず、それがシステムの実装にも刻印されていました。
例えばロギングひとつとっても、各サブシステム毎にログフォーマットが異なっていたり、そもそも "何を" ログに記録するかが定まっていなかったり……。
こういった種類の落ち度が運用段階に入って以降、次々と顕在化してきました。
業務の境界がシステムの境界となり、その境界をまたいだ情報流通に不便を生じさせている……。 まさにコンウェイの法則そのままですね。
問題にどう取り組んだか？ここでスクラムの話。
コンウェイの言葉をもういちどよく読んでみましょう。"コミュニケーション構造において完全に柔軟" でないときの話をしていますね。"コミュニケーション構造において完全に柔軟" であれば、組織の生み出すデザインは組織と似ないのですよ。
ここでちょっと話を飛躍させて、スクラムの話をします。
スクラムというと、アジャイルの文脈から語られることが多いので、その名の通り Agility=俊敏さ を期待されるのが一般的でしょう。しかし、これは私見ですが、スクラムは俊敏さの実現を最終目的としたプラクティスではないです。
俊敏さが欲しいのなら、その案件によく通じた担当者ひとりかふたりに任せ切るのが一番です。それで問題が無いならそれに越したことはない。しかしその体制が、"コミュニケーション構造において完全に柔軟" な状態を持続できるかというと、それはまた別の話なわけです。
対してスクラムというのは言うなれば、情報とそのやりとりを透明化することを目的とした、コミュニケーションのためのフレームワークです。
そのシステム開発・運用にかかわるすべての事柄がチーム全員で共有され議論されること。これが我々にそれまで欠けていたことでした。VOCE開発チームはすべてをスクラムに則ってすすめることにしました。それがいまから2年ほど前の話。
我々にとってのDatadogの位置づけ
VOCEの各サブシステム・各モジュールの出力する情報をまとめて可視化するために、ログやシステム統計をすべてひとつのツール上に集約する、というイシュー。ふつうですね。そのふつうの仕事、Datadogが無いとできない？
いえいえ、もちろんそんなことはないです。
ただ使ってみた実感としては、Datadogは、従来使っていたAWS CloudWatch Logs によるログ閲覧や、AWS CloudWatch Alarm および AWS CloudWatch Synthetics による監視に較べると、明らかに使いやすいです。
使いやすさとは何か？という議論はここでは省きます。
問題は「使いやすさ」にどれくらい重きを置いて価値判断すべきかということ。
そしてその答えは、「めいっぱい重きを置いて判断しよう」です。なぜなら我々の求めていたのは監視&分析ツールであると同時に実は、コミュニケーションツールだからです。（極論するなら、スクラムやその思想の実践者にとっては、すべてのツールはコミュニケーションツールなのかもしれません。）
たとえば、Datadogではすべての画面のすべての状態にURLが振られ、そのURLにアクセスすれば必ず同じ画面が再現できます。 これはまさにコミュニケーションのための機能です。Datadogは「レポートを作成する担当者と、それを待つ上役」などというユーザー像は想定していないのでしょうね。「みんなDatadogにログインして画面を見ろ、見ながら会話しろ」という思想が見て取れます。 そりゃあ使いやすくなければ勝負にならないですよね。そういう状態に自らを追い込んでプロダクト開発を頑張っているわけだ。偉い！ 開発者として敬意を表します。
Datadogは必ずしも安価ではないので、「高いお金を払っているんだから使わなくちゃ」という気持ちが作用するのは確かです。その結果、ツールに関する評価が高くなるバイアスがかかっているかもしれません。 しかしそれでよいのですよ。そうやってシステムの、ひいては自分たちの事業全体のオブザーバビリティへの関心を高めることは、どんな開発現場にとっても正常進化であるはずです。 その進化をドライブするものは実はツールなのかもしれませんよ。もちろんそれは "よいツール" である必要があるのですが。
まとめ
以上、VOCEでのDatadog導入・利用経験について、というより、そのバックボーンとなる考えを述べました。
あなたの開発現場でDatadogの（あるいはその他のなんらかのツールの）導入判断するにあたって、いくらか参考になってくれるとよいなと思ってます。