プログラマの思索

プロジェクト管理や要件定義、システム企画をやっていると、どうしても因果ループ図のような考え方が欲しくなる。
自分の気づきをラフなメモ書き。

【参考】
因果ループ図（いんがるーぷず） - ITmedia エンタープライズ

システム原形とは？複数の切り口で根本原因を探る | akibito

システム原型を知れば、課題に予め対処することができる ? 変化から進化の物語へ/(株)Salt

因果ループ図の書き方　ルール編 ? 変化から進化の物語へ/(株)Salt

因果ループ図の書き方　実践編 ? 変化から進化の物語へ/(株)Salt

「引き寄せの法則」はシステム思考で説明できる ? 変化から進化の物語へ/(株)Salt

システム思考がアマゾンを世界一のECサイトにした ? 変化から進化の物語へ/(株)Salt

ルールを覚えても、因果ループ図がうまく書けない理由 ? 変化から進化の物語へ/(株)Salt

新しいビジネスモデルの作成（構築）方法 ? 変化から進化の物語へ/(株)Salt

System Dynamics 日本未来研究センター　Japan Futures Research Center

相殺フィードバックを再考: プログラマの思索

相殺フィードバック: プログラマの思索

【1】因果ループ図を使いたい場面はどこなのか？

ロジックツリーやWBS詳細化のように、既に確定した要件を分解していく時ではなく、輻輳した現状、混沌とした現状で使いたい。
問題の原因を掘り下げていく時に、単純ななぜなぜ分析では難しく、いくつかの要因が複雑に絡み合っている場面で使いたい。

プロジェクト管理で、進捗遅延が発生した問題、テスト工程でバグが噴出して品質が劣化している問題。
企画や要件定義で、利害関係者の要望が予算の上限枠に当てはまらない問題、要件定義やシステム企画が混乱している問題。
それらの背後には、数多くの因果関係が問題を複雑にしている。
単純な解決策では、応急処置に過ぎなかったり、逆に問題をさらに悪化させる場合もある。

【2】因果ループ図のメリットは何なのか？

問題の症状を定義して、その問題を増幅させる変数を複数個洗い出し、それを因果関係でつないで、一つのシステム構造として見てみたい。
そうすることで、問題の本質が見えてくる。

堂々巡りの議論ではなく、問題を一つの構造として洗い出したい。

【3】因果ループ図を書くコツは何か？

基本は、時系列グラフを収集して、変数を洗い出す。
時系列で見ると、何らかの目的変数が増大して、問題になっている。
顧客の不満、コスト、行動、利益、資源、など。

時系列グラフにはパターンがある
指数関数、S字型曲線、頭打ちの曲線、振動する曲線、振動しながら成長する曲線、成長するが最後に崩壊する曲線、など。
それらは因果ループ図が背景として構造を持つが、それを具現化したもの。

相関関係と因果関係は異なる。
因果関係→相関関係だが、相関関係→因果関係とは限らない。
統計学では当たり前の常識。

因果関係の間にある潜在変数は書き出す。
潜在変数があるということは、疑似相関があること。
因果の飛躍を避ける。

因果ループ図では、フィードバックという考え方が大事。
システム思考の構造が「システム」「情報」「制御」から成り立つ。
制御＝フィードバックになる。
システムダイナミクスの創始者がフィードバック制御の専門家だった。

フィードバックして因果ループ図になる。
たとえば、因→果が正の相関であっても、果→因は負の相関の時もある。
この場合、バランスループ、均衡ループになる。

各ループが自己強化型かバランス型かを判断することが大事。
変化を強めているのが自己強化ループ。
抑制しているのがバランスループ。

拡張フィードバック⇒自己強化ループになる。
拡張ループとも呼ぶ。
雪だるま（スノーボール）が転がる絵を描く方法を指導している。

相殺フィードバック⇒バランスループになる。
均衡ループとも呼ぶ。
天秤の絵を描くように推奨している。

以前、「相殺フィードバック」という言葉が何故か頭の片隅に残っていたが、意味を理解できていなかった。
たぶん、相殺フィードバックはバランスループを表す。

ループ構造に名前を付ける。
因果関係のループには意味がある。
フィードバックの特徴を表す名前を付ける。
読者の直感的理解を促進する。

ストックフロー図に置き換える。
微分方程式に置き換えられる。
専用ツールで、時系列グラフに変換できる。
因果ループ図は定性分析。
ストックフロー図は定量分析に相当する。

【4】自己強化ループ、バランスループの区別するコツは何か？

2つある。
一つは、どこか任意の変数を出発点として、ループに沿ってぐるっと一周して、最初の変数の変化を強めるのか、抑制するのかで判断する。

他方は、マイナスループの合計個数で、自己強化orバランスに分ける。
奇数ならバランスループ。
偶数なら自己強化ループ。

【5】因果ループ図を元に、どんな解決策を実行するのか？

絡み合った因果関係の中で効果的な作用点＝レバレッジポイントを発見するのが大事。
Amazonビジネスモデルの初期モデルは、顧客体験だった。
Kindleビジネスは、出版社だった。

割れ窓理論では「割れた窓ガラス」だった。
割れた窓ガラスを徹底的に無くすことで、最終的に犯罪件数が劇的に減った。

目的は成長させたい場合、
システム内の自己強化ループを強める施策を入れるなら、「ベゾスが考えたAmazonビジネスモデル」のように、別の自己強化ループを作る。

システム内のバランスループを弱める施策を入れるなら、「成功の限界」のように、制約を入れる。
「犯罪都市ニューヨークの割れ窓理論」のように、流量を抑える変数を入れる。

目的は現状維持なら、
システム内のバランスループを強める施策を入れるなら、制約や流量を抑える変数を入れる。
システム内の自己強化ループを弱める施策を入れるなら、別の自己強化ループを作る。

【6】感想

因果ループ図は使いこなすのが難しい。
因果関係となる変数を導くこと、それらを意味あるようにつなぐのが難しい。

一つのきっかけは、時系列グラフとセットで考えること。
そして、２つの変数のみでまずはループ構造を描いて、雪だるま式に自己強化ループを増やす。
あるいは、天秤のようにバランスループを書き出す。

ループ構造に名前を付けるのも重要。
この認識が以前はなかった。
売上増大ループ、顧客関係性強化のループ、とか。

因果関係と相関関係は違うのに、混同している時もある。
まずは書いてみては直す。

やりたいのは、問題となるシステム構造を描き出したい。
そうすれば、どこかの変数に制約を入れれば、流量が減るので、拡張ループは抑えられる。
成長させたい時は、別の拡張ループを増やるように、売上増加の別の戦略を打ち立てれば良い。

Amazonのベゾス、MSのビル・ゲイツも因果ループ図を使いこなしていた、と言う。
この考え方を実際に使ってみる。