- まともなPdMがいない
- スクラムマスター不在
- ステークホルダーに権限がない
- アジャイル経験者0
この状態を想定して、アジャイル開発を行ったことがないチームに対してアジャイルを導入するために、非エンジニアを含めた関係者に開発としてのユーザーストーリーを浸透させるために作った資料です。
システム開発においてのユーザーストーリー？
システム開発向けのユーザーストーリーを今まで作ってこなかった場合、最初につまづくのがここだと思います。
実際にユーザーストーリーはプロダクト全体で見れば使っているはずなんです。
問題はユーザーストーリー自体、事業を起こす場合2種類存在してしまっているということです。
１種類目はマーケティング手法としてのユーザーストーリーは例で書くとこうなりますよね？
- ペルソナの設定
- ペルソナの属性や行動
- 行動を促進するためのキャンペーンや施策
- 行動後ユーザーが得られるメリット
さてと……それじゃぁ、ユーザーストーリーは完璧ですね（？）Qiitaと同等の機能を考えましょう。
- エンジニアは他の人とのナレッジの共有のためにQiitaで記事を書く、それによってhogehogeできるから
さぁこれから、Qiitaの開発をしてください。
Qiitaというサービスの前例があるんでできんことはないですが、一から作るとなると……何もかもが足りません。
そのため、システム開発にはより具体的なものが必要になります。
そのために以下のような情報を具体的に書いてあげる必要があります。
- システムが持つ機能
- 機能操作
- 得られるべき結果
じゃぁQiitaの編集者をペルソナとして記事を書いてみましょう（＊社内で没になったシステム元なので雑です）
- 編集者は記事一覧を見たい、なぜなら自分の投稿を探すためだ
- 編集者は記事を作成したい、なぜなら読者に記事を提供するためだ
- 編集者は記事を確認したい、なぜなら記事の脱字などを確認するためだ
- 編集者は記事を編集したい、なぜなら誤解を生むような記事はー謝罪しないか別に
- 編集者は記事を削除したい、なぜなら都合の悪い記事を抹消するためだ
これだと、一覧がページネーション必要か削除は論削なのかなどの詳細情報が入りません。
そのためここからユーザーストーリーのマッピングを行う必要があります。
ユーザーストーリーマッピング
1. ユーザーストーリーを抽象化
せっかく作ったユーザーストーリーですが、重複が見られるのでいったん抽象化しましょう。
おおまかにわけると、一覧と投稿機能に分けられると思います。
面倒臭ければユーザーストーリーじゃなくいきなりここ書いてもいいんですが……経験積まないといきなりやるのは難しいので今回は手順を踏んでいます。
2. タスクの設定
ユーザーの行動には必ず何らかの目的……タスクが存在します。それを書きだしましょう、例えば記事を管理したいにまとめられた、作成、編集、削除等ですね。
先ほど「システム開発においてのユーザーストーリー？」のところで語ったユーザーストーリーになりましたね。
ここから必要な処理を細かく切り出していきましょう。
3. 詳細なストーリー
ここからなんですが、各タスクで必要な処理を適当に書き殴っていきましょう。思うままに書いてください、見返してここ同じだったなとかで消してもいいので。
私も稀に、元々のユーザーのタスク自体が足りなかったなとかありますので（実話）
正直編集系は編集系でまとめた方がいいんですが……なんか縦に長くなるの嫌だなぁって理由で横に並べています。ここは伝わればいいので端折っていない限りで言えば、好みでいいでしょう。
さて……処理の推定がより詳細になることにより、優先順位づけやどういう処理があるかなどの合意や共有ができるようになるのではないでしょうか？
ですが、書いていくと必ずこんなにいっぺんに開発できないよーってなる時が稀によくあります。
リリーススコープを定め、段階的なリリースにするパターンですね。
その場合、優先順位の高い順に処理を並び替えましょう。
リリーススコープ
非エンジニアが主導権を取る場合、どうしても１画面を完璧に仕上げようとしてきますが、それはアンチです。
私の経験したのは……例えばこんなんとかですかね？
なんだこの気持ち悪いリリーススコープ、レバーにきますね。実際にスコープわけするとこうなります。
優先度が高くかつ、まとまった単位でリリースするのが本来の意味のスコープわけですね。
最後に
共有できるのであれば、タスクに分解するのと必要な処理書きなぐるだけでもいいかと思います。よっぽど天才でもない限り慣れていないのに一発で書けるとかはまずないので地道に一歩一歩書いていきましょう。
ここら辺はプロダクトとエンジニアとの約束事でもあるので、たまにいるのが「俺がわかるから」で端折ってしまうと一人開発の一人プロジェクトなら何とかなりますが複数名だと「私はこう思っていた」でこじれるのでやめときましょう。
一般的だからの思考も危険です。一般的だと感じているのが業界的慣習の場合……業界未経験のやつはわからんし自分が一般的だと思い込んでいるだけなので普通に教えるの忘れるし、中核メンバーがごっそり消えると仕様自体が遺失する危険性も上がります。考えるだけでレバーにきますね？