1/24(水)の夜に、ユーザーストーリーマッピングの公開ワークショップに参加して来ました。
自社サービス/顧客とコラボしてのサービス展開などの際に必要なツールの1つとして、社内的な知識の共有と、
実戦で使うためのナレッジを得たい!・社内でワークショップをやりたい!
...ので参加させて頂いた次第です。
ファシリテーターはギルドワークスの中村 洋 氏。
twitterではフォローさせて頂いていますが、ご本人にお目通りする?のは、これが初めてです!
当日は、大変お世話になりました。
下記のレポートは、筆者自身の言葉への置き換えやメモが含まれていたりしますのでご了承下さい。
また、認識齟齬・誤植などありましたら、ご指摘頂ければ幸いです。
参加コンテンツ名/講師/機関
実施日時
2018-01-24(水) 19:30 - 21:30
実施場所
合同会社ねこもり 秋葉原オフィス
東京都千代田区外神田2丁目15-8 長坂第三ビル 3F
満足度
95点~
(0~100点満点、時間分の価値がどうにか有った=60点、概ね満足=80点)
内容は、各IT企業にコーチングやファシリテータ、コンサルとして現役であり、講演や執筆も数多くこなす方だけに申し分ない。
"もの凄い" と感じさせずに、着実に参加者が結果を出せるように企画準備・臨機応変に方向転換・褒める ⇒ 本人達もびっくりの結果が出た。
概要・所感


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

★クリック1つでブログランキングにご協力戴けます! m(_ _)m
最近のコメント