今年度、約1年間の育児休暇から職場復帰した。

復帰したばかりの私は役立たずで、私の仕事はとにかく「慣れること」であった。
何かチームの役に立ちたい、自分だけ取り残されたプロジェクトのことをもっと理解したい、そんな思いで取り組んでみたのが「ユーザーストーリー」だった。

ユーザーストーリーとは

ユーザーストーリーは、システム開発時に「なぜその開発を行うのか」、その背景を記述することでチームメンバーと共通理解を得るためのものだ。

『ユーザーストーリーマッピング』には、ユーザーストーリーのテンプレートが紹介されている。

 [ユーザータイプ]　として
私は　[これこれの結果を得る]　ために、
[これこれ]　をしたい。

[図書館の利用者]　として
私は　[新しい本を取り寄せる]　ために、
[図書の予約システムでリクエスト]　をしたい。

といった具合だ。

良かったこと

「書き出す」ことで、自分がどこがわかっていないのか、チームにとってどこが不明瞭だったのか、明確にすることができた。
絵を描くのも良いかもしれないが、あいまいな部分をより浮き彫りにするためにもまずは文章化することをお勧めしたい。

また、ユーザーストーリーという取り組みを通すことで、遠慮なく疑問点をチームにぶつけることができるのも良かった。
今まで見過ごされていた問題に対し、「これはどういうことですか？」と質問を投げかけることで話し合いが始まり、漠然としていた仕様が明らかになっていくこともあった。

機能の洗い出しはできているつもりでも、いざ開発に入ると意外と抜け漏れがあるものだ。
ユーザーストーリーは、そんなプロジェクトを俯瞰して見るきっかけになった。

悩んだこと

書いていくうちに、ストーリーの粒度がバラバラになっていくのに悩んだ。大雑把だったり、細かすぎたり・・・。

しかし『ユーザーストーリーマッピング』にはこう記述がある。

ストーリーは要件ではない。会社、顧客、ユーザーが抱える問題の解決についての議論であり、何を作るかについての意見を一致に導くものだ。

ユーザーストーリーには3C【カード（Card）、会話（Conversation）、確認（Confirmation）】と呼ばれるプロセスがあるが、カードに書かれる文章は要件ではなく、会話へのきっかけになるものだ。

たとえ粒度がバラバラであっても、それを会話と確認につなげることができたのであれば、十分意義があったと思う。

さいごに

育休からの復帰は2度目である。
2度目でも不安は不安だったし、復帰してからも自分のふがいなさに自己肯定感は下がるばかりであった。

しかし「ユーザーストーリー」という取り組みは、そんな私だからこそできたものかもしれない。
仕事をしていると、堂々と疑問をぶつけるということはなかなかしにくいものだ。
途中からプロジェクトに参入した私だからこそ、この取り組みの中でわからないことをわからないと言えたし、それをきっかけに問題の発見へとつながることもあった。

ひとりで悩んでいてもモヤモヤはモヤモヤのままだ。
チームと会話し、確認し合うことが、私たちが何をつくるべきかの道標となる。

プロジェクトを進める上でチームとの理解にギャップを感じたら、ぜひユーザーストーリーを活用して共通認識を深めてもらいたい。