Mary Poppendieck氏がAgile Adria 2015カンファレンスで，アジャイルのスケーリングにまつわるジレンマをテーマとした基調講演を行った。複数のチームが一緒に仕事をするというのは，時には困難が伴うが，大規模で複雑な製品を開発し提供するために不可欠なことも多い。講演の中でPoppendieck氏は，アジャイルのスケールアップを望む組織にヒントを示してくれた。
InfoQはMary Poppendieck，Tom Poppendieck両氏にインタビューして，アジャイルチームにおける協力と自主性のバランス，複雑性に対処するために実験を行うこと，プロジェクト重視の考え方よりも製品重視の考え方によってよい結果が得られること，ビジネスへの影響に注目することなどを聞いた。
InfoQ: プレゼンテーションの中では，スケールアップにおいて解決を要する問題点として，協力，複雑さ，考え方，重点の４つが取り上げられていました。その中で，チームは協力と自主性をバランスする方法を模索している，という話がありましたが，なぜそれが難しいのか，詳しく説明して頂けますか？
Mary & Tom Poppendieck: Dan Pink氏の2009年の著書“Drive”の中には，人々を動機付けるものとして，３つのものが取り上げられています。自主性，習得，そして目的です。アジャイルムーブメントの中にいる人たちは“自主性(autonomy)”ということばを，文面通り，“外部のコントロールや影響からの自由と独立”という意味で受け取っています。興味深いことにアジャイルムーブメントでは，自主性を個人のレベルというよりも，小規模なチームのレベルのものだと理解しています。集団思考のようなバイアスが往々にして，チームにおける個人の自主性を阻害するにも関わらず，です。
多くの場において，小規模でクロスファンクショナルな開発チームは，完全に独立したものであるべきだ，とする考えが，ごく一般的なものになりました。これらのチームが大規模なチームの一部であって，その成功が小規模なチームの成功に不可欠なものである，という事実に対しては，あまり注意が払われていないのです。小規模かつ自主的なチームを重視する考え方は，権利の意識に転じることも少なくありません。そのため，より大きな目標達成のために協力を求められた場合，彼らは往々にして，自分たちの自主性が蔑ろにされたように感じてしまうのです。
事実として，人々やチームが協力するためには，お互いの要求に対処することが必要です。共通の目標の前では，自分自身の目標に専念することを諦めなくてはなりません。それぞれのチームが独立して，コードの一部分を担当することが – マイクロサービスのように – できれば，互いの折り合いをつける必要は少なくなります。しかし多くの領域では，ひとつのモジュールないしコンポーネントの開発にも，少なくない人数を必要とします。これらの人々が大きなひとつのチームとして – あるいは小さなグループが協同で – 作業しなければならず，自主性はその大グループにおいて認められるのです。
大規模な協同作業グループというのは，特に新しいアイデアという訳でもありません – 事実，30～50人のチームが集まって共同で作業するというのは，昔からごく普通に行われてきたことです。このような規模のグループを，進化生物学者は“ハンティング・グループ”と呼びます – ひとつの村を養えるほどの大きな獲物を狩るように，大きな目的を達成するには，大勢の人々が必要なのです。ノーベル賞を受賞したEleanor Ostrom氏は，森林や牧草地，灌漑用水，魚の群れといった，自然界の資源を効果的に利用する大規模グループの例を数多く記録しています。
残念なことにアジャイルソフトウェア開発では，7人程度の小チームの自主性を擁護するという，行き過ぎた状況が往々にして見られます。そこには，より高いレベルの目標を達成する上で，これら小チームが他チームのニーズにどう対応するかという，現実的な方法に関する議論が欠けています。ですから私たちには，小チームを基本とした自主性の議論から，共通の目標を持った適切な規模のグループによる協同作業へと，重心を変えていく必要があるのです。
30～150人のメンバという大きなグループで，効果的な協同作業は可能なのでしょうか？ いくつか例を挙げて頂けますか？
Mary & Tom Poppendieck: 新しい製品を市場に出して成功を収めるには，通常は7人では足りません。もっとたくさんの人たちが必要です。保険製品であろうと，スマートフォンアプリであろうと関係ありません。設計からの洞察，マーケティング，エンジニアリング，流通，サポート，金融，その他さまざまな領域での検討が，製品を成功させるために必要なのです。大成功を収めた最近の製品について，その背景を調べれば，30から50人強という人数のチームが存在しているはずです。
私たちは，デリバリチームは自立したチームであるという(間違った)考えを持っています。そうではありません – もっと大きなチームの一部なのです。ソフトウェア開発チームを，開発対象ごとの小さな“自立した”チームに分割してしまうと，製品全体に対する彼らの貢献範囲を制限してしまうことになります。優れた製品を開発するには，エンジニアリングチームは大きな議論の一部でなければならない，と私たちは考えています。その製品にはどのような機能が必要か，どのテクノロジを活用すべきか，市場にどうやってアピールするか，どのようなサポートが必要か，どのような改善方法がもっとも望ましいか，といった議論です。
Gore and Associatesでは，150人のチームも珍しくありません。チームそれぞれがビジネスユニット全体を備えていて，メンバの生活はそのビジネスの成功にかかっているのです。大ヒットアニメ映画を次々と製作しているPixerのチームは，およそ200人のメンバが3年間，共同で作業します。彼らが重視するのは，チームメイト(多くは他の分野の)たちが最高の仕事ができるように，いかに支援するか，ということなのです。
InfoQ: スケールアップに伴う複雑性への対処として，“突っつく(poke)”ことを提案されていましたが，これはどういったもので，どのような理由があるのかを教えてください。
Mary & Tom Poppendieck: ソフトウェア，特に製品や市場，ビジネスに結び付いたソフトウェアのスケールアップを考えるには，複雑性適応システム論(Complex Adaptive Systems Theory)が有効です。ソフトウェア集約型のビジネスシステムが，全体として複雑なシステムであることは間違いありません。この理論から私たちが学ぶことのできるのは，成功したシステムのリーダは，その状況に応じて，独立性(自己組織化)と一体感(相互依存性)とのバランスを常にとっている，ということです。自立と協調のバランスに関する最初の質問には，これが答になります。
時間の経過を生き残り，成長してきた複雑なシステムは，適応性を備えています。その適応性は，ある特別な方法で発揮されます。小さな試みの絶え間ない繰り返し - 大部分はうまくいきません - が，システムに責任を持つ人たちに対して，物事を行う上での，よりよい方法を教えてくれるのです。小さな試みが必要なのは，例え複雑なシステムが確定的なものであったとしても，入力条件の些細な変動が(蝶の羽ばたきのように)，システムの挙動に大きな変化を起こす可能性があるからです。
複雑なシステムを大きく変更すれば，効果があることは間違いありません – ですが，そこで何が起こるのかを事前に予想することは，事実上不可能です。システム内の絡み合った依存関係は，誰にも，どのチームにも理解できないからです。ですから，予測可能性と安全性を重視するのであれば，システムの安定性を維持するために，小さな事を試してみて結果を観察し，その後にそれらに対処する，というのが唯一の方法であることを理解すべきです。今日のシステムは予測可能である，十分に計画された変更が望ましい，などという考えが希望的観測に過ぎないことは，はるか昔に証明されています。私たちは複雑なシステムという戦争の中にいるのです。計画することに意義はあっても，計画は無意味であることを理解しなければなりません。
InfoQ: プロジェクトよりも製品を重視することが，よりよい結果を得るために望ましいという点について，詳しく説明して頂けますか？
Mary & Tom Poppendieck: プロジェクトの抱える問題は，まず第1に，それが仕事の山であることです。そして第2には，計画の遵守を目的としていることにあります。リーンソフトウェア開発の世界において，私たちは，コードを少しずつデプロイする方法が，大幅な品質向上のみならず，フロー効率の(延いては全体的効率の)向上にも大きく寄与する，という事実を学んでいます。
プロジェクトではいわゆる“デリバリチーム”が，十分に練られた計画の実行を期待されると同時に，その計画のさまざまな面を基準として評価されます。ですがこれには，その計画 - 情報が極めて限られていた時点で作られらもの - が，プロジェクトの広い意味での実行期間を通じて，絶えず有効であることが前提となります。状況からさらに学んだり，それに対応する必要がないということも，前提になっています。大規模なプロジェクトであれば，プロジェクトの将来的な部分に対して継続的な変更を行うことは可能ですが，基本的にプロジェクトは，計画が有効で，従うべきものであるという考えに基づいて実施されるものなのです。不確実な状況においては，これは誤った前提です。
製品が存在するのは，不確実な世界なのです – 経済的な不確実性，競争に関する不確実性，影響の不確実性。製品は構想され，実験された後，設計やプロダクト管理，マーケティング，エンジニアリング，サポート，オペレーションといった，さまざまなチームによって処理されます。これらさまざまな機能領域が協力して市場や消費者，技術的状況，将来の可能性を理解できたとき，素晴らしい製品が生まれるのです。事実として，今日の市場において優れた製品の中で，実験の過程を経ていないものはほとんどありません。
Marty Cagan氏(Silicon Valley Product Group)は，優れたソフトウェア集約型製品のアイデアの過半数は，技術チームが生み出したものだと言っています。彼らはテクノロジで何ができるか，将来はどこに向かうのかを，理解している人たちだからです。逆に言うとこれは，技術チームが“ビジネス”による要請に基づいたプロジェクトのデリバリを重視しているようでは，優れたアイデアを製品に活かすことは決してできない，ということにもなります。
InfoQ: 講演では，アジャイルをスケールアップする際の，ビジネスへの影響について話されていましたが，これがどのようなものか，例を挙げて説明して頂けますか？
Mary & Tom Poppendieck: 今の質問を次のように言い換えたいと思います - なぜ“アジャイルをスケールアップ”したいのか？正確に言うならば，リーン(本来ならばアジャイルも)は思想です。規模やスケールアップできるものではありません。スケールアップのできる，つまり規模を問題にできるのは，リーンあるいはアジャイルの原則の適用を通じて得られる，ビジネスへの正の影響についてなのです。ですから，影響を重視する理由と，その方法について話したいと思います。
賢明で創造的なエンジニアは，自分の仕事に目的を持っています。彼らの努力の恩恵を受けるべき人たちのための，真に前向きな改善が，もしも彼らを制約する組織機構によって妨げられているとすれば，彼らはより優れたテクノロジを追求するか，自らのレジュメを改訂するか，さもなくば個人ないし身近なチームのビジョンを追求することに自らの目標を見出すようになるでしょう。しかしエンジニアも人ですから，このような内向的な目標では，他の人々の問題を効果的に解決するために，自らの熟練した技術を駆使する時のようなモチベーションを持つことはできません。あなたが気に掛ける人々にとって重要な問題を，ビジネスへの持続的影響に貢献する方法で解決するということは，自らのモチベーションを奮い立たせることのできる目的のひとつなのです。
では，どうすればよいのでしょう？注意を払うべき最も重要なことは，設計者やプロダクトマネージャ，あるいはエンジニアにとっての - 理想的には協同するこの3者にとっての - フィードバックループの長さです。何かを試そうと決定してから，そのアイデアが - 現実のユーザに対して実際に行われたものとして - 期待していたようなインパクトを達成することができたかどうか，そのフィードバックを受け取るまで，どの程度の時間が必要ですか？ 数時間でしょうか？ 数日？ 数週間？ 数ヶ月？ それとも，まったく？ 設計者のBent Victor氏は，“クリエータには，自らの生み出したものと直接関わり合うことが必要だ”，という基本理念を持っています。同じような基本理念が，私たちにもあります。“チームは，自分たちの活動からメンバが直接学んだものに基づいて，自らの行動を調整しなければならない”，というものです。フィードバックループを短くしましょう。