アジャイルコーチのDavid Mole氏とSandy Mamoli氏は先日，ウェリントンのアジャイルミートアップグループで，ニュージーランド最大のオンライン企業であるTrade Meでの成功体験について講演した。彼らはSpotify型のスクワッドモデル(Squad Model)をTrade Meに導入すべく，チームの自己形成(Self Formation)とビッグバン方式のマイグレーションを行ったのだ。彼らのこの話は，今年後半にオーランドで開催予定のAgile 2014でも聞くことができる。
InfoQは両氏に詳しい話を聞いた。
InfoQ: Trade Meがどのような企業なのか，簡単に説明して頂けますか？
David & Sandy: Trade Meはニュージーランド最大の商用サイトです。ニュージーランド版eBayと思って頂ければいいでしょう。15年前にオークションサイトとして生まれた小さなスタートアップ企業でしたが，現在はウェリントン，オークランド，クライストチャーチに350人以上の従業員を擁する上場企業に発展しています。資産管理や自動車，仕事や交際相手の紹介，旅行情報，最近では保険サービスにも積極的に取り組んでいます。
InfoQ: 自己組織型チームとしての再構築が必要になったのは，何が問題だったのでしょう？
David & Sandy: ２年ほど前に私たちは，ひとつの転換点に達しました。企業としての成長は続いていたのですが，新たに人を採用しても実施可能な仕事量が増えず，かえって効率が低下してしまう状況に陥ったのです。気が付かないうちに，すべての人々やプロジェクトが互いに頼り合う，依存関係の網が張り巡らされていて，各専門グループの間で大量のハンドオーバが発生していました。別のプロジェクトのために忙しい人の手が空くまで待つ，という行為が日常的に行われていたのです。１週間で済む仕事に１年を要するような状況の下で，努力すればするほど，事態が複雑になっていました。
InfoQ: Spotifyのスクワッド(squad, 分隊)モデルに一斉移行する方法を選択したのは，どのような考えからなのでしょう？ もっとリスクの低い自己組織化の方法や，問題領域を限定したクロスファンクショナルチームなども可能だったと思うのですが。
David & Sandy: 私たちには人員とプロジェクトという，非常に困難な移行目標がありました。２つとも当時は常に流動的な状態にあったので，まずは複雑なマトリックスから人々を脱却させて，もっと確立したチームへと再配置することから始めたかったのです。
私たちは以前，クロスファンクショナルチームに挑戦して失敗したことがありました (メンバが複数のチームに同時に参加したのですが，必要なスキルをすべてのチームに用意することができず，一部のキーパーソンがボトルネックになるという問題を克服できなかったのです)。今回はその轍を踏まないように，新たなキーワードに目を光らせていました。そんな時にSpotifyのホワイトペーパを見て，これならうまく行きそうだ！と思ったのです。
本当の問題領域というものはありませんでしたが，スケーリングに関して全社的な課題を抱えていました。私たちは非常にアジャイルな考え方を持った会社としてスタートしたのですが，50人の時に成功した仕事のやり方を350人にスケールアップできない，という問題に突き当たっていたのです。ですから，ある特定の場所ではなく，Trade Meの組織全体を変える必要がありました。
InfoQ: これほどの野心的な変革に対して，トップレベルの賛同を得られる確信はあったのでしょうか？
David & Sandy: 正直に言って大変でした。当然ながら全面的な賛成はありませんでしたが，素晴らしいと思ったのは，組織が信頼関係で結ばれていたことと，新たな挑戦に対して彼らが寛容であったことです。加えて私(David)とも，すでにプロジェクトリーダとして良好な関係がありましたし，相応の影響力も持っていました。
さらに私たちは，ごく小さいい規模で始めることにしました。うまく行きそうな場所を選んで，最初のスクワッドを適用したのです。非常に戦略的な行動ですが，これは私たちのアジャイルコーチであるSandy Mamoliの提案によるものです。成功するためには何をすればよいのか，彼はよく理解していました。その後６ヶ月にわたって新たなスクワッドを１つずつ，非常にコントロールされた方法で増やしていきました。この方法ならば，新しいスクワッドに十分な注意を払えますし，必要な場合にはいつでも手助けすることができます。このゆっくりした拡張方法は，私たちによく合っていました。先行投資型のビッグバンアプローチよりも，こちらの方がうまくいっただろうと思います。ビッグバンアプローチの場合，私たちの望むスムーズな移行ではなく，カオスな状態に陥る可能性もありますから。
しかしながら私たちは，ある時点で，事の進行が遅すぎることに気付きました。 皆しびれを切らし始めて，いつになったら"スクワッド化(squadify)"できるのか，と私たちに詰め寄るようになったのです。明確な成果を上げている部分から除外されているために，自分たちが粗末に扱われているように感じ始めたのでしょう。私たち自身もこの時点で，すでに今回のアプローチのメリットを確信していました。それをTrade Me全体に広めたいと思っていましたから，これ以上待つ必要はまったくなかったのです。
InfoQ: 自己組織型チームに再構成されるというニュースに対して，既存のチームや関係する人々からは，当初どのような反応があったのでしょうか？
David & Sandy: こういった場合の反応は，誰であっても同じようなものでしょう。"すごいアイデアだ，きっとすごくクールだよ"，と言うのですが，それが本当に実行されるとなると "えっ！"，ということになります。次にはショックと困惑の表情を浮かべながら，失敗する理由を数限りなく挙げてみたり，"この場合はどうするんだ？"といったシナリオを並べ立てたりするものです。
そうであっても，十分な計画とサポート技術があることを理解してもらえれば，たいていは協力してくれるものです。厄介事を扱う場合のステップはこんなものですが，それでも私たちには，彼らがこのように反応してくれるかどうか不安がありました。今回に限っては，彼らの日常的な作業を根本的に変えるようなものが対象だったからです。実施する上での立場は違いましたが，彼らの以前の状況を知っていましたから，彼らを支援することができました。例えば，"もし・・だったら"という問いかけのすべてに耳を傾けて，計画や図を示して安心させることが重要だと理解していたのです。
nfoQ: あなた方が行った"スクワッド化(squadification)"のプロセスについて説明してください。テストや洗練化はどのように行ったのでしょうか？
David & Sandy: チーム化プロセスを説明したこのラフスケッチが，私たちの望んでいることを理解する上で本当に役立ちました。オークランドのサテライトオフィスでベータトライアルを行った時にも，この図を使用しました。
グループが "さあ，自己選択(self-select)しよう！"という誘いのEメールを受け取ると，プロセスが始まります。私たちがいつも重視しているのは，それを実施する理由と，きっとうまくやってくれる，という大きな信頼です。今まで実施した中で(といっても，まだ３回ですが！)，この連絡に対する否定的な応答や，辞退の申し出を受けたことはありません。これほど素晴らしい人々と一緒に仕事をできるのは幸運だと思いますし，私たちも，彼らに十分な説明をしていると思っています。
チーム化を実行する時点では，すべてのメンバが，自分がこれから何に参加するのかを知っている必要があります。そのため，それぞれのスクワッドには，事前に割り当てられたプロダクトオーナがいます。彼らはスクワッドの目的，すなわち"スクワッドミッション"と，何を行うのかを説明するために選ばれているのです。１つのプロジェクトでは期間として短すぎますから，チームを解散する前に，それまでのチーム構成による過去のプロジェクト歴を確認することで，長期的な検証を行うようにしました。
それからルールについて説明します。ルールの数はごくわずかですが，中心となるのは "Trade Meにとってベストなことを行う" という考え方です。その他は"チームは同じ場所で作業する"，"３～７人で構成する"，"エンド・ツー・エンドを提供可能である" などです。
自己選択の段階(それまでのエネルギーと熱意を維持するために，できるだけ早く取り掛かりたいと思っていました)になって，タイムボックスやサイクルが重要なことが分かりました。自己選択を求められるときには必ず，10分のタイムボックスで取り掛かるようにしています。最初の10分間が終わった時点では，まだ完全なスクワッドはできていません。そこでミニ・レトロスペクティブを行ってグループの状況をレビューし，次に解決策として何をすべきかを決定します。
それから10分間の時計をリセットして再度実行し，何があって何が足りないのかをチェックして，それをグループに発表します。例えばひとつのチームがテスタの数が多すぎると言い，別のチームがテストを実施できていないのなら – この２チームは，次の10分間のラウンド中に話し合うべきだと思うでしょう。
いつ完了するのかを事前に知ることはできません。すべてのエネルギーを使いきるまで，可能な限りたくさんのスクワッドが完成するのを目指すのみです。このプロセスの実践は驚くほど疲れるので，２時間も一緒に作業すれば，誰もがふらふらになってしまいます。そうなったら作業を切り上げた方がよいでしょう。そのまま続けても，よくない結果が得られるばかりだからです(人の移動ばかり続いて，完成するスクワッドの数が少なくなったりします)。
InfoQ: オークランドで学んだ教訓は，おもにどのようなものだったのでしょう。最終的なスクワッド編成にそれは活かされましたか？
David & Sandy: 視覚化ですね。 いろいろなことを視覚化する必要がありました。付箋紙に名前を書くだけでは不十分です。チーム構成図が見えるようにして，すべてのチームに必要なスキルと人材が揃っているのか，一目で分かるようにしておかなければなりませんでした。自己選択サイクルを迅速に動作させることが必要だったのです。視覚化が不十分であったため，サイクル毎のレビューにずいぶん時間を費やしてしまったと思っています。ペースを完全に確立できなかったことで，タスクに対してメンバが持っていたエネルギや熱意を損ねた部分もあります。うまくできれば，エネルギに満ちた，効率のよい作業ができるのですが(もっと疲れるでしょうね！)
今回の方法の選択にマネージメントの全面的な賛同があったことも，説明しておいた方がよかったかも知れません。誰かひとりのマネージャの発案ではないのかと噂するかも知れなかったからです。直感的に何か間違ったことをしているとか，あるいはマネージメント的な決定に背いているとか。まったくの的外れなのですが。
今回で一番の教訓は，自己選択の原則が機能する，ということですね！正直に言うと，試してみるまで分からなかったのですが，今回の成功で確信できました。
InfoQ: スクワッド移行日に至るまでの参加者からは，どのような感情を読み取ることができましたか？
David & Sandy: 疑問の声はたくさんありましたが，それは当然だと思います。彼らの仕事仲間を変えようとしていた訳ですし，その過程で，新しい仕事のやり方(スクラム，カンバン，あるいは新しいグループの決めたアジャイル的なもの)を取り入れましたから。そのためにEメールや会議招待，キッチン(やトイレ！)で質問攻めに合いました。
何もかも悪い方向へ進むのではないかという不安や懐疑的な見方，あるいは気の合わない人に縛られることへの恐怖心があるというのは，私たちにも分かっていました。
もっとルールや制約が必要だという意見もたくさんありました。例えば，すべてのチームに初級開発者とベテラン開発者を配置するべきだ，という具合です。私たちは新たなルールをすべて拒否しました。それぞれが波及効果を引き起こして，解決すべき問題がさらに複雑になるからです。そこで私たちは，どのようなレベルの初級技術者あるいは上級技術者が必要なのか，スクワッド自身にケースバイケースで決めてもらうことにしました。この時に私たちが介入してルールを決めていたら，現在のような成功を得ることはできなかっただろう，と正直に思います。
私たちは狂っている，とも思われていました。非常識だったからでしょうね！
InfoQ: 当日の反応はどうでしたか？
David & Sandy: 当日はすばらしいものでした。一歩下がって，自己選択した技術部門全体を見る気持ちには，他に比べるものがありません。その日は１日，高いエネルギのままでした(これもトライアルの経験から学んだことです)。これが紆余曲折のエキサイティングな１日のために役立ちました。全員がプロセスを受け入れることによる素晴らしい相互作用が，部屋中に満ちていました。完成したスクワッドの数を大声で読み上げて，それが理想の数にどんどん近づくのは，まさに爽快でした！
その日の終わりには，多くの人たちが成功を手にしていたと思います。自分の望んでいた場所で，望んでいた人たちと仕事をしていました。前日まで懐疑的だった人たちも，当日は本当に肯定的なようでした。支援作業で疲れた１日を終わるにあたって，そのような状況を見聞きするのは本当にうれしいことでした。
InfoQ: この経験でもっとも意外だったのは何ですか？
David & Sandy: 一番驚いたのは，"もし...だったら"というシナリオがひとつも実現しなかったことです。ほんのひとつも，ですよ！同僚が誰であるかを基準に決断した人の数が多いことにも驚きました。仕事や製品が何であるかは二の次だったようです。
これほどうまく行きそうなことが，これまで一度も行われていなかったことも驚きですね。プロセスを一通り実施してみて，なぜ誰もこれを試さないのか，どうして非常識だと思われているのか，不思議でなりません。
InfoQ: チーム編成日の成功状況の確認は，どのような基準や項目で行ったのですか？その経験から何を学んだのか，この情報をどのように用いたのか，といった点を教えてください。
David & Sandy: 当日もっとも重視した基準は，スキルを完備したスクワッドを編成できた数です。完全なスキルを備えたスクワッドひとつの方が，特化したスキルのスクワッドが多数あるより望ましいということは，前もって説明してありました。目標11に対して，10のスクワッドが編成できました。これはすばらしい成果です。もし目標のスクワッド数に対して正確な人数が揃っていたとすれば，それはあまりにも偶然に過ぎると思います。未達成の部分は今後の人材採用に対する動機になりますから，それもこの日の重要な副産物でした。
私たちが考えていた "もし...ならば" のひとつは，どう処遇してよいか分からない人が残ってしまう，というものでした！最終的に，このカテゴリに当てはまる人はいませんでした。
経験から学ぶという意味では，私たちは100%正しかったと思います。計画と準備に非常に注力したこと，適切な空のスクワッドの選択を確認したこと，適した人材に恵まれたこと，複数のスクワッドに属するデータベースの専門家のような例外的存在をあらかじめ考慮していたことなど，すべてがうまく行きました。
InfoQ: 最終結果やチーム構成について，何か意見の相違はありましたか？
David & Sandy: 特にありません，ほとんどの人が結果に満足していましたし，完全に満足しなかった人たち(自らを犠牲にした人や，全体のために必ずしも希望しないチームに参加した人もいました)も，会話や選択に直接参加していたので，納得はしていました。その日に参加しなかった人たちについて，"自分のスクワッドには参加してほしくないと皆が言っている"という噂もありましたが，事実でないと分かりましたし，そのような話もすぐになくなりました。
InfoQ: 既存のプロジェクトを新しいスクワッドに移行する作業や，従来構造を解体するプロセスはスムーズに進んだのでしょうか？
David & Sandy: その日選択したスクワッドに移行するまでには，ほぼ３ヶ月必要でした！既存のプロジェクトや業務を離れる人たち，クリスマス休暇や新たに採用される人たちのことを検討する必要があったのです。例えば一部のスクワッドは新しい設計者が雇用されるのを待って，数ヶ月後までスタートできませんでした。このために小さな依存関係の網が生まれて，最初の３ヶ月間はグループのメンバが新たに参加したり離れたり，新しいスクワッドの始まりという小さなバーストで埋め尽くされていました。ちょうどテトリスで，画面の3/4をパーツで埋めるのに成功したときのような感じですね！
InfoQ: スクワッドを自己強化あるいは自己組織化する上で，スクワッドの自己形成に対して与えられた権限はどのようなものでしたか？
David & Sandy: 原則的にはその日以降，今日まで変わっていません。圧力は何度かありました(新たなプロジェクトが明日から開始するという状況で，人をかき集めようというように)が，スクワッド構成は維持されています。
自己選択されたスクワッドは，私たちマネージャが選定したチームより安定しています。生産性が高く，個人間の衝突や意見の相違は少なくなっています。
すべてのスクワッドが形成された今，残ったのは，プロダクトが変わったり，プロダクトオーナが方針を変えたことによる，"私たちはまだこのような作業契約にサインしていない" というただひとつの問題です。私たちが当日決定して発表したことは，その時点で持っていた情報においてベストを尽くした結果でした。物事が変化するのは必然ですし，それに対して異議を唱える権利が私たちにはあります。
InfoQ: 新たなスクワッドの団結と価値創造を維持する上で，あなたが使用した介入や学習などのサポート構成はどのようなものでしたか？
David & Sandy: すべてのスクワッドにサポートとコーチングを行いました。ただし現在22あるスクワッドに対して，フルタイムのアジャイルコーチはたったひとりしかいません。つまり，トレーニングの機会やコーチングを提供することは可能ですが，このボトルネックを回避するためには，私たち自身で内部コーチを育成しなければなりません。そのために，可能な限り各人がお互いに支援やサポートをできるような構成を作り上げました。私たちにはアジャイルコーチング協会があって，読書クラブのように書籍の推薦などを行っています。また各人をペアリングすることで，サポートする相手が誰であるかをいつでも分かるように努めています。
介入することもあります。私(David)が入ってスクワッドを支援しなければならない場合もまれにありますが，問題の規模は最初に比べると徐々に小さくなってきていますね。このようなことは必然的で，アジャイルやスクワッドというよりも，一般的なグループ構成や心理学の範疇でしょう。
InfoQ: あなたのプレゼンテーションでは，トライブ(Tribe,部隊)やギルド(Guild)の"発生"，さらにはそれらをリードするチャンピオンの出現について簡単に触れていますね。これらの面について，もう少し説明して頂けますか。これらはどのように進展して，コミュニケーションの豊かさに対してどう貢献するのでしょう？
David & Sandy: チャプタ(Chapter, 支部)，トライブ，ギルドは，Spotifyモデルを全面採用するという最初の決定において，全体的なデザインの重要な部分でした。Spotifyモデルに関する大きなリスクのひとつとして，スクワッドが孤立してコミュニケーションが行われなくなる，というものがあります。ですから，このようなサポート構造は，成功を収めるためには欠かせないものなのです。
社内的な"アジャイルチャンピオン"の出現は，このモデルの成功に大きな影響力を持ったファクタです。幸いなことに私たちは，アジャイルに対する熱意と非凡な行動力，卓越した対人スキルを備えた人材に恵まれました。彼らはまさに事を成すことが可能な人たちで，皆が途方に暮れるような問題に直面しても笑いを絶やさないのです。そういった人たちが現在10人いますし，新たなチャンピオンも生まれようとしています。
InfoQ: このストーリはこれで完結なのでしょうか，あるいはスクワッド構造の洗練を今後さらに続けていくのですか？
David & Sandy: まだ始まったばかりです！もう次のことを考えていたとしたら，それは考えが甘すぎるでしょう。ただし最初の時点で，スクワッドのロールアウトが完了するものと考えていた人たちには，説明が必要でしょう。終わりがない，ということを説明するのは難しいかも知れませんね！
私たちがここで作ったのは，ひとつの社会実験です。スクワッドはそれぞれ，日常的に緊密に協力し合う人々の，新たなグループなのです。彼らは同じ立場に投げ込まれていて，仕事の内容によっては，時に強いストレスに苛まれるかも知れません。彼らをサポートして，アジャイルナレッジを構築して，成長を図り，離職する人たちにも対処して，無駄を削減し，サポートツールや環境を改善して，... やるべきことはたくさんあります！
今まででよかった点は，アジャイルの原則と自己選択がTrace Me文化の不可欠な部分になったことですね。
InfoQ: 新しいチームに関する今後のあなた方のエクスペリエンスについて，読者はどこで学ぶことができるのでしょう？
David & Sandy: Nomad8ブログで読むことができます。特に以下の記事をお勧めします(公開順)。
あるいは，Agile 2014での発表時にも詳細をお話するつもりです。