Tbpgr Blog

Employee Experience Engineer tbpgr(てぃーびー) のブログ

根性論の可視化で学ぶシステム思考

システム思考には広義と狭義の概念があり、ここで扱うのは狭義のものとします。

ピーター・センゲの「The Fifth Discipline(ISBN 0385517254、邦訳『最強組織の法則』(徳間書店))で、同書は因果ループによるシステム思考をコアにしながら、ビジネスの組織と人間の行動、学習する組織について論じている。同書を契機にこの因果ループ図を活用したシステムダイナミクスの定性モデリング手法は、「システム思考」として広く利用されるようになった

システム思考は我々が気づきにくいものごとの全体の関係性・因果関係から問題の構造を見抜き、その中で最も影響のあるレバレッジポイントを発見し、そこを変化させることで小さな変化で大きな影響を与えることに役立つ思考法です。

どんなときにつかうの?

  • 身の回りで、対策を講じていて短期的には解決するが、根本解決できないでいるような問題
  • 歴史的に根付いている問題
  • 組織で部分最適化が発生していて相互理解が必要なとき

「どんなときにつかうの?」という質問は「どこが嬉しいの?」という質問とつながるものですが、システム思考の考えに慣れていない場合は、そもそも現状がよりよくできる状態であることに気づいていないかもしれないので、知ることではじめて利用場面や利点を自覚できる、という面があるかもしれないと思いました。

ツール

システム思考には、下記のようなツールがあります

  • 氷山モデル
  • 因果ループ図(Causal Loop Diagram)
  • システム原型(Systems Archetype

氷山モデル

システム思考ではある「できごと」だけが表面から見えている氷山の一角に例えた氷山モデルによる説明がよく行われます。

  1. できごと
  2. パターン
  3. 構造
  4. マインドセット

例えば、あるシステム開発会社で人が辞めるという できごと があった。
そこで、進捗を回復させるために残ったメンバーの稼働時間を伸ばした。
すると、また人がやめていった。これは パターン のようだ。
気にせずさらに減った人員分残った人の稼働を増やしたらさらに人がやめていった。
構造 として、「人が減ってもその原因を追求し、問題を解決せずに稼働時間の増加で補う」という状態になっています。
これが、パターンとして人がやめていくサイクルを生み出しているようです。

この 構造 を作り出している原因は人員減に対する対応の有無を決めている責任者の マインドセット でしょう。
おそらく

人が減っても稼働時間を増やせるうちは増やせば成果物を補える。そうすれば新規の採用コストを節約できる

という根性論で考えているのでしょう。

このパターン、構造、マインドセットを気にしていない人からは「なんかどんどん人がやめてるな」という部分しか見えていません。
このケースはわりとわかりやすい問題なので実際は察しがつく人が多いかもしれませんが、このように氷山の見えない部分にはパターン・構造・マインドセットが隠れているのです。

因果ループ図(Causal Loop Diagram = CLD)

因果ループ図は、システム内の変数がどのように影響を与えあっているかを可視化する因果図です。
図は、ノードとそれを結ぶエッジからなる。ノードは変数を表し、エッジは関連するノードを結び、その関係性に併せて + (もしくは S) or - (もしくは O) を記載します。S は Same 、 O は Opposite です。

自己強化型ループ (Reinforcing loop)

自己強化型ループは、フィードバックをもとにシステムがどんどん強化(弱化)されていくようなループです。
例えば、売れれば売れるほど口コミで更に売れる製品について考えてみます。
※実際には顧客数の限界がありますが、ここでは考慮しないものとします

f:id:tbpg:20190307181819p:plain

バランス型ループ (Balancing loop)

バランス型ループは、正負の関係性の共存により収束に向かうようなループです。
例えば、ダイエットをしているけど、体重が多いほど必死にダイエットをする。
減ってくるとサボりだす。ということを考えてみます。

f:id:tbpg:20190307181829p:plain

例 - 残業根性論の例

先程氷山モデルで説明した残業の例を因果ループ図にします。

f:id:tbpg:20190307181839p:plain

ここでは、社員が減ったら稼働時間を増加させていることが悪循環の原因になっています。
そこで、この意思決定を変更して、社員が減ったら減った分採用して増員するようにしてみます。

f:id:tbpg:20190307181849p:plain

稼働時間の変動がなくなり、それによる退職の悪循環がなくなりました。
※実際は人が採用のコストや、オンボーディングのコストなどありますが、ここでは問題の単純化のため考えていません

システム原型(Systems Archetype

システムによく現れるパターンはシステム原型としてまとめられています。
プログラミングの世界で言えば、よくある設計手法がデザインパターンとしてまとめられているようなものです。

例えば、顧客数のような上限のある構造を表した「成長の限界(Limits to growth)」などがあります。

システム原型を知っておくことによって、これに一致するパターンの問題を発見しやすくなります。

まとめ

システム思考によって物事を全体思考、時間軸も含めて見ることで真因が浮かび上がりやすくなります。
特に、多人数のミーティングで複雑な問題を取り扱う場合に、言葉だけでやりとりしていても中々うまくいきません。
問題を共有して費用対効果が高く根本解決ができる真因を発見するためにも、チーム全員がシステム思考を理解した状態にするのは、有益ではないかと予想しています。実際、そういった状態のチームは少なそうなので、もしあれば「システム思考を導入する前後の差異」について聞いてみたいものです。

例えば、よくありがちな「とりあえず新たなプロジェクトを立ち上げるが、リーダーは既存のメンバーに兼任してもらって、既存業務は生産性を上げてもらえば万事解決だよね」というような根性論にもとづく意思決定も、こういった図にすると問題が可視化されます。

関連情報