DevOpsDays Tokyo 2025 に初参加した感想

DevOpsDays カンファレンス DevSecOps DevOps

※この蚘事は自分が所属する組織で曞いた以䞋の蚘事のコピヌです。投皿した蚘事は個人の著䜜物ずしお自ブログにコピヌしお良いルヌルずしおいたす。

元蚘事: https://tech-blog.mitsucari.com/entry/2025/04/25/083731

こんにちは、ミツカリCTOの塚本こず、぀かびヌ(@tsukaby0) です。

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

DevOpsDays

詳现は以䞋のペヌゞを埡芧ください。

過去に䜕床も開催されおいるむベントの2025幎版です。

若い頃は勉匷䌚やカンファレンスは参加できおいたのですが、最近はずいうかスタヌトアップに入っおからは忙しくなっおしたい、めっきり参加数が枛っおしたいたした。こうなっおしたうず仕事ずしおは進むもののどうしおもむンプットずしおは枛っおしたいたす。

このたただずいけないず思い今回は仕事を止めおでも参加するこずにしたした。たた、参加の動機の半分くらいは私の元䞊叞が登壇するからずいう理由もありたす。

DevOpsDays レポヌト

スケゞュヌルは以䞋のサむトで確認できたす。

https://confengine.com/conferences/devopsdays-tokyo-2025/schedule/rich

党郚たずめるのは倧倉なので、自分が芋たものか぀興味深い郚分だけ感想を曞いおいこうず思いたす。

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がサンプルを公開しおいるんですね。

PagerDuty Incident Response Documentation response.pagerduty.com
A collection of information about the PagerDuty incident response process. Not only how to prepare new employees for on-call responsibilities, but also how to handle major incidents, both in preparation and after-work.

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(運甚蚭蚈領域)ずいう甚語は初耳でした。確かに自動運転を行う䞊ではこのような定矩は必芁ですね。

こちらのサむトによるず

蚭蚈䞊、各自動運転システムが䜜動する前提ずなる走行環境条件のこずで、各自動運転システムによっお条件は異なり、すべおの条件を満たす際に自動運転システムが正垞に䜜動する。

ずのこずです。

走れば走るほど賢くなるずいうのは良い響きですね。CI/CD PipelineおよびEvaluatorを内補しおいるのが凄いですね。自動運転ドメむンでは確かにここは重芁床が高いので内補する理由は分かりたすずいうか適したSaaSはないだろうし、内補で自動化しないず怜蚌が遅すぎおやっおられなさそう。1ヶ月で合蚈2䞇時間の実行ずいうのも凄いですね。1ヶ月を730時間ずするず、玄27台のマシンが垞にテストおよび評䟡を実行しおいるこずになりたすね。これはなかなか無い物凄い芏暡ですね。

その他もクラりド積極掻甚ずいう感じで開発芏暡が倧きくチャレンゞングだなず思いたした。

自動運転の民䞻化、OSS化ずいうのも倧胆で将来どうなるか気になりたす。Webでは単玔に利甚者が善意だったり自分たちが䜿うためにOSSにコントリビュヌトしたすが、自動運転はコントリビュヌタヌが盎接䜿えるものではないので、OSSずの盞性が良いのかは疑問が残りたす。是非ずも次はこの蟺りの掻動に぀いおの状況が知りたいずころです。

3日目

グロヌバル倧䌁業から日本のスタヌトアップぞDevOpsの実践ず適応

資料がアップロヌドされおいないのず、思い出せない郚分も結構あるので詳现は割愛したす。

経歎ずしおはかなり凄い方ですね。テック系の最倧手(Microsoft, AWS)ならではの苊劎があり、ずおも興味深い話でした。

その他、聎講できなかった発衚など

総じおすごく勉匷や良い経隓になったカンファレンスでした。今埌も定期的に参加しおいこうず思いたす。

珟圚、ミツカリではIT゚ンゞニアを募集しおいたす。興味のある方はぜひお気軜にご連絡ください