はじめに

こんにちは。tanai（棚井龍之介）です。
2025年からは、FutureVuls の SRE 領域で活動しています。

少し前に、Connpass のイベント を眺めていたところ、Datadog のユーザ会が「札幌現地のみ、オフライン開催！」との見出しを見つけました。

最近、担当サービスへの Datadog 導入に成功 しまして、その「導入成功に至るまでのプロセス」をなんらかの方法でナレッジ化しておきたいと考えていました。なので、このイベントを契機に「自分の経験の言語化する」->「スライド作成を通してナレッジ化する」の経験学習サイクルを回しました。また、「オフライン限定」という利点を活かして、オンライン環境では話せないような「SaaS運用保守担当者としてのリアルな苦労話」にまで踏み込んだ内容となり、Datadog に限らず「オブザーバビリティツール導入時の、胃がキュッとなるような実体験談」を共有できました。

会場は、クラスメソッド株式会社さんの「札幌オフィス」でした！

イベント内容などは「Japan Datadog User Group Meetup#8@札幌 のページ」をご覧ください。

イベント当日のタイムテーブルはこちらでした。

私の登壇内容について、一部のみとなりますが抜粋してご紹介します。

現場の課題分析からDatadog導入に繋げるまでの話

今回は、オブザーバビリティツールの利用状況を「利用開始前」と「利用開始後」の2つに分けた上で、今回は「利用開始前の状況から、Datadog 導入に至るまで」の部分にフォーカスしました。

オライリー本の「オブザーバビリティ・エンジニアリング」など、可観測性がいかに重要か、なぜ重要かを説く本は多数あります。ただし、それらの内容は、書籍という制約上どうしても「一般的な話」に留まってしまうか、もしくは、ビックテックの事例集になっている感があります。Datadog などの「実際のところ、業務を回すのに必須とは言い難い」ツールを導入した担当者であれば、誰もが「（予算獲得に向けた社内説得などでの）個別の苦労話」を抱えているはず（ありますよね？）と思い、その部分にフォーカスしました。

以下のスライドは、プロジェクトの前提条件から、どのような経緯で監視ツールの必要性を強く意識するようになったかを説明しています。

私の場合は、「サービスがスケールし始めた地点」から、チーム体制が「役割分担せずに、全員で取り組む」配置から「各領域ごとに、専任の担当者を決める」体制へと移行し始め、それぞれが専門性を深める中の「業務効率化の一環」として、監視ツールの必要性を感じ始めました。

※本ブログでは「オブザーバビリティツール」と「監視ツール」の表記揺れがありますが、どちらも同じ意味で利用しています。

その中で私が強く実感したのは「情報不足」という点です。

チーム体制が「役割分担せずに、全員で取り組む」のであれば、「オレが知らないことは、アイツが知っている」で乗り切れますし、以心伝心とは言わないまでもツーカーでの意思疎通が可能です。この体制がうまく回っている間は、コミュニケーションコストが少ないので圧倒的なアウトプットに繋がるのだとも思いますし、最新の状況を自動トレースできないドキュメントは「むしろ不要」になります。ただし、メンバー増員によりチームがスケールし始めると「この情報は、誰が知っているんだ？」のルーティング処理に工数が取られ始めて、ドキュメンテーションへのニーズが高まります。

そこで私は、以下の3ポイントを「解決したい課題リスト」として設定し、オブザーバビリティツールの導入により解決を試みました。

• 課題リスト
  • 必要な情報が、どこにあるのか分からない
  • 情報はあるのに、必要な情報に辿り着けない
  • 情報が断片的で、全体像を把握できない

導入候補のツールとしては、以下3つのサービスを検討しました。

• Datadog
• New Relic
• Dynatrace

各サービスの用意する「計装ツール」を自分の環境に組み込み、コンソール画面での表示状況を確認しながら、課題リストの問題が解決できるかを検証していきます。

計装処理を実装するには、マニュアルに記載された「基本的な設定方法」を正しく理解した上で「自環境に合わせたカスタマイズ」が必要になります。実装上難しいポイントや質問事項などは、各社のシステムエンジニア、カスタマーサポートに伴走いただきました。多数の質問へクイックに回答いただき、大変感謝しております。

また、トライアル期間中には、Datadog の「Datadog Summit Tokyo」に参加したり、New Relic の「New Relic実践入門 第2版 オブザーバビリティの基礎と実現」を読むことで「基本機能やツール利活用方法」をインプットしました。

オブザーバビリティツールは「導入後も長い付き合いとなる」ことが明確なので、ツールの検証は「ノリと勢い」ではなく「事実と論理」を土台に、1つ1つの疑問点を解消しながら進めていきました。各社のサービスには「知名度」や「人気度」がありますが、重要な判断指標は「そのサービスが自社に適したツールだと、根拠を持って話せるか」です。このポイントで自信が持てないと、トライアル後の「（予算交渉を含めた）社内説得フェーズ」にて、「なんでそのツールが必要なんだっけ？」や「他はどうなの？」というツッコミに回答できず、それまでの苦労が水疱になります。

最後に、Datadog の導入にあたり、私が重要だと思うポイントを記載しました。

登壇内容では「Datadog 導入に至るまで」のみフォーカスを当たため、「Datadog 導入後」の話までは触れられませんでした。このポイントは、今後のユーザ会やブログで発信していく予定です。Datadog の導入により「Ops + SRE 業務の効率化」だけにとどまらず、開発速度の向上や、CS（カスタマーサクセス）活動での利用にもつながっているため、今回の監視ツールは「導入成功」です。

おわりに

社外イベントは「同じ悩みを持つエンジニア」と苦労話を共有する機会になり、自分自身への刺激とのモチベーションアップにも繋がるため、今後も機会を見つけて積極的に登壇していきたいと思いました！

また、今回のイベント登壇は、以前に 渋川さん の「継続的なアウトプットはなぜよいか？ 著作も数多いエンジニアが語る、社外向け発表がチームまで成長させる話」を読んで刺激を受けていた（それと、イベントに登壇すれば会社経費で東京から北海道に行ける）ので、まずは枠を押さえてから発表ネタを考えた方式です。

ラーニングピラミッドにもあるように、イベント登壇の「他の人に教える」というアウトプットの機会を駆動にすることが、経験の継続的なナレッジ化として有効だと改めて実感しました。

出典: ラーニングピラミッド キャリア教育ラボ

以上、Japan Datadog User Group Meetup#8@札幌 への登壇レポートでした！
今後とも、JDDUG コミュニティの皆様方、よろしくお願いします。