「カンバン ソフトウェア開発の変革」の感想~カンバンはメトリクス駆動のアジャイル開発
「カンバン ソフトウェア開発の変革 Improving Service Delivery in Technology Business」を読んだ。
とても良い本。
率直な感想は「カンバンはメトリクス駆動のアジャイル開発ではないか」。
「カンバン ソフトウェア開発の変革 Improving Service Delivery in Technology Business」の内容はそのまま、Redmineによるチケット駆動開発に全面適用できるし、チケット駆動開発を使えば、カンバンの奥深さをより実感できると思う。
以下、ラフなメモ書き。
【参考】
Yes We Kanban!『カンバン ソフトウェア開発の変革』を読んだ | 世界はどこまでもシンプルである
Technologic Arts Incorporated | 書籍「カンバン ソフトウェア開発の変革」発売
【1】Redmineによるチケット駆動開発を経験している者から見れば、カンバンは所詮タスクボードに過ぎないでしょ、と思ってしまう。
単なるチケット集計機能に過ぎないカンバンにそんなに奥深さがあるのか?と。
また、ScrumやXPなどのアジャイル開発の観点では、スプリントやイテレーションというタイムボックスでスコープをコントロールするやり方に対し、カンバンでは、仕掛りチケットの枚数をWIP制限で制御する手法に過ぎないのでは、と思う。
さらに、TOCのドラム・バッファ・ロープや5つの改善サイクル、ボトルネックの改善の観点で見れば、カンバンはそれらの技法を取り入れただけではないのか、と思ってしまう。
でも、「カンバン ソフトウェア開発の変革 Improving Service Delivery in Technology Business」を読むと、カンバンがそれらの技法と全く異なる概念であることを明確に述べている。
ScrumやXPなどのタイムボックス型アジャイル開発は、イテレーションというタイムボックスでスコープを制御し、プラクティスと言う名の運用ルールで開発メンバーを制御しようとする。
定期的にリリースするから、受託開発案件や製品開発で多いだろう。
一方、カンバンは、タイムボックスはないので緩い。
仕掛中のチケットの枚数をWIP制限で上限を設けて、作業の停滞をなくすことに注力する。
ソフトウェア保守や、最低限の機能を持つ製品(MVP)ないし市場投入可能最小限リリース(MBR)の開発案件に向く。
また、アジャイル開発のようなガチガチのプラクティスはないので、現場の運用ルールをいきなり変えずに、見える化から始めましょう、という掛け声のもとで、導入しやすい利点もある。
【2】カンバンの成功のレシピ
カンバンを成功させるレシピは以下が紹介されている。
【2-1】1)品質に集中
2)仕掛り(WIP)を減らす
3)頻繁なデリバリ
ここまでは、アジャイル開発でも同じ。
カンバンの思想の根底には、リトルの法則が作業を支配している、という発想があるように思う。
リトルの法則は「L=λW:顧客数=到着率 * 処理時間」。
SW開発ならば、「WIP=Velocity * サイクルタイム」または「WIP=Velocity * リードタイム」を表す。
つまり、下記の因果関係が発生していることになる。
リードタイムが長くなる
=仕掛り作業が増える
=メンバーが忙しくなる
=メンバーの暗黙知が共有できなくなる
=ソフトウェアの品質が劣化する
だから、カンバンの第1段階は、ソフトウェアの品質を確保し、仕掛り(WIP)を減らすことで、リードタイムを短くし、頻繁にリリースできるようにする。
【2-2】4)要望とスループットのバランスを取る
5)優先順位付け
カンバンの第2段階では、頻繁なデリバリが安定稼働している前提で、デリバリの対象にビジネス価値をがあるかどうかを気にする。
つまり、ビジネス価値の最適化によって、デリバリの質を上げるわけだ。
そのために、要望とスループットのバランスを取って、開発チームが処理できる分量の要望に絞り込む必要があるし、そのために要望に優先順位を付ける必要がある。
【2-3】6)予測可能性を高めるために、ばらつきの要因の解消
カンバンの第3段階は、カンバンの内外から影響してくる要素のばらつきを制御すること。
「カンバン ソフトウェア開発の変革 Improving Service Delivery in Technology Business」では、初期のリーンの論文では、生産のばらつきの考慮が不足していると厳しく指摘している。
このレベルは、カンバンの第2段階までクリアして初めて考えた方が良い、とのこと。
【3】カンバンのメトリクス
「カンバン ソフトウェア開発の変革 Improving Service Delivery in Technology Business」で最も印象に残ったことは、以下のメトリクスだ。
【3-1】WIP(仕掛り)
チケット駆動なら、作業中のチケット枚数を表す。
カンバンでは、カンバンに流れる作業に上限を課すために、WIP制限を課す。
WIP制限の枚数が少ないほど、全体のプロセスを見渡すと、暇になる人が増えてくる。
暇にならないプロセスがあれば、そこがボトルネックであると分かる。
つまり、カンバンでは、WIP制限を厳しくしてボトルネックを洗い出し、チームや組織に良い緊張をもたらす。
例えば、マネージャの立場では、暇な人が多いと、部署の稼働率が下がり、スループットが下がって売上が下がるわけだから、すごく不安になってくる。
だから、ボトルネックをフル稼働させるか、ボトルネックを解消させることで、スループットを上げるように仕向ける。
カンバンの手法では、WIP制限を実現する場合、キューに入る作業の最大枚数をWIP制限にする場合が多い。
そうすれば、ビジネスオーナーやプロダクトオーナーが要望をキューに入れる時に、要望の枚数に制約を課せるので、自然にWIP制限を実現できるから。
【3-2】リードタイム
チケット駆動なら、チケットの平均完了日数。
リードタイムが長いほど、リリース間隔が長くなる。
アジャイル開発なら、リードタイムはイテレーションよりも短くなるように、チケットの粒度を細かくするだろう。
カンバンでは、ScrumやXPよりもリードタイムは短くなる。
【3-3】納期パフォーマンス(納期遵守率)
カンバンで最も重視されるメトリクス。
「作業項目(または要件)を計画通りにデリバリーしたか」という割合。
チケット駆動なら、チケット完了率。
つまり、あるイテレーション内で、イテレーション計画時に予定したチケットと割り込みで発生したチケットの合計枚数に対し、完了したチケットの枚数を割った割合。
納期パフォーマンスがは「目標通りにデリバリーできたか」という指標そのものなので、予測可能性のメトリクスとして使える。
つまり、納期パフォーマンス(納期遵守率)が高ければ、ビジネスオーナーは安心して要望を追加できるし、信頼関係を増すこともできる。
逆に、納期パフォーマンスが低ければ、見積もりの精度が悪く、ビジネスオーナーの信頼も下がるだろう。
【3-4】スループット(またはVelocity)
スループットは、ある決まった時間(例:1ヶ月)内にデリバリーされた項目数を表す。
アジャイル開発なら、Vecloity。
チケット駆動なら、イテレーション毎の平均完了チケット数。
カンバンとアジャイル開発では、スループット(Velocity)の扱いに微妙な違いがある。
アジャイル開発では、Velocityは急激に増やすべきものではなく、安定すべき数値として扱う。
つまり、次のイテレーションの見積りに使うために、実績値をベースに予測可能な生産能力として扱う。
一方、カンバンでは、チームや組織がどんなパフォーマンスを発揮しているか、常時改善を行われているか、という指標として使われる。
つまり、ある時間軸でのデリバリー量の予測や、具体的なデリバリーの約束に使うわけではない。
【3-5】デリバリ効率
デリバリ効率=(トータルコスト-(取引コスト+調整コスト))/トータルコスト
または
デリバリ効率=1 - (取引コスト+調整コスト)/(利益+取引コスト+調整コスト)
但し、取引コスト:間接費。例えば、ソフトウェア製品をCDに焼くリリース準備、他サーバーと係るデプロイなど。
調整コスト:直接費。例えば、会議・マーケティング・ヘルプデスクなど。
デリバリ効率は、ビジネス価値として生み出す製品開発の開発効率を表すと思われる。
デリバリ効率を上げるには、デリバリー間の間隔を長くするか、調整コストや取引コストを減らすか、の手法がある。
20世紀は「規模の経済」を優先するために前者を選択する時が多かったが、長期間の減価償却が発生するデメリットがある。
最近のリーン思考を標榜する企業では、バッチサイズ(例:リードタイム)を効率的にするために、調整コストと取引コストを削減することでムダをなくす。
【4】カンバンの変数
カンバンをコントロールする変数は以下がある。
1)仕掛り(WIP)
2)優先順位付け
3)デリバリー
4)優先度分類
5)リードタイム
上記の変数は、カンバンのパフォーマンスを調整するためのレバーの役割を果たす。
レバーをどのように動かし、効果的だと思わせる選択肢をどのように取捨選択するかは、腕の見せ所。
【5】キューとバッファの違い
僕の理解が甘かった部分は、キューとバッファの違い。
【5-1】キューは、処理待ち行列。FIFO。
キューの要素は上から順に優先順位付けされている。
キューのサイズにWIP制限を課すようにすれば、優先順位付けしやすくなる。
例えば、優先順位付けキューのサイズが8枚で、既に5枚埋まっているとしたら、ビジネスオーナーには、直近にデリバリ可能な要望は残り3枚です、今までのバックログにある要望から3枚だけ選んで優先順位付けしてください、と言えばいい。
「カンバン ソフトウェア開発の変革 Improving Service Delivery in Technology Business」では、マイクロソフトのチームの事例として、バックログと開発者のタスクリストの間に、WIP制限付きキューを設けて、作業量を調整する手法が取られていた。
その結果、リードタイムが劇的に短くなる効果が出た。
【5-2】バッファは、処理待ち項目を貯める場所。
利用シーンとして、ボトルネックの前に置く手法がよく使われる。
ボトルネック保護、保護アクションと呼ばれるらしい。
バッファをボトルネックの前に置く効果は二つある。
一つは、システム内の仕掛り数が増大するので、リーンの立場では、ムダが増え、リードタイムも長くなるが、容量制約の資源による作業が安定して流れるので、スループットも増える。
つまり、ボトルネックの稼働率を増やしてスループットを増やす。
もう一つは、ボトルネックへの作業項目の到着率のばらつきを吸収することで、ボトルネックの稼働率を上げること。
以上のように、キューとバッファを意識して使い分けることで、カンバンで流れる作業チケットを制御しやすくする。
「リーン開発の現場 カンバンによる大規模プロジェクトの運営」では、カンバンにキューとバッファを配置するノウハウが詳しく書かれていた。
【6】ばらつきの要因の解消の対処
カンバンが従来のアジャイル開発よりも良いとしても、運用が難しい原因の一つは、作業の到着率のばらつきを抑えることが難しい事だと思う。
「カンバン ソフトウェア開発の変革 Improving Service Delivery in Technology Business」では、ばらつきを与える要素の分類として、シューハートの分類「偶然原因」「突き止められる原因」を使っている。
【6-1】偶然原因は、ばらつきがランダム。
ばらつきの内部要因に相当。
例えば、ソフトウェアのバグ。
つまり、予測できない。
しかし、実は、チームやマネジメント層の制御下にある。
実際、ソフトウェアの品質を良くすれば、バグは減る。
解決策はいくつかある。
一つは、作業項目のサイズを整える。
例えば、チケットの粒度を整えたり、RedmineならIssueTemplateプラグインでチケット内容をテンプレート化する。
2つ目は、作業タイプごとに分類する。
例えば、チケットの種類をトピック・ストーリー・タスクに分ける。
あるいは、チケットをタスク・バグ・課題などのように分ける。
この時、チケットの種類ごとに、WIP制限を課すと尚良い。
つまり、開発メンバーの制約、開発環境の制約などのボトルネックを考慮して、WIP制限を課すと、リードタイムの短縮やスループットの増大に寄与する。
3つ目は、作業項目を優先度で分類する。
例えば、チケットの優先度。
優先度ごとにWIP制限を割り当てるとよい。
例えば、今日中に完了すべき特急チケットは、WIP制限1枚とする、など。
【6-2】突き止められる原因は、外部要因によるばらつき。
例えば、顧客による要望変更、マーケット環境の急激な変化によるプロジェクト中止、など。
突き止められる原因は、チームが制御できないが、予測可能ではある。
だから、事前にリスク対策を取ることはできる。
例えば、曖昧な要件に対しては、チケットを却下したり、対応しにくいために放置チケットを見える化することで対処する。
カンバンから、毎月のレポートで、曖昧な要件であるがゆえに却下されたチケットを載せておくと、ビジネスオーナーも気づいて、自分たちで容量の消費をしないように注意し始める。
つまり、不適切な要件記述から生じた「突き止められる原因によるばらつき」という根本原因を除去できたわけだ。
つまり、この事例では、カンバンが開発プロセスを透明化することによって、メンバーだけでなくビジネスオーナーにも影響を与えたことになる。
カンバンが与える透明性とレポートによる効果は、平均リードタイムとばらつきの範囲に対する影響を小さくさせて、根本原因を取り除いたわけだ。
【7】このように読んで理解してみると、カンバンは作業状況を見える化することで、透明化を推進し、組織変革をもたらしている事が分かる。
また、本の事例を読むと、作業チケットの流れをバリューストリームマップで表現してボトルネックの解消とスループットを向上させる部分は、すごくTOCに似ている。
でも、僕が一番興味深いのは、カンバンがメトリクスをかなり重視している点だ。
5つのメトリクス(WIP、リードタイム、納期遵守率、スループット、デリバリー効率)によって、チームや組織の改善が進んでいるかどうか、パフォーマンスをチェックする。
この辺りは、WF型開発で管理者が稼働率や生産性、原価計算をしている部分に似ている。
また、カンバンのメトリクスは、Redmineによるチケット駆動開発でも実現可能だ。
Redmineなら下記のように置き換えられる。
1)WIP=イテレーション内の作業中のチケット枚数
2)リードタイム=チケットの平均完了日数
3)納期遵守率=イテレーション毎の、完了チケット枚数/(計画時のチケット枚数+割り込み発生のチケット枚数)
4)スループット≒Velocity=イテレーション毎の平均の完了チケット枚数
上記4つのメトリクスをイテレーションごとに算出すれば、チームの生産能力や改善能力を測定することもできるだろう。
このアイデアも実際に試してみたい。
最近のコメント