ここでは、DXやAIによって企業を変革する５つのステップについて説明します。
- 企業変革のコンセプト
- STEP1：企業の輪郭を明確にする
- STEP2：事業パーパスを実現する道筋を描く
- STEP3：データ基盤を構築し企業を変化に強い構造にする
- STEP4：AIエージェントドリブンでビジネスプロセスを再設計する
- STEP5：データドリブン経営を実践し企業を学習し進化する組織に換える
企業変革のコンセプト
企業変革の目的
企業変革を行う目的は、企業を次のような体質に変換し、結果的に事業パーパスを実現することです。
詳細はデザイン思考経営を参照してください。
企業変革の方針
企業変革の目的を実現するための方針は次の４つです。
- 事業パーパスを変革の中心に据える
企業の事業パーパスと、それを実現するための道筋を明確にし、企業変革の精神的な支柱を築きます。
デザイン思考経営では、人間の価値観という本質を中心に据えて、事業のパーパスを定めます。
企業を構成するメンバーがこのパーパスに共感し、ともに歩むことで、自らの貢献と成長を実感し、そこに喜びや意義を見いだすことができます。
この貢献と成長による内発的な動機づけが、メンバーのやり抜く力（グリット）や、しなやかさ（レジリエンス）を育み、結果として、企業の継続力を向上させます。 - EA×TOCで全体最適を目指す
企業変革とは、単なる業務改善ではなく、企業の体質そのものを変える取り組みです。
そのためには、部分最適ではなく、企業全体を最適化する視点が不可欠です。
まず、企業のアーキテクチャ（エンタープライズアーキテクチャ：EA）を、ビジネス、データ、アプリケーション、テクノロジー（IT）の観点から俯瞰的に描き、どこが価値創出の中核（コア）で、どこが支援的な領域（ノンコア）なのかを明確にします。
そのうえで、制約理論（TOC）を適用し、コア業務に存在する制約（ボトルネック）を特定・統制することで、企業全体のスループットを最大化していきます。 - マイクロサービス×AIエージェントで業務とシステムを変化に強い構造にする
EAの一要素であるビジネスアーキテクチャでは、企業のジョブ（職務）と、それらをつなぐビジネスプロセスを分析します。
「製品の出荷」プロセスの業務フロー
「製品の出荷」プロセスのコラボレーション
このジョブを支援する単位としてマイクロサービスを設計し、顧客に価値を生み出すコアプロセスを中心に統合します。
マイクロサービスは、それぞれが高い信頼性とセキュリティが担保されたデータを内包するため、それを疎結合に組み合わせてアプリケーションシステムを構築することで、環境変化に迅速に適応できる構造を実現します。
これにより、開発の生産性や保守性が向上するだけでなく、信頼性の高い分散型データ基盤を構築することが可能になります。
さらに、マイクロサービスにAIエージェントを組み込み、コアプロセスを再設計することで、環境の変化を自動的に察知し、自律的に最適な状態へと調整する、ホメオスタシスのような仕組みを実現することができます。
次の図は、マイクロサービス×AIエージェントによって構築された自律分散型データ基盤のイメージです。
自律分散型データ基盤
（Decentralized Autonomous Data Platform）
- データドリブン経営が実践できる仕組にする
データドリブン経営とは、
社員一人ひとりが
データとAIなどのデジタル技術を活用して
仮説と検証を繰り返し
自律的に業務課題を解決することができる
科学的マネジメント
のことです。
データドリブン経営のマネジメントサイクル
データドリブン経営は仮説と検証繰り返して業務課題を解決する科学的マネジメントです。
データドリブン経営では、解決策を仮説として考え、ランダム化比較実験を通して、解決策の妥当性を統計的に検証し、誰もが実践できるよう、妥当な解決策をビジネスプロセスに組み込みます。
この実証された解決策（何をすればうまくいくか・何をすればうまくいかないか）と、それを組み込んだビジネスプロセスが組織ナレッジになります。
先行き不透明で予測困難な時代、これまでうまくいった方法を前提に計画、実行、検証、改善というPDCAサイクルをまわしても、前提自体が間違っている場合、うまく機能しません。
このような時代、環境の変化に応じて迅速に事業を変革・創出し続けるためには、環境の変化を察知して仮説を立て、実験してうまくいく方法を探してから、その方法を実践するという仮説検証型のアプローチのほうが有効です。
つまり、仮説検証を繰り返すことで体系的にナレッジ（何をすればうまくいくか・何をすればうまくいかないか）が蓄積され、持続可能性を高める、やればやるほど成功の確度が上がる仕組みをつくることが重要なのです。
データドリブン経営は、一部のマネジメント層だけが実施するのではなく、企業を構成するメンバー一人ひとりが、アイデアを出し、仮説を立てて自ら課題を解決するマネジメント手法です。
データドリブン経営によって、社員一人ひとりが透明かつ公平な評価の下、事業への貢献と、事業とともに成長する喜びを享受することで価値創造の企業文化が育まれていくのです。
企業変革の手順
ここでは、企業変革の５つのステップの概要について説明します。
- 企業の輪郭を明確にする（Identity & Boundary）
ここでは、「企業の輪郭」を、誰に、何の価値を、誰（どんな価値基準を持った人）が、何を使って、どこで提供するのかという観点で明確にします。
まず、誰に何の価値を提供するか（顧客価値 × 製品価値）ですが、これは、事業の目的（存在理由）でありアイデンティティ（Identity）の核心です。
ここが曖昧だと、次のような問題が生じます。
・事業が拡散する
・AIやデータの最適化方向が定まらない
・「何のための効率化か」が分からなくなる
次に、誰（どんな価値基準を持った人）が、何を使って、どこで提供するのかですが、ここでは、価値を提供する人、物、場所という観点で、事業の境界（Boundary）を明確にします。
特に、どういう価値基準を持った人（メンバーやパートナー）が事業に参加するのかは、経営理念や組織文化に適合した事業の境界を形成します。
それから、何を使って、ですが、これは価値を生み出す源泉となる会社固有の資産で、有形資産（財務資産）だけでなく、無形資産（データやAI、テクノロジー）も含みます。 - 事業パーパスを実現する道筋を描く（Value Logic）
次に、事業パーパス（顧客価値 × 製品価値）を実現するための「価値の論理（Value Logic）」を戦略マップを描くことで明確にします。
Value Logic とは、なぜ顧客に選ばれ、その価値がどのように事業成果や企業価値につながるのかを、一貫した因果関係として説明できるものです。
これは理念やスローガンではなく、価値創出の仕組みを論理として設計する工程です。- 事業パーパスが中心
Value Logic の中心にあるのは、事業パーパスです。
・誰の、どのような課題や欲求に対して
・自社は、どのような製品・サービスを通して
・どのような価値を提供するのか
この 「顧客価値 × 製品価値」 が明確でなければ、その後の活動・投資・AI活用はすべて方向を失います。 - 価値は「活動の連鎖」によって実現される
顧客価値は、単独の施策や部門によって生まれるものではありません。
Value Logicでは、価値が、次のような 組織横断的な活動の連鎖（バリューチェーン）によって実現されると捉えます。
・価値を創る活動（Innovation）
・価値を届ける活動（Operation）
・価値を伝える活動（Communication）
これらが適切に連動して初めて、事業パーパスは現実の顧客体験として実現されます。 - 無形資産が活動の原動力
Value Logicでは、これらの活動の連鎖を支え、動かしている源泉を、企業固有の無形資産と捉えます。
戦略マップでは、代表的な無形資産として、職務（ジョブ）、情報（データ、アプリケーション、IT基盤）、文化（組織の文化）をあげています。
職務（ジョブ）は、バリューチェーンのビジネスプロセスを実行する主体であり、データ、アプリケーション、IT基盤といった情報資産を活用してタスクを遂行します。
また、職務（ジョブ）は、人だけでなく、AIエージェントによって実現され、経営理念（企業の価値基準）をベースとした組織文化によって行動規範が規定されます。 - 成果としての企業価値
このようにして実現された事業パーパスは、最終的に 企業価値 という成果につながります。
企業価値とは、単なる短期的な利益ではなく、
・生産性の向上（収益／資産）
・事業の持続的な成長
・環境変化に対する適応力
といった、中長期的な価値創出能力の総体です。
Value Logicを戦略マップとして描くことで、
・どの無形資産への投資が
・どの活動を通じて
・どの事業成果・企業価値に結びつくのか
を因果関係として説明できるようになります。
これにより、投資・改善・AI活用は場当たり的な施策ではなく、企業価値を高めるための合理的な選択として位置づけられます。
- 事業パーパスが中心
- 自律分散型データ基盤を構築し企業を変化に強い構造にする（Structural Resilience）
戦略マップで、事業パーパスを実現する道筋が描けたら、次は、マイクロサービス×AIエージェントで自律分散型データ基盤を築きます。
これは、その上で動く、すべての経営プロセスの土台になります。
Structural Resilience（構造的レジリエンス）とは、環境変化・不確実性・外乱が起きても、個人の頑張りや場当たり対応に依存せず、企業構造そのものがしなやかに耐え、素早く変われる能力のことです。
従来の企業は、例えば、こうやって耐えてきました。
・ベテランの勘
・現場の根性
・例外処理・手作業
・部門間調整の長時間会議
これは Human Resilience（人的レジリエンス） です。
しかし、
・市場変化が速すぎる
・プロセスが複雑すぎる
・AIが前提になる
・人は不足する
という昨今の状況を考えると、人的レジリエンスは限界で、構造的にレジリエンスを埋め込む必要があります。
これが Structural Resilience です。
マイクロサービス×AIエージェントで構築された自律分散型データ基盤は、次のように、企業が「見え、変えられ、試せ、学べる」構造を実現します。- 可視性（Visibility）
・何が起きているか分かる
・制約がどこか見える
・数字がリアルタイムで取れる
データが取れない構造は、変化に気づけず、壊れるまで異常に気づけません。 - 可変性（Flexibility）
・ルールやフロー、役割を変えられる
・人とAIの役割配分を変えられる
・プロセスを止めずに改修できる
固定化されたプロセスは、変化に弱くなります。
自律分散型データ基盤は、ビジネスプロセスを構成する要素がマイクロサービスとしてカプセル化されており、それらが疎結合で連携しているので、組み合わせを自在に変更することができます。
これは、次に説明するBPR（ビジネスプロセスの再設計）の土台になります。 - 分離性（Decoupling）
・変更が全体に波及しない
・局所最適を試せる
・失敗を限定できる
業務パッケージや集中型データ基盤のようなモノリス構造は、変化が全社的なリスクになります。
自律分散型データ基盤は、ビジネスプロセスを構成する要素がマイクロサービスとしてカプセル化されており、それらが疎結合で連携しているので、リスクを局所化することができます。 - 学習性（Built-in Learning）
・仮説→実行→結果→次の仮説が回る
・成果・失敗がデータとして残る
・改善が属人化しない
学習できない構造は、同じ失敗を繰り返します。
自律分散型データ基盤は、次のように、人とAIが組織ナレッジ（知的資産）を共創する仕組を内包します。
・人が、仮説を立て、意味を解釈し、意思決定する
・AIは、結果を記録し、関係を見つけ、再利用可能にする
これは、データドリブン経営の土台になります。
- 可視性（Visibility）
- AIエージェントドリブンでビジネスプロセスを再設計する（Autonomous Operation）
経営プロセスの土台となる自律分散型データ基盤が構築できたら、次は、その上で自律するオペレーションを設計、実装します。
次の図は、バリューチェーンを構成する価値を創る活動（Innovation）、価値を届ける活動（Operation）、価値を伝える活動（Communication）と付加価値の関係を表したものです。
購買・生産・販売といった価値を届ける活動（Operation）に比べて、研究開発や製品開発といった価値を創る活動（Innovation）や、マーケティングや顧客関係管理といった価値を伝える活動（Communication）は、相対的に高い付加価値を生み出すと考えられます。
なぜ、価値を届ける活動（Operation）がスマイルカーブの谷になるかというと、購買、生産、販売という活動は、次のような特徴があり、競争優位が構造的に生まれにくいと考えられるからです。- 標準化しやすい
- 比較されやすい
- 代替されやすい
制約理論（TOC）でいうと、価値を届ける活動（Operation）は、制約になりやすく、スループットの最大化に直結する業務領域です。
それに対して、価値を創る活動は、顧客価値に対する製品価値という意味や文脈を設計する、つまり、どこで稼ぐのかという集中すべき制約を設計する領域であり、価値を伝える活動は、顧客に正しく商品を選択していただく、つまり、制約を適切に調整する領域になります。
価値を伝える活動は、一見するとオペレーションに近く見えますが、実際には「選択の設計」「比較軸の再定義」を通じて、価格競争からの脱却を可能にするため、高い付加価値を生み出します。
なお、制約は、価値を届ける活動だけでなく、価値を創る活動や価値を伝える活動にも存在します。
価値を届ける活動が組織内部にある制約ならば、価値を創る活動や価値を伝える活動の制約は、顧客価値や市場の制約という組織外部の制約になります。
それから、生成AIを活用する場合、比較的標準化・ルール化されている価値を届ける活動（Operation）に適用するのが、最も効果が高いと考えられます。
これは、生成AIが得意とするパターン処理・判断・実行の特性が、オペレーションの性質と最も適合するためです。
３つの活動と生成AIの関係を考えると次のようになると考えられます。- 価値を創る活動（Innovation）
人が主、AIは補助 - 価値を届ける活動（Operation）
AIが主、人は監督 - 価値を伝える活動（Communication）
AIと人の協働
価値を届ける活動（Operation）は、AIエージェント前提でビジネスプロセスを再構築（BPR：Business Process Re-engineering）し、極限まで自律化すること（AIエージェントドリブンBPR）が可能です。
これにより、限られた人的リソースを価値を創る活動（Innovation）や価値を伝える活動（Communication）といった高付加価値領域に再配分することで、組織全体の競争優位性を高めることができます。
企業変革は血液循環と同じです。
まず、価値を届ける活動を改革し、出血や詰まりを止めて「流れる状態」を作る。
その上で、価値を創る活動で血を増やし、価値を伝える活動で血流を最適化する。
この順番を間違えると、改革は失敗します。
TOCの観点では、システム全体の成果は最も弱い制約によって決まるため、付加価値が相対的に低く、かつ制約になりやすいオペレーションを放置したまま価値創造（Innovation）や 価値伝達（Communication）に投資しても、成果は全体に波及しないのです。
ここでは、TOC × 生成AI によって、制約になりやすいオペレーションをAIで極限まで自律化し、人の知性を 価値創造（Innovation）と価値伝達（Communication）に集中できるようにします。 - データドリブン経営を実践し企業を学習し進化する組織に換える（Learning Organization）
最後に、人とAIが協働してデータドリブン経営を実践し、価値を創る活動（Innovation）や価値を伝える活動（Communication）を行うことで企業を学習し進化する組織にします。
ここでいう学習し進化する組織（Learning Organization）とは、教育や研修を強化する組織ではありません。
仮説 → 実行 → 結果 → 次の仮説というサイクルが、日常の業務と経営の中で自然に回り続ける組織です。
・成果も失敗もデータとして残り
・経験が属人化せず
・織全体の知（ナレッジ）として蓄積されていく
この状態が実現されたとき、企業は「人が賢い組織」ではなく「構造的に賢くなる組織」になります。
STEP4 で実現した AI エージェントドリブンな自律オペレーションは、学習し進化する組織（Learning Organization）の前提条件です。
オペレーションが自律化されることで、
実行のばらつきが減り、
判断と結果の因果が明確になり、
学習に使える高品質なデータが継続的に生成されます。
このデータがあるからこそ、価値創造（Innovation）や価値伝達（Communication）において、意味のある仮説検証が可能になります。
さて、学習し進化する組織（Learning Organization）では、人とAIが次のように役割を分担します。
人の役割
・仮説を立てる
・意味を解釈する
・価値判断を行う
AIの役割
・実行結果を記録する
・パターンや関係性を見つける
・知識を再利用可能な形で蓄積する
ここでは、AIは意思決定を置き換える存在ではなく、学習を加速する装置として機能します。
設計、戦略、構築、運用という戦略サイクルのすべてが、学習の結果として蓄積される状態がデータドリブン経営の本質です。
この状態が実現されると、企業は次の特性を持つようになります。
・環境変化に早く気づく
・小さく試し、素早く修正する
・成功を再現し、失敗を繰り返さない
これにより、企業変革は一度きりのプロジェクトではなく、終わりのない進化のプロセスへと換わるのです。
STEP1：企業の輪郭を明確にする
ここでは、「企業の輪郭」を、誰に、何の価値を、誰（どんな価値基準を持った人）が、何を使って、どこで提供するのかという観点で明確にします。
具体的には、次を３つを実施します。
事業の仕組を設計する
まず、お客さまの事業の本質となる仕組を次の点で明確にします。
これらは、事業の仕組（ビジネスモデル）の最も基本的な構成要素になります。
業務の仕組を設計する
次に、お客さまの業務の本質となる仕組を次の点で明確にし、業務一覧としてまとめます。
次の図は、活動領域、ビジネスプロセス、ジョブ、バリューチェーンの関係を表したものです。
これを見ると次のことがわかります。
- 事業ドメインには、複数の活動領域がある。
- 活動領域には複数のビジネスプロセスがある。
- ビジネスプロセスには、ビジネスプロセスの本質的（不変的）な流れを表すアクティビティフローがある。
- アクティビティフローのアクティビティには、アクティビティの中身の流れを表すアクションフローがある。
- アクションを実行する主体がジョブである。
アクションは、ジョブのタスク（課業）に対応する。 - 事業ドメインには、ビジネスプロセスからなるマネジメントサイクルの流れで構成されるバリューチェーンがある。
システムの仕組を設計する
最後に、企業のシステムの仕組をジョブ×種類×FEという観点でMECEに設計し、システム台帳としてまとめます。
- アプリケーションタイプ
アプリケーションの型。
概念レベルのアプリケーション。
上記業務の仕組のジョブ（職務）ごとにアプリケーションタイプを定義します。
これによって、ビジネスアーキテクチャとアプリケーションアーキテクチャが整合します。
詳細は、アプリケーションポートフォリオも参照してください。 - アプリケーションカテゴリ
アプリケーションタイプをアプリケーションの種類という観点で論理的に分類した単位。
論理レベルのアプリケーション。
アプリケーションの種類は次のようになります。- SoR（System of Record）
トランザクション処理アプリケーション。
社内の業務活動によって発生する事実を記録するためのシステム。
ここでは、さらに、マスターデータを管理するシステム、参照データを管理するシステム、トランザクションデータを管理するシステムに分けて管理します。 - SoI（System of Insight）
分析アプリケーション。
主に様々な切り口でKPIを分析することで財務、顧客、業務、資産に関する洞察を得るためのシステム。 - SoE（System of Engagement）
変革アプリケーション。
顧客や従業員、パートナーにサービスを提供することで良好な顧客関係を構築するためのシステム。
- SoR（System of Record）
- アプリケーション
IT基盤にデプロイするアプリケーションの単位。
物理レベルのアプリケーション。
UI/UXを担うフロントエンドアプリケーションと、ビジネスロジックとデータ管理を担うバックエンドアプリケーションに分割します。
マイクロサービスは、バックエンドアプリケーションの一種になります。 - 現行アプリケーション
どのアプリケーションを、現行、何と言うアプリケーションが担っているのか分析します。 - アプリケーションが管理するデータ
アプリケーションが主管として管理するデータを明確にします。
このデータを構造化したものがデータアーキテクチャの業務概念データモデルになります。
STEP2：事業パーパスを実現する道筋を描く
次に、事業パーパス（顧客価値 × 製品価値）を実現するための「価値の論理（Value Logic）」を戦略マップを描くことで明確にします。
戦略マップは、企業価値を創出するロードマップ（道筋）を示します。
下図は、戦略マップを簡略した図です。
本図は、学習と成長の視点における人的資本・情報資本・組織資本といった無形資産が、内部プロセスの視点である価値創出活動（バリューチェーン）を実行することにより、顧客価値を提供し、収益の拡大や生産性の向上を通じて企業価値を最大化する因果関係を示しています。
そして、企業価値は再び無形資産への投資として還元され、学習と成長が促進されることで、さらなる価値創出へとつながります。
内部プロセスと財務の関係をみると、価値を届ける活動（Operation）の効率化は「生産性の向上」に直結し、一方で価値を創る活動（Creation）や価値を伝える活動（Communication）は製品価値や顧客価値の向上を通じて「収益の増大」に結びつきます。
戦略マップを描くことで、アプリケーション、データ、IT基盤という情報資本がどのように企業価値を上げるのか、その道筋を明確にすることができます。
具体的には次の手順で進めます。
戦略マップを設計する
次の順で戦略マップを設計します。
- 財務の視点の目標を設定する
- 顧客の視点の目標を設定する
- 内部プロセスの視点の目標を設定する
- 学習と成長の視点の目標を設定する
BSCを設計する
次の順でBSCを設計します。
- 財務の視点のKPIを設定する
- 顧客の視点のKPIを設定する
- 内部プロセスの視点のKPIを設定する
- 学習と成長の視点のKPIを設定する
KPIを構造化する
BSCのKPIの因果関係を明確にします。
業務一覧のバリューチェーンに、内部プロセスの戦略目標、および、KPIと、学習と成長の人的資本目標、情報資本目標、組織資本目標、および、KPIを設定します。
詳細のイメージは、以下の記事を参考にしてください。
KPIの構造化
SoIを設計する
各KPIを様々な切り口で分析できるSoIを設計し、システム台帳にSoIを追加します。
STEP3：自律分散型データ基盤を構築し企業を変化に強い構造にする
戦略マップで、事業パーパスを実現する道筋が描けたら、次は、次の手順で、マイクロサービス×AIエージェントで自律分散型データ基盤を築きます。
データアーキテクチャの設計
自律分散型データ基盤は、データの品質とセキュリティを担保する基盤である必要があります。
そこで、まず、企業全体のデータの青写真であるデータアーキテクチャを描くことで、品質とセキュリティを担保すべきデータを明らかにします。
データアーキテクチャ（概念レベル）は次の順で設計します。
アプリケーションアーキテクチャの設計
自律分散型データ基盤は、ビジネスプロセスを構成する要素がマイクロサービスとしてカプセル化されており、それらが疎結合で連携しています。
ここでは、マイクロサービスを含めた企業全体のアプリケーションの構成、アプリケーションアーキテクチャを次の順で設計します。
アプリケーション戦略の結果を受けて、システム台帳のアプリケーション戦略欄を記載します。
モデルドリブン開発
モデルドリブン開発とは、MDAの考え方で、次の３つのモデルを創れば、PSMから自動的にソースコードを生成するという開発方法のことです。
- CIM（Computation Independent Model）
計算機処理に依存しないモデル。 - PIM（Platform Independent Model）
IT基盤に依存しないモデル。 - PSM（Platform Specific Model）
IT基盤に特化したモデル。
具体的には、次のような手順でシステム（マイクロサービス、および、フロントエンドアプリケーション）を開発します。
- CIMの設計
- PIMの設計
- PSMの設計
モデルドリブン開発の詳細は、次の記事を参照してください。
モデルドリブン開発で創るアプリケーションシステム
AIエージェントの実装
AIエージェントの実装として、Anthropic社が提供する 大規模言語モデル（LLM）／AIアプリケーションと、外部データ・ツールとの接続を標準化するプロトコル、MCP（Model Context Protocol）を適用する例を考えることができます。
下図では、マイクロサービスのアダプタに、MCPでAIエージェントを接続しています。
自律分散型データ基盤では、アダプタ層が疎結合インターフェースとして機能しているため、AIエージェントの追加が容易です。
そして将来的には、すべてのマイクロサービスにAIエージェントを組み込むことで、それぞれのサービスが環境の変化をリアルタイムに察知し、自律的に会話・連携しながら、全体を最適化する、まるで生物のホメオスタシス（恒常性）のような仕組みを持つシステムを実現することが可能になります。
（Decentralized Autonomous Data Platform）
STEP4：AIエージェントドリブンでビジネスプロセスを再設計する
経営プロセスの土台となる自律分散型データ基盤が構築できたら、次の手順で、その上で自律するオペレーションを設計、実装します。
価値を届ける活動（オペレーション）サイクルの制約の特定
まず、上記した業務の仕組を設計するで設計したバリューチェーンのうち、価値を届ける活動（オペレーション）サイクルの制約（ボトルネック）を次の手順で特定します。
スループットを止めるビジネスプロセスは何か考える
例えば、価値を届ける活動（Operation）が次のビジネスプロセスから構成されるとします。
- 製品管理計画、マーケティング計画の策定
- 販売計画、サービス提供計画、生産計画、購買計画の策定
- 製品の改良、顧客の活性化
- 製品の販売
- 部品の購買
- 部品の入荷
- 代金の支払
- 製品の生産
- 製品の出荷
- 代金の請求
- 製品管理計画、マーケティング計画の検証・改善
このうち、どのビジネスプロセスが止まればスループットが止まる（売上がたたない）かを考えます。
そう考えると、次のビジネスプロセスが制約の候補になると考えることができます。
- 製品の販売
- 部品の購買
- 部品の入荷
- 製品の生産
- 製品の出荷
代替が効くか？でふるいにかける
例えば、別倉庫、別運送会社で代替できないのであれば「製品の出荷」プロセスが制約になっている可能性があります。
他が従属しているか？を見る
残った候補について、次を観察します。
- 他工程が「待たされている」
- 前後に在庫、滞留、WIP（仕掛）が溜まっている
- スケジュールがそこ基準で決まっている
そのビジネスプロセスのうち、スループット定義点になっている活動が制約です。
スループット定義点とは、そこを通過した瞬間に、会社に新しいお金が入ってくることが確定する一点です。
例えば、「製品の出荷」プロセスが制約の場合、次のような状況を観察することができます。
- 他工程が「待たされている」
・生産完了しているが出荷できない
・倉庫が満杯で次が置けない - 在庫・滞留・WIP
・出荷待ち完成品が山積み
・梱包・検品前後で滞留 - スケジュールの従属
・納期が物流キャパに縛られる
・出荷可能日＝納品日になる - 典型的な例
・倉庫人員不足
・梱包作業が属人化
・出荷システムが遅い
この場合の制約
「製品の出荷」プロセスがスループット定義点になり、それを実施する物流設備（資産）の能力（キャパシティ）も影響します。
1点だけ仮説として決める
ここで重要なのは、「全部制約っぽい」は NGで、必ず1つに決めることです。
TOCは分析ではなく、意思決定の理論です。
現時点で、最もスループットを制限しているのは「製品の出荷」プロセスである
と仮説を置きます。
アクティビティフローの分析
次に、制約となったビジネスプロセスのアクティビティフローを分析します。
次の図は、「製品の出荷」プロセスのアクティビティフローの例です。
アクティビティフローの制約の特定
次に、アクティビティフローを構成するアクティビティの中でどこが制約になっているか、上記ビジネスプロセスと同じ観点で特定します。
現在、品質管理者が過去のロット別品質検査結果を格納する品質DBにアクセスして、不良リスクを予測しているため時間がかかるとともに精度が低いという問題があります。
TOCの観点で観ると、これは以下のような理由で制約になります。
- 代替が効きにくい
・品質管理者しか判断できない
・経験依存・属人化
・担当者を簡単に増やせない - 待ちが発生する
・出庫 → 品質検査 → 出荷
・この「判断待ち」で後続が止まる - 他が従属している
・配送指示
・会計計上
・顧客への納期確定
すべてが、品質検査判断が終わるまで待ち状態になります。
アクションフローの設計
ここでは、TOCに従って以下の観点で制約を統制し、その結果を受けて、制約となるアクティビティのアクションフローを設計します。
- 制約を改善する（Exploit the Constraint）
制約の効率を最大化するために、現在のリソースを最適化する。
例：生産ラインのボトルネック工程の稼働率を最大化する。 - 制約へ適合させる（Subordinate Everything Else to the Constraint）
制約が最適なパフォーマンスを発揮できるように、他のプロセスを調整する。
例：非制約工程が無駄な作業をしないように同期を取る。 - 制約を克服する（Elevate the Constraint）
もし制約が依然としてボトルネックである場合、新しいリソースを追加したり、プロセスを改善したりする。
例：新しい設備を導入する、追加の人員を投入する。
次の図は、品質管理サービスに連携したAIエージェントが不良リスクを予測するアクションフローを示しています。
次のような流れになります。
- 出庫報告を受け取った品質管理サービスが品質管理エージェント（MCPホスト）に部品のロット情報を渡して不良リスクの予測を依頼します。
例
POST /tools/invoke
Host: mcp-agent.example.com
Content-Type: application/json
{
“tool”: “suggestExtraInspection”,
“input”: {
“lotNumber”: “LOT-20251116-001”
}
} - 品質管理エージェント（MCPホスト）は、品質管理エージェントが持つ過去のロット別品質検査結果を格納する品質DB（MCPサーバー）にアクセスして、不良リスクを予測し、「重点検査を実施してください」など次のアクションとして結果を品質管理サービスに返します。
例
{
“recommendation”: “重点検査を実施してください”,
“riskScore”: 0.82,
“reason”: “このロットは過去に20%以上のNG率を記録しています”
} - 品質管理サービスは、品質管理エージェントの結果を受取り、品質管理者に「重点検査を実施してください」などの指示を出します。
- 品質管理者
品質検査
品質検査結果報告 - 品質管理サービス
不良予測依頼
品質検査指示 - 品質管理エージェント
品質検査結果の取得
不良予測
タスクの設計
次に、設計されたアクションフローのアクションからジョブやマイクロサービス、AIエージェントのタスクを設計します。
前のアクションフローより、品質管理者、品質管理サービス、品質管理エージェントのタスクは次のようになります。
アクションの設計
ここでは、ジョブのタスク設計を受けて、ジョブが関連する部門のアクションを設計します。
例えば、品質管理者が関連する品質管理部があるとすると、そのアクションは
品質検査
品質検査結果報告
になります。
オペレーションの実践
AIエージェントの設計ができたら、上記AIエージェントの実装アクションを通してAIエージェントを実装し、品質検査アクティビティが実行できるか検証します。
品質検査アクティビティが実行できることが確認できたら、「製品の出荷」プロセスにAIエージェントを組み込んで、それを実践します。
本オペレーションを実践した結果、品質検査が制約でなくなった場合、制約は次のビジネスプロセスまたはアクティビティへ移動します。
その場合は、同じ手順に従って新たな制約を特定し、継続的にオペレーションを再設計します。
STEP5:データドリブン経営を実践し企業を学習し進化する組織に換える
最後に、次の手順で、人とAIが協働してデータドリブン経営を実践し、価値を創る活動（Innovation）や価値を伝える活動（Communication）ができるようにします。
