要件定義は"最適化の競技"。妥協を納得に変える
日頃KSRで活躍されている山根さんに、KSR SS事業部責任者の丸山がインタビューを行いました。
Q：山根さんにとって、「そもそも要件定義って何？」って聞かれたら、何と答えますか？
そうですね…僕の中では"最適化の競技"って表現が一番しっくりきます。お客様は「これもやりたい、あれもやりたい」と夢を広げますし、システム部門やベンダー側は予算や工数の制約の中で「なるべくシンプルにまとめたい」と考える。立場も優先順位も全然違う人たちが一緒にものづくりをするわけなので、それぞれの期待値や要望をすり合わせて、全体最適な着地点を見つけていく。これが要件定義の本質だと思っています。
単に仕様を並べる作業ではなく、「目的に対して何が必要か」を複数のステークホルダーで主張しあい、収め合う。そういった競技ですね。
Q：その中で「これだけは大事にしている」っていうポイントはありますか？
一番は「妥協を（合理的に）納得させること」ですね。理想を全部叶えようと思えばお金をかければできることも多いですが、現実はリソースや予算のトレードオフの世界です。だから、限られた条件の中で納得感ある妥協点を描き、それをちゃんと飲んでもらう。これは口で言うほど簡単じゃなくて、時には"寝技"も必要になります。
例えば、要望を出している部署の上長に事前に話を通しておく。「今のリソース状況だとここだけは削らせてもらえませんか？」と先に合意をもらっておくんです。こういう根回しって、日本的でウェットな方法ですけど、合意形成の土台をつくるうえでかなり効いてきます。ロジカルだけで押し切れない場面も多いので、柔らかいアプローチを組み合わせることはよくありますね。
Q：要件定義のスキルって分解するとどんな力が必要ですか？
まずは「ロジカルシンキング」です。構造を作って、数字や根拠で説得力を持たせる。コンサルやSEの研修でも鍛えられる基本の部分ですね。
次に「現場経験」。これは本当に教科書に載ってない力です。大企業で複雑な承認フローを通す経験や、小さな会社で限界まで手を動かす経験など、現場で培った"肌感"は強い武器になります。そして最後に「調整力」。正解が一つじゃない場面で、人の立場や感情も含めて全員が納得できる形を作る力です。これがないと、どれだけロジカルでも現場は動きません。
Q：その正解が定義しづらいことも多いと思うんですけど、どうやって着地点を探すんですか？
初期の要望って、意外と本当の正解じゃないことが多いんです。整理してみると「この機能は実は優先度が低かった」「別のものを先に作ったほうが全体の価値が高くなる」ということがよくあります。僕は特に"リソースベース"での見立てを重視します。実装にどれだけ工数やコストがかかるのか、それが価値に見合うのか。逆に豊富なリソースがあるなら、一気にプラットフォームまで作ったほうが長期的には効率が良い場合もあります。そうやって利用者、コスト、リソースの三つの観点を交えて検討すると、かなり確からしい正解に近づけると思いますね。
Q：ちなみに過去で一番関係者感の合意が取りづらかった案件はどのようなものでしたか？
AI系スタートアップにいたときのプロジェクトですね。複数の出資者がいて、その中の大口出資者が石油化学業界だったんですが、自社としては将来的には建築など複数業界に展開したいというビジョンがありました。ところが出資を受けている以上、目先は石油化学寄りの仕様で作らざるを得ない部分がある。でもそうすると将来の展開に制約がかかる。この板挟みがとにかく大変でした。
最終的には製品を分けて、石油化学向けには使える形を作りつつ、コア技術は別ラインで開発するという判断をしました。単純な「顧客1社＋ベンダー1社」の形と違い、ステークホルダーが多いと要件定義の難易度は一気に跳ね上がりますね。
Q：逆に要件が明確になって、「これはうまくいった！」っていう例はありますか？
あくまでの私のケースではありますが…。実は"飲ミュニケーション"ですね（笑）。クライアントの中にも複数のステークホルダーがいて、それぞれが自分の立場での要望を細かく主張してくる。その理由は会議の中ではロジカルに説明しているようで、本音の部分までは見えてこないことも多いんです。
そこで、食事や雑談の場で直接、日々の細かい主張・指摘について触れてみる。そうすると、「実は役員会で自分の発言力を見せたいだけ」とか「他部署に仕事を奪われたくないから」という、表には出ない理由が垣間見えてきます。そういう背景を理解したうえで議論に臨むと、相手の"正義"を守りながら要件を整理できるんです。ロジカルだけじゃなく、人の感情も扱う。これも要件定義の重要な部分ですね。
Q：どうしても要件の理解が追い付かないような、非エンジニアのクライアントと話すときって、どんなことを意識してますか？
翻訳者になることを意識してます。エンジニアは機能や技術の話に寄りがちで、お客様は「契約書読んでるみたい…」ってなってしまう。そこで、「この機能はこういう理由で必要なんですよ」と、要望と開発現場の両方の視点をつなぐ役割を担います。実際、作ってないものを入れるほうがバリューを生むことも多くて、そういう視座を持つことが大事です。
Q：まだ要件がふわっとしてる案件だと、どうやって動いていきますか？
まずは課題ベースで掘り下げます。「業績を伸ばしたい」という漠然としたゴールがあれば、業務や売上のどこにボトルネックがあるかを見極める。そこから最も効果が出やすいポイントを特定して、小さく試す。契約も少額から始められる形にして、うまくいけば徐々に広げていきます。大事なのは"クイックに結果が出るお手軽感"と"リスクコントロール"のバランスです。
Q：ふわっとしているなかでも、最低限ここまで固まってたら進めてもいいかも。という線引きってありますか？
気持ちで言うとワクワク感ですかね。後は契約の握り方にもなるかもしれませんが、いきなりまるっと全てを一括でというより、都度アドホックで少額からのスタートなどであれば、最初のスタートは切りやすいと思います。
Q：要件定義であったり、作りたいものに輪郭を与えられなくて悩んでいるような、非エンジニアの新規事業開発責任者の人に、なにかアドバイスできることはありますか？
そうですね…。まずは一緒にホワイトボードに現状と課題を描いたりみたいなところから始めて、大まかに課題が整理出来てからシステム関連の部署や、ベンダーを呼んでいきましょう。例えばアプリを作りながらアジャイルやりましょう的な流れもあるかと思いますが、その前半のブレストであったりドキュメントワークみたいな時間は事前に設けるといいですね。
Q：要件定義をするPdMみたいな人って社内で持つべきですか、それとも外注のがいいですか？
最初は外注がいいと思います。社内にいるとどうしても色がついてしまい、少なからず思考が偏ってしまいがちなので、フラットな視点を持ちづらくなるからです。外部なら必要なときだけ動かせるし、リソースも無駄にしにくい。長期的には社内で育てるのが理想ですけどね。
Q：外注先を選ぶときの見極めポイントってあります？
「よしな力」があるかどうかですね。細かく説明しなくても、ぽろっと話した情報から意図を汲み取り、技術的にも実現可能な形に落としてくれる。いわば"テレパシー"が通じる感覚です。肌感や考え方が合う人だと、プロジェクトは驚くほどスムーズに進みます。
▶︎ 編集後記
山根さんのお話から印象的だったのは、「最適化の競技」という表現です。要件定義は単に仕様を整理するのではなく、立場も優先順位も異なる人たちを同じゴールへと導くための総合格闘技。その過程で大切なのは、理想と制約の狭間にある妥協を"納得できる選択"へと変えていく力です。ロジカルな分析だけでなく、現場で培った肌感覚や、人の感情に寄り添う調整力があってこそ成り立つ。要件定義の奥深さが強く感じられるインタビューでした。