Lean XPチームができた。さあ、どうやって広げる？
最初のチームがEnablement出来たら、こうやって組織全体に広げていこう。
そもそも、Enablementとは？
この記事ではEnablementされたチームを「自力でLean XP開発のできるバランスチーム（プロダクトマネージャー×1、デザイナー×1、エンジニア×1~4）」と定義します。また、Enablementに必要とされる期間を１サイクルと呼びます。
Lean XPプロセスの習得は、すでにEnablementされているチームに参加し、1サイクルかけてプロダクト開発を進めることが最も効果的です。プロダクトマネージャー、デザイナー、エンジニアとしての基礎知識のあるメンバーの場合、３〜４ヶ月のサイクルでLean XPを自力で進めるために必要なスキルセットを身に付けられます。
Pivotal LabsではI Do、We Do、You Doというステップを踏んでEnablementの度合いを深めていきます。始めのI DoステップではPivotal Labsのメンバーがプロセスをリードし、慣れてきたらWeDoステップでフラットな形でお互いをサポートしながら開発します。最後のYou Doステップではクライアント主導で開発を進め、Lean XP未経験者と組んでもプロセスをリードできることを確認します。
サイクルの終盤を迎えると、必ずと言って良いほどクライアントに聞かれるのが今回の課題、「戻ってから、どうやって広められるか」です。
以下の通り、各役割の新メンバーが経験者とペアを組んで実プロダクトでの開発を進めることが、最も効果的な方法です。（Pivotal Labsでのバランスチームやペアでの開発については、Pivotal Labsって一体なに？参照）
こうやってLean XPプロセスを広げよう
① ペアワークで密にコミュニケーションをとる
Enablementされたバランスチーム（プロダクトマネージャー、デザイナー、エンジニア）が新しいメンバーと１対１でペアできる形でチームを構成することが重要です。Lean XPのプロセスの多くは、「まずやってから、その理由を理解する」という方法で習得します。様々なタスクの「やり方」に関してはプロダクトやチームによって微調整をするので、正式なドキュメントなどがありません。Enablementされた「プロセスの先輩」とそのタスクを経験しながら学んでいきます。
② 実プロダクトで実践する
Lean XPには決まったルールは少なく、本を読めば概要は把握できる訳ですが、当然、決まり事を暗記することが目標ではないはずです。
決まったルールが少ない分、プロダクトやチームによって強調するべき点、妥協するべき点が変わってきます。このようなチームの方向や優先度の微調整等は実プロダクトで応用しないと経験できません。
エンジニアの例を挙げると、アプリに対して書くテストは最初は簡単ですが、数が増えるに連れて管理が難しくなります。常にConfidence（求められている振る舞いを正しく評価できているか）、Speed（実行時間）、Freedom（実装のリファクタリングへの影響）、Cleanliness（読みやすさ）を天秤にかけながらテストの内容を調整するのですが、テストの数が増えるとどこかを妥協しなくてはならなくなります。実プロダクトでテスト駆動開発をして小さい失敗を重ねることが、そのような微調整のスキルの上達への近道だと考えてます。
妥当なプロダクトが無い場合は、研修や型にはまった練習問題などは効率的では無いので、組織内の課題を見つけ、それを解決するアプリをバランスチームで開発するのが良いかもしれません。
③ ゆっくりスタートの指数関数的成長を目指せ！
せっかく最初のLean XPチームのEnablementに成功したのに、バランスチームでのペアリングでしか広げられないのはもったいない！とのフィードバックをよくいただきます。
確かに、最初のサイクルでは１チームから２チームにしか育たないので、一気にEnablementを増やすことができません。ただ、ペアリングを通して毎サイクル着実にEnablementすれば、サイクルごとにチーム数を倍増できるので長期的には飛躍的な拡大を実現できます。
非効率的な広げ方の典型
以下の２パターンをよく見ます。どれも部分的には効果的なことがありますが、長期的に自力で走れるチームを増やしたいのであれば、お勧めしません。
① 教授型
Enablementされたメンバーが一度に複数のメンバーにスキルを教える（セミナー、ドキュメントの共有など）手法。
Lean XPには厳密なルールが少ないので、そのルールだけであれば教室で簡単に学べます。理論上は簡単にできそうなことが多いので、実際のプロダクトで実在する課題に応用するまで、Enablementを計れません。また、概念の説明を受けるよりは、ペアを組んで実際に体験をする方が格段と効果的に（かつ楽しく😀）習得できます。
また、どんなにLean XPの経験豊富であっても、分からないことがあったり、認識が間違っていたりすることがあります。チームとして「正解」を探し求め続けない限り、Enablementの際に一人の誤認識が広がり、「正解」として一人歩きしてしまいます。
② 分散型
Enablementされている１人のPM（あるいはDesigner、Engineer）が、Lean XPを知らないチームに一人で広げる手法。PM、Designer、Engineerが各自に別チームをリードできて効率的に思えますが、一人のメンバーに複数人（しかも複数の役割）のEnablementをリードさせることには無理があります。
バランスチームでは役割ごとにやることがはっきりと分かれているので、自分の役割以外のプロセスに関しては、Enablementをリードすることができません。
Lean XPとはルールを学ぶ事ではなく、実在するプロダクトに応用する事で初めて価値が発揮できる開発手法です。チームの拡大は焦らずに実際のプロダクトの開発を通して着実に進めることが最も効果的です。
