要件から設計への橋渡し ― 机上で聞いた要件は氷山の一角 ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「ソリューションアーキテクチャ」カテゴリ第2弾として、要件から設計への橋渡しについて解説する記事です。

要件定義の失敗は後工程で10倍のコストになります。本記事では業務部門の「やりたいこと」を技術設計に変換する実務、ヒアリング・As-Is/To-Be・MoSCoW優先順位・スコープ管理・要件トレーサビリティまで、ソリューションアーキテクトの最初の仕事を扱います。

本記事のテーマについてさらに詳しく知りたい方は『システム設計のセオリーと実践方法がこれ1冊でしっかりわかる教科書』も参考にしてみてください。

そもそも要件定義とは何か

家を建てる前の打ち合わせを想像してください。「広いリビングがほしい」「収納はたっぷり」──施主の漠然とした希望を、建築士が間取り・構造・予算に落とし込める具体的な仕様に翻訳します。この翻訳を飛ばして図面を引けば、完成後に「思っていたのと違う」が必ず起きます。

要件定義とは、業務部門の「やりたいこと」を技術設計に変換できる具体的な仕様として整理する工程です。何を作るか・何を作らないかの境界線を明確にします。

もし要件定義がなければ、開発チームは的外れな機能を作り込み、手戻りコストは後工程になるほど10倍ずつ膨らみます。

なぜ要件定義が必要か

業務と技術の言葉は違う

業務部門が「システムに問題がある」と言っても、問題の正体は業務プロセスだったりします。逆に「技術的にできない」と技術が言っても、要件を見直せばできることも多い。翻訳の専門家が必要です。

要件は発注者にもわかっていない

業務部門も何が欲しいか完全には分かっていないのが普通です。対話を通じて要件を引き出すのがアーキテクトの仕事です。

設計の選択肢は複数ある

同じ要件でも、技術選択で5倍のコスト差が出ます。業務要件の本質を掴めば、安い・早い・運用が楽な選択肢を提案できます。

要件の3階層

要件は階層構造になっています。上位から下位へ順序立てて明確化するのが原則で、ここを混ぜるとブレた設計になります。

システム要件から始めるのは最悪で、目的不明のまま作ってしまう原因です。必ずビジネス要件から降ろします。

業務ヒアリング

要件定義の起点は業務部門への丁寧なヒアリングです。一方的に質問するのではなく、現場観察・質疑応答・資料分析を組み合わせます。

現場観察が最も価値が高いことが多いです。口頭では「Excelで入力してる」でも、実際見ると「3つのExcelを行き来してる」といった複雑さが判明します。

要件の優先順位付け（MoSCoW）

全ての要件を実装するのは不可能です。優先順位を明確にするフレームワークが MoSCoW です。なんとなくではなく、客観基準で絞り込みます。

Won’tの明記が重要で、やらないと約束するとスコープクリープを防げます。

ユーザーストーリー

要件をユーザー視点の物語として記述する手法です。エンジニアと業務部門が共通理解を持つための定番フォーマットです。

【役割】として、
【目的】のために、
【機能】が欲しい。

例:
営業担当として、顧客訪問前に過去の履歴を
確認するため、モバイルで顧客情報を見たい。

受け入れ条件（Acceptance Criteria）も併記し、「完成」の判断基準を明確にします。「動く＝完成」ではなく、業務価値が出ることが完成と定義します。

現状分析（AS-IS）とTo-Be

要件定義では現状（AS-IS）と目指す姿（To-Be）の両方を描きます。現状を踏まえないと、既存業務・既存システムとの整合が取れず破綻します。

AS-IS を詳細に描きすぎて To-Be に辿り着かないのは典型的な失敗です。AS-ISは課題特定に必要な粒度で止めるのが実務的です。

業務フロー・データフロー

要件を図として業務フローとデータフローに落とします。文字だけでは誤解が生まれるため、視覚化して合意形成します。

業務部門と技術部門が同じ図を見て議論できるのが理想です。PowerPoint より Miro・Figma・Lucidchart の方が共同編集に向きます。

要件の抜け漏れ対策

要件定義の抜け漏れは後工程で致命的です。チェックリストを使って網羅的に洗い出します。

「正常系だけ定義して終わる」のが典型的失敗です。異常系こそ時間をかけて定義する価値があります。

設計への落とし方

要件が確定したら、技術設計に落とし込みます。ここで複数案を出して比較するのが鉄則で、1案だけ出すと「それが最適か」を判断できません。

最低3案がソリューションアーキテクトの鉄則で、2案だと優劣で決まり、3案以上だと中間案も検討できます。

要件定義書の構成

要件定義の最終成果物は要件定義書です。一般的には以下の構成で作成します。企業によってテンプレートは違いますが、本質的な項目は共通です。

非機能要件は次回記事で詳しく扱う重要領域です。

判断基準①:プロジェクトの規模

要件定義の詳細度はプロジェクトの規模で変わります。小規模で過剰に詳細化すると、作るより書く方が長くなります。

判断基準②:アジャイルvsウォーターフォール

要件の変化頻度で進め方が変わります。変化が少ない業務は要件を固めて進め、変化が激しい領域は段階的に進化させるアプローチが向きます。

ケース別の選び方

小規模Webサービス・3か月以内

ユーザーストーリー + Figma ワイヤー + MoSCoW で優先順位付け。要件定義書は不要、Notion 1ページで十分。現場観察1日 + インタビュー数人で AS-IS を粗く把握し、To-Be プロトタイプを早期に作って検証します。

中規模B2B SaaS・6〜12か月

要件定義書（標準テンプレ）+ BPMN 業務フロー + ユースケース図 + 受け入れ条件。業務側キーマン3〜5名との定期ワークショップ、MoSCoW で実装範囲合意、非機能要件も早期に定義。Figma／Miro で共同編集しながら合意形成。

大規模基幹システム刷新・1〜3年

AS-IS 詳細分析 + To-Be 設計書 + PoC 併用 + 段階リリース計画。業務部門から専任ユーザー代表を出向、要件定義フェーズだけで3〜6か月、BPMN L1-L3 階層化、移行計画・データ変換仕様まで含めた文書群を整備。

新規事業・B2Cプロダクト

リーンキャンバス + MVP ユーザーストーリー + スプリント毎見直し。要件は固定しない前提、最小機能で早期リリース → ユーザーフィードバックで追加。仕様書よりプロトタイプと実データ、PM とエンジニアが同席する運用。

要件定義工数・期間の数値Gate

※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。

要件定義はプロジェクト期間の20〜30%が経験則。以下が規模別の目安です。

要件定義の質を測る指標は、受け入れ条件の数値化率90%以上、スコープ（Won’t）の明示率100%、現場観察実施率（業務フロー検証）80%以上、プロトタイプ／ワイヤー共有率100%。MoSCoWでWon’tを明記するのが、スコープクリープを防ぐ最強の武器です。

要件定義の失敗は後工程で10倍のコスト。初期の丁寧さが全てです。

やってはいけないこと

要件定義で事故る典型パターン。どれもプロジェクトの半分を失うレベルの破壊力です。

2013-2015 Target Canada撤退事件（SAP 基幹システムの要件定義が杜撰で、商品マスタ現場データが大量欠損、棚が空のまま開店、2年で20億ドル損失）、英国NHS NPfITプロジェクト2002-2011（1,500ページの要件定義書、9年120億ポンド費やして中止）は、現場観察を省略した要件定義の致命的代償を示します。

机上で聞いた要件は氷山の一角。現場観察なしの要件定義は危険です。

| 「要件定義はユーザーに聞けば完成」と鵜呑み | ユーザーは欲しいものを正確に言えない、観察・試作で引き出す | | 「機能要件だけ決めれば設計できる」と非機能後回し | 非機能がないと性能・可用性で失敗、両方必要 |

AI判断軸

1. ビジネス要件から降ろす — システム要件から始めない、目的から技術へ
2. MoSCoWでWon’tを明記 — スコープクリープ防止、やらないと約束する
3. AS-ISは粗く、To-Beに時間 — 現状分析で止まらない、解決策に投資
4. 数値化された受け入れ条件 — AI に渡せる仕様、完成判断を客観化

機械可読な要件定義がAIへの指示書になる

要件定義書がPowerPointやWordの自然言語だけで書かれていると、AIコーディングツールに渡す際に人間が「翻訳」する手間が発生します。最初から機械可読な形式で要件を定義しておけば、その翻訳コストがゼロになります。

具体的には、ユーザーストーリーをMarkdownで書き、受け入れ条件をGherkin形式（Given-When-Then）で記述する方法が有効です。この形式で書かれた要件はそのままテストコード生成のインプットになり、AIが実装→テスト→修正のサイクルを自律的に回せます。

PowerPointの図解や表は人間向けの補助資料として残しつつ、正式な要件はGitリポジトリ内のMarkdownで管理する。この二重管理を避けるために「Markdownが正」と明確に宣言し、PPTは生成物として扱う運用が現実的です。

AIを活用した要件の曖昧さ検出

要件定義で最も危険なのは「曖昧な表現が誰にも気づかれないまま設計工程に進む」ことです。「高速に」「使いやすく」「セキュアに」といった形容詞だけの要件は、実装者によって解釈が分かれ、手戻りの原因になります。

AIに要件定義書を入力し「数値化されていない品質要件を列挙せよ」と指示すると、こうした曖昧表現を網羅的に検出できます。人間のレビューでは見落としがちな箇所（特に前提条件や例外パスの記述不足）を機械的に洗い出せる点が強みです。

ただし、AIが「曖昧」と指摘した箇所すべてを数値化する必要はありません。意図的に幅を持たせている要件（将来の拡張余地など）まで無理に数値化すると、かえって設計の柔軟性を損ないます。AIの指摘をチェックリストとして使い、最終判断は人間が行う運用が適切です。

決めるべきこと — 自分のプロジェクトでの答えは？

以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。

• ヒアリング方法（インタビュー・ワークショップ）
• 優先順位付け（MoSCoW等）
• 記述形式（ユーザーストーリー・業務フロー）
• 要件定義書のテンプレート（社内標準）
• 受け入れ条件の定義方法
• 変更管理プロセス（要件変更の承認）
• AS-IS／To-Beの粒度

筆者メモ — 「要件定義の失敗」が企業を沈めた事例

要件定義の甘さがどれほど重い代償を生むかを示す事例は、業界の歴史に何度も刻まれています。

Target Canada 2013-2015撤退事件は、要件定義の失敗が一つの事業そのものを消し去った象徴事例です。米国小売大手の Target が2013年にカナダ市場へ進出し、133店舗を一気に展開しました。ところが SAP を基幹とする新システムの要件定義が杜撰で、商品マスタの現場データ（サイズ・バーコード・重量）が大量に欠損、棚が空のまま店舗が開店する事態が続きました。業務の実態を見ずに要件を書いたことが直接の原因で、2年で17,600人の雇用と約20億ドルの損失を抱えて撤退、経営史に残る失敗として研究されています。

もう一つ、英国NHS（国民保健サービス）のNPfITプロジェクト2002-2011も有名な事例です。英国政府が全国統一の電子カルテシステムを目指して発注、要件定義が1,500ページを超える長大な文書になった結果、現場の病院ごとに異なる運用実態を反映できず、9年間・推定120億ポンドを費やした末にプロジェクトは中止されました。「紙の上で完璧な要件」と「現場で使える設計」は全く別物だと突きつけた事件です。

どちらも現場観察を省略した要件定義が致命傷で、机上のインタビューだけでは捕まえられない暗黙の業務ロジックが、プロジェクトの生死を決めることを示しています。

この記事に関連する記事

https://senkohome.com/arch-intro-solution-overview/ https://senkohome.com/arch-intro-solution-poc/ https://senkohome.com/arch-intro-index-solution/

まとめ

本記事は要件から設計への橋渡しについて、3階層・MoSCoW・現場観察・受け入れ条件・AI時代の仕様の意味まで含めて解説しました。如何だったでしょうか。

ビジネス要件から降ろし、Won’tを明記し、AS-ISは粗く、AIに渡せる仕様で書く。これが2026年の要件定義の現実解です。

次回は「非機能要件の設計」について解説します。性能・可用性・セキュリティ・運用を数値で定義する作法と、「遅い」「止まる」で大炎上を防ぐための数値Gateを掘り下げる予定です。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

本記事で扱った内容の詳細は AWS Well-Architected フレームワーク も合わせて参考にしてください。

それでは次の記事も閲覧いただけると幸いです。