カンバンはステータス名が大事
「カンバン仕事術」を読んで、気づいたことをメモ。
【1】カンバンの運用では、ステータスはどんな観点で作るべきなのか?
カンバンはチケット管理と相性が良い。
なぜなら、カンバンのステータスはチケットのステータスと同じだから。
チケット一覧をタスクボードでビジュアライズすれば、障害修正プロセスのどの工程でボトルネックが発生しているのか、一目で分かる。
では、カンバンのステータスはどんな観点で作るべきなのだろうか?
一般に、Redmineのワークフローでは、新規→進行中→解決→完了 がデフォルトだが、現場で運用する場合は必ず変更した方がいい。
チケットのステータスと同じ、と言っても、それぞれの現場でワークフローはかなり違う、という経験をしてきた。
たとえば、デフォルトステータスのまま運用すると、実は、ステータスに対応する担当者がいない時もあれば、複数人もいる時がある。
たいていの場合、SIの開発プロセスはインフラ基盤・デザイナー・アプリ開発・DB基盤・設計レビュー担当のように部門ごと、役割ごとに縦割り組織になっているので、割と複雑だ。
よって、ステータスが組織と対応付けられていないと混乱しやすい。
では、カンバンのステータスはどんな観点で作るべきなのか?
【2】カンバンのステータスは、役割やチームごとに割り当てる
「カンバン仕事術」のイントロでは、Jiraを例として、カンバンのステータスを決める場面がある。
最終的には、ToDo→分析→開発→テスト→受入→運用待ち→本番 に決まる。
決め方は、各ステータスに役割ごとの担当者がアサインされる。
最後に「完了」ステータスがない理由は、チケットのタスクを実装して運用待ちになっても、リリース作業は別のベンダーが担当するので、自分たちで本番リリースしてバグがなかったことを見届けられないからだ。
本番リリースしたとしても、バグが出れば、また戻ってくるので、完了という呼び名が合わない、とチームで決めたからだ。
この場面を読んでいると、カンバンのステータスは、作業の役割ごとに決められる点だ。
開発プロセス、組織構造の部門ごとに、作業の役割は細分化されるので、その単位ごとにステータスが対応付けられる。
Redmineのデフォルトステータス「新規→進行中→解決→完了」ではステータスが少なすぎる場面が現実では多い。
経験上、メーカーのように生産工程が、生産計画部・製造部・品質保証部などのように縦割りになっている場合、ステータスの個数が増える傾向が多い。
メーカーの生産工程を模倣したWF型開発や、ソフトウェア工場のプロセスでは、通常のソフトウェア開発よりもさらにステータスが多くなりがち。
たとえば、開発者がバグ修正してコミットしても、テストサーバーにアップするには、構成管理担当者に連絡してアップしてもらい、別のテスターに検証してもらう、といった手間がかかる場合は、「構成管理担当者によるリリース待ち」「リリース終了・テスト検証前」のようなステータスがないと、誰がボールを持っているのか、混乱しやすい。
とは言え、現状を表したステータスをつけて、ワークフローを作るべき。
別の話では、リーン開発の考え方により、バリュ・ストリーム・マッピングの手法を使って、複雑になりすぎたワークフローをリファクタリングしてプロセス改善しましょう、というやり方もある。
【3】ボトルネックになるステータスの前に、キューを置け
役割ごとにステータスをアサインして実際に運用すると、ボトルネックとなる作業者の前に仕掛作業が滞留し、ボトルネックとなる場合が多い。
その原因を探ると、単純に、WIPが少ないからだけではない。
たとえば、受入ステータスのWIPが4になっているが、常に受入可能なチケットが埋まっているわけではない。
基本は、受入可能なチケットがあれば、担当者はすぐに検査・テストして、リリース可能と判断できれば、運用待ちステータスへ流す。
しかし、WIPが4より小さいと、テスターは常に張り付いて作業しないといけないが、出張や会議などで不在の時は対応できない。
一方、WIPが4より大きいと、テスターがフィードバックを戻す前に、開発者は別の作業に仕掛中になってしまって、すぐに対応してくれなくなる。
よって、受入フェーズでは、バッファとなる「準備完了」と、実際の「作業中」でステータスを分ける。
つまり、何らかの理由で制約がある工程の前にキュー(バッファ)を置くことで、ワークフローの一連の流れが停滞しないようにする。
キューの役割は、作業の流れを平準化することだ。
すなわち、フローの中で、流量(つまりタスク)のばらつきを抑える役割を果たす。
一般にキューは、ボトルネックとなる作業の前後で置かれる場合が多い。
たとえば、ToDo、開発準備完了、開発完了、テスト待ち、リリース待ち、レビュー待ち、受入待ち、などの呼び名がある。
キューの有無を判断するには、ステータスの入出条件、退出条件から考えればいい。
【4】カンバンは奥が深い
キューは、アルゴリズムの基本の一つ。
FIFO。
ワークフローを作る際に、流れが悪い場面で使う事が多いと思う。
ふりかえりでプロセス改善する時に、思いつきやすいと思う。
カンバンが面白いのは、2つある。
一つは、ワークフローの改善に役立つこと。
もう一つは、メトリクスやKPIを採取しやすいので、プロセス改善の材料に簡単に昇華できることだ。
なぜなら、カンバンはフロー管理に特化しているので、流量を速度にたとえれば、チケットの枚数で計測化しやすい。
完了ステータスとなったチケットはアウトプットなので、生産性にたとえられる。
「カンバン仕事術」では、下記のKPIを紹介している。
リードタイム:1枚のチケットが最初のステータスから最後のステータスに入るまでにかかった時間
スループット:一定期間(例:1週間)ごとに完了したチケット数
こういうKPIはグラフ化すると分かりやすい。
たとえば、チケット完了日xチケットのリードタイム で散布図をプロットすれば、問題解決について、色々議論しやすい。
なぜ、このチケットはこんなに時間がかかり過ぎたのか?
そこからどんな原因が分析できるか?
たとえば、リリース週xスループットを折れ線グラフにすれば、納期遵守の工夫が見つかるかもしれない。
つまり、これらのKPIを開発プロセスにフィードバックすることで、各ステータスのWIPを減らしたり多くしたり、ステータスを統合・分割する解決法が見つかり、プロセスを改善する行動につなげられる。
元々、Redmineはカンバンと相性が良いので、どのKPIがプロセス改善に役立つのか、そういうノウハウも蓄積できるはずだ。
いろいろ考えてみる。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- 初中級プロマネはIPAデータ白書の統計情報を見積り、生産性、品質の観点で活用せよ(2022.04.17)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
「Redmine」カテゴリの記事
- 第22回東京Redmine勉強会の感想 #redmineT(2022.05.29)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かった(2022.04.24)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- RedmineのWikiタグでタスクリストを書けるようになった(2022.03.21)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
「Agile」カテゴリの記事
- 組織を芯からアジャイルにする対談の感想~今のアジャイルは先カンブリア時代なので何でもいい、アジャイル警察はいらない(2022.08.05)
- 製造業の業務にスクラムを適用できるのかという疑問~全てのビジネスモデルにスクラムを適用できるのか?(2022.07.31)
- 認定スクラムプロダクトオーナー研修の感想(2022.07.28)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
コメント