はじめに
UL Systems Advent Calendar 2018 の20日目です。
皆さん、システム思考をご存知でしょうか？
システム思考は、出来事の裏にある因果関係=システムを捉えて課題解決を図る思考法です。
近年、リーダーやマネジャー、経営者、人事や人材開発の担当から注目されていますが、活用場面は経営や組織運営の課題にとどまりません。ビジネス現場の日常的な問題や生産性向上、更にはプライベートの課題にも使える汎用性の高いツールなのです。
実際、筆者の家庭（以下、M家と呼びます）では、夫婦の家事分担の問題をシステム思考によって穏便に解決しました。
M家の家事分担問題の例
あるところに、夫婦ともにフルタイムで働いている家庭がありました。
お互いフルタイムで働いているため、家事は分担すると決めていました。しかし夫が全く家事をしないのです。
最終的に妻は、我慢できなくなって夫の分も代わりに家事をしていたため、日々不満を感じていました。ある日妻が『夫が家事をしない原因』を分析したところ・・・
夫にも家事をする意識はありますが、どのタイミングで家事をするか（部屋の散らかり度合いなど）の基準の違いが主原因であると突き止めました。そして、妻が夫の分も家事をしてしまうことが『夫が家事をしない』状況を生み出しているのだと気づきました。妻は「家事をするタイミングの基準自体に良し悪しはないので、何らかの『仕組み』で夫の家事への意識を変えられないだろうか・・・」と考えました。
そこで、まず日常生活で発生する家事のリストを洗い出し、作業量ポイント（その家事を1回実施する負荷を数値化したもの）を夫と一緒に設定しました。そして、簡略化したかんばんを壁に貼り、各々がその日にやるべき担当家事を貼り出したのです。また、担当家事を実施したら作業量ポイントを獲得できるルールを作り、各々のレーンに累積消化ポイントを書きました。
さて、以前と同じように妻が家事をすると、夫との累積消化ポイントに差が出てきます。
すると累積消化ポイントの差に気づいた夫は、その差を埋めようと積極的に家事をし始めました。
結果的に、妻の家事負担が増えると夫の家事への意識が高まるシステムを作り出せたわけです。かんばんの運用は1ヶ月ほどで自然消滅しましたが、夫の家事への意識が変わり、家事の負荷バランスが維持されるようになりましたとさ。
めでたしめでたし。
このエピソードに隠れているシステム構造は、下のように図式化できます。この図は因果ループ図と呼ばれるシステム思考の主要ツールです。（ツールの説明は後々出てきます。）
※あくまでM家でうまくいった例であり、他のご家庭での効用は保証いたしませんのでご注意ください。
システム思考に興味が湧いてきましたか？
詳細な説明を始める前に、そのメリットを挙げておきます。
システム思考を使うメリット
- 問題の因果関係を整理・可視化・抽象化できる。問題を「正しく」捉えることができれば、8割は解決したと言える！
- システム構造に問題があると捉えるため、建設的な解決策を立案しやすい。ある特定の失敗や精神論から視点をずらせる
- システム構造を可視化するため、変化を生むポイントを発見しやすい。適切な箇所にアクションを起こせば、小さな労力で大きな効果を生み出せる
それではシステム思考の概要と具体的な考え方を見ていきましょう。
システム思考とは
システム思考とは、複雑な社会システムの課題解決のため、そのシステムの構造や諸関係を把握し「システムを制御して」課題解決を図る考え方で、事象の要素細部を見るのではなく、全体のシステムを構成する要素間のつながりと相互作用に注目し、その上で全体の振る舞いに洞察を与えます。
簡単に言うと、問題の表面を見て近視眼的に対応するのではなく、根本的な原因にアプローチして問題の根絶を目指す考え方です。
システム思考のエッセンス
システム思考を実践する際、様々なフレームワークを使用します。今回は特に重要な3つのフレームワークをご紹介します。
- 氷山モデル
- 因果ループ
- システム原型
1. 氷山モデル
氷山モデルとは、物事の全体像を4つの階層に見立て、根本的な原因を探るフレームワークです。
上から順に、表面にあって注目されやすいできごと、繰り返し起こっているできごとに見られるパターン、パターンを生み出している構造、そしてその構造の根底にあるメンタルモデルに分けて考えます。
M家の家事分担問題を例にすると、
- できごと: 妻の家事の負担が大きい
- パターン: 夫に家事を任せても、妻がしびれを切らして先にやってしまう
- 構造: 妻が先に家事をしてしまうので、夫の家事への意識が下がる
- メンタルモデル: どれくらい家の維持管理度が下がったら家事をするかの価値観が異なる
のような具合です。
2. 因果ループ図
因果ループとは、システムダイナミクス理論に基づいて、世の中で起きている物事の原因となっているシステムを解明するために描くモデルです。
なんだか堅苦しい説明ですが、要は「事象」を因果関係の「矢印」で結んで「システムの構造」を表現する図です。
因果ループ図の構成要素
- 変数とリンク
- 変数間の関係
- フィードバックループの種類
- 遅れ
1. 変数とリンク
因果ループ図は、状態や行動などの事象を表す変数とそれらを原因と結果の関係で結ぶリンクで構成されます。
また、変数とリンクによって作られる閉じた円をフィードバックループと呼びます。
2. 変数間の関係
変数を結ぶリンクには2種類あり、原因が結果にどのような影響を与えているかを表します。
図中ではリンクの横にSまたはOと表記します。
-
Same (S) の関係
- 原因が増えれば（減れば）結果も増える（減る）関係
-
Oppisite (O) の関係
- 原因が増えれば（減れば）結果は減る（増える）関係
3. フィードバックループの種類
フィードバックループは、その振る舞い方から2種類に分類できます。
図中ではループの中にRまたはBと表記します。
-
拡張ループ: Reinforce Loop (R)
- ある変数の変化がさらに大きな変化を生むループ。システムに発生した変化を加速させる力がはたらく
-
バランスループ: Balance Loop (B)
- ある変数に変化が起こっても、回り回ってその変化が抑制されるループ。システム自身が目指す「状態」へと収束させる力がはたらく
4. 遅れ
遅れとは、原因の事象が発生してから、結果の事象に影響が現れるまでのタイムラグを表します。多くの場合、遅れはシステム上の重要な役目を果たしているため要注意です。
図中では、遅れを持つリンクに 「||（平行線）」または「遅れ」と表記します。
※注意※
記法は必ずしも共通ではありません。RやBではなく「拡張」「バランス」と書かれたり、記号で描かれたりするケースもあるようです。そのため、記法そのものではなく、意味で理解してもらうのが良いかと思います。
因果ループ図の特徴
その名のとおり、「シーケンス」ではなく必ず「ループ」構造を成します。また、ループは1つとは限りません。多くの場合、複数の拡張ループとバランスループが組み合わさってシステムを構成しています。
すべてのシステムは2種類のフィードバックループの組み合わせでしかないため、因果ループ図さえ描くことができれば、システムが局所的にどのように振る舞い、大局的にどのような状態に向かうのかをシンプルに理解できます。
ちなみに工学的に考えると、「できごと」は、システムが自身の目標（変化を加速させる、またはある状態に収束させる）に向けて絶えず自分の位置を修正し続ける「フィードバック制御」の働きの結果であると捉えることができます。
3. システム原型
システム原型とは、様々な分野で共通して発生する典型的なシステム構造です。
一見特殊な構造に見える問題も、多くの場合、定型的なシステム構造の組み合わせで表現できます。システム原型を使って問題を読み解けば、「隠れたシステム構造」をより簡単に把握できます。
システム原型には以下の8つがあります。
- 漂流する目標(Drifting Goals)
- 問題のすり替え(Shifting the Burden)
- 成功の限界(Limits to Success)
- 成功には成功を(Success to Successful)
- 応急処置の失敗(Fix That Fail)
- 共有地の悲劇(Tragedy of the Commons)
- 成長と投資不足(Growth and Underinvestment)
- エスカレート(Escalation)
すべてのシステム原型を説明すると、この記事が超大作になってしまうので割愛しますが、後の話で登場する「漂流する目標」と「応急処置の失敗」の2つのモデルを紹介します。
例1. 漂流する目標
「漂流する目標」モデルでは、目標と現状のギャップは以下の2種類の方法で解決されます。
- 目標達成のための行動を取る
- 目標を下げる
このシステム原型では、目標と現実の間にギャップがあるときは、多くの場合、そのギャップを少なくするために目標が引き下げられると考えます。そのため、時間が経つにつれて目標が低下し、状況は次第に悪化していきます。
例2. 応急処置の失敗
「応急処置の失敗」モデルでは、短期的な解決策が意図せざる結果を引き起こし、それがさらに問題を悪化させる可能性を示唆します。
このシステム原型では、応急処置によって短期的には問題の症状が改善しますが、時間が経つにつれ元の状態に戻るか、あるいは症状はさらに悪化していきます。
システム思考の手順
さて、基礎知識を得たので、実際に使ってみたくなってきましたね。
実は、多くのシステム思考初学者は、因果ループ図がなかなか上手く描けずに苦戦します。それは、因果ループ図を書くために必要な手順を踏んでいないためです。では、どのような手順で実践すればよいのでしょうか？
1. 問題に関する過去から現在、そして未来に至る「ストーリー」を考えてみる
問題を定義するために、その問題がどのようなストーリーを辿ってきたのかを考えます。また、未来ではどんなストーリーが続くのかを想像してみます。この段階で、問題に関する情報を洗い出しておきましょう。
2. 「ストーリー」の中から「パターン」を見つける
ストーリーの中で繰り返し発生している「出来事」を認識し、そこに一定の「パターン」が存在しないかを考えてみます。
3. 「パターン」をうまく表現できる「グラフ」を描いてみる
パターンをうまく説明できる「変数」を定義し、その「変数」が時系列でどのように変化しているのかを「グラフ」で表現します。因果ループ図の前に時系列グラフを描くと、システムに影響を与えている要素をより簡単に抽出できます。
4. 「グラフ」の変数の増減を支配している「システム」を考察する
ここでようやく「因果ループ図」を描く段階です。グラフから変数を抽出し、原因と結果の関係（リンク）で結びます。「変数間の関係」「フィードバックループの種類」「遅れ」を付与できたら、システムがどのような振る舞いをするか考察しましょう。
ここまでが問題を整理して深く理解するための手順です。問題解決に取り組むには、以下の手順に進みます。
5. システムの構造に変化を与えるポイントを見つける
因果ループの流れを変えたり、システムの構造自体を変えたりできるポイントを見つけます。理想のシステム構造を描いてみるのも良いでしょう。
6. アクションプランを考える
システム構造に変化を生むための具体的なアクションを決めます。因果ループ図には表れないケースもありますが、重要なポイントです。M家の家事分担問題でいうところの「かんばんの導入」や「家事消化ポイントの見える化」に相当します。
7. 結果を観察する
行動の結果がシステムがどのように変化したかをチェックします。実行した行動が、必ずしも期待した変化に繋がるとは限りません。意図した変化が得られなかった場合は、再度システムを考察し、アクションプランを練り直します。
ウォーターフォール開発とアジャイル開発の違いをシステム思考で解釈する
それではエンジニアの皆さんに馴染みのあるウォーターフォール開発とアジャイル開発を題材にして、具体的な例を見てみましょう。
ここでは、プロジェクトで発生する「遅延」を起点に、それぞれの開発手法がどのようなシステム構造を持つのかを解釈してみます。※問題をわかりやすくするため、極端な例で考えています。
1. ウォーターフォール開発のケース
ある開発プロジェクトの後半、テストフェーズに入る段階でスケジュールに大幅な遅延が発生していました。プロジェクト責任者は、現状のメンバーだけでは納期に間に合わないと判断し、追加要員を投入しました。メンバーの増加によりテスト消化が進み、スケジュールの遅れは徐々に減っていきました。しかし時間が経つにつれて、プロジェクトの主要メンバーが体調を崩し始めました。彼らの作業負荷を確認してみると、新規メンバーの教育やサポート、メンバーへの情報伝達に多くの時間を取られ、高い負荷が続いていたことがわかりました。更にユーザーテストの段階に入ると、不具合の報告が多発してしまいます。原因は、仕様を深く理解できていない新規メンバーのテスト漏れでした。早急に対応すべく、仕様を理解している古参の主要メンバーに修正タスクが降ってきます・・・
遅延しているプロジェクトに人員追加によって更に遅れが生じる「ブルックスの法則」の典型的なパターンですね。
このストーリーの裏に隠れているシステムを因果ループ図で描いてみます。
このシステムは、プロジェクトの遅延を回復するために人員追加すると、かえって遅延を増幅させてしまう構造になっており、システム原型の一つ応急処置の失敗モデルに該当します。
ただし、この構造だけではウォーターフォールの特徴が表れていない気がします。ウォーターフォールは大きな遅れが生じやすい開発手法ですが、その原因は何でしょうか？ウォーターフォール開発のシステムに影響を与えている別の変数を考えてみましょう。
導入した新しい変数は、次のレビューまでの作業期間、レビュー対象の量、指摘事項の3つです。
遅延が発生すると、次のレビューまでの期間が延びてしまい、作業期間が延びるとレビュー対象のドキュメントや機能の量も増えます。そしてレビュー対象の量が多いとレビュー自体に時間がかかり、数週間後に大量の指摘事項が一気に開発チームへ返ってきます。こうなったら十中八九、更に遅延しますよね。
なるほど、恐ろしや。
2. アジャイル開発のケース
ある開発プロジェクトでイテレーション中に遅延が発生しました。プロジェクトリーダーは、今回のイテレーションでは目標の機能すべてを開発しきれないと判断し、プロジェクトオーナーと調整して開発対象の機能を削りました。作業量調整の結果、優先度の高い機能は予定通りリリースできました。そのイテレーションの振り返りでは、遅延が発生した原因をチームで話し合い、次のイテレーションで取り組む改善策が立案されました。改善策が功を奏し、前のイテレーションで遅れた分を次のイテレーションで挽回できました・・・
このストーリーの裏に隠れているシステムも、因果ループ図で描いてみましょう。
上のストーリーでは、遅延を挽回できてめでたしめでたし、となっていますが、描いた因果ループ図をシステム原型と照らし合わせると、漂流する目標モデルに該当します。このシステム構造には目標を押し下げる拡張ループがあるため、安易に目標を下げる（リリース機能を削る）と、どんどん当初の目標（開発規模）から遠ざかってしまうリスクがあると解釈できます。
しかし、皆さんご存知のようにアジャイルは「なし崩し」に目標を下げる開発手法ではありませんよね。どうやら、上の因果ループ図ではアジャイル開発の特徴を表現しきれていないようです。どのような変数やリンクを見落としているのでしょうか。
導入した新しい変数は、アウトプットの質、レビューの質、仕様FIXの速さの3つです。
遅延が発生しても作業量を調整したり、生産性を上げると負荷が下がります。負荷が下がるとアウトプットの質が高くなり、それによって質の高いレビューを得られます。レビューの質が高ければ仕様スムーズに固まり、プロジェクトが順調に進んでいきます。
ここで注意しておきたいのは、アウトプットとレビューの頻度です。アウトプットの質が下がり、レビューの質も下がる悪循環が発生する可能性もありますが、アジャイルではイテレーション毎にレビューがあるため、発生する遅延は小さく抑えられます。また、因果ループの中に「遅れ」がない点もウォーターフォールと異なります。
以上の因果ループ図から、2つの開発手法はレビュープロセスの違いが肝であると筆者は考察しました。
今回題材にしたウォーターフォールとアジャイルの例は、システム開発をよくご存知の方にとって「当たり前」を図にしているだけかもしれません。しかし、漠然とした「当たり前」を整理・可視化し、システム構造の肝を自分なりに解釈しておくだけでも恩恵はあると思います。
システム思考に対する理解
最後に、システム思考を体系的に学んだ上で感じた、個人的な見解を述べます。
難しさ
- システム構造の理解に普遍的な「正解」はない。メンタルモデルや個人の持つ情報量によって一人ひとり理解は異なる
- システム構造は不変ではない。自分が意図的に行動を起こさなくても、世の中の様々な要素の影響によって変化していくものである
重要だと思ったポイント
- あくまで思考整理のツールであって、問題の解決策を「自動的に」導き出してくれるものではない
- 問題を複雑に捉えすぎない方が良い。変数は出そうと思えば無限に出せてしまうので、重要な要素のみを抽出して理解しやすいシステムを描くのが良い
- 考えただけではシステムは変わらない。行動を起こし、システムの変化をチェックするプロセスが大事
- システムを変えるには時間が掛かる。行動がすぐ結果に繋がるとは限らない
- 実行不可能な美しいアクションプランより、遠回りでも実行可能な泥臭いアクションプランの方が価値がある
- 自分のちからでは変えられないシステムに対して絶望しない。大きい問題をいきなり変えようとするから絶望するのであって、身近なところから変化を生み出してみよう
おわりに
システム思考についてざっくりとまとめてみましたが、いかがだったでしょうか。
興味を持った方はぜひ実践してみてください！