「チーム・ジャーニー 著者による本読みの会 第13話『チームとチームをつなげる』」に参加しながらまとめてみた
肌寒かったのと朝日による直射日光で6時起きしてしまった日曜日。読書会も込みで有意義な時間が過ごせました。
チームとチームをつなげる
見ているものが違うチーム
統合化は終え、これから第2段階としてテスト管理ツールの連携やさらなる統合に向けていくところからこの章がはじまります。
同じ機能を2つのチームで作っていたことが発覚します。どっちが捨てるか、リモートワーク導入してるから認識違ってるんじゃないかとか不毛な言い争いが繰り広げられます。
チームごとに KPI が異なるのも一つの要因っぽいですね。
蔵屋敷さんの代行として西方さんという新たな登場人物が登場します。
同じユーザーをチーム全員で見よう
「何のために、それぞれのチームは、こんな追い立てられながら仕事しているの？」
「プロダクトをせっかく統合したのに、肝心の”ユーザー”が一緒になってないよ。まるで、ユーザーが3人おるようなもんや。」
「ユーザーの行動フローを全チームでまず共通の理解にし、そこで何が必要かを見立てる。そして、そのために各チームでどういう協力が必要かを決めていくわけですね。」
そして、われわれは何者なのか？ に答えるむきなおりをすることになりました。
「バラバラのユーザー」を「一人のユーザー」にする
「一人のユーザー」がチームをまとめる求心力になる！
ユーザー行動フローを描く
描くタイミングによって内容が変わると書かれており、2つの観点で判断していきます。
①プロダクトがまだなく、ユーザーに関する共通理解をつくりたい
②すでにプロダクトがあり、ユーザー体験の最適化を進めたい
①プロダクトがまだなく、ユーザーに関する共通理解をつくりたい
「自分たちがいかに想定ユーザーのことを知らないのか」を知る
いきなり細かく出そうとすると挫折するので、ざっくり概要から詳細へと段階を踏むことが勧められています。それから対応する行動を書き出していくことで、書けていないところがそのまま理解していないユーザーの状況として浮かび上がってきます。次に行動に伴い発生する課題を書き出します。この時はユーザーになるきるのが重要と書かれています。その課題に対する解決策を挙げていきます。そして最後に改めて理想的な行動フローを描いていきます。
②すでにプロダクトがあり、ユーザー体験の最適化を進めたい
こちらも概要から詳細へと細かくしていきます。そして状況に対応する行動を細かく書き出し、それぞれの行動に伴い発生している障害を書き出します。これをするためにはユーザーの実際の状況がわかっていないといけないので、行動ログの計測やユーザー調査を行うことが求められています。最後に障害に対する解決策を挙げていきます。
カンバンで状況を追う
今回は各チームのカンバンをプロダクトチームとして統合するので、アウトプットを統合するタイミングが定まっている必要があります。
チーム全体でどれだけ価値を生み出せたか、追いかけるべき指標として計測したい観点が2つ挙げられていました。
ある一定期間あたりに創出できた価値の数。これをスループットと呼ぶ。
スループットが低調なら、チームに何らかの問題が起きている可能性があり、カンバンでどこでそれが起こっているか把握しやすくなります。
価値創出までのリードタイム。課題が発見されたり、プロダクトについてのアイデアが生まれたりしてから、実際にユーザーに届くまでの時間
この数字もボトルネックの把握に役立ちます。
最後に西方さんから一言。
実はそれがユーザーにとってほんまに有効なんか、価値がもたらされるのかってわからんことが多いよね。だったら、それは仮説でしかないわけ、価値の仮説が本当のところユーザーにどう受け止められたのか、利用についての計測を行う必要がある。こうした活動は仮説検証と呼ばれる。
---
アジャイル開発がビジネス価値を高めるための開発手法であることが再確認できる章でした。
残り3章なので7月中にこの読書会も終わりになってしまいます。最終話以降に感想会も開催するかもしれないとのこと。
寂しくなるなあ。
この記事が参加している募集
😉