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

ツール導入前の課題

プログリットは創業以来、本格的なObservabilityツールを導入していませんでした。当時使用していたツールは以下の3つです。

• AWS CloudWatch Logs: ログ管理（検索性が低く、使い方に精通していないと使いにくい）
• CloudWatch Alarms: アラート設定
• Sentry: エラー通知（モバイル・フロントエンドには強いが、バックエンドのパフォーマンス分析には弱い）

プロダクト規模が小さく、開発メンバーが数十人規模であった頃は、"あうんの呼吸"で運用できていました。 しかし、プロダクト数が1つから4つに増え、チーム規模も拡大。この状況ではさすがに限界が見え始め、何らかのObservabilityツールを導入しなければ運用が破綻し、可用性・保守性・パフォーマンスの問題が顕在化することは明らかでした。

具体的な課題として、プロダクトの1つであるスピフルではパフォーマンスや可用性の問題が時折発生していました。

しかし全体像を可視化する手段がないため、ログに実行時間を手動で出力したり、コードを読んでボトルネックを推定したりと、実測値に基づかない手探りの改善を続けていました。

このような状況を放置すれば、いつか新機能開発がほとんどできず、障害対応に追われる状態になると判断しました。

• Datadog（採用）
• New Relic

1. 料金体系: ユーザーベース課金か従量課金か
2. AI機能の充実度: 今後のエンジニア生産性向上につながるか
3. 日本でのサポート体制: 日本語サポート・コミュニティの有無
4. 信頼性・実績: 市場やビジネスサイドへの説明のしやすさ

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のパフォーマンス劣化がトリガーでした。

以前の調査手順では、

1. ログに実行時間を出力するコードを追加
2. 次のリリースを待つ
3. 再度障害が発生するのを待つ
4. ログを比較して問題箇所を特定する

という手順が必要で、根本原因の特定と改善には数週間かかっていました。

しかしDatadogが導入されていたおかげで、問題を即座に把握することができました。 さらに、パフォーマンス問題のあるコード箇所まで紐付けて表示してくれる機能により、日頃スピフルの開発をしていないSREでもコードを特定し、開発者に的確に共有できました。

翌日には該当箇所を修正し、問題を解消できたことが印象的です。

従量課金ゆえ、社内稟議に提出する際のコスト見積もりに苦労しました。 使い方によってコストが変動するため、事前に正確な試算を出すことが難しかったからです。

ただし、Datadogの担当者に伴奏いただき、検証環境で一定期間実際に使用した実績データをもとに、担当者と一緒にコストを算定することができ、社内稟議を通すことができました。

ツール導入はあくまで手段であり、「なぜ導入するのか」という目的を常に念頭に置くことが重要です。

Datadogを検討する際は、以下の点を確認することをお勧めします。

• 料金体系の選択: 開発メンバーの全員にアカウントを配布したいなら従量課金が適している。大企業でコスト管理を一元化したいならユーザーベースも選択肢になります
• コスト試算: 従量課金の場合、見積もりが難しい。Datadogの担当者に相談し、検証環境で実績を取ってから算定することをお勧めします
• 段階的な導入: いきなり全プロダクトに展開するのではなく、1プロダクトから先行導入して効果を実感してから横展開する方がスムーズです

全プロダクトへの展開

現在は3つのプロダクトでDatadogを導入済みです。今後は全プロダクトへの展開を計画しています。

SLOとエラーバジェットの啓蒙

エンジニアは体感的に「最近障害が多い」「パフォーマンスに問題がある」と判断できますが、ビジネスサイドにとっては深刻度の判断が難しいという情報の非対称性があります。SLO（Service Level Objective）とエラーバジェットを設定・運用することで、この問題を解消します。

• SLO違反の可視化: エンジニア以外でも問題の深刻度を理解できる
• 開発の優先順位判断: エラーバジェットの消費状況から、新機能開発継続か品質改善優先かを判断できる

最終的なゴール

売上・有料会員数・解約率などのビジネスデータと並べて、SLOやエラーバジェットをボードメンバーも確認できる体制を構築したいと考えています。

エンジニアでなくても、プロダクトの健全性を定量的に把握できるようにすることが、最終的な目標です。