---
title: PowerPointでターゲットオペレーティングモデル(TOM)スライドを作る手順
description: TOM(ターゲットオペレーティングモデル)の4階層ピラミッドとPeople/Process/Technology列をPowerPointで組む具体的な手順を解説。SmartArtで挫折する理由と、列の高さを揃えて失敗するパターンとその直し方、事業部が複数ある場合の応用まで扱う。
image: https://www.advis-io.com/hubfs/blog-key-visuals/083-target-operating-model-powerpoint.ja.kv.png
---

[![logo\_transparent-Apr-12-2025-09-23-39-9623-AM-1](https://www.advis-io.com/hubfs/logo_transparent-Apr-12-2025-09-23-39-9623-AM-1.svg)](https://www.advis-io.com/en/?hsLang=ja)

- [BLOG](https://www.advis-io.com/blog?hsLang=ja)
- [ABOUT](https://www.advis-io.com/about?hsLang=ja)

[今すぐはじめる](https://marketplace.microsoft.com/en-us/product/advisioinc1760912844242.advisio-202604?tab=Overview)

コンサル仕事術

# PowerPointでターゲットオペレーティングモデル(TOM)スライドを作る手順

TOM(ターゲットオペレーティングモデル)の4階層ピラミッドとPeople/Process/Technology列をPowerPointで組む具体的な手順を解説。SmartArtで挫折する理由と、列の高さを揃えて失敗するパターンとその直し方、事業部が複数ある場合の応用まで扱う。

[Advisio編集部](https://www.advis-io.com/ja/blog/author/advisio-editorial)

 9月 26, 2026

---

組織・業務改革プロジェクトに入って2週間、ステアリングコミッティから「金曜までにTOMのスライドを」と言われる。どこかのファームのデックで見たことがある、あのピラミッドと3本の列が入ったスライドのことだと分かっていても、具体的な組み方までは誰も教えてくれない——というのはよくある話だ。PowerPointでTOM(ターゲットオペレーティングモデル)スライドを最速で組む方法は、上から「ビジョン・戦略」「オペレーティングモデル」「組織設計」「ガバナンス・レポーティング」の4階層ピラミッドを、SmartArtではなくグループ化した四角形で作り、中間の2階層に「People」「Process」「Technology」の3列を縦に重ねる、というものだ。SmartArtのピラミッドレイアウトはこの列の重ね合わせに対応していないため、テンプレートギャラリーから作り始めた人の多くがここで手が止まる。

## TOMスライドが同時に表現している2つの軸

TOMスライドが作りにくいのは、PowerPointの操作が難しいからではなく、1枚のスライドで2つの軸を同時に成立させる必要があるからだ。縦方向のピラミッドは意思決定の階層を表す。頂点の「ビジョン・戦略」はその組織が何のために存在し、何を最適化するのかを示し、次の「オペレーティングモデル」はその実現のために業務をどう構造化し提供するかを示す。さらに下の「組織設計」は誰がそれを担い、どうグルーピングされるかを示し、最下段の「ガバナンス・レポーティング」は意思決定の仕組みそのものをどう運営し追跡するかを示す。People・Process・Technologyはこの階層と直交する形で、中間の2階層を貫く3本のイネーブラー列として置かれる。人の組織、業務の流れ、それを支えるテクノロジーは、オペレーティングモデルの水準でも組織設計の水準でも別々に定義する必要があるからだ。

テンプレートが用意してくれるのはこの格子そのものまでで、縦に読んでも横に読んでも筋が通る中身までは用意してくれない。People列を上から下まで縦に読めば、オペレーティングモデルの意図が組織設計の詳細にどうつながるかが見え、オペレーティングモデルの行を横に読めば、その水準で人・プロセス・テクノロジーの意思決定がどう関係し合っているかが見える——この2方向の読み方が両方成立して初めて、TOMスライドとして機能する。

ガバナンス・レポーティングの階層をPeople/Process/Technologyの3列にそのまま当てはめようとするのは、このスライドが過剰に作り込まれる典型的な原因だ。ガバナンスは意思決定権限・会議体の頻度・エスカレーションルート・報告するKPIなど、3列のどれか一つに属するものではなく3列すべてを横断する内容なので、無理に3セルに分けるより、幅いっぱいの1本の帯として置いたほうが読みやすい。

## PowerPointでTOMピラミッドを組む手順

テンプレートを開いた直後ではなく、実際の中身を入力し始めてから崩れない組み方は次の順序だ。

1. **4階層の中身をPowerPointの外で先に固める。**「ビジョン・戦略」「オペレーティングモデル」「組織設計」「ガバナンス・レポーティング」それぞれについて、テキストファイルやノート欄に1〜3個の箇条書きを書き出す。**よくある失敗:** 空のテンプレートに合わせて図形サイズを決めてしまい、後から「組織設計」の階層に5項目必要だと分かって作り直す羽目になる。
2. **4階層をSmartArtの「ピラミッドリスト」ではなく、グループ化した四角形で組む。**\[挿入\]\>\[図形\]\>\[四角形\]で、上から下に向かって幅が広くなる4つの四角形を、同じ垂直軸に中央揃えで配置する。三角形の輪郭がなくても、この配置だけでピラミッドとして読める。**よくある失敗:** SmartArt標準のピラミッドから始めてしまうこと。テキストが図形の外側の吹き出しに入る仕様なので、階層ごとの比率調整も、後から列の格子を重ねることもできない。
3. **三角形の斜辺が必要な場合は台形図形を使う。**\[挿入\]\>\[図形\]\>\[台形\]で古典的なピラミッド型のシルエットを作り、180度回転させて広い辺を下にする。**よくある失敗:** Process列やTechnology列のラベルが長いまま上段の狭い台形に押し込むこと。上段は幾何学的に幅が狭いため、台形の幅を決める前にラベルの文字量を確認しておかないと、真っ先にここで文字があふれる。
4. **People・Process・Technologyの3列を、中間2階層だけにまたがる縦長の四角形として重ねる。**塗りなし+枠線、または低い不透明度の塗りにし、右クリックで「最前面へ移動」を明示的に指定する。**よくある失敗:** ピラミッドの図形を前面に残してしまい、列の境界線が完全に隠れて、投影したときにただの4段リストに見えてしまうこと。
5. **ピラミッド本体と列のオーバーレイは、1つにまとめず別々の2つのグループにする。**ここが軽視されがちだが重要な点で、全体を1つのグループにしていると、来週「Processにもう1項目追加してほしい」と言われたときにグループ解除して直す作業が、他の図形の位置ずれを引き起こすリスクを伴う。**よくある失敗:**「とりあえず整理のため」に早い段階で全体を1グループ化してしまうこと。最初の修正依頼が来るまでは問題ないが、それ以降は毎回同じ整列作業をやり直すことになる。
6. **階層名は図形の中ではなく、左マージンのラベルとして外に出す。**各階層の左側にテキストボックスを追加し、「ビジョン・戦略」「オペレーティングモデル」「組織設計」「ガバナンス・レポーティング」と記す。**よくある失敗:** 階層名を図形内の本文と同じ場所に置くこと。箇条書きが2行に折り返した瞬間にラベルと衝突し、改訂のたびにテキストボックスを微調整する作業が発生する。
7. **色をつける前に、まず1本のグリッドに揃える。**4つの階層を選択して\[配置\]\>\[上下中央揃え\]→\[上下に整列\]、3つの列を選択して\[上揃え\]→\[左右に整列\]を使う。これは中身が入った後に行う作業で、空の図形に対してグリッドを組んでも実際の文字量では崩れる。**よくある失敗:** 階層間の余白を目分量で決めてしまうこと。配布資料にしたときに「なんとなく揃っていない」と評される最大の原因はここにある。
8. **ガバナンス・レポーティングの土台帯は、上のピラミッドと完全に同じ幅にする。**ガバナンスを4段目のピラミッド階層ではなくフッター的な帯として見せる場合(スライドの主眼がガバナンスではなくオペレーティングモデルにあるときによくある構成)、スライドの余白ではなく、ピラミッドの最も広い階層の外側の端に合わせる。**よくある失敗:** ガバナンス帯がピラミッドより数ポイントだけ狭い・広いこと。意識に上らない程度の差でも、レビュアーには「なんとなく整っていない」印象として伝わる。

中身を先に固めてから1本のグリッドに揃える、という順番は、修正のたびに崩れない[MECEなイシューツリー](https://www.advis-io.com/ja/blog/issue-tree-logic-tree-powerpoint-ja?hsLang=ja)を組むときの考え方と同じだ。ボックスとコネクタで組むスライド全般に使える整列の手順として、そちらの記事も参考になる。

## 案件の途中で中段の階層とP/P/T列が崩れる理由

実際のプロジェクトでは、オペレーティングモデルと組織設計の2階層が最も動きやすい。シェアードサービス層が追加されたり、ITがインフラとアプリケーションに分割されたり、機能別組織が地域別組織に置き換わったりする。4階層を高さ固定の1つの積み重ねとして作ってしまうと、どこか一つの階層にサブ項目を1行追加するだけで、その下のすべての階層を手作業でサイズ調整し直すことになる。列側にも同じ問題が逆方向に起きる。「バランスを取るため」にPeople・Process・Technologyのセルを同じ高さにしてしまいがちだが、それぞれの中身の分量は実際にはほぼ揃わないので、これは完全に逆効果になる。

**現場メモ:** 外資系コンサル時代に初めて作ったTOMスライドは、隣のPeople列(1行)に合わせて固定した高さのProcessセルに、6項目の箇条書きを詰め込んでいた。パートナーのアシスタントが、Processのテキストを箱に収めるためにフォントサイズを縮めるだけの作業に40分を費やしていたのを覚えている。本当に直すべきだったのは、幅さえ揃っていれば高さを揃える必要はなかった点で、Processのセルを他の2つよりおおよそ2倍の高さにする——それだけで済む話だった。誰かが「なぜセルの高さを揃える前提にしているのか」と一言聞くまで、それに気づく人がいなかった。

具体例で見てみる。中堅損害保険会社の請求(クレーム)対応機能について、オペレーティングモデルの行がこうなっているとする。**People**——「クレーム担当者はプロセス工程ではなく商品ラインごとに編成」(1行)。**Process**——「新しいワークフローでは事故受付(FNOL)と査定を分離。クレームは金額に応じて自動的にルーティングされ、複雑・高額な案件は専任シニア査定者のキューにエスカレーションされる」(3行)。**Technology**——「クレーム管理システムが現行の2つのレガシーシステムを置き換える」(1行)。3つのセルをProcessの高さに合わせてしまうと、PeopleとTechnologyのセルがほぼ空白のまま残り、分析自体は問題なくても「詰めが甘い」という印象を与えてしまう。行の高さを一番長いセルの自然な分量に合わせ、残る2つのセルには文字を無理に引き伸ばさず余白を残す形にすれば、同じ中身が「意図的に非対称な行」として読める。

![TOMスライドのPeople・Process・Technology行の比較図。3列を同じ高さに固定して文字が縮小する例と、一番長いセルに合わせて行の高さを調整した例。](https://www.advis-io.com/hubfs/blog-figures/083-target-operating-model-powerpoint-fig1.ja.png)

図: People・Process・Technologyの3列を一律の高さに固定した場合(上)と、最も分量の多いセルに合わせて行の高さを調整した場合(下)。

## AIがリサイズの手間を引き受ける部分

ワークストリームが追加されるたび、あるいは事業計画のスコープが変わるたびに同じリサイズ作業が繰り返されるからこそ、ここはデモ映えのためではなく実務としてAIレイアウトツールが効いてくる部分だ。4つの階層名とPeople/Process/Technologyそれぞれの箇条書きをAdvisioに渡すと、一律の格子に押し込むのではなく、各階層・各列のセルをその中身に合わせて個別にサイズ調整する。整列が終わったピラミッドを、Processに1項目追加されるたびに手作業で組み直す必要がなくなるということだ。[Microsoft AppSource](https://marketplace.microsoft.com/en-us/product/advisioinc1760912844242.advisio-202604?tab=Overview)に掲載されており、生成される図形はネイティブに編集可能なPowerPointの図形なので、パートナーレビュー後の修正も通常のクリック&タイプ操作で完結する。

## 提出前の仕上げチェックリスト

- 4つの階層が同じ中心線と一定の余白で揃っているか——目視ではなく\[整列\]で確認したか。
- People/Process/Technologyの区切り線が、対象となる中間2階層だけにまたがっているか(ピラミッド全体の高さになっていないか)。
- 各行の高さが、隣のセルに合わせて伸縮されたものではなく、最も分量の多いセルの自然な高さになっているか。
- 階層名が図形の外・左マージンに配置され、折り返した本文とラベルが衝突しないか。
- ガバナンス・レポーティングの土台帯が、ピラミッドの外側の幅と完全に一致しているか。
- 塗り色に一貫したロジックがあるか(例: 土台に近いほど濃く「より現場的」、頂点に近いほど薄く「より戦略的」)。階層ごとにばらばらな6色を選んでいないか。

## 実務でよく使う3つの応用パターン

- **複数事業部にまたがるTOM(マトリクス版)。** 事業部ごとにオペレーティングモデルが実質的に異なる場合、1つのピラミッドにすべてを押し込むと、どの事業部にとってもしっくりこない箱になる。代わりにマトリクスにし、列を事業部、行を同じ4階層にする。ただしこの形式は事業部が3〜4を超えると読みにくくなるため、それ以上はメインスライドに要約マトリクスを置き、事業部ごとの詳細ピラミッドは付録に回したほうが読みやすい。マトリクスには濃淡のグラデーションを付けるのも効果的で、現状からの変化が大きい事業部を濃く塗ると、ステアリングコミッティの最初の質問である「どの事業部が一番変わるのか」に、文章を読まなくても答えられるようになる。
- **階層を持たないコンポーネント型TOM。** 組織によっては、同じ内容を「機能プロセス」「人材」「サービスデリバリーモデル」「テクノロジー」「パフォーマンス・データ」「ガバナンス」の6つのほぼ対等な構成要素として、中央のラベルを囲むハニカム状に並べて見せる。「この4階層は積み上がっている」ではなく「この6つはすべて同時に設計すべきだ」というメッセージのときはこちらが向いている。作り方は[PESTELのハニカムスライドの作り方](https://www.advis-io.com/ja/blog/pestel-analysis-powerpoint-ja-ja?hsLang=ja)で解説した、色をつける前に各セルを中身の分量に合わせてサイズ調整する手順とまったく同じだ——TOMのセルを隣と無理に揃えるべきでない理由も同じ理屈になる。
- **小規模組織向けの簡略3階層版。** 30人規模の組織に、組織設計をわざわざ独立したピラミッド階層として持たせる必要はない。オペレーティングモデルの階層にサブ項目として組み込み、「ビジョン・戦略」「オペレーティングモデル・組織設計」「ガバナンス・レポーティング」の3階層にする。小規模な組織を無理に4階層版に当てはめると、組織設計の階層を、そこまでの独立した行に値しない内容で埋めることになりがちだ。これはデック全体でも起こりやすい落とし穴で、[コンサル資料の定番テンプレート10種](https://www.advis-io.com/ja/blog/consulting-slide-templates-ja-ja?hsLang=ja)でも、テンプレートの初期レイアウトをそのまま使うより、少ない・適切なサイズの箱で組んだほうがよいケースをいくつか紹介している。

[コンサル仕事術](https://www.advis-io.com/ja/blog/tag/コンサル仕事術) [コンサル資料作成](https://www.advis-io.com/ja/blog/tag/コンサル資料作成) [スライドデザイン](https://www.advis-io.com/ja/blog/tag/スライドデザイン)

## Similar posts

![logo\_white-1](https://www.advis-io.com/hubfs/logo_white-1.svg)

Transform your business data into actionable insights with AI-powered analytics. Get consultancy-grade presentations in minutes, not weeks.

N&E Building, 6th Floor  
1-12-4 Ginza, Chuo-ku  
Tokyo 104-0061  
Japan

[contact@advis-io.com](mailto:contact@advisio.com)

 

- [Blog](https://www.advis-io.com/en/blog?hsLang=ja)
- [About Us](https://www.advis-io.com/en/about?hsLang=ja)
- [問い合わせ](https://www.advis-io.com/contact?hsLang=ja)
- [特定商取引法に基づく表記](https://www.advis-io.com/jacommercialtransaction?hsLang=ja)
- [利用規約](https://www.advis-io.com/terms?hsLang=ja)
- [プライバシーポリシー](https://www.advis-io.com/privacy-policy?hsLang=ja)

© 2026 Advisio Inc. All rights reserved.

[Powered by Atlas - a B2B SaaS HubSpot theme](https://www.kalungi.com/atlas-hubspot-theme-for-b2b-saas-software)

```json
{
  "@context" : "https://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Advisio編集部",
    "url" : "https://www.advis-io.com/ja/blog/author/advisio-editorial"
  },
  "dateModified" : "2026-09-26T02:38:21.416Z",
  "datePublished" : "2026-09-26T02:38:21.000Z",
  "headline" : "PowerPointでターゲットオペレーティングモデル(TOM)スライドを作る手順",
  "image" : [ "https://www.advis-io.com/hubfs/blog-key-visuals/083-target-operating-model-powerpoint.ja.kv.png" ],
  "mainEntityOfPage" : {
    "@id" : "https://www.advis-io.com/ja/blog/target-operating-model-powerpoint-ja-ja",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : "https://www.advis-io.com/hubfs/logo.svg"
    },
    "name" : "Advisio株式会社"
  }
}
```