Photo by
masumiyutaka
【メモ】チーム・ジャーニー本読み会 第13話
チームとチームをつなげる
機能開発数をKPIとして開発を進める3つのチーム。それぞれが異なるユーザーを見てる複数のチームが、ひとりのユーザーを見ようとすることでひとつのチームになろうとしている。
ユーザー行動フローをみんなでつくる
背骨となる大きな粒度から始めて、肉となる詳細な粒度へ掘り下げていく。
全員でつくるプロセスを経ることで成果物はチームの共通理解となる。
どうやら細かいことにこだわり始めると抜け漏れ等が気になってなかななか進まないらしい。そのため大きな粒度で1周してから詳細度を高めていくと良い。
フレームワークは以下がある。
■ ユーザー行動フロー
* サービスブループリント
* カスタマージャーニーマップ
* ユーザーストーリーマッピングユーザーストーリーマッピングは現在の事業が立ち上がる際に一度作ったきりだったことを思い出した。あれからメンバーがだいぶ増えた。開発を進めてきているからそれなりに差分がある。今いるメンバーでもう一度共通理解をつくってみることで課題を共有できそうだ。いい気づきが得られた。
すでにプロダクトがある場合の目的
現場のプロダクト利用に伴って発生する障害を特定する
これをやるためには、ユーザーの実際の利用状況がわかっていないといけない。
事実ベースで把握
なぜ改めてユーザー行動フローを描き直すのか。WHYを大切にしたい。ただやってみたいからでは着地点がわからなくなってしまう。
カンバンと線表
カンバンはトヨタ生産方式として知られている。線表は大きな粒度で示したスケジュール表のようなもの、またはかなり粒度の荒いガンドチャートっぽいもの。
カンバンはフローの可視化。カンバンは「いつまでに出来上がるのか」が分からない。そこで線表の出番。
線表でマイルストーンを見える化する
線表は意思の可視化である。
スクラム開発をはじめとしたアジャイルソフトウェア開発は、現状から得られたフィードバックを基に最適化がとくに働きやすい印象である。そうすると当初計画していたことのスケジュール感が曖昧になってしまう恐れがある。
そこでチーム間で共通の意思を線表として可視化する。これが達成への推進力となる。
私の現場では線表を試験的に業務に実際に取り入れている。特に複数チーム間で協働する場合に効果的な印象だ。
メモ
チーム全員で取り組むことで共通理解をつくる。