BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ アーティクル 「かんばん」をソフトウェア開発に適用する: アジャイルからリーンへ

「かんばん」をソフトウェア開発に適用する: アジャイルからリーンへ

原文(投稿日:2008/01/14)へのリンク

概要

かんばん1は、トヨタ生産方式(TPS)で使われる物理的なカードであり、非集中型のプル型生産管理を支援します。かんばんは、リーン生産方式のツールとして世界中の製造業に広まりました。現在、アジャイルソフトウェア開発において、壁にカードを貼るようなプロジェクトの見える化は、よく見られるプラクティスです。これは、「ソフトウェアかんばん」や「タスクかんばん」と呼ばれることもあります。今では、ウォーターフォールのようなプロセスモデルの中で、かんばん方式を利用する製品保守チームを見ることもあります。それでは、かんばんとは何でしょうか? かんばんは、なぜソフトウェア開発の場で使われるのでしょうか?

この記事では、最初にTPSといったリーン生産方式において、かんばんシステムがどのようなものであるかを説明し、成熟産業における実践と原則から本質を見つめ、ソフトウェア開発に当てはまる概念を明らかにします。次に、ソフトウェア開発プロジェクトについて考え、かんばんを使用している例に注目します。そして、製造現場のかんばんシステムとソフトウェア開発のかんばんシステムの間の共通点と相違点を分析し、ソフトウェア開発にかんばんシステムを効果的に適用する方法についてアイデアを示します。また、kanbandev 2の議論に現れた「KSSE - Kanban System for Sustaining Engineering」(持続するエンジニアリングのためのかんばんシステム)の最近の動向を紹介します。最後に、ツールとしてかんばんを使う元の背景を含むTPSの全体像とソフトウェア開発においてさらに学べることを示します。

TPSにおけるかんばんとは?

かんばんは指示を伝達する仕組みであり、通常は透明なビニールで包まれた物理的なカードです。 プル生産方式により部品を移動したり、作ったりすることを指示するものであり、トヨタ生産方式(TPS)の一部として発明され、発展しました。ソフトウェア開発のかんばんについて述べる前に、ここでTPSにおけるかんばんの元の使い方をよく見てみましょう。

かんばんの目的は、上流プロセスが下流プロセスに必要な場合にだけ部品を生産することでプロセス間のWIP(Work-In-Process(進行中))、すなわち、在庫を最小化することです。「プル」とは、下流の作業員が上流プロセスから必要な部品を引き取ること、または、「引っ張る」ことです。

図1 かんばんとプル生産方式

図1は、かんばんシステムの抽象的なモデルです。図1で示されているのは、上流と下流の2つのプロセスであり、上流プロセスが下流プロセスに部品を供給しています。最終的な顧客に製品を供給するために、プロセスは部品を生産し、その部品を下流に流し込まなければなりません。しかし、多すぎてはいけません。過剰生産は最悪のムダだと考えられます。そこで、過剰生産を防ぐため、上流が完成した部品を下流に押し出す(プッシュ)のでなく、その代わりに、下流が上流から自発的に部品を取ってきます(プル)。部品が置かれる場所は、「ストア」と呼ばれます。(または、「スーパーマーケット」3 - 大野耐一氏 がアメリカのスーパーマーケットに行った時にかんばんの最初の考えを手に入れました。そこでは、店の人ではなく顧客自身が店の中で必要なものを取りに行きます。) ストアは上流に置かれ、WIPの「バッファ」や「キュー」として機能します。「運搬係」と呼ばれる下流プロセスの作業員がストアに来て、新しく完成した部品を拾い上げると、同時に次の製造を指示します。すなわち、下流は上流からものを引っ張ると同時に、かんばんカードを通して上流に情報を押し出します。これが必要なのは、上流プロセスが下流プロセスからの指示がなければ、決して部品を製造しないからです。

図1では2種類のかんばんが補完しながら動いています。

  • Withdraw Kanban (引き取りかんばん) - 運搬係がストアに持って行く購入リストにある部品
  • Production Kanban (仕掛りかんばん) - 下流プロセスのために部品を生産するように上流プロセスに指示する

図1で示すように、Withdraw Kanbanはプロセス間を循環します。一方、Production Kanbanはプロセス内で循環し、ストアで交換されます。この仕組みについてもう少し見てみましょう。図2は、「かんばんの交換」がストアにおいてどのような役割を果たすのかを示します。

図 2 ストアにおけるかんばんの交換

  1. 下流にいる運搬係は、部品を取り出す合図を受けます。ここで合図が下流プロセスで定義され、以下の2つのうちのいずれかになります。(a) 集められた引き取りかんばんの量によって合図される。
    (b) 周期的に合図される。
    運搬係は、購入リストとして集めた引き取りかんばんと空っぽの荷台を持って上流を訪れます。引き取りかんばんは、下流プロセスで必要なものと量を示します。
  2. 上流プロセスにおいて完成した部品は、荷台に積み込まれ、仕掛りかんばんと共にストアに置かれます。(これは、独立したスレッドの中で(1)とは別に起こります。)
  3. 運搬係は、引き取りかんばん(購入リスト)で指定された部品を取り出し、部品に付いている仕掛りかんばんと合うかどうか確認して、2つのかんばんを交換します。
  4. 運搬係は、仕掛りかんばんを「Production Board」(仕掛りボード)に置きます。かんばんが入口に積み上げられると、上流で生産を始めるきっかけになります。
  5. 運搬係は、ストアから下流の場所まで、取り付けられている引き取りかんばんと共に必要な部品を運びます。

ストアは2つのプロセス間のキューです。ストアは、別々のスレッドによる制御の中で動き、かんばんを通してものと情報を交換します。かんばんカードの表に、部品番号/名前、量、荷台の種類、ストアの住所などの情報が書かれているので、このカードを手にした運搬係は何をすべきかが分かります。

「かんばんの6原則」と呼ばれるかんばんを運用するための厳しい規律があります。

  1. 顧客(下流) プロセスは、かんばんで指定された正確な量の部品を引き取ります。
  2. 供給者(上流) は、かんばんで指定された正確な量の部品を順番に従い生産します。
  3. かんばんを持たずに生産されたり、移動されたりする部品はありません。
  4. かんばんと各部品は毎回同時に動きます。
  5. 欠陥品や量が違うものは、けっして次の下流プロセスに持ち込まれません。
  6. 在庫を少なくして問題を明らかにするために、かんばんの数は注意して減らします。

私たちが見てきたように、ストアは部品のキューとして働き、荷台は部品を運搬するものになります。そして、かんばんカードは、顧客の必要なものを示す情報を運ぶものです。これらによって「継続的流れ」を維持する(待つムダをなくす)ことと、「WIPを最小化する」(過剰生産のムダをなくす)ことの間のバランスをとり、プル生産方式になるのです。買いと売りの間の流れの中で「正しい」量のWIPを管理するこの仕組みは、まさにスーパーマーケットで起きていることであり、ストアの収益率にとってWIPをうまく管理することが重要な点だと言えます。

ここまで製造業におけるかんばんの使われ方について説明してきました。この説明は、実際のかんばんシステムを簡略化したモデルであることに注意してください。ここでは明確に述べられていませんが、かんばんは各作業員の目に見えるように情報の流れを示し、Gemba 5 (現場)におけるKaizen 4 (プロセスの改善)を促すことです。KaizenはGembaの出来事を見ることから始めます。かんばんを通して、マネージャではなく各作業員が流れを見ることができ、流れの中のムダに気付く機会があります。そして、自分たちの働いているプロセスに改善を提案します。

かんばんのプロパティ

前のセクションで詳しく見てきたように、ここにTPSの最初のかんばんの概念に関するプロパティとその効果を一覧してみます。

  1. Physical (物理的): かんばんは物理的なカードです。手に持ったり、移動したり、何かに入れたり、壁に貼ったりできます。
  2. Limits WIP (WIP制限): WIP (進行中)を制限します。言い換えれば、過剰生産を防ぎます。
  3. Continuous Flow (継続的な流れ): ストアの在庫がなくなる前に、生産が必要なことを通知します。
  4. Pull (引き出す): 下流プロセスは上流プロセスから部品を引き出します。
  5. Self-Directing (自己決定): 何をするかという情報を持ち、非集中化された方法でミクロの管理を必要とせずに生産を自律させます。
  6. Visual (見える化): 視覚的に現在の状況を示すように積み上げられたり、貼られたりします。
  7. Signal (信号): 状態が目に見えることで、次の引き取りや生産の動きに合図を送ります。
  8. Kaizen (改善): プロセスフローの見える化により改善の必要性が分かります。
  9. Attached (取り付ける): 供給される物理的な部品に取り付けられて移動します。

図3は、上記9つのプロパティの結果を示す図です。これらのプロパティがどのような原因-結果グラフになるかを示します。ここで分かるように、かんばんには大まかに2つの異なる意味があります。1つは「継続的な流れが持続しながらもWIPを制限すること」です。もう一つは「Kaizen」です。

図3 かんばんのプロパティと効果

このグラフの右側は、継続的な流れが持続しながらもWIPをどのように最小化するかを説明します。ストアのWIPが少なすぎる場合、下流プロセスは必要なときに部品が準備されていないため、待たなければなりません。しかし、同時にWIPは過剰生産を防ぐために最小化されるべきです。これら2つの目的は矛盾しているため、かんばんはこのジレンマを解決する戦略として見ることができます。

かんばんは、物理的に部品に取り付けられて、回収、再利用されます。そのため、かんばんの数は一定です。そして、必要な時にだけ部品を引き出すように、かんばんは目に見えるように下流プロセスへ合図を送ります。これらの2つの仕組みによってWIPを制限します。

最初の仕組みである「物理的に取り付けられたかんばん」は、「エネルギー保存則」のように働きます。市場における製造販売の状況に比例し、現在のプロセスに内在する変動率に基づいてかんばんの数が決められると、WIPは部品の出入りにかかわらず、かんばんの数に応じて制限されます。かんばんの最大数(システムの中の「エネルギー」)は決められていて、いつでもWIPの上限を物理的に維持します。図4では、「System」(システム)が上流プロセスと下流プロセス間の在庫、すなわち「ストア」のWIPであることが分かります。

図4 WIPを制限するかんばんの仕組み

2番目の仕組み「プル方式」もまた、生産の速度を下流の消費速度に依存させることによって、WIPを制限します。最初の仕組みはWIPの量を参照するだけですが、この2番目は流れ、方向、そして、スピードにも注目します。

「方向」- 生産を誘導するのは下流プロセスだけです。
「スピード」- かんばんが次の生産のタイミングとその量を伝えます。
「プル方式」は、1次微分として、上流プロセスの生産を下流プロセスの消費に依存させることによってWIPを制限します。下流プロセスから上流プロセスへ生産をコントロールする情報を押し出しながら、ストアで行われるかんばんの交換によって、この依存関係は達成されます。

図3のグラフの左側は、かんばんによって、どのように作業が自己決定化され、改善が進められるかを示します。ボードに貼られたかんばんカードを見ることで、何が起きているのか、そして、プロセスがどのようにうまく流れているかを誰でも理解できます。現場のワークフローを見ることが改善の始まりです。物理的なかんばんカードを目に見えるようにボードに貼ることで、管理を中央で制御しなくても自律的に作業できます。この自律的なプロセスによって、改善を支援する動作に関してデータを与え、管理側の注意を詳細な作業の割り当てや指示から改善活動に向けます。

グラフの矢印が示すように、最後には3つの結果が得られます。かんばんの最終的な目的は、「WIPの制限」、「継続的な流れ」、「改善」によって表せます。かんばんシステムは、「継続的な流れ」を持続させながら「WIPを制限」します。このことにより、改善案を示しながら、共通要因による変動をバッファリングし、特殊要因による変動を明らかにします。

ソフトウェア開発におけるかんばん

それでは、自分たちの仕事場、ソフトウェア開発を見てみましょう。プロジェクトの部屋の壁にカードを貼ってプロジェクトの状態を見える化して共有することは、アジャイルソフトウェア開発でよく行われるプラクティスになっています。前回のInfoQの記事、かんばんボードによるプロジェクトの見える化 [Hiranabe07]では数多くの例を挙げています。実際に、壁に貼られた現在の状態を示すタスクカードは、「タスクかんばん」や「ソフトウェアかんばん」と呼ばれることがあります。[Poppendieck03]. 図5は、株式会社チェンジビジョンのastah6開発チームが作ったタスクかんばんの例です。

図5 アジャイルかんばん

ボードでは、開発タスクはカード(付箋紙)で表されます。ボードには「ToDo」、「Doing」、「Done」と書かれた別々のエリアがあり、それぞれのエリアにカードを貼って状態を示します。これらのタイトルは、場所によって違うかもしれません。例えば、「In Progress」「Tested」、「Accepted」、「Blocking」などがあります。このかんばんボードは、視覚的にタスクを表現し、現在取り掛っているタスクであるWIPを制限する役に立ちます。しかし、ここでは上流や下流の「プロセス」は見つけられず、新しい概念である「イテレーション」が現れました。各イテレーションで、ユーザストーリーをタスクに細分化することでタスクは新しく決められます。そして、これらのタスクはToDoのエリアに貼られます。

これはプル方式でしょうか? 製造業において、部品は上流プロセスから下流プロセスへと渡されます。図5に示されているアジャイル開発の見える化では、「渡されるもの」(ハンドオフ)は目に見えません。1つのかんばんカードが1つのタスクに相当し、カードに書かれている情報は、タスクID、タスク名、見積もり時間、タスクにサインアップした人の名前などです。タスクは「ToDo」、「Doing」、「Done」といった状態を持ち、チームで共有されています。アジャイル開発アプローチでは、一緒に作業することを重要視し、チーム内でハンドオフを減らす傾向があります。これをここでは「アジャイルかんばん」と呼びます。

図6は、ヤマハモーターソリューション株式会社7で使われたかんばんボードの例です。

図6 持続的かんばん

ここでは、かんばんシステムが流れと共にウォーターフォール開発モデルで使われています。このプロジェクトは「設計」、「開発」、「検証」に分かれて、順番に実施されるプロセスがあり、かんばんカードはプロセス間を移動します。各カードはシステムの変更や追加の要求を表し、下流プロセスに渡されます。これは昔からあるウォーターフォールのプロセスではないことに注目してください。ウォーターフォールのプロセスでは、すべての要求が一度に「設計」され、「開発」と「検証」は別の機会に行われます。そのため、すべてのカードはまとまって移動します。ここではそうではなく、製造業で部品が1つずつ流れるように、カードは1つずつ移動します。ここで起きているのは、製品のライフサイクルの中の安定した「保守」段階であり、この段階は、流れのあるウォーターフォールの状態推移のモデルの中で管理されます。ここでは、アジャイルの「イテレーション」の概念とは違い、はっきりと「作業の流れ」の概念が見られます。これは、アジャイルのかんばんよりも工場のかんばんに似ています。下流プロセスだけがカードを動かせる8というルールを作ることでプル方式にもなります。私はこれを「持続的かんばん」と呼びます。このかんばんは、後半のセクションで述べるDavid Anderson氏の「Kanban System for Sustaining Engineering」(持続的エンジニアリングのためのかんばんシステム)と同じものです。

別の例を挙げると、図7は、製品開発プロセス全体の価値流(バリューストリーム)の中でかんばんの使い方を示す思考実験です。[Poppendieck 07]

図7 リーン+ アジャイル かんばん

1つの製品開発の流れの中に、顧客チーム、プロダクトオーナー、開発チーム、QAチームがあると仮定し、キューを使って出来たものを渡しながら一緒に作業しています。そのため、チームはお互いに依存して作業スピードを維持しながら、独立して作業できます。「DONE」のエリアは、製造工場で「ストア」のような働きをするキューであり、まるでTPSのかんばんシステムのようです。偶然にも、各プロセスで同時にアジャイルかんばんを使い、プロセスのバリューストリーム全体で非同期に持続的かんばんを使っているようにも見えます。私は、かんばんシステムはバリューストリーム全体をカバーするようにスケールできると思います。この場合、かんばんシステムはバリューストリームのライブな見える化になるでしょう。

この例では、各エリアの大きさを定義することでWIPを制限できます。これをプル方式にするには、上流プロセスが動き出すように、下流プロセスから上流プロセスへどうにかして合図できる仕組みが必要です。上流に合図するために下流だけがDONEカードを動かせるというルールを決める方法があります。定期的に「イテレーションミーティング」を実施するという方法もあります。この方法では、チームとチーム間の情報の運搬(伝達)を同期させます。伝達に関するこれら2つの方法は、セクション1で議論された部品を引き出す2つの合図に対応しています。すなわち、2つの合図とは、引き出しかんばんの量によって出される視覚的な合図(a)と定期的な時間間隔(b)です。ここでは、1イテレーションのユーザストーリーは、イテレーション中にパレットに引き出される部品に相当し、部品の数(かんばん)は、そのイテレーションのプロジェクトの「ベロシティ」(昨日の天気[Beck00])に相当します。これを「リーン+アジャイルかんばん」と呼び、次の例で示すように、「アジャイルかんばん」と組み合わせられます。

図8は、私がセントラルコンピュータサービス株式会社で見つけた小さな「ポータブル」かんばんシステムです。このプロジェクトでは、1つのチームがいくつかの小さなサブチームで作業します(通常は、ペアになります)。チーム全体は、図7と概念的には同じワークフローを持ちます。これは、図8のアジャイルかんばんボード(ToDo/Doing/DONE)を小さくしたものと同じです。サブチームが1つのユーザストーリーを取り上げて、タスクに分割し、ポータブルかんばんボードにタスクを貼り付けます。この場合、かんばんシステムは、2つのレベルで出来ています。1つのカードが1つのユーザストーリーを表すプロジェクトレベルと、1つのカードが1つのタスクを表すチーム、または、ペアのレベルです。

この会社では、この持ち運び可能な小さなかんばんシステムをとても気に入って、「かんばんナノ」と名付けました。

図8 ポータブルアジャイルかんばん(「かんばんナノ」)

ご覧の通り、かんばんの概念をソフトウェア開発に適用する様々な方法があります。「アジャイルかんばん」は、チーム内で情報を共有し、作業を自己決定させるように作用しますが、フローはサポートしません。「持続的かんばん」はもう1つの種類であり、複数の状態の間でちょっとしたバッチを使ったメンテナンス作業を可能にします。これらの組み合わせは、バリューストリームを通して「持続的かんばん」を使い、下位の流れの中で「アジャイルかんばん」を使う「リーン+アジャイルかんばん」です。

今日のアジャイルプロジェクトでよく見られる図5の最初の「アジャイルかんばん」は、バリューストリームの中でサブチームだけを見ることに注目してください。顧客に始まり顧客に終わるバリューストリーム全体について考える場合、通常は同じ流れの中に要求を出すチームか、顧客に成果を納品する別のチームがあります。この記事の目的の1つは、「アジャイルかんばん」を超えてかんばんの適用をバリューストリームの中のもっと多くのかんばんに拡張するために、アイデアを与えることです。

生産と開発

ソフトウェア開発は生産や製造の活動ではありません。[Reves92] 製造では何度も何度も同じものを作り出すのに対して、ソフトウェアエンジニアたちは毎回異なったものを作り出します。そのため、生産と開発を直接結びつけるのは危険です。しかしながら、TPSかんばんの性質がソフトウェア開発のかんばんという異なる種類の中でどのように見えるのか調べてみましょう。表1は、セクション1で見られるかんばんの特徴が、私たちが述べてきた2つの種類のソフトウェアかんばんの中でも当てはまることを示しています。

「WIPの制限」、「継続的流れ」、「プル方式」の特徴は、図5に示されたアジャイルかんばんの例自体では実現していません。アジャイルかんばんは、タスクが「視覚的に」「自己決定」できることに注目します。そうすれば、チームは自律的になり、自分たちのプロセスを改善できる手助けとなります。WIPを制限しながらプロセスを継続的に流れるようにするために、「イテレーションミーティング」によって情報を伝達する必要があります。

図6の「持続的かんばん」は、イテレーションミーティングを実施しなくても、WIPを制限し、「上下続き」の「プル方式」で流れを制御できます。このアプローチでは、同時に「WIPの制限」、「継続的流れ」、「プル方式」に注目します。そうすることで、チームやマネージャは、かんばんをプロセス改善のために使えます。

図3に戻って、図9にかんばんの特徴とその効果を2つの注目する分野に分類しました。上記2つのソフトウェアかんばんの概念はこれらの目的に合います。そして、図10は、生産と開発の範囲を示します。生産は、99%以上の成功確率を持つプロセスです。開発は、もっと成功する確率が低いものです。アジャイルは、最適化された開発アプローチであり、成功の確率は50%です。ウォーターフォールでは、成功する確率が90%以上だと最適だと言えます。Shannon情報の理論をあてはめると、成功する確率が50%のプロジェクトが、もっとも価値のあるプロジェクトです。一般的に、開発が持続的なメンテナンスの段階になると、不具合の修正と新機能の追加の成功確率は上がります。

かんばんシステムの「プロセス制御に注目すること」は90%以上の成功率であり、「プロセス改善に注目すること」は、90%の分野と同様、50%の分野にも合います。

アジャイルアプローチは製品の持続状態の中でうまくいき、かんばんの「プロセス改善に注目する」という特徴は持続的なモードでもうまくいくことに注意してください。

図9 かんばんの特徴とその効果(2)

図10 かんばんを利用したアプローチの範囲

KSSE - 持続的エンジニアリングのためのかんばんシステム

ここで、最近見られるようになったソフトウェア開発へのリーンの適用について紹介します。Agile2007カンファレンスで、David Anderson氏によるソフトウェアかんばんに関するCWAC (カンファレンスの中のカンファレンス)セッションに参加しました。Anderson氏は、Corbis.comで保守でのかんばんシステムを管理し、関連する記事、Kanban System for Sustaining Engineering (持続的エンジニアリングのためのかんばんシステム)[Anderson 07]を発表しました。Anderson氏が最初に注目したのは、抽象的に表された図4にあるようにかんばんの特徴である「WIPの制限」です。チームを自己組織化して、トップダウンの管理をより少なくする「自己決定」も同様です。それから、かんばんを通して流れを視覚化することで、プロセスの流れ全体の中で流れが止まる場所を見つけました。そして、プロセス間のメンバを動かして、人的資源を調整しました。つまり、Anderson氏は「図3」で示す通り、「WIPの制限」の特徴と「自己決定」からかんばんの「改善」の特徴までカバーしています。

カンファレンスの後、Anderson氏はkanbandevメーリングリスト2を始めました。そこでは、「KSSE」と呼ばれるソフトウェア開発へのかんばんの導入に関して新生の知識を創造する議論が行われました。「KSSE」とは、Kanban System for Sustaining Engineeringのことで、キスイーと発音します;-) Aaron Sanders氏もまた、かんばんに関する知識の構築に参加し、KSSE用語集を作り始めました。

プロセス間でキューに手渡すもの(ハンドオフ)があり、連続する複数のプロセスがある場合、KSSEはうまくいきます。KSSEは「イテレーション」の概念が必ずしも必要ではないことに注意してください。KSSEのアプローチを使うことで「スクラムのスクラム」よりも、別の方法でアジャイルを大規模にスケールできる可能性があると思います。 [Ladas07]

価値を流れさせる

かんばんを使ってアジャイルをリーンにスケールさせる場合、1つのかんばんカードは何を表すでしょうか?

アジャイルかんばんシステムでは、1つのカードは「ユーザストーリー」を細かくした1つの「タスク」です。開発チームにおいて、このカードは作業のまとまりとして機能し、チーム内の誰でもカードが意味するものを理解できます。しかし、1つのバリューストリームの中で複数のプロセス(チーム)を通して使われるかんばんシステムでは、流れているものは顧客が認識する価値であるべきです。この場合、1つのかんばんカードは「作業」に関連するのではなく、「機能」に関連します。これは、WBS(作業分割構成)の断片ではなく、FBS(機能分割構成)の断片であり、この流れの中にいる人は誰でも、顧客であっても流れているものの意味とその価値を理解できるべきです。Jim Highsmith氏もまた、アジャイルプロジェクト管理の本[Highsmith04]の中で述べた原則において、WBSよりもFBSを支持していました。

「ユーザストーリー」、「バックログアイテム」、「ユースケース」は、抽象的に「MMF」(minimum marketable feature (顧客が価値を得られる最小単位))と呼ばれ、流れるものが顧客の価値であることを明示的に示しています。そこで、リーン開発は「バリューストリーム全体を通してMMFの流れを速くする」ものと解釈できます。

図5の例の「アジャイルかんばん」は作業を細分化したもので、チーム内でうまく機能します。図6の例の「持続的かんばん」は機能を細分化したもので、1つのカードが1つのMMFを表します。そして、図8と一緒に使われた図7の例の「リーン+アジャイルかんばん」は、上流レベルの機能の分割と下流レベルの作業の分割の組み合わせを示します。

一度作業の流れが構築されると、「リーン思考」の5つの中心概念[Womack1996]をプロセス全体に直接当てはめることができます。リーンプロセスの管理は、以下の原則に従うだけです。

  • 顧客の目で価値を明らかにする - MMFを明らかにして、分類する。
  • バリューストリームを確認し、ムダを減らす - 止まっているタスクを見つける。
  • 顧客が引き出すことで価値を流れさせる - かんばんのプル方式のルールを作る。
  • 従業員を巻き込み、権限を与える - 現場のチームに権限を与える。
  • 完璧さを求めて継続的に改善する - ふりかえりと改善。

TPSの全体像

以下は、トヨタ生産システム(TPS)についての追記です。私がTPSから学び、ソフトウェア開発に適用できると気付いたことがありますので、ここで共有しましょう。Mary Poppendieck氏とTom Poppendieck氏は、効果的なソフトウェア開発では、リーンやTPSと共通することが沢山あると感じていました。これは、実践的なレベルではなく、原則に基づくレベルです。[Poppendieck03, 07] そこで、一歩下がって、高い視点からTPSのかんばんを見てみましょう。

かんばんがTPSの中心だと仮定するのは簡単ですが、そうではありません。図11は、TPSの概念構造を示します。これは、「TPSの家」とも呼ばれます。TPSの概念構造は何種類もあり、図11は、成沢俊子氏とJohn Shook 氏の考えに基づいています。TPSにおいて、かんばんはジャスト・イン・タイム(Just-In-Time) 9を実現する「プル方式」のためのただの装置です。ジャスト・イン・タイムは、「必要なものを、必要な時に、必要なだけ作って納品すること」だと言い換えられます。そして、「できるだけ早く最低価格で最高品質の製品」をほしいという顧客の要望に応えることを目的とします。「ジャスト・イン・タイム」はTPSの2つの柱のうちの1つであることに注目してください。もう1つは、自働化 10です。「自働化」、または、「オートノメーション」は、ソフトウェア開発ではテスト駆動開発に翻訳される生産方法です。Mary Poppendieck氏とTom Poppendieck氏は、「ラインを止める文化」として自働化を解釈しました。トヨタ工場の作業員たちは、次の下流へ欠陥を送り込むよりも、実際にラインを止めます。これは、ルールであるだけでなく、豊田佐吉氏の機織りに由来するトヨタの文化だと言えます。

図11 TPS の概念構造

ジャスト・イン・タイムは3つの要素から成ります。 「タクトタイム」、「継続的流れ」、「プル方式」です。

  1. タクトタイムは 売上率に基づいて、生産率を決定する。
  2. 継続的流れは、 タクトタイムに合わせて止まらないように、1つのプロセス内で部品を生産する。
  3. プル方式は、在庫量を制限しながらプロセス間の部品を移動して、生産の指示を与える。

また、2つの柱が「改善」と「人間性尊重」を基礎にしていることに注目してください。トヨタは、1年に約1千万台の自動車を生産し、同時に、作業場などの現場において約百万の改善提案によって、プロセスを改善します。チームがしていることを見える化することは、いつでも改善の開始点になります。

結論

生産におけるかんばんの運用を分析し、その特性の概略を述べてきました。かんばんシステムは、以下のことを達成するために使われます。

  1. よりよいプロセス制御 - WIPを制限しながら継続的流れを維持する。
  2. よりよいプロセス改善 - 流れを見える化し、改善の刺激となる。

「持続的かんばん」はNo1に注目しますが、私が言う「アジャイルかんばん」はNo2に注目します。企業活動全体に渡ってリーン活動を推進するには、見える化と「プル方式」をバリューストリーム全体へと拡張するために、これら2つを組み合わせることを提案します。

 

謝辞

Tom Poppendieck氏に、MaryPoppendieck氏と共にこの記事全体をレビューしていただきました。特に、沢山の考察と提案をくださったことに感謝します。佐藤竜一氏と株式会社ヤマハモーターソリューション社長の寺井康晴氏には、かんばんシステムの写真を使う許可をいただきました。David Anderson氏には、この記事のレビューと、かんばんのより抽象的なレベルをKSSEに進めるように提案していただきました。Kanbandev Yahooグループの議論は、KSSEという新しく生まれたアイデアの元になりました。そして、私の意図をよりクリアに編集していただいたDeborah Hartmann氏に感謝します。

著者について

平鍋健児氏は、日本の株式会社チェンジビジョンのCEOです。また、ERD、DFD、マインドマップと統合したUMLエディタであるastahの作成者です。そして、「リーンソフトウェア開発」、「XPエクストリーム・プログラミング導入編 ― XP実践の手引き」、「アジャイルプロジェクトマネジメント 最高のチームづくりと革新的な製品の法則」、その他XP/アジャイル関連の本を翻訳しました。平鍋氏は、ソフトウェア開発をコミュニケーションのゲームの形だと考え、さらに生産的、協調的、そして、おもしろくするよりよい方法を試しています。

参照

TPS

  • [Ohno78] 大野耐一、「トヨタ生産方式」、1978 (英語版:「Toyota Production System」, 1988). TPSのバイブル。リーン実践者にとってなくてはならない本。
  • [Narusawa06] 成沢 俊子, John Shook、「英語でkaizen! トヨタ生産方式」、 2007(日本語版と英語版). 最近、TPSに関して英語版と日本語版が同時に出版された。
  • [Ishii05] 石井正光、「トヨタの元工場責任者が教える入門トヨタ生産方式」、2005. TPS概念構造の1つのバージョンを含む。
  • [Monden06] 門田 安弘, 「トヨタプロダクションシステム」、2006(英語版: 「Toyota Production System 3rd」, 1998). TPS実施のバイブル。私は、この本からセクション1のかんばんに関する議論を学んだ。

アジャイルとリーンのメインストリーム

  • [Reeves92] Jack W. Reeves、「What is Software Design?」 C++ Journal、1992. ソフトウェア設計に関して私が好きな記事。
  • [Kent00] Kent Beck、Martin Fowler、「Planning Extreme Programming」、2000、 Addison-Wesley. リリースとイテレーションの計画について。昨日の天気とプロジェクトベロシティに関して、この本で最初に詳しく説明された。
  • [Poppendieck03] Mary & Tom Poppendieck、「Lean Software Development」、 2003、Addison-Wesley. TPSとソフトウェア開発を結びつけた最初の書物。
  • [Highsmith04] Jim Highsmith、「Agile Project Management」、2004、Addison-Wesley. 機能分割構造がAPMの実践として紹介された。
  • [Poppendieck07] Mary & Tom Poppendieck、「Implementing Lean Software Development」、2006、Addison-Wesley. リーンのかんばんについて、また、かんばんがプル方式のプロセスの仕組みの中でどのように働くかを説明する。
  • [Cockburn06] Alistair Cockburn、What engineering has in common with manufacturing and why it matters 2006. Alistair氏が、ソフトウェアエンジニアリングプロセスの中で有効になっていない決定をWIPとして見ることに関して議論する。

最近出てきたかんばんの概念


1かんばんについてhttp://en.wikipedia.org/wiki/Kanban
2kanbandevについてhttp://finance.groups.yahoo.com/group/kanbandev
3大野耐一氏についてhttp://en.wikipedia.org/wiki/Taiichi_Ohno
4改善についてhttp://en.wikipedia.org/wiki/Kaizen
5現場についてhttp://en.wikipedia.org/wiki/Gemba
6astahは、UML、ERD、DFD、そして、マインドマップを統合した視覚的なソフトウェア設計ツールです。 もっと知りたい場合は、http://astah.change-vision.com/ をご覧ください。
7ヤマハモーターズは、ハードウェアの生産ラインがあり、ソフトウェアチームは、工場からリーン思考を学ぶ良い環境にいます。ヤマハモーターを訪問した時に、私は施設内で「アンドン」や工場の視覚的な管理システムと同時にプロジェクトの見える化のために沢山の「XFD」(エクストリームフィードバックデバイス)を見ました。
8興味深いことに、赤い部分のプロセスは中国でオフショア開発されています。
9ジャスト・イン・タイムについてhttp://www.toyota.co.jp/en/vision/production_system/just.html
10自働化についてhttp://www.toyota.co.jp/en/vision/production_system/jidoka.html
 

日本語版翻訳への追記(平鍋、2010/4/30)

本記事中で紹介した KSSE(Kanban System for Sustaining Engineering)は、その後"Kanban"(かんばん)というシンプルな名前で開発メソッドとして定着している。その場合、kanban(小文字の'k')はツールとしてのかんばんを、Kanban(大文字の'K')は方法論としてのかんばんを意味する。この周辺は、kanbandevメーリングリストにていまだに活発な議論が行われている。また、議論の中心となる人々は、Limited WIP Societyグループを作ってブログ等で啓蒙活動をしている。

また、中心人物である David Anderson は、Alan Shalloway らとともに、LSSC(Lean Software and Systems Consortium)を組織し、ソフトウェア開発のみならず、より広く、製品開発分野でのリーン界との交流をはじめた。

イベントとしては、2009 年5月にマイアミで、Lean & Kanban Conference 2009 MIAMI、2009年11月にロンドン、UK Lean and Kanban Conference 2009(平鍋も講演者として参加)、そして、2010年4月にアトランタで、Lean Software and Systems Conference 2010 ATLANTAをそれぞれ開催した。

時に、かんばんはスクラムの概念と対立するとみなされることもあるが、Henrik Kniberg らが InfoQ から、かんばんとスクラムの効果的な利用法についての小冊子を刊行した。日本語訳がこちらから取得できる。

日本では、アジャイルジャパン2010が開催され、上記LSSCの知識体系化を努める Alan Shalloway が、「アジャイルの現状と未来、次に来るもの~リーン・アジャイル開発への展望」と題して、基調講演を行っている。

さらに、アジャイルをスケールする方法として、スクラムが「スクラムのスクラム」というように木型にスケールするのに対して、リーン(かんばん)は川型にスケールするというブログを平鍋が発表している。

この記事に星をつける

おすすめ度
スタイル

BT