0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

DevOpsDays Tokyo 2024 の参加レポート

Posted at

本記事について

DevOpsDays Tokyo 2024に初めて参加してきました。この記事は参加して得られた学びを定着させるためにアウトプットしてみた内容です。

DevOpsDays Tokyo 2024の概要

参加セッションの感想

全部書くと量が多すぎるので、特に印象に残ったセッションについて書きます

keynote Patrick Debois - From Pilot to Transformation: Embracing the Reality of GenAI at Scale

1日目のキーノート。DevOpsの父であるPatrick Debois氏の話…なのですが、前半はほとんど生成AIの話でした笑。
後半はその生成AIのデリバリーが難しいという話になり、特にテストを同自動化かつスケール化するかが難しいようです。従来のテストと違いテストが絶対的ではない(生成AIの「良い答え」は文字数などで定義できない)と話しており、確かに難しいなと。
自動化においてはヘルパーモデルを使い、「有害な言語がふくまれるか?」「いい答えか?」を他のLLMに聞いているとのことで、実践的な話でした(そして技術内容の8割がわからずでした…)。

DevOpsのグローバルトレンド

The State of DevOps Report2023 について kyon _mm 氏の見解で解説する内容。燃え尽き症候群になりやすいチームやAIのポジティブ/ネガティブな影響、信頼性とパフォーマンスのJ字モデルの関連性など話を聞いていてとても面白い内容でした。
24時間ぶっ続けのカンファレンス ALL Day DevOps、気になる笑

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

「開発ロードマップ、こっそり変わることあるよね」から始まる、チーム外から見た開発生産性を見える化したいお話し。
スクラムではベロシティなどの生産性の指標を評価KPIにするアンチパターンがある中で、どうやって生産性の指標を持つのか難しいことを痛感しました。その中でもSoftware Outcome Delivery Architecture(SODA)というアーキテクチャを構築し、指標を図りながらも課題→改善を繰り返しながら進めており、データを可視化できているのが凄いです。
他のセッションでも触れられていた気がしますが、まず推力(チームの技術力)が無いとアウトカムに進まないというのは私の過去の経験からも納得しました。チームが価値を出せていくためにもまずは推力を図れるようにしたいし、推力を出せるようにする技術力も身に着けていきたい。
まずは Four Keys を図れるようにするところから始めるかな。

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

ボリュームが多すぎて、後半半分くらいが「続きは劇場で」となったキーノート笑
内容はDevOpsの物語に関する内容で、超面白い。資料も見られますが川口氏のトーク力あってこその内容だった思います。
DevOpsがPatrick氏のたった2人で始めた活動から広がり、実践者から生まれる実践者のためのコミュニティとして発展していった歴史を知れたのは大きな収穫でした。DevOpsが歴史を大切にしている理由がとてもよくわかります。
川口氏の「計画外の出会いが大事、想像していなかったことを学ぶ」というメッセージが、私の中にあるカンファレンスへの現場参加が楽しい理由を言語化してくれました。想像していないことが学べるから現場参加は楽しい、本当にそう。

Vertically Integrated in Platform Engineering: Secrets to Success When Operating the Company Within the Company

Plartform Engineeringの話。最近の案件がPlatform Engineeringと親和性があるので一番目当てにしていたセッション。
「自分たちのPlatformを会社として考えてみると、マーケティングなどの観点が無いと会社がなくなりますよね?だからエンジニアはいい職人なだけでは十分でない」というメッセージがその通りだと感じました。

  • When DevOps is a business, business is DevOps
    • 全部DevOpsであり、ビジネスもDevOps
    • 良い職人だけでは十分でない

DevOpsはシステムに閉じた話ではないですね。

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

今回のカンファレンスで最もワクワクしたセッションでした。ちょうど私の中でやりたいと考えていたことを実践していた内容で、ものすごく刺さりました(まさに予期せぬ出会いが!)。
運用チームやスクラムマスターのローテションは難しくないか?と思ったらやはり難しかったり、そんな中でも改善しているのが凄いなと思います。
スクラムチーム間の情報共有という取り組みをネガティブなものからポジティブでハッピーかつ有意義な取り組みに改善できているのが素晴らしいです。
自分の組織でもやってみたい(近日中に組織内で企画予定)取り組みですし、取り組みを褒める文化が醸成されていて良い組織を目指せていることが伝わってくる内容でした。

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

建築家の中埜 博さんのお話し。
とても素晴らしいセッションだけど、自分の語彙力でこのセッションの凄さを言語化ができない悲しみ。ただ、2日間聞いた中で一番熱いセッションだったと思います。
「ユートピアを現実にあてはめて、ずれを計測しながら価値を創造する」
単語だけ聞くと何の話?となりますが、確かにDevOpsな内容でした。

まとめ

DevOpsDays Tokyoへは初参加でしたが、参加して本当に良かったです。2日間のカンファレンスに参加するのは久々でしたが、その分学びが多くとても有意義な2日間になりました。何より参加していて楽しいのが一番いいところですね。ただ、私はまだ参加者同士でガンガン会話したり、英語のスピーカーと話すことができていないので、まだ全体の2~3割の楽しさしか知らないとも思います。
もっと楽しさを知るためにも、いろいろなセッションに参加したり、それこそ登壇できるくらいの取り組みをしたいなと思えた2日間でした。英語はもうちょっと頑張ろう

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?