要件定義は"コアバリュー"。優先順位が自然に定まる
日頃KSRで活躍されているMiuraさんに、KSR SS事業部責任者の丸山がインタビューを行いました。
Q：Miuraさんにとって「要件定義」とはどんなイメージですか？
シンプルに言うと、"要件を定義すること"なんですが（笑）、やりたいことを実現するために必要なことを、ちゃんと文章で言語化するっていう意識は常に持っています。単に仕様を列挙するんじゃなくて、「目的に向けて何が必要か？」をきちんと書き起こすのが要件定義なんだと思いますね。
Q：要件定義をするうえで、大事にしていることって何かありますか？
ずっと意識しているのは、「結局、やりたいことって何だっけ？」という視点です。要件定義って、どうしても話が細かくなりがちじゃないですか。だから議論が深まれば深まるほど、そもそもの目的を見失いがちになってしまう。
でも、プロダクトで一番大事なのって"コアバリュー"だと思うんですよ。そこがちゃんと見えていれば、「やるべきこと」「今やらなくていいこと」って自然と整理されてくる。何を解決するサービスなのか、真の目的をぶらさずに持っておくことがすごく大切だと思っています。
Q：とはいえ、その真の目的がふわっとしているクライアントには、どう対応していますか？
ふわっとしてるのって、まあ当然だと思うんですよ。クライアント自身も、まだ答えを持っていないんですから。
なので、僕らの役割はその答えを一緒に見つけていくこと。いきなりMVPを作って最短で突っ走るとかではなく、たとえば仮説を立てて「まずはこの方向で試してみましょう」と提案して、うまくいかなければ次はこうしてみましょう、っていうような。中長期的に検証しながら正解に近づけていく、という道筋を見せるようにしています。
そのときに「軽く作って擦り合わせていく」っていう動きも大事で、仮説の段階から一緒に進めていくことで、比較的クライアントともアラインしやすくなる感覚がありますね。あくまで我々も仮説段階なので、検証はいろいろしていきますという前提で、一緒に伴走するっていうようなイメージです。
Q：最近特に増えてきているように思いますが、アジャイルの中での要件定義について、どう捉えていますか？
昔は、正直アジャイルがあまり好きじゃなかったんですよ。要件定義が適当になりがちだったので。でも最近は逆に「作ってから要件を深める」という流れのほうが早いこともあるなと感じています。
vibeコーディングとかもそうですけど、いまはとにかく作るスピードが速いので、まずモックを作って反応を見て、そこから要件を詰めるっていうアプローチでも十分やれる時代かなと。
Q：例えば非エンジニア事業責任者のクライアントとアジャイルで進めるとき、一歩目ってどんな感じですか？
まずは軽く会話してみることが多いですね。そもそも"物を作る以前"のビジネスモデル自体がふわっとしていることもあるので。
その場合、ざっくりとビジネスモデルが見えた時点で、「こんなサービスを想定しているんだけど」ってAIに壁打ちしてみて、ラフなモックをつくって、それを出発点にすることもあります。そこから、必要な機能が見えてくる、みたいな進め方が最近は多いかもしれません。
Q：ウォーターフォールとアジャイルの線引きってどこで判断していますか？
スケーラビリティの要否が、一番大きいポイントかなと思います。
たとえばMVP的に仮説検証したいだけであれば、アジャイルでさっと作ってみるのが良い。でも、既存サービスのリプレイスだったり、最初から1万人以上のユーザーが想定されるような場合は、やっぱりしっかりとした設計が必要。
そういうときはウォーターフォールでやることが多いですね。
Q：システムを作りたいけれど、社内に相談できる人がいない場合ってどうしたら良いと思いますか？
個人的には、最初は外注したほうがいいと思ってます。というのも、PMとかPdMの使い方が分からない企業も多くて、いきなり内部に入っても「で、何してもらえばいいの？」ってなりがちなんですよね。
でも外部の立場であれば、必要なときに必要なことだけ頼めるし、ニーズが発生したタイミングで動ける。そのほうがリソースを無駄にしなくて済むと思います。
中長期的に考えたときは、もちろん社内に人材を抱えたほうが良いです。PMの役割が社内で認識されていけば、自然とその必要性も広がっていくので。
Q：ちなみに外注する際の"見極めポイント"のようなものはありますか？
個人的には、「いきなり手を動かす人」はちょっと信用できないですね。
やっぱり、ちゃんと上段から「なんでこれをやりたいのか？」「そもそも本当にこの方法で解決すべきなのか？」といった問いを立てられるかどうかが重要だと思います。要件定義って、ただの聞き取りじゃなくて、問いを立てて構造化するプロセスだと思っているので。
極論、クライアントの言うことを信じすぎないことも大切だと思います。本当にやるべきことは何かを見極めにいける人は信用できるな、と思いますね。
Q：新規事業開発において、「早めに検証する」ことって常に意識されていますか？
めちゃくちゃ意識してます。以前、一生懸命プロダクトを作ったけど、ほとんど使われずに終わったこともあったので……。
なので今は、超スピーディーかつ確実に、ちゃんと仮説を持って検証していくってことをかなり意識してますね。
Q：社内システムでの検証はどのように進めていますか？
まずは「どこが一番優先順位高いのか？」を整理するところから始めます。
工数で測ったり、リスクの大きさで判断したり、いろんな指標がありますけど、まず問題を一覧にして、見える化する。それで影響度の高いものから潰していく感じですね。
私は前職がコンサル系だったこともあって、業務担当者に一週間がっつりインタビューして、業務の構造から理解することもよくやってました。社内システムって、"使う人からの信頼"もすごく大事で、良いものを作っても使われなければ意味がない。だからこそ、ちゃんと現場との関係構築も含めて、丁寧にやっていくようにしています。
Q：PMがいない企業で、責任者の「抽象的なやりたいこと」をエンジニアがそのまま作っているようなケースには、どんなアドバイスをされますか？
ちょっと冗談っぽくなっちゃいますけど……「私を入れてくれればいいのに」とは思います（笑）。
でも本当に、エンジニアって真面目だから「これ作って」って言われたら、まず動き出しちゃうんですよね。でも、それって意外と危なくて。作ってみてから、結局なにがしたいんだっけ？に陥りがちかと。
「どこから作る？」「どこまでできたらレビューする？」みたいな進め方の設計がないと、工数も時間もムダになってしまいます。家づくりに例えるなら、「こんな家欲しい」とだけ言って大工さんに丸投げしても、思った通りにはならないように、それをちゃんと翻訳して、進行管理してくれる"間の人"は絶対に必要です。
Q：機能要件を出しても理解が難しいクライアントには、どう対応していますか？
それはもう、よくないなと思いつつも割り切ってモックを作っちゃいます。
それこそデザイナーさんには「たぶん後で変わると思う、ごめんね」って言いながら、コーヒーでも奢って協力してもらいます。
でも実際、動くものがあるとクライアントの理解が一気に深まるんですよ。
途中で要望が変わったとしても、上段の「やりたいこと」さえ握れていれば大丈夫です。「それは次のフェーズで検証しましょう」って言えるので。まずは大枠を掴んでおくことが大事だなって思ってます。
Q：要件定義のスキルを要素分解すると、どんな力が必要ですか？
まずは「ヒアリング力」。相手が言いたいことをちゃんと聞く。
次に「構造化する力」。聞いた内容をロジカルに分解して、目的に対して何が必要かを整理する力ですね。
あとは、ある程度のIT・Webの知識。私自身は一社目がコンサルで、いきなりPMとして開発現場に入ったことで、その知見が身についた感じです。
▶︎ 編集後記
Miuraさんのお話で印象的だったのは、議論が複雑化する中でも「結局やりたいことは何か？」と常に立ち返る姿勢でした。要件定義は仕様の羅列ではなく、プロダクトの核である"コアバリュー"を守り抜く営み。だからこそ、やるべきことと今はやらなくてもよいことを整理し、目的に沿った優先順位を描き出すことができるのだと感じました。曖昧な要望に対しても、仮説検証を重ねながら伴走する姿勢に、要件定義の真価が宿っていました。