DevOpsDays Tokyo 2023の参加レポート

# DevOpsDays Tokyo2023に参加して
4月18日、19日にDevOpsDays Tokyo 2023に初めて参加してきました。
Scrum Festなどはオンラインで何度か参加したことはあったのですが、今回は初めて現地参加しましてとにかく楽しくて学びが多い2日間でした。
スケジュール：https://confengine.com/conferences/devopsdays-tokyo-2023/schedule

# Day1
## Keynote DevOps, Development Cadence and the Product Life Cycle
レガシーコード改善ガイドの著者Michael Feathersさんの講演でした。
まずはAgile開発の歴史のお話しがありました。
その後Agile開発は大規模な問題には対応できないという話にシフトしていきました。

色々とチーム開発の課題感について話されていましたが、一番印象的だったのは **リズム** が大切だという点です。
例えば組織としてはリソース効率の観点で開発チームをフルで動かす事が至上命題のような所もあると思います。
人間にも日中は活動して、途中休憩を挟みながら、趣味の時間もあって、夜はゆっくり休む、というようなリズムや緩急がああると思います。
これを開発チームにも当てはめれば緩急がつくのは当然だよねという考えです。
Four Keysの観点からDeploy頻度を高めていくことは大切かもしれないけど、スローダウンする時もあって良いとの事です。
大切なのは必要な時に集中できるチーム環境だよねという点です。
例え何かあって一度止まってしまったとしても、自然の緩急と捉えて再開するリズムが大事という考え方がとても大切だという事です。

## ファクトから始める改善アプローチ Ep. 2 〜 Four Keys の先にあるアウトカムに向き合ってみた 〜
スライド：https://speakerdeck.com/visional_engineering_and_design/devopsdaystokyo-2023

ビズリーチさんは1年前のDevOpsDays TokyoでFourKeysにまつわる発表をされていたとのことで、今回はそのFourKeysで計測したパフォーマンス指標からアウトカム指標に繋げていったのかの話でした。

発表の中で `「アウトプットと距離が遠いアウトカム指標ほど開発組織以外（外部要因）の影響を大きく受ける可能性が高まる」` という文脈があったのですが、これは私も計測した事はないのですがまさにその通りだなと思いながら聞いていました。
エンジニアとして働いていると `「この機能の速度を速くしたい！」` など外部要因とは関係がない部分での性能に目が行きがちなんですが、アウトカムで考えると外部要因と届けたい価値から逆算する方が色々ハッピーなんだろうかと思いました。

また職種によって見ているアウトカム指標が違う事によるすれ違いについても言及されていました。
アウトカム指標が合わせられることで顧客により良い価値を届けられるという点はその通りだなと思いながら、じゃあ果たして今の自組織のエンジニアが見ているアウトカムってなんだろうという思いにもなりました。
そこがBizメンバーやPdM（弊社ではプロデューサー）と違うって事は大いにあり得そうでして、ズレてることを認識するためにもそもそもエンジニア組織でFour Keysをまずは計測することの重要性を感じました。

## 変更障害率0%よりも「継続的な学習と実験」を価値とする〜障害を「起こってはならないもの」としていた組織がDirtの実施に至るまで〜
スライド：https://speakerdeck.com/navitimejapan/devops-transformation-in-navitime-japan
「障害は起きてはならないもの」なので障害0件が目標としていた事で、「疑わしいものは障害報告せずにこっそり処理する」というハックが横行してしまったという文化から、「障害は対処できるものだ、そこから学びを得るものだ」という文化に変えていった話でした。
きっかけはScrum Fest Osaka2021でDiRTに出会った人がそれを社内にすぐに持ち帰った事からだったようでして、ここで私が学びを得たのは「社外の勉強会で得た熱は早いうちに社内に伝えるべき」という事です。
今回の例で言うと社外で得た熱を2日後には既に社内に伝える準備をして動いていたことです。
こうして私はDevOpsDaysTokyoのレポートを2週間経った今書いているのですが、素晴らしいカンファレンスだったと感じたにも関わらず悲しいもので当日と次の日の熱と比べると落ち着いてきているのは間違いありません。
冷静になって見えてくるものも間違いなくあると思ってはいますが、ある程度熱をそのままに行動していく事で伝えられるものもあると思ってます。

# Day2
## Keynote ノリと組織　Groove & Organizations
[株式会社ポリゴン・ピクチュアズ](https://www.ppi.co.jp/)の代表取締役塩田周三さんのKeynoteから二日目は始まりました。
参加者がワイワイコメントを書くDiscordがあるのですが、そこに流れるコメントを見返すと `「熱くなった」` と言う感想がとても多かった印象です。
私個人としても心が熱くなった1時間だったと今振り返っても感じるKeynoteでした。

全体として題名の通り **「どう組織にノリをもたらせるか」** と言う趣旨のお話でした。
私個人としては最近サイモン・シネックの[WHYから始めよ!](https://books.rakuten.co.jp/rb/11466366/)を読んだ事もあり、WHYが明確になることでストーリーが描きやすくなり、それを伝えていく事の面白さと巧さの部分がとても刺さった点でした。
ストーリーの部分で言うと[なぜ科学はストーリーを必要としているのか](https://books.rakuten.co.jp/rb/15472616/)をひけあいに出されており、And But Therefore(ABT型)と言う語り方について紹介されてて、すぐにポチったのでこれから読みます。

## OST 
OST（Open Space）なるもの初めての経験でして、全く未知数だったんですがめちゃくちゃ楽しかったです。
 `「セッションも面白いけど、OSTがしたくてDevOpsDays Tokyoに参加した！」` なんて人もいるとかいないとか、そんな噂を耳にしました。
私は来年もDevOpsDaysTokyoに参加したい！と思ってるのですが、理由が `「セッションが面白かったのと同じくらいOSTをやりたい」` からです。
じゃあOSTってなんなの？って話だと思うのですが、それは実際にDevOpsDaysTokyoの説明にも使われていた[このスライド](https://www.docswell.com/s/matsushu83/587J1K-2023-01-13-093430#p1)を見ていただけるのが一番良いかと思います。

テーマが全て面白そうで分身して全て参加したかったぐらいなんですが、その中でも私が参加したもので何点かピックアップしてレポートします。

### AIとDevOps
昨今話題に上がっているChatGPTとDevOpsはどうコラボレートしていくかって話をしていました。
私は参加が途中からになってしまって後ろで聞き専だけしていたので全部はわかってないのですが、かなりの人数が集まっていて話も盛り上がっていました。
その中で `「AIにも人権がある。人間が得意な事でAIが苦手なことをわざわざAIにやってもらうのはどうか」` と言う文脈の意見が興味深かったです。
よく聞く論調だと `「AIによって私たちエンジニアの仕事がなくなるかもしれない。どうしよう？」`などを聞くのですが、どんな事でもAIにやらせてその先に何があるかという言う感覚ではなく、うまくAIとコラボレートすると言う感覚で話されていた点が、個人的には新しい感覚でAIとの協働に興味を持つようになりました。

### DevOps組織において専任QAは必要か？
この議題は実際のQAエンジニアの方が上げたものでして、今の組織でも `QAエンジニアの方に開発チームにジョインしてもらってクロスファンクショナルなチーム` を模索していたのでとても興味深い話でした。
中でも実際にクロスファンクショナルで動いてみたチームの方がいてその方の体験談がとても勉強になりました。
起きた事象としては以下とのことです。

- チーム内QAとなってしまい、コラボレートはしてなくて単純にそのQAメンバーに全てのテストをやってもらうだけになった
- QAチームで共有できていたナレッジ共有がなくなってしまった

なのでその方の体験としてはそのQAメンバーのモチベーションだったり積極度次第では意図したクロスファンクショナルを実現することは難しかったという事です。
だからと言ってクロスファンクショナルである事を否定する意図はなく、きっとその試行錯誤から見えてくる学びもたくさんあると思ってます。

### 評価とモブ
このテーマは一緒に参加してた同僚が上げてくれたテーマです。
私も同じようなテーマを上げていたので、合わせて議論をしたOSTとなりました。

モブで動いているとMGRから見ると評価が難しいという話がよくあり、それをもとに議論をした会となりました。
パワーワードで `「評価は人類には早すぎる」` と言う言葉も出てくるぐらい、実際に誰かを評価するってことはとても難しい話だと思います。
私はMGR経験がないので想像でしかないのですが、わかりやすい個人のアウトプットと言うものが見えにくくなるから、相対的に評価をつけるのが難しいのだろうかと思ってます。

ただ中には「モブは個人としての成長を感じづらい」と言うご意見もありまして、これはきっと個々人の趣向などと合う合わないも関係するから `「モブは絶対いいよ！」` と押し付けるものではないと思ってます。

# まとめと感想
全体的には初DevOpsDays Tokyo、参加して本当に良かったです。
会社を超えたある程度近い問題意識を持つ人たちが集まった場となっていて、 `「あーでもないこーでもない」` とお互いに学びを深めあえる環境だったと思いました。
`「よし、私も来年参加までに色んなことに挑戦してまたワイワイしたい」` と勝手に熱い気持ちになりまして、コミュニティ活動っていいなぁと思った2日間でした。