プログリットにおけるDatadog導入の背景と今後の展望

株式会社プログリット / inady
テックリード / テックリード / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
| ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|
| 11名〜50名 | 2025年10月 | B to B B to C |
| ツールの利用規模 | 11名〜50名 |
|---|---|
| ツールの利用開始時期 | 2025年10月 |
| 事業形態 | B to B B to C |
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
プログリットは創業以来、本格的なObservabilityツールを導入していませんでした。当時使用していたツールは以下の3つです。
- AWS CloudWatch Logs: ログ管理(検索性が低く、使い方に精通していないと使いにくい)
- CloudWatch Alarms: アラート設定
- Sentry: エラー通知(モバイル・フロントエンドには強いが、バックエンドのパフォーマンス分析には弱い)
プロダクト規模が小さく、開発メンバーが数十人規模であった頃は、"あうんの呼吸"で運用できていました。 しかし、プロダクト数が1つから4つに増え、チーム規模も拡大。この状況ではさすがに限界が見え始め、何らかのObservabilityツールを導入しなければ運用が破綻し、可用性・保守性・パフォーマンスの問題が顕在化することは明らかでした。
具体的な課題として、プロダクトの1つであるスピフルではパフォーマンスや可用性の問題が時折発生していました。
しかし全体像を可視化する手段がないため、ログに実行時間を手動で出力したり、コードを読んでボトルネックを推定したりと、実測値に基づかない手探りの改善を続けていました。
このような状況を放置すれば、いつか新機能開発がほとんどできず、障害対応に追われる状態になると判断しました。
比較検討したサービス
- Datadog(採用)
- New Relic
比較した軸
- 料金体系: ユーザーベース課金か従量課金か
- AI機能の充実度: 今後のエンジニア生産性向上につながるか
- 日本でのサポート体制: 日本語サポート・コミュニティの有無
- 信頼性・実績: 市場やビジネスサイドへの説明のしやすさ
選定理由
1. 料金体系の柔軟性(従量課金)
ユーザーベース課金のツールは、コスト観点からアカウント数を絞る方向に力学が働きます。 しかしObservabilityツールは、エンジニアだけでなくPdM・PO・事業責任者・ボードメンバーも含めた全員がプロダクトの状態を把握できることが理想です。 従量課金であれば、開発に関わる全員にアカウントを発行できます。
2. AI機能の進化
DatadogはBits AIをはじめとする最新のエージェンティックAI機能を積極的に導入しています(2025年のカンファレンス「Dash」でも強調)。 DatadogのAI機能を活用することで、エンジニアの負担を軽減し、プロダクト開発により多くの時間を割ける体制を目指しました。
3. 日本でのサポート体制の充実
2019年末のDatadog日本法人設立以降、日本向けのサポート体制が大きく整備された印象です。 毎年開催されるDatadog Summit Tokyoや、ユーザーコミュニティの醸成も進んでいます。2019〜2020年頃に前職でDatadogを検討した際と比べると、日本での存在感は格段に増しています。
4. S&P 500への選定
Datadogはエンジニア界隈だけでなく、市場からも評価されているという事実は、ビジネスサイドやボードメンバーへの説明において「安心材料」として大きな意味を持ちました。
導入の成果
スピフルへの先行導入から1週間後、障害が発生しました。
この障害対応で、早速Datadogの効果を実感しました。
発生した問題: 数分間APIのレスポンスが大幅に劣化。外部APIのパフォーマンス劣化がトリガーでした。
以前の調査手順では、
- ログに実行時間を出力するコードを追加
- 次のリリースを待つ
- 再度障害が発生するのを待つ
- ログを比較して問題箇所を特定する
という手順が必要で、根本原因の特定と改善には数週間かかっていました。
しかしDatadogが導入されていたおかげで、問題を即座に把握することができました。 さらに、パフォーマンス問題のあるコード箇所まで紐付けて表示してくれる機能により、日頃スピフルの開発をしていないSREでもコードを特定し、開発者に的確に共有できました。
翌日には該当箇所を修正し、問題を解消できたことが印象的です。
導入時の苦労・悩み
従量課金ゆえ、社内稟議に提出する際のコスト見積もりに苦労しました。 使い方によってコストが変動するため、事前に正確な試算を出すことが難しかったからです。
ただし、Datadogの担当者に伴奏いただき、検証環境で一定期間実際に使用した実績データをもとに、担当者と一緒にコストを算定することができ、社内稟議を通すことができました。
導入に向けた社内への説明
上長・チームへの説明
主に以下の3点を説明材料にしました。
- 従量課金による全員アクセス: アカウント数の制限がなく、経営層含む全員がプロダクト状況を把握できる体制を作れること
- AI機能による生産性向上: 開発生産性を高めながら事業貢献を最大化するというプログリットの方針との整合性
- S&P 500選定という実績: エンジニアだけでなく、市場が認めているという客観的な根拠
活用方法
よく使う機能
| 機能 | 用途 |
|---|---|
| APM | トレース追跡・ボトルネック特定・コードとのひも付け |
| Logs | ログ検索・APMトレースとの連携 |
| Dashboard | プロダクト状態の定常的な可視化 |
| Monitors | 閾値アラート・インシデント検知 |
ツールの良い点
- APMとコードの紐付け: パフォーマンス問題のあるコード箇所まで特定できる。プロダクト開発に詳しくないインフラエンジニアでも、開発者に的確なレポートを渡せる
- 全体の可視化: 断片的な情報ではなく、システム全体を俯瞰できる
- 視覚的な把握: ダッシュボードで誰でも状況を直感的に理解できる
- AI機能(Bits AI): エージェンティックAIによるインシデント対応・パフォーマンス調査の支援
- サポート体制: 日本担当者が伴走してくれるため、導入・運用のハードルが下がる
ツールの課題点
学習コストが一定かかることが課題です。機能が豊富なため、使いこなすまでに時間を要します。
ただし、最近DatadogよりMCP(Model Context Protocol)が提供されました。 これにより、開発者が普段使っているClaude CodeやCursor経由で対話形式のパフォーマンス調査・障害調査が実現できるようになっていきます。 よって、学習コストの課題は今後改善されると期待しています。
ツールを検討されている方へ
ツール導入はあくまで手段であり、「なぜ導入するのか」という目的を常に念頭に置くことが重要です。
Datadogを検討する際は、以下の点を確認することをお勧めします。
- 料金体系の選択: 開発メンバーの全員にアカウントを配布したいなら従量課金が適している。大企業でコスト管理を一元化したいならユーザーベースも選択肢になります
- コスト試算: 従量課金の場合、見積もりが難しい。Datadogの担当者に相談し、検証環境で実績を取ってから算定することをお勧めします
- 段階的な導入: いきなり全プロダクトに展開するのではなく、1プロダクトから先行導入して効果を実感してから横展開する方がスムーズです
今後の展望
全プロダクトへの展開
現在は3つのプロダクトでDatadogを導入済みです。今後は全プロダクトへの展開を計画しています。
SLOとエラーバジェットの啓蒙
エンジニアは体感的に「最近障害が多い」「パフォーマンスに問題がある」と判断できますが、ビジネスサイドにとっては深刻度の判断が難しいという情報の非対称性があります。SLO(Service Level Objective)とエラーバジェットを設定・運用することで、この問題を解消します。
- SLO違反の可視化: エンジニア以外でも問題の深刻度を理解できる
- 開発の優先順位判断: エラーバジェットの消費状況から、新機能開発継続か品質改善優先かを判断できる
最終的なゴール
売上・有料会員数・解約率などのビジネスデータと並べて、SLOやエラーバジェットをボードメンバーも確認できる体制を構築したいと考えています。
エンジニアでなくても、プロダクトの健全性を定量的に把握できるようにすることが、最終的な目標です。

株式会社プログリット / inady
テックリード / テックリード / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
プログリットでインフラテックリード、AI活用推進などをやっているinadyと申します。
よく見られているレビュー

株式会社プログリット / inady
テックリード / テックリード / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
プログリットでインフラテックリード、AI...


