ここでは、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）
- 事業パーパスを実現する道筋を描く（Value Logic）
- 自律分散型データ基盤を構築し企業を変化に強い構造にする（Structural Resilience）
- AIエージェントドリブンでビジネスプロセスを再設計する（Autonomous Operation）
- データドリブン経営を実践し企業を学習し進化する組織に換える（Learning Organization）
- 企業の輪郭を明確にする（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エージェントを含めAIを活用する場合、比較的標準化・ルール化されている価値を届ける活動（Operation）に適用するのが、最も効果が高いと考えられます。
これは、AIが得意とするパターン処理・判断・実行の特性が、オペレーションの性質と最も適合するためです。
生成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は意思決定を置き換える存在ではなく、学習を加速する装置として機能します。
設計、戦略、構築、運用という戦略サイクルのすべてが、学習の結果として蓄積される状態がデータドリブン経営の本質です。
この状態が実現されると、企業は次の特性を持つようになります。
・環境変化に早く気づく
・小さく試し、素早く修正する
・成功を再現し、失敗を繰り返さない
これにより、企業変革は一度きりのプロジェクトではなく、終わりのない進化のプロセスへと換わるのです。
具体的には、事業の仕組、業務の仕組、システムの仕組という観点で企業のアーキテクチャ（エンタープライズアーキテクチャ）を描きます。
ポイントは、以下です。
それから、EAの設計のポイントは、企業変革をするための見取り図を作ることです。
なので、賞味５日程度で実施し、企業全体を広く浅く俯瞰できるようにします。
具体的には、財務、顧客、内部プロセス、学習と成長という観点で企業の戦略マップを描きます。
これによって、EAで設計した業務とシステムの仕組を、企業改革の目的である事業パーパスの実現と、最終的な成果である企業価値に結びつけることができます。
具体的には、EAのアプリケーションの部分を、マイクロサービス×AIで置き換えることで自律分散型データ基盤（Decentralized Autonomous Data Platform）を構築し、企業を、業務改革、事業創出・変革に柔軟に適応できる変化に強い構造にします。
具体的には、自律分散型データ基盤（Decentralized Autonomous Data Platform）の上で、制約理論（TOC）に基づいて、AIドリブンでビジネスプロセスを最適化することで、価値を届ける活動（オペレーション）を極限まで自律化します。
具体的には、TOCをベースとしたデータドリブン経営を実践することで、企業を学習し進化する組織へと変換します。
それでは、STEP1から５まで詳しく見ていきましょう。
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の最小実験で裏取りするで検証します。
アクションフローの設計
ここでは、TOCに従って以下の観点で制約を統制し、その結果を受けて、制約となるアクティビティのアクションフローを設計します。
- 制約を改善する（Exploit the Constraint）
制約の効率を最大化するために、現在のリソースを最適化する。
例：生産ラインのボトルネック工程の稼働率を最大化する。 - 制約へ適合させる（Subordinate Everything Else to the Constraint）
制約が最適なパフォーマンスを発揮できるように、他のプロセスを調整する。
例：非制約工程が無駄な作業をしないように同期を取る。 - 制約を克服する（Elevate 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率を記録しています”
} - 品質管理サービスは、品質管理エージェントの結果を受取り、品質管理者に「重点検査を実施してください」などの指示を出します。
UMLのアクティビティ図で描くと次のようになります。
タスクの設計
次に、設計されたアクションフローのアクションからジョブやマイクロサービス、AIエージェントのタスクを設計します。
前のアクションフローより、品質管理者、品質管理サービス、品質管理エージェントのタスクは次のようになります。
- 品質管理者
品質検査
品質検査報告 - 品質管理サービス
不良予測依頼
品質検査指示
品質検査報告の受領 - 品質管理エージェント
品質検査結果の取得
不良予測
設計されたタスクは、上記「業務の仕組を設計する」で作成した業務一覧のジョブのタスクとして追記します。
アクションの設計
ここでは、ジョブのタスク設計を受けて、ジョブが関連する部門のアクションを設計します。
例えば、品質管理者が関連する品質管理部があるとすると、そのアクションは
品質検査
品質検査結果報告
になります。
設計されたアクションは、上記「業務の仕組を設計する」で作成した業務一覧の部門のアクションとして追記します。
オペレーションの実践
AIエージェントの設計ができたら、上記AIエージェントの実装アクションを通してAIエージェントを実装し、品質検査アクティビティが実行できるか検証します。
品質検査アクティビティが実行できることが確認できたら、「製品の出荷」プロセスにAIエージェントを組み込んで、それを実践します。
本オペレーションを実践した結果、品質検査が制約でなくなった場合、制約は次のビジネスプロセスまたはアクティビティへ移動します。
その場合は、同じ手順に従って新たな制約を特定し、継続的にオペレーションを再設計します。
さて、AIエージェントドリブンで、TOCをベースに自律的にオペレーションをまわすためには、AIエージェントを組み込んで、ビジネスプロセスマネジメント（BPM）を自動化する必要があります。
ここで、AIエージェントと人が協調するHuman-in-the-loopでオペレーションを自動化するAIエージェントドリブンBPMについて説明します。
AIエージェントドリブンBPM
目的
本アーキテクチャの目的は、ビジネスプロセスを「固定的に設計・遵守する対象」から、「観測・判断・調整し続ける対象」へと進化させることです。
従来のBPMは、以下の課題を抱えていました。
- プロセスは事前定義され、変更に時間がかかる
- KPIは可視化されるが、改善判断は人依存
- 部分最適（工程最適）が全体最適を阻害する
- 制約（ボトルネック）の発見が遅れる
本構成では、BAMによる観測、TOCエージェントによる制約判断、BPMによる状態制御を分離・連携させることで、ビジネスプロセスをAIエージェント主導で継続的に最適化することを目的とします。
本構成におけるプロセス
- 業務サービス（SoR）
出荷管理・在庫管理・品質管理といった各業務サービスは、それぞれが System of Record（SoR） として自律的に動作します。- 出荷指示
- 出庫指示
- 出庫報告
- 品質検査指示
- 品質検査報告
これらは、イベントソーシングによって各業務ごとのイベンストアとして持ちます。
各マイクロサービス（SoR）のイベントストア（時系列）のイメージ
出荷管理サービス時刻 イベントID 集約ID イベント種別 主な属性 09:00 E-001 S-9001 ShipmentInstructionIssued orderId=O-1001 在庫管理サービス
時刻 イベントID 集約ID イベント種別 主な属性 09:04 E-101 INV-9002 PickingStarted location=A1 09:10 E-102 INV-9002 PickingCompleted quantity=10 品質管理サービス
時刻 イベントID 集約ID イベント種別 主な属性 09:12 E-201 QI-9003 QualityInspectionStarted inspector=U-01 09:14 E-202 QI-9003 QualityInspectionPassed result=OK 既存業務の責務やトランザクション整合性は一切変更しませんが、イベントが発生する都度、BAMサービスに対して疎結合なイベントをQueueに発行します。
各業務サービスは業務ごとのイベントを管理し、BAMは、業務横断的なビジネスプロセス単位のイベントを管理します。
なので、BAMのイベントは出荷IDを相関ID（Correlation ID)としてもち、出荷プロセス単位にイベントが管理できるようになっています。 - BAM（観測レイヤ）
BAMサービスは、各業務イベントを非同期に受信し、イベントストアに蓄積します。
※
BAM（Business Activity Monitoring）とは、企業の業務活動をリアルタイムで監視・分析するための技術やツールのことを指します。
BAMのイベントストアのイメージ時刻 BAMイベントID 元イベント プロセスID 観測内容 09:00 B-001 ShipmentInstructionIssued P-7001 出荷指示 09:04 B-002 PickingStarted P-7001 出庫開始 09:10 B-003 PickingCompleted P-7001 出庫完了 09:12 B-004 QualityInspectionStarted P-7001 品質検査開始 09:14 B-005 QualityInspectionPassed P-7001 品質検査OK BAMの役割は「判断」ではなく、以下に限定されます。
- 実績時間（リードタイム・滞留時間）
- WIP量
- 処理頻度・ばらつき
- 工程間の待ち時間
つまり、事実を歪めず、再計算可能な形で保持する観測装置です。
- 影響度
改善したら全体がどれだけ動くか。
量。影響度i =
avg(timei) / avg(totalLT)合計リードタイム（LT）の平均に対する各工程のリードタイムの割合。
スループット（売上）は、リードタイムが短くなるほど増えると考え、全体のリードタイムに占める工程のリードタイムが大きいほど改善した場合の効果が大きいと考えます（全体に対する感度係数）。 - 従属性
全体が誰に引きずられているか。
支配性。従属性i = |corr(timei, totalLT)|
各工程のリードタイムと合計リードタイムの相関係数。
合計リードタイムが増えるとき、一緒に増えている工程（全体に対する相関度合が高い工程）に全体が従属していると考えます。 - 流れ阻害
どの場所で流れが止まっているか。
滞留。流れ阻害i = WIPi / max(WIP)
ここで WIP（仕掛件数）は、
WIP = スループット（単位時間あたりに完了する件数） × 平均滞留時間
と定義されます（Littleの法則）。
WIPが大きい工程ほど、処理能力不足や判断待ち等により流れが止まっている可能性が高いと考えます。
流れ阻害は「どこが最も詰まっているか」を相対的に把握する指標であるため、最もWIPが大きい工程を1とし、各工程のWIPを最大WIPで正規化して評価します。 - 歪み。
不安定さ・将来の詰まりの可能性。
不確実性。歪みi = CVi / max(CV)
CV（Coefficient of Variation）は変動係数で、各工程のリードタイムの標準偏差を平均で割ることでバラツキを標準化します。
CVが大きい工程ほど、処理時間のばらつきが大きく、速いときと遅いときの差が生じやすいため、フローを不安定にし、将来的にWIPを発生させやすいと考えます。
歪みは「どこが最も不安定か」を相対的に把握する指標であるため、最もCVが大きい工程を 1 とし、各工程のCVを最大CVで正規化して評価します。 - A：出荷開始→出庫開始
- B：出庫開始→出庫完了
- C：品質検査開始→品質検査完了
- 平均値
- avg(A)=8.4
- avg(B)=12.0
- avg(C)=8.0
- avg(totalLT)=(12 + 25 + 35 + 25 + 45) / 5 = 28.4
- 4因子の算定（式と結果）
- 影響度（Impact）
- A: 8.4 / 28.4 = 0.295775
- B: 12.0 / 28.4 = 0.422535
- C: 8.0 / 28.4 = 0.281690
- 従属性（Dependency）
（Pearson相関の絶対値。計算結果）- A: 0.970130
- B: 0.789410
- C: 0.958160
- 流れ阻害（Flow Obstruction）
- A: 8.4 / 12.0 = 0.700000
- B: 12.0 / 12.0 = 1.000000
- C: 8.0 / 12.0 = 0.666667
- 歪み（Distortion）
まず CV（変動係数）：
CV（計算結果）- CV(A)=0.455503
- CV(B)=0.263523
- CV(C)=0.632456（最大）
よって歪み
- A: 0.455503 / 0.632456 = 0.720213
- B: 0.263523 / 0.632456 = 0.416667
- C: 0.632456 / 0.632456 = 1.000000
- 影響度（Impact）
- 制約スコア
区間 影響度 従属性 流れ阻害 歪み 制約スコア 制約スコア×100 A 0.295775 0.970130 0.700000 0.720213 0.144661 14.4661 B 0.422535 0.789410 1.000000 0.416667 0.138981 13.8981 C 0.281690 0.958160 0.666667 1.000000 0.179936 17.9936 結果の読み（BAM的に言えることだけ）
C（品質検査開始→品質検査完了）がに最大（このデータでは「制約候補」が最も強く現れる区間） - BPM（制御レイヤ）
BAMサービスのイベントは、CQRSを通じて BPMサービス に渡されTOCエージェントが参照しやすい状態ストアの形で保管します。
BPMの状態ストアのイメージ
BPM 状態ストア（例：ProcessInstance テーブル）プロセスID 出荷ID 現在ステータス 開始時刻 最終更新 P-7001 S-9001 DELIVERED 09:00 11:30 BPM 状態遷移履歴（内部）
時刻 プロセスID 状態 09:00 P-7001 SHIPMENT_STARTED 09:04 P-7001 INVENTORY_DONE 09:10 P-7001 QUALITY_OK 09:12 P-7001 IN_DELIVERY 11:30 P-7001 DELIVERED BPMサービスは、以下を担います。
- 現在のプロセス状態の一元管理（状態ストア）
- 優先度・WIP制限・進行可否の決定
- 業務への指示・制御方針の反映
BPMは「過去」を持たず、常に「今どう動かすか」だけを決めます。
- TOCエージェント（解釈・判断）
TOCエージェントは、BPMが提供する観測データ（状態ストア）をもとに、- 現在の制約工程はどこか
- どの工程が他工程を待たせているか
- 全体スループットを止めている要因は何か
を 制約理論（TOC）に基づいて解釈・仮説化します。
ここでは、- 単純な閾値判定
- KPIの大小比較
ではなく、文脈・履歴・相対比較による判断が行われます。
BAMの観測値から、工程の制約の度合を表す制約スコアを計算することができます。
制約スコア＝影響度×従属性×流れ阻害×歪み
各因子は、評価・比較のために 0〜1 の範囲に正規化して表します。
これら４つの因子はどれかが０であれば制約でないと考えるので制約スコアは因子の掛け算で表されます。
例
各プロセスのイベント差分（分）を次の3区間に分解します（BAMは差分しか使わない）
| プロセス | A | B | C | 合計LT （A+B+C） |
|---|---|---|---|---|
| P-7001 | 4 | 6 | 2 | 12 |
| P-7002 | 7 | 13 | 5 | 25 |
| P-7003 | 10 | 12 | 13 | 35 |
| P-7004 | 6 | 14 | 5 | 25 |
| P-7005 | 15 | 15 | 15 | 45 |
制約スコアは、BAMに蓄積されたすでに完了したプロセスのデータを基に計算されます。
一方、BPMの状態ストアは、まだ完了していない進行中プロセスの現在状態を保持します。
TOCエージェントは、
過去データから算定された制約スコア（構造的な制約傾向）と、
BPMの状態ストアにある現在の滞留状況（現実の制約状態）を突き合わせることで、
「今この瞬間の制約」を仮説ベースで特定します。
例
スループットを止めている要因は、品質検査工程（区間C）における処理能力制約です。
これは一時的な例外ではなく、複数プロセスが同一の品質検査完了待ち状態に滞留しているため、構造的制約である可能性が高いと考えられます。
制約の活用（Exploit）
プロセスID：P-006 が 品質検査工程（区間C） に滞留しているため、当該プロセスに対して品質検査工程の処理を最優先で実行してください。
・検査担当者・検査設備・検査時間帯を最優先で割り当てる
・非付加価値作業（待ち・切替・段取り）を可能な限り排除する
制約への適合（Subordinate）
プロセスID：P-006 が 品質検査工程の制約プロセスとして処理中であるため、他の進行中プロセスについては、品質検査工程の処理能力を超える新たな流入を発生させないよう制御してください。
・出庫完了（B終了）から品質検査開始（C開始）への投入量を制御
・品質検査工程のWIP上限を超える投入は禁止
・非制約工程（出庫・出荷指示）は、品質検査工程の進捗に従属させる
AIエージェントドリブンBPMの特徴
- BAMとBPMの完全分離
項目 BAM BPM 役割 観測・計測 制御・意思決定 データ イベント 状態 再計算 可能 不要 正解 複数（計算方法ごと） 単一 この分離により、
- 観測の自由度
- 制御の安定性
- 判断の柔軟性
が同時に成立します。
- TOC理論との親和性
TOCは、- 「どこが制約か」は動的に変わる
- 制約は局所最適では見えない
- 判断は文脈依存
という特性を持つ。
そのため、次のようなかたちにします。- BAMに判断させず
- BPMに分析させず
- TOCエージェントに解釈させる
この構造は、理論的にも実務的にも極めて自然です。
- 人とAIの協調（Human-in-the-loop）
TOCエージェントの判断結果は、- 自動制御
- 人への提案・警告
- シミュレーション結果の提示
として利用できます。
これにより、- 全自動化が必要な工程
- 人の判断が必要な工程
を柔軟に切り分けられます。
AIエージェントドリブンBPMのメリット
- 業務全体のスループット向上
- 制約工程に資源を集中
- 非制約工程の過剰稼働を抑制
- 全体最適を阻害するムダを削減
- 改善サイクルの高速化
- 計測 → 制御 → 判断が非同期で連続
- プロセス変更のための大規模改修が不要
- 効果測定はイベント再計算で即時可能
- 既存システムを壊さない
- SoRは変更不要
- 追加はイベント購読のみ
- 段階導入が可能
経営と現場をつなぐ
- 経営
制約とスループットが見える - 現場
理由ある指示として届く - IT
責務分離された拡張可能な構造
STEP5:データドリブン経営を実践し企業を学習し進化する組織に換える
最後に、人とAIが協働してデータドリブン経営を実践し、企業を学習し進化する組織に換えていきます。
まず、事業ステージ別データドリブン経営を参照してください。
プロセスの制約（内部プロセスの視点）が原因である場合、データドリブン経営のマネジメントサイクル（PDCAサイクル）にTOCのアプローチを組み込んで実施します。
データドリブン経営のマネジメントサイクルの「原因の推定」タスクで、TOCの５つのステップの制約の特定を実施します。
次に、「課題の設定」のときに、TOCの５つのステップの中の制約の改善、制約への適合、制約の克服から制約の統制方法を選択し、それを課題として設定します。
そして、「解決策の考案」で、具体的な制約の統制方法を考案します。
「実験計画の策定」、「解決策の検証」では、制約の統制方法がスループットを改善するか検証します。
制約の特定のときに最小実験で裏取りすると説明しましたが、この部分が「実験計画の策定」、「解決策の検証」になります。
以上のように、データドリブン経営は、仮説検証を繰り返す科学的アプローチです。
PDCAの結果をすべて記録しノウハウとして蓄積することで学習し進化する組織が実現します。
さて、ここで、価値を創出する活動（Innovation）と価値を伝える活動（Communication）におけるTOCについて触れておきます。
価値を届ける活動（Operation）の場合、直接売上を上げる領域なので、制約の統制が、売上ー完全変動費であるスループットにダイレクトにつながりますが、価値を創出する活動（Innovation）と価値を伝える活動（Communication）は、直接売上につながる領域ではないためTOCのアプローチを考慮する必要があります。
例えば、スタートアップの創業ステージやシードステージなど、まだ、売上が上がらない時期は、何が制約で、何をスループットとし、それをどう統制するか考える必要があります。
３つの活動領域のスループットと制約の正体をまとめると次のようになります。
それから、価値を創出する活動（Innovation）と価値を伝える活動（Communication）のビジネスプロセス、製品の開発と顧客の獲得のタスクを次のようになります。
製品の開発プロセスのタスク
- 新規価値（製品価値）仮説の設定
顧客価値に対する製品価値の価値提案を仮説で創り製品タスクとして設定する。 - 新規価値仮説の検証方法設計
仮説を「正当化」するのではなく最短で否定・修正する方法を決める。 - 新規価値仮説のMVPの構築
仮説検証に必要な最低限の「体験」を作る。 - 新規価値仮説の検証
顧客と接触し、価値仮説を検証（学習が前進する瞬間）する。
顧客の獲得プロセスのタスク
- 新規顧客（顧客価値）仮説の設定
「顧客の欲求を満たす性質は何か？」「この価値は 誰の 意思決定を前に進めるのか？」を明確にする。 - 新規メッセージ仮説の設定
顧客が「自分ごと」として理解できる意味の形を仮説化する。 - 新規市場の接点設計
LP / 営業資料、デモ / 商談、コンテンツ / イベントなど、そこを通らないと顧客は判断できない接点を考える。 - 新規顧客の反応観測
理解されたか？誤解されたか？無反応だったか？意味のある質問数、意思決定の前進・停滞理由など観測すべき反応を測る（学習が起きる瞬間）。 - 新規顧客仮説の検証
顧客の反応を受けて、顧客（顧客価値）仮説を検証する。
それぞれ、詳しく見ていきましょう。
価値を創出する活動（Innovation）の場合
まず、価値を創出する活動（Innovation）の場合、スループットは、
一定期間あたりに前進した「価値仮説の数・質」
です。
例えば、
・顧客課題仮説が1つ検証された
・価値提案が否定された（＝学習が進んだ）
・MVPの改善サイクルが1周回った
など、正解に近づく速度 = スループットです。
なので、制約を特定する場合、次のような観点で考えます。
- スループットを止める活動は何か？考える
スループットを止める活動とは
・仮説が検証されない活動
・学習が進まない活動
です。
具体例
・完璧な企画書作り
・過剰な仕様検討
・社内承認のためだけの議論
・顧客に当たらない開発
これは、「それ、学習が前に進む？」で見抜くことができます。 - 代替が効くか？でふるいにかける
以下のような問を発します。
・他の人、他の方法、AIで代替できるか？
・やらなくてもスループットは落ちないか？
具体例
・資料作成 → 代替可
・顧客インタビュー → 代替不可
・仮説の構造化 → 代替しにくい
代替できない活動が制約候補になります。 - 他が従属しているか？を見る
ここで「真の制約」が見えてきます。
以下のような問を発します。
・この活動が止まると、全部止まるか？
・開発も検証も意思決定も止まるか？
具体例
・顧客課題仮説が固まらない
・MVPも検証も全部止まる
学習の起点が制約になりやすいです。 - 1点だけ仮説として決める
ここが「経営の覚悟」です。
制約仮説の例
「今の制約は、顧客課題仮説の質と検証速度である」
正しいかどうかより、1点に集中することが重要です。
TOCは、「当てる理論」ではなく「集中させる理論」です。
価値を伝える活動（Communication）の場合
価値を伝える活動（Communication）の場合、スループットは、
正しく選択された顧客・市場との接点の増加
です。
例えば、
・適切な顧客セグメントからの反応数
・無駄なリードが減り、意味のある対話が増えた
・顧客が「自分ごと」として理解した回数
など、選択の精度が上がること = スループットです。
- スループットを止める活動は何か？考える
スループットを止める活動とは、
顧客の意思決定を遅らせる・迷わせる活動
です。
具体例
・メッセージが多すぎる
・セグメントが曖昧
・誰に向けた価値か分からない資料
・機能説明ばかりの営業
「顧客が選べなくなる活動」が制約候補になります。 - 代替が効くか？でふるいにかける
具体例
・広告運用 → 代替可
・顧客の反応を読み取る → 代替困難
・価値の言語化 → 人の知性が必要
「判断」「意味づけ」は代替しにくいです。 - 他が従属しているか？を見る
顧客が選べないと何が起きるか？考えます。
具体例
メッセージが曖昧→ マーケも営業も迷走
「選択の軸」が制約になりやすいです。 - 1点だけ仮説として決める
制約仮説例
「今の制約は、顧客が価値を即座に理解できないこと」
正しいかどうかより、1点に集中することが重要です。
最後に、この企業変革では、TOC × 生成AI によって、制約になりやすいオペレーションをAIで極限まで自律化し、人の知性を 価値創造（Innovation）と価値伝達（Communication）に集中できる仕組を構築することを目指します。
事業ライフサイクルの観点で見ると、価値を届ける活動（オペレーション）が確立された、花形や金のなる木に位置づけられる事業ほど、AIによる自律化の効果が大きい領域です。
これらの事業を徹底的に自律化することで、安定したスループットを維持しながら、人的資産という最も希少な経営資源を、新規事業や問題児の状態にある事業へと戦略的にシフトさせることが可能になります。
これは単なる業務効率化ではありません。
既存事業から知性を解放し、未来を創る事業へ再配分するための、経営構造そのものの転換です。
生成AIの登場によって、オペレーションの自律化が現実の選択肢となった今、「どこに人を使い、どこをAIに任せるのか」は、企業の成長を左右する戦略的意思決定になりました。
TOC × 生成AI は、その意思決定を一貫した論理で支え、企業を持続的に学習し進化する組織へと導くための、極めて実践的なフレームワークなのです。
企業変革支援サービスのご紹介
カルノ株式会社では、本企業変革のステップに則って、DXによる企業変革を進めるご支援をさせていただいております。
詳細は以下を御覧ください。
企業変革支援サービス
[…] の制約が原因である場合、制約スコアなどビジネスプロセスのKPI値に問題が生じます。 […]