システムシンキング（５）

「システムにおける問題を発見するガイドラインは５つある」 - Systems Thinking Basic (2001年)

1. 問題は繰り返し発生するものである


2. その問題は発生してから非常に長い時間が経過しているものである


3. これまでに実施した解決策が全く効果がなかったか、あるいは途中で中止されたものである


4. 問題の時系列的な動きのパターンについての、明確な理由を特定できていないものである


5. 問題の時系列動きが、あるいくつかの特定のパターンに類似して行われているものである

問題をどう位置づけるか、そもそもそれは取るに足らない、とかそれは深刻な、というとらえ方はかなりの部分で主観的である。上に掲げられたものが確実に正しいといえるわけでもなく、また掲げられている定義そのものもかなり広義に解釈できるといえばそれまでだが、しかしそれでも、問題、を問題とみなしそれを発見するには、それなりの尺度は必要であって、このレベルは確かに「程よい」と言えるだろう。

とくに4番目と5番目、これは興味深い。時系列的な動きとは…　これはまた次回に。

システムシンキング（４）

「システムの構造を明らかにするには、①問題を定義する、②重要な変数を特定する、③時系列で変数の動きをグラフ化することが必要である」- System Thinking Basic (2001年)

そもそも「システム思考」を始める前に、システムとは何か、を規定する必要があった。
それは、「お互いに関係し合う、複数の構成要素の集まりである」。

つまり、システムとは、複雑なものであり、その構造を明らかにするには、手順を追った分析を必要とする、ということで、だから冒頭に述べたような３つのプロセスが必要になるということだ。

システムとは複雑なものだ、というのは至極当たり前のように聞こえるが、それをどう解析すればいいのか、はそう簡単ではない。ITの世界におけるシステムの解析もまた然り。そもそも①問題の定義の時点から本質とずれてしまうことが多々ある。この「問題」をどう発見すればいいのか、それは問題とはどんなものか、を理解するところから始まるが、システムシンキングでは…

本日はここまで。

システムシンキング（３）

「システム思考は、①全体像をとらえる、②長期と短期のバランスをとる、③動き・複雑性・相互依存性というシステムの３つの性格を理解する、④測定可能なデータと不可能なデータ双方を考慮に入れる、⑤自分自身がそのシステムの一部であり、システムと自分は相互に影響を受け、与え合っていることを理解する、という原則から成り立っている」 - System Thinking Basic (2001年)

さらっと読むと、どれも、当たり前のこと、のように思える。
が、これを常に意識して日頃の仕事、生活の中で思考ができているかというと、そうではない。
これをすべて意識して行動しようと思ったらおそらく考える時間が行動する時間の数倍にも及んでしまうだろう。

鍵は、自分がいるシステムのポジションとその関係性をまず把握すること、に思える。あとは、ダーっと走り出さずに、立ち止まって大きな視野で対象を見つめてみること。

そう考えてみると、本格的に思考を始める前に、まずはメンタル的なものを改善する必要もありそうだ。

システムシンキング（2）

「システム思考は解題解決のための分析ツールを提供するだけでなく、物事の全体像をとらえるための思考の仕組みを提供してくれる。あるいは人の生き方を変えることになるかもしれない」 - System Thinking Basic（2001年）

線型的に因果関係を導くのではなく、まわりまわって元に戻ってくる循環的な関係、相互依存的関係を導くのがシステム思考、ということらしい。線型的な因果関係…これは演繹・帰納などの違いはあれど、論理思考におけるロジックツリーを指しているように見える。

線型思考＋循環思考＝「木を見て森も見る」ということだろうか。大きく思考の回路が違う両方を理解し、使いこなせると、確かに生き方までも変えるかもしれない。

システムシンキング（1）

「論理的思考とシステム思考をあわせて行うことで『木を見て森も見る』ことを実現すると考えて欲しい。（中略）論理的思考は体系だった論理的な手法に基づき、「考え方」を整理し・構成し・分析していくことであり、システム思考は「物事」を整理し全体像として捉えて、さらに物事の構造や動きを把握し、その理解をグループで共有することである」 - System Thinking Basic（2001年）

論理思考とシステム思考は違う、ということからまず論理的に理解できないと、おそらくシステム思考を正しく理解することはできないようだ。難解。地道に身に付けていくことにしよう。

ステークホルダ分析

「ステークホルダ分析は、何が最も頻繁に議論を要するプロセスになるかについて、、ある程度明らかにしたり、制御したりするために役立つ」 - "THE ADVENTURES OF AN IT LEADER"（2009）

なにか一つのプロジェクトを始めるとき、一番重視することは何か？と問われると、個人的には、「キーパーソンをどう巻き込むか？」と考えている。参画する自分の立場によって対象者は異なっても、その人と良好なコミュニケーションを保たなければ、たとえ自分に周囲を圧倒する知力、体力があってもミッションの成功は覚束ない。一度その対象者を見つけてしまえばそれは地道な努力でなんとかなるものだが、難しいのは、「それが誰なのかを特定すること」。

そのキーパーソンたる人たちは、プロジェクトのどまん中にいるとも限らないし、最初からいる（把握できる）とも限らない。

どこにどんなステークホルダが居て、その人が、味方なのか、抵抗者なのかを見極めることは非常に重要で、それがもし一番最初に出来たなら、物事を自分が思っている方向にスムーズに進めていくための大きな源泉になる…が、いままでそれをプロジェクトという仕事場の中でクリアに出来た試しがない。

また、そんなことを考えければいけない季節がやってきた。今度はうまくやれるだろうか？