DevOpsDaysTokyo2023の全セッション感想

DevOpsDaysTokyo2023の全セッションを見たのでその感想になります。

注意事項

• 一度見たセッションの感想については、以前の記事を引用しているものもあります。
• 英語の講演も聞いていますが、ネイティブレベルからは遠いため、内容を誤って解釈してしまっている可能性もあります。

DevOps, Development Cadence and the Product Life Cycle

自然で人間的な働き方(=フルタイムで働くときとゆとりを持ちながら働くときで緩急をつけながら働く)がDevOpsやアジャイルに関わってくるという主張は、今までにない話で面白かったです。
3Xモデルとの絡みや頻繁なリリースを追い求めることの危険性など、話の繋げ方も教科書的な繋げ方とは違っていたので、興味深かったです。

プレゼンテーションや質疑応答の内容から、開発者が頻繁なリリースや常に成長や改善を求められる環境に燃え尽きてしまう現場を何度もMichael Feathersは見てきたのかなあ...?と勝手に感じていました。

生Michael Feathersは最高でした。

自動テストのFour Keys​ ~テストプロセスのソフトウェア化の4つの鍵~

自動テストのメンテナンスをしていく中で、いたずらに自動テストを増やしたり、ただ自動テストケースに着目していくのではなく自分たちで考えた指標を軸に改善をしていく実例が聞けた素晴らしい発表でした。

Lead time for testing/Testing frequency/Testing failure rate/Lead time to recover from test failureの指標自体にも納得感はあったのですが、これらを4 keysとして運用しているというのであれば、それぞれの要素同士の関係性や特定要素を求めたときにトレードオフに見えるような事象が起きないか？という部分をもう少し詳しく聞いてみたい感じはありました。

DevOps最新動向 高パフォーマンスな技術組織の秘訣

State of DevOps report2022の概要を「コンテキスト」に注目してわかりやすく説明してくれた発表で、ストーリー形式で重要なポイントの解説をしてくれたのが非常によかったです。

内容的にはState of DevOps report2022とのdiffはなかったので、一度読んだ身としては良い復習になった感じだったのですが、ロードマップはベストプラクティスと呼べるような画一的なものはなく組織によってぜんぜん異なることや、信頼性を上げるプラクティスは一時的に信頼性を下げることを強調されていたのは、印象深かったです。

Transparent Infrastructure at Uber Scale

Uberの爆発的なスケーリングを支えるGrailの話を聞いていきました。

Grailの存在は今回のセッションで初耳だったのですが、Graph Databaseとして非常に優れた性能を叩き出していることが各種数値から実感でき、素直にすごみを感じました。

ただ、すごい性能を叩き出していたからこそ、技術的にどのようにしてGrailを実現させているのか？という部分はGraphの説明よりもう少し詳しい説明が欲しかったです。

高信頼 IaaS を実現する DevOps

社内k8s基盤の作成やCI/CD整備の部分を中心に、かなり具体的な技術要素にまで踏み込んで実現方法や重視していたポイントの解説をしてくれる発表で、学びが多い内容でした。

技術的な話が面白かったのはもちろんですが、DevOpsを推進していった結果、さくらインターネットの組織文化(3つのバリュー)が非常に重要だったという話はすごく素敵でしたし、繰り返し伝え続けることがDevOpsの創造的な文化づくりの基礎になっていたというのもとっても印象的なお話でした。

4keys 導入のリアル〜ひと通りやってみて分かったこと〜

4 keysを現場でどのように計測し、どのように組織の生産性向上に組み込んだのか？という話を聞くことができた発表でした。

計測の部分では、何かしらパッケージ商品を使うのではなく、社内で自分たちなりの4 keys(4keysの定義にしたがったら自分たちのプロダクトにおける4 keys)を考えているのが印象的でした。プロダクトの理解が浅いので指標の妥当性まで細かくは判断できませんでしたが、自分たちの組織に見合うように言語化している姿勢がよかったです。

生産性向上に向けた取り組みとしては、普段から4 keysに接するような機会を作るためにレトロスペクティブに4 keysを組み込んだという工夫が、単なる意識付けに留めない取り組みとなっている印象があってよかったです。

GitHub Actions & オートスケールするSelf-hosted runnerで実現する KAGのみんなのCI/CD

CI/CDの構築方法としてGitHub Actions+Self-hosted runnerの話があり、そのCI/CD基盤をどのように運用しているのか？を最後に説明するという構成で、見事にまとまっていました。

有志での対応ということですが、ごりごりActions Runner Controllerで頑張られているのはなかなかすごいですし、terraform-aws-github-runnerを使わずに労力をかけている理由というのも納得できました。

技術的に制約はなく、自分たちがやりやすいようにしている結果の話だという前提が最初にあった上での発表ということもあって、なんだかんだ今はGitHub Actionsなんだなあというのを実感する発表でもありました。

ファクトから始める改善アプローチ Ep. 2 〜 Four Keys の先にあるアウトカムに向き合ってみた 〜

アウトカムの計測というのは一つのテーマとして色々なところで語られていますが、その中でもEBMをもとにしながらアウトカムの定義をした事例が聞けたのが特によかったです。

また、指標を定義する際に、その道のプロフェッショナルにヒアリングをしたりインタビューを通して指標を洗練させていくというのも、組織で納得感ある運用をしていくにあたって非常に重要なステップなんだろうなあというのを個人的に感じました。

Reliable and Faster Deliveries: Complete Test Automation

テスト自動化を通して信頼性が高い製品を作るために必要な要素がプレゼンテーションの中にぎゅっと凝縮されていました。

一つのプレゼンテーションで扱うスコープとしてはだいぶ広かったので、細かな部分までは話が聞けませんでしたが、色々な観点からのベストプラクティスが幾つも紹介されていて、テスト自動化を考えている人はまずこれを見ればよいのではないか？と感じるセッションでした。

QAセッションではありましたが、テストスキルというよりも開発力の部分にかなりフォーカスをしている印象があった発表で、これまで自分が聞いてきたQA関連のセッションとはいい意味で全然異なる印象を感じる発表でした。

カオナビのGitLab CI/CDにおける自動テスト運用と速度改善

前半にあった使われなくなったE2Eテストの話では、E2Eテストが「ない」ことよりも「使われなくなった」方が組織に与えるダメージとしては大きいんだな、というのを一つの事例ベースではありますが実感するような内容でした。

後半にあったGitLab及びSelf HostでのGitLab Runnnerを使用していく中で出てきた課題やその対応策の話では、以前の失敗経験を活かそうとした結果(?)スモールスタートが一つのキーワードになっているように感じました。

難しい大きな問題に対して、全体を見つめた上で小さな課題に対応していく様子が見られて非常に刺激を受けることができるプレゼンテーションでした。

組織のサイロを打破する！エンジニアがオーナーシップを持って共創する開発プロセス「インナーソース」

DevOpsの文脈でも語られる組織文化の変革(透明化)と絡めて、インナーソースの取り組みの意義やインナーソースにまつわる誤解、インナーソースの効果的な活用方法やアンチパターンの話がメインにあり、最後にAIとの協働に関して話がありました。

最初はインナーソースが解決したい問題意識について話があったのですが、組織のサイロ化を仕組みを活用して壊せるのは非常に魅力的だなあと感じましたし、DevOpsやXPといった思想との相性が知れたのもよかったです。

中盤はインナーソースにまつわる誤解やインナーソースが活用できるユースケース, アンチパターンの説明がありました。
スライドに出ていたほど極端な誤解はなかったですが、自分の捉えている範囲が狭いことを痛感するような話が多くあったので非常に学びが深かったですし、抽象的なポイントから現場であるあるな事例の話まで広く聞けたことで、理解が深まりました。

最後はAIとの協業にまつわる話がありました。
ここでもインナーソースの考え方が繋がってくるというのは見事な流れでしたし、GitHubの中の人からGitHub Copilotの話が聞けて面白かったです。

自分は全然インナーソースに詳しくない状態で話を聞いたのでインナーソースに対する理解が深まったという意味でまず勉強になったのですが、DevOpsという参加者のコンテキストから見事にインナーソースの魅力を伝えている点や、スライドとトークの組み合わせ方がめちゃくちゃ上手な点など、発表のクオリティという意味でも勉強になることが非常に多かったです。

Building Apps in Kubernetes the DevOps way: Tools, Trick and Tips

セキュリティ周りを中心としたk8sの周辺ツールとして、Secret management, Container tools, Container image signature, Software Bill of Materials, Valnerability scaninngそれぞれの観点でツールの紹介をしてくれる実用性が高いセッションでした。

セキュリティ周りのツールはどうしてもアジリティを下げたり開発者体験を悪化させるイメージが個人的には強いのですが、今回紹介されたツールは話を聞く限りそこまでアジリティや開発者体験の低下に寄与しないようなツールも多くあったので、Container image signature, Software Bill of Materialsを中心に、幾つか気になるものを使ってみようと思いました。

肥大化・モノリス化するプロダクト開発組織を自律的で小さなチーム群に変えていく ―kintone開発チームの事例―

「自律的な判断ができるまでにチームを小さくする」という原則のような取り組みを大規模プロダクトで愚直に適応した事例が聞ける素晴らしい発表でした。

組織の変遷を時系列で追いながら、各種取り組みとその中で見えてきた課題の説明をしてくれたので、実際に組織の変遷を追体験できるような感覚があって非常に楽しかったです。

発表でもありましたが、部門に閉じず全体的な視点でアドバイスを与えてくれたりサポートをしてくれるメンバーの存在というのは、こうしたチーム分割をしていく上で一つの鍵になるんだろうなあというのを個人的には実感しました。

変更障害率0%よりも「継続的な学習と実験」を価値とする〜障害を「起こってはならないもの」としていた組織がDirtの実施に至るまで〜

最初はDevOpsとは程遠い「障害は起こってはいけないものであり変更障害率は0%を目指すべきである」時代の話から始まったのですが、このあたりは自分自身も前職で経験がある話だったので、強い共感を持ちながら話を聞いていきました。

その後、GoToさんがまず明確にそのスタンスが間違っていることを発生したあたりまではそれなりに聞くような話だったのですが、そこから地道に活動を続け、100点ではないにしろ確実に過程を踏みながら障害を学習の一つとして捉えていく道のりの話になったあたりからは組織の強さやGoToさんを中心とした色々な方々の凄みがひしひしと伝わってきました。
特に、スクフェス大阪で得た学びを次の日から行動に移して次の次の日にはDirtをやっているのは本当にすごくて、きっかけ一つでここまで大きな変革が起きるのか...!というのを実感しました。

最後は、そうした活動をふりかえって再現可能性を高めるようなまとめに続いていったのですが、ここでもいくおさんらしい切り口で、相手を信頼して尊重した結果起きたことを見事に言語化してくれており、素晴らしかったです。

いくおさん自身や会社全体がどのように変革していったのか？というのを、発表の中で強弱をつけながらめちゃくちゃリアルに伝えているのが本当にすごくて、最高の発表でした。
また、途中にあった＼DevOps! DevOps!／のスライドを見たときに「これは絶対叫ぶんだろうな」と思ったのですが、期待を超える叫びを見せてくれて大満足でした。

Understanding deeper needs

自分の思い込みや知っているプラクティスに引っ張られてしまった結果相手が求めていたことを見失ってしまうという話は本当にあるあるですが、そういったことを防ぐために、プロダクトリサーチのスペシャリストであるAras Bilgenがネガティブ/ポジティブ両側面から話すことや、感情的に声を大きくしたり話を遮ったりしないように気をつけているというのを聞くことができて面白かったです。

技術的なセッションががんがんと続く中で、「なぜDevOpsなのか？」というところに改めて立ち返れるセッションで、カンファレンス全体のセッションの中で非常にいい味を出していると感じたセッションでした。

また、さらっとAras Bilgenが話していたことに驚きました。

『品質』カルチャーの育て方 ～DevOpsの世界にフィットする5つの方法～

DevOpsの文脈で自動化を推進していくと、自動化に対する恐怖を抱く人が取り残される可能性がある&自動化に対する恐怖は人それぞれ異なる理由で持っている可能性がある、という話は、自分がこれまで持ったことのない観点だったので、自身の内省をするきっかけをもらうことができました。

フィードバック周りの部分を中心に、話を抽象化していく中でちょっと主語が大きくなりすぎているような気もしましたが、具体的な事例と課題意識がセットで語られていたので話としては頭に入ってきやすかったです。

モニタリングからオブザーバビリティへ

オブザーバビリティに関して初心者でもわかるように丁寧な説明をしてくれた見事なセッションでした。

スライドがシンプルで分かりやすかったというのもありますが、そんなに聞き慣れないような言葉であっても、実際のシステムで説明をすると具体的にどういうことなのか？というのを一個一個丁寧に説明してくれたので、表層的に単語の意味だけ知っていた言葉もだいぶ理解が深まりました。

また、プレゼンテーションがすごく上手だったので、ちょっとした小話や具体例を交えながら楽しくオブザーバビリティの話を聞くことができるあっという間の45分間でした。

Fail Fast, Succeed Faster ~ DevOpsで上手に早く失敗する

テストがこけていることにいち早く気がつけるためにしたほうがいい技術的な取り組みの紹介が具体的な例をもとに説明されていた良いセッションでした。

並列実行しているシチュエーションでは、テストが一つこけるとコケた他のテストに引っ張られて無駄にクレジット消費してしまうみたいな話はあるあるなので、バッチ分割を使いましょうというのは納得感がありました。

また、まずはマシンスペックを最適なものにしましょうというのは、元も子もないような話ですがなんだかんだ一番効くことが多いという実感がめちゃくちゃあるので、テストで上手に早く失敗するための第一歩として適切な例だと感じました。

ノリと組織　Groove & Organizations

魂を揺さぶるようなプロダクトをどうやって作っていくのか？というのを、プレゼンテーションの中で体現し続けてくれたように感じる講演でした。

プロダクトを生み出すのは人であり、その人の魂を揺さぶるような感動が起こせてこそその人たちがまた別の人の魂を揺さぶるようなプロダクトを作ることができるというのは本当にそのとおりだなあと感じましたし、人の魂を揺さぶるためにポリゴン・ピクチュアズで行われている取り組みの数々が余すことなく公開されていたのも、非常に高い希少価値を感じるkeynoteでした。

塩田さんの情熱に触れたくて、久しぶりに思わず何度も再生したくなるようなkeynoteが聞けて、この話が聞けただけでも参加して満足！という最高のkeynoteでした。

DevOps推進におけるカルチャー醸成の重要性 ～アサヒビジネスソリューションズ株式会社様の事例～

次々と問題が起きるような環境を研修の中でロールプレイングをすることで、自分たちの普段の活動と重ね合わせ、危機意識が芽生えたしそういったときにどのように動いたらいいのかが当事者意識を持って知れたというのが印象的でした。

長期戦を覚悟しても、研修で得たものを会社の中でものにしていこうと根気強く現在に進行形で組織変革に取り組まれているのは素敵だなあと感じました。

Identity-Native Infrastructure Access Management

ホスティング環境における典型的な攻撃パターンとその対策を丁寧に説明してくれたので、ホスティング環境でどういう状態だとどのような問題が起きるのかが分かるセッションでした。

特に、Connectivity, Authentication, Authorization, Auditの観点からVPNのSSO/LDAPO認証にまつわるリスクが説明され、ここに対してk8sでどのような対応策が考えられるのか？という話は、実際に馴染みがある構成も出てきたのでリスクと対策のイメージがわきやすかったです。

自分の場合はセキュリティに対する知識がまだまだ不足しているので、こうしたセキュリティ系セッションがカンファレンスで聞くことができるのは、すごくありがたいです。

How DevOps & the "Every thing as code" paradigm are powering l'Oréal's Beauty Tech transformation

ロレアル社さんの開発を支えている技術基盤について自動化をキーワードに、その基盤構成で気をつけられていることや具体的な技術要素の話がたっぷりと語られている発表で、めちゃくちゃよかったです。

各技術要素のベストプラクティスにしたがって教科書通りに実現されていてめちゃくちゃすごいなあと思うとともに、ベストプラクティスが適用可能な部分についてはかなり細かい部分まで気を払っている様子がプレゼンテーションでは語られていて、自分たちだけしかできない仕事というのに徹底的にフォーカスを当てている様子が伺えたのが非常によかったです。

How I made Prometheus Remote Write 60% cheaper in one week

Prometheus Remote Writeの新フォーマットを活用することでコストの節約を測った結果をプレゼンテーションしてくれました。

Prometheus Remote Writeのデータ送信方式を考慮して如何にバッチサイズを大きくするのか？という話はたしかにそうだよね、という感じで、イメージ通り大幅にコスト削減ができている実験結果も見ることができてよかったです。

冒頭にはPrometheus Remote WriteやPrometheus自体の説明が簡単にあった他、フォーマットの話をする際には実際に新旧フォーマットの差分を比較して説明してくれたので、イメージがわきやすく聞きやすい発表でした。

Code your Cloud Infrastructure with Jenkins and Terraform

AnsibleやTerraformといったIaCがアジャイル開発やDevOpsに与える影響と、それを踏まえてIaCがアジャイル開発やDevOpsになぜ必要不可欠なものなのか？という話を聞くことができました。

自動化との相性の良さやスモールスタート的なコスト観点からの話、スケーリングの話など大まかな概要の説明があった後に、技術要素の具体的な比較検討の話がされるという構成で話が入ってきやすかったです。

技術要素の部分ではPuppet, ChefといったTraditionalな要素からTerraformに至るまで変遷を辿りながらの説明があったので、技術要素のつながりや関わりが聞けて非常に楽しかったです。