『KANBAN』は、エリヤフ・ゴールドラット博士の制約理論（TOC: Theory of Constraints）の考え方（Drum-Buffer-Rope 等）をソフトウェア開発に発展させた考え方

　元来TOCはトヨタ生産方式（TPS) からアイデアを得て、理論構築されたフロー(整流化）を重視する考え方で欧米で表現されるリーン(Lean）の一理論であるが、トヨタ生産方式（TPS）を提唱した大野耐一氏の思想的な部分は省かれ、制度的な仕組みを理論化している。

　一方『スクラム』は、トヨタ生産方式（TPS）からアイデアを得てソフトウェア開発プロセスの多能工のチームによる、単純化、可視化を重視する考え方であり、また仕事への対処の仕方の考え方でもある。

　ソフトウエア開発以外（事務、企画作業）にも転用が可能である。

1. KANBANシステムとは元来、プル型のシステムである。

   1. • カンバンやカード、チケットなどが受け渡されながら、プロセス（仕事）が進んでいく。

2. ソフトウエア開発に適用すると

   1. • このカンバンを仕掛（WIP）を制限する事に利用し、その許容量を表現する。

ー制限とはそのプロセスの許容量（能力）である。

• KANBANは付箋を利用したり、ボードにカンバン（カード）を差し立てる枠を付けて使用する。

• KANBANボードは、実際に仕事（ワークオーダー）の可視化のメカニズムを提供する。

3. 何故KANBANシステムが良いか？

   1. • アジャイルチームの許容量によって仕掛(WI P) を設定して、プロセス上の問題やボトルネックなどスループット（フロー）を可視化できる。

      • 単にWIPで制限を設定する事で、品質向上や生産性向上を促進できる。

4. ソフトウエア開発ライフサイクルやプロジェクト管理の手法ではない。

   1. • KANBANは新次改善を促したい部分で適用する改善のツールである。

• ワークフローの可視化

• 仕掛(WIP:Work in Progress)の制限

• 計測と流れの最適化

• 完了の定義、WIPの制限等、明示的なポリシー

記述されている規定の数

• RUP：120+

• XP：13

• スクラム：9

• KANBAN：3

1. 品質に注目

2. 仕掛(WIP)の削減

3. 頻繁なデリバリー

4. 需要とスループット（流量）のバランス

5. 優先順位

6. 予測能力改善の為に可変性（流動性）の原因に挑戦

1. どちらもリーンでアジャイルです。

2. どちらもプル・スケジューリングに基づいています。

3. どちらもWIP （仕掛）を制限します。

4. どちらもプロセス改善を推進するために透明性を活用します。

5. どちらもリリース可能なソフトウェアを早く頻繁に提供する事を重視します。

6. どちらも自己組織化したチームに基づきます。

7. どちらもワークを部品に分割する事を要求します。

8. どちらの場合でも、リリース計画は、経験値(データ：ベロシティー/リードタイム)に基づき常に修正（最適化）されます。

ＫＡＮＢＡＮ

1. タイムボックス化したイタレーションは任意である。

2. コミットメントは任意である。　

3. 計画やプロセス改善のための測定基準はリードタイムを使用する。

4. 機能横断的なチームは任意であり、専門家のチームも許容している。

5. 特に項目のサイズは規定されていない。

6. 特に使用する図表は規定されていない。

7. (ワークフローの状態で/wIPは直接的に制限されている。

8. 見積りは、任意です。（開発チームが見積りをする事はムダ）

9. 容量が空いている限りいつでも新しい項目を追加できる。

10. KANBANボードは複数のチームや個人で共有される。

11. 如何なる役割も規定されていない。

12. KANBANボードは持続性がある。

13. 優先順位付けは、任意です。

1. 品質向上への寄与が不明

   • • 品質向上メカニズムが？

2. スクラムに比べ、要求変更や追加へ柔軟に対処

   • • スクラムでスプリントの期間が長い、またタスクの粒度が大きい場合には、KANBANによる効果が認められると思われる。

     • ー方スプリント期間が一週間、タスクの粒度が細かい場合には、KANBANの効果と同様な事がスクラムで可能である。

3. 改善ツールか不明

   • • プロセスの見える化（可視化）には、寄与

4. WIP (許容量）にてボトルネック対処

   • • プロセスフロー(スループット）を整流化する手法

     • 基本的にドラムバッファーロープの概念と同様

     • この考え方を利用しなくても、タスクの粒度を細かく

1. プロセス（進歩）可視化（見える化）ツールとして、TPSで紹介されている大部屋での進歩状況表示に利用できる。

2. スクラムとの組み合わせにより効果を増強できる。

• 開発チーム以外のステークホルダー間でのプロセス状況の共有化、可視化

• 特に、大規模組織、分散開発環境、オフショア等でプロセスの可視化に有用であり、ソフトウエアツール(RTCやTF S） による支援も効果的

3. 開発チームでの利用はそれぞれの考え方によりKANBAN、スクラムの採用を検討すべきである。

• KANBANの特長で紹介されているイタレーション実施最中での項目（バックログ）の追加、変更への対処はスクラムの規定では厳禁されているが、追加、変更に対処可能なスクラム・チームの運営方法はあります。（弊社での指導実績有り）

開発チームでの開発作業への適用に関しては、持続可能な開発ペース（開発チームのリズム）を維持する容易さや品質に対するチームでの意識の高揚等を考慮して、どの様に適用するべきか検討が必要です。自由度が大きい為に、事前でのチーム内、組織内での意識合わせを十分考慮すべきです。

• 1. スプリント（タイムボックス）を一週間に固定する。

  2. タスクの粒度を極力一時間に近づけ、均一化に努める。

• 弊社の経験上、上記要件がプロジェクトでの追加・変更要求への対処、及びプログラム品質向上への有効な対策である。

• スプリントを一週間とすることで、追加・変更要求へのチームの対処が最大一週間の遅れで対処可能である。また仮に一週間のスプリント実施中での追加・変更を吸収できる方策としては、タスクの粒度の細かさに依存する。

• タスク粒度を細かく、均一化する事で、開発リズムを作り易くなる。またタスク粒度を細かくできることで、一週間というスプリント期間（タイムボックス）での作業が可能となる。

• 更に、タスク粒度を細かくするためにタスクの分割を検討する過程で、「内段取り」の「外段取り」化が志向されて、ムダ取りや、カイゼン活動に結びつく。

• その上、タスク分割とタスク取得のチーム内でのルール化により、より「自工程完結」の思想が導入し易くなり、品質の向上に繋がる。