DevOpsDaysTokyo2023のレポートです。自分が参加した範囲のものを全体的にまとめています。

DevOpsDaysTokyoとは

2009年にベルギーのヘントで初開催され、
https://legacy.devopsdays.org/events/2009-ghent/
以降世界各地で開催されているDevOpsに関する国際カンファレンスの東京版です。

公式サイトのトップページを見るとこれから開催予定のイベントロゴを見ることができますが、
これだけでも非常にさまざまな国と地域で開催されていることが見て取れますね。
（東京は今年は開催終了したのでもう載っていません）
https://devopsdays.org/

DevOpsDaysTokyoの公式ホームページはこちらです。今年は4/18（火）、4/19（水）に開催されました。
https://www.devopsdaystokyo.org/

国際カンファレンスということで海外からもスピーカーを招いており、
講演には同時通訳も提供されます。
海外の著名な本の作者やDevOps実践者から話を聞いたり質問したりする貴重な機会でありつつ、
もちろん国内での最新の取り組み事例の紹介も充実しています。
参加方法は現地参加とオンライン参加の2通りで、筆者は昨年に引き続きオンラインで参加させてもらいました。

1日目

Hall-A 講演 DORAメトリクスの4Keysにまつわる諸々

Hall-AにずっといたのでHall-A内での話をします。
キーワードとして、DORAメトリクスの4Keysをどうやって使おうか、という話が基調になっていた印象です。

DORAメトリクスの4Keys

  • デプロイ頻度
  • 変更のリード タイム
  • 解決までの平均時間
  • 変更失敗率

4keys自体は2020年くらいにはGoogleのGCPブログで取り上げられたりしていたようですが、
DevOpsの成果の計測というテーマは去年の同イベントではあまりなかった（筆者が忘れているだけの可能性もあり）気がするので、
今年のカラーという印象を受けました。

これを組織の文脈の中で具体的に定義して計測を試みたノバセルさんの講演
4keys 導入のリアル〜ひと通りやってみて分かったこと〜

さらにその先にあるビジネス指標との連動性を確認するにはどうするかというビズリーチさんの講演
ファクトから始める改善アプローチ Ep. 2 〜 Four Keys の先にあるアウトカムに向き合ってみた 〜

が連続していて大変興味深かったです。
指標系に共通することかもしれませんが、
エフェクティブに活用するには指標の定義を組織のプロセスやカルチャーに合わせて具体化する必要があるというメッセージが印象的でした。

例えば、DORAの指標で
「正常な本番リリースの頻度」とされているものを
「スプリント内でmainブランチにマージされた日数」としたり、
「コミットから本番環境リリースまでの期間」を
「スプリント内で完了したチケットの着手から完了までの日数」としたり・・・。
スプリントでタスクを回しているチーム、マージ＝デプロイの文化が根付いているチームなりの実運用が想像できるレベルに落とし込まれていて、具体化の例として非常に勉強になりました。

さらにその先にあるビジネス指標も見てみよう、というビズリーチさんの取り組みはとても野心的でした。
まだどうなるかはこれから運用してみて・・・ということでしたが、システムとビジネスのコラボレーションが進んでいるのが感じ取れてワクワクしました。

キーノート 「DevOps, Development Cadence and the Product Life Cycle」

数字をどう有効なツールにしていくか、という議論が深くされているのも面白かったですが、
「ただ、数字を追うことはどうしても人間性のある営みとかけ離れてくるもので・・・」という話がキーノート DevOps, Development Cadence and the Product Life Cycle でまずされていたのも振り返ると良いプログラムだったなと感じました。
登壇者は『レガシーコード改善ガイド』 の筆者、Michael Feathersさんです。

この講演の中では、指標を追うことの落とし穴を「ただ継続的に指標を追っていると常にメンバーをフル稼働させてしまう」と指摘し、
その対策として「エピソディックな開発」が提案されました。

エピソディックな開発という言葉には馴染みがありませんでしたが、

「開発チームみんなで意思決定を共有し、
まずエピソード1,終わったら2...
と区切りのある章を追うように開発していくことで、
忙しさに自然な緩急がつく」

というような話だと筆者は理解しました。
（開発チームにある程度の裁量は必要となります）

自然な緩急があるとはニアイコール、ライフサイクルがあるということです。
システムにもライフサイクルがあるとして、3Xという概念が紹介されました。

システムのライフサイクル-3X

  1. Explore あまりバックログは生じない、調査の段階
  2. Expand 投資的なバックログが増えてくる 、常にバックログがある状態で燃え尽きの危険がある
  3. Extract これ以上機能を増やすとシステムの本質が損なわれるので、一旦足を止め、今あるものを維持していく段階

上記はシステム全体のライフサイクルの話ですが、より短期的にもこういったサイクルはよく発生しているように感じました。
今が上記のどの段階に当たるのかを見極めて立ち回れると、燃え尽きのリスクや区切りの付け方を意識できて良さそうです。
会場からは「緩急がついている状態は実際に人間のパフォーマンスもいいと思う」といった意見も聞こえました。

2日目

OST（オープン･スペース・テクノロジー）

今回初の試みとして、OST（オープン･スペース・テクノロジー）が開催されました。
参加者が話したいテーマを自主的に持ち寄って、各々が情熱と責任を持ってオープンに議論をするという催しです。
▼参考
https://www.humanvalue.co.jp/keywords/ost/

こちらはzoomやmiroといったツールを用いてオンラインでも行われました。
私は最後に少しだけ参加しましたが、オープンな雰囲気の中でインプットとアウトプットが同時にできるというOSTのメリットを感じることができました。

miroに空の時間割のような枠を用意してそこにテーマを書いていったり、議論中のアウトプットに使ったりなど、フルリモートでも真似しやすそうな手法が知れたのもよかったです。

私が参加したのは「おすすめのチームビルディング」というテーマの時で、「仕事の話でまとまらずに人間性を深く知るにはどうしたら良いか」という議論が行われていました。

合宿をやった話やボードゲームの話、偏愛マップを用いた自己紹介の話などが上がり、
他社の方々の取り組みや知らなかったツールが知れて刺激的でした。
私からは会社で主催したテーマトーク会の話をし、
ポジティブフィードバックをもらえてモチベーションが上がりました。
テーマトーク会については別の記事で書きたいと思います。

キーノート 「ノリと組織　Groove & Organizations」

2日目キーノートは ノリと組織　Groove & Organizations と題し、
ポリゴン・ピクチュアズ さんという3DCGアニメーションの会社より、社長の塩田さんがいらして講演されました。
世の中にはその時勢ならではの出来事というものがいつもありますが、
変化を恐れずそこに「ノっていく」ことで、業界随一の老舗となるまで会社を存続できたと感じているそうです。

事象の結果としてはよくビジネス用語で「スピーディーに時代に適応してきた」とか言われるものに近いかなと少し思いましたが、
それを「ノリ」そして「グルーヴ感」と言い表すところに個々人の意思や主体性を重視する哲学が現れているように感じます。

実際に、社員は全員「ストーリーテラー」でなければならないとおっしゃっていて、「ストーリーテリング」とは何かというと
＝「自分ごと化」（ヒューマニティ）＋「ABT型の語り」（ナラティヴ）である
ということでした。

「ノリがいいということ」には「周りに合わせられること」と思いがちですが、むしろここで語られている本質は逆で、
自分のこととして物事を捉えたときに心を動かせるかという主体の話なのだなと、「ノリ」という言葉を捉え直しながら大変面白く拝聴しました。

（ただ、ということはつまりノリにも主体の数だけ多様性があるということなので、「ノリが合う」ことも「合わない」こともあるのだろうと念頭に置いておくことは大切かなと思います）

組織の話に戻すと、ただ受け身で変化を受け入れるという以上に「自分からノっていく」人々の集まりなのが肝であるというのは昨年のクラスメソッドさんの講演でも感じたところでした。
（クラスメソッドさんの講演では「踊る」と表現されていたような）
日々の業務に追われる中でも自分の主体をしっかり捉えておくこと、変化や新しいものにノれる体力とモチベーションを残しておくこと（＝燃え尽きないこと）、
そしてそれが可能になる組織と文化づくりが重要だと改めて感じました。

まとめ

計測、指標といったキーワードもHOTながら、
キーノートは両日人間性やライフサイクル、主体、ノリといった生身の人間にまつわる概念が共通しているのが興味深かったです。
数字というツールを組織の文化に合わせて使おうという話と、
前提として人間が仕事をするということを忘れてはいけないという話が両方されるのは非常にバランスが良いとも感じました。
OSTは初めて聞いたのですがすぐに持ち帰れそうな取り組みで、金曜日の午後にでもトライしたいです。
（弊社では金曜日の午後をDevOpsLabという、学習や実験の時間に当てる取り組みを行なっています）

筆者はDevOpsDaysTokyoの参加は2回目ですが、
今回は日々の業務に追われる中で自分のモチベーションや日々の取り組み、組織文化を見つめ直すきっかけになりました。

オンライン参加でしたが、質問もdiscordなどに書けば結構拾ってもらえ、
講演者や他の参加者とコミュニケーションがはかれるオープンな雰囲気もとても良かったです。
エンディングでファーストアクションを宣言するコーナーもありました。

勉強になり、刺激的かつ楽しいイベントでしたので、
DevOpsに興味があるが参加したことがない・・・。という方、人間的に働きたいよ〜という方、文化ってなんだろう・・・という方は来年は参加してみてはいかがでしょうか。

プロフィール

Yuri Masaki
Yuri Masaki
WEBアプリケーションの設計実装、PM（O）など経て現職へ。どちらかというと話をまとめるとか仕様整理するとかの方に強みがあります。