うっかり間違えやすい、「要件定義」の本質的な意味と方法【テンプレートあり】

着目する問題：
クライアントからの理不尽な要求はどうしたらいいか

　プロジェクト型の業務を進めるうえで、約束通りにものをつくったはずなのに、なぜか受け入れてもらえず、追加の作業やコストを強いられる。プロジェクト現場では、そんなことが昔からたくさんありますが、昨今、相変わらず多く、むしろ増えているような気がします。

　そんなプロジェクトの悩みを、今回は、「要件定義」をキーワードに、紐解いてみたく思います。

　久しぶりに、アリスとボブに登場願いましょう。

ボブはちゃんと仕事をしているはずなのに、なぜか、アリスからえんえんとクレームが発生し、収束しない。

ボブは、依頼主であるアリスに気を遣って、強く切り返すこともできず、つい、相手の言いなりになってしまう。

アリスはアリスで、言いなりになるばかりで提案のないボブに、不満を募らせている。

　アリス側も、ボブ側も、経験をしたことがある方は多いのではないでしょうか。

　なぜ、こうした、理不尽なことが起きるのか。

　十中八九、おそらくそれは「要件定義」の進め方や内容が、まずかったせいです。

　SIプロジェクトやWeb制作、SaaSの導入、あるいは映像制作、個人宅の注文住宅など、目の前の顧客に対して、顧客の希望に沿った形で成果物を提供するプロジェクトを、クライアントワークと呼びますが、このクライアントワークプロジェクトにおいて、要件定義はとても重要なプロセスです。

　特にIT界隈だとこの「要件定義」というものをやるんだ、ということは、ほぼほぼ常識になっています。厳密に言えば、ウォーターフォール界隈では、ほぼほぼ絶対になっていて、アジャイル界隈だと、まだ少し諸説あって定まっていない、といったところもありますが、細かいところはひとまずおいておくとして、たいていのプロジェクトではこの「要件定義」をやることになっていて、実際に、やられています。
　ある程度まともな会社には必ず、要件定義のためのテンプレートがありますし、インターネット上にもたくさんのテンプレートがあります。

　しかし、おおくの人に、要件定義の重要性が認識されているにも関わらず、なぜか、プロジェクトの成功率は高まっていません。

　なぜでしょうか。

　要件とはなにか、要件定義のプロセスで、なにを、どう握るべきなのか、ということの本質が、あまり、理解されていないからです。

　要件定義というものを、なんのために、どうやるのか。
　どうなれば要件定義が成功したと言えるのか。

　そういうことを曖昧にしたまま、なんとなくでプロジェクトの上流工程を済ませてしまう、ということが、非常によく見られます。
そうすると、結果として、なんとなくテンプレートを埋めただけの「見かけだけは要件定義書っぽいもの」を作っただけで、本当に大事な話がすっぽり抜けてしまう、ということになります。

　クライアントワーク型のプロジェクトがうまくいかない、というときは、ほぼほぼ間違いなく、要件定義の段階で、大きな過ちを犯しています。

　このコラムでは、過ちをおかさないためのヒントを、解説します。

要件定義で抜かしてはいけない、たったひとつの重要な観点

　結論から申し上げますと、要件定義の間違え方には、たったひとつのパターンしかありません。

●要件定義のおおもとになるのは「顧客の要望」だと思っている
●要件定義では、成果物の「外観やユーザー体験、ユーザーインターフェース、機能など」を取り決めるものだ、と、思っている
●そして、要件定義の完了後の作業である、設計、製造工程とは、それらを具体化、詳細化する作業のことだと思っている

確かに、辞書を引くと、こんなふうに書いてあることが多いです。

要件定義とは、情報システムやソフトウェアについて顧客が望んでいる機能や仕様などの概略をまとめたもののことである。通常、要件定義をまとめたものは要件定義書と呼ばれる。また、要件定義に先立って、発注する側の顧客の方から、おもな要望や必要条件などをまとめたRFPが先に提出されることもある。

IT用語辞典より　 https://www.sophia-it.com/

　おおまかにいって、こうした理解が間違っているわけではありません。確かに、要件定義という作業のなかでは「成果物の外観やユーザー体験、ユーザーインターフェース、機能など」について話し合います。
　しかし、ある重要な観点を抜かして「顧客が望んでいる機能や仕様などの概略」だけを話し合っていくと、単なる机上の空論、理想論としての要望書しか出てきません。

　では、重要な観点とはなにか。

　その取り組みにおける「制約」と「趣旨」です。

　この世におけるあらゆるプロジェクトは、なにかしらの制約条件に拘束されています。

●技術的な制約
●日程の制約
●予算、財務上の制約
●組織、契約関係上の制約
●人材、スキル面での制約
●業界の慣習、ルール
●その他マクロ環境等の制約

などなど。

　ヒト・モノ・カネ・情報・技術・ノウハウなどの資源が豊富に合って、自由自在に利用できるのであれば、きっと、「顧客が望んでいる機能や仕様などの概略」だけを話し合えば、最高の成果物が生まれることでしょう。
　しかし、プロジェクトとは、現実論の世界です。その場にある、利用可能な資源をかきあつめて、ベストを尽くす以外にありません。スーパーエンジニアがいてくれたらできるのに、とか、予算が倍あればこれもできるのに、なんて、ないものねだりをしても、仕方がありません。

　また、プロジェクトには必ず、趣旨というものがあります。背景とか目的と言い換えても結構です。

　複雑な成果物を作り出そうとすると、どうしても、そのモノの話に意識が偏ってしまいがちです。なにを作るのか、どう作るのか、という議論が難しければ難しいほど、議論は錯綜します。
　そうこうしているうちに、「そもそもなんで、なんのためにやるんだっけ」ということが忘れられるのも、よくある失敗パターンです。手段の目的化、というやつですね。

　現実的な制約条件や趣旨を忘れ、とりあえず、アリスの要望をヒアリングし、なんとなく要件定義書のテンプレートを埋めてみる、ということだと、単なる机上の空論しか、出てきません。

そもそも要件とはなにか

　要件という言葉のもともとの由来は、法律用語です。

　法律や契約、規則などの「ルール」の条文は、かならず「要件と効果と趣旨」によって構成されています。
どんな法律も契約もルールも、これこれの条件を満たすと、これこれの効果が発生する、というという基本文法によって、成り立っているのです。

「教室にゲーム機を持ち込んだら、一時的に没収される」といったルールがあったとしたら

「教室にゲーム機を持ち込む」が「要件」
「一時的に没収される」が「効果」

ということになります。

　ただし、言葉で作ったルールには、解釈の幅があります。特に、ルールそのものがあいまいだったりすると、解釈次第で形骸化されたり、濫用されかねないのが怖いところです。

・将棋やトランプはゲーム機に入るのか
・ミニゲームが遊べる腕時計はどうなのか
・保護者が授業参観のときに持ってくるのはダメか
・放課後なら遊んでも良いのではないか
・探究学習の題材に持ってくるのもだめなのか

などなど。

　こうした混乱を防ぐために「趣旨」というものが設定されるのが通常です。

　あくまで一例ですが、たとえば

「教室に高価なゲーム機を持ち込むと、紛失や貸し借りなどのトラブルが起きやすい。本来、勉学を目的とした場でそのような問題を起こすのは適切ではないため、持ち込みを制限する」

といった具合に趣旨を設定すれば、個別の事案に対して、ある程度方針の定まった対応ができるようになります。

　あらためて、ルールの基本構造を図示すると、以下のようになります。

　クライアントワークプロジェクトの商取引における「要件」も、まったく同じ話の構造があてはまります。

　それは考えてみれば、実に当たり前の話で、これから未知なる成果を生み出し、対価と交換する、という取り組みには、不確実性があります。不確実だからこそ、悪意を持って商談を持ちかけて、あとでだまし取ることも理論上可能ですし、悪意がなかったとしても、「こんなはずじゃなかった」ということになる場合もあります。
　それを防ぐために、取引のルールを定めるのです。それが、要件定義の本質です。

・ボブはアリスに、これこれの条件を満たす成果物を、いついつまでに、このような形で引き渡す
・アリスは成果物に対して、これこれこういう手続きで検査、受入をし、合格した場合に、これこれの条件で対価を渡す

　こういう話をするのが、本来するべき、要件定義というものです。

　つまり、取引におけるルールを定めるのが、要件定義です。

　その中身として、「成果物が満たすべき条件」ももちろん含まれますが、納期や費用、検収条件や支払条件といったものも含まれます。話し合いのなかに、納期や費用、検収条件や支払条件といったものを含む以上は、純粋に物の話をするだけでは、片手落ちになってしまいます。

　ボブの側は、作るうえでの体制や生産キャパシティといったものも考慮しなければなりません。
　アリスの側は、予算の確保や執行の段取り、受入体制といったものも、考慮しなければなりません。

　そのような、生み出したい成果物の外堀にあるものを考慮にいれて初めて、要件定義は実効性のあるものになります。

　以上のように考えると、成果物が満たすべき条件は「仕様」と呼んで、「仕様」に加えて、取引条件も含んだものを「要件」と呼んだほうが、議論がスッキリしますので、お勧めしたく思っています。

いい要件を握り合うための、３つのヒント

　要件定義とは、非常にクリエイティブな行為です。仕様がひとつ違えば、コストも納期も、まったく変わります。

●アリス：いつまでに、どれくらいの予算で、どんなものが欲しいのか
●ボブ　：どれくらいの労力で、どんな技術やノウハウを用いて、どんなものを作るのか

　ふたりの立場は、常に、鶏と卵の関係にあります。相手の出す情報や条件によって、こちらも変わります。

　ボブは、ときどき、言うことがコロコロ変わったり、そもそもなにを言っているのかよくわからないアリスに対して「とにかく、なんでもいいから、欲しいものを決めてくれ！決めたらもう、前言撤回はしないでくれ！そうじゃないと、予算も納期も、約束できない！」と、叫びたくなるときがあります。

　アリスもアリスで、ボブに対して「もう、なんでもいいから、とにかくいい感じの提案を出してよ！」と、突き放したくなります。

　たくさんの矛盾や、たくさんの未知の要素があるなかで、ベストな結論を導き出すには、様々な工夫が必要です。

　下手に運転すると、あっという間に迷子になりかねない要件定義を進めていくには、以下の３つをヒントにしていただきたく思います。

「関係性」の工夫	・そもそもの大前提として、アリスとボブの、互いの信頼関係が第一 ・アリスは「このボブにだったら、本当に困っていることを相談したい」と思えること ・ボブは「このアリスのためなら、一肌脱いで、いい仕事をしたい」と思えること ・そのために、ボブは要件定義の段取りや手順を整理整頓して、アリスを適切にリードする ・同時に、結論を急ぎすぎず、悩みや課題の深層を深く掘っていく
「論理性」の工夫	・最終的には、趣旨、制約、要件、効果の関係性には、ロジカルな辻褄合わせが必要 ・正しい検討には、できる限り広く、正確な情報が必要 ・そのために、良い関係性のもとで、とにかく一次情報をしっかり集め、整理整頓する
「握り」の工夫	・いざ、ゴーサインを出して、いい形に持っていくためには、タイミングと決心が重要 ・そのために、最前衛の当事者同士が、リスクも理解したうえで、握り合うことが大事 ・実務を走らせるための、契約締結プロセスも、タイムリーに進める工夫をする

おわりに

　要件定義は、なんとなくフォーマットを埋めてみる、とか、AIサービスにヒアリング資料を読んでもらって、それっぽいものを出力してもらう、ということだと、十中八九、失敗します。要件定義の失敗は、未来のアリスとボブの、両方にとっての損失をもたらします。

　そうならないために、ぜひ、要件定義とはなんのためにするのか、どうするのか、ということを、ぜひこの機会に、考えてみていただけますと幸いです。

　また、要件定義にあたっての考えを整理するのに便利なテンプレートを、無償で配布しています。もし、お役立ていただけるようでしたら幸いです。

https://www.gotolab.co.jp/wp-content/uploads/2025/09/condition-definition_gotolabSpecialTemplate.pptx