※この記事は 2022年11月28日に Medium で公開されたものを、ブログ移行に伴い再掲載したものです。内容は当時のままですので、一部情報が古くなっている可能性があります。
Tebiki株式会社では「現場向け動画教育プラットフォーム tebiki 」を開発しています。そして、このプロダクトの価値を最速で大きくしていくために、スクラムを導入しています。
スクラムによりtebikiの開発チームはより速いプロダクトのフィードバックサイクルを回せるようになりました。その一方で「スクラムチームはどのように技術的負債の解消に取り組んでいけばいいのか？」という課題に直面しました。
この記事では「スクラムと技術的負債の解消の両立」という課題に対してTebiki社が導入した「20%ルール」についてご紹介します。
Tebiki社における20%ルールとは
Tebiki社の20%ルールは
エンジニアが開発に充てられる時間の20%をスプリントゴール以外のことに使うこと。
というものです。
つまり、エンジニアのリソースは以下のように使われます。
スプリント … 80%
スプリント以外の開発業務 … 20%
「スプリントゴール以外の開発業務」の具体例としては、
現在抱えている技術的負債の解消
利用しているライブラリのアップデート
開発体験を向上させる技術の導入
ドキュメント整備
などが挙げられます。ざっくりまとめると、カイゼン活動です。ここでのカイゼン活動とは「顧客に直接的な価値を提供しないがプロダクト価値の最大化に欠かせない重要なタスク」とします。
この「20%ルール」を導入するまでの背景をご説明します。
スプリントゴールと技術的負債解消の両立は難しい
冒頭で紹介した通り、tebikiの開発チームはスクラムを導入しています。
2022年9月の導入時点ではスクラム未経験のメンバーがほとんどでした。
そのため、スクラムガイドのルールを堅実に守りつつ、スクラム経験者の知見を借りながら1ヶ月取り組みました。
スクラムはシンプルである。まずはそのままの状態で試してほしい。そして、スクラムの哲学、 理論、構造が、ゴールを達成し、価値を⽣み出すかどうかを判断してほしい。 出典: スクラムガイド2020
各スプリントにて振り返りを重ねていく中で、いくつかの課題が顕在化しました。
開発チーム「技術的負債解消はいつやればいいんだろう…」
スクラムではスプリントという単位で開発を進めます。tebiki開発チームの場合は1週間が1スプリントです。
スクラムチームは現在のスプリントで達成したいことを「スプリントゴール」として掲げます。
スプリントゴールはスプリントの唯⼀の⽬的である。 出典: スクラムガイド2020
このスプリントゴール達成のためにスクラムチームは作業に取り組んでいきます。
これはチームが1つの目的に集中するために有効な反面、技術的負債の解消に取り組むタイミングを難しくしています。なぜなら「技術的負債の解消そのものは顧客に価値を提供しないし、スプリントゴールにも直結しないから」です。
ですが、技術的負債の解消は、事業が継続的成長をする上で必ず解消しなければならない課題です。技術的負債はプロダクトが肥大化していく過程で開発速度を落とし、プロダクトの価値向上を妨げていくからです。
つまり現実問題として「スプリントゴールに全集中！」というわけにいかず「スプリントゴールと技術的負債の解消の取り組みの両立」に取り組む必要があります。
補足: Tebiki社のスクラムチームは「技術的負債の解消のためのスプリント」を避けています。毎スプリント必ず1つ以上価値提供をし、利害関係者を巻き込んだフィードバックサイクルを止めないためです。
プロダクトオーナー「機能開発と技術負債解消を比較、優先度づけするの難しくない？」
スクラムではプロダクトの改善に必要な作業一覧として「プロダクトバックログ」を作成します。
プロダクトオーナーと呼ばれる(スクラム上の)役割を持った人がこのプロダクトバックログの作業(プロダクトバックログアイテム)を優先度順に並べ替えます。
この時、「技術的負債の解消」に関する作業があると優先度付けがとても難しくなります。
技術的負債の解消に関するプロダクトバックログアイテムは、スプリントレビューでフィードバックをもらうことができない
技術的負債の解消がビジネス上どのようなインパクトがあるかを評価するためには定量化が必要だが難易度が高い。例えば、 「この技術的負債が解消されることでベロシティが向上する」という成果はベロシティ計測をすることで証明できそうに思える。しかし実際は「メンバの成長」などの変数も潜んでいる。つまり、有意差を取るのが難しい。
技術的負債の事情に詳しい開発者たちとコミュニケーションをとりながら優先度付けが必要。コミュニケーションはスクラムにおいて重要だが、作業コストが高いのは事実
このように、作業の優先度付けにおいて悩みの種にもなります。これではプロダクトオーナーにとっても技術的負債を管理すること自体がコストになってしまいます。
これらの課題は、スクラムの振り返り(スプリントレトロスペクティブ)の中で顕在化しました。
そして、スクラムチーム全員でこの課題に向き合い、実践的なソリューションを出しました。
それが本ブログで紹介する「20%ルール」です。
スプリントレトロスペクティブはSlackのHuddle(グループ通話機能)とFigmaのFigjam(オンラインホワイトボード)を活用して取り組んでいます。
20%ルールが組織にもたらしたもの
20%ルールを導入して様々な恩恵を得ることができました。その一部を紹介します。
継続して技術的負債を解消する時間を作ることができた
「今回のスプリントゴールは重要かつ難しいタスクがあるので、技術的負債の解消はスプリントに含められないですね…」という会話をする必要がなくなりました。そもそも、プロダクトの成長を考える上で機能の開発が重要ではなくなる、なんてことはありません。この会話は定常化しがちなので、それを避けられるのは大きいです。
また、チームとしてはスプリントゴールとは切り分けて、存分に技術的負債の解消を含むカイゼン活動に取り組めます。
POがプロダクトバックログの優先度をつけるための作業コストが減った
POが技術的負債とスプリントゴールを天秤にかける必要がなくなったのも、チームの生産性向上に貢献しています。
スプリントゴールにより集中しやすくなった
前述した「スプリントゴールと技術的負債の解消が結びつかない」という違和感を抱えることがなくなり、「価値提供するにはどんなことをすべきか」にスプリントの時間を集中させることができるようになりました。
20%ルールの具体的なプラクティス
最後に、Tebiki社の20%ルールの具体的な方法を共有します。
毎週火曜日は20%ルールの日
Tebiki社のスプリントは1週間で、水曜にスプリントが開始します。
そのため、火曜日をちょうど20%分として時間をとり、スプリントゴールとは別の作業をしています。
曜日で切り出されていると、頭の切り替えがしやすいというメリットがあります。
20%ルール内でやりたいことはIceboxの中に入れよう
Tebiki社のスクラムではIceboxという「スクラムチームが着手したい課題や作業を放り込む場所」設けています。このIceboxにエンジニアはやりたいことを発見した段階で追加します。
プロダクトバックログと分けることで、POは顧客への価値による優先度付けがやりやすくなりました。
20%ルールでやることは、直前にスクラムチームで話し合って決めよう
実際にどのIceboxに着手するかは、スクラムチームで話し合います。
どれから手をつけるべきかには、優先度付けがやはり重要です。
この優先度づけは「20%ルールで着手する直前」に取り組みます。これにはとても大切な理由があります。それは「第二のプロダクトバックログを生み出さないため」です。
20％ルールのために使える時間は週あたりに1日です。つまり、Icebox内のアイテムのライフサイクル(追加から完了まで)は長くなります。
そのため、時間を割いて適宜優先度付けをしたとしても、着手する頃にはその優先度は変わってしまっている可能性が高いです。つまり、その優先度付けは価値を産まず無駄になってしまいます。
これを避けるために、Tebiki社の20%ルールの時間の中で「Just In Time（JIT: 必要なものを、必要なときに、必要な分だけ）」の精神で取り組む内容を決めています。
Just In Timeについての考えは、弊社の三宅の記事で紹介しておりますので是非読んでみてください。 企画や開発で生まれた知的在庫、見えていますか？ Tebiki株式会社では「現場向け動画教育プラットフォーム tebiki…techblog.tebiki.co.jp
ペアプログラミング・モブプログラミング
また、Tebiki社の開発チームでは着手する作業の大半をペアプログラミングやモブプログラミングで作業しています。これはスクラム、20%ルールどちらにも適用しています。これにより作業とレビューの時間や大幅なやり直しを減らし、着手から完了までのライフサイクルの短縮に繋げています。
ペアプロをするためのSlack Channel。エンジニアが増えていくにつれ、続々とChannelが増えています。
今後の課題
20%ルールは多くの利益をチームにもたらしましたが、まだまだ課題は残っています。
まとまった時間を確保しないといけない負債は解消することができない
週20%の時間しか当てられないので、「大規模なカイゼン活動」には取り組みづらいです。
この課題に対しては20%ルールとは別のアプローチをしていく必要があると考えています。
ベロシティが不安定だと、80%内でスプリントの作業が完了できず、20%ルールの時間を圧迫することがある
スプリントの作業が常に簡単とは限りません。設計段階や実装の不確実性の高い作業は、どうしても見積もりより時間がかかってしまうことがあります。
この事象が定常化してしまうとせっかくの20%ルールが台無しになってしまいます。スプリントを重ねていくことでチームのベロシティが安定し一部解消されるものと思われますが、常に気をつけないければいけない課題です。
ここまで、20%ルールのいいところばかり紹介してきましたが、実際このような事象が起きてしまうことがあります。
弊社に関わらずどの組織もそうかと思いますが、まだまだ課題はどんどん出てくる、というのが現状です。
しかし、スクラムには「スプリントレトロスペクティブ」というスプリントの振り返りと改善策をを決めるイベントがあります。その中で、「なぜそれが起きてしまったのか」「どうすれば解決できるのか」「改善策を試してみてどうだったか」というフィードバックサイクルを回すことで、さらなるチームの改善に取り組んでいます。
まとめ
スクラムにおけるスプリントでは、スプリントゴール達成のために作業をします。「技術的負債の解消」などの作業はスプリントゴールに直接的につなげることが難しく、プロダクトバックログ内での優先度づけにも苦戦します。そのためTebiki社ではそれらの作業をスプリントから切り出し、「20%ルール」という形で取り組むことにしました。その結果、スプリントと技術的負債の解消を両立して進めやすくなりました。
我々は一緒に働く仲間を募集してます！
Tebiki社では、現場教育の DX を促進する動画マニュアルの SaaS「tebiki」を開発しています。
我々の開発組織は「プロダクト価値の最大化」を目指し、「スクラム」「ペアプロ・モブプロ」などの新しい取り組みに積極的に取り組んでいます。また、「20%ルール」のようなチーム課題のソリューションにチーム全員で考え、取り組んでいます。
これらの取り組みに少しでも興味がある方、是非一度カジュアルにお話ししませんか？ 3.エンジニア の求人一覧 - Tebiki株式会社 Tebiki株式会社が公開している、3.エンジニア の求人一覧ですherp.careers
執筆者
二瓶駿
Tebiki株式会社 の Product Engineer というロールで「現場向け動画教育プラットフォーム tebiki 」をより価値あるプロダクトにしていくための開発をしています。また、開発組織のリーダとしてより良いチームにしていくための施策や仕組みづくりに組織全員の力を借りながら取り組んでいます。
