ビズリーチ事業部のSREチームは、スクラムを導入して1年が経ち、タスクの可視化と脱属人化を実現しました。 導入にあたって何をしたのか、開発チームとは異なる工夫が必要だったところはどこか、導入後何が変わったのかを振り返ってみました。

ビズリーチ事業部のSREチームについて

「ビズリーチ」を担当していて、SRE(Site Reliability Engineer)としてアプリケーションエンジニアと共にプロダクトの継続的な成長のため信頼性・可用性の向上、自動化、効率化などに取り組んでいます。

なお、チームの構成は以下のようになっています。

SREチームが抱えていた課題とスクラムの導入目的

まず、SREチームがスクラムを導入した背景を説明します。

PO目線で導入を決定した理由として一番大きかったものは、タスクの可視化を進めたいというものでした。 例えば、ある人にタスクをアサインすると、アサインされた人がタスクを抱え込んでしまい、どういった状況なのかわからない、ということがよく起きていました。 すると、POは適切なアクションを取ることができなくなります。 ここでいうアクションとは、例えばタスクに取り組む人を増やす、他チームと期日を交渉する、要件を定義し直す、といったことを指します。

チームメンバー個人の目線ではタスクの属人化が頭を悩ませる課題でした。 インフラ関連のタスクはアプリケーション開発と違い、コードがないことも多いため容易に属人化が発生します。 引き継ぎ・ドキュメントの不足もあり、先任の人が不在となったタスクを行う際には無駄な開発工数がかかってしまっていました。

スクラムを始めるにあたってどうしたか

スクラムを始めることは決まったものの、スクラムマスターを除くとチーム内にスクラム経験者は1人しかおらず、当初は何から始めて良いか手探りの状態でした。 そういった状況で、私たちがスクラムを始めるにあたって何をしたかを紹介します。

Whyの整理

スクラムを始める前にまずやったことは、SREチーム全員(開発者,PO,スクラムマスター)でスクラムに対する期待を言語化することです。 具体的な手順は以下のようなものになります。

  1. ホワイトボードに「なぜスクラムなのか」「スクラムへの期待」をそれぞれ付箋を使って書き出す
  2. グルーピングして特に付箋が集中したものを次のステップで取り扱う
  3. 「なぜ？」「どういうこと？」といったオープンクエスチョニングを使ってグルーピングしたものを深掘る
  4. ある程度深掘れたら2に戻り別のグルーピングしたものを取り扱う
スクラムに対する期待を書き出してみる
スクラムに対する期待を書き出してみる

私たちは、こうして作った7つの目標(「価値が高いものから取り組む」「品質向上」「遅延をなくす」「改善機会の創出」「スキルアップ」「属人化の排除」「変化に強くなる」)を、チームの目標として掲げました。

スクラムを始めるときの失敗例として、スクラムをやること自体が目的となってしまうケースや、スクラムを始めたときの目的がいつの間にか曖昧になってしまうケースがあります。 私たちは、ここに時間を使うことで「チームとしての目標を言語化する」「チームとしての目標を達成するためにスクラムをやっている」という意識をチーム全体で持つことができ、軸をぶらさずスクラムを導入することができました。

スクラムガイド読み合わせ

次に、スクラムガイドをSREチーム全員で音読してディスカッションする時間を作りました。 ガイド自体は20Pに満たないため、ディスカッションする時間を含めても2時間ほどで終わります。 これによりスクラムとは何か、スクラムにおける重要な価値について共通認識を持つことができました。

スクラムガイドにはスクラムの定義が含まれている。フレームワークの各要素には特定の目的があり、スクラムで実現される全体的な価値や結果に欠かせないものとなっている。スクラムの核となるデザインやアイデアを変更したり、要素を省略したり、スクラムのルールに従わなかったりすると、問題が隠蔽され、スクラムの利点が制限される。場合によっては、スクラムが役に立たなくなることさえある。 Ken Schwaber & Jeff Sutherland スクラムガイド(2020年版)

セレモニーの設計

上の章で扱ったスクラムガイドは指針を示してくれますが、方法までは示していません。

方法に関しては、ビズリーチで作成した共通の「型」となるもう一つのスクラムガイド、と呼べるものがあるので、そちらも紹介します。 私たちはこのスクラムガイドに沿ってスプリントの基本設計を行いました。 例えば、スプリントを1週間にする、各種セレモニーの実施時間を決める等です。

具体的にセレモニーの中で何を行うかは始めのうちは手探りでやっていました。 始めは付箋に簡単な実施手順を書いていたのですが、改善が進み現在はWikiページで手順を管理しています。

Doneの定義

Doneの定義は、「現状チームで成果物をリリースする時できていること」を書き出し作成しました。 現在のDoneの定義は以下のようになっていて、各項目ごとにより細かな定義も定めています。

スクラムの中での改善、仕組み化

スクラムの柱である「検査」と「適応」。これを反復し、プロセスを改善していくことがスクラムでは重要です。 スクラムを実践する中で、SREチームがどのような改善を行ってきたかを紹介します。

MTGごとの振り返り

SREチームでは、スクラムのセレモニーやチーム内MTGの最後に5分間、振り返りを行うことが習慣になっています。 通常のスクラムだと、レトロスペクティブが主な振り返りの場となっていると思います。 しかし、小さな気付きは1週間経つと忘れてしまうこともあり、より細かな単位で振り返りをしたいと考え、 MTGの最後に振り返りをすることを習慣化しました。

セレモニーごとの振り返り
セレモニーごとの振り返り

他チームとのコミュニケーション

SREチームは、機能開発よりも、他のアプリ開発チームからの依頼案件を受けることが多いです。 その場合のステークホルダーはアプリ開発チームとなります。 そのため、案件の内容にもよりますが、セレモニーの場に他のチームを招待することもあります。

リファインメント: どう作るのか、要件をヒアリングする場

依頼を受ける際はチケットを依頼者に書いてもらいます。 場合によってはそれがそのままリファインメントされますが、要件がSREチームから見て不明な部分があるとき、直接依頼者をリファインメントの場に呼んで質問しながらチケットを作成します。

スプリントレビュー: 今回の連携がどうだったか、次回の改善につなげる振り返りの場

依頼案件や、成果物の利用者が開発者の場合、スプリントレビューに呼んで、以下のようなことをヒアリングしています。

ツールを使って「気づき」を生み出す

リモート環境下の現在は、そうでない場合と比較すると他人の作業が見えなくなり、協調が生まれにくくなります。 それを防ぐため、SREチームはJIRA, Miro, Zoomなどのツールを使い、作業の可視化と協調が生まれる仕組みを実現しています。

一つ例を挙げると、JIRAのカンバンで進行中の作業（WIP）の制限を行っています。 WIP制限とは、カンバンで、「作業中(WIP: Work in Progress)」となっている項目の数を制限するというものです。1

チームメンバーが5人に対して、WIPには2つまでしか積めないようになっています。 こうすることによって、強制的に複数人で1つのタスクに協力して取り組むことができ、自然と協調が生まれる仕組みができます。

wip警察
スクラムマスターからの指摘

写真はスクラムマスターからWIPを守れてないという指摘があったときのものです。この後、WIPを超えたときは自動でSlackにアラートが飛ぶような仕組みを作りました。

スクラム前と後で変わったこと

スクラムを始めて1年経ち、SREチームがどう変わったか、それぞれの立場から見てみます。

メンバー目線ではどうだったか

始めは変化に戸惑うことも多かったのですが、慣れていくうちにスクラムの利点を実感できるようになりました。

属人化防止という観点では、リファインメント(要件定義)とプランニング(設計)を全員で実施するようになったこと、実際の作業の協力も増えたことにより、属人化したタスクはほぼなくすことができました。 そのおかげで、以前は1ヶ月ほど必要だった引き継ぎ準備が1週間ほどで終わるようになりました。

PO目線ではどうだったか

開始2ヶ月時点で、個人がタスクを抱え込むという問題については解消して、誰がどのタスクをやっているか、どういう状況か把握できるようになりました。

また、開始3ヶ月時点でベロシティ測定によってスプリント内に積んだタスクが終わりそうかどうか、見積もりが立てられるようになりました。

他チーム目線ではどうだったか

他アプリケーション開発チームのマネージャーにヒアリングしたところ、以下のような意見をもらいました。

実際にヒアリングして、チーム内では見えていなかったこと、特に専任の担当がいなくなったことによる負が見えたのは大きな収穫でした。 SREチーム自身のために始めたスクラムですが、今後は他チームの視点をより取り入れて、改善を進めていくことを考えています。

今後どうしたいか

今後もスクラムは続けていきます。 上に掲げた「Whyの整理」「セレモニーの設計」「Doneの定義」などは、一度作って終わりというものではありません。 メンバーの入れ替わりもあり、改めて今のチームに沿ったものにするため、作り直しを行っている最中です。 この記事は、作り直しを行うため、改めて一年間スクラムをやってきた意義を振り返る過程で生まれたものです。

また、スクラムのベストプラクティスに沿えていない部分はまだまだあり、例えばDoneの定義をより拡張したり、守るための仕組み導入、ROIの可視化などに今後取り組みたいと考えています。

ビズリーチでは、プロダクトの継続的な成長のために一緒にスクラムを作り上げてくれる仲間を募集中です！ 少しでも興味をお持ちいただいた方は、このページの下部にあるバナーより採用情報をご覧ください！

  1. scrum.orgのカンバンガイド を参照 ↩︎

永徳 泰明
永徳 泰明

ビズリーチ事業部SRE。登山が趣味。仕事でもプライベートでも石橋を叩きつつチャレンジするのが好き。