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

本記事について

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

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

このカテゴリの他の記事

概要 ― 企業の地図を描く4層モデル ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-ea-overview/

データアーキテクチャ ― 全社データを戦略資産として設計する ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-ea-da/

アプリケーションアーキテクチャ ― 全社システム群を地図化する ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-ea-aa/

テクノロジーアーキテクチャ ― 企業の技術選択の憲法 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-ea-ta/

EAフレームワーク ― TOGAF+ArchiMateをTailorして使う ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-ea-framework/

なぜBAが必要か

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

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

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

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

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

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

BAの主要構成要素

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

要素	内容
ビジネス戦略	ビジョン・目標・KPI（Key Performance Indicator＝重要業績評価指標）
ビジネスケイパビリティ	「何ができるか」の能力
バリューストリーム	価値を生む流れ
ビジネスプロセス	業務手順・手続き
組織	部署・役割・責任
ステークホルダー	顧客・取引先・規制当局
ビジネスサービス	提供するサービスの目録

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

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

flowchart TB
    RETAIL([小売業])
    CUST[顧客管理]
    PROD[商品管理]
    SALE[販売]
    C1[顧客獲得]
    C2[顧客維持]
    C3[顧客支援]
    P1[商品企画]
    P2[在庫管理]
    P3[価格管理]
    S1[店舗販売]
    S2[EC販売]
    S3[法人営業]
    RETAIL --> CUST --> C1
    CUST --> C2
    CUST --> C3
    RETAIL --> PROD --> P1
    PROD --> P2
    PROD --> P3
    RETAIL --> SALE --> S1
    SALE --> S2
    SALE --> S3
    classDef root fill:#fef3c7,stroke:#d97706,stroke-width:2px;
    classDef l1 fill:#dbeafe,stroke:#2563eb;
    classDef l2 fill:#dcfce7,stroke:#16a34a;
    class RETAIL root;
    class CUST,PROD,SALE l1;
    class C1,C2,C3,P1,P2,P3,S1,S2,S3 l2;

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

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

バリューストリーム

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

用途	内容
業務改善	どこがボトルネックか
デジタル化	どこを自動化すべきか
顧客体験	接点の洗い出し
システム投資	優先順位の判断

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

ビジネスプロセス

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

記法	特徴
BPMN 2.0	業界標準・ツール多数
UMLアクティビティ図	開発寄り
フローチャート	軽量・簡易
DFD	データ流れ中心

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

組織とガバナンス

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

要素	内容
組織図	部署・階層
役割と責任（RACI）	Responsible／Accountable／Consulted／Informed
意思決定権限	承認ライン・金額基準
ガバナンス委員会	アーキテクチャ委員会等

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

ステークホルダーマップ

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

ステークホルダー	典型的な関心事
顧客	品質・価格・体験
従業員	働きやすさ・給与・成長
取引先	取引条件・決済
株主	収益性・成長性
規制当局	法令遵守・安全性
社会・地域	ESG（Environment／Social／Governance＝環境・社会・ガバナンス）・環境・雇用

BAと下位レイヤーの関係

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

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

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

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

BAのモデリング手法

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

手法	用途
ケイパビリティマップ	能力の全体像
バリューストリームマップ	価値創出の流れ
BPMN	プロセス詳細
ArchiMate	EA統合モデリング言語
ビジネスモデルキャンバス	事業モデル

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

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

状態	色
戦略的優位あり	緑
競合同等	黄
劣後	赤
不要	灰

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

判断基準①：企業規模

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

規模	推奨
スタートアップ（〜50名）	ビジネスモデルキャンバス程度
中小（〜500名）	ケイパビリティマップ + 主要プロセス
中堅（〜5000名）	本格 BA + EA チーム
大企業（5000名以上）	フル EA + 専門組織

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

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

変革フェーズ	BAの役割
定常運用	最低限の維持
DX 推進	現状 BA 作成・TO-BE 設計
M&A	両社の 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

それは一部でしかありません。ケイパビリティ・バリューストリーム・戦略も含まれます。

BAは1回作れば終わり

事業変化とともに更新が必要です。生きているモデルとして扱います。

詳細であるほど価値がある

逆です。意思決定に使われる粒度でないと作っただけの紙になります。使われるなら粗くても構いません。

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

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

フェーズ	期間目安	成果物	投資人員
①スタートアップ	1日〜1週間	ビジネスモデルキャンバス1枚	創業者兼任
②中小企業DX推進	1〜3か月	ケイパビリティマップ2階層 + 主要3〜5プロセスBPMN	0.5〜1名
③中堅企業	〜1年	フルケイパビリティマップ + RACI + ステークホルダーマップ	EAチーム3〜5名
④大企業	継続的	ArchiMateフルモデル + 四半期レビュー + CBP（Capability Based Planning）	専門EA組織 10名〜
⑤規制業種	継続的	フル + 業界特化（BIAN等）+ 監査対応	中央EA + 事業部EA

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

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

BA運用の鬼門・禁じ手

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

禁じ手	なぜダメか
ケイパビリティマップを4階層以上の詳細度で作る	維持不能、3年で放置・陳腐化
BAを経営コンサルに丸投げ	技術判断との乖離、使えないBAが生産される
組織図と業務フローだけでBA完成と誤解	ケイパビリティ・バリューストリーム・戦略が欠落
PowerPoint・Wordで手書き図のみ	AI読解不能、API連携不可、静的な資料止まり
BAを1回作って放置	事業変化に追従せず、3年で全面書き直し
業務部門を巻き込まずIT部門単独で構築	業務実態との乖離、現場から無視される
ケイパビリティを組織名で分割	組織変更でBAが崩壊、能力単位で安定軸に
BAに数値（KPI）を紐付けない	定性的な説明だけで、AIも人間も判断に使えない
新規事業でBAを作らず要件定義を開始	中堅製造業の「新規サブスク事業8か月停滞」パターン
「リファレンスモデル」（BIAN等）を活用せず自力でゼロから作る	業界知識の蓄積を無視、無駄な労力

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

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

AI時代の視点

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

AI時代に有利	AI時代に不利
構造化されたBA（ArchiMate等）	手書き図・PowerPoint
ケイパビリティの定量化	定性的な説明のみ
APIで参照可能なモデル	Excel で埋もれたデータ
継続更新の習慣	3年前のまま放置

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

AI 時代の 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 活用でも競争力を持てます。

選定の優先順位

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

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

まとめ

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

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

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

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

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