デジタルトレンド

プロジェクト管理方法としての「かんばん方式」について聞いたことはあっても、その詳細については知らないという人は多いかもしれません。かんばん方式は、スクラム（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（完了）：タスクが完全に完了し、これ以上検討する必要がないときのカラム

続きは以下より

デジタルトレンド