先日シカゴで開催されたLean Kanban Conference で，かんばん方式のパイオニアであるDavid J.Anderson氏と会話する機会がありました。そこで氏に，分かりやすく説明された「かんばんクイックスタートガイド」といったものがないものでしょうか，と尋ねてみました。氏はIT-AgileのArne Roock博士の話を聞くように勧めてくれました。博士はかんばん方式を紹介した30ページのブックレット "Stop Starting, Start Finishing" の著者で，カンファレンスではトラック "Scaling Kanban" の講師兼議長を務めています。ドイツでアジャイルのコンサルタントおよびトレーナとして活動する博士に話を聞きました。
InfoQ: 現在の書籍などでは，かんばん方式を思想的なものとして扱っているように思えます。かんばん方式がチームにとって適切なツールかどうかを評価するには，何から始めればよいのでしょう。かんばん方式の導入に必要なものは何でしょうか。
Roock博士: もっとも大切なのは，とにかく変化が必要なのだ，というメンバ全員の同意を得ることです。変化を望まないのならば，かんばん方式は向かないでしょう。かんばん方式は，何よりもまず変化のための手段だからです。プロジェクト管理手法や開発手法と混同されることも多々ありますが，まったく違います。変化を起こす方法なのです。ただしそのためには，前提条件がひとつあります。リーダシップの権威であるJohn Kotter氏が自身の著書の題名にもしている "切迫感 (a sense of urgency)" が必要なのです。
変化への同意ができたならば，次に大切なのはその方法です。具体的には２つの戦略があります。ひとつは革命的な方法です。すなわち，組織をひっくり返したり裏返ししたりといった，大規模な変化を起こすのです。大きな痛みは伴いますが，変化の後には以前よりもずっとよい状態になることを期待できる方法です。ただしこれは，かんばん方式のアプローチではありません。かんばん方式は漸進的変化のための手法なのです。
InfoQ: では，変化を受け入れる合意ができたとしましょう。私たちは正しい選択をしたいと思います。それが革新的な変化を伴うのならば，その心構えもします。その一方で，斬新的な変化で大きな改善が望めるのなら，できればそちらを選びたいとも思うでしょう。デリバリや予測可能性，透明性の改善といった観点で，結果を目にしたいのです。
Roock博士: 経験から言えば，かんばん方式を導入するまでは，大きな目標に対する同意が必要です。それはつまり，マネージメントの介入が必要だということです。
あるいは草の根的な "ステルス" アプローチで，マネージメントから隠れて，チーム内だけで事を進めようとする場合もあるでしょう。そのようなアプローチでもある程度は成功できるかも知れませんが，すぐに限界に突き当たってしまいます。企業規模での本当の成功を望むなら，マネージメントの介入は必要なのです。マネージメントと話して，彼らが何を達成しようとしているのか，苦労している部分は何か，到達したい目標は何か，といった点を理解することが重要です。
あなたの例で言えば，"予測可能性とデリバリを改善したい" といったところでしょう。それならば，まず最初にするべきなのは，エンド・ツー・エンドのフローの可視化の実現でしょう。知識労働の大きな問題は，仕事の成果を見たり触れたりできない，ということです。工場に行ってみてください。たくさんの材料や未完成品が現場のフロアにあるはずです。しかしオフィスはどこへ行っても全部同じように見えます。デスクがあって，キーボード，電話，コンピュータ，山積みの書類，といった具合です。オフィスでは仕事の成果が目に見えません。それが改善活動を難しくしているのです。
ですから，かんばん方式の導入で最初に行わなければならないのが，仕事を可視化することです。いくつのタスクが開始されていて，今どの段階なのか。開発すべき作業はどの程度あるのか，解析はどれだけか，テストはどうか，といったことです。
これは非常に洞察力を要する仕事です。ほとんどの人たちは，どれほど多くの仕事が進行中 (開始して，まだ終了していない)なのか，気付いていないものなのです。
次に必要なのはフィードバックループの構築です。作業フローとその内容を定期的に観察して，フローを改善するために何をしたいのか，意見をまとめておきましょう。
こうして作業の透明性が確保できてみると，テストの欄に作業が山積みになっていることが分かります。つまり私たちは，テストやデプロイに比べて開発作業の進捗が早いのです。そうとなれば一致団結して，作業フローをスムーズにする方法を検討するための改善ワークショップを開けばよいでしょう。
このボトルネックに対して，どんな対策が可能でしょうか？一番最初に思い付くのは，テスタを増員することかも知れません。しかし多くの場合，これは適切なソリューションにはなりません。おそらくはテスト段階で実施される作業品質の改善や自動化，あるいは開発者をテストに移行させる方がよい手段でしょう。開発者なら普通，テストを担当することは可能なはずです。
このように，まずは透過性が必要なのですが，フィードバックループも非常に重要です。かんばん方式を採用するチームの多くは，かんばんボードの前で，作業状況を確認しながらスタンドアップミーティングを行います。さらに改善ワークショップや，あるいは彼らの言う "レトロスペクティブ" ないし "改善(Kaizen)ミーティング" を実施しています。
次に必要なのは，自分たちの進んでいる方向が正しいかどうかを判断するための，いくつかの指標を用意することです。
目標が予測可能性の改善，あるいはデリバリの迅速化と頻度向上といったものであるなら，サイクルタイムを計測するのが適当でしょう。タスクを開始してから終了するまでの時間を計るのです。その次には作業者を１名，開発からテスト作業に移動させて，その結果を確認します。あるいは，作業を違った方法で分割してみたらどうでしょうか。さらにはポリシとして，同時に実行する項目を開発では２件，テストでは３件に制限すると決めたらどうなるでしょうか。
ここまで来れば，他にもいろいろと試してみたくなるかも知れません。フィードバックループと指標が手に入れば，実行したことが広く展開すべき成功策なのか，あるいは撤回すべき失敗策なのかを判断することができます。
InfoQ: 先程ボードの話が出ましたので，次はそれについて話を伺いたいと思います。ボードにはどの程度の単位で作業を書くべきなのでしょうか。最初から最後まで書くべきか，あるいは自分の開発ステップだけでよいのでしょうか。
Roock博士: コントロールの可能なバリューストリームから書き始めるのがよいでしょう。スポンサーが開発主体ならば，開発を開始点にするべきです。私たちのボードは分析タスクの詳細化から書き始められています。次が開発，テスト，それから製品管理などの上流工程や，デプロイメントのような下流工程とのインターフェースがあります。
将来的にはもちろん，この範囲を拡張していきたいと思っています。 ローカルに最適化するのではなく，部門の境界を越えたコラボレーションをしたいのです。しかしこれが管理外である場合，あるいは上流や下流工程のパートナがコラボレーションに同意してくれない場合には，これらをすべてボードに載せても意味がありません。これは非常に重要なことです。
コントロール可能な書き始めてください。かんばん方式を広めようなどとしないでください。それが目的ではないのです。大切なのはよりよい結果を達成できたかどうかであり，それを公開することです。そうすれば皆が好奇心を持ってくれるようになります。好奇心こそが最高に強力なツールなのです。いろいろな人がやってきては，あなたに質問するでしょう。"どうしたら，そんなにたくさんのデリバリが可能になるんだい？”あるいは "なんでそんなにバグが少ないんだ？”そうやってかんばん方式がチーム全体に広がるのを，私たちは何度も目にしてきました。
以前，Jimboという会社のプレゼンテーションを見たことがあります。Jimboではオンラインマーケッティングチーム，プレスチーム，ビデオチーム，パートナチームでかんばん方式を採用しています。かんばんボードは当然チームごとに違うのですが，小さなステップで継続的に改善する，という原則はすべて共通しています。
InfoQ: チームが地理的に分散している場合，どうやってボードを拡大すればよいのでしょう。
Roock博士: 難しい質問ですが，今日では多くのチームが分散していますから，非常に現実的な問題だと思います。市場には優秀なかんばん方式ツールがたくさん出回っていますが，電子ツールにはよい面と悪い面があります。私は可能な限り，物理的なボードを使用するようにしています。たとえロケーションが２つに分かれていても，物理的なかんばんボードを運用することは可能ですが，当然ながらチーム間で同期は取らなければなりません。Webカメラやインスタントメッセージ，あるいは各地域がそれぞれ相手の地域にバディを持っているなら，バディシステムを利用することもできるでしょう。
InfoQ: バディ(buddy，仲間)というのは，どういう意味なのですか。
Roock博士： すべてのチームが他の場所に常駐するバディを持つ，というシステムがバディシステムです。かんばんボードを更新する毎に，例えばチケットを開発からテストへ移動した場合など，バディに対してそちらのボードを更新するように連絡するのです。電話やビデオ会議，インスタントメッセージングなどを使って。オーバーヘッドが大きいように思えるかもしれません。事実そうなのですが，このようなコミュニケーションが実は大切なのです。実際にバディたちとコミュニケーションを始めてみると，単にチケットを移動させるだけではなく，例えば "来週休暇を取る予定だから，これとそれを他のチームメンバに伝えてくれないかな" といったことも伝え合うようになるはずです。あるいは "今コードのこの場所に取りかかっているみたいだけど，こことあそこは結構大変だから，ちょっとアドバイスさせてくれるかな" といったこともあるかも知れません。こうしてチームの境界を越えたコミュニケーションが生まれることが，本当に意味のあることなのです。
InfoQ: チームが２つより多い場合，あるいは例えばニューヨークとシンガポールのように，12時間などという大きな時差があった場合はどうでしょう。
Roock博士: ２つの地域なら大丈夫ですが３つは難しいでしょうね。うまく行っているのを見たことがありません。時差も確かに問題でしょう。コミュニケーションが非常に難しくなります。
ここで指摘しておきたいのですが，かんばんは意地の悪い姑のようなものでもあるのです。間違っていることは必ず指摘しますが，それが改善に役立つ訳ではありません。このようなケースでかんばん方式を適用すると，分散型チームの運用では非常に辛い思いをすることになります。チームの同期を図るために多くの労力が必要になるのです。しかしこれはかんばんであるか否かに関係のない現実なのです。かんばん方式が問題を浮き彫りにしたに過ぎません。２つより多いロケーションがあれば，電子ツールは必須です。 しかしそのためには，コミュニケーションのバンド幅もかなり必要になります。 このような状況は，これまで何度となく見てきました。 皆がツールだけを通じてコミュニケートするようになったら，そこから離れられなくなります！コミュニケーションはいつだって必要です。そしてEメールより電話，電話よりビデオ会議，ビデオ会議より直接対面した方が望ましいのも当然です。ですから，可能な限りコミュニケーションを行えるようにしてください。要するにそれは，メンバを折に触れて相手の場所へ行かせなければならない，例えそれがシンガポールであっても，ということなのです。それから，本当によいビデオ会議機器や，優秀なかんばんツールも必要です。組織を変えるために非常に重要なのは，信頼関係の構築です (かんばん方式は，まさしくそのために生まれたのです)。お互いに顔見知りであれば，信頼の構築はずっと簡単になります。人々が会って，お互いの顔を見ながら話し，ビールを飲み交わし，プライベートな生活についての多少の知識，子供がいるかとか，どんな映画が好きかとかをお互いに知ることで信頼関係を構築する，これが本当に，本当に大切なことなのです。
スタートアップミーティングは，このように定期的に集まって，お互いに言葉を交わすためのフォーラムを作るひとつの方法なのです。時間差があるのはもちろん問題ですが，それはかんばん方式とは関係なく，解決の必要な問題であるはずです。
InfoQ: 地域を越えたスタンドアップミーティングを運営する上で，標準的なソリューションというものは存在するのでしょうか。
Roock博士: 時差があるといっても，たいていは１，２時間は重なった時間がありますよね。
InfoQ: ですが，シンガポールとは12時間違います。彼らが遅くまで働いたとしても，毎日ミーティングをするのは難しいでしょう。
Roock博士: そうですね，１日の違う時間にいる訳ですから，可能だとしてもエネルギーのレベルが違います。難しい問題ですね。ですが，たとえ一部の人たちが夜に働かなくてはいけなくても，定期的にコミュニケーションを取る必要はあります。例えばラウンドロビンのメカニズムを使用して，他のチームのひとりと話すことはできるでしょう。
チーム間の壁を取り除くことも必要です。ひとつのチームが米国に，もうひとつがシンガポールにあったとき，米国のチームが "シンガポールのやつら，僕らのビルドを壊しやがった" とか，あるいはその逆であったり，というのはよくある話でます。ジョークで済むことも多いのですが，その裏には理由があるものです。何人かの代表者を数ヶ月間，相手の場所に送り込んで，次には彼らの代表者がこちらにくるようなことをすれば，関係構築の仕組みとしてはとても効果的だと思います。
InfoQ: それでは仮に，マネージメントの許諾を得られたとしましょう。リスクを軽減するためには，スモールスタートで始める方がよいでしょうか。
Roock博士: そうですね，それがかんばん方式の基本的な考え方です。手元にあるものから始めて，それから展開するのです。作業を視覚化するなら，今やっていることを視覚化してください。目標とする状態を視覚化しようとしてはいけません。
以前，Siemens Health Careでかんばん方式の実施責任者を務めるDaniel Vacanti氏のプレゼンテーションを見たのですが，彼らは違う方法を使っていました。企業全体にわたって大規模なかんばん方式のロールアウトを行ったのです。
ですが通常は小さな部分から始めて，それをウィルス的に，あるいはチームからチームへと拡大する方がよいでしょう。
かんばん方式には，現在の役割，プロセス，責任を尊重するという，重要な原則があります。先ほどお話した漸進的アプローチとも関係する，非常に大切なものです。
部門間のコラボレーションのない組織や，確固とした管理あるいは役職構造があるのならば，それらもすべて維持しなければなりません。現状を尊重してください。テストマネージャやアーキテクト，ビジネスマネージャがいるのなら，それらの役割を継続する必要があります。人々が責務や肩書，役割の変化を好まないことは，経験からも明らかです。彼らはプロとしての役割に誇りを持っているのです。もし私がこれまで12年間ビジネスアナリストを続けてきて，新しく導入されるプロセスにビジネスアナリストの役目がないとしたら，私は名刺の肩書の変更を余儀なくされるだけでなく，深く傷つくことでしょう。ですからかんばん方式の導入当初は，このようなことを行わないようにしてください。しかし私たちが行動を継続して，信頼を得られ始めたときならば，このような変化の導入を始めることも可能になるでしょう。
InfoQ: かんばんボードの列としては，どれくらいの単位が適当でしょうか。
Roock博士: ボードの列には，現時点での仕事のやり方を反映する必要があります。人々が話すのを聞いていれば，たいていは簡単に見つけられます。例えば "開発が終わったんだね。テストは始めたのかな？" という会話があれば，彼らの作業の進め方を反映して，開発とテストにそれぞれ１列を割り当てるのが適当でしょう。とにかく，ワークフローの現実をボードに描きたい訳ですから。
ただし単位が細かすぎて列が多すぎたり，レーンが多くなりすぎたりすると，ボードは分かりやすいものでなくなってしまいます。ここでは "３×３" というルールがあります。かんばんボードから３メートル離れて立って，３秒で３秒で何が起きているのか把握できる，というものです。すべてのカードを読むことはできなくても，作業が積み上がっている場所や，仕事のなくなっている場所は確認できるはずです。しかし列が多すぎたりレーンが多すぎたりすると，どこを見ているのか分からなくなってしまうでしょう。(編集注："列"はかんばんボードの垂直方向の列，"レーン" は水平方向の行を示す)。
InfoQ: "Work in Process" (WIP/仕掛品) についてお聞きしたいのですが，スクラムのプロセスでは，いくつかのストーリがありますね。私たちはそれを作業して，もし終了しなければ次のスプリントに持ち越します。ですが，私たちが注目するのは残り時間であって，自身のベロシティ(velocity)を当てはめたときに，あといくつのストーリをそこに取り込めるか判断します。そういう意味で言えば，WIPはすでにスクラムのコンセプトなのではないでしょうか。
Roock博士: そのとおりです。スクラムはスプリントの概念を持つことによって，WIPに制限を加えます。原則的には同じものなのですが，かんばん方式で私たちが行っていることとは違います。かんばん方式ではWIPは列，レーン，あるいは人単位で制限されるのです。秘訣は能力に対する需要のバランスを取ることにあります。自分たちの処理能力以上の作業は引き受けたくありませんから。
InfoQ: では仮に，プロジェクトで10人の開発者が作業しているとしましょう。 私のキャパシティは１，他の人たちも同じです。したがってWIPの限界値は10になります。誰かが何かで行き詰まれば，他のメンバはもうひとつ引き受けることになるでしょう。もし何か製造上の問題が起きれば，私はさらにひとつ 引き受けざるを得ません。
Roock博士: 今の質問には２つの内容が含まれていますね。説明しましょう。ひとつはかんばん方式で "催促(expedite)" と呼ばれる，生産性の問題です。早急に処理しなければ，高いコストを発生させることになるような場合，催促によってWIPの制限を越える必要が生じます。その場合には特有のポリシを適用することになるでしょう。例えばメンバをその問題に集結させて，チームとして即座に処理する，というようにです。問題が解決すれば，そのような作業が必要になった理由をチームとして反映する必要があります。そのような事態を減らすにはどうすればよいのか？これがかんばん方式のアプローチです。
あなたの質問にあった件のもうひとつは，ブロックされているが催促の対象ではない項目です。今，情報など何らかのものが必要なために，他のチームを待っているとしましょう。ここで別の項目を開始してWIP制限を越えることもできますし，あるいは発生した "余剰能力(slack capacity)" をシステムの改善に利用することも可能です。これがかんばん方式の基本的な考え方です。ＷＩＰ制限はこの余裕を作り出すための，非常に強力な方法です。この余剰能力を利用すれば，大きく深呼吸して周りを見渡し，何が起きているかを確認して，この余剰を取り除くにはどうすればよいかを検討することによって，根本原因を解決することができるのです。
例えば，もし同じような停滞が何度も起きるようならば，そこにもう一人増やすか，その場所の担当者をこちらに呼んで技術移転を行うなどの方法が取れるでしょう。かんばん方式では，このようなブロックをどう扱うかは決めていません。"WIP制限を利用して余剰時間を作り出すこと，人々の作業能力を100%使い切ってはならない" とだけ言っているのです。つまり，古典的なプロジェクト管理で行っているようなやり方です。私たちはいつも，作業能力をフルに活用してしまいます。その結果として，プロセス改善に使用すべき余剰能力を使い切ってしまうのです。
InfoQ: 私がある組織のプロジェクトマネージャでかんばん方式に疎く，それを試してみたいと思ったとしましょう。企業が私の練習のために，数千ドルの投資をしてくれることはあり得ません。かんばん方式を始めるために，最低限必要なものは何でしょう。
Roock博士: 私はこれまで，かんばん方式で大きな成功を収めた企業をいくつも見てきました。彼らは外部のコーチやトレーナがなくても，本やブログ記事を読んだり，メーリングリストを購読したりしていました。彼らは小さな企業でした。そこで見た経験から，実際の経験者が少なくともひとりいれば，成功の確率はずっと大きくなると言えます。経験者が社内にいれば最高ですが，そうでなければコンサルタントを利用するという手もあります。
通常，私たちはマネージメントワークショップから始めるのですが，そこで受ける質問は「なぜかんばん方式を行うのか？」「漸進的な変化の追求を認めるべきか？」「目標は何か？」といったものです。その次には，全員が同じ言葉で話せるようにチームを訓練します。列やスイムレーンとは何か，チケットの催促をどう扱うべきか，などといったことです。これが終われば，それをシステムに反映して改善できるように，定期的にチームを支援することになります。そうなれば，もう週５日フルタイムの仕事ではありません。当初は２日程度のパッケージから始めることも多いのですが，その後は組織内のコーチング経験構築に努めることで，時間的には少なくなります。ですからコーチング実施の全体量はそれほど多くなくても，成功の可能性を高めることができます。
InfoQ: コーチは組織内で，どれ位の時間を費やす必要があるのでしょうか。
Roock博士: 一般論で答えるのは難しいですね。共同で作業するチームの数によりますから。３つないし４つのチームと同時に作業するのであれば，フルタイムの仕事になるでしょう。でもコーチするチームがひとつだけなら，短時間のコーチングを頻繁に行うのが最善の方法でしょう。つまり６ヶ月おきに５日間の期間を取るより，１週間に１日の方が望ましい，ということです。
InfoQ: 最後に何かアドバイスはありますか。
Roock博士: ひとつ，重要なことがあります。私がかんばん方式で達成したいと思っているのは，私たちが行っていること，私たちの仕事を理解する，ということです。それがかんばん方式の基本的価値のひとつなのです。もしコンサルタントが会社にやってきて，あれとこれを行わなければいけない，と言うのであれば，恐らく彼は間違っています。優れた改革マネージャは企業のすべての人々，取り分けリーダに対して，作業の方法を理解するプロセスを促進します。それ以外の部分で改革を行うというのは，本当に難しいものだからです。ですから，教科書どおりにかんばん方式を適用するだけでなく，なぜWIP制限が必要か，透過性はなぜ重要か，などといいったことを理解するように努めてください。それが行えれば，成功のチャンスは十分にあります。
回答者について
Arne Roock博士 はIT-アジャイルにおけるリーンおよびかんばん方式のトレーナ兼コーチとして，ドイツで活動しています。博士が重視するのは，かんばん方式の使用を通じて，企業の改善(Kaizen)文化の確立を支援する，ということです。博士はさらに，リーン/かんばん方式に関するいくつかの論文や，書籍 "Kanban – Successful Evolutionary Change for Your Technology Business" のドイツ語訳などを執筆しています。博士はドイツ内で最初のLimited WIP Societyの創設者であるとともに，"Lean Kanban Central Europe" を主催し，その役員も務めています。それら功績に対して，Lean Systems SocietyからBrickell Key Award 2012を受賞しています。博士には Twitter，ブログ，あるいは Eメール を通じて連絡することができます。
コミュニティコメント