システム思考(Systems Thinking)とは、ある問題を個々の要素や単独の原因だけで説明するのではなく、要素間の相互作用、フィードバック、時間の遅れ、全体として現れる振る舞いなどに注目して理解しようとする考え方です。
例えば、ある工場で納期遅延が増加しているとします。納期を守るために残業を増やした結果、一時的には生産量が増えるかもしれません。しかし、長時間労働による疲労が増え、作業ミスや設備トラブルが発生しやすくなれば、かえって生産効率が低下する可能性があります。その結果、さらに残業を増やす必要が生じるかもしれません。
この問題を単純な因果関係として捉えるなら、「納期遅延が増えたので残業を増やす」という説明になります。しかし、残業が作業品質や将来の生産能力に影響し、それが再び納期遅延へ影響するのであれば、複数の要因が循環的に関係していることになります。
システム思考では、このような相互作用を考え、目先の問題への対応が、時間を経て別の問題を生み出さないかを検討します。
また、ある部門では合理的な判断が、組織全体では望ましくない結果を生む場合もあります。例えば、調達部門が大量購入によって単価を下げようとしても、過剰在庫や保管費用が増えれば、会社全体の利益が悪化する可能性があります。
システム思考の特徴は、個々の判断や行動を切り離して評価するのではなく、それらが全体の中でどのような影響を及ぼし合うかを考えることです。
ただし、「すべてのものはつながっている」という一般論だけでは、具体的な分析にはなりません。どの要素がどの要素に影響するのか、その影響はどの程度か、どのような時間差があるのかを確認する必要があります。
システム思考の目的は、問題を単に複雑に捉えることではありません。問題を生み出している相互作用の構造を理解し、どこに働きかければ望ましい変化を生み出せるかを考えることです。
システム思考の歴史と理論的背景
システム思考には、単一の創始者や統一された手順が存在するわけではありません。生物学、制御工学、情報科学、経営学、社会科学など、複数の分野におけるシステム研究が背景になっています。
20世紀には、ルートヴィヒ・フォン・ベルタランフィ(Ludwig von Bertalanffy)による一般システム理論、ノーバート・ウィーナー(Norbert Wiener)によるサイバネティクスなどが、要素間の関係やフィードバックを理解するための重要な理論的基盤を提供しました。
1950年代には、ジェイ・フォレスター(Jay W. Forrester)がMITでシステムダイナミクス(System Dynamics)を開発しました。1961年の著書『Industrial Dynamics』では、企業の生産、在庫、流通などの活動を、フィードバックや時間の遅れを含む動的なシステムとして扱いました。
その後、システムダイナミクスは都市、経済、環境、エネルギーなどの問題へ応用されました。
1990年には、ピーター・センゲ(Peter M. Senge)が『The Fifth Discipline』を刊行し、組織学習と経営管理におけるシステム思考を広く紹介しました。
また、ドネラ・メドウズ(Donella H. Meadows)は、システムの振る舞いを理解し、変化を生み出すための介入点について重要な研究を行いました。
| 研究者・研究領域 | 主な貢献 |
|---|---|
| Ludwig von Bertalanffy | 一般システム理論。システムを相互関係のある全体として扱う |
| Norbert Wiener | サイバネティクス。制御、通信、フィードバックを研究 |
| Jay W. Forrester | システムダイナミクス。ストック、フロー、フィードバックを数理モデル化 |
| Peter M. Senge | 組織学習へのシステム思考の応用 |
| Donella H. Meadows | システムの振る舞いと、変化を生み出す介入点の分析 |
このほかにも、ソフトシステム方法論(Soft Systems Methodology)、複雑適応系(Complex Adaptive Systems)、システム工学など、関連する研究分野が存在します。
ただし、これらは必ずしも同じ理論や方法を利用するわけではありません。
本ページでは、特に組織や事業、技術開発などの問題を考えるためのシステム思考を中心に説明します。
システムとは何か
システムとは、複数の要素が相互に関係し、一定の構造や働きを形成しているものとして捉えられます。
例えば、工場の生産システムには、設備、作業者、材料、工程、品質管理、在庫、受注、出荷などが関係しています。
これらの要素は、それぞれ独立して存在しているわけではありません。
受注が増えれば、生産計画が変更されるかもしれません。生産計画が変更されれば、材料の発注量や作業者の配置が変わります。設備の稼働率が上昇すれば、保守の必要性や故障リスクにも影響する可能性があります。
システムの性質を理解するためには、要素そのものだけでなく、要素間の関係を考える必要があります。
ただし、何を一つのシステムと見なすかは、分析の目的によって変わります。
例えば、生産設備の保全を検討する場合には、設備の構造、使用条件、故障、保守作業などに注目するでしょう。
一方、企業全体の収益性を検討する場合には、生産だけでなく、販売、調達、在庫、開発、投資なども対象にする必要があります。
つまり、システムの境界は、常に自然に決まるものではありません。
分析の目的に応じて、どこまでを対象に含めるかを決める必要があります。
要素ではなく関係を見る
システム思考の重要な特徴は、要素の一覧を作るだけでなく、それらがどのように影響し合っているかを考えることです。
例えば、製造品質に関係する要素として、設備、材料、作業者、工程条件、検査方法などを挙げられます。
これは、原因分析やロジックツリーによる問題の分解としても利用できる考え方です。
しかし、実際には、これらの要素が互いに影響していることがあります。
例えば、設備の稼働率が高まると保守作業の時間が不足し、それによって設備の状態が悪化し、不良品や設備停止が増加する可能性があります。
また、不良品が増えることで再加工が必要になり、設備の稼働時間がさらに増えるかもしれません。
このような場合、問題を個別の要因へ分解するだけでは、全体の振る舞いを十分に理解できません。
システム思考では、それらの要素が形成する相互作用に注目します。
| 問題の捉え方 | 主な問い |
|---|---|
| 要素への分解 | どの要素が問題に関係しているか |
| 関係の分析 | それらの要素は、どのように影響し合うか |
| 時間変化の分析 | その影響は、時間とともにどう変化するか |
| 介入の検討 | どこを変更すれば、全体の振る舞いが変わるか |
ただし、要素への分解が不要になるわけではありません。
複雑なシステムを理解するには、個々の要素について正確な知識を得ることも必要です。
要素の分析と関係の分析は、互いに補完するものです。
システム思考の基本概念
システム思考を理解するうえでは、いくつかの基本概念が重要になります。
| 概念 | 意味 |
|---|---|
| 相互依存(Interdependence) | 複数の要素が互いに影響する |
| フィードバック(Feedback) | ある変化の結果が、再び元の変化に影響する |
| 時間の遅れ(Delay) | 行動と結果の間に時間差がある |
| ストック(Stock) | 時間とともに蓄積される量 |
| フロー(Flow) | ストックを増減させる流入・流出 |
| 非線形性(Nonlinearity) | 入力と結果が単純な比例関係にならない |
| 創発(Emergence) | 要素の相互作用から、全体としての性質や振る舞いが現れる |
| システム境界(System Boundary) | 分析する対象の範囲 |
| レバレッジポイント(Leverage Point) | システムの振る舞いを効果的に変えられる可能性のある介入点 |
これらは、常にすべてのシステムへ当てはめるべきチェックリストではありません。
問題を理解するために、どの概念が必要かを判断することが重要です。
フィードバック ― 結果が再び原因に影響する
システム思考の中心的な概念の一つが、フィードバックです。
フィードバックとは、ある要素の変化が他の要素へ影響し、その結果が元の要素へ再び影響する仕組みです。
通常の直線的な因果関係では、AがBへ影響し、BがCへ影響するという一方向の関係を考えます。
一方、フィードバックでは、AからB、BからC、さらにCからAへと影響が循環することがあります。
このような循環構造は、システムが時間とともに示す振る舞いを理解するために重要です。
フィードバックは、大きく分けて、強化型フィードバックと調整型フィードバックに区別されます。
強化型フィードバック(Reinforcing Feedback)
強化型フィードバックは、ある変化をさらに強める方向に働く循環です。
例えば、あるサービスについて、次のような関係を考えます。
「利用者が増える」
↓
「口コミや紹介が増える」
↓
「サービスを知る人が増える」
↓
「新しい利用者が増える」
↓
「さらに利用者が増える」
このような関係が実際に成立する場合、利用者の増加がさらに利用者を増やす方向へ働く可能性があります。
ただし、利用者が増えすぎるとサービスの品質が低下したり、対応能力が不足したりすることもあります。
その場合には、別のフィードバックが成長を抑える可能性があります。
なお、強化型フィードバックは、必ずしも望ましい成長を意味しません。
悪化をさらに加速させる循環も、強化型フィードバックです。
調整型フィードバック(Balancing Feedback)
調整型フィードバックは、変化を打ち消したり、一定の目標へ近づけたりする方向に働く循環です。
例えば、倉庫の在庫が不足した場合を考えます。
「在庫不足が大きくなる」
↓
「発注量を増やす」
↓
「入荷量が増える」
↓
「在庫不足が小さくなる」
これは、在庫不足を解消する方向に働く調整型フィードバックです。
ただし、発注から入荷までに時間がかかると、状況が変化する前に追加の発注が重なり、在庫が過剰になる可能性があります。
調整型フィードバックが存在しても、システムが必ず安定するわけではありません。
因果ループ図とは何か
フィードバックの構造を整理する代表的な方法が、因果ループ図(Causal Loop Diagram:CLD)です。
因果ループ図では、時間とともに変化する変数を取り上げ、それらの影響関係を矢印で結びます。
矢印には、通常、プラス(+)またはマイナス(−)の極性を付けます。
プラスは、他の条件が同じなら、原因側の変数が増加したときに結果側の変数も増加する方向へ変化することを示します。
マイナスは、原因側の変数が増加したときに結果側の変数が減少する方向へ変化することを示します。
ここで重要なのは、プラスが「よい影響」、マイナスが「悪い影響」を意味するわけではないことです。
また、因果ループ図では、強化型の循環をR(Reinforcing)、調整型の循環をB(Balancing)として表すことがあります。
因果ループ図は、システム思考を具体化するうえで有用ですが、それを描くこと自体が因果関係の証明にはなりません。
分析者が想定した関係を図として表しただけの場合もあります。
因果ループ図は、複雑な相互作用についての仮説を表現する道具であり、現実の因果構造が確認されたことを示すものではありません。
因果ループ図の記号、作成手順、フィードバックの極性の読み方などは、別ページの「因果ループ図」で詳しく説明します。
時間の遅れ ― 改善が逆効果になる理由
システムの振る舞いを考える際には、時間の遅れ(Delay)が重要です。
例えば、工場で在庫が不足していることに気づき、発注量を増やしたとします。
しかし、材料が入荷するまでに数週間かかる場合、その間に在庫不足が続く可能性があります。
担当者が不足を解消するために追加発注を繰り返せば、後になって大量の材料が入荷し、過剰在庫になるかもしれません。
そこで発注量を減らしすぎると、今度は再び在庫不足が発生する可能性があります。
このような振る舞いは、フィードバックと時間の遅れの組み合わせによって生じる場合があります。
ただし、時間の遅れが存在するだけで、必ず振動や不安定性が発生するわけではありません。
実際の振る舞いは、制御の仕組み、調整の強さ、在庫量、需要の変化などにも左右されます。
例えば、次のような活動には時間の遅れが存在します。
| 活動 | 時間の遅れの例 |
|---|---|
| 材料調達 | 発注から納品まで |
| 人材育成 | 教育から技能向上まで |
| 研究開発 | 投資から研究成果が得られるまで |
| 設備保全 | 保全活動から故障率への効果が現れるまで |
| マーケティング | 認知拡大から購買へ至るまで |
時間の遅れを考慮しないと、まだ効果が現れていない施策を失敗と判断したり、逆に短期的な改善だけで成功と判断したりする可能性があります。
ストックとフロー ― 蓄積を考える
システム思考に関連する重要な概念に、ストック(Stock)とフロー(Flow)があります。
ストックは、ある時点で蓄積されている量です。
フローは、一定の時間内にストックへ流入したり、ストックから流出したりする量です。
例えば、倉庫の在庫量はストックです。
入荷量と出荷量はフローです。
ある期間の在庫変化は、単純化すると次のように表されます。
期末在庫量=期首在庫量+期間内入荷量−期間内出荷量
この関係は、在庫の増減を考えるうえで基本となります。
ただし、実際には廃棄、紛失、返品などを考慮する必要がある場合もあります。
別の例として、問い合わせ対応の未処理件数を考えられます。
| ストック | 流入 | 流出 |
|---|---|---|
| 在庫量 | 入荷 | 出荷 |
| 未処理問い合わせ件数 | 新規問い合わせ | 対応完了 |
| 従業員数 | 採用 | 退職 |
| 利用中の有料会員数 | 新規登録・復帰 | 解約 |
ここで重要なのは、ストックとフローでは単位が異なることです。
例えば、在庫量は「個数」ですが、入荷率や出荷率は「個数/日」などで表されます。
ストックはフローの差によって時間とともに変化します。
そのため、ある時点で流入量が減少しても、流入量が流出量を上回っている限り、ストックが増加し続ける場合があります。
このような蓄積の関係は、単に要素間を矢印で結んだだけでは理解しにくいことがあります。
システムダイナミクスとの関係
システム思考とシステムダイナミクスは、密接に関連していますが、同じ意味ではありません。
システム思考は、相互依存、フィードバック、時間変化などに注目する広い考え方です。
一方、システムダイナミクスは、これらの関係を数理モデルとして表現し、時間とともにシステムがどのように変化するかを分析するための方法論です。
代表的なシステムダイナミクスのモデルでは、ストック、フロー、補助変数、フィードバックなどを利用します。
例えば、未処理の問い合わせ件数を (B(t))、新規問い合わせの発生率を (I(t))、対応完了率を (O(t)) とすると、単純化されたモデルでは次のように表せます。
[
\frac{dB(t)}{dt}=I(t)-O(t)
]
この式は、未処理件数の変化率が、新規問い合わせの発生率と対応完了率の差によって決まることを表しています。
さらに、対応完了率が担当者数、業務負荷、処理能力などに左右されると考えれば、それらの関係を追加できます。
ただし、単に数式を作るだけでは、現実の振る舞いを正しく予測できるとは限りません。
処理能力や時間の遅れなどについて、適切な関係式とパラメータが必要です。
システムダイナミクスでは、こうしたモデルを使って、条件や施策を変更した場合の時間変化をシミュレーションできます。
| 観点 | システム思考 | システムダイナミクス |
|---|---|---|
| 基本的な目的 | 相互作用や全体の振る舞いを理解する | 時間変化をモデル化し、分析する |
| 表現方法 | 文章、関係図、因果ループ図など | ストック・フロー図、方程式など |
| 数値データ | 必須ではない | 定量モデルでは必要 |
| 得られるもの | 構造についての理解や仮説 | モデル条件下での動的な予測やシナリオ |
| 主な注意点 | 関係の想定が正しいとは限らない | モデル構造とパラメータの妥当性が必要 |
システムダイナミクスは、システム思考を数理的に扱うための重要な方法ですが、システム思考のすべてを代表するものではありません。
非線形性 ― 小さな変化が大きな結果を生む場合
現実のシステムでは、入力と出力が単純な比例関係になるとは限りません。
例えば、生産設備の稼働率が70%から80%へ上昇しても、待ち時間や納期への影響は比較的小さいかもしれません。
しかし、稼働率が限界に近づくと、わずかな負荷増加によって待ち時間が大きく増える場合があります。
これは、処理能力に余裕が少なくなった結果、変動を吸収しにくくなるためです。
ただし、具体的な待ち時間の増加は、到着率、処理時間のばらつき、設備構成、優先順位などによって異なります。
このように、ある要因を少し変化させたときの結果が、その時点の状態によって大きく異なる場合があります。
また、一定の閾値を超えたときに、システムの振る舞いが急激に変化することもあります。
非線形性を持つシステムでは、過去の小さな変化に基づいて、将来の大きな変化を単純に比例計算することが適切でない場合があります。
創発 ― 全体に現れる性質
システム思考に関連する概念に、創発(Emergence)があります。
創発とは、複数の要素の相互作用によって、個々の要素だけを見ても十分には説明できない全体的な性質や振る舞いが現れることです。
例えば、交通渋滞は、個々の自動車の運転行動、車間距離、道路条件、交通量などの相互作用によって生じます。
それぞれの運転者が渋滞を作ろうと考えているわけではありません。
しかし、多数の車両が互いに影響し合うことで、交通の流れに特徴的な現象が生じます。
同様に、企業組織でも、個々の担当者が合理的に行動していても、情報伝達の遅れや部門間の目標の違いによって、全体として非効率な状態になる場合があります。
ただし、全体に現れる現象がすべて説明不能であるという意味ではありません。
交通流や待ち行列などの現象については、数理モデルによって説明・予測できる部分もあります。
重要なのは、個々の要素の性質だけでなく、要素間の相互作用を分析する必要があるということです。
システムの境界をどこに置くか
システム思考では、分析対象の境界を決めることが重要です。
例えば、製造工程の不良率について考える場合、対象を一つの設備に限定すれば、設備の状態や加工条件に注目することになります。
しかし、不良率が材料ロットや工程間の調整にも関係している場合、設備だけを対象にした分析では重要な要因を見落とす可能性があります。
逆に、工場全体、調達先、顧客、市場、法規制まで含めると、分析対象が広すぎて実際の検討が難しくなる場合もあります。
システムの境界は、問題とする振る舞い、検討する時間範囲、分析の目的に応じて決める必要があります。
| 境界の設定 | 起こりやすい問題 |
|---|---|
| 狭すぎる | 重要な外部要因や相互作用を見落とす |
| 広すぎる | 変数が増えすぎて、モデル化や検証が難しくなる |
| 固定しすぎる | 新しい証拠によって境界を変更することが難しくなる |
| 曖昧なままにする | 何を説明するモデルなのか不明確になる |
また、誰の視点でシステムを定義するかによって、重要な問題が変わる場合があります。
例えば、調達部門は購入価格を重視し、生産部門は安定供給を重視し、経営部門は全体の利益を重視するかもしれません。
そのため、組織的な問題を扱う場合には、分析者が何を目的とし、どの立場からシステムを捉えているのかを明確にする必要があります。
システムアーキタイプ ― 繰り返し現れる振る舞いのパターン
システム思考では、異なる問題に共通するフィードバック構造を、システムアーキタイプ(Systems Archetypes)として整理することがあります。
ピーター・センゲの著書『The Fifth Discipline』などでは、組織や経営の問題に繰り返し見られる構造が紹介されています。
代表的なものを挙げます。
| アーキタイプ | 典型的な問題 |
|---|---|
| 成長の限界(Limits to Growth) | 成長を促す活動が進む一方で、別の制約が成長を抑える |
| 問題のすり替え(Shifting the Burden) | 短期的な対症療法に依存し、根本的な解決が進まなくなる |
| 逆効果の対策(Fixes That Fail) | 短期的な改善策が、後になって問題を悪化させる |
| 成功者への集中(Success to the Successful) | 成功している対象へ資源が集中し、差が拡大する |
| 共有資源の悲劇(Tragedy of the Commons) | 個々の合理的な利用が共有資源の劣化につながる |
例えば、ある企業で、売上が伸びている製品に研究開発費を集中したとします。
その結果、その製品の性能がさらに改善され、売上が増加するかもしれません。
一方、新しい分野への研究開発投資が減少すれば、将来の技術的な選択肢が狭くなる可能性があります。
このような現象は、「成功者への集中」というアーキタイプから検討できるかもしれません。
ただし、現実の問題を既存のアーキタイプへ無理に当てはめるべきではありません。
アーキタイプは、考えられる構造を発見するための手がかりであり、どの問題にもそのまま適用できる法則ではありません。
実際にどのようなフィードバックが働いているかについては、データや現場知識を確認する必要があります。
レバレッジポイント ― どこへ働きかけるか
システムの問題を理解した後には、どこへ働きかければ望ましい変化を生み出せるかを考える必要があります。
このような介入点を、レバレッジポイント(Leverage Point)と呼びます。
ドネラ・メドウズは、1999年の論考「Leverage Points: Places to Intervene in a System」で、システムを変化させるさまざまな介入点を整理しました。
その中には、パラメータの変更、ストックとフローの構造、時間の遅れ、フィードバック、情報の流れ、規則、目標、パラダイムなどが含まれています。
例えば、ある工場で過剰在庫が問題となっている場合、発注量の数値を調整するという対策が考えられます。
しかし、部門間の情報共有が不十分で、需要変化を適切に把握できないことが問題の一因であれば、発注量の調整だけでなく、情報の流れを変更する方が有効かもしれません。
さらに、部門ごとの評価指標が大量購入を促している場合には、その評価制度を見直すことも考えられます。
| 介入の種類 | 例 |
|---|---|
| パラメータの変更 | 発注点や安全在庫量を変更する |
| 情報の流れの変更 | 営業、生産、調達の情報を共有する |
| フィードバックの変更 | 需要変化を発注計画へ反映する仕組みを改善する |
| 規則の変更 | 大量購入だけを評価する仕組みを見直す |
| 目標の変更 | 購入単価の最小化から、総費用や供給安定性の改善へ変更する |
このように、目に見えている数値を調整するだけでなく、その数値を生み出す仕組みへ働きかけることが考えられます。
ただし、メドウズのレバレッジポイントの整理は、あらゆるシステムで同じ順位の効果が得られることを実証したものではありません。
本人も、複雑なシステムについて単純に一般化することの危険性を指摘しています。
どの介入が有効かは、対象とするシステムの性質や条件によって判断する必要があります。
実践例1 ― 在庫管理とブルウィップ効果
サプライチェーンでは、消費者の需要が比較的安定していても、小売、卸売、製造などの段階を経るにつれて、発注量の変動が増幅される場合があります。
この現象はブルウィップ効果(Bullwhip Effect)として知られています。
例えば、小売店で商品の販売量が少し増えたとします。
小売店は将来の品切れを避けるために、通常より多く発注するかもしれません。
卸売業者は、その発注量の増加を需要の急増と解釈し、さらに多くを製造業者へ発注するかもしれません。
このような行動が重なると、最終消費者の需要変動よりも、上流の発注量の変動が大きくなる場合があります。
ここで重要なのは、各担当者が不合理な判断をしているとは限らないことです。
各担当者は、納期遅延や品切れを防ぐために、合理的と考える行動を取っている可能性があります。
しかし、情報の遅れ、需要予測、発注ルール、在庫政策などが組み合わさることで、全体として大きな変動が生じることがあります。
この問題に対しては、単に担当者の判断を改善するだけでなく、情報共有、発注ルール、リードタイム、在庫管理の仕組みなどを検討する必要があります。
ただし、実際のブルウィップ効果には複数の要因が関係し、すべてのサプライチェーンで同じ仕組みが働くわけではありません。
実践例2 ― 製造品質と生産能力の悪循環
ある工場で生産能力が不足し、納期遅延が発生しているとします。
短期的には残業や設備の連続運転によって生産量を増やせる可能性があります。
しかし、長時間労働や保守時間の不足が作業品質や設備の状態へ影響すれば、不良品や設備停止が増えるかもしれません。
不良品が増えると、再加工や追加生産が必要になります。
その結果、設備や作業者の負荷がさらに高まる可能性があります。
このような関係が存在するなら、単純に稼働時間を増やすことが、長期的な生産能力の改善につながるとは限りません。
ここでは、以下のような要素間の関係を検討できます。
| 変数 | 想定される影響 |
|---|---|
| 生産負荷 | 稼働時間や作業者の負担に影響する |
| 保守時間 | 設備状態や故障発生に影響する |
| 作業者の疲労 | 作業ミスや生産性に影響する可能性がある |
| 不良率 | 再加工量や追加生産量に影響する |
| 再加工量 | 生産負荷を増やす可能性がある |
| 納期遅延 | 残業や特急処理の判断に影響する |
ただし、これらの関係はすべての工場に一律に成立するものではありません。
設備が十分に保全されている場合や、作業者の負担が適切に管理されている場合には、長時間運転によって同じ問題が生じるとは限りません。
重要なのは、想定した悪循環が現実に存在するかを確認することです。
そのうえで、稼働時間の増加、設備保全、工程改善、不良の削減など、異なる対策が全体へ及ぼす影響を比較できます。
実践例3 ― SaaS事業における成長と顧客維持
SaaS事業では、新規顧客の獲得と既存顧客の維持が重要です。
例えば、広告によって新規顧客を増やしたとしても、顧客が短期間で解約すれば、利用者数や売上の継続的な増加につながらない可能性があります。
また、顧客数が急増することでサポート業務が逼迫し、対応品質が低下すれば、解約率が高まるかもしれません。
一方、製品品質や利用体験の改善によって継続率が高まれば、顧客基盤が安定し、紹介による新規獲得にも影響する可能性があります。
| 要素 | 検討する関係 |
|---|---|
| 新規顧客獲得数 | 利用者数を増やす |
| 解約数 | 利用者数を減らす |
| 顧客数 | サポート業務量に影響する |
| サポート品質 | 顧客満足や継続率に影響する可能性がある |
| 利用者の評価 | 紹介や新規獲得に影響する可能性がある |
このようなシステムでは、広告費を増やすという一つの施策だけでなく、顧客獲得、継続率、サポート能力、製品品質などの関係を考える必要があります。
ただし、顧客満足度が高まれば必ず紹介が増えるというわけではありません。
その関係の強さは、製品の性質や利用者層によって変わる可能性があります。
実践例4 ― 研究開発における既存技術と新しい探索
研究開発では、すでに成果が見込める技術へ投資を集中することが合理的な場合があります。
しかし、短期的な成果だけを重視すると、新しい技術領域の探索へ十分な資源が配分されなくなる可能性があります。
例えば、次のような関係を考えられます。
「既存技術の改良によって短期的な成果が得られる」
↓
「既存技術への投資が優先される」
↓
「異分野や新技術の探索へ投入する資源が減る」
↓
「新しい研究開発候補が育ちにくくなる」
↓
「さらに既存技術への依存が強まる」
このような関係が存在する場合、個別の研究テーマの評価だけではなく、研究開発資源の配分や評価制度そのものが、将来の技術的な選択肢に影響している可能性があります。
一方、探索的な研究開発ばかりを増やせばよいというわけでもありません。
新しい技術の探索には不確実性があり、短期的な収益や既存事業の競争力を維持する活動も必要です。
ここでは、既存技術の改善と新しい可能性の探索の間で、どのように資源を配分するべきかという問題になります。
システム思考は、このような関係を検討するための一つの視点を提供します。
ただし、どのような配分が最適かは、企業の事業状況、技術分野、投資余力、目標期間などによって異なります。
システム思考の実践方法
システム思考には、すべての問題に適用できる唯一の手順があるわけではありません。
しかし、実際の問題を分析する際には、次のような作業を行うことが考えられます。
| 段階 | 作業 | 主な問い |
|---|---|---|
| 1. 問題を明確にする | 問題となっている振る舞いを特定する | 何が、いつから、どのように変化しているか |
| 2. 時間変化を確認する | 指標や出来事の推移を見る | 一時的な現象か、継続的な傾向か |
| 3. システム境界を設定する | 分析対象と時間範囲を決める | 何を含め、何を対象外とするか |
| 4. 関係する変数を抽出する | 重要な要素を整理する | どの要素が問題に関係するか |
| 5. 影響関係を検討する | 変数間の関係を仮説として記述する | 何が何に、どの方向へ影響するか |
| 6. フィードバックを探す | 循環的な関係を確認する | 結果が再び原因に影響しているか |
| 7. 蓄積と時間の遅れを考える | ストック、フロー、遅れを確認する | なぜ効果が遅れて現れるのか |
| 8. 仮説を検証する | データ、現場知識、実験などと照合する | 想定した関係は実際に成立しているか |
| 9. 介入点を考える | 改善案を比較する | どの変更が全体へ望ましい影響を与えるか |
| 10. 結果を確認する | 施策後の振る舞いを観察する | 予想外の影響や新たな問題はないか |
特に重要なのは、最初から大きな因果ループ図を描こうとしないことです。
まず問題となっている変化を確認し、それを説明するために必要な要素を追加していく方がよい場合があります。
また、仮説と確認された事実を区別して記録することも重要です。
システム思考とロジックツリーの違い
ロジックツリーは、対象や問題を階層的に分解する方法です。
例えば、製造原価を材料費、労務費、経費などへ分解できます。
このような分解は、原価の構成を理解するうえで有用です。
一方、システム思考では、材料費の削減が品質へ影響し、品質の低下によって再加工費や保証費用が増加する、といった関係も考えます。
つまり、ロジックツリーでは要素を分けることが中心になりますが、システム思考では分けられた要素がどのように影響し合うかが重要になります。
| 観点 | ロジックツリー | システム思考 |
|---|---|---|
| 主な目的 | 問題や対象を分解する | 相互作用と全体の振る舞いを理解する |
| 主な構造 | 階層構造 | ネットワークや循環構造 |
| 時間変化 | 必須ではない | 重要な分析対象 |
| フィードバック | 通常は中心的に扱わない | 重要な概念 |
| 主な用途 | 論点整理、構成分析、原因・施策の整理 | 動的な問題の理解、介入策の検討 |
ただし、両者は対立する方法ではありません。
ロジックツリーによって重要な要素を整理した後、それらの間に存在する相互作用をシステム思考で検討することもできます。
また、システム思考によって問題の構造を考えた後で、特定の要因について詳細な原因分析を行うこともできます。
対象を分解することと、要素間の関係を考えることは、補完的な活動です。
システム思考と根本原因分析の違い
根本原因分析(Root Cause Analysis:RCA)は、発生した問題について、その原因を特定し、再発防止につなげるための方法です。
一方、システム思考は、個々の原因だけでなく、要素間の相互作用や時間変化によって問題が生じる仕組みを考えます。
例えば、設備故障の原因が特定の部品の摩耗であると確認された場合、RCAによって摩耗の発生条件や再発防止策を検討できます。
しかし、なぜ保守が適切に行われなかったかを考えると、設備の稼働計画、保全人員、納期目標、評価制度などが関係しているかもしれません。
この場合、部品の摩耗という直接的な原因を特定するだけでなく、その状態を生み出している組織的な仕組みを検討することになります。
ただし、RCAでも複数の原因や組織的な問題を扱うことがあります。
したがって、両者を厳密に分離することはできません。
重要なのは、現在の問題に対して、どの範囲まで原因や相互作用を調べる必要があるかを判断することです。
システム思考と複雑系の関係
システム思考は、複雑系(Complex Systems)の研究とも関係しています。
複雑系では、多数の要素の相互作用、非線形性、適応、自己組織化、創発などが重要な研究対象になります。
例えば、市場では、多数の企業や消費者がそれぞれ意思決定を行い、その相互作用によって価格や競争構造が変化します。
また、企業や消費者は、環境の変化に応じて行動を変更することがあります。
このように、システムを構成する要素自体が学習や適応によって変化する場合があります。
ただし、システム思考と複雑系研究は同義ではありません。
システム思考は、問題を全体的な相互作用から理解するための幅広い考え方として利用されます。
複雑系研究では、数理モデルや計算機シミュレーションなどによって、複雑な振る舞いの成立条件を具体的に調べることがあります。
システム思考によって重要な構造を考え、その一部を数理モデルとして検討することもできます。
システム思考の限界1 ― すべてをつなげても説明にはならない
システム思考が形式的に利用されると、関係する要素をできるだけ多く挙げ、矢印で結びつけることが目的になってしまう場合があります。
しかし、変数を大量につなげた図を作るだけでは、問題を十分に説明したことにはなりません。
重要なのは、どの関係が実際に存在し、その関係が全体の振る舞いにどの程度影響しているかです。
例えば、売上高、従業員数、顧客満足度、広告費、製品品質などは、企業活動の中で相互に関係しているかもしれません。
しかし、それぞれの影響の強さや時間差が不明であれば、具体的な施策を判断することは難しいでしょう。
「すべてはつながっている」というだけでは、実務的な分析には不十分です。
システム思考の限界2 ― 因果関係を想像してしまう
因果ループ図などを作成する際には、分析者がもっともらしい因果関係を想定する場合があります。
例えば、「社員満足度が向上すると生産性が高まる」といった関係です。
このような関係が存在する場合はありますが、すべての組織や状況で成立するとは限りません。
また、生産性の向上が社員満足度を高める可能性もありますし、職場環境などの第三の要因が両方に影響する可能性もあります。
そのため、因果ループ図に矢印を描くことと、因果関係を確認することを区別する必要があります。
データ分析、現場観察、実験などによって、関係の成立を確認することが重要です。
また、すべての関係を厳密に検証できない場合には、未確認の仮説であることを明示しておく方が適切です。
システム思考の限界3 ― 複雑にしすぎる危険
問題を広く捉えようとするあまり、分析対象が際限なく拡大することがあります。
例えば、ある工場の不良率を分析していたところ、作業者の教育制度、企業文化、取引先との関係、市場環境などが次々に追加されるかもしれません。
これらが重要な場合もありますが、すべてを一度に分析しようとすると、実際の検証や改善が難しくなる可能性があります。
システム思考では、分析対象の境界を明確にし、問題を理解するために必要な範囲へ絞り込むことも重要です。
何でも含めることが、優れたシステム思考を意味するわけではありません。
システム思考の限界4 ― 図から将来が予測できるわけではない
因果ループ図によってフィードバックの存在を説明できたとしても、実際の時間変化を定量的に予測できるとは限りません。
例えば、ある強化型フィードバックが存在したとしても、その効果がどの程度強いのか、どの時点で別の制約が働くのかは、図だけではわかりません。
また、システムダイナミクスによって数値シミュレーションを実行した場合でも、モデルの構造やパラメータが現実に適合していなければ、結果は信頼できません。
シミュレーションは、入力した仮定とモデルに基づく計算結果です。
将来の出来事をそのまま保証するものではありません。
システム思考の限界5 ― 全体最適の基準が一つとは限らない
システム思考では、しばしば部分最適と全体最適の違いが強調されます。
しかし、実際の組織や社会では、何を全体最適と考えるかが明確ではない場合があります。
例えば、企業全体の利益を最大化することと、従業員の負担を減らすこと、顧客への提供価値を高めること、環境負荷を低減することは、必ずしも同じ方向へ進むとは限りません。
そのため、全体を見ることによって、価値判断の問題まで自動的に解決できるわけではありません。
どの目標を重視するかについては、意思決定や合意形成の問題が残ります。
システム思考は、その判断によってどのような影響が生じるかを考える手がかりになりますが、価値判断そのものを代替するものではありません。
AIによるシステム思考の支援
LLMなどのAIは、問題に関係する変数の抽出、影響関係の仮説生成、フィードバックの整理などを支援できます。
例えば、ある工場の問題について文章で状況を説明すると、AIが設備、工程条件、品質、保守、納期などの関係を整理し、因果ループ図の候補を提案することが考えられます。
また、既存の図に含まれる関係について、未確認の前提や、考慮されていない変数を指摘することも考えられます。
| 支援する活動 | AIによる処理の例 |
|---|---|
| 問題の整理 | 問題に関係する変数を抽出する |
| 関係の仮説生成 | 変数間の影響関係を提案する |
| 因果ループ図の作成 | 変数と矢印を構造化する |
| 時間の遅れの検討 | 結果が遅れて現れる関係を指摘する |
| ストックとフローの分類 | 蓄積量と流入・流出を区別する |
| システム境界の検討 | 重要な外部要因や分析範囲を提案する |
| 介入案の検討 | 異なる施策による影響を比較する |
| 検証課題の整理 | 確認が必要な因果関係やパラメータを抽出する |
ただし、LLMが生成した因果ループ図には、誤った関係や、存在しないフィードバックが含まれる可能性があります。
また、LLMは、文章としてもっともらしい因果関係を生成できても、その関係の強さや時間の遅れを正確に推定できるとは限りません。
数値シミュレーションを行う場合には、関係式、パラメータ、初期条件などを明確に設定する必要があります。
さらに、出力されたシミュレーション結果が、実際のデータや既知の振る舞いと整合しているかを確認する必要があります。
AIによるシステム思考の支援では、関係構造の候補生成と、その関係の検証を分けて考えることが重要です。
ThinkNaviでの位置づけ
ThinkNaviでは、システム思考を、問題の要素間に存在する相互作用と時間変化を理解するための基本的な考え方として位置づけます。
ロジックツリーやMECEによって問題を分解するだけでなく、分解された要素が互いにどのような影響を及ぼすかを考えることが重要です。
特に、因果ループ図は、システム思考を実践するための代表的なツールとして利用できます。
ThinkNavi Freeでは、変数を手入力し、その間の影響関係を矢印で結び、強化型・調整型のフィードバックや時間の遅れを整理するツールが考えられます。
また、ストックとフローを区別し、簡単な蓄積関係を記述する機能も考えられます。
LLM活用版では、文章から変数と影響関係の候補を抽出したり、因果ループ図を作成したり、考慮されていないフィードバックや時間の遅れを提案したりする機能が考えられます。
さらに、より専門的な機能として、ストック・フローモデルを作成し、簡単なシミュレーションを行う方向もあります。
ただし、システム思考のすべてを定量的なシミュレーションへ置き換える必要はありません。
問題を理解する初期段階では、変数と関係の整理だけで十分な場合もあります。
一方、具体的な対策の効果や時間変化を評価したい場合には、数理モデルや統計分析が必要になる可能性があります。
ConceptMiner R&Dなどの知識探索システムとの関係では、技術情報から抽出された因果・機能・制御関係を利用して、異なる技術システムの仕組みを比較することも考えられます。
ただし、GNGなどによる概念的な近傍関係と、システム思考で扱う因果関係は異なるものです。
また、因果ループ図と構造写像理論で扱う関係構造にも共通点はありますが、目的は異なります。
因果ループ図は、主に一つのシステム内部での相互作用や時間変化を理解するために利用されます。
構造写像は、異なる対象間の関係構造を対応づけ、類推や新しい推論へつなげるために利用されます。
両者を組み合わせれば、あるシステムの振る舞いを説明する仕組みを、別のシステムと比較する可能性も考えられます。
ただし、こうした高度な応用については、関係の抽出と正規化、成立条件の確認、計算負荷などの問題があります。
これらは今後の開発可能性を示すものであり、現在すべての機能が提供されていることを意味しません。
システム思考の本質は、問題を構成する要素を増やし、複雑な図を作成することではありません。
問題となっている振る舞いが、どのような相互作用によって生じているのかを理解し、望ましい変化を生み出すための介入点を考えることです。
システム思考は、個々の要素を見ることから、要素間の関係と時間変化を見ることへ視点を広げる方法です。ただし、関係を想像して図に描くだけでは、現実を理解したことにはなりません。観察、データ分析、実験、モデル化などと組み合わせ、仮説を検証しながら利用することが重要です。
関連ページ
- 因果ループ図|フィードバックを読み解く
- ロジカルシンキングとは ― 論理的に考え、筋道を説明し、相手の理解につなげる
- ロジックツリー・イシューツリーとは ― 問題を分解し、答えるべき問いを明らかにする
- 問題構造化とは ― 問題を分解し、関係を明らかにして解決への道筋をつくる
- 根本原因分析(RCA)― 問題が発生する仕組みを解明し、再発を防ぐ
- MECEとは ― 漏れと重複をなくす論理的思考と、その限界
- KPIツリーとは ― 目標指標を分解し、改善のレバーを見つける
- 概念マップとは ― 概念間の関係を表現し、知識の構造を理解する
- 構造写像理論|異なる対象の関係構造を対応づけ、新しい推論を生み出す
- アナロジー(類推)とは ― 異なる領域の知識を結びつけ、新しい発想と仮説を生み出す
- 実験計画法(DOE)― 複数の要因とその交互作用を調べるための実験設計
- 多変量解析 ― 多くの変数から関係や構造を発見する統計的分析
- 定性と定量 ― 世界を理解する二つの視点とその統合
- 批判的思考|主張と根拠を吟味する
- 科学的方法と反証可能性 ― 仮説を生み出し、批判的に検証する
- シナリオプランニング
- 概念調査
参考文献・関連資料
- Ludwig von Bertalanffy, General System Theory: Foundations, Development, Applications, George Braziller, 1968.
- Norbert Wiener, Cybernetics: Or Control and Communication in the Animal and the Machine, MIT Press, 1948.
- Jay W. Forrester, Industrial Dynamics, MIT Press, 1961.
- Peter M. Senge, The Fifth Discipline: The Art & Practice of the Learning Organization, Doubleday, 1990.
- John D. Sterman, Business Dynamics: Systems Thinking and Modeling for a Complex World, Irwin/McGraw-Hill, 2000.
- Donella H. Meadows, Thinking in Systems: A Primer, Chelsea Green Publishing, 2008.
- Donella H. Meadows, “Leverage Points: Places to Intervene in a System,” 1999
- MIT Sloan School of Management — System Dynamics
- MIT — System Dynamics and Jay Forrester
- The Systems Thinker — Guidelines for Drawing Causal Loop Diagrams
- The Systems Thinker — Anatomy of a Reinforcing Loop
- isee systems — Shifting the Burden
- C. W. Churchman, The Systems Approach, Delacorte Press, 1968.
- Peter Checkland, Systems Thinking, Systems Practice, Wiley, 1981.
- Dennis L. Meadows et al., The Limits to Growth, Universe Books, 1972.