PowerPointでビジネスケイパビリティマップを作る方法

妥当なレベル1(L1)のビジネスケイパビリティは、7〜10個程度に収まるのが一般的です。問題はその下の階層です。エンタープライズアーキテクチャの実務家が公開しているグローバル製造業の実例では、L1ドメイン8個に対してL2ケイパビリティが45個――1ドメインあたり平均5.6個という計算になりますが、この平均には大きな偏りが隠れています。経理はL2ケイパビリティが4個しかないかもしれません。オペレーションは14個あるかもしれません。L2ケイパビリティ1個につき箱1つ、しかも全ドメイン共通のサイズというテンプレートで組んだケイパビリティマップは、このばらつきに出会った瞬間に崩れます。14個を抱えるドメインは文字が重なり合う壁になり、4個しかないドメインは同じ大きさの箱の中でほとんど空白のまま隣に並びます。

固定グリッドのケイパビリティマップが、そもそも成立しない理由

ケイパビリティマップの役割は、組織が「何をできるか」を、組織図からも、現在のプロセスからも、今年たまたまその機能を率いている人からも独立して示すことです。そして、まさにこの独立性こそが、マップの形をあらかじめ決められない理由でもあります。テンプレートが「1ドメインあたりケイパビリティ4個、均等なグリッド」のようなデフォルトを置くのは、実際のケイパビリティ一覧がまだ手元にない段階でテンプレートが置ける唯一の仮定だからです。実際の一覧ができた瞬間にこの仮定は崩れます。ドメインごとのケイパビリティ数は組織の複雑さを反映しており、複雑さは事業内で均等に分布することなどまずないからです。

コマース色の強い小売企業のケイパビリティマップでは、チャネル管理・プライシング・プロモーション・ロイヤルティ・マーチャンダイジングを抱えるマーケティング&営業ドメインが分厚くなり、法務・コンプライアンスドメインは相対的に薄くなるのが典型です。規制業種である保険会社では逆になります――リスク&コンプライアンスが重くなり、マーケティングは軽くなります。どちらのパターンも「その企業の何かがおかしい」わけではありません。マップが本来の仕事――その組織の複雑さが実際どこに集中しているかを示す――を果たしている証拠です。固定グリッドはこのシグナルを示せません。すべてのドメインを同じ複雑さに見せかけてしまうからです。

直感に反する点: ケイパビリティ数が多い=重要というわけではない

ある箱があふれ始めると、それを「大きい=重要なドメイン」として扱いたくなります。面積が大きいことが視覚的に重要性を裏付けているように見えるからです。しかしこの直感は、名指しして注意する価値があるほどの頻度で逆転します。ケイパビリティ数が示すのは、そのドメインの業務がどれだけ細かく分解されているかであって、戦略上どれだけ重要かではありません。製造業のマップでオペレーションドメインが14個のケイパビリティを抱えるのは、通常オペレーション業務が入庫物流・生産計画・品質管理といった形で、独立した名前を持つ活動にきちんと分解されていることを意味します。同じマップで経営企画ドメインがケイパビリティ4個しかなくても、経営企画が重要でないことを意味しません。戦略立案の仕事がそこまで細かく(しばしば、細かくすべきでない)分解されていないだけです。戦略的な仕事は本質的にオペレーション業務ほどモジュール化しにくいためです。

したがって、ドメインの箱をケイパビリティ数でサイズ調整することは、重要性についての主張ではなく、粒度についての主張です。この2つを混同すると、ケイパビリティマップが「オペレーションの方が経営企画より重要だ」と意図せず主張してしまうことになりかねません。これはTOMやDXの運営委員会向けスライドが暗に伝えたい内容では決してありません。かといって、サイズの差を消してしまうのも正解ではありません――すべてのドメインを無理やり同じ視覚的重みに揃えたマップは、本来見せる価値のある情報を失います。正しい対応は、ケイパビリティ数に応じて意図的にサイズを変え、かつそれが「粒度の違い」であることをスライドの文脈で明示することです。そうすれば読み手は箱の大きさを「どれだけ重要か」ではなく「どれだけ細かく分解されているか」として読み取ります。

4〜14個のばらつきでも崩れないグリッドの組み方

このばらつきに耐える組み方は、各L1ドメインを共有グリッドのセルではなく、自分自身のケイパビリティ数に合わせてサイズを決める独立したコンテナとして扱うことです。

ステップ1 ― 列数を固定し、箱のサイズは固定しない。 画面上部に並べるL1ドメインの数を決めます(一目で見渡せるマップとして実務上妥当とされる範囲は7〜10個。10個を大きく超える場合は、たいてい2つのドメインを統合すべきサインです)。各ドメイン列の幅は均等にします――幅はケイパビリティ数について何も語らないため、ここは揃えておくべき部分です。幅が不揃いだと単なるレイアウトミスに見えてしまいます。変わるのは高さです。

ステップ2 ― 各列のケイパビリティの積み上げを、その列自身のL2件数に合わせてサイズ調整する。 ドメイン列の中では、L2ケイパビリティ1つにつき小さな箱を1つ積み上げます。10ポイント文字・罫線0.5ptで高さ約0.9cm、箱同士の間隔は約0.15cmが目安です。4件のドメインなら積み上げの高さは約4cm、14件のドメインなら約14cmになります。14件のドメインの箱を無理に0.4cm程度まで圧縮して他と揃えようとしないでください。これは3C分析スライドで競合の弾条6つを3つ分の箱に押し込んで文字を縮小するのとまったく同じ失敗です。理由を言葉にできなくても、読み手は圧縮されて読みにくい箱を「無理に詰め込んだ」と直感的に受け取ります。

ステップ3 ― すべてのドメイン見出しを同じ上端に揃え、下端はそれぞれの件数任せにする。 8個(あるいは9個、10個)のドメイン見出しラベルはすべて同じy座標の1行に揃え、フォントサイズも高さも統一します。その共有ラインの下で、各列のケイパビリティの積み上げは、その列自身の件数が必要とする分だけ下に伸びていきます。結果として、上端は一直線、下端はオペレーションが経営企画よりはるかに下まで伸びるというギザギザの形になります。これこそが、マップが自分のデータを隠さずそのまま見せている証拠です。

ステップ4 ― 各ドメイン列を1つのオブジェクトとしてグループ化する。 あるドメインの見出し・ケイパビリティの積み上げ全体・背景の塗りを選択し、Ctrl+Gでグループ化して「Domain_Operations」のように名前を付けます(「グループ7」のままにしない)。スコープレビューであるドメインにケイパビリティが2つ追加されたとき――「自分たちがやっていると思っていたこと」が、その機能の実際のリーダーとの最初のワークショップを経て「実際にやっていること」に修正される、という場面でよく起きます――それは1つのグループに箱を2つ挿入し、その列の高さを伸ばすだけの作業であり、変更のなかった他の7つのドメインを測り直す必要はありません。

第4階層を作らずに3階層を守る

エンタープライズアーキテクチャの実務では、ケイパビリティマップは3階層までに留めるべきという点でおおむね一致しています――L1ドメイン、L2ケイパビリティ、そして特定のL2がどうしても分解を必要とする場合のオプションのL3です。3階層を超えると、マップは安定したケイパビリティの記述をやめ、プロセスステップの記述に変わっていきます。プロセスはケイパビリティよりはるかに頻繁に変化・再編されるため、そもそもプロセスマップではなくケイパビリティマップを作る理由そのものが失われます。この違いはメソドロジーのメモの中だけの話ではなく、スライドの上でも意味を持ちます。ケイパビリティマップは組織図や現在の実行方法から独立して「何ができるか」に答えるのに対し、プロセスマップは特定のチームの中で実際にどう仕事が進むかを、手順・判断・引き継ぎの連なりとして示します。どちらも箱の図に見えるため混同されがちですが、見分け方は箱の名前付けです。アウトカムとして名付けられているか(「サプライヤー関係を管理する」)、活動として名付けられているか(「発注書を発行する、請求書を受領する、支払いを承認する」)です。

スライドの上でこれが意味するのは、TOMワークショップでほぼ毎回出てくる「この複雑なドメインだけ第4階層を足したい」という要望に抵抗することです。受注管理のようなL2ケイパビリティが1つの箱では収まらないほどの解像度を本当に必要とする場合、正しい対応はそのL2の下にL3のサブボックスをネストすること(受注受付・受注充足・返品処理)であって、マップ全体に構造的な第4階層を導入することではありません。L3は視覚的に従属させておきます――文字を小さく、罫線を細く、親のL2ボックスの下にインデントする――ことで、マップ全体が新しい階層を抱え込んだのではなく、1つのケイパビリティの詳細情報として読めるようにします。

異なる2つの業態で見え方がどう変わるか

TOM再設計のために初めてケイパビリティマップを作るSaaS企業では、たいていテクノロジー&データドメインが突出して分厚くなります――プラットフォームアーキテクチャ、データ基盤、セキュリティ、インテグレーションなど、それぞれが独立したケイパビリティとして数えられ、合計で12個を超えることも珍しくありません。その隣で経理ドメインは5〜6個程度と相対的に薄くなります。同じ演習をDXプログラムのために行う地方銀行では、これが逆転するのが一般的です。リスク&コンプライアンスと顧客対応がケイパビリティ数の大半を占め、テクノロジーはむしろ薄くなることがあります。銀行の基幹処理が、細かく分解された多数のケイパビリティではなく、少数の広いケイパビリティの上に成り立っているためです。

この4ステップの組み方自体は、この2つのケースの間で何も変わりません。変わるのはどの列が高くなるかだけであり、それこそが、実際のケイパビリティ一覧ができる前に列の高さを決められない理由そのものです。SaaS企業のマップと銀行のマップが同じテンプレートを共有すべきでない――テンプレートを共有することこそが、それぞれの組織の本当の複雑さがどこにあるかを誤って伝えるスライドを生み出す原因になります。

FAQ

ビジネスケイパビリティマップのL1(レベル1)は何個くらいが適切ですか?

一目で見渡せて、意味の異なる機能を1つのバケツに押し込まないようにするには、L1ドメインは7〜10個程度に収めるのが実務上の相場です。組織によっては8個のところも14個のところもありますが、その範囲を大きく超える場合はたいてい2つのドメインが重複しており、統合すべきサインです。

ケイパビリティマップとプロセスマップの違いは何ですか?

ケイパビリティマップは組織が「何をできるか」を示すもので、安定していて、アウトカム志向で、組織構造から独立しています。プロセスマップは特定のケイパビリティが実際に「どう実行されるか」を、手順・判断・引き継ぎの連なりとして示すもので、ケイパビリティ自体よりはるかに頻繁に変化します。ケイパビリティの箱はアウトカムとして名付けられ(「サプライヤー関係を管理する」)、プロセスの箱は活動として名付けられます(「発注書を発行する」)。

すべてのドメインのケイパビリティ数を揃えるべきですか?

いいえ。均等な分布を無理に作ると、実態を誤って伝えることになります。ケイパビリティ数が示すのはそのドメインの業務がどれだけ細かく分解されているかであって、ドメインの重要度ではありません。実際の偏りを正直にサイズへ反映したマップの方が、無理に揃えて整って見せたマップより多くの情報を伝えます。

ケイパビリティマップは何階層まで掘り下げるべきですか?

ほとんどのマップはL1ドメインとL2ケイパビリティの2階層でカバーできます。特定のL2がより高い解像度を必要とする場合に限り、選択的にL3を設ける程度が妥当です。それ以上掘り下げると、多くの場合マップはプロセスの記述に踏み込んでしまっており、それはケイパビリティマップの第4階層ではなく、別のプロセスマップとして切り出すべき内容です。

Microsoft AppSourceに掲載されているAdvisioは、実際のL1/L2ケイパビリティ一覧から、ドメインのグリッドをネイティブで編集可能なPowerPointの図形として直接組み立てます。各ドメイン列を自身のケイパビリティ数に応じてサイズ調整し、すべての見出しを同じ上端に揃えるため、2回目のワークショップを経てケイパビリティ数が40個から55個に増えても、マップは列が伸びるだけで、作り直しにはなりません。多くのケイパビリティマッピングの演習が最終的に行き着くターゲットオペレーティングモデル(TOM)スライドも、同じエンジンで組み立てられます。