こんにちは！モバイルアプリケーション開発部の折田 (@orimomo)です🍑
私たちの部署では2023年1月にチームの再編成をおこないました。
もともと2チーム制だったところを3チーム制へと変更し、そのうち2チームでスクラムではなくカンバンを採用するという選択をしています（残り1チームはスクラムを継続）。
今回は、カンバンを採用した理由や、この4ヶ月間おこなってきた試行錯誤について書いてみようと思います。カンバンが気になっている方、スクラムからカンバンへの移行を検討している方にとって、少しでも参考になれば幸いです。
なお、以前に部署のスクラムについて紹介する記事を書いておりますので、よければそちらもご覧ください。
2023年〜のチーム構成
今回のチーム再編成では、『チームトポロジー』を参考にチームを3つに分けました。
- 🟥 Rougeチーム: ユーザーに素早く価値提供することを目指すストリームアラインドチーム
- ⬜️ Blancチーム: 他チームがiOS開発をしやすいように、各種サポートや整備などをおこなうiOSプラットフォームチーム
- ⬛️ Noirチーム: 他チームがAndroid開発をしやすいように、各種サポートや整備などをおこなうAndroidプラットフォームチーム
モバイルアプリケーション開発部のメンバーだけではなく、他部署に所属する開発者もモバイルアプリ開発をおこなう場合があるため、そういったメンバーからのコードレビュー対応もプラットフォームチームの守備範囲となります。
そんな新設されたプラットフォームチームでカンバンを使い始めました、というのが今回のお話です。
ちなみに私はというと、もともと2チームのスクラムマスターだったところ、再編成後は1チームのスクラムマスター兼2チームのサポート役として関わらせてもらっています。知識としてカンバンは知っていたものの、チームでの実践経験はなかったので、私にとっても大きな挑戦となりました。
このチーム構成にした目的や、各チームの詳しい責務については、マネージャーの福井が書いている以下の記事をご覧ください。
カンバンを採用した経緯
私たちの部署では長年スクラムで開発を進めてきたので、「スクラムには慣れている（が他は知らない）」というメンバーが多く、新しいアジャイル手法を採用することは勇気がいりましたし、うまくいかないリスクもありました。
それでもカンバンに白羽の矢を立てたのは、プラットフォームチームの性質を考えたときに、以下3つの観点で合いそうだと思ったからです。
プラットフォームチームは他チームからの突発依頼にも優先順位を変えながら対応していく必要があったこと。スクラムはスプリント中の変更を原則許可しておらず、「次のスプリントまで待ってくれ」となりがちな一方、カンバンであれば柔軟に変更できるため、スピーディーな対応が可能なのではと考えました。
プラットフォームチームはiOS / Androidの技術に特化した専門家チームなので、開発者ではない誰かに優先順位を決めてもらうよりも、自分たちで状況を判断して進めていくほうがスムーズにいく可能性が高かったこと。スクラムと違ってカンバンにはPOというロールが存在しないのもあり、体制的にもマッチしそうに見えました。
プラットフォームチームはマルチモジュール化やリアーキテクチャといった「先の見通しが立てづらい作業」を多く扱うこと。これらの作業は試行錯誤の連続で、思い通りにいかないことも多々あり、スプリント期間に合わせて丁度良く分割・完了するのにこれまでも苦労していました。明確な期間の区切りがないカンバンであれば、多少（気持ち的にも）緩和されるのではないかと考えました。
ただ最終的にどうしたいかを決めるのは私ではなくチームだと考えていたので、スクラム・カンバンそれぞれのメリット・デメリットと、スクラムからカンバンに移行した場合に既存のイベントや各々の役割にどんな変化が起こるのかなども含めてお伝えしたうえで、みんなで話し合ってもらいました。その結果「カンバンでやってみよう」となり、現在に至ります。
「慣れ親しんだスクラムがいい！」という強い声が上がるわけでもなく、思ったよりもすんなり決まったのは、これまでのスクラムを通じて「実験的に新しいことをやってみる」というのにみんなが慣れ、変化を受け入れやすくなったからなのかもしれない…と、内心すごく嬉しかったのはここだけの話です🫶
カンバンを始めるにあたって
まずは有名な黄色い本こと『カンバン仕事術』をベースに、カンバンの3原則「1. 見える化、2. WIP制限、3. 流れの管理」と、重要なスローガン「始めるのをやめて、終わらせることを始めよう」について説明をさせてもらいました。 そして普段の作業をマッピングしてカンバンボードの列を作り、WIP制限をいくつにするかを決めるワークを全員でおこないました。
カンバンには、スプリントプランニングやスプリントレビューといった、スクラムで当たり前におこなっているイベントを切り離す自由が与えられています。
そこで、イベントについては毎日の朝会と週1のふりかえりだけをあらかじめ設定し、バックログリファインメントについては各チーム様子を見ながらおこなうこととしました。
また、チケットの切り方や、ボードに入れる前にReadyにしておくルールなど、細かい部分についてはスクラムをやっていた頃をそのまま踏襲することにしました。
結果として、特に大きな問題が生じることなく、わりとスムーズにカンバンに移行することができたと思います。スクラムに全員が慣れていたことと、それまで培ってきた土台をベースに話し合いを進められたことが大きかったです。
実際カンバンをやってみて
どうだったか？
「カンバンを採用した経緯」で紹介した3つの観点について、まだまだ検証中の部分はありますが、現時点での所感を書いておきます。
「他チームからの突発依頼にも柔軟に優先順位を変えながら対応できそう」という点については、概ね満足のいく結果となりました。特に他部署からのコードレビュー対応に関しては、スクラムでやっていた頃は完了まで1週間以上かかっていたところ、カンバンにしてからはおよそ2日以内で完了させられるようになり、「速くなって助かる」「ありがとう」といった喜びの声をいただきました。「他チームが開発しやすくする」というプラットフォームチームの役割に、カンバンの柔軟性がうまくマッチしているように思います。
「自分たちで優先順位を判断して進めていくほうがスムーズかも」という点についても、及第点かなと思います。やはりプラットフォームチームの作業は技術的なものが多いので、POへの説明や確認を挟まず、開発メンバー内で話し合って進められるのはスピード感があって良いなと感じています。スクラムと違ってバックログリファインメントも自分たちでタイミングや内容を考えて実施する必要があるため、若干開発メンバーへの負荷は上がったのかもしれませんが、その分自由度・裁量が大きくなり、チームとしての成長につながっているようにも感じます。 ただ「ズルズルと継続してしまっているチケットの撤退判断」を自分たちだけで下すのは難しいケースもあり、POのような俯瞰的・中立的な判断をできるようになるのが理想だとは思いつつ、もう少し時間がかかりそうです。
「マルチモジュール化やリアーキテクチャといった先の見通しが立てづらい作業を扱いやすくなるかも」という点に関しては、正直うーん…という感じです。たしかにスクラムのときのような、スプリント終わりにチケット完了せず残ってしまったり、複数スプリントをまたいでしまうことによる辛みはなくなったかもしれませんが、その代わり、カンバンボードにチケットが残り続けてWIPを圧迫してしまうことによる辛みが生まれたように思います。スクラムでもカンバンでも、流れを良くするためには適切にチケット分割をする必要があること、大きすぎるチケットは扱いづらいことに変わりはありません。この点は私の見立てが少し甘かったなという部分ですが、改めて実感できて勉強になった部分でもありました。
上記以外の部分でも
- 稼働が一定ではない業務委託メンバーのWIPをどう扱うべきか？
- もともとスプリントプランニングでしていたような、作業に関する詳しい話はどこでおこなうのが適切なのか？（現状朝会で話すことも多く、朝会の時間が伸びてしまうことも）
- 先を見越してリアーキテクチャやリファクタリングを進めていきたいが、他チームからの相談や依頼を優先しているので歩みが遅い
- 目先の作業に集中するあまり、中長期計画を顧みる機会が少ない
といった課題があったりもします。とはいえ、どのアジャイル手法を用いようと100%自分たちに合っているものは無いと思うので、状況を見つつ、改善を目指していくだけかなぁと思っています。
メトリクス活用中！
カンバンを始めてからの4ヶ月、フローやカンバンを最適化する上で、各種メトリクスの計測・分析はとても役立ちました。毎週ふりかえりのタイミングで以下3つの指標を確認するようにしており、変化を起こすきっかけになってくれています。
サイクルタイム
サイクルタイムは「ワークフロー全体を通るのにかかった時間」のことで、カンバンチームはサイクルタイムをとにかく短くすることに集中するべきとされています。計測にはJIRAの管理チャートを使っています。
完了までに時間がかかったチケットは上の方にプロットされるので、「時間がかかったのはなぜだろう？」「どの列で時間がかかったのか？」などを話し合うことで、改善できる部分を探るようにしています。
スループット
スループットは「一定期間に完了したタスクの数」のことで、その週に完了したチケット数を数えることで計測しています。お手製のスプレッドシートで記録・見える化をしています。
この数値を見ながら「今週少なかったのはなぜだろう？」「増加傾向にあるけど何が要因だろう？」といった議論をしたり、後述する「リフレッシュDay」の予定を確認したりしています。
WIPの傾向
WIP制限をいくつにするかはカンバンチームの永遠の課題であり、その時の自分たちに合うように常に調整を続けていく必要があります。特にカンバンに慣れていない立ち上げ期のチームでは、「WIP制限を変えたい」という話が頻繁に出てくる可能性があります。
そこで便利だったのがJIRAの累積フローダイアグラムで、その週の仕掛り作業数がどう推移したかをチェックすることができます。（上に貼った図はWIP制限が 4 のチームのものですが、「計測期間中にWIP制限を超えたことは一度もなかった」ことがここからわかります。）
いつも制限を超えているようなら制限を上げてみることを検討すべきかもしれませんし、逆に上限に達することがほとんどなかったら議論は起こらず改善しようという緊張感も生まれないので、制限を下げることを検討するべきかもしれません。
そういったことをこの図を見ながら話し合い、実際この4ヶ月間で、BlancチームはWIP制限を 4 → 6 → 5 と、Noirチームは 5 → 4 → 3 → 4 と変更しています（それぞれの変更にも記事1本書けるくらいのストーリーがあるのですが、長くなるのでここでは割愛）。
なんとなくでいくつにするかを決めていくのは難しいですが、目に見える数値があることで、チーム内での合意を素早くとりつつ、適切に最適化ができているように思います。
リフレッシュDayの誕生🏖️
ふりかえりから出てきたものとして一つご紹介したいのが「リフレッシュDay」です。
カンバンを始めて1ヶ月が経った頃、「スクラムと違ってカンバンには終わりのタイミングがないので、気づけば絶え間なくチケットをやってしまう。なんだか疲れる…」という課題が複数人から出たことがきっかけで始まりました。
スループットを見ながらちょうど良さそうな数値を探り、「50チケット消化すると1Dayゲットできる」というルールでやってみることになりました。
早く50チケットに到達しようと思うとチケットを細かく切ることになるため、大きすぎて流れを阻害するチケットが生まれにくくなるという副次的な効果もあります。
実際には、長らく着手できていない技術負債を解消したり、全く新しい技術に触れてみたり、有給を使って心身ともにリフレッシュしたりと様々な使い方をしていて、持続可能に楽しく働くための大事なイベントとして定着しています。
さいごに
プラットフォームチームでカンバンを使い始めてみて、全部が全部うまくいったわけではありませんし、今でも悩んでいる部分はたくさんありますが、チームみんなで改善策を考え、少しずつ前に進むことはできているように思います。メンバーからもカンバンに対して肯定的・好意的な意見を聞くことが多いです。
もしまた状況が変わってカンバンが合わなくなったらスクラムに戻すこともできますし、部署としても、メンバーとしても、スクラム以外の経験値を貯められていることは意義深いんじゃないかなと思います。
個人的には今回、チームの責務や望んでいる仕事の進め方をもとに、アジャイル手法を選択することの重要性を改めて感じました。今チームが回っているのは、メンバーの日々の努力や工夫があるからなのは言うまでもありませんが、カンバンの原則に沿う形で改善を進めることで、それをやんわり後押しできているようにも思っています。カンバンについて深く知ることで、逆にスクラムについての理解が深まったのもまた印象的でした。
今後はさらにメトリクスを充実させつつ、みんながより速く、より楽しく、仕事ができるようにサポートしていけたらと思っています。
そんな私たちの部署ではiOSエンジニア、Androidエンジニアを絶賛募集中です！また会社としてスクラムマスターも募集しています。 少しでも興味を持ってくださった方、お気軽にご応募いただけると嬉しいです。
