ソフトウェアカンバン手法の概要	
長瀬 嘉秀	

「カンバン(邦訳版)」の刊行に寄せて 	  トヨタの「かんばん」の本質は、モノの流れの滞留(異常)を検知することで あり、またトヨタ生産方式の狙いは、異常(カイゼン・ニーズ)に対して前向きに取り組む組織文化・風土を醸成することにある。 	  
本書では、今までに出版されているアジャイル関連の書籍以上に組織文化や マネジメント(経営)に触れると同時に、「かんばん」の考え方を用いてより「儲かるIE(Industrial	  Engineering)」に近づいてきた取組みであると言える。マネ ジメントを行っていく上で大変重要でかつ根源的な西洋文化と改善文化(日本 文化)という部分にも触れ、よりトヨタ生産方式の本質を理解した上での「カン バン」(本書)の取組みであることが伝わって来る。	  
本書の「カンバン」は、アジャイル関連の書籍には少なかったトヨタ生産方式の本質を意識した内容になっており、アジャイルの枠を超えた「儲かる IE」とソフトウェア工学の新たな融合を提唱する一冊である。	

私が指導した IT	  職場では、サービスを提供するまでに2ヶ月の期間を要していたが、カードレベルで見ると、現実には、20時間前後の時間しか消費しておらず、大半が、仕掛りの量と優先順位の問題により遅延を引き起こしていた。 仕掛りというのは、トヨタ生産方式では、手待ちのムダとして扱われるが、こ の仕掛りを無くすために、一個流しで整流化するためには、本書のような「カ ンバン」のしくみが必要になってくる。 	  
企画、開発、運用などのチームを跨がった場合には、チーム毎に複数の案件 を抱えているため、仕事の優先順位がチーム毎に勝手に設定されている。
した がって、経営者から見ても、品質の向上やリードタイムの短縮を行うためには、 本書に書かれているような取組みは有効であり、組織文化を変えるための古く て新しい取組みであるといえる。既にアジャイル開発に取り組んでいるチームの次のステップとして、営業〜企画〜開発〜運用までのリードタイムの短縮などに是非この「カンバン」(後工程引取り)方式を用いて実践し、研究されることを推奨する。 	
2014年6月
株式会社 豊田マネージメント研究所 	  副社長 エグゼクティブ・コンサルタント 高木 徹

万能な開発プロセスはない	「フリーサイズの」開発方法論がうまくいかない理由
チームは以下で異なる。
・スキルセット・経験レベル・能力レベルプロジェクトは以下で異なる。
・予算
・スケジュール・スコープ
・リスクプロファイル

組織は以下で異なる。
・バリューチェーン・ターゲットマーケット

出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

開発プロセスのトレンド	• ウォーターフォール	  • スパイラル	  • イテレーティブ	  – RUP（ラショナル）	  • アジャイル	  – XP	  – スクラム	  – FDD	  • リーン	  • カンバン	アジャイルの特徴：短期間の反復開発
ウォーターフォール

イテレーティブ

アジャイル

時
間分析
設計
凡例
実装

スコープ

ObjectMentor資料より
7	  テスト

ゴールドラットの「制約条件の理論」 	
ボトルネックを発見し、それがパフォーマ ンスの制約とならなくなるまで、その解消方法を考えるというものである。 ボトルネットが一つ解消すれば、新しいボトルネックが出てくるので、サイクルを繰り返す。
ボトルネックを発見し除去することで、パフォーマンスを体系的に改善するという反復的な手法である。

• ド	  ラ	  ム	  ・	  バ	  ッ	  フ	  ァ	  ・	  ロ	  ー	  プ	  	  • 開発の状況をフローとしてとらえトラッキングする	  • プル型システム(後工程引き	  取り方式)	  	  • 仕掛り(WIP)	  が事前に同意したある一定量に制限	  • カンバンシステムへ	  	  カンバンシステムへのアイデア	• ワークフローの見える化	  • 作業項目型	  • リズム（フローの独立、平準化）	  • 優先度分類	  • 具体的な管理レポート	  • 改善のための検討	  	  カンバンとは	
• 皇居東御苑訪問	  	  • 入園票で制御する	  • 入場者を制限して、観光（処理）をできるようにする	

出典：「KANBAN」by	  David	  J.	  Anderson	  より

カードウォール	

出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

5 つのプロパティ• ワークフローの見える化	  • 仕掛り(WIP)の制限	  • フローの測定と管理	  • プロセスポリシーの明示化	  • 改善機会を認識するためのモデルの使用	  	  出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

カンバンの手順	
• 品質に集中する。	  
• 仕掛り(WIP)を減らす。	  
• デリバリーをひんぱんに行う。	  
• 要望とスループットのバランスを取る。	  
• 優先順位を付ける。	  
• 予測可能性を向上させるために、ばらつきの原因を解消する。	  	  仕掛り(WIP)の減少とひんぱんなデリバリー	
• 累積フローダイアグラム	  OTAダウンロードチームの2003年秋から2004年冬のCFD

出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

• 累積フローダイアグラムの例２	

出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

仕掛りの量が減ると、平均リードタイムが短くなるワークフローとリードタイム	
MS社での例
初期のワークフローとリードタイム

未処理項目

出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

概算値見積り作業とPTC（割り込み作業）が邪魔をする
概算値見積りとPTC入力を含むワークフロー

概算値
概算値

未処理項目

出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

	  	  	  	  	  	  	  	  	  	  	  	  未処理項目
出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

更なる改善テストチームを 3 人から 2 人に減らし、開発者を 1 人追加する
リソースの平準化

未処理項目
出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

リソースの追加

未処理項目
出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

TTR(解決時間) Microsoft社の会計年度で表示
TTR	  
５四半期で５ヶ月から３週間へ

未処理項目	  	  出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

カードウォール	

出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

	  	  	  	  出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

カンバンシステムの調整	

出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

分析(Analysis)の上に4という数字が書かれていて、制限が4であることがわかる。
ところがカードは3枚だけである。4 ー 3 = 1 なので、 入力キューであるエンジニアリング準備完了から、分析に項目を1つ引き取ることができるという信号が表示されている。
ここで入力キューの制限も4であるが、今あるのは2項目だけである。1 つを分析に移すと、残りは1つだけになる。
したがって、次の優先順位会議では、新しく3つの項目を入力キューに入れることができる。

出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

デリバリーリズム	
カンバン手法は、タイムボックスに区切られたイテレーションをなくし、優先順位付け、開発、デリバリーの工程(アクティビティ* 2)を分離する。それぞれのリズムに対し、自然な形での調整が可能である。カンバン手法では定期的なリズムという考え自体が不要である。カンバンチームはそれでもソフトウェアを定期的に、それも短い時間軸でデリバリーする。「アジャイルマニフェストの背後にある原則」も満たしている。しかし、 不自然に物事をタイムボックスに入れると、さまざまな機能不全が生じるため、そのようにならないようにしている。	

デリバリー効率	
トータルコスト – (調整コスト＋取引コスト)		  	   デリバリー効率（％）＝ 100％ ×	
ソフトウェアリリースのトータルコスト

コストだけの式

1,500,000 ドル – 500,000ドル		  100％ ×		  1,500,000 ドル	

= 66.7 ％	

あるリリースでどれだけの価値がもたらされるかが分かれば、デリバリーの頻度をどれだけの長さにすべきかの判断をより的確に下すことができる。毎月のソフトウェアのデリバリーで 150 万ドルのコストに対して、 200 万ドルの収益が見込まれるのであれば、デリバリーによって 50 万ドル の利ざやが得られる。	  	   デリバリー効率（％）＝ 100％ ×	 1 - 	
価値を考慮した式

調整コスト ＋ 取引コスト	
利ざや ＋ 調整コスト ＋ 取引コスト	  500,000 ドル	
1	100％
×		  500,000 ドル ＋ 500,000ドル		  = 50％	

出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

優先順位分類	

出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

緑の作
業
カド	 

黄色の作業カード	

出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

常時
メン
バ	の名
前	 
オレンジ色の	作業カード	
出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

メトリクスと マネジメントレポート	
• 仕掛かりの追跡	  • リードタイム	  • スループット	  • 初期品質	  	  仕掛りの追跡	

未処理項目

出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

リードタイム	

出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

スループット	  	  	出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

初期品質	

出典：「カンバン ソフトウェア開発の変革」〈リックテレコム〉より

3 種類の改善機会	
• ボトルネック	  • ムダ削減	  • ばらつき軽減	  改善の5ステップ	• ステップ 1: 制約を識別する。	
• ステップ 2: 制約の活用方法を決定する。	
• ステップ 3: その他のことはすべて、	  ステップ 2 での決定に従属させる。 	  
• ステップ 4: 制約を補強する。	
• ステップ 5: 惰性を避け、次の制約を識別して、	  ステップ 2 に戻る。	

ソフトウェアカンバン手法の概要	
長瀬 嘉秀