BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Agile 2016: ペルソナベースのチーム — 究極のフォーカス

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

ブックマーク

原文(投稿日:2016/08/23)へのリンク

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

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

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

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

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

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

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

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

  • ペルソナ定義の旅に乗り出したとき,見つけ出したペルソナの数は86!そこで,それら86を追跡することはせず,まずユーザの役割によって分類し,その上でペルソナに展開することにした。その結果,86のペルソナを最新に保つために必要な3人を特定することができた。
  • 次に氏らは,それぞれの製品を使用するペルソナの典型的な1日と目標を理解するという,新たな旅を追加した。システムが何をするかではなく,各ペルソナに何が必要なのかに注目したのだ。
  • スクワッド(squad)と呼ばれる開発チームが,“日毎リリース毎に可能な限りペルソナを改善する”というミッションの下,1グループのペルソナの問題解決と開発に集中した。8~12のスクワッドが編成され,それぞれが数人のペルソナと,そのペルソナのグループを所持するプロダクトオーナに対応している。
  • プロダクトオーナの仕事は,自身のペルソナの日常や仕事を知り,問題とその現れ方を観察することだ。そのために定期的にサイトを訪れ,ペルソナの作業を支援した。彼らの苦痛を知り,ユーザに対する共感を深く理解した上でチームに戻り,スクワッドがミッションを達成できるようにに,ペルソナの状況をチームに伝授している。
  • ペルソナを深く理解するこのチーム構造では,すべてのチームメンバが自身のサイトを訪れる必要がある。これによって,プロダクトオーナがサイト訪問から帰ったとき,チーム全体がすぐにペルソナの生活する状況や環境を理解し,共感し,思い描くことができるようになる。
  • このモデルでは,それぞれが注目するペルソナを持ったチームを複数まとめて担当する,チーフプロダクトオーナも置かれている。そして別のグループ(プロダクト管理)が,複数のペルソナが同じ機能を使用する依存関係と,チームとを結び付ける役割を果たしている。

 

 
 

この記事を評価

関連性
スタイル
 
 

この記事に星をつける

おすすめ度
スタイル

BT