Agile 2016: ペルソナベースのチーム — 究極のフォーカス

ペルソナベースのチーム — 究極のフォーカス

先日のAgile 2016カンファレンスで，MixのAndy Hircock, Mike Lowery, Rob Vandenburg各氏が，“Persona Based Teams”と題した講演を行なった。その中で氏らは，アジャイル転換を導く上で，スキルベースのチームではなく，ペルソナベースのチームに移行するにはどうすればよいかを論じた。

数年前の氏らは“有名な壁”に突き当たっていた。スキルベースのチームによって編成されていた氏らの会社では，ウォーターフォールを使用しており，その利用に長けていた。その時点では成功していたのだが，オペレーションがすべての大陸，数千のユーザ，50を越えるユーザタイプにまで拡張するにつれ，いくつもの課題に直面することになった。

同社は組織構造をドラマティックに変革した。アジャイルを始める前の同社は，チームはまずスキルセットによって，次に製品，それからペルソナ，という順で構成されていた。それをまずペルソナ，次に製品，それからスキル，というように逆転させたのだ。それによってクロスファンクショナルなチームを作り，複数のシステムを利用する特定のユーザグループの問題解決に当たることにした。

そこで得た意図しない結果としてプレゼンタが説明したのは，ペルソナを重視することで，チームメンバに対する深遠な目的感覚を持つことが可能になり，参加意識が向上して，よりよい結果が得られるようになったことだ。これらはすべて偶然の産物だが，意図的に行なうことも可能なはずだ！

氏らはまず，実施前と後のハイライトを次のようにまとめた。

• 開発者とユーザとの会話がほとんどなく，ユーザの価値に対して的外れになることも多かったが，現在はすべてのチームメンバがユーザの日常を十分に理解している。
• システムをサポートする担当者と開発した担当者は別々だったが，現在は同じチームが開発とサポートのペルソナを持っている。
• システムやプロセス，ユーザの詳細をチームが直接理解するには，あまりにも情報が多過ぎていたが，現在は必要な知識ベースが分離されているため，システム全体ではなくペルソナに集中することができる。

その上で自分たちのアプローチを，いくつかの面から説明した。

• ペルソナ定義の旅に乗り出したとき，見つけ出したペルソナの数は86！そこで，それら86を追跡することはせず，まずユーザの役割によって分類し，その上でペルソナに展開することにした。その結果，86のペルソナを最新に保つために必要な３人を特定することができた。

• 次に氏らは，それぞれの製品を使用するペルソナの典型的な１日と目標を理解するという，新たな旅を追加した。システムが何をするかではなく，各ペルソナに何が必要なのかに注目したのだ。

• スクワッド(squad)と呼ばれる開発チームが，“日毎リリース毎に可能な限りペルソナを改善する”というミッションの下，１グループのペルソナの問題解決と開発に集中した。8～12のスクワッドが編成され，それぞれが数人のペルソナと，そのペルソナのグループを所持するプロダクトオーナに対応している。

• プロダクトオーナの仕事は，自身のペルソナの日常や仕事を知り，問題とその現れ方を観察することだ。そのために定期的にサイトを訪れ，ペルソナの作業を支援した。彼らの苦痛を知り，ユーザに対する共感を深く理解した上でチームに戻り，スクワッドがミッションを達成できるようにに，ペルソナの状況をチームに伝授している。

• ペルソナを深く理解するこのチーム構造では，すべてのチームメンバが自身のサイトを訪れる必要がある。これによって，プロダクトオーナがサイト訪問から帰ったとき，チーム全体がすぐにペルソナの生活する状況や環境を理解し，共感し，思い描くことができるようになる。

• このモデルでは，それぞれが注目するペルソナを持ったチームを複数まとめて担当する，チーフプロダクトオーナも置かれている。そして別のグループ(プロダクト管理)が，複数のペルソナが同じ機能を使用する依存関係と，チームとを結び付ける役割を果たしている。