DevOpsDaysTokyo2024に参加してきました

この記事は202406アドベントカレンダーの6日目の記事となります。少し前ですがチームで4/16-4/17で実施していた表記カンファレンス(DevOpsDayTokyo2024)に参加及び動画を視聴しましたので感想を記載します。

ちなみに参加する前に書いた下記記事も参照いただけると幸いです。

Day1

From Pilot to Transformation: Embracing the Reality of GenAI at Scale

The DevOps HANDBOOKを書いたパトリックドボアさんのキーノートでした。AIが開発にどう入っていくかという2年後の常識の話を聞いた気がしましたが、頭が理解が出来ず衝撃を受けけました。。下記のようなコメント/感想がありました。

・生成系AIから信頼できる回答を得るのはほんとに難しそう
・LLMの回答の違いはlabのHPでも検証してる人もいたなーと思い出した
・LLMでも長い文だと中盤は無視される
・RAGのサービス、ファインチューニングは近々、サービスとしてコモディティ化する
⇒これを使って、価値に変換するスキルがとっても重要になるんだろうなー。
・プロンプト、データ、モデル、API、そしてそれらのオーケストレーション
・RAG Ops
・生成AIのテストを他のモデルで行う
・業務フローに生成AIを組み込んでしまう。いつぞやのRPA以上に判断の自動化をする。ルールベースの業務ではなく、人間よりも品質の高い出力をする
・LLM扱うプロダクト用のWAFがある
・クラウドネイティブと同じようにすべてのエンジニアがAIネイティブになっていく
・データサイエンスとエンジニアリングを統合したシフトライトの話、重要そうな気がする。もうちょっとじっくり考えたい。
⇒仮説検証が大事も、似た話な印象
・コモディティ化はブラックボックス化でもあるから、中身を知るのは大事な気がする

DevOpsのグローバルトレンド

デロイトトーマツのkyonさんの講演でした。DevOpsに関するリサーチのまとめでした。DevOpsのカンファレンスが世界的にこんなに開かれているなんて驚きでした。

・アジャイルは「顧客中心」のやり方、納得
・イテレーティブに回したいのは、顧客の満足にリーチする一番効率的な方法だから
・ユーザー中心のチームは満足度高くいられる
・しかし、燃え尽き症候群になりやすい・・・
・トランクベース開発が生産性向上に有効
・シフトライトによるオペレーションコストの増加
・SREがとても気になるけど理解できてない

DevOpsで支える研究部門のIT基盤づくり

ダイキンの前川さんからの講演でした。大企業でDevOpsを進める時の苦労話が聞けました

・情報発信に力をいれている(1月RSGT、2月devsumi、3月JaSST、4月Devops Days)
・JTCなので社内規定やフローが重い
・ログを転送すること、この権限管理下から抜けられないこと、のみ強制
・研究機関なのでソースも資産のため、盗難を監視
・統制しつつ、上から求められたら簡単に説明できる仕組みも構築している

Seize the core concepts and value of BizDevOps

台湾のチェンチェンさんの講演でした。

・ビジネス、マネジメント、エンジニアの3者間のコラボレーションが重要だが、現場はなぜ分断して「最適化」してしまうのか?
・階層型組織のコミュニケーションラインから、部門横断のコミュニケーションと自己組織化を目指す
・”Shared goals”で複数チームが包含されている図
・bizDevOpsのライフサイクル
・ドメイン知識を押し付けるな、理解と同意形成をファシリテートせよ
・2!=2、2=2!(プログラマと数学者で真偽が変わる)

DevOpsを体感!?DevOps大仮面の組織カルチャーお悩み相談室!

ITプレナーズさんのスポンサーセッションでいわむーさんが変装して講演してくれました。

・devops大仮面(変な人がいた)
・わかっていても変革は難しい
・文化を浸透させたいなら物語を語る。物語というか理想の共通目標みたいな感じ
・完璧主義の文化は失敗が怖いので、失敗から学びを得る文化に
・やる気のパルスを共振させる
・サービス精神がすごかった!!ありがとうございます。

自動生成を活用した、運用保守コストを抑える Error/Alert/Runbook の一元集約管理

サイバーエージェントの岩見さんからの講演でした。

・コード+ドキュメントで適切にエラーを運用したい⇒ただ、ドキュメントの管理はコストがかかる・・・⇒自動生成
・opsの負荷軽減のために情報の集約、連携が大事
・形骸化しない工夫が必要
・エラーを詳細化することで、誰でもエラーに対応できるようになる

カオナビのユーザー利用実績をアウトカムにつなげる旅

カオナビの本江さんからの講演(スポンサーセッション)でした。DevOps2023に影響を受けたという事で見ていて勇気が出る内容でした。

・本番のログを確認できなかったはまぁ大体そうよね。。
・データスチュワードという概念を初めて聞いた
・チームが関連していき、自発的に起こる良い影響があった
・一つでもアウトカムがでたのはすごいと思う
・顧客や顧客に近い人を大事にする雰囲気が良かった

知識ゼロから学ぶAIのテスト 信頼できないソフトウェアとそのテストのために

マネーフォーワードの高橋さんによる講演でした。AIテストワクワクする

・ソフトウェアを支える技術として、インフラやテストが重要
・AIのテストはめんどくさい(本番の環境じゃないとテストできないなど)
・恣意的でないデータ準備が重要
・AIのテストは理系の技術と文系の考え方が必要
・QAの人だけど、アプリやAIも詳しそうで、業務領域を横断した知見をもつことって大事だなと思った

生成 AI による DevOps プロセスの改善

Googleの中丸さんの講演でした。

・SREに関して最初からFBをもらえるよう設計することが重要
・最初にジャーニーを作る!指標を決めて計測できるように実装、モニタリング!
・ロギングで出てきたエラーログの内容を自然言語で教えてと言ったら教えてくれるのは凄い
・groundingが生成AIの嘘を防ぐ

生成AI時代のDevOps – 文化を進化させるToolの未来

アタマプラスの前田さんからの講演でDevOpsにAIをどう組み込むかという実験の講演でした。

・楽しそうだった。こういう事をいつも考えている事が大事なんだよなぁと思いました。
・身の回りのカイゼンについてAIをしっかり使っていきたい

トランクベース開発の導入で見えた、DevOpsの技術・プロセス・文化との繋がり

テックタッチの国定さんの講演でした。

・MTのリスナー枠いいですね、我々も勝手に聞きに行ったりしてますよね
・タスク細分化のワークショップについてはTDDのリスト工程みたい
・DevOpsについて、スクラムの価値を意識して作業する感じに思えた。
・納得感の醸成は大事

今すぐできる! DORA metrics でカジュアルに始める CI/CD
クラウドエースの水野さんとGoogleの平岡さんの講演でした。

・Devopsの講演では燃え尽きるというキーワードが多く感じた。どこも運用が大変なのかな。
・LeanとDevOpsの科学を読まないといけない気がした
・なぜ4keysか?の理解も大事だとおもった。なぜ4keysがビジネスに良い影響を与えるのか?のwhyを知らないといけないと感じた

セキュリティプラクティスの継続的な実践〜セキュアなシステム構築を目指して〜
デロイトのaki.mさんの講演でした。RSGTの続きが聞けて嬉しい。

・偽陽性を防ぐために、できるだけ有償ツールを使う。OSSは偽陽性が多くなりがちらしい
・プラクティス名とか知らなかった。書いてあることは当たり前のことでも、観点を考えるのに名前を知っておくことは大事だと思った
・顧客報告とか、指揮系統とか、確かに緊急時に疎かにしがちかも。事前にそういった整理も必要
・aki.mさんのセキュリティの続きが聞けてよかった!

SPI原点回帰論:事業課題とFour Keysの結節点を見出す実践的ソフトウェアプロセス改善

Bizreachの高橋さん、内藤さんからの講演でした。いつものごとく盛りだくさんでスゴイ内容。

・SODA構想(「チーム」を組織に「実装」する)気になる
・見える化できてもたいていの組織では改善するための仮説が立てられない
・イネイブリングチームがルール整備してあげないと、複数チームでの4kkeys測る等難しい
・無風が続くと、「スクラムだから遅い、会議が多すぎる」みたいな意見が出がち
・対応するために、EBMに注目して進めている
・オンプロダクト指標(チームがプロダクトと価値に費やす時間の割合)に注目した
・SPI-Enabling teamが実際、どのくらい組織改善に寄与できているのかとても気になる
・ソフトウェア開発は料理に似ている
・バリューストリームマッピングでボトルネックを特定してムダに対処する話、むしろシステム設計に適用したい

エンジニアゼロからのDevOps ~ エンジニア文化のない大企業での内製開発成功への軌跡 ~
東京ガスの中島さんからの講演でした。東京ガスさん大企業なのにすごいなーと思います。

・my TOKYO GASは元々ベンダ発注していたが、内製に切り替えた
・ウォーターフォールまじりのオリジナルアジャイルはあるある・・・
・レガシーシステムの有識者を「仲間」としてきてもらう
・受発注の関係にしないと言うは易しここの本当のところは聞きたい
・プロダクトがどう世の中を変えられるのかを考える(言うは易し)
・ビジネスメンバーが開発メンバーと会話できるようになるために開発の知識を勉強するパッションはなにか?
・ビジネスに溶け込んで当事者意識を持つ、兼務は作らない
・DevOpsをやらないと絶対に内製化は無理
・アツかった、テクニックじゃなくてマインドだった
・パッションがすごかった!熱量、当事者意識、やる意義どれも大きい影響を与えるならかえちゃいけない要素だと改めて思った

週5時間から始めた活動が組織の壁を超え、 商用サービスの運用者を救った話

Densoの島津さん冨田さんからの講演でした。

・googleの20%ルールを参考にした
・寺子屋の価値観を合意するまでにどれだけの時間を要したのか気になる
・筋トレはスクラムのメタファーにちょうど良いと感じた
・このような取り組みに割く時間がないという声をよく耳にする。しかし、もしあなたがすでに会社の主要な目標を達成しているのであれば、10%や20%のプロジェクトに時間を割くことを許してもらうのはとても簡単なことだ。
・委託先でどうやって作っているのか、ブラックボックスになっているから簡単に内製に戻せない
・ビジネスサイドを巻き込むはなるほどな・・・そうなんだよな・・・

DAY2

サービス運用はボールを落とさない競技 : 2009年DevOpsDays の誕生と私の身の回りの話

川口さんのキーノートの講演でした。DevOpsやる人には必見の内容です。

https://speakerdeck.com/kawaguti/devopsdays-history-and-my-devops-story

・アジャイルのアップデートは文化かテクニカルかで両方を含むものはないかもしれない
・番外:信頼貯金大切。10年やろう
・どんな学びがあるかわからない=計画外の出会いが大事
・DevOpsは実践者のコミュニティから生まれている
・DevOpsは継続的に顧客に価値を届けられるかを考えてやっていくもの。ツール導入すればいいとか規準満たせたらOKとかそういうことではない
・10 deploys per day
・障害時の対処と対応(対処:障害発生したときに本線に戻す/対応:障害が起きないようにするためにどうするか考える)
・変化が必要とされるけれど、日本は障害を恐れるフォースが強い気がする。
・組織が分かれてると、犯人探しに躍起になる可能性ありますよね。自分たちはやってない!お前らのせいだ!みたいに謎対立発生する
・自分でわかっていない人たちに運用させると、長大な手順書に従うしかなくて、ブラックボックス化するね。インシデントに対処できず、変化を恐れようになる
・計画外の出会いってやつを、社内でできると良いかも(DevOpsっていうキーワードだけ置いて集まるか)
・安定性を重視するか、変化を重視するか
・devopsがコミュニティから生まれたという歴史を知れた

Value-Driven DevOps Team〜価値貢献を大切にするチームがたどり着いたDevOpsベストプラクティス〜

カケハシの小田中さんと椎葉さんの講演でした。チームで見て一番盛り上がっていたかも。

・トランクベース開発を導入する目的が仮説検証のループを素早く回したいというのは良い
・フラグの削除重要
・自分がモノリポとポリリポのメリデメが良く分かってない。理解せねば
・今回はこのレトロだと嫌だなぁと正直に言えるチームはすごい
・WA多いな
・必ずしもみんなで、ではない、1人でさえなければいい
・自社のアジャイルを理解していない人に見せたい。神公演


スクラムで作り続けるauでんきアプリの開発と24/365運用の実践

AUでんきの志村さんからの講演でした。

・Lessで8年間開発、運用をしているのは凄い!
・ミッションクリティカルなので、DSの運用版などでカイゼン。バーチャルな運用チーム
・オブザーバビリティに対するカイゼンがスゴイ

DevOpsメトリクスとアウトカムの接続にトライ!開発プロセスを通して計測できるメトリクスの活用方法

Findyのはまださんからの講演でした。

・FindyさんはDevOpsDaysとあってるなー
・RICEスコア(Reach:影響を受けるユーザー数、Impact:ユーザーやビジネスへの影響の大きさ、Confidence:成功確度、Effort:開発に必要な工数)
・アウトカムへの影響を大事にする(フロー効率に着目)
・工数の遷移も見えるようにして不確実性のコーンを見える化する

境界を越えたアジャイル:他社間で構成されたスクラムチームで私たちが試行錯誤していること
ウィングアークの荒川さん、木田さんからの講演でした。

・スクラムは銀の弾丸ではない
・スクラムで開発者の役割がどこまでかはいつもモヤモヤしてる気がする
・ウジウジの方、自分たちのラボではあんまり気にしてないな
・スクラムガイド勉強会とか自分達も結構やれているなと思った
・「境界を超え、より良いチームを目指すためにそれぞれが持つ個性や特性を認め合う」という部分について、たとえば新人や経験、スキルが皆無の人はどう、何が認められるのか、認められたとしてそれが「良いチーム」になるためにどう作用するのか、とおもった

Feature Toggle Promotion via CI/CD Pipeline
Nareshuさんの講演でした。

・Confengine作っている人だった
・開発とデプロイを独立してやるインデプロイとして7つのプラクティスを紹介
・トランクベース開発:単一のブランチで開発。複雑すぎると言われることも有るが、とてもシンプル
・トランクベース開発ネタ多いなぁ。

君もテスト自動化の同志を増やすパターンで大勝利!
食べログさんのスポンサーセッションでした。

・テストデータ作成自動化やった話
・howが先行するのは良くないよなぁ
・最後のテストピラミッドとアーキテクチャの話が興味深かった。

〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える自動化テスト戦略

ビットキーの佐々木さんからの講演でした。難しいハードのモック化をサラッとやるのがビットキーさんのシステムとドメインスキルの高さを感じさせます。

・制御盤のモック気になる。作成するスピードに驚いた
・クリーンアーキテクチャを大事にしていると言えるのがいいな
・ハードのソフト化は概念は分かるものの、実際どの程度大変なのかはとても気になる

How we reduced our yearly AWS bill from 2.2 million to 1.9 million

アメリカのポールさんからの講演でした。

・自分の部署の仕事ではない、ベンダーに任せるという態度は間違い
・NGな考え方に陥りがち(心機一転更地にして新システム構築)になると、古いシステムも残って結果効果が薄れる
・一から作り直すのは間違い(実態として、もっとお金がかかるかもしれない、危険。元々の目的は会計年度のコストを下げることだし、WF的アプローチをとってしまう。そもそも完全に全て新しいシステムに置き換えるのは不可能で、新旧併存することになる)
・全体の経営ゴールを理解すべし
・担当部門に地道に状況ヒアリングし続ける
・100%使われていない、と確信していなくても、リスクを想定の上で止めてみる(スクリームテスト、止めたら誰が叫ぶか)
・マイグレーションが完了すればコスト削減できる、というWF的アプローチはうまくいかない。やめろ。

金融業界で複数チームDevOpsを目指して奮闘している話

MSOLデジタルの能勢さんの講演でした。伴走の成功例ですね。すごい。

・アジャイルに出会って価値にコミットできるようになったと実感⇒よい
・アジャイルの基礎知識1日で理解できるのか?気になった
・「声の大きさで作業がきまる」はある、ある
・面白い!モブ・ペアでしきれないところをこういう風に楽しく共有できるよ良いのかも
・howから浸透させていく?的なのはあるある
・1ヶ月50人でwhyを深掘りしていった!すげー
・兼務でも、whyが理解できていればうまくいく?のか気になったと思ったらダメだったw
・成果発表会という名前良い!
・良くなると別の問題が出るやってみないとわからないな
・価値の情報(WHY)が抜け落ちてくるは良いと思う
・情報共有会の話について、共有会がしやすいように改善するたびデグレみたいに不満が出てくるのを根気強く、うまく解決していてすごいなと思った

「パタンランゲージ」から「センタリング」へ

中埜先生からの講演でした。

・ルールは一般的な話であり、あなた個人の特殊性を反映しない
・パタンには個人の特殊性が含まれている
・物語、ナラティブに切り替えて、集団で美の共通認識を得る
・形で見える「モノ」文化や伝統といった固有のコンテキストを持つコミュニティにとっての意味である「コト」を連結する
・現場で建物が既にあるかのように「体感」する
・頭の中で言語で考えた理想が、現場の物理的な制約を受けて形を変える
・このずれを見つけて、それへの対処を工夫する。これが創造力だ。


Becoming antifragile is more important than ever in disruptive times
オランダのヤンさんからの講演でした。

・Not frigileは「Robust、Resilient(回復力)」の2つだけだったが、これにAntifragileが加わった
・改善を続けてプロダクトの価値を上げていく場合は、Antifragileな状態になる(Pain下がり、Gain上がる)
・PhoenixProjectはAnti Frigileを考えるうえでもは読んでおくべき
・Fragileな部分を取り除くにも技術負債を解決するのは重要
・Antifragileの例(ABテスト、マイクロサービス化、ソフウェアを小さくすることでリスクを下げられる)
・MTBFよりMTTRにフォーカスするのがAntifragile
・技術負債だけでなく組織的な負債(コミュニケーションなど)にも目を向けるべき
・組織負債特にトップの部分こそがボトルネックになる
・Antifragileの話で、組織的な負債の解決についてはもっと話が聞きたかった

今日から始める会社横断ワンチームのつくりかた 〜僕らが進むセキュリティ向上への道〜
NTTスマイルエナジーの迎さんとサーバーワークスの松井さんからの講演でした。

・マインドセットが悪の組織っぽいw
・ふりかえりでプライベートなことも書けるのはいいと思った
・Design Docは試してみたい
・プロパー・パートナーは越境していきたい
・振り返りの際に誰が書いたかで印象が変わるのを防ぐために同じ色を用いるのはなるほどと思った

DevOps Past and Future: An Interview

パトリックドボアさんとの対談でした。飲みながらのアフタートーク。乾杯!!

・アジャイルマニフェストが短い文章であったために誤解されることも多く今も完全に解けた状態ではない
・組織の中での部署の対立を壊していくのがDevOpsだと思う。開発と運用に限定しない
・DevOpsはツールだけ、人(文化)だけ、ではなく両方が必須
・people and AI working togetherになっていく
・我々が1つの仕事を成し遂げたら、それは既に過去のものになる。常に新しい仕事をしないといけない。

ふりかえり

ふりかえりとして、メンバーでFunDoneLearn/Moyattoをやりました。下記が出てきた意見

<FunDoneLearn>
・同じものを見ることで場の共有ができ、感想戦で話もできたので楽しかった
・知り合いと再会!現地ならでは
・浴びるように聞いていると熱にあてられる
・チームは人間の集合でナマモノだから、熱が重要だと学んだ。結局そこ。と言いつつ、ユーザーに寄り添うほど燃え尽きが起こりやすいらしい。そこまで行ってみたい
・若いスピーカーが多かった印象。。。すげー
・どの会社もDevopsやアジャイルを実施し内製化を進め、情報発信する流れになってると感じた。
・RSGTに参加してかなりラボ内の社外カンファレンスに対する意識が変わった気がする。
・イケイケな人や、今時の開発と比較して、自分/チームは今どこなのか?をリアルに体感する機会だなーと!
・業務にAIを活用することが当たり前の世界になってきたなと、肌で感じました
・若手が活躍してきていると感じた
・品質にかける費用比率が30年も変化なしということ
・リアクションしたりキャプチャはったりしたのが楽しかった
・セッション終了後にみんなでセッションに対しての話題でワイワイできた
・誰の話でも個人主義ではなくチーム主義、ヒーローになろうとするやつを抑える、犯人探しをしないなど個々の問題ではなくチームで改善するということに重きを置いていた。ただ連帯責任というニュアンスが一切感じないお話で興味深かった
・デプロイ頻度を高める工夫を聞けて面白かった!サービス運営をしていく中で自分達もやっていきたい!
・運用できてはじめて、価値を届けたい人に届けられるよなと思えた
・価値を届けるための人のかかわり方の話もたくさん聞けて、両輪あって価値を届ける活動なのだと分かった
・いくつになっても何かに熱中できる熱量を持つ人でありたい

<Moyatto>
・もっとがやがやしてみたいw。自分たちの心理的安全性もまだまだ?
・ちょこちょこ休憩はあったが、結構疲れた
・さらっと、ビジネスとITが協業してみたいなプレゼンや、CI/CDを構築してとか言われてましたが、そこに大変だったけどこうしたらなんとかなったというのが潜んでると思うので、そこが知りたい
⇒「whyを先行させよ」、という風に解釈しましたw。熱があれば、技術自体はどうとでもなる、的な・・・(というより、技術ではなく、人が原因で解決できない問題がほとんどで、人を解くために熱がいる?)
・結局、devopsには組織内での、価値類級への理解/説明が必要な気がする
・身近な業界(金融・保険)の話をもっと聞きたい(FINSUMで聴けばいいのかもだが)

感想

同じものを見て場の共有が出来、みんなでディスカッションできるというのはとても良いと思います。DevOpsというテーマはエンジニアが興味強く見れる物であり、それでいてツールだけでなく文化の話も強く、共有が盛り上がりました。最後まで読んでいただきありがとうございました。