アジャイルコーチでメタスクラムを組む

　チームでスクラムに取り組む。チームとしてスクラムの経験がなく、スクラムマスターも含めて実践のための支援が必要となる場合、「アジャイルコーチ」を招聘する。単一のチームへの支援の場合、それほどややこしい臨み方が求められるわけではない。しかし、対象が複数のチームになる、組織的なスクラムの実践の場合は、アジャイルコーチ側の組織化が必要にもなる。

　具体的にはアジャイルコーチ側で、現場のスクラムとは別のスクラムを仕組もう（仮にメタスクラムと呼ぼう）。メタスクラムではアジャイルコーチ同士が複数のチームを横断して、何が課題かを話し合う。そこで、チーム個別もしくはチームを越えて全体として取り組むべきことをやはり「バックログ」として著していく。

　アジャイルコーチ側の動きをスクラムにすることは一定のオーバーヘッドも伴うが、「横断的俯瞰的に、仮説立てて取り組み進めていく」にあたっては不可欠と言える（どこまでスクラムイベントを忠実に行うかはもちろん適宜決めてやるとして）。

　具体的には、各チームでの学びをコーチ陣営で共有し、踏まえてチーム間での取り組みのムラをなくす、全チームで共通としたい理解を形成・醸成する、チームを越えた重点支援の実現（複数人のコーチで支援にあたる）などが狙いだ。チーム個別の支援は、どうしても個別の学びで閉じがちになる。メタスクラムか、ハンガーフライトか、意図的に学びの「共同所有」にもっていく仕掛けが必要だ。

　アジャイルコーチ自体も当然ながら経験に限りがある。一人で何もかも対応できるのは相当スーパーなコーチだ。なかなかいない。現実的には、チームへの臨み方（仮説、課題、解決の仕方）についてコーチ陣営で相談したり、中身を練り上げていくやり方で担保したほうが妥当で安全だ。

　この整理の中で、なお抜け落ちていく観点がある。それは、プロダクトオーナーへの支援だ。え？ アジャイルコーチが当然担うのでしょ。もちろんそうなのだけど、プロダクトオーナーにとって必要なのはスクラムのプレイの仕方だけではない。バックログの中身自体をどうやって詰めていくか、その方法が問われる。つまり、「探索（仮説検証）」をどのように行うかが肝になる。

　ここがアジャイルコーチの経験上不足していることがありえる。例えばスクラムマスターからアジャイルコーチにキャリアを進めてきたとしたら、プロダクトオーナーとしての実務経験がごそっと落ちることになる。仮説検証をどのように行うかの勘所がなければ、そのレクチャーなりコーチングにあたることは難しい。

　ゆえに、仮説検証にあたっては別の支援が必要なことが多い。仮説検証コーチでも、探索メンターでも、PO支援者・PO代行でも名前はいずれでも良いが、プロダクトオーナーの実務を支援する役割が必要だ。

　もちろん、仮説検証を下支えする、デザインシンカー（UXリサーチャー）が別に存在すればその力を借りる算段もある。ただし、その場合はUXリサーチとアジャイルの統合について講じなければならない。アジャイルのリズムとUXリサーチをどう合わせるか。これはまた別途論じたい。