ITコンサルタントの業務分析・要件定義プロセス
システム開発を成功させるカギは、技術選定の前段階にあります。ステークホルダーの目線を揃え、現状業務の課題を構造化し、あるべき姿（To-Be）を合意する——この「業務分析・要件定義」フェーズの質がプロジェクト全体の成否を左右します。
なぜ業務分析・要件定義が重要なのか
システム開発の失敗原因の多くは「要件定義の不備」です。経済産業省の調査でも、ITプロジェクトの問題の約70%は要件定義フェーズに起因するとされています。
関係者間で「何を作るか」の認識が揃っていないまま開発が進み、完成後に「思っていたものと違う」となる。
「なんとなくこうしたい」レベルのまま仕様化され、後工程で手戻りが多発する。変更コストは後工程ほど指数関数的に増大。
"表面的な症状"に対処する機能を作ってしまい、根本課題が解決されないまま運用フェーズに入ってしまう。
これらを防ぐために、ITコンサルタントは「業務要求（Business Requirement）」を5つのステップで体系的に整理します。以下にその全体像を解説します。
業務分析の5ステップ（BR.1〜BR.5）
プロジェクトに関与するすべての人物・組織を特定し、関心事・影響度・関係性を整理する。意思決定構造を可視化することで、要件収集の優先順位と合意形成の道筋が明確になる。
現状の業務プロセス・システム・データ管理を可視化する。「リッチピクチャ」や「業務フロー図」を作成し、業務全体像を俯瞰することでボトルネックの発見が容易になる。
「なぜなぜ分析」や「課題マップ」を用いて、表面的な問題の根本原因を特定する。ビジネスインパクト・緊急度・対処可能性で優先度を評価し、対策すべき課題に絞り込む。
特定した課題に対する解決策（施策）を複数立案し、投資対効果・実現可能性・優先度で評価する。「施策マップ」として体系化し、次フェーズのTo-Be構想への橋渡しとする。
あるべき業務フローとシステム像を描く。KPI/KGIで変化を数値化し、ROI試算・フェーズ別ロードマップを作成することで、意思決定者が承認しやすい「経営レベルの言葉」で提案できる。
BR.1 ステークホルダー把握
ステークホルダー分析は業務分析の出発点です。「誰が何を期待しているか」を明らかにしないまま要件を定義すると、後から利害関係者の反対で頓挫するリスクがあります。
主な成果物
役職/部門・関与度（オーナー/承認者/担当者/関係者）・主な関心事・懸念を表形式で整理する。ヒアリング計画の基礎となる。
人物・組織間の関係性を図示（Mermaidなど）。影響力と利害関係のマトリクスで、重点的にケアすべき関係者が一目でわかる。
各業務タスクに対してResponsible（実施者）・Accountable（責任者）・Consulted（相談先）・Informed（報告先）を定義し、責任の所在を明確化する。
現場の生の声を記録。「Excelの打ち込みミスで年60件の出荷違いが発生」のような定量的なエピソードが要件定義の説得力を高める。
実践のポイント
- •「実際にシステムを使う人」と「承認する人」は往々にして異なる。両者の要件を同時に収集・調整することが重要。
- •経営層は「ROI・KPI」の言語で、現場は「日常業務の痛み」の言語で語る。翻訳役として機能することがコンサルタントの価値。
BR.2 As-Is現状把握（業務フロー・リッチピクチャ）
現状の業務を「ありのまま」可視化します。改善したい衝動を抑え、まず現実を正確に記録することが目的です。「見えていなかった業務」「例外処理の多さ」が浮き彫りになることがよくあります。
主な成果物
業務全体を俯瞰した概念図。人・システム・データ・外部組織の関係を絵として描く。厳密な記法より「全員が同じ絵を見ている」感覚が重要。
主要業務プロセスをフローチャートで表現（Mermaid / BPMN）。スイムレーンで担当部門・システムを分け、引き継ぎ箇所（ハンドオフ）を明示する。
業務を「大分類→中分類→機能」に階層化した一覧。この表がシステムの機能要件定義（Step5）の土台になる。
組織固有の業務用語を統一定義する。同じ言葉が部門によって異なる意味で使われていることは珍しくない。
BR.3 問題・ニーズ把握（課題の構造化）
業務フローが明らかになったら、「どこに問題があるか」を構造化します。単に「困っていること一覧」を作るのでは不十分で、課題の因果関係・根本原因・ビジネスへの影響を整理することが求められます。
「なぜその問題が起きているか」を5〜7回繰り返して根本原因を掘り下げる。例：受注ミスが多い → なぜ？手入力だから → なぜ手入力？システムがないから → 根本原因：IT投資の優先度が低かった。
課題を「重要度 × 緊急度」のマトリクスでプロットし、対処すべき課題を絞り込む。リソースは有限であり、すべての課題に同等に対処することはできない。
課題をカテゴリ（経営・業務・IT・コスト・人材）で分類し、影響範囲・優先度を付与した一覧表。ステークホルダーとの合意形成ドキュメントとして活用する。
「年間60件の出荷違い＝1件あたり¥50,000の損失→年間¥3M」のように課題を数値化する。数値化することで経営層の優先度判断が容易になる。
BR.4 施策検討（解決策の立案と評価）
課題が明確になったら、解決策（施策）を複数立案します。「最初に思いついた1案で進む」のではなく、複数案を比較検討することで意思決定の質が高まります。
施策評価の観点
施策優先度マップ（例）
BR.5 To-Be構想（あるべき姿の設計）
施策が固まったら、「システム化後の業務がどうなるか」を具体的に描きます。To-Be構想はプロジェクトのゴール像であり、経営層・現場・開発チームが同じビジョンを持つための共通言語です。
As-Isと対比させることで、どのプロセスが自動化・効率化されるかを一目で示せる。Mermaid等のフローチャートで可視化し、システム化範囲を明確にする。
「受注リードタイム4h → 2h」「入力ミス年60件 → 0件」のように、As-IsとTo-Beの差を数値で表現する。KGI（最終目標）とKPI（中間指標）を階層的に設計する。
投資額・削減コスト・増収効果・回収期間を試算する。「¥30M投資 → 年間¥15M削減 → 2年で回収」という形式で、経営層の意思決定を支援する。
すべての施策を一度に実施することはリスクが高い。MVP（最小限の価値を持つ製品）から段階的に展開するフェーズ計画を作成し、各フェーズの投資・効果・マイルストーンを明示する。
フェーズ別アウトプット成果物
| フェーズ | 主な成果物 | ArchitectAI |
|---|---|---|
| BR.1 ステークホルダー把握 | ステークホルダー一覧・関係図・RACI表 | Step1 |
| BR.2 As-Is現状把握 | リッチピクチャ・As-Is業務フロー図・業務機能構成表・用語集 | Step2 |
| BR.3 問題・ニーズ把握 | 課題一覧・なぜなぜ分析・優先度マトリクス | Step1 |
| BR.4 施策検討 | 施策一覧・施策優先度マップ | Step3 |
| BR.5 To-Be構想 | To-Be業務フロー・KPI/KGI・ROI試算・ロードマップ | Step3 |
| システム要件定義 | 業務要件定義書・機能要件定義書・非機能要件定義書 | Step4〜6 |
| アーキテクチャ設計 | アーキテクチャ設計書・構成図・コスト見積・提案書 | Step9〜11 |
ArchitectAI での実践
ArchitectAI の Step1〜Step3 は、このBR.1〜BR.5フレームワークに対応しています。ヒアリング内容・ステークホルダー情報・業務フローを入力するだけで、AIが上記の成果物を自動生成します。
- ✓BR.1: ステークホルダー一覧・関係図・RACI表
- ✓BR.3: 課題一覧・なぜなぜ分析・優先度マトリクス
- ✓BR.2: リッチピクチャ・業務フロー図
- ✓BR.2: 業務機能構成表・用語集・ボトルネック
- ✓BR.4: 施策一覧・施策優先度
- ✓BR.5: KPI/KGI・ROI試算・ロードマップ