ミツカリ技術ブログ

株式会社ミツカリの開発チームのブログです

DevOpsDays Tokyo 2025 に初参加した感想

DevOps

こんにちは、ミツカリCTOの塚本こと、つかびー(@tsukaby0) です。

先日DevOpsDays Tokyo 2025というカンファレンスに参加しました。今回の記事はその感想レポートです。

DevOpsDays

詳細は以下のページを御覧ください。

www.devopsdaystokyo.org

過去に何度も開催されているイベントの2025年版です。

Past Events | devopsdaystokyo

若い頃は勉強会やカンファレンスは参加できていたのですが、最近は（というかスタートアップに入ってからは）忙しくなってしまい、めっきり参加数が減ってしまいました。こうなってしまうと仕事としては進むもののどうしてもインプットとしては減ってしまいます。

このままだといけない！と思い今回は仕事を止めてでも参加することにしました。また、参加の動機の半分くらいは私の元上司が登壇するからという理由もあります。

DevOpsDays レポート

スケジュールは以下のサイトで確認できます。

DevOpsDays Tokyo 2025 - Program Schedule | ConfEngine - Conference Platform

全部まとめるのは大変なので、自分が見たものかつ興味深い部分だけ感想を書いていこうと思います。

1日目

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

Performance working groupの取り組みは面白いですね。昨今では似たようなことをしている組織は多そうですが、2010年からやっている点は流石ですね。弊社の場合はtoBということもあり、アクセス数が少なく、パフォーマンスの優先度はそれほど高くはないのですが、こういう活動が無いと改善は生まれませんし、単なる新機能製造工場のチームになってしまうので、見習って行きたいと思いました。

2012年や2013年の時代に84週連続リリースや200週連続リリースという点も凄いですね。ここで言う連続リリースとは何らかのユーザーにアナウンスできる内容を伴うリリースとのことでしたので、ものすごい開発力だと思いますね。今でこそ私は自組織で似たことができていますが、リファクタリングなどの内部改善系がメインのリリースの週もあるので、単に毎週リリースするだけであれば楽勝ですが、毎週アナウンスという点はまだまだ実現できていないなと思っています。組織規模は違うでしょうが、2012年のタイミングで実現できている点が驚きです。

ソフトウェア開発現代史: "LeanとDevOpsの科学"の「科学」とは何か？ - DORA Report 10年の変遷を追って -

ソフトウェアプロセス改善の専門家のようです。Findyではそのソフトウェアプロセス改善を実現するとも言えるFindy Team+を開発されていますので、専門家がいたり歴史を知っている人が組織にいるというのは良いですね。

この資料ではタイトル通り歴史が学べますね。情報工学、ソフトウェア工学の世界に足を踏み入れて(学生から数えて)20年近く経ちますが、知らないことが多く勉強になりました。

恥ずかしながらLeanとDevOpsの科学は知っては居たものの読んだことがないです。立場上、自分一人だけでなく組織全体のパフォーマンスを気にしなければならなくなっていますし、興味は湧いてきたので読んでみても良いかなと思いました。

ミツカリではFindyTeam+を使っているのでFour Keysに沿った計測はできていますが、変更失敗率や復旧時間は特に課題を感じておらず計測の体制や環境は完璧に整っていません。このあたりの重要度を私が理解できていないというのもあると思うので、DORAのレポートあたりでしっかり学んで見ようと思いました。(LeanとDevOpsの科学を読むのもありだけど、技術本というよりは統計手法解説本という位置づけのようですね)

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

過去のインシデントをしっかりと分析されている点が素晴らしいですね。また、分析できる形でインシデントの情報を残していた点も素晴らしいです。ミツカリ社でもログは残しているし振り返ることはできるのですが、すぐに分析できるような管理体制、データ構造にはなっていないので、見習いたいところです。分析観点も参考になって嬉しいですね。

スプリントの後ろ1日は余白としてロードマップの開発を行わないというのも良いですね。とある企業では金曜日に会議を集中させることで、金曜は一切リリース作業をできないようにして安全性を高めているようです。

スプリントのどこか1日は特別な日として、製品開発ではなく、組織改善に充てられるようにするのは良さそうに思えます。ミツカリではこのあたりの考えがまだまだ薄く、どうしても価値あるもののリリース(ロードマップ開発)や売上が優先されてしまう状況ではあるので、今後のやり方を模索していきたいなと思いました。

レビューなしマージの取り組みもよいですね。真似していきたいです。ただし、企業によっては、それこそ上場企業の内部統制ルール次第ではこれは受け入れられないかもしれないと思いました。開発者が好き勝手やっていいよというのは内部統制がないという意味にもなりうると思っており、監査要件を満たさない可能性があります。このあたりは私は専門家ではなく、上場自体も未経験ですので、詳しいことはわかりません。スタートアップ目線ではよほどの事業、上場準備フェーズでなければ、こういう考えを積極的に取り入れて開発を加速させるのが良いかなと思いました。ミツカリでも見習っていきたいですね。

Real-Time Security: How DAST Elevates DevSecOps Practices

スライドは探したけども見つけられず。Snykというセキュリティプラットフォームサービスの方ですね。

ミツカリではSnykは利用していませんが、セキュリティ関連のサービス、ツールはいくつか利用しています。ただし、恥ずかしながらSCA、SAST、DASTというような用語や領域、分類があることは知らなかったので勉強になりました。セキュリティ周りのツールは分類や略称が多くて、他にもCSPMやCIEMとかもありますよね。範囲が広すぎて追いかけるのに一苦労ですね。

スライドが無いので詳細が思い出せませんが、SASTでは検知できない脆弱性をDASTなら検知できるというような実演があり、興味深かったです。スタートアップではどうしてもセキュリティは後手になりがちだと思います。理想はセキュリティエンジニアを雇用することですが、小さい組織では居ないケースのほうが多そうですし、雇用できるかと言うとできないケースも多そうです。なので、少しでもセキュリティに詳しい、あるいは興味があるメンバーでDevOpsからDevSecOpsへの意識改革、移行を行い、最大限セキュリティSaaSを活用して少しずつ改善していく意識を持つことが大事かなと思いました。ちなみに私はセキュリティスペシャリスト合格者(※失効済)であり、この領域に興味はあるので、私から少しずつ発信、主導していくことで組織にDevSecOpsの文化を作っていきたいと思いました。

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

意外にもkintoneでは近年まで技術的な制約でDevOpsは実現していなかったというのが少し驚きですね。技術的ではなく内部統制的にというのであれば理解はできます。サイボウズは上場企業ですし、開発者が強い運用権限を持って良いのかという疑問はあり、これはおそらく監査的には指摘事項となりえるはずです。そのため、開発と運用を切り離すような体制は理解はできます。

ただ、そのような権限の話ではなく(それもあるが)、インフラに対する高度な知識が問われるために難しかったという話のようですね。私は前職でプライベートクラウド(Openstack)の経験もありますが、その辺りはインフラ担当に任せていました。その辺りまで保守するとなると難しかったことは想像に難くありません。

まだ新体制の運用は始まったばかりのようですが、いろいろな取り組みをされていて素晴らしいですね。

製品チームでモニタリングアラート設定するとオーナーシップが芽生えると思いますし、理解度も高まるので良さそうですね。社内ダッシュボードというのも良いですね。おそらくこのくらいの組織、製品規模になると他チーム・他製品の影響が何かしらあるでしょうから、Write権限はなくともReadは与えて他チームの状況が把握できるのは良さそうです。また、俯瞰して全体を観れるのも良いですね。

ロールプレイや訓練も良さそうです。カオスエンジニアリングは最近聴く頻度が減ってきましたが、そのエッセンスも取り入れているように感じますね。

全体的にかなり先を行っているし、うまく自分たちで改善できるような良いエンジニアが揃っているような印象を受けました。流石のサイボウズですね。

Creating "Awesome Change" in SmartNews! 特務部隊”ACT”で挑んだインシデント半減作戦

私の前職で同じ部署だったIkuoさんの発表です。同じチームで仕事したことはないのですが、ずっとアドテクノロジー業界ですし、Staff Engineerなので優秀ですね。スペシャリストですね。

トークが上手いというのもありますが、今回のカンファレンスコンテンツとしては最も面白いと感じた発表でした。やはり他社の具体的な改善事例、試行錯誤は面白いですね！

Get our Hands Dirty (泥臭い手段を取る)、まず自分たちが動いて信頼貯金を作る、というのはすごく良い教訓ですね。見習っていきたいです。口だけの人や、いうだけ言って仕事を増やす人は信頼できないという人は多いと思います。このACTは実際に自分たちで手を動かしたというのが良いですね。

Incident Response Framework (IRF) という用語は初めて知りました。また、Pager Dutyがサンプルを公開しているんですね。

response.pagerduty.com

It is a cut-down version of our internal documentation used at PagerDuty for any major incidents and to prepare new employees for on-call responsibilities.

とあるので、おそらくこの資料でしょうか。PagerDuty自体がインシデント対応のためのアラートツールなので紛らわしいですが、彼らの社内のプロセスの簡易版ドキュメントのようですね。

この辺りは特に業界標準というものはおそらくないですし、各社によってさまざまだと思うので、SmartNewsの一例が聞けたのはすごく良い収穫でした。ちなみにミツカリでは一応私が手順書を作ったり、私自身も手を動かしてきましたが、まだまだ浸透していないし、30点くらいのIRFだなと思っています(プロセスだけでなく実際のインシデント対応の運用も30点くらい)。例えばトリアージや調査プロセス体系化などはまだ甘いですし、ランブックも整っていません。見習って改善していきたいと思いました。

専用のSlackチャンネルを作るのは良いですね。ここはミツカリではSlackスレッドで行っているのですが、どうしてチャンネルにしたのかは気になりました。おそらくは弊社とはインシデントの大きさが違うからかもしれません。スレッドが長大になる場合はチャンネルにしたいと思います。

Stateの変化を記録するというのも良いですね。確かにそこができないとMTTRなどがうまく集計できません。実際に整備して、KPIを追えるようにしMTTRを半減させたのは素晴らしいですね。

2日目

生成AI時代のソースコード管理を考える：'X as Code'からGitOpsへのDevOps進化論

自分が知っている X as Code はごく一部だということがわかりました。かなり種類があるんですね。Policy as Codeなどはまだ流行っていないと思いますが、必要性は分かります。例えばGitHubや関連する開発者用SaaSの設定をコード化したいと思ったことは何度かあります。TerraformにはGitHub Providerもありますし、昨今ではできるのかなとは思います。

Single Source of Truth という考え方は良いですね。この用語は知りませんでしたが、ミツカリでもこのようなスタンスを取っています。設計書はその時の実装を最適にするためのものであり、ADRの側面が強いものとして位置付けています。そのため、機能Aの設計書を作り実装した後で、機能Aを拡張することになっても既存の設計書は変えずに新しい設計書を作成していき、それを積み上げていくというスタンスを取っています。ソースコード(git repo)がTruthであるとしており、設計書はその時の意思決定資料としています。

ただし、このやり方には欠点があって、設計や仕様のマスターがソースコード以外にないため、非エンジニアや、ソースコードが理解できないジュニアエンジニアにとっては理解の妨げとなってしまいます。この点については仕様書や設計書のマスターを用意すれば良いのでしょうが、そこまでのコストは払えないので、現状ミツカリではできていないです。生成AIにも限界はあるので、昨今コンテキスト長が増えてきてはいますが、ソースコードから完璧な仕様書を生成するというのはまだ少し時間がかかりそうに思えます。理想的にはこれらのマスターの設計書・仕様書もX as Codeとしてリポジトリに入っていた方が良いのかもしれません。

資料の後半で Design as Code という言葉が出てきますが、これはまだあまり浸透していない考え方のように思えました。検索してもあまりヒットしません。

Code化とはテキストで書くことという説明になっているので、 Design as Code は設計書をテキストで書くという意味になり、それは結局いつも通りのことだと思いました(設計書は普通テキストで書くはず？)。ただ、AI時代を考えて、構造化して書くことという意識が大事なのかなと思いました。Excelで書いたり、画像やフリーハンドの図で表現したり、フォーマット無しのplain textで書いたりせず、markdown等で構造化して書くことが今後大事になってきそうです。

Single Source of Truth を踏まえつつgit repoに構造化された設計書や仕様書を配置するのは今後重要になってきそうです。ただ、私自身はこの点については少し懐疑的です。今後の生成AIの進化によってコンテキスト長はさらに増えると思いますし、Agent to AgentやMCPの登場もありますし、今後さらに色々と捗りそうです。別にNotionやGoogle docに資料が散らばっていても適切かつ簡単にAIが扱える時代が数年以内には来るかもしれません。git repo以外にドキュメントがあった方が非エンジニアは扱いやすいでしょうし、今生成AIの使いこなしを頑張りたい人以外は進化を待つのも良いのかなと思いました(本当に簡単になる時代が来るかは分からない)。

Devinで挑むゼロベース開発：AIエージェントと試行錯誤するDevOps

私の前職の上司のpotix2さんの発表です。

最近ではDevinよりもCline等をよく使っているそうですが、それでも1ヶ月で1250ACUsは凄いですね。かなり使ってますね。

命名や概念のズレは私も感じており、コードベース的にはこっちの用語を使ってほしいのに使ってくれないな・・・というシーンは何度かありました。やはり１つ前のYurieさんの発表や他何名かの発表でもありましたが、AIが理解できるようにドキュメントを整備することが大事ですね。

lintを実行しろという指示をしているのに守られない、ということを経験していたので、pre-commit hookで対処するのは良いですね。

この発表で一番の驚きはAI活用によってバックログが空になったということですね。そんなケースあるのか！？ミツカリでは生成AIの活用はまだ始まったばかりですが、フル活用しても空になる未来は想像できません。これはAIでは解きづらい課題が多いというのもあるかもしれませんが、やるべきでない課題が詰まれていることが問題なのかなと思いました。今後は思い切って価値の低いバックログは捨てていくことも検討したいです。

アジャイルの本質が問われているというのは、なるほどと思いました。まだミツカリではバックログが空になるようなレベルの高い状況にはなれていませんが、確かにコーディングフェーズが大幅に簡略化されるならより考えることに時間を費やせそうです。

資料上でAIが大量ゴミ生成器になっていないか？という一文があります。AIが作ったコードは品質が低くてMergeする気になれないとか、Mergeした後で保守フェーズで負債となるというような考えもあります。これは理解できます。私の考えでは、今はとにかく生成AIを使ったコーディング、開発生産性向上の施策をとにかく動かして知見を集めたり、一定ゴミがあってもいいので、とにかく触るということが大事かなと思っています。数をこなして数ヶ月後、数年後に質も両立できるようになるとか、あるいはゴミを作らずに価値のある開発だけに集中できる組織を作りたいものです。

これが自動運転システム開発におけるDevOps！

このセッションのタイトルを見た時に自動車(組み込み)業界の難しさを想像して驚きました。普段私はWeb業界にいるため、意識していませんでしたが、ドメインによっては同じCI/CD、DevOpsだとしても難易度が格段に違いそうですね。Webでは昨今エコシステムがかなり整っているので、CI/CDは特段難しくないですが、組み込みではどうやってハード側(物理)をスムーズに更新していくかや、どうやってエミュレート環境を構築するかとか、どうリアルなデータを揃えてシミュレートするかなど、考えることがかなり多そうです。

実際に資料の中でエキサイティングで高難易度とありますね。

ODD(運用設計領域)という用語は初耳でした。確かに自動運転を行う上ではこのような定義は必要ですね。

jidounten-lab.com

こちらのサイトによると

設計上、各自動運転システムが作動する前提となる走行環境条件のことで、各自動運転システムによって条件は異なり、すべての条件を満たす際に自動運転システムが正常に作動する。

とのことです。

走れば走るほど賢くなるというのは良い響きですね。CI/CD PipelineおよびEvaluatorを内製しているのが凄いですね。自動運転ドメインでは確かにここは重要度が高いので内製する理由は分かります（というか適したSaaSはないだろうし、内製で自動化しないと検証が遅すぎてやってられなさそう？）。1ヶ月で合計2万時間の実行というのも凄いですね。1ヶ月を730時間とすると、約27台のマシンが常にテストおよび評価を実行していることになりますね。これはなかなか無い物凄い規模ですね。

その他もクラウド積極活用という感じで開発規模が大きくチャレンジングだなと思いました。

自動運転の民主化、OSS化というのも大胆で将来どうなるか気になります。Webでは単純に利用者が善意だったり自分たちが使うためにOSSにコントリビュートしますが、自動運転はコントリビューターが直接使えるものではないので、OSSとの相性が良いのかは疑問が残ります。是非とも次はこの辺りの活動についての状況が知りたいところです。

3日目

グローバル大企業から日本のスタートアップへ：DevOpsの実践と適応

資料がアップロードされていないのと、思い出せない部分も結構あるので詳細は割愛します。

経歴としてはかなり凄い方ですね。テック系の最大手(Microsoft, AWS)ならではの苦労があり、とても興味深い話でした。

その他、聴講できなかった発表など

総じてすごく勉強や良い経験になったカンファレンスでした。今後も定期的に参加していこうと思います。

現在、ミツカリではITエンジニアを募集しています。興味のある方はぜひお気軽にご連絡ください！

herp.careers