【システム思考の基本】てこの原理を見つけるために必要な「システムを見る目」の養い方
はじめに：なぜプロジェクトの問題解決は難しいのか？
プロジェクトマネジメントの現場では、日々さまざまな問題に直面します。期日遅延、予算超過、リソース不足、コミュニケーション齟齬、品質問題など、挙げればきりがありません。これらの問題に対し、多くの場合、私たちは目の前の現象に直接対処しようとします。例えば、期日が遅れそうなら残業で対応したり、リソースが足りなければ他のプロジェクトから一時的に補充したりするといった対応です。
しかし、このような表面的な対処療法では、問題が根本的に解決されず、形を変えて再び発生したり、別の問題を引き起こしたりすることが少なくありません。それは、問題が単一の原因で起きているのではなく、複数の要素が複雑に絡み合った「システム」の一部として発生しているためです。
真に効果的な問題解決とは、この複雑なシステムの中で、わずかな力で大きな変化を生み出すことのできる介入点、すなわち「てこの原理」を見つけ出すことにあります。そして、「てこの原理」を見つけるためには、システム全体を構造的に理解するための特別な「見方」が必要になります。それが「システム思考」の基本的な考え方です。
システム思考やシステム分析に馴染みがない方にとって、「システムを見る目」とは具体的にどういうことなのか、どのようにすればそのような見方を習得できるのかは分かりにくいかもしれません。
この記事では、システム思考の基本概念を解説し、「てこの原理」を見つけるために不可欠な「システムを見る目」をどのように養っていくかについて、具体的な考え方のヒントをステップ形式でご紹介します。
システム思考とは：木ではなく森を見る視点
システム思考を一言で説明すると、「物事を単独の要素として捉えるのではなく、それらが相互にどのように影響し合い、全体としてどのような振る舞いをするのか」という視点で捉える考え方です。
伝統的な問題解決アプローチが、問題を構成要素に分解して個々の部分を詳しく分析する「要素還元主義（木を見る視点）」に傾倒しがちなのに対し、システム思考は要素間の関係性や全体としてのパターン、そして時間経過に伴う変化に焦点を当てる「全体論（森を見る視点）」に基づいています。
システム思考における「システム」とは、共通の目的を持って相互作用する複数の要素の集まりを指します。例えば、プロジェクトチームはメンバー（要素）、コミュニケーション方法や役割分担（関係性）、そしてプロジェクト成功（目的）から構成されるシステムと見なすことができます。
なぜ「システムを見る目」がてこの原理特定に必要なのか？
システム思考の視点がなぜてこの原理を見つけるために重要なのでしょうか。それは、てこの原理がシステム構造そのものへの介入点だからです。
- 問題はシステム構造から生まれる: 多くのプロジェクト問題は、個々の担当者の能力不足や一時的な不注意といった単純な原因ではなく、チームのコミュニケーション構造、意思決定プロセス、組織文化、外部環境との関係性など、システム全体の構造やパターンから繰り返し発生します。
- てこの原理は構造を変える: てこの原理となる介入点は、システム内の特定の要素を操作するのではなく、要素間の関係性やフィードバックループといったシステム構造に働きかけることで、システム全体の振る舞いを大きく変化させます。
- 「システムを見る目」が構造を明らかにする: システム思考による「システムを見る目」を養うことで、目の前の問題を引き起こしている根本的なシステム構造やパターンが見えるようになります。表面的な現象に惑わされず、真に効果のある構造的な介入点（てこの原理）を特定できるようになるのです。
「システムを見る目」を養うための基本的な考え方
では、具体的にどのようにして「システムを見る目」を養っていけば良いのでしょうか。ここでは、システム思考の入門者でも日々の思考に取り入れやすい、基本的な考え方のステップをご紹介します。
ステップ1：問題を「システム」として捉え直す
まず、目の前の問題や課題を、単なる個別の事象としてではなく、何らかの「システム」の一部として捉え直すことから始めます。
- 問題を取り巻く「要素」を洗い出す: その問題に関係している人、組織、プロセス、情報、ツール、外部要因などをリストアップしてみます。
- 要素間の「関係性」を考える: リストアップした要素同士がどのように繋がっているか、どのような影響を与え合っているかを考えます。「AがBに情報を渡す」「CがDの判断に影響を与える」「EとFが対立している」など、具体的な関係性を言語化してみます。
- システムの「目的」や「機能」を考える: そのシステムは全体として何を目指しているのか、どのような機能を果たしているのかを考えます。プロジェクトチームであれば「期日内に高品質な成果物を納品する」といった目的があるはずです。問題はその目的達成を阻害しているかもしれません。
この段階では、まだ詳しい分析は必要ありません。ただ、「この問題は、単なる私の目の前のタスクの問題ではなく、このような要素と関係性を持つシステムの中で起きている現象なのだ」という認識を持つことが重要です。
ステップ2：因果関係とフィードバックループを意識する
要素間の関係性を考え始めたら、次に「因果関係」と「フィードバックループ」を意識する練習をします。システム思考の根幹にあるのが、このフィードバックの概念です。
- 単線的な原因結果だけでなく、双方向の影響を考える: 「Aが原因でBが結果」という一方的な見方だけでなく、「Bが変化すると、それが再びAに影響を与える」という双方向の関係性（フィードバック）があるのではないかと考えます。
- 例えば、「テスト期間不足（A）がバグ増加（B）を引き起こす」だけでなく、「バグ増加（B）がテスト工数を圧迫し、さらにテスト期間不足を深刻化させる（A）」といった悪循環（負のフィードバックループ）があるかもしれません。
- あるいは、「開発者への権限委譲（A）がモラール向上（B）を促し、モラール向上（B）が開発速度をさらに向上させる（A）」といった好循環（正のフィードバックループ）の可能性もあります。
- 時間の遅れ（タイムラグ）を考慮する: 原因の結果が現れるまでに時間がかかる場合が多くあります。「今日行ったことが、数週間後、数ヶ月後にどんな影響として現れるか」という時間軸での変化を想像する訓練をします。
フィードバックループは、システムが安定したり、逆に問題が加速したりする動的な振る舞いを理解するために非常に重要です。具体的な因果ループ図の作成は次のステップで行うとしても、まずは思考の中で「これはどんなフィードバックになっているのだろう？」と考えてみることが、「システムを見る目」を養う第一歩です。
ステップ3：時間的なパターンと全体の振る舞いに注目する
問題が一時的なものなのか、それとも繰り返されるパターンなのか、そしてそのパターンが時間とともにどのように変化しているのかに注目します。
- データや観察からパターンを見つける: プロジェクトの進捗、バグ発生率、チームの生産性などが、どのように推移しているか、そこに特定の傾向やパターンはないかを探します。
- システムの「振る舞い」を考える: 個々の要素の動きではなく、システム全体として、例えば「プロジェクトの進捗が常に後半で遅延する」「新しいメンバーが入ると一時的に生産性が低下する」「特定の部署との連携で常にボトルネックが発生する」といった、全体的な振る舞いや傾向を把握します。
これらのパターンや振る舞いは、そのシステムがどのような構造を持っているのかを推測する重要な手がかりとなります。
ステップ4：自分の「視点」や「前提」に気づく
私たちは皆、これまでの経験や知識に基づいて、特定のフィルターを通して現実を見ています。システム思考では、自分がどのような視点からシステムを見ているのか、どのような前提やメンタルモデル（mental models）を持っているのかを自覚することも大切です。
- 「なぜ私はこのように考えるのだろう？」と自問する: ある問題に対して、自分が当たり前だと思っていることや、無意識のうちに置いている前提に気づくよう努めます。
- 異なる視点から考えてみる: 他のチームメンバー、顧客、上司など、異なる立場の人々が同じシステムや問題をどのように見ているかを想像してみます。
自分の視点や前提を意識することで、より広い視野でシステムを捉えることができるようになり、これまで見えなかったてこの原理候補が見つかることがあります。
プロジェクトマネジメントにおける「システムを見る目」の応用
これらの基本的な考え方は、プロジェクトマネジメントのあらゆる場面で応用できます。
例えば、「仕様変更が多発し、開発が遅延している」という問題があったとします。表面的な対処は「仕様変更を受け付けない」「納期を延ばす」かもしれません。しかし、「システムを見る目」で捉え直すと、以下のように考えることができます。
- システムとして捉える: この問題は、開発チーム、顧客、営業部門、仕様決定プロセス、変更管理ルール、コミュニケーション方法など、様々な要素が関わるシステムの中で起きている。
- 因果関係とフィードバック: 仕様変更の多発（A）が開発遅延（B）を引き起こし、その遅延を挽回しようとして拙速な開発が進み、それがさらにバグ増加（C）を招き、バグ対応のためにさらに開発が遅延する（B）。また、仕様変更の承認プロセスが曖昧（D）なために、軽微な変更も大規模な影響を及ぼし、これが仕様変更の多発（A）を助長しているかもしれない。
- パターンと振る舞い: プロジェクトの初期段階よりも終盤に仕様変更が増える傾向がある、特定の顧客からの変更が多い、変更要求が出されてから承認されるまでの時間が長いなど、何らかのパターンが見られるかもしれない。
- 視点と前提: 開発チームは「顧客は仕様を確定させない」と不満に思っているかもしれないが、顧客は「ビジネス環境の変化に迅速に対応したい」という切実なニーズを持っているのかもしれない。営業部門は「顧客の要望は何でも受け入れるべき」という前提で動いているかもしれない。
このようにシステムとして問題を捉えることで、単に仕様変更を禁止するのではなく、「仕様変更の承認プロセスを明確化・迅速化する」「影響度評価の仕組みを導入する」「顧客との定期的な要求レビュー会議を設ける」「アジャイル開発の手法を取り入れ、変更に強い開発体制を構築する」といった、システム構造に働きかけるてこの原理候補が見えてくる可能性があります。
まとめ：てこの原理特定への第一歩は「見方」から
この記事では、システム思考の基本的な考え方と、「てこの原理」を見つけるために必要な「システムを見る目」をどのように養うかについて解説しました。
プロジェクトにおける問題解決は、単に目の前の事象を解決するだけでなく、問題を生み出している根本的なシステム構造に働きかけることが重要です。そして、そのためにはシステム全体を構造的に理解する「システムを見る目」が不可欠です。
システムを見る目を養うことは、一朝一夕にできるものではありません。しかし、今回ご紹介した「問題をシステムとして捉え直す」「因果関係やフィードバックを意識する」「時間的なパターンと全体を見る」「自分の視点に気づく」といった基本的な考え方を日々の思考の中で意識することから始めることができます。
これらの考え方を実践することで、次に因果ループ図などのシステム分析ツールを学ぶ際に、より効果的に問題の本質に迫ることができるようになります。てこの原理特定に向けたあなたの第一歩は、まず「システムを見る目」を意識することから始まります。
次のステップでは、この「システムを見る目」を具体的に構造として描き出すためのツール、例えば因果ループ図の基本的な使い方などを解説していく予定です。
[次の記事のタイトル案：【実践】因果ループ図でプロジェクトの「見えない構造」を可視化する]