
ここでは、データドリブン経営について、次の観点で説明します。
データドリブン経営とは
データドリブン経営とは、
社員一人ひとりが
データとAIなどのデジタル技術を活用して
仮説と検証を繰り返し
自律的に業務課題を解決することができる
科学的マネジメント
のことです。
下図は、データドリブン経営のマネジメントサイクル(PDCAサイクル)です。

通常のマネジメントサイクルとどこが違うのかを見ながらデータドリブン経営の特徴について見ていきましょう。
通常のマネジメントサイクルの場合、次のような流れになります。
- BSCやKPIで目標を管理している場合、Planで、BSCのKPI目標を実現するためのアクションプランを策定します。
- 次に、Doで、策定したアクションプランを遂行します。
- 次に、Checkで、目標と実績のGAPである問題を特定し、その根本的な原因を推定します。
- 最後に、Actで原因を取り除くことを課題、Issueとして設定し、課題に対する解決策を考案し、解決策を組み込んだPlanを策定します。

この2つを比較してみると、マネジメントサイクルのうちCheck(検証)とAct(改善)の部分が違います。
従来からあるマネジメントに対して、データドリブン経営が違う点、つまりデータドリブン経営の特徴は、次の2点になります。
①データやAIなどのデジタル技術を使って、できるだけ客観的な事実を基により適切な意思決定をするプロセスになっていること
②予測困難な時代、できるだけ成功の確度を上げるために、仮説と検証繰り返して業務課題を解決するプロセスになっていること
です。
具体的に見ていきましょう。
まず、データドリブン経営は、データやAIなどのデジタル技術を使って、できるだけ客観的な事実を基に、より適切な意思決定をするプロセスです。
具体的に言うと、データドリブン経営では、問題を特定するとき記述的分析(Descriptive Analytics)をし、原因を推定するとき予測的分析(Predictive Analytics)をし、解決策を考案するとき処方的分析(Prescriptive Analytics)をします。
この3つのデータ分析のうち、記述的分析は、BI(ビジネスインテリジェンス)を活用し、予測的分析と処方的分析はAI(人工知能)を活用します。
記述的分析は、過去や現在の状況を「見える化」する方法であるため、既存の構造化データ(RDBなど)を効率的に集計・可視化するBIのほうが適しており、予測的分析は、過去のデータからパターンを学習し、「未来を予測」し、処方的分析は、予測に基づいて「最適な意思決定・行動提案」を行う方法なので、大量で多様なデータから傾向を自動的に学習し、未来の値を予測し、人間には困難な最適解や推奨アクションを導き出すAIのほうが適しているからです。
それから、この記述的分析、予測的分析と処方的分析を従来のデータ分析とし、データ活用という点で、生成AIの活用と比較すると次のようになります。
- 従来のデータ分析
- 主に数値データや構造化データを対象とし、統計モデルや機械学習を用いて処理する。
- 「解釈する(記述的分析)」「分類・予測する(予測的分析)」「最適化する(処方的分析)」といった分析的なタスクに特化している。
- 成果物は、過去の傾向の可視化や将来の数値予測、最適な意思決定に資する数値的な答えなど、定量的でロジカルな知見。
- 生成AIの活用
- 主に非構造化データ(文章・画像・音声など)を対象とし、学習済み知識をもとに新しいコンテンツを生成することを目的とする。
- 「テキスト要約」「レポート自動生成」「顧客対応シナリオの作成」「画像や動画生成」など、人間が理解・利用しやすい形式に落とし込むことを得意とする。
- 成果物は、自然言語による説明やビジュアル表現など、人に伝わる形でのアウトプット。
なお、従来AIと生成AIは対立する技術ではなく、それぞれの強みを活かすことで、次のような補完関係を形成します。
- 従来AIは、数値的な予測や最適解の算出に優れており、客観的な意思決定を支える。
- 生成AIは、その結果をわかりやすく解釈し、人間とのインターフェースとして提示することで、意思決定や行動への橋渡しを行う。
なので、AIエージェントも含めて生成AIは、データドリブン経営のマネジメントサイクルを構成するすべてのタスクで活用することができます。
人間が目的を持ってAIエージェントを訓練するすることで、データドリブン経営の精度を上げるとともに、データドリブン経営を加速させることができます。
次に、データドリブン経営は仮説と検証繰り返して業務課題を解決する科学的マネジメントです。
データドリブン経営では、解決策を仮説として考え、ランダム化比較実験を通して、解決策の妥当性を統計的に検証し、誰もが実践できるよう、妥当な解決策をビジネスプロセスに組み込みます。
この実証された解決策(何をすればうまくいくか・何をすればうまくいかないか)と、それを組み込んだビジネスプロセスが組織ナレッジになります。
先行き不透明で予測困難な時代、これまでうまくいった方法を前提に計画、実行、検証、改善というPDCAサイクルをまわしても、前提自体が間違っている場合、うまく機能しません。
このような時代、環境の変化に応じて迅速に事業を変革・創出し続けるためには、環境の変化を察知して仮説を立て、実験してうまくいく方法を探してから、その方法を実践するという仮説検証型のアプローチのほうが有効です。
つまり、仮説検証を繰り返すことで体系的にナレッジ(何をすればうまくいくか・何をすればうまくいかないか)が蓄積され、持続可能性を高める、やればやるほど成功の確度が上がる仕組みをつくることが重要なのです。

最後に、データドリブン経営は、社員一人ひとりが自律的に課題を解決するマネジメントです。
データドリブン経営は、一部のマネジメント層だけが実施するのではなく、企業を構成するメンバー一人ひとりが、アイデアを出し、仮説を立てて自ら課題を解決するマネジメント手法です。
データドリブン経営によって、社員一人ひとりが透明かつ公平な評価の下、事業への貢献と、事業とともに成長する喜びを享受することで価値創造の企業文化が育まれていくのです。
データドリブン経営のマネジメントサイクル
次に、データドリブン経営の具体的なマネジメントサイクルについて説明します。
その際、制約理論(TOC)と対応づけながら説明します。
- 計画(Plan)
戦略フェーズで策定された、バランススコアカード(BSC)のKPI目標を実現するためのアクションプランのスケジュールを設定します。 - 実行(Do)
アクションプランを実行します。 - 検証(Check)
検証は「問題の特定」「原因の推定」の順で行います。- 問題の特定
まず、KPI目標値と実績のGapである問題を発見します。
次に、ドリルダウン・アップやスライシングによる多次元分析によって、どこに問題があるか特定します。
データ分析は、記述的分析、予測的分析、処方的分析に分けることができますが、多次元分析は、記述的分析(Descriptive Analytics)になります。
例えば、次のようなデータ分析で問題を特定します。- どの店舗に問題があるか
- よく買ってくれる顧客は誰か(顧客のセグメント別分析)
なお、2つ目のケースなどのように「機会」は、負(ネガティブ)の問題と考えます。
- 原因の推定
多次元分析によって、どこに(Where)問題があるか特定できたら、次に、なぜ(Why)問題が生じたのか、仮説推論(Abduction)で問題の原因を推定します。
そして、回帰分析など機械学習を通して原因の確からしさを検証します。
回帰分析は主に帰納(Induction)的な手法であり、与えられたデータから一般的な法則になる変数間の関係性を導きます。
なお、回帰分析は、予測的分析(Predictive Analytics)になります。
例えば、次のようなデータ分析で原因を推定します。- 問題がある店舗の何が原因(接客、品揃えなど)で問題が生じているか
このような原因で店舗に問題がある。 - よく買ってくれる顧客の特徴(顧客の属性)は何か
こういう特徴がある顧客は、この製品をよく買ってくれる。 - よく買ってくれる顧客は製品やサービスの何に(提供商品の特徴)価値を感じているか
製品がこういう価値を提供するから、顧客がよく買ってくれる。
制約理論(TOC)では、問題を発生させる原因を、スループットに対する制約として特定します。
制約の種類には、次のようなものがあります。- 計画レベルの制約
- 具体的な顧客に関する制約
- 具体的な製品に関する制約
- アクションプランのスケジュールに関する制約
- 具体的な財務資産(特定の設備など)に関する制約
- 具体的な場所(特定の店舗や倉庫など)に関する制約
- システム(物理的なアプリケーション・データ・IT)に関する制約
- 具体的なメンバー(具体的な単数、複数の社員)に関する制約
- 具体的なパートナー(具体的な単数、複数の取引先)に関する制約
- 戦略レベルの制約
- 顧客カテゴリ(市場)に関する制約
- 製品カテゴリ(製品ポジション)に関する制約
- アクションプランに関する制約
- 財務資産カテゴリ(設備など財務資産の種類)に関する制約
- 場所カテゴリ(店舗や販売エリア、販売チャネルなど物理的、論理的場所の種類)に関する制約
- 組織(部門)に関する制約
- システムカテゴリ(アプリケーション・データ・IT)に関する制約
- メンバーカテゴリ(社員の種類)に関する制約
- パートナーカテゴリ(取引先の種類)に関する制約
- 設計レベルの制約
- ビジネスプロセスに関する制約
- 財務資産タイプ(設備など財務資産のタイプ)に関する制約
- 場所タイプ(店舗や販売エリア、販売チャネルなど物理的、論理的場所ののタイプ)に関する制約
- ジョブ(職務)に関する制約
- システムアーキテクチャ(アプリケーション・データ・IT)に関する制約
- メンバータイプ(社員のタイプ)に関する制約
- パートナータイプ(パートナーのタイプ)に関する制約
なお、制約を特定するときは、システム思考で根本的な原因を推定します
- 問題がある店舗の何が原因(接客、品揃えなど)で問題が生じているか
- 問題の特定
- 改善(Act)
改善は「課題の設定」「解決策の考案」「実験計画の策定」「解決策の検証」「業務の改革・改善」の順で実施します。- 課題の設定
まず、原因を取り除くことを課題(Issue)として設定します。
例えば、店舗の問題の原因が接客にあるのであれば、接客を改善することが課題になります。
また、よく買ってくれる顧客の特徴がわかれば、似たような特徴を持つ顧客に製品をプロモーションして購買量を増やすことが課題になります。
制約理論(TOC)の場合、次のような制約の制御方法を課題として設定します。
制約の改善(Exploit the Constraint)
制約への適合(Subordinate Everything Else to the Constraint)
制約の克服(Elevate the Constraint) - 解決策の考案
次に、仮説推論(Abduction)で、課題に対する解決策(仮説)を考えます。
その中には、AIを活用した解決策(レコメンド、最適な治療法の提案、最適な学習経路の提案など)も含みます。
例えば、よく買ってくれる顧客と似たような特徴を持つ顧客の抽出には、類似性マッチング(similarity matching)などの機械学習モデルを活用することができます。
AIを活用した解決策は、処方的分析(Prescriptive Analytics)になります。
制約理論(TOC)の場合、具体的な制約の制御方法を考えます。- 計画レベルの見直し
- アクションプランのスケジュールを見直す
- 物理的なシステム(アプリケーション・データ・IT)の能力を改善する
- 具体的な場所(特定の店舗など)を改善する
- 具体的な財務資産(特定の設備など)を改善する
- 特定のパートナーを変える、あるいは、パートナーの数を増やす
- 特定のメンバーを変える、あるいは、メンバーの数を増やす
- 具体的な製品の機能や品質を改善する
- 具体的な顧客との関係を見直す
- 戦略レベルの見直し
- アクションプランを見直す
- システムカテゴリ(アプリケーションカテゴリ・データカテゴリ・ITカテゴリ)を見直す
- 組織(部門)を見直す
- 場所カテゴリ(店舗や販売エリアなど場所の種類)を見直す
- 財務資産カテゴリ(設備など財務資産の種類)を見直す
- パートナーカテゴリ(取引先の種類)を見直す
- メンバーカテゴリ(社員の種類)を見直す
- 製品カテゴリ(製品ポジション)を見直す
- 顧客カテゴリ(市場)に関する制約
- 設計レベルの見直し
- ビジネスプロセスを改善・改革する
- システムアーキテクチャ(アプリケーションタイプ・データタイプ・ITタイプ)を再設計する
- ジョブ(職務)を再設計する
- 場所タイプ(店舗や販売エリアなど場所のタイプ)を再設計する
- パートナータイプ(パートナーのタイプ)を再設計する
- メンバータイプ(社員のタイプ)を再設計する
このうち、システムのアプリケーションは、エンタープライズアーキテクチャのアプリケーションアーキテクチャ、データは、データアーキテクチャ、ITは、テクノロジーアーキテクチャ、システム以外の部分はビジネスアーキテクチャの設計に該当します。
- 計画レベルの見直し
- 実験計画の策定
次に考案された課題解策を実証するために、ランダム化比較実験など因果推論に基づいた実験計画を策定します。 - 解決策の検証
ランダム化比較実験を行い課題と解決策に、因果関係(一般的法則)があるか統計的に検証します。
例えば、類似性マッチング(similarity matching)などの機械学習モデルを使って優良顧客の類似顧客を抽出したら、本当に、その顧客に製品をプロモーションすると製品を買ってくれるかどうか実験して確かめます。
PoC(Proof of Concept:概念実証)も解決策の検証に入ります。
例えば、計画レベルの見直しで、特定の店舗を改善し、その効果が検証さた場合、その店舗を前提にアクションプランのスケジュールを立案します。戦略レベルの見直しの場合、上記「解決策の考案」のアクションプランの見直しから始めて、上記制約の克服の順番で解決策の考案→実験計画の策定→解決策の検証プロジェクトを繰り返します。そして、検証の結果、制約が克服できた場合、その方法で、次の戦略サイクルの戦略フェーズのアクションプラン(プログラム)を実行します(実験から実践へ)。
その際、その方法をアクションのガイドラインとして記録することによって組織ナレッジ(戦略ナレッジ)が蓄積されていきます。 - 業務の改革・改善
設計レベルの見直しの場合、上記「解決策の考案」のビジネスプロセスの改善・改革から始めて、上記制約の克服の順番で解決策の考案→実験計画の策定→解決策の検証プロジェクトを繰り返します。そして、検証の結果、制約が克服できた場合、その方法をビジネスプロセスに組み込んで、次の戦略サイクルの設計フェーズのアクションプラン(プログラム)を実行します(実験から実践へ)。その際、その方法をタスクのガイドラインとして記録することによって組織ナレッジ(規範ナレッジ)が蓄積されていきます。
実証された解決策を適用してアクションを実行し結論を導くのは演繹(Deduction)的アプローチです。
- 課題の設定
以上のように、データドリブン経営は、仮説検証を繰り返す科学的アプローチです。
PDCAの結果をすべて記録しノウハウとして蓄積することで学習し進化する組織が実現します。
データドリブン経営とTOC
ここでは、制約理論(TOC)とデータドリブン経営の関係について説明します。
次の図は、データドリブン経営のマネジメントサイクルにTOCのタスクを組み込んだイメージです。

データドリブン経営のマネジメントサイクルの「原因の推定」タスクで、TOCの5つのステップの制約の特定を実施します。
次に、「課題の設定」のときに、TOCの5つのステップの中の制約の改善、制約への適合、制約の克服から制約の統制方法を選択し、それを課題として設定します。
そして、「解決策の考案」で、具体的な制約の統制方法を考案します。
「実験計画の策定」、「解決策の検証」では、制約の統制方法がスループットを改善するか検証します。
制約の特定のときにも最小実験で裏取りしていますが、ここでは、より計画的に検証します。
データドリブン経営と業務改革・改善
ここでは、制約理論(TOC)に基づいた業務改革・改善について説明します。
次の図は、データドリブン経営と、業務改革、事業変革の活動の関係を表したものです。

解決策を考えるとき、まず、TOCを適用して課題を解決するための制約を特定し、TOCのステップ2から4で解決策を考案します。
TOCのステップ2から4、それぞれの解決策に対して実験を行い検証します。
業務改革・改善では、検証された解決策を反映した業務フローを設計します。
制約理論(TOC)に基づいた業務改善
制約理論(TOC)に基づいた事業変革
関連動画
データドリブン経営
.
[…] ;で早くすることができ、データドリブン経営による仮説検証の回転速& […]
[…] データドリブン経営 […]
[…] かります。 継続的な改善は、データドリブン経営として実行します。 […]
[…] ;革アプリケーションは、データドリブン経営の過程で開発れます。 業 […]
[…] ;、維持されたデータは、データドリブン経営によって利活用されます& […]
[…] ;することができる経営をデータドリブン経営といいますが、近い将来& […]
[…] ;することができる経営をデータドリブン経営といいますが、企業がデ& […]
[…] ;に生産性を上げた上で、データドリブン経営による仮説検証の仕組に& […]
[…] データドリブン経営が実践できる仕組にする データドリブン経営とは、 社員一人ひとりが データとAIなどのデジタル技術を活用して 仮説と検証を繰り返し 自律的に業務課題を解決する […]
[…] PDCAのCheck(検証)とAct(改善)を事業のステージ別に分けて説明します。 下図は、データドリブン経営のマネジメントサイクル(PDCAサイクル)です。 Check(検証)の「問題の特定」タ […]
[…] それでは、経営活動においてナレッジマネジメントはどう位置づけられるのでしょうか。 下図は事業ライフサイクルを表した図です。 運用フェーズのマネジメントサイクル(PDCAサイクル)でデータドリブン経営のマネジメントサイクルが実行されます。 […]