Slide 1
Slide 1 text
Datadog のトライアルを
成功に導く技術
ヌーラボにおけるオブザーバビリティ改善の道のり
Japan Datadog User Group Meetup#9@福岡
Yuki Yoshiiwa
Slide 2
Slide 2 text
📛 吉岩祐貴 (@mananyuki)
💻 Platform Engineer @ Nulab Inc.
📚 趣味・関心
● SRE / Platform Engineering
● Kubernetes
● いぬ🐕 / さかな🐟
● アイドル
Slide 3
Slide 3 text
3
ヌーラボについて
● 創業21周年
● NULL + LAB = NULAB
○ 無の状態から有を創り出す「研究所」のような会社
● 福岡を拠点に世界へ広がるヌーラボオフィス
○ リモートワーク / コアレスフレックス / 多様な労働スタイルに理解のある職場
○ General Meeting (社員総会) で集結することも
Slide 4
Slide 4 text
No content
Slide 5
Slide 5 text
5
本⽇のテーマ
本セッションで特に伝えたいこと:
● Datadog チャンピオン (推進者) となることの重要性
● 透明性が高く、客観的な評価に基づく意思決定プロセスの勘所
📝 アジェンダ:
1. Datadog 選定の背景: ヌーラボの課題とツール選定プロセス
2. トライアルを成功に導いた「3つの戦略的準備」
3. まとめ
Slide 6
Slide 6 text
Datadog 選定の背景:
ヌーラボの課題とツール選定プロセス
Slide 7
Slide 7 text
Datadog 導⼊前の課題
Slide 8
Slide 8 text
8
監視ツール乱⽴による「⾒えない壁」
🧩 監視ツールの断片化
● 主要ツール: Prometheus、Grafana、CloudWatch、Mackerel などが併存
● 結果: システム全体の健全性を一元的に把握できず、情報がサイロ化
● 影響: インフラとアプリケーション間のデータ相関分析が困難
😥 SREs / 開発者の負担増
● 運用負荷: 複数ツールの管理 (アップデート、設定など) で SREs の負荷増
● 認知負荷: 新規メンバーの学習コスト増。複数ツールの UI / クエリ習得
● 潜在的コスト: オブザーバビリティ基盤の自社構築・維持には SREs 3-5名相
当の工数が必要と試算
Slide 9
Slide 9 text
9
MTTR 悪化とその他の問題
⏱ インシデント解決の遅延 (MTTR 悪化)
● 初動の遅れ: 新規オンコール担当者などが、どのツールを見るべきか迷う
● 調査の非効率: オブザーバビリティが不十分で、複数ツール間でリクエスト
ID を突き合わせ調査
🤔 その他、見過ごせない課題
● 属人化の進行: 特定個人に依存した専門知識のブラックボックス化
● 限定的な可視性: システムパフォーマンスの可視性が不十分で、プロアク
ティブな問題特定やリソース最適化が困難
● DevOps の阻害: 開発と運用の効果的な連携を妨げ、共通理解の醸成が困難
Slide 10
Slide 10 text
ツール選定プロセスと ADR の活⽤
Slide 11
Slide 11 text
11
Architecture Decision Records (ADR) とは？
📜 Architecture Decision Records (ADR) とは
● 重要なアーキテクチャ上の決定を記録するための軽量なドキュメント
● 「何を」「なぜ」「どのように」決定したのかを簡潔に記述
👍 ヌーラボがADRに期待するメリット
● 関係者の合意形成の促進
● 後日の決定理由の明確化・参照の容易性
● 知識の共有とオンボーディングの効率化
● 意思決定プロセスの透明性向上
Slide 12
Slide 12 text
12
なぜ意思決定プロセスに課題があったのか？
🤔 過去の反省点:
● 2022年に全社的に Architecture Decision Records (ADR) を導入するも、
SRE チーム内での活用が不十分
● 結果: 意思決定の経緯が不明瞭になるケースが発生
💡 今回の選定での改善:
● オブザーバビリティツール選定では ADR を積極活用し、決定プロセスを記録
・共有
Slide 13
Slide 13 text
13
評価プロセス①: トライアル対象ツールの選定
⚖ 客観的評価軸に基づく網羅的な比較検討
● 機能、コスト、操作性、将来性、学習リソース、コミュニティなどを多角的
に評価
● 例: Observability (Metrics, Logs, APM, Frontend), Learning resources,
Cost control, Popularity, Business Continuity
🎯 候補ツールの絞り込みと ADR による記録
● 比較の結果、Datadog を含む複数の主要候補ツールをトライアル対象として
決定
● この意思決定を ADR として記録し、透明性と再現性を確保
Slide 14
Slide 14 text
14
評価プロセス②: 多⾓的なフィードバック収集
🧪 実践的なシナリオに基づく詳細トライアル
● 選定された候補ツールを導入
● 実際の業務課題（例: 特定の障害調査、ダッシュボード作成）を解決できる
か検証
📊 定量的・定性的評価の収集と分析
● Datadog (社内評価: 4.46/5) / 候補B (社内評価: 3.88/5) のように評価スコ
アを収集
● SREs、開発者など現場エンジニアによる定性評価 (操作感、学習コスト、課
題解決能力、サポート体制など) を重視
Slide 15
Slide 15 text
15
評価プロセス③: 導⼊ツールの最終決定と組織的合意
⚖ 総合的な評価と最終決定
● トライアル結果、アンケート、コスト、将来性、Datadog の主な強み (直感
的な UI、Go 言語プロファイラ、包括的機能、社内評価の高さなど)、候補 B
の主な強み (手厚いサポート体制など) を総合的に比較検討。
● 最終決定会議での議論を経て、Datadog を選定。
ADRによる最終決定の記録
● この最終決定を ADR として記録し、全社に公開
Slide 16
Slide 16 text
16
判断理由①: 優れた操作性と開発⽀援機能
🌟 直感的な UI と柔軟なダッシュボード
● 学習コスト低減と迅速な情報把握・分析を支援
💡 Go 言語を含む継続的プロファイリング機能
● ボトルネック特定と開発サイクル改善に寄与
Slide 17
Slide 17 text
17
判断理由②: 包括的な機能セットと将来性
🛠 統合監視プラットフォーム
● Metrics、Logs、APM などを単一基盤で提供しツール分断を解消
📈 R&Dへの継続的投資と事業計画との整合性
● 技術的進化への期待とヌーラボ戦略との適合性
Slide 18
Slide 18 text
18
判断理由③: トライアルによる有効性の実証と組織的合意
🤝 社内トライアルでの高い評価
● 平均4.46/5点という高評価を獲得
📊 課題解決への貢献
● 「ボトルネック特定」「調査効率向上」など業務改善効果を実感
🗣 全社的な意思決定
● 最終決定会議での広範な支持と合意
Slide 19
Slide 19 text
トライアルを成功に導いた
「3つの戦略的準備」
Slide 20
Slide 20 text
20
なぜ「準備」がトライアルの成否を分けるのか？
😥 過去の反省:
● 透明性の低い意思決定プロセスは、現場に「押し付け感」を生み、ツールの
定着を阻害
💡 今回の学び:
● 技術検証だけでは不十分。ツール選定・導入を成功させるには、組織的な
「仕込み」が不可欠
本セクションでは、ヌーラボが Datadog トライアルを成功に導いた、具体的な
「3つの戦略的準備」を紹介します。
Slide 21
Slide 21 text
準備①: 「なぜやるのか？」
⽬的と評価軸の徹底的な明確化
Slide 22
Slide 22 text
22
現状課題の共通認識を醸成
🗣 全社アナウンスによる目的共有
● トライアル開始前に、監視体制の現状課題（運用負荷、認知負荷、MTTR 悪
化など）と、ツール統合によって「何を目指すのか」を共有
📢 現実的な期待値の設定
● 「ツール移行で全てが解決するわけではないが、本質的な活動に取り組める
状況を作る」
Slide 23
Slide 23 text
23
トライアルのゴールと評価基準を定義
🎯 明確な評価軸の設定
● 「何を触っていいかわからない」状態を回避
○ オブザーバビリティの民主化
○ MTTR の短縮
○ 効果的な DevOps 文化の醸成
○ 開発生産性の向上
📝 フィードバック収集の仕組み
● 設定した評価軸に基づき、具体的なアンケート項目を作成し、トライアル参
加者からフィードバックを収集
Slide 24
Slide 24 text
準備②: 「誰とやるのか？」
推進体制と情報透明性の確保
Slide 25
Slide 25 text
25
Datadog チャンピオンの役割
🏆 主体的な情報提供と推進
● 自身が推進者となり、トライアルに必要な情報（ツールの概要、効果的な使
い方、外部セッション資料など）を積極的に提供
📚 事前の徹底的なドキュメント読解
● 事前に Datadog ドキュメントを徹底的に読み込み、理解を深めることで、ト
ライアル中の問い合わせに迅速かつ的確に対応できる体制を構築
Slide 26
Slide 26 text
26
関係者の早期巻き込みと ADR 活⽤
👥 多様な視点での評価
● SRE チームだけでなく、開発チームのメンバーにも初期段階からトライアル
へ参加を呼びかけ、多角的なフィードバックを収集
🔗 透明性の高い意思決定プロセス
● ADR を活用し、トライアル対象の絞り込みから最終決定までのプロセスと理
由を記録・公開し、組織全体の納得感を醸成
Slide 27
Slide 27 text
準備③: 「どう試すか？」
効果的なトライアル体験の設計と⽀援
Slide 28
Slide 28 text
28
スモールスタートと学習⽀援
🚀 スモールスタートと対象範囲の明確化
● 限定的な範囲（代表的なサービスや機能、開発環境など）からトライアルを
開始
● 検証したい内容、対象範囲を明確化し、評価のブレを防止
操作理解を促すハンズオンとベンダーセッション
● 主要機能や評価ポイントを理解するためのハンズオンを実施 (「ここを触れ
ば OK」というガイド)
● Datadog ベンダーによる紹介セッションを企画し、初期理解を促進
Slide 29
Slide 29 text
29
迅速な Q&A と情報共有
💬 専用 Q&A チャンネルの設置
● Slack チャンネルを設置し、チャンピオンが積極的に回答
🗣 情報共有会による知識の底上げ
● 進捗、課題、Tips などを共有する情報共有会で、参加者全体の知識レベルを
向上
Slide 30
Slide 30 text
トライアルから得られた主要な学び
Slide 31
Slide 31 text
31
学び①: ツール選定は技術と組織の両輪で
🤝 高機能ツールも組織適合が不可欠
● 導入プロセスや組織文化に適合しなければ真価を発揮できない
🗣 広範囲利用ツールは納得感が鍵
● 特に広範囲で利用されるツールの場合、多様な関係者の納得感ある意思決定
プロセスが不可欠
Slide 32
Slide 32 text
32
学び②: 成功の鍵となった「3つの戦略的準備」
🔑 1. 目的設定の明確化
● 「何のために導入するのか」を明確にしたことで、評価軸がブレず、トライ
アルの方向性が定まった。
🔑 2. 関係者の早期巻き込み
● 透明性の高いプロセスで関係部署と連携した結果、導入後のスムーズな協力
体制、さらには新たな Datadog チャンピオンの誕生に繋がった。
🔑 3. 段階的な導入と検証
● スモールスタートで得た小さな成功体験が、全社展開への自信と組織全体の
納得感を醸成した。
Slide 33
Slide 33 text
まとめ
Slide 34
Slide 34 text
34
成功への提⾔: Whyを問い、仲間と⼩さく始める
🔥 情熱を力に、まず「Why」を問う
● なぜ Datadog なのか？ 導入目的を明確にし、組織の共通言語に
● 推進者自身が熱意を持ち、目的と期待効果を粘り強く伝える
仲間を増やし、透明性を武器にする
● 関係各部門を早期から巻き込み、共にトライアルを推進
● ADR などを活用し、選定プロセスや評価基準をオープンに
🌱 小さく始め、学びを力に変える
● 限定的な範囲からスタートし、具体的な評価軸で効果を検証
● 学びを活かし、適用範囲やルールを段階的に拡大・改善
Slide 35
Slide 35 text
35
今後の展望と謝辞
🔭 ヌーラボにおける今後のオブザーバビリティ向上施策:
● IDP (Internal Developer Platform) との連携強化
● SLO 運用の本格化
● FinOps へのオブザーバビリティデータ活用
● → 目指す姿: データドリブンな開発文化の醸成
ご清聴ありがとうございました。