カンバン導入失敗から学ぶ、フレームワークの考え方
皆さん、カンバンでチームの可視化やっていますか？
チームで使うツールが Figjam に切り替わったので、せっかくだったらカンバンやってみるか！という話になり、チームのカンバン導入をやってみることになりました。
自分のカンバンに対しての理解度が低かった & チームに合わなかったので、結果としてカンバンは採用しなくなったのですが、その時に調べたことをまとめていこうと思います。
レーンがあって、付箋移動させていくんやろ
TODO/DOING/REVIEW/DONE のレーンがあって、各々がやっているタスクについて付箋に書き出して、アイコン移動させて、誰が何をやっているかみんながわかるようにする。
自分のカンバンについての認識はこれでした。
じゃあ、みんなレーン引いたから来週のやること付箋にして TODO のところにガシガシ貼っていってくださーい。
そんな形でゆるっとカンバン運用が始まりました。
メンバーの戸惑いポイント1: 付箋の粒度
最初に上がった疑問は付箋にどんなタスクを書くか？でした。
チームでやっているメインのストーリー(バックエンド/フロントエンド)の付箋 + 各職域でやりたいことの付箋、それぞれ書くことになるが、カンバンに書くもの = そのスプリントで達成したいことなのか？という話。
スプリントを跨いで行われるタスクの扱いについて悩みました。
また私のチームでは、チーム外の作業(コーポレート系や他チームに対してのマネジメント系の作業等)も行っていることが多く、その作業をどう表現するか？という話も議論になりました。
メンバーの戸惑いポイント2: WIP 制限どうする？
先ほども話した通り、チームの中で扱っている領域の幅が広すぎて、 DOING / REVIEW の WIP 制限を設定したいけどできない状態が生まれました。
レビュー中ではないけど、作業の性質上仕掛中で止めないといけない作業が DOING に溜まったり、領域毎に作業ペースが違う中でどんな形で WIP 制限ができるのか？
専門領域を分けているチームだからこその悩みでした。
メンバーの戸惑いポイント3: カンバンでチームが強くなっている感が薄い
2~3週やってみて、カンバンの流れはちょっとずつ整備されてきている感覚はあるけど、「チームが強くなっているか？」については疑問のままでした。
付箋がどれぐらい DONE になっているか、ポイント的にどれぐらい消費できているか？等の目に見える数値の変化とかをちゃんと追ってなかったのが要因だったと思います。
ちゃんと勉強した
勉強するにあたって読み込んだ書籍・資料はこの３つ。
特に下２つのガイドシリーズは、スクラムガイドに似た形で書かれているので読みやすかったです。
カンバンとは、視覚的かつプルに基づく仕組みによるプロセスを通じて、価値の流れ（フロ ー）を最適化するための戦略である
まずスタート地点からずれていますね。
フレームワーク使うときはそのフレームワークの思想や目的を正しくメンバー全員が理解するの大事。
Rails でもレールから外れないことが大事と言われているように、間違った解釈によって、有効に働かないパターンが生まれ正しい評価ができません。
最終的にスライドに落とし込んで、チームに解説した時に「だから上手くいかなかったのか」という話に納得感が出ました。ワークフローをちゃんと定義していない状態でやるなんて、なんちゃってカンバンにそりゃなるわ。
カンバン導入を考えるうえで思ったのは、、チーム全体のイベントも含めた設計として考えるのが良さそう。
スプリントレビューに絡めつつチームの届けたい価値について可視化できるとより効果的かも知れない。
ただ、チームの状況によって使える使えない部分はあるので、使い所は見極めるべきでした。
今は、もともと運用していた OKR の P1/P2 方式に戻していて、チームの中でフォーカスする課題に絞っています。こちらは数年運用して、チームが慣れている部分もあるので、回っています。
色々書きましたが、「カンバンを試す」ということを実験してみることができるチームであるのはめっちゃいいなと思いました。
一旦やってみて体験したことでしか得られない知見があるはず。
また別のことを試すときは今回の経験を活かそう。
この記事が気に入ったらサポートをしてみませんか？