プロジェクト管理方法としての「かんばん方式」について聞いたことはあっても、その詳細については知らないという人は多いかもしれません。かんばん方式は、スクラム（Scrum）などほかのアジャイル方式や、ガントチャートなどのツールとはどのように違うのでしょうか。また、かんばん方式はどのような目的で使われているのでしょうか。
かんばん方式の由来を説明しながらこのような疑問に回答し、実践でどのように使われているのかを解説します。
かんばん方式の基本原則
日本発祥の「かんばん」という言葉はトヨタの生産システムから生み出されたことは、業界周辺では良く知られています。その存在と基本原則を知っていれば、利益を受ける人は多くなると見込まれています。かんばん方式の基本原則とは、リーン生産方式、継続開発、カスタマーオリエンテーションなどです。すべてトヨタの元副社長、大野耐一氏の著書『トヨタ生産方式―脱規模の経営を目指して』に説明されています。
かんばんという言葉を逐語訳するなら、「かん」は「見える」または「視覚的な」、そして「ばん」は「カード」または「板」となります。かんばん方式は、トヨタ工場の在庫管理の効率化を目的としたカード（帳票、作業指示書）が使われています。倉庫内が雑然とすることがなく、作業現場に必要な数だけ、必要な部品を供給できるようになっています。
トヨタ・カローラの製造現場で車体にドアを取りつける作業をしていて、新車のドアを10個を連続で取り付けなければならないとします。このとき、手元にドアが5個しかない場合、新しくドアを注文しなければなりません。かんばんカードを取り出してドアを10個注文する旨を書き込み、ドアを製造している現場にカードを持って行きます。いま残っている5つのドアを使い終わるまでに、新しいドアが作られると分かっているので、安心感があります。
トヨタの工場で取り入れられているのは、このような方法なのです。手元にある最後のドアを取り付ける頃には、新しいドアが10個届けられます。必要なときだけ新しいドアを注文する、というサイクルを常に続けるという仕組みです。
このかんばん方式が工場全体に行き届いていると想像してください。無駄な部品が倉庫の中に数週間、数カ月にわたって寝かされていることは決してありません。全従業員が求められた量に応じて作業し、予備は本当に必要量だけ製造されます。受注数が増減しても、このシステムなら対応できます。
かんばん方式のカードの考え方で主軸となっているのは、部品の数を少なくすることです。たとえば、かんばん方式では、ドア用のカードは全製造ラインにおいて10枚しか与えられていません。つまり、生産ループ中で使えるドアの数は10個だけです。新しいドアをいつ発注するか決めるのは取り付け担当部署の仕事です。発注可能数はいつも10個に限られていて、取り付け担当部署だけが現場で必要となる個数を把握し、製造部門に発注できるようになっています。
このリーン生産方式と呼ばれる方法は、最初にトヨタで導入されましたが、世界中の多くの企業でも採用されています。ただし、上の例は製造に関するものなので、ソフトウェアエンジニアリングとは異なります。
かんばん方式はソフトウェア開発にどのように役立つのか？
では、かんばん方式とそのほかのアジャイル方式ではプロジェクト計画がどのように違うのか見ていきます。
かんばん方式とスクラム方式の違いは以下のようになります。
- かんばん方式にはタイムボックスが存在しない（タスク、スプリントのどちらの場合でも）
- かんばん方式のタスク規模は大きくなるが、数は少なくなる
- かんばん方式では期間評価は任意かまったくない
- かんばん方式には「スピードチーム」は存在せず、全導入過程にかかる平均時間だけがカウントされる
それでは、上のリストを見ながら考えてみましょう。スプリントを廃止して作業規模を拡大し、チームワークのスピード計測をやめたらなにが残るでしょうか。なにも残りません。
管理ツールの主要なものをすべて廃止したら、開発管理について語ることすらできなくなります。おそらく、かんばん方式に対するもっとも大切な疑問です。
マネージャーは常に管理とその達成に考えを巡らせているものの、実際にはあまり成功していません。マネージャーによる開発プロセスの監督というのは作り話なのです。チームが働きたくなければ、どのようなレベルで管理したとしてもプロジェクトは失敗します。
一方、チームが楽しく、最高の効率で働いていれば管理の必要などありません。そのような状況での管理はかえってプロセスの邪魔になるだけで、コストも増大するからです。
例をあげれば、スクラム方式に共通する問題として、話し合いや会議によるコストが増大し、またスプリントで膨大な時間が無駄になっていることが挙げられます。スプリント完了に少なくとも1日、そして次のスプリントを開始するのにまた1日かかるという次第です。スプリント期間が2週間なら、そのうち2日間をこうした作業に当てるだけで20%を費やしているということになります。これは大変な数字です。そのため、スクラム方式では、デイリーラリーやスプリント・レストロペクティブなど、スプリント過程そのものの維持のために全体の30%から40%もの時間が浪費されていると言えるのです。
それに対し、かんばん方式はタスクに集中するという点でスクラム方式と異なります。スクラム方式の主な目的はスプリントを首尾よく完了することですが、かんばん方式ではタスクが先に来ます。スプリントはまったくせずに、チームは首尾一貫してタスクに集中した作業をしています。完了した仕事を納品する準備ができたら、新しいタスクが配備されます。また、かんばん方式に基づいて作業をしているチームでは、タスク完了にかかる時間の見積もりを作ることはありません。そもそも無意味で、こうした見積もりは不正確であることがほとんどだからです。
作業チームを信頼しているなら、マネージャーが時間の見積もりをする必要性などあるでしょうか。かんばん方式のマネージャーの目的は優先タスクのプールを作ることにあり、チームの目的はこのプールを可能な限りたくさん完了することです。それだけなのです。管理手段のようなものは必要ありません。マネージャーがしなければならないことは、タスクプールへの項目の追加か、優先順位の変更だけに尽きます。かんばん方式のマネージャーはこのようにしてプロジェクトを管理しているのです。
チームがかんばん方式で作業している様子をボードに書くとすれば、次のようになります。
ボードのカラムを左から右へ説明したものが以下です。
- Goals（ゴール）：このカラムを設けるのは自由だが、あると便利。プロジェクトのゴールを高めに設定しておけば、チーム全員が認識して、定期的に思い出すようになる。たとえば、「作業スピードを20%上げる」「Windows 7のサポートを追加する」といった目標
- Story Queue（ストーリーキュー）：開始準備が整ったタスクについてのカラム。優先順位が一番高いタスクのカードが一番高いところに置かれ、最初に取られて次のカラムに移される
- Elaboration & Acceptance（推敲＆承認）：このカラムを含め、「Done（完了）」より前のカラムはすべてチームのワークフローごとに違うものになるかもしれない。まだ話し合い中のタスク、たとえば未確定のデザインや最終決定が必要なコードアプローチはここに置く。話し合いが完了したら次のカラムに移動する
- Development（開発）：機能開発が終わるまでのタスクはここに置く。タスクが完了したら次のカラムに移動する。機能の構成が不正確・未確定の場合は左側のカラムに移動する。
- Test（テスト）：テスト中のタスクはこのカラムに配置する。なにか問題が発生した場合は「Development（開発）」カラムに戻す。問題がなければ次のカラムに移動する
- Deployment（展開）：各プロジェクトには、サーバーに新バージョンをアップロードする、コードをレポジトリーにコミットするなど独自の展開がある
- Done（完了）：タスクが完全に完了し、これ以上検討する必要がないときのカラム
最優先タスクが出てくる可能性はどのカラムにもあります。その場合、計画の有無や内容にかかわらず、そのタスクをすぐに実行しなくてはなりません。最優先タスクのためのかんばんボードを特別に作るケースもあります。図の上部に「Expedite（緊急）」というカラムがあります。「Expedite」カラムに入れられるのは一番優先度の高いタスクで、チームはそのタスクにできるだけ早く着手・完了しなければなりません。ただし、このカラムに入れて良いタスクは1つだけと決まっています。もう1つ作るなら、現段階での最優先のタスクが完了するまで「Story Queue」カラムに追加しておきます。
さて、このボードで一番重要な要素について説明します。例として作ったボードの各カラムの下に数字が見えます。この数字は、各カラムに一緒に入れられたタスク数を表しています。数字は実験的に選んだものですが、たいていはチームにいる開発者の数、つまりチームの作業能力を表します。
チームにプログラマーが8人いる場合は「Development」カラムに4と入力します。というのは、プログラマーが一度に作業できる開発中のタスクは4つしかなく、経験を伝えたりシェアしたりする理由もたくさんあるからです。プロジェクトが2つだと、退屈して話し合いに無駄な時間を使ってしまいます。逆に8つとするとプログラマーそれぞれが自分の仕事に取り掛かりますが、経験を伝えたりシェアすることなく進めるとタスクのいくつかがいつまでも完了されないままになる恐れがあります。これでは、タスク開始から終了までの時間を短縮するというかんばん方式のそもそもの狙いからそれてしまいます。
チームそれぞれで事情は異なるので、タスクの限界数に正確な数値は出せません。そのため、最初は開発者の数を2で割った数を書いておき、実績に合わせて調節していくのがおすすめです。
ここで「開発者」を意味するのはプログラマーだけではありません。たとえば、「QA（品質保証）」カラムにとっての開発者はQAスペシャリストです。テスティングはQAスペシャリストの役割だからです。
チームがかんばん方式から得られるもの
かんばん方式でタスクの限界を設けることで、チームはどのようなメリットを得るのでしょうか。
まず、同時に実行されるタスクの数を減らすことにより、それぞれの完了までの時間を短縮できます。本当に必要なアクションだけが取られるため、タスクの間を行ったり来たりしていろいろな構成要素の経過を追ったりする必要はありません。計画はすでに「Story Queue」カラムで完了しているので、スプリント計画や5％ワークショップも必要ありません。本格的なタスク開発はそのタスクが開始したときのみスタートします。
次に、バグがすぐに見つかるようになります。たとえばQAスペシャリストがテスティングに対応できず、その旨をカラムに書き入れる場合です。その場合、新しいタスクの準備が完了しているプログラマーは新しいタスクを「テスト」カラムに動かせません。では、なにをすべきでなのでしょうか？ こうした状況では、チームとして問題解決をしなければなりません。プログラマーが協力してテストタスクのうち1つの達成を助け、後で新アイテムを次のカラムに移動するだけです。これで両方のアイテムをより高速に実行できるようになります。
最後に、平均的なタスク達成に要する時間を計算します。カードを「Story Queue」カラムに入れた日付、タスク開始日、または完了日を記録したり、この3段階における平均的な待ち時間と完了時間を測ったりできます。こうした数字を使えば、マネージャーまたはプロダクトオーナーはなんだって計算できるのです。
かんばん方式で追うべき説明は次の3つだけです。
- 生産の視覚化
- 作業をタスクに細分化する。それぞれの細分化したタスクをカードに書き、そのカードをかんばんボードに貼る
- この記事で説明したカラムを使い、未完成タスクの位置をはっきりさせる
- 生産段階すべてにおいてWIP（作業中または同時進行タスク）数に制限を設ける
- サイクルタイム（タスク完了に必要な時間の平均）を測り、時間短縮できるようにプロセスを常に改善する
この通り、かんばんには3つの基本原則しかないのです！
スクラム方式の基本ルールは9つ、XP方式では13個、そして従来型のRUP方式では120個もあります。その違いを感じてください。
（原文：How & Why to Use the Kanban Methodology for Software Development）
［翻訳：加藤由佳／編集：Livit］
