要件定義は"誰の・何を解決するか"を貫くプロセス。ペルソナ起点でブレを断つ
日頃KSRで活躍されているIshikawaさんに、KSR SS事業部責任者の丸山がインタビューを行いました。
Q：Ishikawaさんにとって要件定義とはって言われたら、なんて説明されますか？
そうですね、要件定義って何て言うんですかね、結局は「何を作るか」だと思うんです。
じゃあ何を作るかって突き詰めていくと、「誰の、どんな課題を解決するか」に行き着くんですよね。だから僕の理解としては、そこを明確にしていくためのプロセス。それが要件定義なんじゃないかなと捉えています。
Q：この中でひときわ大事にしているものって何かありますか？
やっぱり「誰の？」っていうところですね。
結局、そのシステムやソリューションを実際に使う人が誰なのか、どうやって使ってもらえるのかが価値を決めると思うんです。
プロジェクトを進めていくと、いろんなステークホルダーや登場人物が出てきますよね。だからこそ、それぞれの立場の帽子をかぶって考える必要があるんです。「利用者にとってはこう」「現場担当にとってはこう」といった具合に。
誰の課題に焦点を合わせるのかを切り分けて意識することを、常に大事にしています。
Q：そうすると、出来上がったものが結局誰に使われて、その人の何を解決するんだっていうところの焦点をぶらさないみたいなところですかね？
そうですね。登場人物ごとに視点や観点が変わってくるので、そこをバランスよく見ていかないと「解決すべき課題」がどんどんズレていっちゃうんですよね。
だから常に「誰の課題か」という意識を持って、焦点がブレないようにしています。
Q：要件がなかなかまとまらずに苦労したことと、その時の原因やどう打開したかとかいうご経験を教えていただけますか？
プロダクト定義の話にも近いんですけど、海外の物流系スタートアップに関わったときです。
最初に出ていたアイディアは「テクノロジーベースでこんなことができる」っていう、いわゆるプロダクトアウト寄りの発想でした。でも、ユーザーさんにヒアリングしていく中で、現場の課題とは全然合っていないことがわかってきたんです。
ニーズのギャップが大きすぎて、当初のアイディアをそのまま進めても刺さらない。そこで、ほぼアイディアの根本からピボットしていく必要が出てきて…これは本当に大変でしたね。
課題とソリューションのズレをどう埋めていくか、アイディエーションを繰り返しながら方向転換していくプロセスはかなり苦労しました。
Q：自社だけでなくクライアントサイドにインタビューしなきゃいけないのもちょっと大変ですね。
加えて投資家の期待像ともズレていたのも難しさでした。
投資家の描くソリューションと現場ニーズの間をどうアジャストするか。要件定義だけでなく"合意形成の設計"も同時に走らせる必要があり、別軸の調整にかなり時間を割きました。
技術だけじゃなく関係者の期待値をマネジメントする苦労もありましたね。
Q：マーケットが求める解決策の部分でズレがあって難しかったことについては、どんな工夫で前進しましたか？
やっぱり"ユーザー理解"に尽きますね。
幸いお客さんと直接つながりがあったので、実際に倉庫に行って業務を観察して、現場の人に徹底的に聞いて回ったんです。「どういう業務フローで」「どこに一番のペインがあるのか」を掘り下げて、その場でアイディアをぶつけては反応をもらう。
これを繰り返す中で、少しずつ現場のニーズに寄せられたソリューションの形が見えてきて、プロダクトを軌道修正できました。
Q：やっぱり近道はなくて、聞いて当てての繰り返しですか？
そうですね。結構アイディア的にも難しいところがあって、企業戦略の3Cの中でどこにウェイトを置くかみたいな部分で、自社に何ができるかという観点を大きくしてしまうと、やっぱりマーケットニーズとずれが発生してしまうので、そのところにまずフォーカスして、その次に自分たちに何ができるのか、競合は何をやっているのかというようなアプローチのプロセスが必要なのかなというのはその時学びました。
Q：逆に要件が明確になってプロジェクトがすごく前進した経験はありますか？
プロジェクト自体は最終的に成功とまではいかなかったんですけど、「ニーズを捉えて前進できた」という点では得られたものもあります。
ユーザーのペインをしっかり掴めたことで、プロトタイプを作って実際に現場で使ってもらったんです。すると「これならいけそうだね」という手応えをもらえて、それをベースに開発に進められた経験がありました。残念ながら事業としてはビジネス面で別の要因があって成功しなかったんですが、プロダクトの筋自体は悪くなかったと今でも思ってます。
要件定義をちゃんとやってユーザーの課題に寄せられたことで、少なくとも前進感は得られました。
Q：ペイン把握・インタビュー・プロトタイプの3点がポイントってことですかね？
その3点に尽きます。加えて私はデザインスクール出身なので、デザインシンキングの「課題発見⇄ソリューショニング」を高速で往復します。重い実装は避け、Figmaや簡易モックでコストを抑えつつ理解を合わせる。
これだけで意思決定の質が上がります。
Q：機能名を見てもピンとこないような非エンジニアの責任者と話すときの工夫ってございますか？
まずは「絵を見せる」ことですね。
文章や機能リストだけではなかなか伝わらないので、モックやプロトタイプを見せることで共通認識が生まれる。加えて大事なのは、彼らが本当に気にしている"ビジネス課題"にちゃんと応えること。たとえば「このソリューションでKPIがどう改善するか」「ROIはどう変わるか」など、具体的な数値のインパクトのイメージを持ってもらうことです。その上で、もう一段下のレイヤーとしてユーザー体験のインパクトを伝える。
つまりビジネス的インパクトとUX的インパクト、この両方を整理して伝えることを意識しています。
Q：要件定義で大事なスキルや視点とは改めて何でしょうか？
テクニカルスキルよりも"ビジネス理解"が大事だと思っています。
要件定義って結局コミュニケーションの積み重ねなんですよ。その中で信頼関係を築くには、相手の業務を理解していること、そしてビジネスの共通言語で話せることが重要です。
技術的な専門用語を振りかざすより、「業務フローがこうだからここに影響する」とか「KPIにこう効いてくる」といった形で伝えるほうが断然伝わりますし、コンセンサスも取りやすいです。
Q：定義・設計・ドキュメント化で気をつけているポイントってありますか？
可視化第一。小さな議論でもメモや図を共有し、書いているところをその場で見せます。
ヒアリング前には"叩き"の業務フロー図を用意して、MTGの場では認識があっているかの確認に集中できるようにする。
言葉だけでの合意は誤差が大きいので、必ず図に落とします。
Q：要件定義を行うにおいて、外注か内製ではどちらを勧めますか？
理想は内製ですね。自社のビジネス理解も深いし、コミュニケーションコストも少ない。
ただ、要件定義をちゃんとできる人材って現実にはすごく少ない。しかも内製だけだとバイアスがかかるリスクもあります。
だから現実的には外部の視点も取り入れた方がいいと思います。事業責任者の思い込みを補正する意味でも、外注は十分メリットがある。
バランスをとるなら外部と内製のハイブリッドがいいかなと思いますね。
Q：Ishikawaさん流の"要件定義テクニック"ってございますか？
ヒアリングでは「クライアントに決めてもらう場」を設計します。
叩き台や論点を用意し、あえて"隙"を作って議論を誘発させる。そこで出た本音が、仕様の肝になります。
フレームワーク過多は本末転倒なので、基本は5W1H。特にWhyとWhoを外さなければ、残りは枝葉で整えられます。
Q：事業責任者がエンジニアに指示しているが、5W1Hが未整理だった場合はどう対応します？
まずWhoから。想定ユーザーを洗い出し、ペルソナごとのWhyを言語化します。
するとWhatが自然に現れます。さらにWhen/Whereのシーンを具体化し、価値の出る使用状況を描く。
ここまで行けば、仕様の粒度も合ってきます。
Q：事業責任者は忙しいことも多いかと思われますが、長期戦を覚悟していますか？
前提知識が少しでもあれば、2〜3回のセッションで"大枠の認識合わせ"までは行ける感覚です（おおよそ2週間以内）。
その後は現場担当を巻き込んでディテールを詰める。全く新規領域なら、事前リサーチのフェーズをちゃんと置きます。
Q：要件定義に悩む非エンジニアの新規事業責任者へ、なにかアドバイスするとしたらなんて伝えますか？
「ユーザーを見ろ」っていう一言に尽きます。
今の技術でできることから考えると、だいたいズレるんですよね。ズレるのは別に悪いことじゃなくて、そこから解像度を上げていけばいい。解像度を上げるってつまり、ユーザーのペインをより深く理解することなんです。結局、システムを作るってことはビジネスを作ることと地続きだから。
だからまずはユーザーを理解することに徹底的に時間をかけてほしいです。
Q：KSRみたいな会社に、要件が固まってないけど相談してもいいと思いますか？
まずは話を聞かせてください。
方向性を決める初期フェーズが一番重要で、ここへの投資が後工程のムダを大きく減らします。ユーザーは誰か／どんなペインがあるか／何を作るかを一緒に整理し、MVPで早く見て学ぶ。そこまで伴走できます。
Q：まず一歩踏み出す、前進することが大事。伴走するしMVP作るし、声かけてくださいという感じですかね？
その通りです。最初から大きなものは作りません。
MVPアプローチでコストを抑え、学習サイクルを早回しする。
その伴走はKSRの得意技ですし、クライアント様にとっても頼りやすい関わり方だと思います。
▶︎ 編集後記
Ishikawaさんの姿勢から強く感じられたのは、要件定義を「仕様づくり」ではなく、ユーザー理解を起点に合意を重ねていく営みとして捉える視点です。ペルソナの課題に立ち返り、現場の声と投資家・経営の期待を丁寧に橋渡しする。その上で、モックやMVPを用いて素早く検証し、解像度を高めていく。この繰り返しこそが、要件をブレさせず、関係者を前進へ導く原動力になっているのだと感じました。