DevOpsDaysTokyo2025にオンラインで参加しました！

はじめに

こんにちは、まさき。です。
NE株式会社がスポンサーしていたのもあり、DevOpsDaysTokyo 2025 にオンラインで参加させていただきました。

以前から DevOpsというキーワードを耳にはしていたものの、具体的に何をすることなのかをわかってなかったなーというのと、どんな活動がDevOpsで、弊社ではどのくらいできてるんだろう？を知りたかったので参加しました。

DevOpsDaysTokyo 2025 とは？

DevOpsDaysTokyo 2025

DevOpsDays は世界中で開催されているカンファレンスです。ソフトウェア開発、ITインフラ運用、そしてその境界線上にあるトピックをカバーし、特にDevOpsを実現するための自動化、テスト、セキュリティ、組織文化にフォーカスします。

弊社も協賛したのでロゴの写真

発表に対しての感想

• はてなの開発20年史とDevOpsの歩み

  • 株式会社はてな は、かなり初期の頃からDevOpsを実践してきたんだなーというのと、最先端を行ってるんだなという感想を抱きました。
  • 実施している「障害ふりかえり」が、弊社でアプリケーションエンジニアとインフラエンジニアが共同で開催している「アプリケーションパフォーマンス定点観測会」そのもので、やはりできているものもあるんだな、と思いました。

• システムとの会話から生まれる先手のDevOps

  • AI在庫管理の運用の話を中心に、本番環境で動いているシステムからのアラートやログなどとの向き合い方の話でした。
  • インシデントレベルを定義して小さなインシデントが大きなインシデントを引き起こす前に対応しやすくしているのが印象的でした。
  • さらにそのインシデントの検知プロセスそのものも改善ループを回しているのがすごいなと思いました。
  • SLOが決まっているとエンジニア以外の人も含めて優先順位の判断ができるのはいいなと思うのと同時に、SLOがないということはこの判断の機会を失っているのかもしれないとも思いました。
  • システムの安定稼働を維持する守りのSLOだけでなく、より良くする攻めのSLOを制定しているのも個人的にはいいなと思いました。

• 運用できる開発組織の作り方 ― kintone開発組織のストーリー

  • 開発チームがモニタリング・アラートを設定して自分たちで運用しているのがいいなと思いました。
  • 障害対応のロールプレイをやっているそうで、弊社のネクストエンジンでも避難訓練という名前で誰でもメンテナンスモードに切り替えるというロールプレイをやったことがあったなーと思い出しました。

• Jun Haeng Hur - CI/CDの成功の指標になる4つのKeyメトリクス

  • CICDを提供するCircle CI さんの発表。実際に4Keysを取得して、視覚的に説明してくださいました。
  • パイプラインがうまく行っていることを判断するには、ビジネスや文化などによって全然状況が異なるので自分たちで基準値を設定しないといけないようで、ここでも運用が必要なんだなと思いました。

• サービスレベルを管理してアジャイルを加速しよう！ ~ スクラムへのSRE導入術 ~

  • 信頼性に過剰に投資しても、投資しなさすぎても市場では選ばれない、という話があり、結局はユーザーが求める基準を達成できているのかが大事なんだろうなと思いました。
  • こちらでも「アプリケーションパフォーマンス定点観測会」の話をしていて、直近でスロークエリの改修をしたときに、それをどうやってチームのタスクにするのかが難しかったなーということを思い出していました。

• AI駆動開発実践！ AI駆動で始めるアプリケーション開発

  • AI駆動開発の話だった。実際に bolt.new でのアプリケーション構築のデモを見せてもらい、可能性を感じました。
  • ビジネスロジックの実装は難しいみたいです。

• AIと開発者の共創: エージェント時代におけるAIフレンドリーなDevOpsの実践

  • AIエージェントの実運用での話でした。
  • AIが生成するコード品質への信頼性はあまり高くなかったり、差分が大きくなってしまったりで、パフォーマンスの低下もあるようでした。
  • ノイズになってしまうので、AIのためにもコードベースのデッドコードは消してあげた方がいいんだなーとも思いました。
  • MCPの活用もAIを活かすためのキーになりそうだなと思いました。

全体的な感想

今回のDevOpsDaysTokyo 2025を通じて、DevOpsが単なる技術的な取り組みではなく、組織文化や開発と運用の連携を重視する包括的なアプローチであることを実感しました。特に印象的だったのは以下の点です：

• 観測可能性の重要性: 多くの発表で、システムの状態を可視化し、適切なメトリクスを測定することの重要性が強調されていました。SLOの設定やインシデントレベルの定義など、「測定できないものは改善できない」という考え方が共通していました。

• 開発と運用の境界線の曖昧化: 開発チームが運用にも関わり、運用チームが開発初期から参画するという流れが一般的になっています。この協力関係が、より良いシステム設計と迅速な障害対応を可能にしています。

• AIの活用と課題: AIを開発・運用プロセスに統合する試みが増えていますが、まだ課題も多くあります。特にAIが生成するコードの品質や、AIと人間のコラボレーション方法については、まだ発展途上の段階であることがわかりました。

• 継続的な改善文化: 障害対応や運用プロセス自体を継続的に改善していくという文化が、成功している組織には共通していました。単に問題を解決するだけでなく、なぜその問題が発生したのか、どうすれば再発を防げるのかを考える姿勢が重要です。

会社で活かせそうなこと

今回の学びを踏まえて、自社で取り入れたい、または強化したいDevOpsの取り組みとして以下が考えられます：

1. SLOの設定と活用: ユーザー体験に直結する重要なメトリクスを特定し、SLO（Service Level Objectives）として明文化することで、チーム全体が目標を共有できるようにする。また、「守りのSLO」だけでなく「攻めのSLO」も設定して、システムの継続的な改善を促進する。

2. インシデント対応プロセスの強化: インシデントのレベル分けを明確にし、小さなインシデントも記録・分析することで、大きな障害の前兆を捉える仕組みを作る。また、定期的な障害対応訓練を実施して、チームの対応力を高める。

3. 4Keysメトリクスの導入: デプロイ頻度、リードタイム、変更失敗率、復旧時間という4つのキーメトリクスを測定し、開発プロセスの健全性を定量的に評価する仕組みを導入する。

4. AIツールの実験的導入: コード生成やレビュー支援などで、AIツールを実験的に導入し、どのような場面で効果的に活用できるかを探る。その際、AIの出力に対する適切なレビュープロセスも確立する。

5. クロスファンクショナルな振り返り: 現在実施している「アプリケーションパフォーマンス定点観測会」をさらに発展させ、開発・運用・ビジネス部門も含めた振り返りの場として活用する。

まとめ

DevOpsDaysTokyo 2025への参加を通じて、DevOpsの本質は技術だけでなく、組織文化や協働のあり方にあることを再認識しました。自社でも既に実践できている部分はありますが、まだまだ改善の余地があることも明らかになりました。

特に印象的だったのは、「システムとの対話」という考え方です。システムが発するシグナル（ログ、メトリクス、アラートなど）を適切に解釈し、それに基づいて先手を打つDevOpsのアプローチは、システムの安定性向上だけでなく、開発者の負担軽減にもつながります。

また、AIの活用については、まだ発展途上ながらも大きな可能性を感じました。ただし、AIを闇雲に導入するのではなく、人間とAIの協働方法や、AIが効果的に機能する環境作りも重要であることがわかりました。

今後は、今回の学びを自社の開発・運用プロセスに取り入れながら、少しずつDevOpsの実践を深めていきたいと思います。DevOpsは一朝一夕に実現するものではなく、継続的な改善の積み重ねが重要であることを肝に銘じて取り組んでいきます。