【イベントレポート】Day1～DevOpsの世界へ～【DevOpsDaysTokyo2025】

皆さんこんにちは。
SB C&Sの近藤です。
本日は先日開催されました「DevOpsDays Tokyo 2025」のイベントレポートになります。
この記事では主に1日目に行われたセッションのご紹介と感想を書かせていただきます。
2日目のレポートについては、別ブログで書かせていただいております！
是非併せてご覧ください。

※イベントスケジュールはこちら

DevOps Days Tokyo2025開催概要

2025年4月15日～17日、大崎ブライトコアホールおよびオンラインのハイブリッド形式で開催された「DevOpsDays Tokyo 2025」に参加してきました。
DevOps Daysは世界各地で開催されているコミュニティ主導のカンファレンスです。
ソフトウェア開発、ITインフラ運用、組織文化などDevOpsに関わる幅広いトピックを扱い、事例を交えながら情報共有が行われます。
2025年の東京開催では、国内外の先進事例や最新プラクティスが多数紹介され、3日間で40名以上のスピーカーによる多彩なセッションが行われました。
現地・オンラインのハイブリッド開催で、全国・海外からも多くの参加者が参加されていました。
参加者の中には、北海道や沖縄など国内だけでなく、アメリカやカナダといった海外からも参加していました。

イベント参加者は、DevOpsにこれから取り組もうとしている方からAIによる社内活用、顧客提案のヒントを得たい方など、現場で求められる技術や組織変革の最新動向の情報収集まで。多岐に渡って色々なテーマを持って参加されていました。
一番の注目はAI技術でしたが、DevOpsの自動化、テスト、セキュリティ、組織改善など、現場で役立つ具体的なプラクティスやツールの情報、国内外のエキスパートによる実践知見、交流会まで多くのコンテンツが詰まったイベントとなっていました。

〜DevOps Days Tokyo2025 Day1基調講演〜

基調講演①：Keynote Session：はてなの開発20年史とDevOpsの歩み

株式会社はてな の、エンジニアリングマネージャーの粕谷さんの基調講演では、株式会社はてなの創業から現在までの技術・組織の変遷を振り返りながら、DevOps導入の歴史を語りました。

【講演内容 概要】

・創業からの変化とDevOps導入の背景

・アジャイル開発を早くから取り入れ、「変な会社」カルチャーを大切にしつつ、独自の開発スタンダードやツールを整備。
・自社サービス「スカウター」開発や、インフラ部門と開発部門の協力体制など、現場のリアルな課題解決を重視。
・SRE体制の構築やプロダクトオーナーシップの強化など、組織の進化を続けてきた。

・DevOpsの歴史と組織の変遷

・組織の成長とともに、現場で直面する課題（組織の壁・文化の違い・技術の進化）に合わせて柔軟に体制を変化。
・DevOpsの考え方を取り入れることで、開発と運用の垣根をなくし、スピード感あるサービス開発を実現。

・今後に向けて

・AI技術の台頭など、技術トレンドの変化にも柔軟に対応し続けることが重要。
・外部の知見も積極的に取り入れながら、今後も日本企業にとって大切なテーマである「変化への適応力」を高めていく必要があるとまとめられました。

・感想

株式会社はてなの20年にわたる開発とDevOpsの歩みを振り返るセッションで、特に印象的だったのは、単に技術やツールを導入するだけでなく、「変な会社」という独自のカルチャーや現場の課題解決を大切にしながら、柔軟に組織や開発体制を進化させてきた点です。
また、今後成長し続けるAI時代において技術だけでなく、組織文化や人の成長、マインドも大切であることを感じさせるセッションでした。

〜DevOps Days 東京2025 Day1セッション〜

セッション②：ソフトウェア現代史：Lean とDevOpsの科学の「科学」って何か？-DORA Report 10年の横断監視得て-

ファインディ株式会社の高橋さんのセッションのレポートです。ソフトウェアの約50年間の歴史を振り返り、現代にどのように繋がっているのかを考えていくセッションです。

【講演内容 概要】

・日本のソフトウェア開発の現状と課題意識

・日本はかつて製造業が強かったが、ソフトウェア分野では世界に遅れを取っている現状がある。
・ソフトウェア開発における価値観や歴史を振り返り、現状を打破したいという思いから講演を企画。

 ・DORAレポートと「Accelerate」本の紹介

・DORAレポートは、ソフトウェア開発組織のパフォーマンスを科学的に分析し、10年以上にわたり進化してきた。
・「Accelerate」では、開発速度と安定性はトレードオフではなく、両立できることを科学的に示した。
・代表的な8つの知見（4つの指標、CDの効果、アーキテクチャの重要性、リーン原則、組織文化、ケイパビリティモデル、燃え尽き症候群との関係など）を紹介。

 ・「科学的アプローチ」とは何か

・科学とは「思考の方法」であり、知識の集積ではない。（現象を観察し、概念化し、測定可能な変数を導き出すこと。）
・従来の「バグ曲線」などの品質管理手法は、科学的モデルまで到達していなかったと指摘。
・DORAレポートは、観察からモデル化までを行い、ソフトウェア開発を科学的に進化させた点が画期的。

 ・最新のトピック

・ユーザー中心の開発や質の高いドキュメントの重要性。
・AIの導入が現場に浸透しつつも、生産性や個人の負担とのバランスに課題があること。
・DORAは今後もAIと開発現場の関係を継続的に調査していくと発表。

 ・感想

今回のセッションでは、単なるDORAレポートの解説にとどまらず、日本のソフトウェア開発の歴史や課題、そして「科学的アプローチ」についての内容でした。
印象的だったのは、「科学とは知識の集積ではなく、思考の方法である」というメッセージです。DORAレポートが単なるアンケート調査ではなく、観察・概念化・モデル化という科学的プロセスを経ている点は、今後の開発組織のあり方を考える上で参考になると思いました。
また、AIの導入が進む中で、単純な生産性向上だけでなく、現場の負担や働き方の変化にも目を向けている点も現実的でした。これからは、ますますDORAレポートの知見を自分たちの現場でどう活かすか、実験と仮説検証を繰り返す姿勢が求められていると感じました。

セッション③：システムとの会話から生まれる先手のDevOps

 株式会社カケハシの松本さんのセッションにレポートです。
主に、医薬品やサプライチェーンの新規事業を手がけるヘルステックスタートアップ「カケハシ」社内での、AI在庫管理プロダクト開発チームの取り組みと、その中でのフィードバックループの強化・改善について講演されました。

【講演内容 概要】

・チーム・プロダクト紹介

・カケハシ社は「日本の医療体験を、しなやかに。」というミッションのもと、調剤薬局や患者さんをつなぐサービスを展開。
・AI在庫管理は、機械学習を用いて薬局の在庫を最適化し、欠品や過剰在庫を防ぐプロダクト。
・開発チームはスクラムで1週間スプリントを回し、小さくリリースしながら高速な仮説検証を重視している。

・大手法人導入プロジェクトでの課題

・プロダクトの規模拡大に伴い、エンタープライズ向けの新機能開発や、既存システムからのデータ移行、サポート体制の見直しなど、やることが急増。
・その最中、インシデント（サービス中断や品質低下）の対応が増え、日々の開発や運用に支障が出始めた。

 ・インシデント対応と品質向上の取り組み

・インシデントをレベル0～5で定義し、小さな問題も積極的に報告・改善する文化を醸成。
・過去インシデントを分析し、リスクアセスメントで優先度を決めて対策。結果、インシデント発生頻度を1/3に減少、夜間オンコールも激減。
・品質・信頼性向上のための「しゃがむ（開発速度を落としてでも品質に集中）」期間を設けた。

・規模拡大による新たな課題と運用改善

・大量店舗同時導入で、インフラコストやDB負荷が急増。これまでのモニタリング粒度では変化に気づきにくかった。
・チームに「余白」を設ける（スプリントの最終日は開発を止めて改善にあてる等）、レビュー負荷軽減のためのルール整備、レビューなしマージの導入など、柔軟な運用改善を実施。

・SLO（サービスレベル目標）の導入

・SLOを設定し、パフォーマンスや信頼性の目標値を明確化。エンジニア以外も巻き込んだ運用を目指す。
・SLOを「守り」と「攻め」の2段階で設定し、安定稼働とユーザー体験向上の両立を狙う。

・感想

今回のセッションは、スタートアップからエンタープライズへとスケールする過程で、開発・運用チームが直面する「成長痛」と、それにどう立ち向かったかが非常にリアルについて多く語られました。
特に印象的だったのは、「品質向上のためにあえて開発速度を落とす（しゃがむ）」という意思決定と、その説明責任をどう果たすかという部分です。
現場のエンジニアがPDMや経営層と対等に話し合い、必要な余白を確保する姿勢は、今後の組織づくりにも参考になると感じました。「余白を作ることの全社的理解」の大切さも感じることができました。
また、SLOの導入で「守り」と「攻め」を明確に分け、全員で主体的にシステムを良くしていこうという文化づくりも素晴らしいです。単に数値を追うだけでなく、エンジニアが自発的に改善提案できる仕組みや余裕を作ることが、長期的なプロダクト成長には不可欠だと改めて感じました。

セッション④：カジュアルに始めるDevSecOps　

Inedoの早滝さんのセッションレポートです。
主にOSS（オープンソースソフトウェア）の脆弱性管理や、ソフトウェアサプライチェーンセキュリティの重要性について解説されました。早滝さんは海外IT企業の日本展開を支援してきたマーケティング担当者で、アメリカと日本のIT事情の違いにも触れつつ、現実的なセキュリティ導入の方法を提案しました。

【講演内容 概要】

・OSSの利用と脆弱性管理の現状

・アメリカのIT企業では、ソフトウェアの99%がOSSで構成されており、そのうち約70%に脆弱性が含まれる可能性があると指摘。
・パッケージ管理では、1つのライブラリ導入で数十の依存関係が発生し、管理が非常に複雑になる。

・セキュリティ対策の課題

・「セキュリティは文化」「セキュリティバイデザインを全社標準に」などの理想論は現場では実現が難しい。
・開発・運用・セキュリティを一体化したDevOpsカルチャーの構築も、現実には「無理難題」と感じている企業が多い。

・脆弱性診断ツールの特徴

・SAST、DAST、SCA（ソフトウェア構成分析）それぞれに長所・短所があり、単体では不十分。
・これらを組み合わせて使うのが理想だが、コストや運用負荷が大きく、経営層の理解も得にくい。

 ・現実的なセキュリティ導入策

・「カジュアルなセキュリティ」として、まずは部品（OSSパッケージ）の検品から始めることを提案。
・SCAツールで既知の脆弱性やライセンス問題を自動スキャンし、管理者が偽物やリスクのあるパッケージを排除する。
・検品済みのパッケージのみを承認リポジトリに登録し、開発者はそこから利用する仕組みを推奨。

・ ProGetによる具体的な運用例

・OSSやライブラリ、Dockerコンテナなどの部品を一元管理・配布できる。
・コーディング前の段階で脆弱性をトリアージでき、シフトレフト（早期対策）が可能。
・導入コストは20万円ほどで、小規模から始めて拡張できる。

・ソフトウェアサプライチェーンセキュリティの重要性

・近年、ソフトウェアも自動車などの製造業と同じように「部品のトレーサビリティ（追跡可能性）」が求められている。
・OSSの利用比率が高まる中、どの部品（パッケージ）がどこで使われているかを把握し、問題発生時に迅速に対応できる体制が必要。

・感想

このセッションは、理想論に走りがちなセキュリティ議論に対し、「現場でできることから始めよう」という現実的な視点が印象的でした。特に、OSSの利用が当たり前になった今、部品の「検品」や「承認プロセス」を導入することで、無理なくセキュリティレベルを上げられるという提案は、多くの企業にとって参考になるはずです。
また、ソフトウェアサプライチェーンという考え方は、今後ますます重要になるテーマです。製造業のように「どの部品がどこで使われているか」を把握し、問題発生時に迅速にリコールや対策ができる体制づくりは、IT業界でも必須となってくると感じました。

セッション⑤：社内副業で他部門へ「越境」として見えた価値再定義──最大1か月のリードタイムを10分に短縮したDevOps実践

株式会社デンソーの富田さんが社内副業制度を活用し、他部門の業務改善に取り組んだ事例を紹介します。最大1ヶ月かかっていたリードタイムを10分に短縮したプロセスや工夫、そして得られた学びについてまとめます。

【講演内容 概要】

・取り組みの背景ときっかけ

・社内でクラウド課題解決のための部署横断コミュニティが発足。
・AWS活用やセキュリティガイドライン整備、コスト最適化などで成果を上げていたが、プロダクト開発の進め方やエンジニアチームの作り方について課題が浮上。
・社内副業制度（越境チャレンジ）が解禁され、他部門プロジェクトへの参画が可能に。

・プロジェクトの現状と課題

・自治体向けSaaSでは、設定変更やリリース作業に最大1ヶ月以上かかっていた。
・外部委託が中心で、社内エンジニア不在のため、依頼から実作業までのプロセスが煩雑かつ非効率。
・新規ウェブアプリ開発を検討したが、既存システムとの連携や業務フローの全体像が不明瞭だった。

・解決へのアプローチ

1. システムコンテキスト図の作成
関係者やシステムの範囲を可視化し、曖昧だった連携や役割分担を明確化。

2. デモとフィードバックの導入
スプリントを重ねてもフィードバックが得られていなかったため、定期的なデモを実施し、ユーザーや関係者からの意見を取り入れる仕組みを構築。

3. 業務フローの全体最適化
バリューストリームマップを用いて、作業時間・待ち時間・リードタイム・手戻り率を可視化。営業やエンジニアなど全員で現状のプロセスを共有し、ボトルネックや無駄な工程を特定。

4. プロダクト価値の再定義
単なるウェブツール化では利用者の負担が増えるだけと判断し、業務全体の最適化を目指してスコープを拡大。不要な工程の削除や自動化、シンプルな運用体制を実現。

5. シンプルなソリューションの導入
Googleフォームやサーバーレス構成を活用し、エンジニア不在でも維持しやすい仕組みに。依頼内容に応じた手順書を作成し、誰でも簡単に対応できるよう工夫。

6. 成果と学び
・リードタイムが1ヶ月から10分に大幅短縮。手戻りや待機時間も劇的に減少。
・バリューストリームマップによる可視化で、関係者全員がプロセス全体を理解し、共通認識を持てた。
・「知っている」から「できる」へのギャップを埋めるためには、実践を通じた学びやエンジニアリングカルチャーの醸成が重要であると実感。

・感想

このプロジェクトは、単なるシステム開発やツール導入にとどまらず、「業務全体の流れを見直す」ことの重要性を講演されていました。現場の声や実際の業務フローを丁寧に可視化し、関係者全員で課題を共有することで、本当に価値のある改善策を生み出せると感じました。
また、「知っている」だけでは業務改善は進まず、実際に手を動かして「できる」に変えるプロセスが不可欠であることも印象的でした。副業制度や越境チャレンジのような柔軟な人材活用が、組織のイノベーションや成長につながる事例だと思います。
全体最適の視点やプロセスの可視化、実践を通じた学びの大切さを改めて実感させられるセッションでした。

〜ネットワーキングパーティー〜

Day1セッション終了後には参加者同士のネットワーキングが開催されました。
色々とお話を伺いましたが、やはり話題がAIになることが多く、AIの注目度の高さを感じることができました。
どの方も口を揃えて「今年1年のAIの成長が凄まじい」とおっしゃっており、特にコード生成AIの精度が高く「AIエージェント」として利用されている方が非常に多いことが分かりました。営業の方もメールの文章や提案資料の素案、社内ドキュメントの検索でAIを使っており、これからはスマートフォンのようにどんどんAIを使い倒す人が増えていくことを確信しました。

終わりに

DevOps Daysへの参加は初めてでしたが、各社の取り組みや事例、歴史から最新技術情報まで多くの刺激を受け、とても有意義な時間となりました。
今後もDevOps・AIの進化と活用方法について引き続き注目していきたいと思います。
最後まで読んでいただき、ありがとうございました。

【関連リンク】

・DevOps Days Tokyo

・Scrum Tokyo Youtubeチャンネル　

・イベントスケジュール