これはアソビュー！ Advent Calendar 2022の5日目です。
こんにちは。
アソビューでテックリードやってる井上です。
12月ですね。この時期の悩みは子供のクリスマスプレゼント（byサンタ）とふるさと納税（毎年12月に駆け込み、、）ですね。
さて、今日はユーザーストーリーマッピングについて、アソビュー社内活用事例と感想や展望などを共有します。
はじめに
ユーザーストーリーマッピングそのものについてはここでは割愛させていただきます。
詳しくはこちらの有名な書籍（オライリーのユーザーストーリーマッピング）や他社事例などが検索すると出てきますのでそちらを参考にしていただければと思います。
アソビューでは以前からいくつかのプロジェクトでユーザーストーリーマッピングを活用していたのですが、
今回直近キックオフを迎えた現在絶賛開発中のとある大規模プロジェクトにおいても取り入れました。
ストーリーマッピングについては多くの会社やプロジェクトで取り入れられているものと思いますが、プロジェクト特性、規模などによって使い方がそれぞれ違ってくると思います。
今回紹介する事例が、ユーザーストーリーマッピングを新しく取り入れようと思われたり改善しようとする際に少しでも参考になればと思っています。
対象のプロジェクトについて
概要
このプロジェクトは、弊社の複数ある既存のSaasシステム（パートナーとなる事業者様や社内のサポートメンバーが使うもの）の統合や機能拡充を目的として、既存の業務プロセスに対して新しいアプリケーションを開発する大規模プロジェクトになります。 このプロジェクトでカバーする業務範囲やシステム、ユーザーなどステークホルダーの範囲が非常に多くなります。
体制
規模としては初期（10月頃）は20人程度、その後直近でも30〜40人ほどに拡大していく予定です。
特徴としては最近入社したメンバーが割合的には多く、全体としては開始時点での業務ドメイン知識が浅いと言えるとは思います。
なぜストーリーマッピングをやることになったのか？
実はこちらのプロジェクトは最初からユーザーストーリーマッピングを取り入れることが決まっていたわけではありませんでした。
こちらのブログ及び登壇で弊社CTO江部から共有しましたが先行してRDRAの手法を用いてモデルベースの要件定義、業務モデル整理をおよそ一年ほど少人数メンバーで実施してきました。
その準備期間を経て、いよいよ実際に実際の設計、開発プロセスに入っていくことになり、今まで他プロジェクトやチームにいた開発メンバーが集結して動き出すことになりました。
事件
そんな中で新しい体制で10月にキックオフを経てさあ、スタート！、、というところで事件は起きました。
まずは要件定義から参加していたPMからメンバーに向けて、膨大なRDRA資料や要件定義の設計資料を元にメンバーへの説明を行いました。 （※事前に資料などは共有していました） 結果、、
( ﾟдﾟ)ﾎﾟｶｰﾝ
何ということでしょう。
meetの小さな枠に映るメンバーの顔、特にアソビュー歴の短いメンバーの顔から？マークや虚無の表情が見て取れます。
そしてその後手始めに簡単なところから詳細の仕様を詰めていくプロセスとなると古参メンバー中心に各論に突入していってしまいその日のミーティングは終わりました。
このまま要件定義資料などを元に設計、実装などと進んでいっていいのか？
- モデルベース要件定義で業務を分解したものだと実際のユーザー目線が足りないのではないか
- このまま進めると個々の業務の繋がりが描けずつぎはぎなシステムになってしまうのでは
- 結果今のシステムの焼き増しが出来上がってしまうのでは？本当はできるはずの業務プロセス改善ができなくなってしまわないか
- 開発メンバーにとってユーザーの使われ方がイメージできないシステムを作るとなるとユーザー企業での開発をする面白みが無いのでは
などなどその日の夜もんもんと考え、次の日目が覚めて、やはりこれじゃだめだ！ となっていても立ってもいられず提案しました。
するとPMを初めメンバー各位も同じ課題感を持ってくださっていたようで、すぐに賛同いただき、他メンバーからもpushや意見をもらって晴れてユーザーストーリーマッピングをやる方針で確定しました。
突飛な？意見でも批判ではなく提案ベースで忌憚ない意見をくれつつ一旦やってみれば良いんじゃないという感じに前のめりに受け入れてくれるチームメンバー達に感謝です！
ストーリーマッピングに何を求めるか
ユーザーストーリーマッピングを実施することで得られることを期待していることを主なことを書き出してみました。
ユーザー理解
今回のプロジェクトでは作るシステムもユーザーも複数で、例えば弊社のSaasを使う事業者、と言っても大手の遊園地や水族館の担当者、はたまた個人でダイビングショップをやられてる方、など規模や属性も多岐にわたります。
これまでは弊社の急激な事業成長によって既存システムをスピード重視で拡張したり、拡張しきれない部分はユーザーのプロセスを当てはめたりしているいびつな部分もあるため、既存の業務プロセスにはとらわれずに新しい業務プロセスをも設計していくことが求められています。
そのため、それぞれのペルソナを設定して業務のシチュエーションを想像しながらメンバー間で議論を重ねることで理解を深め、これから作り出す機能に反映していきたいと思います。
インクリメンタルな開発
アジャイル開発を説明する上で有名なイラストを共有しておきます。（出典）
今回のPJについては現在見えている範囲でも足掛け2年を想定しており、ファーストリリースまでも数ヶ月以上開発するような長期プロジェクトです。
また、前述の通り業務プロセスなども設計し直すために事前に正確な見積り（あらゆるプロジェクトにおいて世の中に正確な見積もりなんて無いと思ってますがそれはまた別のお話）やスケジューリングができないため、不確定要素が多いです。
このような長期プロジェクトの場合切れ目が見いだせず、長期の設計、実装フェーズその後にまとめてテストフェーズという形で置いてしまうと検証（例えばユーザーやPdMなどに見せたり）が後ろの方、リリース直前によってしまい、そのタイミングで設計の破綻（例えば仕様バグ）が見つかったり変更を余儀なくされてスケジュール遅延につながったり品質問題につながったり、、など非常にリスクが大きいと思います。
そのためリリースまでにもいくつかフェーズを分けた上で最低限一貫して動き業務が行えるようなアプリケーションをまず作って検証する、そこから次の段階の機能追加（これもきちんと動くものとして完結するもの）して検証する、また次の機能追加…
という形で進めていくことが必要になります。
自動車の例だとスケボー作って短い距離の移動手段としての有効性を確認した後にハンドル付けてペダル付けて自転車にして更に拡張して…ということですね。
完璧なタイヤと車軸だけ作っても求めてる価値である移動手段として確認できることはほとんど無いですので。
機能の優先順位付けとスコープを区切ることを俯瞰して見られることはユーザーストーリーマップの利点ですのでそこを生かして行きたいと思います。
複数人の目で抜け漏れ少なく
ユーザーストーリーマッピングは参加型で会話を促すことが非常に重要で、複数人でワークする場合それぞれの経験、バックグランドなどが違い色々な視点から見ることができるため、個々人では気づかない観点での意見が集まります。
それを共有していくと結果的に抜け漏れが少なくなし、共通理解が深まることで全員のドメイン知識レベルの向上にも繋がります。
例えば一人で要件定義、機能設計するのに比べるとかなり抜け漏れがなくなると思います。 （時間はかかりますが効率は高いかと）
イメージは線を重ねていってメッシュの網目がどんどん小さくなって隙間がなくなるような感じです。
進め方
基本的にはユーザーストーリーマッピングの教科書的な進め方をしていますが一部変えている部分もありますので、共有します。
参加者
現時点で体制上このプロジェクトに関わっているメンバーは基本的に全員参加しています。
具体的にはエンジニア（FE、BE）、要件定義チーム（PM、ドメインマスター）、QAなどになります。
UXデザイナーに関しても体制の関係（フルタイムメンバーではない）で現在はできておりませんが調整中です。本来はUXデザイナーむしろ必須なくらい参加してもらう価値が大きいと思いますので。
ビジネスサイド（営業、カスタマーサクセスなど）のメンバーについては時間の調整などが難しく一部機能のみ参加してもらってる形になります。
ツールについて
- 今回ストーリーマッピングにはFigjamを利用しました。
付箋機能があり、名前が自動でついたりしてたり、タイマーがついていたりとストーリーマッピングのワークショップに適した機能が多く使いやすいです。 - 会議は基本的にはリモートなのでGoogle Meetを使っています。病欠や予定休などで欠席したメンバーのキャッチアップのために毎回録画をしています。
- その他のドキュメントについては弊社ではAtlassianのConfluenceを標準ツールとして使っていますのでそちらを活用しています。
ユーザーのペルソナを出す
例えば今回作るあるシステムのユーザーである事業者について、詳細なペルソナ設定を行いました。
ストーリーマッピングのワークショップ時になるべく想像が付きやすいように実際の業務に関係ないところまで設定してます。
こちらについては事前にパートナー業務に詳しい社内メンバーなどへのヒヤリングを元にPMの方で準備してくださいました。
ペルソナの行動の洗い出し（グループワーク）
上記のペルソナをもとにメンバー全員で集まってペルソナの「行動（アクティビティ）」を洗い出しました。
「[ペルソナ]さんが◯◯を◯◯する」といった形式で付箋を貼っていきました。
最初は粒度が合わないのですが、何回か繰り返すうちに勝手がつかめて粒度が揃ってきます。
その場でグルーピングしたり、一度持ち帰ってPMがグルーピングするなどしてユーザーの行動のバックボーンを洗い出します。
ストーリー洗い出し
前のグループワークで洗い出せた行動を元にして、それらの行動をするために必要なストーリー（≒価値≒機能とも言われると思います。ここは色々な呼び名があるようです。）を洗い出しました。
こちらは「◯◯を◯◯できる」という書き方で付箋を出しています。
こちらは行動の粒度によっては「◯◯する」がそのまま語尾を変えて「◯◯できる」となるケースもありますがより詳細に「◯◯する」ためにはこういった機能がいる、を洗い出して行きます。ここはそのまま機能につながるくらいの粒度で出して行きました。
こちらは簡単に同じものをまとめるところまでを行います。
例）
- 行動
- 「ダイビングショップのAさんが商品を一覧から選択する」
- ストーリー
- 「商品を一覧で表示できる」
- 「商品を商品名でソートできる」
- 「商品を商品名で検索できる」
- 「...」
ストーリーの優先順位付けとスコープ決定
その後洗い出せたストーリーについて優先順位への並び替えとファーストスコープの決定を行いました。
ファーストスコープについてはまずは「動くことを確認する」ものとして必要最低限の機能をPM主導のもと全員の同意を持って決めていきました。
セカンドスコープ以降は現段階だと洗い出すものが難しいため一旦「動くことを確認する」のに必要なものとそれ以外という形で分類しています。
追って次以降の開発の見通しが見えて来た段階で決めていく想定です。
結果ある機能のユーザーのプロセスについて下記のようなマッピングになりました。
ストーリーのタスク化
次にこれらのストーリーを作業タスクとして置こしていきます。
プロジェクト管理ツールとしてJIRAを使ってるので基本的にはストーリーごとにJIRAのエピック（配下にタスクをおける概念的なククリとして）を置こしていきました。粒度によっては複数のストーリーを束ねて一つのエピックとして置こす場合もありました。
付箋ではストーリー（機能）について一言で簡潔にかかれていますが、その機能を実点するために裏に様々なタスク必要になるので、エピックを担当者に割り振り、そこから必要なタスクへの分解をしてJIRAチケットとして作成してもらいます。（ここに設計、実装、QAやその他必要な作業が現れてくるイメージです）
良かったこと
業務理解とアウトプットが同時にできる
設計書で文章や表で書いてある業務要件だと個々人のドメイン知識や経験の違いによって理解レベルが異なってしまいますが、ストーリーマッピングをすることによって全員でワークショップで手と頭を動かしてディスカッションをすることで理解を深めつつアウトプットを作ることができました。
抜け漏れが見えた
先行してRDRA整理や要件整理を進めていたドメイン知識が深いメンバーから見ても気づけなかった観点などがメンバーの付箋から出てきたりするケースもありました。
むしろ既存システムなどに引きづられない新規メンバーなどの目線で見ることであぶり出される観点などもあるので良かったです。
RDRA定義と照らし合わせることで補完しあえる
ユーザー目線のストーリーマッピングとモデルベースのRDRA定義をあわせることでお互いの抜けを補完する事ができることがありました。
例えばストーリーマッピング中にRDRAで整理した業務フローから抜けていたパターンに気づいたり、逆にストーリーマッピングした結果、RDRA定義の変更が必要になったり相互にブラッシュアップすることができています。
こちらに関してはどこまでリンクしていくのかなど課題はありますので今後も開発を進める中で進め方を改善できればと思います。
オンラインの環境でのコミュニケーションが活発化した
弊社は基本的にはエンジニアはフルリモートで開発を進めています。
そのため通常の開発だと基本的にはチャットベースのコミュニケーションとなり、必要な際に必要なメンバーで集まってコミュニケーションということが多くなりがちです。
一方ストーリーマッピングは全員が一同に会した上でほぼ強制的に自分の考えや意見を書いたり喋ったり、他の人に質問したりすることになるため、必然的に会話量が増え、そうすると個々人の考え方や人となりなどがわかるようになります。
結果的に新規メンバーが多い体制ですが、チーム内での心理的安全性が生まれたことを実感しています。
遠方からのリモートだったりして一度もリアルで合ったことが無いメンバーも何人かいるというのが改めて驚きです！
改善点、その他感じたこと
ストーリーマッピングについての説明が不十分だった
ストーリーマッピングをやったことがあるメンバーがそこまで多くなく、意図や目的、ストーリーの粒度ややり方などがイメージできなかったり意図がうまく伝わっていなかったと思います。
今回やるぞ！と決めてからやるまでは本当に数日で一週間無いくらいでしたが、もう少し丁寧に必要であれば全員オライリー本読む、であったり勉強会を行うなどしても良かったかも知れません。
時間がとにかく多く取られる
多くのメンバーの時間を週に数時間単位で拘束するわけなので（現在だと例えば5、6時間をメンバー20人）とにかく多くの時間を使います。
こちらプロジェクト初期ということもあり全員の認識合わせることが重要なため、無駄にはなっていないと思いますが、スケジュール上だと本来は実装を始めているはずのフェーズに時間を取って行ってる状況です。
予めスケジュールにこの時間を想定して組み込むなどは本来は必要だったと思います。
RDRAやUIデザインなどとの関係をどうするべきか
今回はRDRAとUIデザインを先行して始めた上で後追いでユーザーストーリーマッピングを始めましたが
その結果手戻りなどもある程度ある状況なのでどういう棲み分けにするべきなのかは今後の課題として追って考察したいと思っています。
ユーザーストーリーから初めてそれをベースにRDRAのモデル定義などを実施するべきだったのかどうかなどはまだ考えられていません。
今回は既存の業務や事業ドメインが複雑で大きなものになっており、 そちらの分解や整理がRDRA要件定義で事前に出来ていたことでストーリーマッピングのがスムーズに行きました。
RDRAとストーリーマッピングは補完しあえて、うまくそれができると設計をより強固にできるものだと感じますので接合点を意識していけると良いなと思っています。
また、UIデザインについてはある程度手戻りになったものの（ストーリーマッピングの結果UIの構成や順序が変わったりした）デザインが合ったことでイメージが付いて議論が出来た部分もあるので、一概にデザインがストーリーマッピングの後で有るべきかどうかは議論の余地がありそうです。
ここは並行して一緒に育てていくべきものなのかなと個人的には感じています。
会議のファシリテーション難易度が高い
今回はPMのSさんが主にファシリテーションしてくれています。（いつもありがとうございます！！）
ストーリーマッピングは基本的には発散させてから整理して収束するような作業になると思いますが、個々の意見を書き出した付箋はどうしても粒度や観点が違ってくるため、それをその場で整理しながら進めていくのはかなりファシリテーション難易度が高いと思います。
数時間の会議の最後ではPMが疲弊しているのが見えます（笑）
ここについては作業を繰り返すことでメンバーが習熟して、付箋の内容や粒度が洗練されていくことで少しやりやすくなっているようにも見えます。
メンバーがこの手法に慣れてポイントを掴んでいくことによってスムーズに進むようになり、ゆくゆくはそちらを理解したメンバーがファシリテーションもできるようになっていくと社内でより広くこの手法が浸透できるようになるのかと思います。
今後の展望
ストーリーマップを恒久的なドキュメントとして引き継ぎたい
これまでだと大きな模造紙で実際の付箋を貼っていったものをオフィスに置いておいて見返す、などで一度行ったものを編集するなどはかなりハードルが高く、（だんだん剥がれていったりしましたねw）結果的に使い捨てになってしまうことも多かったと思います。
この点、Figjamなどのツールによって成果物がオンラインで共有できるようになったことはかなり大きいです。
成果物としてのストーリーマップを恒久的なドキュメントとして、プロダクトのストーリーを語り継ぐ道具として使えると、例えばメンバーが増えたりリリース後にチーム編成が変わったりした場合でもそちらを元にストーリーベースで共有することができます。
設計ドキュメントベースでそれらを行うことに比べると認識のズレが少なくなることが期待されます。
ビジネスサイドも巻き込みたい
一部機能では実際のパートナー業務ドメインに精通したビジネスサイドのメンバーにもユーザーストーリーマッピングに参加してもらっています。
そういったメンバーからエンジニアサイドでは把握していなかった業界の商慣習や必要な要件が出てくることが多く、非常に有効性を感じています。
今回のプロジェクトのような業務プロセス改善や変更も念頭に置いていたり、アプリケーションの使い勝手が大きく変わる可能性のある開発プロジェクトの場合、慣れているオペレーションの変更で効率が下がることなどに対して運用の現場から抵抗や反発が一定あると思います。
また、導入を推進する営業から見た時に、実は売りにしてた機能が変わってしまって困ると言われるような事態も想定されます。
そのためにも早い段階でまずは社内から共通認識を持ち、社外のパートナーなどに対しても早いうちに変更を開示して準備をしておいてもらう必要がありそうです。
適切なタイミングでビジネスサイドをストーリーマッピングの作業に巻き込んでストーリーを確認することでそういったリスクを減らして行ければ良いと思います。
まとめ
今回はアソビューのとあるプロジェクトで始めたユーザーストーリーマッピングについてご紹介させてもらいました。
ユーザーストーリーマッピングはシンプルですがチームでアジャイル開発をするにあたって非常に有効なツールだと思います。
細かい手法は会社やチームによって柔軟に変更できるため、様々であり今回紹介した進め方も他社やチームにとって有効かは分かりません。
チーム規模やプロジェクト特性によって進め方は柔軟に変更できると良いとは思いますが、その際の参考としてもし弊社の事例が役に立つとありがたいです。
アソビューではアジャイル開発を基本として今回のような様々なツールや手法を柔軟に取り入れながらユーザー目線のプロダクト開発を行っています！ そしてそんなアソビューでは一緒に働くメンバーを大募集しています！ カジュアル面談もありますので、少しでも興味があればお気軽にご応募いただければと思います！
