Klaus Leopold氏がGOTO Berlin 2015カンファレンスでの講演で，チームレベルのパフォーマンスの重視が多くの場合，局所的な部分最適化を引き起こし，結果としてチーム全体のアジリティが向上しない理由について，詳しく説明した。InfoQは氏にインタビューして，なぜアジャイルフレームワーク導入がアジリティ向上に結び付かないのか，コラボレーション向上にかんばんをどのように利用すればよいのか，チームがかんばんに期待できるメリットは何か，などを聞いた。
InfoQ: アジャイル手法で開発を行なうために，かんばんを採用しているチームの話をよく聞きますが，あなた自身が開発に参加したチームではかんばんをどのように使用していたのか，例を紹介して頂けますか？
Leopold: 私はかんばんを使って，さまざまな分野で仕事をしています。古典的なハードウェア開発からマーケティング，管理，人事部門や代理店まで，関わったことのない分野はほとんどありません。かんばんを人事採用に使っている企業やかんばんを開発プロセスで運用している自動車関連の企業，さらには複数の工場が関わった資源再利用のプロセスも知っています。ソフトウェア開発も当然その中のひとつですが，現時点では私の仕事の30%を占めるに過ぎません。どのような環境であってもそこでの仕事の状況を十分に理解した上で，その理解に基づいた改善策を実施することが，顧客満足を高めるために重要なのです。
InfoQ: かんばんの使用は，チームにとってどのようなメリットがあるのでしょうか？
Leopold: 最初は，ほとんどのチームが可視化を求めます。“状態の見える化”は，かんばんを始める目標として一番多いのではないでしょうか。ですが私は，可視化は目標ではないと思っています。可視化は，自分たちの作業システムを理解するという目的を達成するための手段なのです。それがかんばんを使うことによって達成できる，最大のメリットなのだと私は思います。 かんばんの根幹は，現在何が起きているかを理解し，それに基づいて適切な改善を実施することにあります。とても簡単なことに思えるかも知れませんが，実はそうではありません。知的労働は直感的ではないのです。いくつか例をあげてみましょう – ずっと作業を続けない方が仕事が速く終わる，依頼された仕事にすぐ取り掛かるとユーザに喜ばれる成果を得られない，作業の速さと仕事を速く終えることに関連性はない，速く仕事に取り掛かるほど完了は遅くなる，等々。これらは完全に直感に反しています。作業を改善するには，これらのような業務システムの側面を理解しなくてはなりません。重要なのは，あなたのビジネスやユーザのために最適化するには，どのレバーを引けばよいのかを知ることです。システムの期限遵守性を高めたいのであれば，市場投入の最適化を行なう場合とは違う行動を選択して，違うシステムを設計しなくてはなりません。
InfoQ: 複数のチームや数百人が関与する大規模組織の場合はどうでしょう？アジャイルフレームワークで作業を整理できるでしょうか，あるいは他の何かが必要ですか？
Leopold: アジャイル，リーン，あるいは他の流行のものであっても，フレームワークを“取り入れる(install)”という考え方はあまり支持できませんね。ひとつ明らかなのは，今日のビジネスの現実で生き残るためには，アジリティは極めて重要だということです。もうひとつ疑いの余地のないのは，メソッドやフレームワークを取り入れるだけでは，望み通りのアジリティを手にすることはできないということです。理由を説明しましょう。
アジリティとはどんな意味なのでしょう？私にとってアジリティとは，絶えず変化を続ける世界に企業が適応する，あるいはさらに，あるテーマにおいて指導的立場となって新境地を開くために必要な方向に一歩進む，という意味です。ここで最も重要な前提条件は，企業が常に変化し，改善することです。フレームワークを取り入れるのならば，その中心となる考え方はプラクティスの無差別なコピーです。継続的変化とアジリティは，しかしながら，プラクティスのコピーで達成できるようなものではありません。逆もまた真 - フレームワークは多くの場合，継続的改善の妨げになります。フレームワークを取り入れたことで，目標とする状態が達成できたように見えるからです – フレームワークが要求するように組織構造を変更し，新しい作業方法を学んだ従業員が新しいプロセスとプラクティスを実践する，という状態です。これで完了！いいえ，全然違います！本当の目標が継続的変化であれ，アジリティであれ，完了では決してありません。
InfoQ: 大規模組織でチームが共同作業する方法を理解し，コラボレーションを改善する方法を見つける上で，かんばんをどのように使えばよいのか，詳しく説明して頂けますか？
Leopold: 最も重要なのは，かんばんでは，例えばチームや部門といったような組織構造を重視しないことです。かんばんは企業のサービス，価値の創出を焦点に置き，それらを改善することを目標としています。ですから，最初の質問は，“ユーザのための価値をどうやったら作り出せるのか？”，というものになります。この問いに答えられたならば，次の質問に注目します – “それを必要とするのは誰か?” つまりこのアプローチは，企業内の100チームにかんばんを導入して，“これらのチームが共同作業するにはどうすればよいのか？”と問うのとは違うのです。最初はサービスか，あるいは価値の創出で始まります。複数のチームでサービスの価値を創造する必要があるのならば，その答はチームのレベルではなく，チーム間でかんばんを採用することです。これがかんばんの素晴らしい部分だと，私は信じています – かんばんのスケールアップには限度がないのです。つまり，３人編成のチームでも，数百人からなる組織でも，かんばんを使った改善が同じように可能だということです。必要なのは，本当のかんばんを行なうことだけなのです。
InfoQ: InfoQのアーティクル “can you scale kanban” では，かんばんを使って，デリバリサイクル全体の作業進行管理を行なった例が紹介されていますが，部分最適化を回避して全体最適化を行なう上で，かんばんが有効であった例はありますか？
Leopold: 私の考える部分最適化とは，システム全体が考慮されずに一部だけが最適化される，という意味です。わずか10人の従業員しかいない企業でもない限り，製品開発やサービスの実現にいくつかのチームが必要であると言っても間違いではないでしょう。例えば，ひとつの製品開発に複数のソフトウェア開発チームが必要な場合もあるでしょう。この集団において，もしチーム全体ではなく，サービスの各チームのみが“最適化”あるいはアジャイル化されたならば，– 多大なコストによってアジャイル化されたにも関わらず – 全体のパフォーマンスがまったく向上しないという結果になっても，驚くには値しません。ひとつの例を紹介しましょう – 私は以前，ソフトウェア開発チームにスクラムを導入した企業と仕事をしたことがあります。導入はとてもうまくいきました – スループットを向上し，製品のリードタイムを削減することに成功したのです。チームが開発を完了すると，彼らは仕事の領域を越えて，スタッフトレーニングチームの仕事に関与することを考えるようになりました。トレーニングチームは，店内でアプリケーションを使用する従業員の訓練がその業務だったのですが，開発チームのパフォーマンス向上に対して，そのペースに付いていくことができず，結果的にトレーニングの質が低下していたのです。ショップスタッフはそのソフトウェアを，購入プロセスのエンドユーザに助言するために使用していました。ところが，最新の製品やプロモーションについて適切なトレーニングをスタッフが受けていなかったために，ユーザに十分なサービスができず，ユーザからの苦情が増加し，結果的にはコストが大きく増えてしまったのです。開発チームは立派な成果をあげたのですが，エンドユーザが最終的に満足できなかったという意味で，この“アジャイル化”はまさに部分最適化でした。そこで私たちは，フライトレベル３のかんばんを導入して，プロダクトオーナからソフトウェア開発，ショップスタッフに至るまで，バリューチェーン全体の最適化を実施しました。その結果，すべての関係者が改善を共有することができました。エンドユーザに満足を提供するためには，これが必要だったのです。大切なのはアジャイルやチームなど組織構造の改善ではありません – 価値創造の改善です！
かんばんが理解され，正しく実行されれば，このような状況になることはありません。前の質問で説明したように，システム全体の中で孤立した個々の部分ではなく，企業のサービスと価値の創造が関心の中心になるからです。
ここでひとつ述べておきたいことがあります – かんばんを組織の一部で始めることは，もちろん可能だということです。システムが正しくモデル化されていれば，部分最適化はすぐに発見されて，潜在的な可能性を経済的に定量化することができます。この議論が出発点となって，最終的なスケールアップが論じられることは少なくありません – 経営的な根拠はとても重要なのです。