こんにちは。配配メール開発課のwnwtt17です。
今回は配配メールチームの要件定義の進め方についてお話ししようかなと思います。
少し前に要件定義の進め方を変更し、とても作業を進めやすくなったので参考になればと思います。
今までの進め方
配配メールチームではエンジニアとデザイナーが協力して要件定義を進めています。
作業の流れは以下の通りです。
①エンジニア側で要求仕様の理解
②要件定義書に落とし込んでいく
③デザイナーにUIの作成を依頼
しかし、この流れだとどうしてもエンジニア主体になってしまい
デザイナー的な視点（UXの観点など）がなかなか取り入れづらいという状態でした。
新しい進め方
エンジニア・デザイナー両方の視点を取り入れていきたかったので
少し前に以下の進め方に変えてみました。
①エンジニア・デザイナーともに要求仕様の理解
②それぞれで作業を進めていく
・エンジニア：開発的な視点で、どういう機能が必要かなどを考えていく
・デザイナー：UI的な視点でペルソナやユーザーストーリーを考えていく
③お互いの成果物をすり合わせる
④デザイナー側ですり合わせた成果物をもとにUIを検討する
⑤作成してもらったUIをもとに要件定義書を作成していく
上記の流れに変えたことによって、良かった（助かった）点があったので紹介しようと思います。
エンドユーザーの気持ち…？
上記の進め方に変更後、初めての案件がなかなかの強敵でした。
その案件では、配配メールを利用するお客様だけではなく、
その先のエンドユーザーの視点でもUIを検討する必要がありました。
今までは、配配メールを利用するお客様のみが利用する機能ばかりだったので
エンドユーザー的な使いやすさなどがエンジニア側では分からない状態でした。
しかし、デザイナーが要求仕様からどんどん参加してくれるようになったので
特に困ることもなく、UIの作成がスムーズに進んだのでとても助かった記憶があります。
また、ペルソナやユーザーストーリーをきちんと作成してもらったので
今まで気付けなかった視点（この操作はユーザーには難しすぎるんじゃないか？など）も盛り込むことができ、
より良い要件定義になったと感じています。
最後に
やり方をガラッと変えたことにより、最初はうまく進まなかったところもありましたが、
お互いがサポートし合うことによって、よりよい要件定義を完成させることができたと思っています。
はじめての案件で作成した機能がもうすぐリリースされるので、
多くの人に「使いやすい」と思ってもらえるといいなと今からワクワクしています。
最後まで読んでいただきありがとうございました。
