タスクボード（カンバン）を導入した振り返り
本記事はSupership株式会社 Advent Calendar 2016の12日目の記事になります。
株式会社Socketの @yoskhdia です。 株式会社SocketはSupership株式会社と同じSyn.グループのメンバーであり Web接客と呼ばれるサービスのひとつであるFlipdeskを展開しています。
弊社で3,4ヶ月ほどタスクボードを試験的に導入しました。 現在は一旦おやすみ中ですが、次に活かすための振り返りをしてみるエントリです。 結論としては、ガッツリ転んだけど、次はもっと良くするぞ！という感じです。
背景
弊社は開発チームと一括りにしてもその中には"機能開発チーム"、"品質管理チーム"や"インフラチーム"が存在します。 少ない人数で進めているので開発要望が増えるスピードの方が早く、この溜まりに溜まった開発要望を開発チーム全体で一挙集中して消化しよう期間が企画されました。
そうすると、開発スピードがあがるのは良いのですが、その分動きが早く誰が何をやっているのか見えにくくなっていました。 どこかで停滞していないか、次のリリースにどこまで含められるのか、などなどといったことは開発のなかでも重要な関心事ですよね。 そんな折、カンバン仕事術という書籍が出版され、チームメンバーからもやってみたいという話があがったので、（まだ書籍を全部読んでないけれど）まずはやってみようということでタスクボードを導入してみたのでした。
何をどうしたか
強粘着タイプ付箋紙を購入し、打ち捨てられていたホワイトボードを使って
「計画」「設計中」「コーディング中」「テスト*1中」「WFR」「品質テスト待ち（計画）」「品質テスト中」「リリース待ち」
という8フェーズを規定したタスクボードを作成しました。
絵にしてみるとこんな感じです。
「品質テスト」として、新機能や修正が正しく行われているかをチェックするのは勿論ですが、ユーザ目線でテストを行うこととしています。 この品質テストは機能開発を行うチームとは別の品質管理チームが担当します。 また、Wait For Review（WFR）というフェーズを設けていて、これは必ず誰か一人のレビューを通ってからでないと先に進めないようにしています。 品質管理チームにちゃんとボールを渡せるように、要件を満たせているかという視点でレビューを必ず行います。
ものによっては、修正は1個所だけれど影響が広範に及ぶなど、開発のスピードと品質テストのスピードが異なる場合があります。 WFRを通ったものは品質管理チームの計画に入り、その中からリリース候補を確定する期日までにテストを通過したものが晴れて「リリース待ち」に移動します。 あれはどうなってる？を見えるようにするためタスクボードは一つにしていますが、何をどのように進めるかはそれぞれのチームでスケジューリングできるようにしています。（タスクボードは開発チームが主体なので、その主管範囲では人ごとのレーンがあります。）
細かいところでは、付箋に書いてる内容は何だとか、特急レーンはどうしてる等ありますが、ここでは割愛します。
どうだったか
1日で終わるようなレベルのタスクが多かったときは、日々流動している感じがあってリズムがありました。 WIP制限もかけていたので、タスクを抱えすぎて中途半端な状態になってしまうことも防げていました。
ところが、難易度が高くて変更箇所が多い大きいタスクが増えてくると、徐々に「コーディング中」などに滞留し始めました。 （開発要望は欲しい度*2の高いものから進めていたのですが、要望の時点で手の掛かることが予期されたものは他のものを優先するようにしたため相対的に大きいタスクは後半から目立ち始めたという感じです。） 滞留し始めると、タスクボードの自分のレーンをメンテナンスする機会が減って、思い出したように最新化するという状況になってしまいました。
メンバーの感想
- 一目で状況が見れるのは良かった
- 長期的なタスクを抱えるとタスクが動かず状況が見えにくく感じた
- たまにメンテを忘れる
- リモートの人のメンテするの大変
- Redmineとの役割の差がイマイチつかめなかった（ステータスを一致させるのが手間）
- 視覚的にタスクがどの位置にあるかを俯瞰するのには大いに役に立った。特にRedmineで自分の持ち分以外
- 本当に見える化するならタスクボードの前で毎朝朝会するくらいじゃないと効果薄いと感じた*3
- きっちりやるのはあまり乗り気じゃないけど朝または昼に軽くやるくらいならやった方がいいかも
- 順調にいってると思ってるときに、どう？って聞かれるのストレスかなと思って、タスクボードという第三者的中継地点に貼りだされてることで、気になった所だけコミュニケーションとれる、というのはタスクボードの利点かなーと思った
- 設計、実装、テストと詳細に分かれているのは把握しているが、そこの情報が得られても大してメリットを感じず、WFRかそうでないかぐらいしか関心がなかった
- テスト側は「次何が来そうか」というのが雰囲気でわかったので助かった
- テスト側からマネジメントという意味ではなしに「進捗どうですか？」って気になるものについてお伺いを立てたりすれば、もっと有効に使えたかもしれない
- マネジメント側では設計、実装などの粒度で情報を得たかった（分析に時間がかかってるなら、それは要件が決まりきってなくって運用などとの調整が必要になったりするし、実装に時間がかかってるなら物量が多いのか難易度が高いのかで介入できるし、テストに時間がかかってるなら品質テストとのバランス調整できないかという話もできる）
- マネジメント側では次のリリース範囲を決める情報の一つになっていた（次のリリースの範囲は早めに把握して、関係しそうなチケットを整理するとかに必要だった）
- この目的意識を把握していないメンバーもいた
まとめると
良かったこと
- 自分の担当範囲外の状況が俯瞰できた
- リリース日を計画する際にタスクの進捗に応じてスケジュールとスコープの調整ができた
改善したいこと
- タスクの大きさに差があり、大きなまま管理しようとしていた
- メンテナンスするきっかけが人に依存していた
- タスクボードの目的が人によってバラツキがあり、自分の関心外のことを行うのが疑問になっていた
あるべき姿を考える
大前提として、弊社開発チームはベストエフォート*4でやる、というのがあります。 開発チームの成果としては、モノをちゃんとリリースできるかどうか、にあるかと思います。 それは、プロジェクトを進めるなかでのスケジュールとスコープの調整につながるのではないでしょうか。 工数管理をしたいわけではなく、詰まっているところがないか、一部に負荷がかかりすぎていないかを見れて、計画を立て続けられる仕組みが良いと考えています。
一方で「設計中」「コーディング中」「テスト中」などの間の完了基準が曖昧になりやすく、大きなタスクほど動きが鈍いだけでなく、一部をテストして別の部分のコーディングに戻るなど実態とそぐわないことも起きていました。 タスクボード上で完了がわかるようにし、また完了基準も明確に見える位置にある方が良さそうです。 また、タスクを一度分析して、タスクを分解していくステップも必要そうです。
その他、情報には賞味期限があり、変化は常に起きるので、変化に一番近い人間が起点となる方が良いと考えています。 しかし、ほころびの予兆は些細な雑談のなかで見つかることもあります。 定期的な会話と雑談的な会話の両方を大事にしてコミュニケーション密度を高められると良さそうです。
「カンバンのアンチパターン」も参考に考える
以下のページで「カンバンのアンチパターン」をダウンロードすることができます。
この中を見ると、以下のようなチェックリストがあげられています。
□ カンバンのボード上のすべてのステップに「完了」列と完了基準があることを確認しているか。
□ すべてのステップにWIP 制限が設定されているか。
□ WIP 制限を使って「作業中」列と「完了」列のカードの合計枚数を制限しているか。
■ 最後のステップのWIP 制限は作業中の項目にのみ適用される。
□ カンバンのボードをいつでも更新しているか。チームのメンバーにも同じようにすることを勧めているか。
□ デイリースタンドアップミーティングの後に、設計についての話し合いやチームの一部のメンバーに関係する問題のための時間を割り当てているか。
□ チームのメンバーがオンラインボードを扱いにくいと感じている場合に、物理的なボードを使用しているか。
□ あなたの戦略やパートナーに合わせてバックロックの計画を慎重に立てているか。
□ 「分解」ステップを追加するか、「分析」ステップに完了基準を設けることで、大きな作業項目が小さなタスクに分解されるようにしているか。
□ 品質がすべてのステップに組み込まれるように完了基準を設定しているか。
□ 品質が先送りになるような依存関係に対処する方法を決定しているか。
□ 顧客のフィードバックやデモを顧客の予定に合わせてスケジュールしているか。
〜「カンバンのアンチパターン」p.5 チェックリストより
このリストを達成できている状態をあるべき姿として定めても良さそうです。
どうするか（改めて注力すべきことを考える）
全てを達成できることがベストですが、いきなりすべてを満たそうとするよりは注力すべきものを決めて、まずはそれが達成できる状態を目指したいと思っています。 先にあげられた改善したい以下の項目への対処を考えます。
- タスクの大きさに差があり、大きなまま管理しようとしていた
- メンテナンスするきっかけが人に依存していた
- タスクボードの目的が人によってバラツキがあり、自分の関心外のことを行うのが疑問になっていた
「分解」ステップを追加する（「タスクの大きさに差があり、大きなまま管理しようとしていた」への対処）
顧客や社内の人間からあがってくる開発要望をそのまま付箋にしていましたが、それをタスクとするには粒度にバラつきがありすぎました。 大きかったタスクは滞留し続けることになってしまい、メンテされなくなってしまった面もあるため「分解」ステップを追加します。 また、タスクボードのステップごとの完了基準だけでなく、タスクのタイトルも”どういう状態がゴールか”が分かるような言葉にしていこうと思います。
会話のきっかけをつくる（「メンテナンスするきっかけが人に依存していた」への対処）
朝会など見直しの時間をとっていませんでした。朝は家で仕事してから出社してくる人がいる（私）などもあるのですが、朝やる必要も無いのでメンバーが顔を合わせられそうな時間帯でデイリースタンドアップミーティングを設定したいと思います。 定期的な会話としては詰まっている項目についてサッと話すデイリースタンドアップミーティングを設定し、雑談的な会話*5の不足を補っていきます。 長い時間をとらずフェイスtoフェイスでさくっと話して、議題があがったら続きはWebで、としていこうかと思います。
目的の共有をする（「タスクボードの目的が人によってバラツキがあり、自分の関心外のことを行うのが疑問になっていた」への対処）
勢いで導入したものの、目的をちゃんと伝えきれていなかった点を反省しています。 自分の見たいものを見たいとき、他の人も見たいかは分かりません。しかし、自分一人であっても見たいということをちゃんと伝えれば協力してくれるメンバーなので、目的を共有した上で運用を再開したいと思います。 また、各々の目的を共有することで、私達のチームなりのタスクボードをつくっていける気がします。
最後に
当たり前のことを実感を持って学びました。 こうして振り返ると盛大に転んでますが、起き上がらないと転び損なので次に活かしていきます。*6 やってみて必要かどうかチームで判断していきたいと思います。
明日はSupership株式会社 Advent Calendar 2016の13日目 @sanojimaru さんです！
