家族アルバム「みてね」のSREとしてシステム運用や改善をしている酒井です。事業部の開発マネージャーも兼任しているため、いつもはエンジニアリングマネージャーネタが多めですが、そういう中でも地道にSREとしてシステムの改善活動もやらせてもらってており、今日はそっち系のお話です。みてねのSREみてねにはSREチームがあります。2020年に入ってから、みてねのSREチームは「チーム内チーム」といった感じの構成を作り、以下のように細かく役割分担をするように変化しました。EKS移行という感じです。🦒チームで行っている活動については、先日行われた弊社清水の発表資料によくまとめられておりますので、ぜひお読みください。何が私たちのトイルなのか本題にはいります。SREの重要な仕事として「トイルの排除」があることはよく知られています。具体的な「トイル」についての話題はいわゆるSRE本を読んでいただくとして、簡単にまとめると「トイル」とは以下のように定義されるものであるとされています。手作業であること繰り返されること自動化出来ること戦術的であること長期的な価値を持たないことサービスの成長に対してO(n)であることこういった物事が、集中すべき本質的な仕事を阻害することは、この定義をみただけでもよくわかると思います。これは私個人の感覚としてですが、「トイル」とは本当によくできた言葉で、ともすれば便利ワード化してしまい、言葉だけが繰り返し消費され、課題の本質を見失い形骸化することを懸念として感じてきました。逆にSRE本という非常に人気のある書籍において、定義が明示されているために、その定義に気を取られすぎて自分たちの現実的な課題とうまく結びつけられずに「これはトイルだ」「いや定義に沿ってないからトイルじゃない」というこれまた本質を見失いそうな議論が展開する懸念もありそうだな、と思っていました。そこで私たち、みてねSREチームでは、「自分たちの仕事の何がトイルでそれはどういう課題なのか?」という問いを自らに投げかけることで課題を深掘りして本質的な「私たちのトイル」を見つける作業を試みました。今回はその中身をご紹介しようと思います。toil”※注意このワークショップは、私の完全自作です。いってきれいに纏まっているわけではないと思います。できる限りうまくいくようメンバーに助けれながら実施してみました。このワークショップの目的このワークショップを終えたのち、SREチームのメンバー間で以下の3つの事柄を手に入れることができるような設計にしました。トイルの抽出とマッピングまずは、SREチームメンバーみんなで「私たちのトイル」と思う仕事を付箋に書き出し、壁の象限内にマッピングしていきます。デジタルなボードに書くのではなく、あえて手作業で付箋に書くようにした理由は、立ち上がったり体を動かしたりして、脳を柔軟に働かせるためです。用意した壁の象限とは以下のようなものです。壁にこのような図を描き、付箋をマッピングしていくまた、以下の2点は付箋に書くときのガイドラインです。これまでSREチームで経験してきた仕事の中から、「トイル」と思われる仕事をできる限り具体的に書き出してください。「経験した仕事」に限定したのは、想像だけで曖昧な議論をしたくなかったからです。他人が先に貼ったものと同じ内容を書いても良いです。自由に自分が思った場所に貼ってください。「トイルをなくす難易度」とは?今あるトイルを排除するとしたらどのくらいの難易度なのか?を表現しています。どのような開発をすれば解決できるか、見当もつかない「現在対応にかかっている時間」とは?そのトイルは一回あたり対応するのにどのくらい作業時間がかかっているのか?を表現しています。完了したら、私たちが抱えている「トイル」の一覧が、以下の意味づけをされて出来上がっているとおもいます。1で作り上げたトイルの一覧の全てのトイルに対して、さらに深掘りする議論をしながら、各トイルへの理解をより立体的にしていきます。以下のような議論を付箋ひとつずつに対して行っていきます。これは本当にトイルですか?(いわゆる「オーバーヘッド」など)サービスの成長に対してO(n)な課題ですか?(O(n)なのであれば、付箋に「O(n)」と書いていきました。)このトイルの発生する頻度は?(付箋に「高・中・低」と描いていきました。1では時間・解決の難易度という平面的な理解しかできていなかったトイルに対して、さらにSRE本の定義とのすり合わせも出来、より自分たちのトイルに対しての理解が深まっていきます。私たちの仕事に与えている影響度を理解する次に、ここまで理解してきた「私たちのトイル」への対応が仕事全体の中でどの程度支配してしまっているのかをできる限り理解してみます。理解するための基準としたのは以下です。サイトリライアビリティエンジニアリング”絶対的な時間を完璧に導き出す意味はあまりないと思ったので、SRE本に記載されていた上記のようなGoogle社内の調査結果と比較して「私たちのトイルが多いのか少ないのか」という理解だけをしてみようと試みました。そのために、「現在対応にかかっている時間」と「発生頻度」を組み合わせて簡単に計算してみました。ここで、発生頻度に対して仮の具体的な回数を付与します。月に1回程度発生しているこの工数感のもと、出ているトイルをすべて足し合わせて、月間のメンバーの就業時間合計の33%を超えているかどうかを判断していきました。わかりにくいかもしれませんが、これは例です。占めてしまっていることがわかります。超えてしまっており、改善の余地があるということを示しています。「私たちのトイル」が仕事にどのような影響を及ぼしているかを把握することができたところで、ワークショップはお開きにしました。戦略を立てるこの後は、「どうやってトイルを減らしていくか?」という戦略を立てていくわけですが、ワークショップで理解したトイルを排除するために我々は以下のような戦略を持って取り組むことにしました。高頻度かつO(n)な案件については緊急度が高く最優先で対応する。実はいくつかの課題はEKS/コンテナ移行を実施した結果、自然に解決できる可能性があるので移行チーム(🦒)で巻き取る。それ以外は「難易度が低く高頻度に発生しているトイル」(つまり、思考停止してしまって時間を無駄にしているような余計な仕事)からバックログに載せて解決するための開発を順次行っていく。まとめこのように、今回ワークショップを開催したことで、現在自分たちが向き合っている仕事に対して、「トイル」という便利ワードに惑わされず、現実として何が「トイル」であり、その「トイル」はどの程度、仕事に悪影響を及ぼしているのか?それを解決する優先度は?ということを地に足をつけて議論することができました。情報を整理して、混沌とした状況を脱することで見通しも良くなり、結果的に「トイル」を対策していくメンバーのモチベーションにも繋げることができ、ワークショップのチーム内での満足度は高かったようです。対象の技術が非常に幅広く、日々割り込みタスクがどうしても多くなり、混沌としがちなSREという仕事において、少しの工夫と少しの時間をかけることで混沌とした状況を冷静に振り返ることができるので、四半期に一回、例えばOKRを決める時などに、一度落ち着いてこのワークショップのようなアクティビティを実施して自分たちの仕事の進め方を見直してみることをお勧めしたいと思います。developersミクシィグループのエンジニアやデザイナーによるブログです。developersFollowミクシィグループのエンジニアやデザイナーによるブログです。UpgradeAboutHelpLegal。