本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「エンタープライズアーキテクチャ」カテゴリ第2弾として、ビジネスアーキテクチャ（BA）について解説する記事です。
EAの最上位レイヤーで、「何を・誰が・どう行うか」という事業そのものを設計対象にします。BAが不明確だとDA/AA/TAが目的を見失う──BAは全ての技術判断の起点です。本記事ではケイパビリティマップ・バリューストリーム・業務プロセス（BPMN）・組織モデルまで、技術と事業の言葉のズレを埋める設計を扱います。
本記事のテーマについてさらに詳しく知りたい方は『エンタープライズ・アーキテクチャの基本と仕組み』も参考にしてみてください。
この記事の結論
- 組織図でなくケイパビリティマップを安定軸にする
- 階層は2〜3で止める（深掘りしすぎない）
- 機械可読な形式で維持する
この記事を読む前に
本記事は会社全体のシステムをどう整理するかという話が中心で、技術用語は比較的少なめです。とは言っても、Webサービスの基本構造を知っていると読みやすくなりますので、不安な方は基礎編の「Webサービスが動く仕組み」からどうぞ。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもビジネスアーキテクチャとは何か
会社の事業計画書を思い浮かべてください。「誰に・何を・どう届けるか」が書かれていなければ、各部署は自分の判断で動くしかなく、全社的な方向性がバラバラになります。
ビジネスアーキテクチャ（BA）はEAの最上位レイヤーで、事業そのものを設計対象にする領域です。ケイパビリティマップ・バリューチェーン・業務プロセスなど、「何を・誰が・どう行うか」を構造化します。
もしBAがなければ、技術部門はビジネスの目的を理解しないままシステムを作ることになります。手段が目的化し、使われないシステムが量産されます。
なぜBAが必要か
第一に、技術と事業の言葉のズレを埋めるためです。業務部門が「顧客接点を強化したい」と言い、技術部門が「CRMを導入する」と返すような目的と手段の混同を避けるには、共通のモデルが必要です。
第二に、組織横断のシステム整合です。部署ごとに独立してシステム投資すると重複・矛盾・統合不能が起きますが、BAが全体像を描けば投資の重複を避けられます。
第三に、変革の影響範囲の可視化です。新事業・M&A・撤退──こうした事業変更がどのシステム・業務に影響するかを、BAがないと追跡できません。
BAの主要構成要素
BAは事業を複数の視点でモデル化します。業界や企業によって重点は変わりますが、以下が一般的な構成要素です。
| 要素 | 内容 |
|---|---|
| ビジネス戦略 | ビジョン・目標・KPI |
| ビジネスケイパビリティ | 「何ができるか」の能力 |
| バリューストリーム | 価値を生む流れ |
| ビジネスプロセス | 業務手順・手続き |
| 組織 | 部署・役割・責任 |
| ステークホルダー | 顧客・取引先・規制当局 |
ビジネスケイパビリティ（能力）
企業ができることを整理したのがビジネスケイパビリティです。「顧客獲得」「注文処理」「在庫管理」──組織ではなく能力単位で整理するのが特徴です。組織変更があっても能力は変わりにくいため、EAの安定軸として使われます。
業界が変わればケイパビリティの粒度と分類軸も変わります。金融業では「リスク管理」「与信審査」が独立した大粒度のケイパビリティとして現れ、規制対応そのものが事業価値の源泉になります。製造業では「サプライチェーン」「生産計画」「品質管理」が主軸になり、SaaS企業では「顧客獲得」と「プロダクト開発」が大粒度の柱になります。自社の業界で既に整備されたリファレンスモデル（BIAN＝銀行業界のケイパビリティ標準、eTOM＝通信業界の業務プロセス標準）があれば、それを出発点にすると粒度調整の手間が大きく減ります。
ケイパビリティマップは2〜3階層で止めるのが実用的です。深くすると維持不能になります。
ケイパビリティを使った代表的な分析手法がCapability Based Planning（CBP）です。どのケイパビリティが強みで、どこが弱いかをヒートマップ（戦略的優位＝緑・競合同等＝黄・劣後＝赤・不要＝灰）で可視化し、赤に集中投資・緑は維持・灰は削減、と戦略判断の見える化をします。経営会議での意思疎通に極めて有効です。
バリューストリームとビジネスプロセス
バリューストリームは顧客価値を生み出す活動の流れです。「注文受付→決済→配送→アフターサポート」のように、顧客の目線で一連の活動を整理します。ケイパビリティが「何ができるか」なら、バリューストリームはどう顧客価値を実現するか。どこがボトルネックか・どこを自動化すべきか・システム投資の優先順位はどこか、という判断に使えます。
ビジネスプロセスはさらに詳細な業務手順で、実際に誰が何をするかを描きます。標準記法はBPMN 2.0（業界標準・ツール多数）で、開発寄りならUMLアクティビティ図でも構いません。プロセスはL1（概要）・L2（中粒度）・L3（詳細）と階層化して描くと、経営層と現場が同じ図の上で議論できます。
組織構造のモデル化ではRACIマトリクス（誰が実行し＝Responsible、誰が最終責任を負い＝Accountable、誰が相談され＝Consulted、誰に情報共有されるか＝Informed）が特に重要です。これがないと変革時に誰に聞けばいいかわからない状態に陥ります。加えて、事業に関わる全主体（顧客・従業員・取引先・株主・規制当局）と各々の関心事を整理するステークホルダーマップが、要件の源泉になります。
BAと下位レイヤーの関係
BAはデータ・アプリ・テクノロジーの下位レイヤーの根拠となります。BAから下位レイヤーへなぜそれが必要かを説明できるのが、正しいEAの姿です。
[ビジネスアーキテクチャ (BA)]
・顧客獲得ケイパビリティ
│
▼ 必要なデータ
[データアーキテクチャ (DA)]
・顧客マスタ・行動データ
│
▼ 処理するアプリ
[アプリケーションアーキテクチャ (AA)]
・CRM・MAシステム
│
▼ 動くインフラ
[テクノロジーアーキテクチャ (TA)]
・クラウド・DB・サーバー下位レイヤーだけで設計すると、技術都合のシステムが生まれ、事業価値を生みません。「このシステム、なぜ存在するの？」と経営層から問われ、開発メンバーも業務部門も口ごもる──という場面は現場でしばしば起こります。逆にBAが生きている組織は、同じ質問に「顧客獲得ケイパビリティの中核だから」と1行で返ってきます。BAがあるかどうかは、この3秒の返答に現れます。
BA構築の段階別ロードマップ
BAは「いきなりフル構築」では運用が破綻するため、規模に応じた段階的投資が現実的です。
| フェーズ | 期間目安 | 成果物 | 投資人員 |
|---|---|---|---|
| ①スタートアップ | 1日〜1週間 | ビジネスモデルキャンバス1枚 | 創業者兼任 |
| ②中小企業DX推進 | 1〜3か月 | ケイパビリティマップ2階層 + 主要3〜5プロセスBPMN | 0.5〜1名 |
| ③中堅企業 | 〜1年 | フルケイパビリティマップ + RACI + ステークホルダーマップ | EAチーム3〜5名 |
| ④大企業 | 継続的 | ArchiMateフルモデル + 四半期レビュー + CBP | 専門EA組織 10名〜 |
| ⑤規制業種 | 継続的 | フル + 業界特化（BIAN等）+ 監査対応 | 中央EA + 事業部EA |
スタートアップはビジネスモデルキャンバス（Strategyzer）+ Miroで軽量に維持し、創業者やPdMが四半期に1回見直す程度で十分です。中小企業のDX推進では、デジタル化対象の業務フローだけBPMNで詳細化し、他は粗いままで構いません。IT部門・業務部門の合同ワークショップで作るのがコツです。中堅以上ではArchiMate + Sparx EA等で更新プロセスを運用し、M&A・事業再編時の統合分析にも活用します。
ケイパビリティマップは2〜3階層で止めるのが実務の鉄板です。4階層以上は維持不能で、絵に描いた餅になります。意思決定に使われる粒度が最大の基準で、詳細さよりも「経営層と現場が同じ地図上で議論できるか」を優先します。BAの整備は変革期（DX推進・M&A・事業再編）に最も必要で、平穏な時期に時間をかけるより、変革の機会に合わせて整備する方が現実的です。
AI判断軸 ― 機械が読めるBAが競争力になる
AIにBA情報を読ませて経営分析に活用する
ケイパビリティマップや業務フロー図がArchiMate等の構造化形式で管理されていれば、AIに渡して「この事業のボトルネックはどこか」「M&A後の重複ケイパビリティはどれか」を分析させることが可能です。PowerPointの手書き図ではAIが構造を理解できないため、分析対象にできません。「我が社のケイパビリティマップをAIに渡して分析させる」時代が来ています。
バリューストリームの定量化とAI予測
バリューストリームの各ステップにリードタイム・コスト・エラー率の数値を付けておけば、AIが「どこを改善すれば最も効果が高いか」を定量的に分析できます。定性的な説明だけのBAでは、AIは改善提案の優先度を判断できません。AI時代のBAは機械が読めて、数値を持ち、更新されるものです。
やってはいけないこと
BA構築で事故る典型を、特に危険な6つに絞ります。どれも絵を描いて終わり・使われないBAの結末を生みます。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| ケイパビリティマップを4階層以上で作る | 維持不能で3年で放置・陳腐化 → 2〜3階層で止める |
| ケイパビリティを組織名で分割 | 組織変更でBAが崩壊 → 能力単位で安定軸にする |
| 業務部門を巻き込まずIT部門単独で構築 | 業務実態と乖離し現場から無視される → 合同ワークショップで作る |
| PowerPoint・Wordの手書き図のみで管理 | AI読解不能・静的な資料止まり → ArchiMate等の構造化形式へ |
| 1回作って放置 | 事業変化に追従せず3年で全面書き直し → 四半期レビューを組み込む |
| BAを作らず新規事業の要件定義を開始 | 「新規サブスク事業8か月停滞」パターン → ケイパビリティの新設か拡張かを先に整理する |
なお「詳細であるほど価値がある」という信念も誤りです。意思決定に使われる粒度でなければ作っただけの紙で、使われるなら粗くても構いません。BIAN等のリファレンスモデルを活用せず自力でゼロから作るのも、業界知識の蓄積を無視した無駄な労力です。
筆者メモ — 「BA不在」が新規事業を8ヶ月止めた事例
中堅製造業で「新規サブスク事業を立ち上げる」DXプロジェクトが始まり、ケイパビリティマップもバリューストリームもない状態で要件定義を進めた結果、「既存の受注管理システムを使うか、新規SaaSを入れるか」の議論が半年以上決着せず、プロジェクトが8か月停滞した、という事例はよく報告されます。BAがあれば「これは『顧客維持』ケイパビリティの新設であり、既存の『受注処理』とは別系統」と1行で整理できたはずの議論が、組織を横断する度に振り出しに戻る──これがBA不在の典型的な被害です。
対照的に、AmazonのWorking Backwardsと呼ばれる文化はBA思想の成功例として語られます。新規サービスを検討する際、最初にプレスリリース（顧客視点のバリューストリーム）を書き、そこからケイパビリティとシステムアーキテクチャに落とす──という規律を全社に徹底したことで、AWS・Prime・Alexaといった全く異なる事業を、同じ発想で生み出し続けられる組織力を獲得しました。
どちらの事例も「事業の構造を先に見える化する」ことの価値を裏返しに示しています。BAは絵を描くためではなく、組織の意思決定を速くするために存在します。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- ケイパビリティマップ（作成範囲・階層）
- バリューストリーム（顧客価値の流れ）
- 重要ビジネスプロセス（BPMN化の対象）
- RACIマトリクス（役割と責任）
- ステークホルダーマップ（関係者の洗い出し）
- モデリングツール（ArchiMate / Miro等）
- 更新プロセス（誰が・いつ見直すか）
この記事に関連する記事
まとめ
本記事はビジネスアーキテクチャについて、ケイパビリティ・バリューストリーム・BPMN・RACI・ステークホルダー・ArchiMate・AI時代の機械可読BAまで含めて解説しました。如何だったでしょうか。
ケイパビリティを安定軸に2〜3階層で止め、規模に応じて詳細度を調整、変革期に整備、機械可読な形式で維持する。これが2026年のBA設計の現実解です。
次回はデータアーキテクチャ（DA）（全社データ戦略・MDM・データカタログ）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は AWS クラウド導入フレームワーク も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（76/95）