カンバン観察日記（カンバンの導入と改善のプロセス@Holmes in 2019 Nov.-Dec.）
この記事はHolmesアドベントカレンダー18日目の記事です。
この記事で書くこと
Holmesの開発チームではスクラム開発を実践しており、私も11月から1チームのスクラムマスターを務めています。
チームでは壁にカンバンを作り見える化を促進しています。
この記事では約1ヶ月半の間にどのようにカンバンを成長させてきたかを振り返ろうと思います。
カンバンがチームにとって価値を産んでいれば見られますし、そうでなければ見られず、メンテされず、荒廃していきます。
カンバンに正解はありませんが、課題を発見し改善を繰り返した軌跡を残すことで、誰かのカンバンライフの役に立てればと願い、この記事を書きました。
せっかちな人へ
- 精密性よりも正確性を優先したことでスムーズに改善に向かうことができました。
- 日々改善の兆候を見逃さず、適切に対処していくことが大事だと思います。
基本的な情報
## プロダクト
開発しているのはHolmesのメインプロダクトであるホームズクラウド、という契約マネジメントシステムです。（契約マネジメントシステムについてはこちら）
ホームズクラウドは企業向けのSaaSで、webアプリケーションとして提供しています。
## チーム構成
開発チームは、デザイナー1名、フロントエンドエンジニア1名、サーバサイドエンジニア1名、インフラエンジニア1名の4名です。
スクラムマスターは私が務め、プロダクトオーナーはチームの隣に常時いる環境です。
カンバン history
## 第1世代
初期状態のカンバン
### 概要
非常にシンプルなカンバンからスタートしました。
ToDo Parking Doing Doneの4カラム構成です。
チケットはGitlabのIssueで管理しており、カンバン導入以前はGitlabのIssue Boardを利用してタスクの進捗を管理していました。
TODOにはあらゆるIssueが入り、それをタスクに分解して表現しています。
### 検出された課題
バリューストリーム上、実装着手可能になる前にデザイナーがPOとイメージのすり合わせをしていました。デザイナもチームに所属しているため、実装着手前の作業についてもこのカンバンの中で無理矢理TODOに押し込んでいました。
その結果、異なるタイムレンジのタスクが同一のカラム内にいることにより、やけにタスクが滞留しているように見えてしまい、チーム全体としての進捗が非常に見えづらい状態となってしまいました。
## 第2世代
Ready前のチケットのカンバン
実装チケット、タスクのカンバン
### 概要
第1世代の問題として検出されたタイムレンジの異なるデザインタスクについて切り出して別のカンバンを作成しました。
また、現在のスプリントではまだ着手しないけど、次スプリントに着手予定のタスクをTODOの左側に貯めていくようにしました。
これにより、デザイン〜実装までのバリューストリームの見通しがよくなりました。
### 検出された問題
大まかな流れはみやすくなったものの、そもそもデザインのプロセスが、「TODOを洗い出してそれを全てDoneさせれば完了できる」という性質ではなかったため、当初出したToDoがなかなか消化されなかったり、一度終わらせたタスクが再度復活するなど相変わら見通しが悪い状況でした。
また、運用に関連するタスクは、レーンを用意していたものの、デザイン同様タイムレンジの違いが大きく、ほぼ活用されていない状況でした。
## 第3世代（現役）
Double Diamondの左側を模したReady前チケットのカンバン
実装タスクのカンバン
リリーストレインを模したカンバン
### 概要
バリューストリームの全容が見えてくる中、それぞれのタイムレンジに適する形のカンバンを模索し始めました。
#### Ready前のチケットについて
チーム内で、そもそもReady前チケットの状況を見える化することで何が嬉しいのか、と問い直してみました。
その結果以下の目的が浮かび上がってきました。
- デザイナとしてはアイデアに対して開発チームに適切なフィードバックをもらいたい
- 開発チームとしてはいつ頃スプリントに投入可能になるかを予測したい
これらを解決するため、チームのデザイナが共有してくれたDouble Diamondというデザインプロセスモデルをベースに見える化をするというアイデアに至りました。
これによって、現在チームメンバーはプロセスの途中にあるアイデアに対して、発散させるフィードバックが必要なのか、収束させるフィードバックが必要なのか、Readyになるまでどのくらいかかりそうかを把握できるようになりました。
#### 運用について
運用についてもインフラメンバーを中心に、チームとして何を見える化すると嬉しいのかを問い直してみました。
まず、運用は以下の2種類のタスクがあることがわかりました。
- 日々バグや問い合わせに紐づいて突発的に発生するタスク
- メンテナンスや機能リリースといった計画して発生するタスク
現状ではいずれも見える化できていない状況だったので、まずは計画リリースに関するタスクを見える化することがチームにとってメリットが大きいと考え、この部分を見える化することにしました。
### 検出された問題
Ready前チケットとリリースに関するカンバンは非常に見通しがよくなったものの、チケットやリリースバジェット自体がそもそも大きすぎたため、カンバンに日常的な変化が少なく十分に活用できていない状況が浮き彫りになりました。
また、突発的に発生するタスクについては相変わらずカンバンには表現できておらず、まだ十分な見える化ができていない状況になっています。
まとめ
上記以外にも日々細かな改善を繰り返しています。
様々な改善を進める中で特に重点を置いていた点を以下にまとめます。
## 精密性 < 正確性
これはRSGT2019のcoach's clinicで原田騎郎さんに教えていただき、自分の中で大切にしてきた概念です。
クリニックを受けた際に書いていただいたメモ
精密性と正確性がどちらも低い初期段階で精密性を高めようとすると、手段の精度を高めることにフォーカスが当たってしまい、本来の目的を見失ってしまうことがある、というものでした。
今回のカンバンの例に当てはめると、精密性にフォーカスすると、第一世代の段階で自分たちのワークフローを詳細に検討し、カラムを細分化したカンバンを作ってしまうようなアプローチになっていたと思います。（過去全く同じアプローチをして大きく失敗しました）
一方で正確性にフォーカスすると、カンバンの目的は見える化であるため、まずは最小限のルールで迷わず全ての作業を放り込める、ざっくりした場所を作るようなアプローチに変わります。
特にカンバン導入の初期段階では、チームがカンバンに対して安心して付箋を置ける・動かせるようなシンプルな作りが重要だと、改めて認識することができました。
## bad smellを見逃さない
安心して付箋を置けるようになると、次に必ずカオスが訪れます。
この時改善のための兆候を見逃さず、適宜カンバンを含めたチームの仕組みを改善できなければ、チームにとって価値ある情報が常にアップデートされる状態を保つことはできません。
例として今回発見された改善の兆候について紹介します。
### 観測された事象
チームにリモートのメンバーがいるため、頻繁にカンバンの写真を撮影して共有していました。
このスナップショットを比較することで、「なんか付箋が動いていない」という状況に気づきました。
このとき、付箋のフォーマットに作業着手の日付を記載していたため、「付箋が動いていない」という事象を発見することができました。
### 付箋が動かない要因
付箋が動かない要因は一枚一枚異なります。
付箋が動かないことは事象に過ぎず、結果的にチーム状況の見える化が十分にできていないことが問題です。
この事象の背景を付箋ごとに深掘りし、適切に仕組みを改善していく必要があります。
今回は以下のような要因で付箋が動いていませんでした。
- 問題発見のプロセス・解決方法を探索するプロセス・解決策の実現するプロセスを同じカンバンの同じカラムに表現していた
- 粒度が大きな付箋（複雑性は低いが処理量が多いタスク）
ここに対して、適宜カンバンの分離を行ったり、タスク分解の粒度の工夫や、付箋にチェックボックスリストやプログレスバーを追記するといった改善を行いました。
## まとめのまとめ
スクラム同様、カンバンの改善もOODAの原則に基づくことが重要だと改めて認識することができました。
少しだけ手を止めて、冷静にカンバンを見てみると改善のきっかけを見つけることができるかもしれません。
それでは、良いカンバンライフを！
## 参考
これらの文献は、たくさんの気づき、学び、勇気を与えてくれました。
OODA LOOP
カンバン仕事術
アジャイルコーチの道具箱 - 見える化実例集
## PS
Holmesではアジャイルチームで活躍していただけるデザイナ、エンジニア、Product Managerを募集しています。
ご興味ある方はお気軽にこちらまでDMください！
この記事が気に入ったらサポートをしてみませんか？