自作のSRE課題発見ワークショップ “Eliminating toil”を開催した

Atsushi Sakai
Feb 7 · 9 min read

こんにちは。家族アルバム「みてね」のSREとしてシステム運用や改善をしている酒井です。

事業部の開発マネージャーも兼任しているため、いつもはエンジニアリングマネージャーネタが多めですが、そういう中でも地道にSREとしてシステムの改善活動もやらせてもらってており、今日はそっち系のお話です。

みてねのSRE

みてねにはSREチームがあります。2020年に入ってから、みてねのSREチームは「チーム内チーム」といった感じの構成を作り、以下のように細かく役割分担をするように変化しました。

  • 🐻(くまさん)チーム: トイルの排除、各種自動化、アプリケーションのアーキテクチャ・パフォーマンス改善など
  • 🦒(きりんさん)チーム: システム全体のコンテナ化・AWS EKS移行

という感じです。

🦒チームで行っている活動については、先日行われた弊社清水の発表資料によくまとめられておりますので、ぜひお読みください。

何が私たちのトイルなのか

本題にはいります。

SREの重要な仕事として「トイルの排除」があることはよく知られています。具体的な「トイル」についての話題はいわゆるSRE本を読んでいただくとして、簡単にまとめると「トイル」とは以下のように定義されるものであるとされています。

トイルの定義

  • 手作業であること
  • 繰り返されること
  • 自動化出来ること
  • 戦術的であること
  • 長期的な価値を持たないこと
  • サービスの成長に対してO(n)であること

こういった物事が、集中すべき本質的な仕事を阻害することは、この定義をみただけでもよくわかると思います。しかし、これは私個人の感覚としてですが、「トイル」とは本当によくできた言葉で、ともすれば便利ワード化してしまい、言葉だけが繰り返し消費され、課題の本質を見失い形骸化することを懸念として感じてきました。

また、逆にSRE本という非常に人気のある書籍において、定義が明示されているために、その定義に気を取られすぎて自分たちの現実的な課題とうまく結びつけられずに「これはトイルだ」「いや定義に沿ってないからトイルじゃない」というこれまた本質を見失いそうな議論が展開する懸念もありそうだな、と思っていました。

そこで私たち、みてねSREチームでは、「自分たちの仕事の何がトイルでそれはどういう課題なのか?」という問いを自らに投げかけることで課題を深掘りして本質的な「私たちのトイル」を見つける作業を試みました。

その際に利用したものが、私が自作してメンバーと一緒に取り組んだ課題発見ワークショップ ”Eliminating toil” です。今回はその中身をご紹介しようと思います。

課題発見ワークショップ “Eliminating toil”

※注意
このワークショップは、私の完全自作です。はっきりいってきれいに纏まっているわけではないと思います。しかし、できる限りうまくいくようメンバーに助けれながら実施してみました。

このワークショップの目的

このワークショップを終えたのち、SREチームのメンバー間で以下の3つの事柄を手に入れることができるような設計にしました。

  • 私たちにとって、「トイル」とは何なのか?の認識を合わせる
  • ︎トイルがどれだけ開発効率に影響が出ているかを理解する
  • トイルを「排除する」ための未来に向けた戦略を立てる

Phase 1. トイルの抽出とマッピング

まずは、SREチームメンバーみんなで「私たちのトイル」と思う仕事を付箋に書き出し、壁の象限内にマッピングしていきます。

デジタルなボードに書くのではなく、あえて手作業で付箋に書くようにした理由は、立ち上がったり体を動かしたりして、脳を柔軟に働かせるためです。

そして、用意した壁の象限とは以下のようなものです。

壁にこのような図を描き、付箋をマッピングしていく

また、以下の2点は付箋に書くときのガイドラインです。

  • これまでSREチームで経験してきた仕事の中から、「トイル」と思われる仕事をできる限り具体的に書き出してください。「経験した仕事」に限定したのは、想像だけで曖昧な議論をしたくなかったからです。
  • 他人が先に貼ったものと同じ内容を書いても良いです。自由に自分が思った場所に貼ってください。

解説

「トイルをなくす難易度」とは?
今あるトイルを排除するとしたらどのくらいの難易度なのか?を表現しています。

  • SS: 数時間程度ですぐ終わるのに、何故か解決していないトイル
  • S: 解決策はわかっており、1~2日程度で対応は可能
  • M: 解決策がわかっているが、対応するには1スプリントくらい試行錯誤しながら開発する必要がある
  • L: 解決策がわからない。どのような開発をすれば解決できるか、見当もつかない

「現在対応にかかっている時間」とは?
そのトイルは一回あたり対応するのにどのくらい作業時間がかかっているのか?を表現しています。

  • SS: 数分~30分程度の小さな手作業
  • S: 1~3時間くらいの手作業
  • M: 1日くらいはかかる複雑な手作業
  • L: 2日以上時間をかけてじっくり解決しなくてはいけない手作業

さて、ある程度時間をかけて Phase 1 が完了したら、私たちが抱えている「トイル」の一覧が、以下の意味づけをされて出来上がっているとおもいます。

  • 私たちがトイルと認識している仕事はどんなものか
  • 1件ずつ解決するのにどのくらいの作業時間がかかっているのか
  • 排除するための開発をするとしたらどのくらい難易度が高い開発なのか
実際に私たちが作成したトイルの一覧

Phase 2. トイルを深掘りする

次に、Phase 1で作り上げたトイルの一覧の全てのトイルに対して、さらに深掘りする議論をしながら、各トイルへの理解をより立体的にしていきます。

主に、以下のような議論を付箋ひとつずつに対して行っていきます。

  • これは本当にトイルですか?(いわゆる「オーバーヘッド」など)
  • サービスの成長に対してO(n)な課題ですか?(O(n)なのであれば、付箋に「O(n)」と書いていきました。)
  • このトイルの発生する頻度は?(付箋に「高・中・低」と描いていきました。)
  • 象限の置く場所についての認識はあっていますか?

そして、Phase 2 が完了すると、Phase 1では時間・解決の難易度という平面的な理解しかできていなかったトイルに対して、さらにSRE本の定義とのすり合わせも出来、より自分たちのトイルに対しての理解が深まっていきます。

Phase 3. 私たちの仕事に与えている影響度を理解する

次に、ここまで理解してきた「私たちのトイル」への対応が仕事全体の中でどの程度支配してしまっているのかをできる限り理解してみます。

理解するための基準としたのは以下です。

“GoogleのSREの四半期ごとの調査によると、トイルに費やされている時間は平均33%”

抜粋:: Betsy Beyer “SRE サイトリライアビリティエンジニアリング”

絶対的な時間を完璧に導き出す意味はあまりないと思ったので、SRE本に記載されていた上記のようなGoogle社内の調査結果と比較して「私たちのトイルが多いのか少ないのか」という理解だけをしてみようと試みました。

そのために、「現在対応にかかっている時間」と「発生頻度」を組み合わせて簡単に計算してみました。

ここで、発生頻度に対して仮の具体的な回数を付与します。

  • 高頻度 = 1日に1回必ず発生している
  • 中頻度 = 1週間に1回程度発生している
  • 低頻度 = 月に1回程度発生している

この工数感のもと、出ているトイルをすべて足し合わせて、月間のメンバーの就業時間合計の33%を超えているかどうかを判断していきました。

少しわかりにくいかもしれませんが、これは例です。

  • 営業日 20 days
  • SREチームメンバーが5人の場合の就業時間合計 = 8 hours * 3 people * 20 days = 480 hours
  • 高頻度 かつ SS トイルが 10件 = 30 min. * 10 * 20 = 100 hours
  • 中頻度 かつ S トイルが 5件 = 3 hours * 5* 4 = 60 hours
  • 低頻度 かつ L トイルが 1件 = 16 hours * 2= 32 hours
  • トイルの対処にかかっている合計時間 = 192 hours

この場合、トイルがチームの就業時間の 40.0 % を占めてしまっていることがわかります。これはGoogle SREチームの平均 33% を超えてしまっており、改善の余地があるということを示しています。

「私たちのトイル」が仕事にどのような影響を及ぼしているかを把握することができたところで、ワークショップはお開きにしました。

戦略を立てる

この後は、「どうやってトイルを減らしていくか?」という戦略を立てていくわけですが、ワークショップで理解したトイルを排除するために我々は以下のような戦略を持って取り組むことにしました。

  • 高頻度かつO(n)な案件については緊急度が高く最優先で対応する。
  • 実はいくつかの課題はEKS/コンテナ移行を実施した結果、自然に解決できる可能性があるので移行チーム(🦒)で巻き取る。
  • それ以外は「難易度が低く高頻度に発生しているトイル」(つまり、思考停止してしまって時間を無駄にしているような余計な仕事)からバックログに載せて解決するための開発を順次行っていく。

まとめ

このように、今回ワークショップを開催したことで、現在自分たちが向き合っている仕事に対して、「トイル」という便利ワードに惑わされず、現実として何が「トイル」であり、その「トイル」はどの程度、仕事に悪影響を及ぼしているのか?それを解決する優先度は?ということを地に足をつけて議論することができました。

また、情報を整理して、混沌とした状況を脱することで見通しも良くなり、結果的に「トイル」を対策していくメンバーのモチベーションにも繋げることができ、ワークショップのチーム内での満足度は高かったようです。

対象の技術が非常に幅広く、日々割り込みタスクがどうしても多くなり、混沌としがちなSREという仕事において、少しの工夫と少しの時間をかけることで混沌とした状況を冷静に振り返ることができるので、四半期に一回、例えばOKRを決める時などに、一度落ち着いてこのワークショップのようなアクティビティを実施して自分たちの仕事の進め方を見直してみることをお勧めしたいと思います。

mixi developers

ミクシィグループのエンジニアやデザイナーによるブログです。

Atsushi Sakai

Written by

mixi developers

ミクシィグループのエンジニアやデザイナーによるブログです。

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade