こんにちは、計測プラットフォーム開発本部システム部SREブロックの市橋です。2021年4月に新たに発足したチームで未経験ながらリーダーを任され、気づけば約2年が経過していました。これまでを振り返ってみると、まっさらな状態から安定したチームができてきたと感じています。今回は新米リーダーとして試行錯誤する中で、チーム状態を可視化して健全なチーム運営を目指した話を紹介します。

チーム状態の可視化を考えたきっかけ

リーダーを任された当初、チーム運営上の課題が色々あるのは認識していましたが、どこから手をつけるべきかが自分の中で判然としませんでした。メンバーの時に一個人として感じていた課題も、チーム全体を俯瞰して見た時にどれから優先的に取り組むべきか自信を持って判断できませんでした。まるで大海原のど真ん中にいきなり放り出された感覚でした。

そんな悩みを抱えていた時、全社に導入されているWevoxのアンケート調査依頼が来ました。これはチームや組織の状態やメンバーのエンゲージメントを可視化するツールです。メンバーの時は流れ作業のようにこなしていましたが、このときは一筋の光明に見えました。このツールによってチームの状態を把握できることはもちろんですが、それ以上にチーム状態を客観的な数値として知ることの重要性に気づけたことが何よりの収穫でした。

考えてみれば、これまで経験してきたSRE業務でも何かしらのメトリクスをもとにシステムやプロセスの状態を把握して、改善の手を打ちます。チームを運営するにあたり、チーム状態を知る指標がなければ、打つべき手は見えてきません。それに気づいてからはチーム状態を客観的に示す指標集めと分析に注力しました。

チーム課題の把握

まず取り組むべきと考えたことは、チームの開発生産性を可視化することです。ここでの開発生産性は特定の期間内に遂行できる作業量の意味で使います。これを優先すべきと判断したのは、先のWevoxの調査でチームのストレス値が高いという課題を把握でき、その解決のために必要だと考えたためです。尚、ストレス値が高いことを課題として認識できたのは、他の項目が概ね全社平均を上回っていたのに対してこの項目だけが顕著に低かったためです。

一口にストレス値が高いと言ってもストレス要因は人それぞれ異なります。そのため、メンバーと1on1を実施して一人ひとりの考えを聞いて深堀りしていきました。その中で次の意見が主となっていることがわかりました。

特定のメンバーに業務が集中して負荷が高くなる。
無尽蔵に湧きでるチケットの対応に常に追われている感覚があり、終わった感がない。

当時はチームが少人数という事情とSREの差し込みタスクが多いという業務特性が相まって、Toil¹に対応しながら中長期的に取り組む改善タスクにも対応していました。やりたいことはたくさんあってもToilに阻まれて思うように進捗が出せないため、それが焦りとなってストレスを増長させている状況でした。また、一部の知見が特定のメンバーに属人化しており、業務負荷が特定のメンバーに集中することも度々ありました。そのような空気感を感じつつも、他のメンバーの状況が見えづらいことでフォローしづらいということが起きていました。

スクラム導入

スクラムの狙い

上記の課題に対して、チーム運営のスタイルにスクラムの要素を取り入れることで改善に近づけると考えました。スクラムに期待したことは次のとおりです。

チームのベロシティを把握して適切な業務量に調整する
他のメンバーの状況を見える化してフォローしやすくする
振り返り頻度を上げて課題を把握する

弊チームのスクラムの流れは以下の図のとおりです。各セレモニーについては一般的なスクラムと概ね同じなので、個々の内容の紹介は割愛させていただきます。

スプリント期間は一週間に設定しています。前述の通り差し込み対応が多いため、スプリントの期間を短くすることでタスク整理の頻度を上げ、計画外のタスクをハンドリングしやすくする狙いがあります。また、緊急性が高くなければ無理にスプリント内で対応せず、次のスプリントに回す判断もしやすくなります。

ここからはスクラムの導入効果について見ていきます。

導入効果

チームのベロシティを把握して適切な業務量に調整する

メンバーへのヒアリングから課題の一端は業務量にあることがわかったので、考えられる対策は無理なく対応できる適切な業務量に調整することです。そのためには、当然のことながら「無理なく対応できる適切な業務量」を把握できていることが前提となります。これを把握するために弊チームでは作成したチケット全てに対してプランニングポーカーを行い、チーム全員で見積もることにしました。

プランニングポーカーのツールには SlackのPoker Plannerを利用しています。メンバー全員が使い慣れたツール上で見積もりから議論まで完結できるので、オーバーヘッドが少なく運用できています。流れは以下のようになります。

slackから/ppコマンドを実行し、プランニングポーカーを開始する
依頼されたメンバーはチケットを見積もり、ストーリーポイント（以下、spとする）を投票する
投票結果が表示される。見積もりの値で意見が割れたらスレッド内で議論して適切なspを設定する
対象のチケットに決定されたspを転記する

プランニングポーカー時の基本的なルールは次の2点です。

見積もりの値がメンバー間で異なる際は必ず相談して決める
5pt以上の場合は原則としてチケットの分割粒度を見直す

メンバー間で見積もりの値が合わない原因の多くは、チケットに記載されている情報（目的や背景）の不足や完了条件が曖昧なことで、このチケットで実現すべきことをイメージできないことで引き起こされます。それに対して時間を取って相談することで、全員が共通認識を持てるように徹底しました。

このルールをチームで運用して8スプリント程度を回したところで、おおよそ無理なく捌けるspを把握できました。スプリントプランニングで各メンバーにアサインされているチケットのspの合計値が適正範囲に収まっているかをチェックすることで、働きすぎを防止しています。以下はスプリントプランニングで実際に見ている画面です。もし基準値を超えていれば、落とせるタスクはないか調整するルールとしています。

他のメンバーの状況を見える化してフォローしやすくする

上記により、特定メンバーへの業務負荷の偏りを可視化でき、負荷の高いメンバーのタスク量を調整できるようになりました。

一方、弊部はZOZOが掲げる戦略の3本柱の1つとして、新規事業を打ち出す役割を担っています。そのため、新サービスの開発案件がしばしば入ってきます。このような案件は不確定要素が大きくなりがちで、スプリントの計画時点では想定できなかったタスクや依頼が突発的に急増することもあります。デイリースクラムで声を挙げられる場は用意しているものの、余裕がなかったり、ついタスクを捌くことに熱中してヘルプを要請することを忘れてしまいがちです。そのような状態でもスプリントの区切りでベロシティを確認することで第三者が変化に気づけます。実際に確認しているベロシティは以下の図の通りです。

運用方法としては、ベロシティの目標値の下限と上限を定め、その範囲から外れたときに要因を分析しています。

目標値の下限を下回っている場合は、開発効率が落ちている要因を分析します。メンバーが休暇を取得したといった一過性の理由であれば問題視しませんが、チケットの粒度が大きすぎたり、アンコントローラブルな問題が起きてタスクを完了できない場合はチケットの完了条件を見直します。

目標値の上限を上回っている場合も、単に開発生産性が上がったと捉えるのではなく、要因を分析する必要があります。もし特定メンバーの負荷が上がっていれば、他のメンバーに業務負荷を平準化するよう調整します。この場合は実労働時間にも反映されるため、セットで確認しています。

上述のプランニングポーカーで全員がチケットを見積もることで他のメンバーのタスクを把握でき、デイリースクラムでも進捗を共有するため、フォローしやすい体制が維持できています。

振り返り頻度を上げて課題を把握する

スクラム導入前は振り返りの施策として月に一度のKPTAを実施していましたが、以下の課題から形骸化しがちになっていました。

月の初めに感じていた課題感を忘れる
改善アクションの確認周期が1か月のため、熱量が保てない

スクラム導入直後はタスク遂行に使える可処分時間を減らしたくない気持ちが強く、振り返り頻度は現状維持としていました。しかし、部内でアジャイルなチームをつくるふりかえりガイドブックの輪読会が行われたことで機運が高まったことに後押しされ、スプリントレトロスペクティブとして毎スプリント振り返りをすることにしました。頻度を上げたことで、チームやメンバーが直面している課題を温度感が高い状態で把握でき、毎週着実に改善に向かっている感覚を得られる利点があります。また、レトロスペクティブをスプリントの最終日においたことで、そのスプリント内で継続すべきことや課題を吐き出して清算するという終わった感を演出する効果もあります。

ユニークな点として、振り返りのアジェンダにはKPTAの他にDoya、Moyaという項目を用意しています。

Doyaはスプリント内で挙げた成果やアピールしたいことを共有するために利用します。KPTAのK（Keep）と似ていますが、Keepは継続したいことを共有するもので、単発の成果などは文脈に合わないため記入しづらいという課題感から作られました。デイリースクラムでもタスクの完了報告はしますが、ここに記入することで改めて他のメンバーが対応してくれたことを振り返ることができます。弊社にはZOZOエールというピアボーナス制度があるので、これと併用して感謝の気持ちを送り合い、称賛する文化を醸成してエンゲージメントを高める効果に期待しています。

Moyaはチームとして議論するほどではないものの共有しておきたい心のモヤモヤを吐き出すことを目的としています。これがあることで課題感を共有する敷居が下がり、より個人的な悩みや課題も抽出できる効果があります。ここに書かれた内容はレトロスペクティブでは深く取り上げず、1on1の会話のネタとして扱う形で活用しています。

スクラム導入後のWevoxスコア

スクラム導入後のWevoxスコアは以下の通りです。

課題として挙げていたストレス反応の数値は59から87に改善しました。このことからスクラムの導入には一定の効果があったと考えています。

まとめ

今回はチーム課題との向き合い方の一例を紹介させていただきました。スクラム導入の成功事例のように書いていますが、チーム運営にも銀の弾丸はないので常に試行錯誤が必要だと考えています。気になった方もおられると思いますが、先のWevoxでは新たに別の課題が見えています。これは達成感というカテゴリで、原因としては新規案件のローンチが落ち着いたことや課題視していたデプロイパイプラインの改修が大方完了し、一息ついたタイミングだったことに起因していると認識しています。状況が変われば別の課題が出てくるので、チームは水物だなという所感を持つとともに学びになりました。

今回のアプローチで最も重要なことは、定量的な数値として客観的にチーム状態を把握し、異常が見られたときに定性的な意見を収集して要因を分析できる状態を作っておくことだと考えています。このアプローチはある程度応用が効くものと考えているので、これから直面する課題にも引き続き真摯に向き合って改善していきたいと考えています。