Pairs事業部全体での「カンバン」をまたまた作り直しました。
こんにちは！！Pairs JapanでiOSエンジニアをしております、@satoshin21です。また、開発以外ではプロセス改善に携わらせてもらってます。最近では一眼にハマり、レンズ沼に浸かり始めています。
我々Pairs JPチームは日々業務プロセスの改善に向けて動いています。目的別から職能別に組織体制を見直し、スクラムからカンバン方式に変更したりなど、特にここ2,3ヶ月の改善の動きはとにかく目まぐるしく、我々は常に「変化」を繰り返しています。
直近のプロセス改善については、弊社の Narichika Kajihara と futabooo が素晴らしいエントリーをポストしているので、そちらを是非ともお読みください。
これまでの「カンバン」の課題
週一で行っているプロセス改善委員会にて、いくつかカンバンV2に関する課題点などがエンジニア・POなど職種問わずあがるようになりました。いくつか代表的な課題点についてまとめます。
「エピック」「ストーリー」など言葉の定義から認識がバラバラで、チケットの大きさがわからない
カンバンV2では、各ストーリーやタスクなどを紐付ける大きな単位として「エピック」を定義し各エピックごとに横軸のレーンを用意、それぞれのレーンの中でストーリーやタスクなどを動かし、プロジェクトのステータスを表していました。
しかし、運用していくにつれ、各チーム間でエピックやストーリーとして言われているものの粒度がバラバラに・・。エピックとして扱うものがストーリーとしてカンバン上に鎮座し何週間も動きがないチケットがあったりと、それぞれのプロジェクトチームごとに異なる粒度でチケットが定義されていました。
そのため、Pairs事業部全体として俯瞰したとき、今何に取り掛かっているのか？このチケットは後どれくらいでリリースできるのか？なぜこのチケットは着手できないのか？を判断することができないぐらいカンバンが複雑化してしまいました。
優先順位が見えにくい、変更し辛い
エピックレベルでレーンを定義していたのは、各エピックで優先順位をつけ、上から対応していく為でした。
しかし、優先順位というものはエピックという大きい粒度ではなく、もっと細かい粒度で優先順位をつけて対応すべきという課題がでてきました。それは、以前のエントリーでも紹介したリソース効率とフロー効率のお話に関係しています。
例えば、現在2つの大きなプロジェクト(= エピック)、「デザインリニューアル」と「コミュニティ画面の機能拡充」があり、それぞれにプロジェクトメンバーがアサインされているとします。そしてそれぞれのエピックに紐づくストーリーが以下のようになっているとします。
利用者へ提供できる価値を最大化するのであれば、まずは#1を行ってから#3を行うべきです。しかし、今まではEpicごとにプロジェクトメンバーをアサインし、それぞれのプロジェクトごとにリソースを分配、優先順位をつけていました。しかし、このままでは仮に#3へのリソースが不足した場合、適切にリソースを再配分することができません。全体最適な観点から横断的な効率化がされていない状態でした。
また、以前のカンバンV2では各レーンにそれぞれエピックを割り振り、カンバンの上から優先順位が高い順として定義していました。それぞれのレーンにはエピックに紐づくストーリーやタスクなどがいくつも紐付いていたため、エピックの優先順位を変更する場合にそれらに紐付いたストーリーなども一緒に変更せねばならず、リアルカンバンを運用する以上優先順位変更のネックとなっていました。(最終的に優先順位を表したバッジを用意してそれぞれのエピックにつけていたりしていましたが、やっぱり上から優先順位が決まっている方がわかりやすいのではないかと思います)。
リードタイムを観測できていなかった・うまく活用できていなかった
改善を行うにはまずは指標としての数値を取ることが必要です。我々はそこがうまくできていなかった・・。
リードタイムを計測しよう、という話には以前から出ていたのですが、そもそもリードタイムとは？という所から認識のズレがありました。開発が始まってからなのか？それとも施策の仮説検証が開始されてからなのか？各ステージを担当するメンバーごとに微妙にリードタイムとは？という認識がずれていた為、たとえリードタイムを取っていたとしても、計測したメトリクスから課題を見つけることができていませんでした。
改めてカンバンとは？
上記の課題から再度カンバンを作り直そうと思いたったとき、我々Pairs事業部がカンバンを使うことが適切なのか？カンバンとはなにか？という所から改めて検討しました。
カンバンの特徴は主に3つあります。
まずは見える化ができること。今どこのステージでどのチームがどのような事をやっているのかその作業量や状況を判断しやすくする為の存在。続いて流れを管理することによってボトルネックを見つけやすくすることがカンバンには可能です。
また、WIPの制約を定義することによって、1つづつ早く終わらせることにフォーカスすることができます。要するにフロー効率の最大化です。我々は、これらカンバンのメリットを最大限受容できていなかったように思います。
我々は「早く価値を利用者に届ける集団」である
改めてプロセス改善メンバーでなぜ我々はカンバン方式なのか？を話しました。そこで我々は「早さ」にフォーカスし、「早く価値を利用者に届ける」「その為に我々はカンバンを活用している」という結論に至りました。
ユーザにとって価値があるものでも、ユーザまで届かなかったら意味がない。また、UI/UXも含めた仮説検証をすばやく、何度も行うことでユーザへの価値が最大化すると考え、たとえストーリー一つ一つの粒度は小さくとも、すばやく価値を届ける為に我々は動いていると我々は考えました。その観点から、カンバンを利用することは最適と判断し、カンバンを改めて作り直す事を決断しました。
そしてカンバンV3へ
そうして出来あがったのがカンバンV3です。様々な改善を施してきた我々のカンバンですが、今回は改めて原点に帰り、いわゆるカンバンと言われているもののフォーマットをベースに再構築しました。V2から変更した点は以下のとおりです。
1. 一つ一つの付箋の単位を統一する
今までエピックやストーリー、タスクといった言葉の定義が難しく、一つ一つの付箋の粒度がバラバラで、どのくらいの大きさのものかわからなかった為、一つの付箋は一つのストーリーとして扱うことでチームの認識を統一しました。
また、ひとえにストーリーといっても粒度がバラバラになる可能性があるため、ストーリーを切る時は以下のルールに従うようにしました。
- リリースできる単位 (このストーリー一つで価値が見込める単位 )
- 2週間以内で流すことができる
リリースしてユーザが価値が見いだせるものでないと、たとえ早くリリースまで持っていけたとしても意味がありません。そのため、事業部全体でリリースのできるストーリー(いわゆるサブタスクではない)単位のみにフォーカスするようにしました。
それでもどうしても1ヶ月かかるストーリーなど、工数をかけないと対応できないストーリーの場合、最低でも2週間以内まで粒度を小さく分割し、俯瞰的に進行具合を判断できるようにしました。
2. レーンの廃止、ステージの横幅を付箋の横幅に
各ストーリーごとに優先順位を都度変更できるよう、レーンの廃止を行いました。レーンによって優先順位の切り替えにコストがあった為、こちらを上記のストーリー単位まで付箋を小さくすることで、各ステージごとに柔軟に優先順位を判断するようにしました。
また、「このチケットとこのチケットは同じ優先順位」というあり得ない事態を物理的にさせなくする為、各ステージ (開発、QA、検証 etc)の幅を付箋の幅とほぼ同じにすることで、必ず優先順位を判断する仕組みにしました。
3. 経過日数を記録する
後々振り返りをする際のメトリクスとして、当初目標としてきたリリース日まであと何日か、そして既に何日が経過しているかを付箋上で表現するようにしました。上記の図のように、チケットの下部にリリース予定までの日数分縦線を引き、一日経過するごとにその縦線を消していきます。こうすることで、予定まで順調かそうでないかを視覚的に表現することができました。
もちろんこの記録はエンジニアや担当者にプレッシャーを与える事が目的ではありません。メトリクスとして記録し、後々なぜこのチケットは予定より遅れてしまったのか？ボトルネックはどこなのか？を洗い出すための記録です。
こちらはメトリクスとしての記録のみならず、毎日カンバンの前で行っている朝会でも時間短縮に役立ちました。基本的にリリースまで日数が空いているものに関しては順調とすぐに判断することができるので、予定リリースまでに日がない(= 何かしら問題を抱えている)ストーリーにフォーカスすることができ、問題解決への動きがスムーズになりました。
まとめ ~V3に移行してから~
上記以外にも細かいところを含めると様々な改善(WIPの厳格化、Doneの見直し、Pullの概念 etc)を行いました。まだ運用して1, 2週間程度しか経過していませんが、以前に比べ、どのレイヤーの人がカンバンを見たとしても、PairsJP事業部が今何をやっているのかを理解しやすくなったかと思います。また、次々とフロー上の課題点を洗い出すことができている上、ストーリーを以前に比べて小さく、そして早く出せるようになったので、とりあえずV3にしてみてよかったなと感じます。
また、今回大きなプロセス改善を行ってきて改めて実感した事は、「チーム全体の理解なくては改善はできない」という点です。PairsJP事業部は一般的なチームと比べて非常に規模が大きいのですが、我々が考えた草案を何度も何度も事業部メンバーに確認してもらい、また我々がカンバンを使う理由や、事業部全体としての動き方をメンバー全員と都度確認することでプロセス改善に結びついているのだと思います。
変化に最も対応できる生き物が生き残る
こちらは弊社エウレカの行動規範の一つです。
多分、来月には今回改善したカンバンもカイゼンを加え、新たに生まれ変わっているんじゃないかと思います。しかし、変化を受容し、それに適応していくことでより強い組織が作り出せていくことができると信じ、これからも変化を楽しんでいきたいと思います。またカンバンを作り直した暁には、またこちらにて報告させていただきます(笑)
