ビジネスケイパビリティ

組織が「何ができるか」を表す業務上の能力単位。技術や組織構造とは独立して、事業として提供している価値を粒度別に整理するためのエンタープライズアーキテクチャ概念。BIZBOK Guide や TOGAF で体系化されている。

概要

「商品を仕入れる」「在庫を管理する」「顧客に配送する」「決済を処理する」など、 組織が提供している『能力』 を、システムや部署の構造から切り離して棚卸しする考え方。「誰が」「どのシステムで」ではなく 「何ができるのか」 で定義する点が特徴。

EC 事業のビジネスケイパビリティ例：
├─ 商品管理
│   ├─ 商品マスタ管理
│   ├─ カテゴリ管理
│   └─ 価格管理
├─ 在庫管理
│   ├─ 在庫数把握
│   └─ 在庫引当
├─ 受注・販売
│   ├─ 注文受付
│   ├─ 決済処理
│   └─ キャンセル
└─ 物流
    ├─ ピッキング
    └─ 配送手配

プロセス・組織との違い

観点	ビジネスケイパビリティ	ビジネスプロセス	組織
答える問い	何ができるか	どうやるか	誰がやるか
安定性	高い（事業構造が変わらない限り変わらない）	中（業務改善で変わる）	低（組織変更で頻繁に変わる）
表現	名詞中心（「在庫管理」）	動詞中心（「在庫を引当てる」）	部署名・役職
用途	事業全体の俯瞰、システム計画	業務手順の改善	責任分担

ケイパビリティは 最も変わりにくい層 なので、システム設計の基準として安定している。

ビジネスケイパビリティマップ

組織のケイパビリティをツリー構造で網羅的に可視化したものを ビジネスケイパビリティマップ と呼ぶ。

階層	例
Level 1	商品管理 / 在庫管理 / 受注販売 / 物流
Level 2	商品マスタ管理 / カテゴリ管理 / 価格管理
Level 3	商品登録 / バリエーション管理 / 画像紐付け

通常 3〜4 階層で表現する。Level 3 以下に降りすぎると業務プロセスと混ざるので注意。

DDD との関係

ビジネスケイパビリティは DDD の Bounded Context と 強く対応 する。

ビジネスケイパビリティ	Bounded Context
商品マスタ管理	Catalog Context
在庫管理	Inventory Context
受注・販売	Sales Context
配送手配	Fulfillment Context

ケイパビリティマップが整理されていると、Bounded Context の境界線を 業務側の言葉で 引ける。エンジニア都合で恣意的に切らずに済む。

AI 駆動開発で重要な理由

AI 駆動開発では、エンジニアに 要件定義を主導する責務 が求められる。そのために、ビジネスケイパビリティの理解が決定的に重要になる。

場面	ケイパビリティ理解がない場合	ケイパビリティ理解がある場合
壁打ちでスコープを決める	「とりあえず作る」になる	「在庫引当ケイパビリティに閉じる」と境界を引ける
AI への指示	機能名だけで雑に伝える	「Inventory Context の在庫引当ケイパビリティを実装」と伝えられる
既存資産の流用判断	同じ機能を二重実装する	既存ケイパビリティに乗せられるか判断できる
業務担当者との対話	技術用語で会話してしまう	ケイパビリティ名で共通言語を持てる

これまで仕様書通りに実装する役割だったエンジニアにとって、ケイパビリティを 自分で見出す力 はハードルが高い。だからこそ、業務担当者との壁打ち・現場観察を通じて、段階的に養っていく必要がある。

ビジネスケイパビリティを身につける道筋

ステップ	やること
1	自社の事業を 1 ページで表現する（Level 1 を 5–10 個列挙）
2	各ケイパビリティを Level 2 に分解する
3	既存システムをケイパビリティ単位にマッピングする
4	重複・欠落・過剰実装を発見する
5	Bounded Context の境界候補として再整理する

このプロセスを 1 度通過すると、業務担当者と「ケイパビリティ名」で対話できるようになり、壁打ちの質が一段上がる。

開発手法ガイド：DDD 編 — ケイパビリティと Bounded Context の対応
壁打ち・規模判定編 — ケイパビリティ理解が壁打ち品質を決める
CTS-EC 共通商品マスタ — ケイパビリティ単位で 3 層構成にした実例

概要

プロセス・組織との違い

ビジネスケイパビリティマップ

DDD との関係

AI 駆動開発で重要な理由

ビジネスケイパビリティを身につける道筋

関連記事

関連用語