こんにちは！RSSでバックエンドの開発を行っているM.K.です。
今回は、Datadog Summit Tokyoに参加してきたので、「開発者の生産性向上」セッションの内容と感想をお伝えします。最近、社内でDatadogを導入し始めましたが、これをうまく活用することで開発者としての生産性を向上させることができるのではないかと考えています。そんな中、Datadogに関連するサミットの案内が届き、これはまさに私にぴったりのテーマだと思い、参加を決めました。
Datadogとは?
Datadog はクラウド アプリケーションのための モニタリングとセキュリティ プラットフォームです。Datadog の SaaS プラットフォームは、インフラストラクチャ監視、 アプリケーションパフォーマンス監視、ログ管理を統合および自動化して、お客様のテクノロジースタック全体を一元的にリアルタイムで監視できるようにします。
(公式HPから引用：https://www.datadoghq.com/ja/)
弊社では元々、別の監視ツールを使用していましたが、有効活用できていなかったため、Datadogへ切り替えることにしました。
徐々に各システムへのDatadog導入が進んでおり、現在は対象システムの4割が導入済みの状況です。
セッション登壇者
萩野 たいじ さん
Datadog シニア デベロッパー アドボケイト
小田中 育生 さん
Kakehashi エンジニアリングマネージャー
立石 智也 さん
Bic Camera 情報システム部 システム開発室 課長
市古 空 さん
Wantedly Platform & Enabling（開発生産性改善）チーム リーダー / DevOps推進チーム リーダー
小田中さんは、ベルギーで開催されたDevopsdays 15 Year Anniversaryで登壇した際の内容が評価され、今回のサミットにお声がかかったそうです。
セッション動画
Youtubeに当日のセッションの録画が共有されています。
Datadog Summit Tokyo お客様パネルセッション: 信頼性向上の実践
開発生産性を向上させるために、どのようにDatadogを活用しているか？
小田中さん（カケハシ）：
「ふみぱお」というMTGでDatadogを活用している。
週次でSLOを確認したり、RUM( Datadogの機能の一つ リアルユーザーモニタリング)でユーザーのパフォーマンスに異常がないか確認したりする。
エンジニア以外もダッシュボードを基に話ができる点が良い。
高速にDevOpsを回せる理由の一つは、この環境が作れていること。
Q. 一定の学習コストがかかる中で、どのようにPDM（非エンジニア）までDatadogを浸透させて、使えるレベルまで引き上げたのか？
A. オンボーディング担当を置いているわけではない。
カケハシは、（DevOpsのカルチャー醸成も含めて）モブプログラミング主体でやっている。
フルリモートのため、slack のハドルミーティングを使用している。
ハドルだと、誰が入っているか見える。
かつ、「いつ入ってきてもいいよ」という雰囲気を作っているので、興味もったPDMがふらっと入ってきてくれる時がある。
そうなると、しめしめと思いながら「ちょっと触ってみない？」と声を掛ける。
最初は、「いやいや、触ったこと無いので……」と言うが、触ってもらうと「意外とできるな」という体感を持ってもらえる。
「ドアを開けておいて、誰でも入っておけるようにしておく」というカルチャーが結果的に、エンジニアと非エンジニアであるPDMの垣根を超えて、協働する流れになった。
メンバーごとにロールを置くことも推進するうえで大事かもしれないが、まずは皆で一つのゴールに向かっていくというカルチャーを作っていくことがポイント。
立石さん（Bic Camera）：
Datadogを導入して、まだ9ヶ月ほどしか経過していない。
インフラチームが統合基盤的な監視ツールを入れようとしている。
アプリ側にオブザーバビリティを入れたいと思っており、インフラチームが検討していたツールでそれを実現することが可能とのことで、導入を決めた。
障害が発生したら、githubと連携しているので、ここの行でエラーが出ているということが分かり、数クリックすれば開発環境で再現できる。
その場で改修してcommitしてpushができる。
開発者体験（Developer Experience）として良くなった。
※おそらくこの機能を使用
ソースコードインテグレーション
Q.Bic Cameraさんだと規模が大きいと思うが、運用面で工夫していることは？
A.同時に約1万人の方がスマホからアクセスすることがある。
そのままユーザーのRUMのデータを取ってくると、それだけでネットワークがパンクしてしまう。
サンプリングした店舗にのみRUMを導入して、できるだけ全体を把握しつつ、ネットワークやシステムに影響しないよう工夫している。
市古さん（Wantedly）：
オブザーバビリティを入れたことにより、機能横断的で、影響範囲が読みにくいような変更（ライブラリのアップデート・リファクタなど）があった際でも「適切なリスクを取る」ことが可能になった。レビュー・承認プロセスが減少したことで、結果的に開発が加速した。
小田中さん所感
エンジニアは全部良くしたくなっちゃう。
ユーザー目線でのSLOを考えないといけない。
例えば、ユーザーが使っているところで、かつ遅いところを優先度上げてチューニングし、1ヶ月に1回の使用頻度かつ、そのレイテンシーをユーザーが許容している箇所は優先度を下げる。
RUMを駆使すればユーザーが使用している箇所が客観的に見えて、取捨選択ができるようになるので、それだけで価値がある、
開発やステージングではなく、本番から得られるFBは全然違う。
「開発生産性が高い」の定義をどう考えているか？
市古さん（Wantedly）：
定義、解釈が大事
定義：
・市場投入をいかに早めるか（市場投入までの期間を完璧でなくていいので手作業でも測ってみる）
・アクシデントに強くなれるか（インシデント、爆弾（EOL切れ、脆弱性など）の数、復旧時間）
立石さん（Bic Camera）：
開発生産性を可視化しているわけではない。
コードのpush量でも測ろうと思ってない。
毎回、費用対効果の出し方も見直しをしている。
「ユーザー側にどう影響するか」、「ほんとに良くなったんだっけ？」を考えることが大事。
小田中さん（カケハシ）：
「four keys」は良くできた指標。
デプロイ数を単純に増やせば、インシデントも増加する。
リリースごとの失敗率など、いい感じに対抗軸があるものを4つ並べている。
その4指標をバランス良く上げていくことで、組織のアウトカムも良くなっていく。
開発生産性指標「SPACE」だと、アウトカムの方にも着目している。
また、開発生産性が上がったが「蓋を開けてみるとエンジニアが軒並み徹夜してます」だと、長続きしないのでWell-beingの指標も大事。
「four keys」を軸にしながら、Well-beingの指標と、しっかりアウトカムになっているかも合わせて追っていく。
気をつけていることは「数字を目的化しない」
「価値を提供したいお客さんにとって大事なのはなんだろう？」を考える。
2週間に1回のアップデートでもいいなら、開発速度ではなく、別のところを上げることを考える。
今、向き合っている課題に効く指標はなんだろう？と考えることが良い。
測った数字に一喜一憂しない。
セッションまとめ
Datadogを使って、オブザーバビリティを向上させることで、3社とも結果的に開発生産性が向上した。
ただし、オブザーバビリティの向上はあくまで手段で、目的・課題が大事。
所感
Bic cameraさんがやっているソースコードインテグレーションを真似たいと思いましたが、GitLabのself-managedを使っている弊社では簡単に導入とはいかないようです(ソースコードインテグレーション ドキュメント)。
しかし、単なるエラーのトラッキングツールで終わらせず、目的や課題に対して他に活用できる方法を模索する余地はまだまだあると感じました。
また、開発生産性の定義のお話の中でも小田中さんがお話しされていたことに共感しました。
特に「four keys」の対抗軸のお話に関して、弊社内では「どちらかを上げればどちらかが下がるシーソーだと考えるのではなく、支点を上げるためにはどうしたら良いかという観点でも考えてみると良い」と言われることがあります。
その話に加えて、「開発生産性を測る指標にこだわりすぎて本質を見失い、ユーザーから『あの開発チームに頼んだときに出てくるものって、いまいちイケてないよね』と言われてしまう状態にならないように」という言葉は心に留めておきたいと思います。
余談
飲み物だけでなく、お昼にはお弁当、懇親会にはケイタリングが用意されていました。
また、お土産に小物ケースとTシャツもいただきました。
Datadogさん、ありがとうございました。
（唯一、撮っていたのは、お弁当の写真だけでした‥笑）
おわりに
最後まで読んでくださってありがとうございました。
単なる製品の活用事例で終わらずに、開発全体まで話が広がったセッションでした。
エンジニアとしてやってみたいことがたくさん出てきましたが、何をするにしても「目的に立ち返ることを忘れずに」と心に決めた1時間になりました。
これからもRSSのメンバーがブログを投稿していきます。
レイスシステムソリューションズ株式会社のソフトウェア開発や、
採用に関するお問い合わせについては、下記のリンクにてお問い合わせください。