要件定義は"切り分け"。要求と要件、理由まで示す
日頃KSRで活躍されている池さんに、KSR SS事業部責任者の丸山がインタビューを行いました。
Q：率直に、"要件定義って何ですか？"って聞かれたら、どう答えますか？
うーん…確かに、いきなり聞かれると難しいですね。すごく抽象的に言えば、「作るものを明らかにすること」です。作るものが何なのかが曖昧なままだと、どんなに頑張っても完成形がブレますから。
ただ、僕が考える要件定義は、それだけじゃ足りません。要求と要件をちゃんと切り分けて、「なぜこの要件になったのか」という背景や理由も一緒に示すことが大事です。
たとえば「こういう要求があったから、この流れで考えて、この手順を選んだ」という経緯。
そして、要件に含めないものも「こういう理由で外した」と明記します。
もともと僕はエンジニアなので、要件定義書には書かなくても、頭の中ではデータの形や流れまで意識しています。
どこからデータを取って、どう加工し、どう表示して戻すのか。この全体像を押さえておくことが、後のブレを防ぎます。
Q：では要求の部分で特に意識していることはありますか？
要求は必ず言語化して残します。
僕の場合は、いきなり要件定義書から書くのではなく、まず「デザインドック」という形で要求を整理します。プロジェクトの全体像、なぜ発足したのか、何をゴールにしているのか、逆に何はやらないのか──こうした情報をまとめた資料です。
形式はプロジェクトごとに可変ですが、少なくとも自分の中で一度は書き出します。
整理するときは、要件のことはいったん考えないのもポイントです。要求がクリアになって初めて、要件を切る土台ができますから。
Q：過去に要件がなかなかまとまらなかった経験ってどんなことがありますか？
PdMとして入った案件ではあまりないのですが、エンジニア時代はありましたね。
要求が曖昧なまま「これ作って」とだけ渡されて、「これ絶対よくないけど…」と思いながら作ってしまう。そして後から仕様が変わる、というケースです。
特に複雑なドメインだと、全員がドメイン知識を持っていないと要件が揃わないんです。少しずつ理解が深まった時点で「やっぱりこの要件は違ったね」となり、作り直しが発生する。
要件が最初からまとまらないというより、途中でコロコロ変わるほうが厄介でした。
Q：うまくいかないときは要求の目的が不明確なことが多いですかね？
そうですね。要求の目的がはっきりしていないと、要件はブレやすいですし、それをチームに共有していないと問題が広がります。デザイナーやエンジニアからの「この要求なら、もっとこうしたほうが良くない？」という提案が出なくなるんですよ。
そうなると、PdMが考えた要件がチームの限界値になってしまう。結果として、完成品を触ったときに「なんか微妙だね」となり、手戻りが増えるんです。
だから、ジュニアPdMと仕事をするときは、「自分の能力以上のアウトプットが出る状態」を意識させます。チームで働く意味は、みんなの力を借りてより良いものを作ること。そのための要件定義や要求定義の書き方を身につけるべきだと伝えています。
Q：逆に、要件定義がうまくいってプロジェクトが前進した例はありますか？
機械学習が絡むような、少し複雑なプロジェクトでの経験です。
知見がないと要件を切るのが難しい領域だったんですが、僕が要件を切って、紙芝居的なプロトタイプを作りました。するとチーム全体の理解が一気に進み、プロダクトオーナーがやりたいことが明確に共有されたんです。
要求がはっきりしていない場合、先に叩き台となる要件を提示して、それをもとに詰めていくこともあります。
Q：その叩き台のイメージはどんな形で見せたんですか？
当時はFigmaで作りました。モックほど精密ではないですが、動きや画面遷移がざっくりわかるものです。今ならVibeコーディングを使いますね。
その場で「じゃあ一旦追加してみましょうか」と手を動かして、微妙なら元に戻せばいい。
技術検証とプロトタイプ作成を一度にできるのが強みです。
Q：現代における要件定義に必要なスキルって、どのようなものだと思いますか？
要求と要件を正しく切り分けられる理解力は必須です。加えて、データへの理解も重要ですね。システムはデータを取得し、加工して表示し、保存する。この流れを理解していないと、設計がちぐはぐになります。ER図を読めるレベルまでは、チームメンバーにも教えるようにしています。
Q：非エンジニアの事業責任者に、要件定義の重要性をどう伝えますか？
正直、深く理解してもらわなくてもいいと思っています。
お互い専門職なので、役割をリスペクトし合うほうが大事です。事業としての戦略は任せるから、その戦略を信じて走る。
だから、戦略をコロコロ変えないでほしいですってことくらいですね（笑）。
Q：要件が固まっていなくても、システム開発会社に相談していいと思いますか？
もちろんです。それを一緒に明らかにしていくのが専門家ですから。
「要件がわからない」と突き返すような会社は、あまり信用しなくていいと思います。変えちゃいけないポイントだけ一緒に見つければ、十分進められます。
▶ 編集後記
池さんのお話から印象的だったのは、要件定義を「作るものを決める」だけにとどめず、要求の背景までを可視化し、チーム全員が納得して進められる基盤を整える姿勢でした。要求を切り分けて理由を明示することで、後の手戻りを防ぎ、メンバーの主体的な提案も引き出せる。要件定義を一人の作業ではなく、チーム全体の創造力を広げるためのプロセスと捉える視点は、多くの現場にヒントを与えてくれそうです。