ビジネスアーキテクチャ ― 事業を技術と接続可能な形にする ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「エンタープライズアーキテクチャ」カテゴリ第2弾として、ビジネスアーキテクチャ（BA）について解説する記事です。

EAの最上位レイヤーで、「何を・誰が・どう行うか」という事業そのものを設計対象にします。BAが不明確だとDA/AA/TAが目的を見失う──BAは全ての技術判断の起点です。本記事ではケイパビリティマップ・バリューチェーン・業務プロセス（BPMN）・組織モデル・戦略と業務の接続まで、技術と事業の言葉のズレを埋める設計を扱います。

本記事のテーマについてさらに詳しく知りたい方は『エンタープライズ・アーキテクチャの基本と仕組み』も参考にしてみてください。

そもそもビジネスアーキテクチャとは何か

会社の事業計画書を思い浮かべてください。「誰に・何を・どう届けるか」が書かれていなければ、各部署は自分の判断で動くしかなく、全社的な方向性がバラバラになります。

ビジネスアーキテクチャ（BA）はEAの最上位レイヤーで、事業そのものを設計対象にする領域です。ケイパビリティマップ・バリューチェーン・業務プロセスなど、「何を・誰が・どう行うか」を構造化します。

もしBAがなければ、技術部門はビジネスの目的を理解しないままシステムを作ることになります。手段が目的化し、使われないシステムが量産されます。

なぜBAが必要か

技術と事業の言葉のズレを埋める

業務部門が「顧客接点を強化したい」と言い、技術部門が「CRMを導入する」と返すような目的と手段の混同を避けるため、共通のモデルが必要です。

組織横断のシステム整合を取る

部署ごとに独立してシステム投資すると、重複・矛盾・統合不能が起きます。BA が全体像を描けば投資の重複を避けられます。

変革の影響範囲を可視化する

新事業・M&A・撤退──こうした事業変更がどのシステム・業務に影響するかを、BA がないと追跡できません。

BAの主要構成要素

BA は事業を複数の視点でモデル化します。業界や企業によって重点は変わりますが、以下が一般的な構成要素です。

ビジネスケイパビリティ（能力）

企業ができることを整理したのがビジネスケイパビリティです。「顧客獲得」「注文処理」「在庫管理」「会計」──組織ではなく能力単位で整理するのが特徴です。組織変更があっても能力は変わりにくいため、EA の安定軸として使われます。

ここでは小売業を例にしていますが、業界が変わればケイパビリティの粒度と分類軸も変わります。金融業では「リスク管理」「コンプライアンス」「与信審査」が独立した大粒度のケイパビリティとして現れ、規制対応そのものが事業価値の源泉になります。製造業では「サプライチェーン」「生産計画」「品質管理」が主軸になり、物理的なモノの流れを中心に階層が組まれます。SaaS 企業では「顧客獲得（マーケティング・セールス）」と「プロダクト開発」が大粒度の柱になり、小売業のような「在庫管理」はほぼ不要です。自社の業界で既に整備されたリファレンスモデル（BIAN＝銀行業界のケイパビリティ標準、eTOM＝通信業界の業務プロセス標準）があれば、それを出発点にすると粒度調整の手間が大きく減ります。

ケイパビリティマップは2〜3階層で止めるのが実用的です。深くすると維持不能になります。

バリューストリーム

顧客価値を生み出す活動の流れを描いたのがバリューストリームです。「注文受付 → 決済 → 配送 → アフターサポート」のように、顧客の目線で一連の活動を整理します。ビジネスケイパビリティが「何ができるか」なら、バリューストリームはどう顧客価値を実現するかです。

Lean・DevOps でも使われる概念で、IT だけでなく製造・物流にも適用されます。

ビジネスプロセス

業務の具体的な手順・手続きです。バリューストリームよりも詳細で、実際に誰が何をするかを描きます。BPMNが標準記法で、フローチャート形式で書きます。

プロセスは階層化して描くのが現実的です。L1（概要）・L2（中粒度）・L3（詳細）のように分けると、経営層と現場で同じ図の上で議論できます。

組織とガバナンス

BA では組織構造もモデル化します。誰が・どの業務・どのシステムに責任を持つかを明確化しないと、変革時に誰に聞けばいいかわからない状態に陥ります。

RACIマトリクスは特に重要で、「誰が実行し、誰が最終責任を負い、誰が相談され、誰に情報共有されるか」を明示します。

ステークホルダーマップ

関係者の可視化です。事業に関わる全ての主体（顧客・従業員・取引先・株主・規制当局・地域社会）を洗い出し、誰が何を求めているかを整理します。これが要件の源泉になります。

BAと下位レイヤーの関係

BA はデータ・アプリ・テクノロジーの下位レイヤーの根拠となります。BA から下位レイヤーへなぜそれが必要かを説明できるのが、正しい EA の姿です。

[ビジネスアーキテクチャ (BA)]
   ・顧客獲得ケイパビリティ
         │
         ▼ 必要なデータ
[データアーキテクチャ (DA)]
   ・顧客マスタ・行動データ
         │
         ▼ 処理するアプリ
[アプリケーションアーキテクチャ (AA)]
   ・CRM・MAシステム
         │
         ▼ 動くインフラ
[テクノロジーアーキテクチャ (TA)]
   ・クラウド・DB・サーバー

下位レイヤーだけで設計すると、技術都合のシステムが生まれ、事業価値を生みません。

「このシステム、なぜ存在するの？」と経営層から問われ、開発メンバーも業務部門も口ごもる──という場面は現場でしばしば起こります。設計書やテーブル定義は山ほどあるのに、その上の層がないのです。逆に BA が生きている組織は、同じ質問に「顧客獲得ケイパビリティの中核だから」と1行で返ってきます。BA があるかどうかは、この3秒の返答に現れる、と示唆するエピソードです。

BAのモデリング手法

BA を表現する手法は複数あり、用途に応じて使い分けます。絵を描くだけではなく、ステークホルダーと議論できる形であることが重要です。

ケイパビリティベースプランニング

BA を使った代表的な分析手法が Capability Based Planning（CBP）です。どのケイパビリティが強みで、どこが弱いかをヒートマップで可視化し、投資優先順位を決めます。

赤色のケイパビリティに集中投資、緑色は維持、灰色は削減──と戦略判断の見える化ができます。経営会議での意思疎通に極めて有効です。

判断基準①：企業規模

BA の詳細度は企業規模で変わります。中小企業で詳細な BA を作ると過剰で、運用が追いつきません。

判断基準②：変革フェーズ

BA の整備は変革期に最も必要です。平穏な時期に時間をかけて BA を作るより、変革の機会に合わせて整備する方が現実的です。

ケース別の選び方

スタートアップ・50名規模

ビジネスモデルキャンバス（Strategyzer）+ Miro で軽量に維持します。BA 専任者は不要で、創業者や PdM が四半期に1回見直します。フル BA は過剰投資となるため、キャンバス1枚で戦略議論に使える状態が理想です。

中小企業・DX推進中

ケイパビリティマップ2階層 + 主要3〜5プロセスを BPMN 化します。デジタル化対象の業務フローだけ詳細化し、他は粗いままで構いません。IT 部門・業務部門の合同ワークショップで作成し、Miro／Lucidchart で共有します。

中堅企業・EA組織あり

ArchiMate + Confluence or Sparx EA で更新プロセスを運用します。EA チーム3〜5名で全社 BA を管理し、四半期レビューとケイパビリティベースプランニングで投資判断を行います。M&A・事業再編時の統合分析にも活用します。

大企業・規制業種

フル EA（TOGAF 準拠）+ 専門 EA 組織 + AI 対応モデルで構築します。ArchiMate モデルを API で公開し、LLM が BA を参照して影響分析を自動化します。ステークホルダーマップも構造化データで管理し、ガバナンス委員会で変更を承認します。

BA構築の段階別ロードマップ

BA は「いきなりフル構築」では運用が破綻するため、規模に応じた段階的投資が現実的です。

ケイパビリティマップは2〜3階層で止めるのが実務の鉄板です。4階層以上は維持不能で、絵に描いた餅になります。意思決定に使われる粒度が最大の基準で、詳細さよりも「経営層と現場が同じ地図上で議論できるか」を優先します。

BA は「使われる粒度」で止める。詳細に作り込むほど運用されなくなります。

BA運用の鬼門・禁じ手

BA 構築で事故る典型。どれも絵を描いて終わり・使われないBAの結末を生みます。

Amazon の “Working Backwards”（新規サービス検討時に最初にプレスリリースを書く文化）は、BA 思想の成功例として広く知られています。事業の構造を先に見える化することで、AWS・Prime・Alexa のような全く異なる事業を同じ発想で生み出し続けられる組織力を獲得しました。

BA は絵を描くためではなく、組織の意思決定を速くするために存在します。

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

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

• ケイパビリティマップ（作成範囲・階層）
• バリューストリーム（顧客価値の流れ）
• 重要ビジネスプロセス（BPMN化の対象）
• RACIマトリクス（役割と責任）
• ステークホルダーマップ（関係者の洗い出し）
• モデリングツール（ArchiMate／Miro等）
• 更新プロセス（誰が・いつ見直すか）

筆者メモ — 「BA不在」が新規事業を8ヶ月止めた事例

BA の欠如がどれほど重い意思決定コストを生むかを示す事例は、中堅企業から大企業にかけて数多く語り継がれています。

中堅製造業で「新規サブスク事業を立ち上げる」DX プロジェクトが始まり、ケイパビリティマップもバリューストリームもない状態で要件定義を進めた結果、「既存の受注管理システムを使うか、新規 SaaS を入れるか」の議論が半年以上決着せず、プロジェクトが8か月停滞した、という事例はよく報告されます。BA があれば「これは『顧客維持』ケイパビリティの新設であり、既存の『受注処理』とは別系統」と1行で整理できたはずの議論が、組織を横断する度に振り出しに戻る──これが BA 不在の典型的な被害です。

対照的に、Amazon の “Working Backwards” と呼ばれる文化は BA 思想の成功例として語られます。新規サービスを検討する際、最初にプレスリリース（顧客視点のバリューストリーム）を書き、そこからケイパビリティとシステムアーキテクチャに落とす──という規律を全社に徹底したことで、AWS・Prime・Alexa といった全く異なる事業を、同じ発想で生み出し続けられる組織力を獲得しました。

どちらの事例も「事業の構造を先に見える化する」ことの価値を裏返しに示しています。BA は絵を描くためではなく、組織の意思決定を速くするために存在する、と突きつける事例群です。

どう選べばいいのか

BA の核心は事業を技術と接続可能な形で見える化するという発想です。BA がないと「このシステム、なぜ存在するの？」に答えられず、技術都合のシステムが量産されます。事業戦略・ケイパビリティ・バリューストリーム・プロセス・組織を統合的にモデル化し、データ・アプリ・テクノロジー層の判断根拠として機能させるのが EA の正しい姿です。ケイパビリティは組織変更があっても変わりにくい安定軸で、2〜3階層で止めて実用性を保つのが定石です。詳細さではなく「意思決定に使われる粒度」であることが価値を決めます。

もう一つの決定的な軸はAIが読めるBAという要請です。LLM・AI エージェントが経営戦略や業務改善の提案を行う時代、PowerPoint・Excel に埋もれた BA は機能しません。ArchiMate 等の構造化モデルで API 参照可能な状態を作り、ケイパビリティを定量化し、継続更新の習慣を持つ企業だけが、AI 活用でも競争力を持てます。

AI時代の判断軸

AI 駆動開発（バイブコーディング）と AI 活用が前提になると、BA はAIに事業を理解させるための教材として再定義されます。LLM・AI エージェントが経営戦略・業務改善の提案を行う時代には、機械が読めるBAが競争力の源泉になります。

AI が事業を分析するには、AI が読める形式の BA が必要です。「我が社のケイパビリティマップを AI に渡して分析させる」時代が来ています。

AI 時代の BA は機械が読めて更新されるもの。紙の上の図表では競争できません。

選定の優先順位

1. ケイパビリティマップを安定軸に — 組織変更に強く、2〜3階層で止める
2. 規模に応じて詳細度を調整 — スタートアップはキャンバス、大企業はフル EA、過剰投資は禁物
3. 変革期にこそ整備 — DX・M&A・事業再編の機会に合わせて作る
4. 機械可読な形式で維持 — ArchiMate + API 公開で継続更新、AI の教材に

AIにBA情報を読ませて経営分析に活用する

ケイパビリティマップや業務フロー図がArchiMate等の構造化形式で管理されていれば、AIに渡して「この事業のボトルネックはどこか」「M&A後の重複ケイパビリティはどれか」を分析させることが可能です。PowerPointの手書き図ではAIが構造を理解できないため、分析対象にできません。

バリューストリームの定量化とAI予測

バリューストリーム（顧客価値を生み出す一連のプロセス）の各ステップにリードタイム・コスト・エラー率の数値を付けておけば、AIが「どこを改善すれば最も効果が高いか」を定量的に分析できます。定性的な説明だけのBAでは、AIは改善提案の優先度を判断できません。

「事業の構造を見える化し、AIにも読ませる」ことが肝心。BA は全技術判断の起点です。

この記事に関連する記事

まとめ

本記事はビジネスアーキテクチャについて、ケイパビリティ・バリューストリーム・BPMN・RACI・ステークホルダー・ArchiMate・AI時代の機械可読BAまで含めて解説しました。如何だったでしょうか。

ケイパビリティを安定軸に2〜3階層で止め、規模に応じて詳細度を調整、変革期に整備、機械可読な形式で維持する。これが2026年のBA設計の現実解です。

次回はデータアーキテクチャ（DA）（全社データ戦略・MDM・データカタログ）について解説します。

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

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

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