チーム開発におけるプロダクトエンジニアの動き方（要件定義編）

新年明けましておめでとうございます。今年もよろしくお願いいたします。

今回はチーム開発においてプロダクトエンジニアがどう要件定義に関わるかについてまとめます。
この記事はお正月休み明け直前に書いています。なぜこんなタイミングで記事を書いてるかというと正月休みで忘却された仕事のやり方を思い出すためです。

もう少し抽象的な話は過去の記事で書いてます。

TL;DR
要件定義ではプロダクトエンジニアは終始「議論を効率化すること」に徹します。

要件定義の会議は3段階ある

• ヒアリングから仮説を見つけられそうな段階

• 解決すべき問題を文書化する段階

• 作るべきものを文書化する段階

要件定義の会議は一回で終わることはほとんどなく、情報を更新しながら何度か議論されたのちに確定するので自分の中では３段階に分けています。

ヒアリングから仮説を見つけられそうな段階

商談やユーザヒアリングを整理してユーザ体験を向上させることができそうな仮説が生まれそうな状態です。ここではほぼデザイナーとして動きます。議事録を読んだ上で、仮説の素案と似たような価値を提供しているサービスの一部機能を探して会議に挑みます。

「例えばこのサービスのこの画面とかイメージ近いですかね？」

と言えるとベストです。視覚化されたものがあれば会議の参加者で共通認識が明らかに取りやすくなります。
もし類似サービスがない場合は、FigmaやFigjamでリアルタイムで「こんな感じですか？」とイメージを作るムーブができるとベストです。ただし、ここで作ったUIに後々引っ張られないように気をつけます。
「こんな感じですか？」でその場で作ったUIは大体より良いユーザ体験のために改善できます（自分の瞬発力がクオリティ不足なだけですが）。

解決すべき問題を文書化する段階

仮説が固まってきたら細部を詰める段階です。ここでも商談やヒアリングの議事録を参考にしながら、どんな機能で課題を解決するかを詰めていきます。8割デザイナー、2割エンジニアくらいで動きます。コードベースを頭に置いて実現可能性を考えながら、機能の機能が存在した場合の正常系のユーザフローの素案を持って会議に挑みます。

「業務フローのここが対象で、機能が入ることでこのように変化します」

と言えるとベストです。ユーザジャーニー全体の中でどこにフォーカスした機能かを決めると、既存の機能との棲み分けや合わせ方を考えやすくなります。理想のユーザフロー図や20%クオリティくらいのグレースケールのUIが作れると良いです。戒めですが、画面を作り込む前にFigjamで矢印ユーザフローだけでも十分伝わる場合があるので、コスト最安値を狙いたいところです。

作るべきものを文書化する段階

解決すべき課題が固まったら、何を作っていくかを詰める段階です。ここではエッジケースやDBスキーマをイメージしてパターン網羅していきます。4割くらいエンジニアで動きます。データが存在しない場合や極端な量の場合、特定の条件下など思いつくエッジケースとUIイメージをまとめて会議に挑みます。

「このパターンの時はこの画面を表示するのはどうでしょうか？」

と提案できるとベストです。エッジケースは大体話題に上がるのが後になるので、考えないといけないのはわかってたけど考えてなかった場合がほとんどです。ここでUIを見せることができるとやはりイメージしやすいので、自分では発見できなかったエッジケースや要件の見直しに繋がります。
また、期限に余裕があれば複数パターンのレイアウト・見せ方を作って比較できるとなお良いです。レビュワーが「もっとこんな感じで」のアイデアがない場合、可/不可の議論になりがちなのでより良く改善するチャンスがなくなります。

如何に素早く形を見せるかが重要

要件定義は抽象的でアイデアや議論が発散してまとまることなく時間が過ぎがちです。仮でもいいので形を作って見せることで、議論済み・要議論の箇所の区別が付きやすくなり、アジェンダの優先度が決まります。

結果として全体的な会議の時間を減らすことができるのでプロダクトの成長スピードが上がります。クオリティを過去以上にしながら前回の要件定義よりも5%,10%でも早く終えることができないか、を常に考えることが重要だと思います。

まとまらない文章になってしまいました。
気が向いたら開発編・改善編あたりを書こうと思います。