要件定義とは？「オーダースーツ作り」に例えたら、システム開発が失敗する理由がわかった

【この記事はこんな方に向けて書いています】

「要-件-定-義」という言葉の、漢字の並びだけで、少し気後れしてしまう方
システム開発を外部に発注する立場になったけど、何をどう伝えればいいか分からない方
新米のプロジェクトマネージャーやシステムエンジニアで、上流工程の重要性を学びたい方
「完成したシステムが、思っていたものと全然違う…」という悲劇を、絶対に避けたい方
曖昧なフワッとした要望を、具体的な「やることリスト」に落とし込む技術を身につけたい方

「納期通り、予算通りに、頼んだ通りのシステムが完成した。しかし、全く使えない…」

ITプロジェクトの世界では、時として、そんな笑えない悲劇が起こります。ボタンの数も、画面の色も、頼んだ通り。バグもなく、サクサク動く。それなのに、なぜか現場の業務には全くフィットせず、誰も使いたがらない。結果、多額の投資と数ヶ月の歳月をかけて作られたシステムは、静かに塩漬けにされていく…。

なぜ、こんな悲しいことが起きてしまうのでしょうか？その原因の9割は、プログラミングの技術力でも、プロジェクト管理の巧拙でもありません。すべての悲劇の根源は、システム開発の、あまりにも重要で、あまりにも軽視されがちな「最初のステップ」にあるのです。

そのステップこそが「要件定義」です。この記事では、このシステム開発の成否を分ける最重要プロセス「要件定義」の本質を、「最高のオーダースーツを仕立てるまでの、テーラーと顧客の対話」という、非常に身近な例え話で、どこよりも分かりやすく解説していきます。

結論：要件定義とは、最高のスーツを作るための「精密な採寸と設計図」である

まず、この記事の結論であり、すべてを理解するための鍵となるイメージをお伝えしましょう。

顧客のフワッとした要望 ＝「とにかく、カッコよくて、仕事ができる感じのスーツが欲しいんです！」
要件定義 ＝凄腕のテーラー（仕立て職人）が、顧客と対話を重ね、「なぜそのスーツが必要か」を深く理解し、身体の隅々まで精密に採寸するプロセス。
要件定義書 ＝その結果をまとめた、生地、デザイン、寸法、価格、納期などが、誰の目にも明確にわかる形で記された「最終仕様書（＝設計図）」。

もし、テーラーが顧客の「カッコいいスーツが欲しい」という言葉だけを鵜呑みにして、いきなり自分のセンスで生地を裁断し始めたらどうなるでしょう？たとえ縫製技術が完璧でも、完成したスーツは、顧客の体型にも、スーツを着る場面にも、全く合わないかもしれません。「私が欲しかったのは、これじゃない…」という、最悪の結果が待っています。

要件定義とは、この最初のボタンの掛け違いを、絶対に起こさせないためのプロセスです。開発に着手する前に、「何を」「なぜ」「どこまで」作るのかを、作る側（開発者）と使う側（顧客）の間で、一字一句違わぬレベルで、完璧に合意形成すること。これこそが、要件定義の魂なのです。

なぜ「最初のボタン」を掛け違える？プロジェクトが失敗する恐ろしいデータ

「要件定義が重要なのはわかった。でも、そんな最初のステップで間違うことなんてあるの？」あるのです。それも、驚くべき頻度で。

ITプロジェクトの成功率に関する調査で、世界的に有名な「CHAOSレポート（米国スタンディッシュグループ）」というものがあります。このレポートの近年の調査結果を見ても、プロジェクトが完全に失敗、あるいは、納期や予算を大幅に超過するケースは後を絶ちません。そして、その失敗の最大の原因として、常に上位に挙げられるのが、「不明確な要件」と「ユーザー（顧客）の巻き込み不足」なのです。

これは、スーツ作りに例えれば、「採寸もそこそこに、どんな場面で着るのかも聞かずに、いきなり生地の裁断を始めてしまう」のと同じです。生地を裁断する前（＝要件定義の段階）であれば、「やっぱり、もう少し袖を短く…」という変更は、ほとんどコストもかからずに可能です。しかし、スーツがほぼ完成した後（＝開発の終盤）で、「やっぱり、生地の種類を変えたい」と言われたらどうでしょう？それはもう、作り直し。コストも納期も、壊滅的なダメージを受けます。

「上流工程での1時間の遅れは、下流工程での10時間の遅れに匹敵する」 これは、システム開発の現場で語られる格言です。要件定義という最初の一歩が、いかにプロジェクト全体の運命を左右するかを示しています。

「要望」と「要件」は違う！凄腕テーラーのヒアリング術

要件定義を成功させる上で、最も重要なのが、顧客の「要望」と、システムが満たすべき「要件」を、明確に区別することです。

要望（Request）：顧客の、感情的で、主観的で、フワッとした「願い」。例：「もっと営業活動を効率化したい」「若者にもウケる、イケてるサイトにしたい」
要件（Requirement）：その願いを叶えるために、システムが具体的に、客観的に、そして測定可能に満たすべき「条件」。例：「顧客情報を入力後、3秒以内に登録が完了すること」「スマートフォンでのサイト表示に最適化されていること」

凄腕のテーラー（SEやプロジェクトマネージャー）は、顧客の「カッコいいスーツが欲しい」という要望を、巧みな質問によって、具体的な要件に翻訳していきます。

テーラーのヒアリング術（要件の分解）

業務要件：「なぜ、そのスーツが必要なのですか？」 「どんな課題を解決したいのか」という、根本的な目的を明確にします。顧客：「大事なプレゼンで、相手に信頼感と情熱を伝えたいんです」 → 目的：プレゼンの成功確率を上げること。
機能要件：「そのスーツには、どんな機能が必要ですか？」 目的を達成するために、システムが「何をしなければならないか（Do）」を定義します。顧客：「夏場のプレゼンなので涼しく、動きやすく。ポケットにはA4資料をしまいたい」 → 機能要ten：通気性の良い生地を使用する。腕の可動域を確保する裁断。内ポケットはA4サイズ対応。
非機能要件：「そのスーツは、どんな品質であるべきですか？」 機能以外で、システムが満たすべき品質や制約。「どうあるべきか（Be）」を定義します。顧客：「見た目は高級感が欲しいけど、予算は10万円以内で。納期は来月末まで。手入れが簡単なものがいい」 → 非機能要件：性能（耐久性）、品質（見た目）、コスト、納期、運用性（メンテナンス性）など。