gloops advent calendar 22日目
gloops Advent Calendar 2016 - Qiita 22日目です
はじめまして。gloopsのk_mandoです
昨日はy_nakaiによるLINQPadで別DBサーバのテーブルを扱ったお話でした
22日目は技術ネタから離れてしまいますが、3ヶ月ほど カンバン を運用してみたので、その内容を紹介しようと思います
背景
現在チームメンバー7名ほどのマネジメントを実施しております
その中でチケットを使ったタスク管理を実施していましたが、以下のような問題が発生していました
- 同一人物による並行タスクが発生し作業が分散していた
- 作業状態が一目でわかりづらい
- 進捗がないチケットの状況がわかりづらい
- 他者の作業に対する興味の希薄化
※ 別にチケットシステムの問題というわけではないのですが、そのあたりを細かく改善していくには、やりづらかった状況です
よろしい。ならばカンバンだ
上記のような問題に対してどうにか出来ないかと考えていたところ以下の書籍に出会いました
カンバン仕事術
※アフィリエイトではないのでお気軽に
アジャイル開発のプラクティスの一つであるカンバンですが、
- アナログ運用大変そう
- 効果が思ったよりないのでは
といった食わず嫌いをしていましたが、上記書籍の内容や、ブログ、スライドなどを改めて確認すると自分達でも導入できると突然思えました
期待したこと
カンバンを導入することで上記に上げた問題について以下のような改善が出来ることを期待しました
-
同一人物による並行タスクが発生し作業が分散していた
->WIP(Work In Process 仕掛り作業)の数を制限し、一つのタスクを集中して終わらせるようにする -
作業状態が一目でわかりづらい
->物理的に視認できるカンバンを置く
チケットを誰が担当しているかも可視化することで視認性のアップ -
進捗がないチケットの状況がわかりづらい
->動きが少ないチケットに対して、作業内容ではなく、課題を中心にヒアリングを実施することで状況を把握する -
他者の作業に対する興味の希薄化
->物理カンバンを中心に置き1日15分程度のミーティングを実施することで強制的に認識する機会を作る
実際に試したこと
その前に運用を始めた当初のカンバンを晒しておきます
最後のほうに運用した中で改善したものも晒しておきます
、、、チケットの内容は見せれないのでモザイクにしてますがそもそも汚いですね
最初は変更がたくさん発生するのでキレイに作る必要はないというのを真に受けすぎてフリーハンドで書きましたが、みんなに汚いと言われてしまいました。。
汚いものはみんな見たくないので、最初でも変更が容易な形でキレイに作っておくのがよいと思います
物理カンバン
チケットの詳細を物理で管理するのは限界がある(というか無理)ので、電子カンバンでうまく表現出来るといいのですが、
- みんなが1箇所に集まれるようなデカイモニターはそんなにない
- 移動が大変
といった部分から物理カンバンを運用することにしました
どういったものかは上で貼り付けた画像をご参考ください
WIPの数を制限
WIP(Work In Process 仕掛り作業)の事ですが、これが担当者の数以上に増えすぎると、仕事の切り替えが多く発生し1つのタスクに集中できる時間が減っていきます
その結果対応が完了するまでの時間が延びる傾向があります
そこで、基本的には1人1つの作業とし、そのタスクを集中して完了させることで余計な切り替えが発生する事防ぎます
ただタスクによっては、待ちが発生するものもあるので、原則1つとして、待ちが解消されるまでは別のタスクに取り組む事もあります
チケットの可視化
実際のタスクをチケットシステムのチケットにしますが、その際にカンバンに貼り付ける為のチケット(付箋的なもの)も発行します
物理チケット例
物理チケットに記入する項目の中で一部の項目を補足します
チケットのID
詳細はチケットシステムで管理しているので、そこを参照出来るようにリンクできるためのIDを記載
概要(任意)
タイトルだけでわからない場合に補足
作業項目のサイズ
作業のボリューム感をS,M,L という単語で表す
S：5日程度
M：10日程度
L：それ以上。なるべくSサイズになる粒度にチケット分解する
※ 本当は日付という概念を消したい
全員でSはこのぐらいだよねと共通認識を持てるようにしたい
目標期限
自分で終わらせようとした期限
期限(任意)
外部から求めらていたり、本当に終わらせないといけない期限
特になければ未記入
色
例では緑ですが、
緑：通常
赤：バグ
黄：考え中
のように色である程度識別出来るようにしています
赤が増えてくると危険信号ですね！
チケット担当者の可視化
チケット自体に担当者名を書いてもいいのですが、名前だと視認性がよくないので、アバターを作ってそれをチケットに関連づけています
1日15分の終礼
業務時間の残り15分を終礼の時間にしています
進め方は、司会がカンバンの前に立ちみんなはカンバンに注目してもらいます
1つの作業を早く終わらせる事を目指しているためチケットがクローズになったものから確認していきます
私達のチームでは4つのステータスを管理しています
-
オープン
今後の対応が必要なもの
確実に対応しないとわかったものは破棄する
チケットシステムには登録しても、物理には対応が迫ってきたものだけを発行 -
対応中
実際に作業を行っているもの
担当者が外部に存在する場合はそのまま
自分が担当者のまま1週間以上進捗がないものは状況にもよるがオープンに戻す
随時対応を実施した内容をメモ代わりに書いていく -
対応済み(レビュー待ちに近い)
チケットに記載された項目について担当者が作業を完了した状態
確認者(報告者)がいる場合は、その人に確認してもらえる状態 -
クローズ
確認者(報告者)が内容を確認し、期待通りだったもの
対応済みになったものがあるか
ある場合はクローズ出来るか
対応中のもので課題、困っていることはあるか
簡単に対応方法をすり合わせ
時間かかりそうな場合は別途
こうすることで自分以外のタスクの状況も知る
自分が持っていない解決策をチームで検討ができる
簡易なものは方法知っている人がいるだけで解決することも
昨日の困っていたことがどうなったか
といった部分を確認しています
この程度であれば15分で終わり(7人程度というのもありますが)、各自の状況がチームにシェアされるようになります
進捗どうですか？みたいな聞き方は課題などを話にくくなるので、素直に困っていることがあるかどうかを中心に確認するようにしています
このあたりの取組により、チケットの状況、他者の作業への関心、チームによる課題解決、といった部分が促進されています
メトリクス
細かいメトリクスを取るにはまだ整備されていない状況だったため、1週間に1回チケットに記載したサイズのチケットが何件完了したかを残すようにしました
まだまだ安定していませんが、最終的にはチケットのサイズが全てSサイズになるように分割し、それが1週間でどの程度完了するのか見えるようになると、自分たちの戦闘力が把握できて敵(タスク)と戦いやすくなるかなと思っています
カンバンを運用してみて
チーム力を向上させるための1つの取組として、業務フロー改善のためにカンバンを導入しました
上記のような運用を行って1ヶ月程度過ぎたあたりでKPTを使った振り返りを実施しました
その結果をふまえたカンバンがこちら
結局モザイクだらけでよくわかりませんが、対応中の箇所を担当者ごとにグルーピングしたり、線をテープで書いてキレイにしたりみんなが見やすくなるように配慮しました
KPTの内容も全部記載すると長くなるので割愛しますが、チームとしては作業は多少増えたもののメリットを多く感じる事が出来ました
具体的には以下のような点です(デメリットも合わせて)
Pros
- 並行タスクが減り1つのタスクに集中することで機能のリリースが早くなった
- 誰が何をやっているかわかりやすくなった
- 他者のタスクの状況を知れるようになった
- コミュニケーションのきっかけを作れた
Cons
-
チケット手書き面倒
、、、頑張る -
情報の2重管理
物理チケットへの記載内容を最低限のものにした -
紙がもったいない
マグネットシートに一部替えました
magnetic NOTES -マグネティックノートも使いましたが、重要な禁止事項 パラパラ禁止 を守らなかったためにあまりひっつきませんでした；；
またいつかリベンジしてみようと思います -
紙が落ちる
縦にはると落ちづらい
剥がす時は引っ張るように
最後に
何を目的にするかにもよりますが、カンバンの運用自体はそこまで大変ではなかったです
また今の作業を大きく変更することなく現時点をスタート地点とすることで負荷も大きくは増えなかったです
メリットも多く感じられたため、今後更に改善していきたいと思います
カンバン始めてみたいけどどうかなー？という方は一つの事例として参考にしてみてください
最後に書籍中に出てきた言葉で響いたものを記載して締めくくりたいと思います！
始めるのをやめよう！
終わらせることを始めよう！
明日23日目は、t_shibakiさんとなります！
引続きgloopsをよろしくお願い致します！