新卒エンジニアが手戻りだらけの要件定義から学んだこと

はじめに

こんにちは。新卒3年目のymyhero7です。

メールディーラーという自社開発プロダクトの開発チームに所属しています。

入社してすぐの頃は、実装やテストの工程を担当していましたが、新卒2年目から徐々に要件定義を任されるようになりました。もともと就職活動の面接段階から、「どうすればお客様にとって本当に価値のある機能を作れるか」といった上流工程への関心が強く、そうした業務に携わることを希望していました。 そのため、2年目という比較的早い段階から要件定義に関われるようになったときは、非常に嬉しかったのを覚えています！

しかし、意気揚々と始めた要件定義の業務は、想像以上に難しく、苦労の連続でした。作成した要件定義書はレビューで指摘を受けることが多く、大幅な手戻りが発生してしまうことがしばしばありました。

本記事では、そうした経験を通じて学んだ要件定義の進め方のコツや「顧客理解」の重要性をご紹介します。

苦戦した要件定義と、繰り返される手戻り

私の所属する開発チームでは、製品企画チームが作成した要求定義書をもとに、「要望をどのような機能に落とし込むか」を要件定義で検討します。

要件定義を担当し始めた当初、私は「要求定義書に書いてあることをそのまま機能として具体化していけば問題ないだろう」と安易に考えていました。 しかし、実際に書いた要件定義書は何度もレビューで差し戻されました。

特に多かったのは、
「そもそもその機能、本当に必要？」
「他にもっと良いアプローチがあるのでは？」
といった、本質を問う指摘です。

「確かにその通りだ」と納得する一方で、「なぜ最初から気づけなかったのか」と悔しさが込み上げました。さらに、手戻りによって開発が2週間以上遅れることもあり、チームに迷惑をかけてしまったことへの申し訳なさも強く感じました。

振り返ると、その原因のひとつは、要求を表面的にしか理解できておらず、ユーザの本当の困りごとやユースケースを自分の言葉で説明できない状態だったことにあります。 “何を作るか”ばかりに意識が向き、“なぜ作るのか”という視点が欠けていたのです。
この状態では、いくら丁寧に要件定義書を作成しても、ユーザの課題を解決できる良い機能を作ることはできません。 結果として手戻りが発生し、開発の遅延を招き、ユーザへの価値提供も遅れてしまいます。

チームで取り組んだ改善

そんな中で支えになったのが、周囲のチームメンバーの存在です。

失敗に落ち込んでいた私に対し、先輩たちは「まずは製品企画チームに要求の背景を聞いてみよう」「最初にチーム内で機能の方向性をすり合わせるミーティングを開こう」など、具体的で実践的なアドバイスをくれました。
ある先輩エンジニアからは、「完璧にしてから出すのではなく、途中でもいいから一度レビューを依頼してみよう」と助言をもらい、「しっかり仕上げてからでないと見せてはいけない」と思い込んでいた自分の固定観念が変わりました。

また、チームの振り返りミーティングでは、「どうすれば手戻りを減らせるか」について皆で何度も話し合いました。その中で、要件定義に入る前にチーム内で要求を読み合わせ、疑問点を洗い出したり、要件の方針をすり合わせたりすることが、開発プロセスとして明文化されるようになりました。

顧客ヒアリングを通じて得られた気づき

あるとき、特定の機能要望について製品企画チームに質問したところ、「それなら実際にお客様に聞いてみよう」と、要望を挙げてくださったユーザに直接ヒアリングする場を設けてくれました。 普段はユーザと直接やりとりする機会がなかった私にとって、ユーザの声を生で聞くことができるのは初めての経験でした。

直接お話を伺う中で、「ああ、これが本当に困っていることなんだ」と心から腑に落ちました。また、製品に対する強い期待や信頼を寄せていただいていることも実感し、より一層の責任感が芽生えました。

それまで私は、製品企画チームは別部署ということもあり、「どこまで相談して良いのか」と遠慮してしまうことがありました。ですが、こうして顧客ヒアリングに同席させてもらえたことで、「分からないことは積極的に相談して、一緒に解決に向かって進めていけばいいんだ」と認識が大きく変わりました。

実践している3つの工夫

こうした経験を通じて、私は以下の3つのポイントを意識しながら要件定義を進めています。

1. 製品企画チームに質問して、ユーザの解像度を上げる
   「なぜこの要望があるのか？」「実際にどんな場面で困っているのか？」といった背景を把握するため、製品企画チームに積極的に質問するようにしています。要求を深掘りし、ユーザの抱えている課題を自分の言葉で語れるようになることを目指しています。

2. まず方針をすり合わせる
   要件定義書を書き始める前に、「こういう背景があって、こういう方針で考えています」とチーム内で方向性を相談しています。すぐに要件定義書を書き始めるのではなくて方針が定まってから手を動かすようにしています。また、要件定義書を書き始めてからも、課題があればその都度相談し、徹底的に認識合わせをするように意識しています。

3. 6割の完成度でレビュー依頼を出す
   要件定義書は、完璧を目指すよりも6〜7割程度の段階で一度レビュー依頼を出すようにしています。そのほうが早期に改善点を洗い出すことができ、結果として手戻りを減らすことができます。

おわりに

弊社の開発チームでは、「顧客志向」を非常に大切にしています。ユーザへの理解を深め、どのような機能であれば真に価値を届けられるのかを考えることは、その顧客志向の姿勢そのものだと感じています。
また、ユーザへの理解が深まることで、結果的に要件定義工程での手戻りも減り、早く価値を届けられるという好循環が生まれると考えています。

もちろん、要件定義は今でも難しいと感じることがたくさんあり、すべてが順調に進むことはありません。それでも、一つひとつのユーザの課題に真剣に向き合っていくことが、より良いプロダクトづくりにつながると信じています。

最後までお読みいただき、ありがとうございました。