ユーザーストーリーマッピングのワークに参加して来た!
また、認識齟齬・誤植などありましたら、ご指摘頂ければ幸いです。
・簡単!楽しい!5分でわかるユーザーストーリーマッピング(User Story Mapping) - Qiita
・ユーザーストーリーマッピングをやってみました | eureka tech blog
東京都千代田区外神田2丁目15-8 長坂第三ビル 3F
(0~100点満点、時間分の価値がどうにか有った=60点、概ね満足=80点)
内容は、各IT企業にコーチングやファシリテータ、コンサルとして現役であり、講演や執筆も数多くこなす方だけに申し分ない。
"もの凄い" と感じさせずに、着実に参加者が結果を出せるように企画準備・臨機応変に方向転換・褒める ⇒ 本人達もびっくりの結果が出た。


・キャンセルの嵐で、キャンセル待ちの方々への連絡するも10名全ては来ず。
・開始時刻を5分遅らせて、更に数分の遅刻者若干名で、4+4名の2チーム構成でワーク。
・最初に、講師から参加者の実務ロールや、今回参加の目的・期待などを聞かれる。
・ユーザーストーリー・マッピングの実務での作成経験者はゼロ。
・開発者(一番多い)、デザイナー、学びの場の提供者(=今回会場の提供者)、私、に分類される。(年齢層:20代~40歳前後?、私(57))
・前回は、"ユーザーストーリーの抽出" だったらしい(連続で参加している人に聞いた)
・私が1番最初に会場入りしたが、関係者間の雑談(主催者側の経験)が面白かった。
・プロダクトの設計
・ユーザーのワークフロー
・リリース計画
(Jeff Patton 氏が考案した手法)
・出来たものは、そのままカンバンボードとして使える=通常
・開発の済んだものにマーク付けしたり ←(進捗見える化)
・今回は上段から順に作成した;下段に行くに従って、上段の不足に気が付く場合も;"行ったり来たりが当たり前"
・各段を終える毎に、2グループ間で見せ合う。
・見積:各機能毎に、相対ポイントで表す。最大の場合、最少の場合、両方の数値を出しておく。(表形式でOK)
・実際に開発を回し、ベロシティ(生産性:1反復で何ポイントの開発を完了させられるか?)を計測 ⇒ 計画を見直し
・ベロシティ自体が不安定な場合は、別の話題へ...
・必ず話し合いながら、付箋を紡ぎ出していく感じ。(全付箋に全員がコミットしてる感じ)
・いきなり詳細から掘り始めると、進まない。完結出来ない。時間の無駄。"全体を押さえたい"目的に反する。
・たまたま思い付いた、細かいけど重要そうな事項は、とりあえず付箋に書いといて後で何処かに配置する・或いは色を変えて/表現し直して利用する、かも。
・"それは後にしよう" で書かないと忘れ去られる...
・今回も、1チームは長机2つでほぼ一杯(3.5m位?)、1チームは壁を利用(3m位?)
・特に、開発者オンリー、1~2人で作るといきなり小機能レベルのキーワード/話題になったりし安い
・利用者の目線ではなく、システム目線に陥りがち。
・当該サービスで実際に役割を担う関係者(若しくは同部署の人間とか..)が参加すると、現実からの乖離を防ぎやすい。
・"~する"・"~できる" の動詞で書く;"◯◯機能" とか書くのは良くない(特に上段では絶対ダメ!)
・頭から順番に見直して、最後まで行き着くか? 途中で当該機能が無かったり、論理的破綻してないか?
・現実なら、前提基準として共有しておくべき事項を "インセプションデッキ" などの形にしておく。
・"大きな目的"・"そもそも論" から離れてしまわないように;手段が目的化してしまわないように
・画面系/バッチ/操作に対するシステム挙動...などは、色を変えた方が分かり易い。(或いは、付箋の隅に色違いのマークを貼り付けるとか...)
・元々が "全体を俯瞰視する"・"先ず始める為のモノ" である。
・開発に入って 2~3週で、マップを見直す(問題に気付いたら適宜?!)。
・マップの見直しは繰返し行うこと(成果物と乖離するとか、既に破綻してる証拠) [重要]
・("間に合いそうなのか?" とかは別の資料が必要になるが...)
・表現の揺らぎは危ない;統一する
・(用語とか、定義を付箋で別枠に貼っておくべきかも)
・逆に言えば、認識合せのチャンスにもなる(認識齟齬の部分が明らかになる) ←(実際に結構多い)
マップ内に存在する?;入る必然性が有る? ⇒ 無かったら、"要らない機能ってことですよね?" と言えるかも。
現実と乖離したまま気付かずに先に進んでしまいがち
時間はかかるが、話し合いをしながら1枚づつ書込み・貼り出す。(前述)
参加できないメンバーでも、チェックを頼むとか必要。
完璧を求めない;絶対無理と割り切る;振返る機会を持ち続ける(前述)
心理的安全(圧力)が無い状態でないと、あるべきマップにならない。
"始める為のモノで、不完全だよ!" を十分に周知する
ウォーターフォールの見積用に使うなど、言語道断!
スマフォだけ対応すれば良いはずのサービスに、PC版の機能を計画:膨大な工数食って無駄死にしたり...
A.目的が"要求の整理"・"開発に入る為のモノ"なので、ユーザーストーリー・マッピングは完全時間順ではない。
カスタマー・ジャーニーマップはUX設計の一環で行われるが、ユーザーストーリーでは人間の感覚・体験は考慮しない(行動は対象に含む)。
システム側で機能を伴わない "人間の行動" も書いて良い(システム側は"何もしない"ことを明示できるから)。
A.完璧を目指さない;"抜けは必ず有る" 前提でチェックのタイミングを事前計画に入れる
A.このマップでは直接的には出て来ない。が、考える元ネタとしては使える。
非機能要件を考えるのは、別の切り口で、別の機会を設ける。
| 固定リンク
| コメント (0)
| トラックバック (0)
最近のコメント