「システム思考の世界へ」読書メモ

書籍リンク: システム思考の世界へ（オライリー・ジャパン）

Diana Montalion 著、宮澤明日香、中西健人、和智右桂 訳。
原題は Learning Systems Thinking。
ソフトウェア技術者が、コード単体ではなく人や組織を含むシステムのなかで考え続けるための本として読んだ。

以下は、読みながら書き残したメモを整理したもの。
書籍の本文からの引用は、引用記号付きで示す。

モデリングは問いを立てる過程

モデリングは成果物そのものより、問いを立てる過程として効く。
その過程で概念の統合が促されるので、重要だと感じた。

採用の場面にも同じ見方を当てはめられる。
システムの課題を解決するために、他者とどれだけ協力して思考を深めていけるか、が問われている。

氷山モデル

氷山モデルは、システムで繰り返し発生する問題から考える枠組みとして読んだ。
目に見える出来事の下に、パターン、構造、メンタルモデルがある、という見取り図。

本番環境でのバグという事象を一つとっても、その背後にあるパターンは組織ごとに異なる。
そして組織の行動は、事象そのものではなくパターンによって規定される。

パターンを探す場所として、次が挙がっていた。

• 時間
• 文脈
• ほかの構成要素との関係
• バグが生じた構造

責任追及の自己強化型パターンを持つ組織では、いずれ人々は専門性を身につける前に離職してしまうだろう、という指摘も刺さった。
組織が表面的な事象ではなく、根本的なメンタルモデルをメタ認知し、フィードバックループのレベルで改善しなければ、同じことが繰り返される。

パターン思考のための7つの質問もメモしておく。

情報の流れ、出来事、境界、構成要素、デリバリープロセス、人々の組織化、意思疎通の構造。
ソフトウェアシステムのパターンを見定めようとするとき、これらの観点で探求し、モデル化し、検討する。

ストックとフロー

「どれだけ知っているか（ストック）」ではなく「どれだけ学べるか（フロー）」を見る、という対比が印象に残った。

知識ストックは蓄積した知識の貯蔵であり、効率性を高める。
知識フローは人や技術のあいだで知識を移転し、システムを動かす能力であり、効果性を高める。
技術文化ではストックが重視されがちだが、フローが優れているほど知恵を発見しやすい。

ストックを増やす活動の例は、コードを書くこと。
フローを増やす活動の例は、ドキュメントを書くこと、フィードバックを得ること、ペアプロ。

情報はレシピ、知識はコック、知恵はシェフ、という比喩もあった。
学びとは、知識のシェフになること、と読んだ。

どの考えを優先するか

どの考えを優先するかを見極めることが、シグナルとノイズを区別することにつながる。

定期的にモデリングを行うグループは、優先順位が競合する場面でも、協力して見極めるのが上手い。

自分の思考をメタ認知する

重要な MTG や集中した作業のあとに、10分ほどジャーナルを書いてみる。
自分の思考をメタ認知するための習慣としてメモした。

リーダーシップとは、自己認識をすることでもある。
感情的な反応をメタ認知し、それをそのまま発露するのではなく、意識的な応答へと昇華できること。

HALT な状態のときは、できるだけ小さな行動にとどめる、という実践も書いてあった。

5章では、感情的な反応から意識的な応答へ移る話として、雨の中で待ち合わせに遅れたときの物語が出てくる。
「物語が同じである必要はない」というマントラが印象に残ったので、5.7節をそのまま引用する。

5.7 実践のために：物語が同じである必要はない

私がこれから語るのは、現実の生活で反応がどれほど複雑で交差しているかを示す物語である。モットーは「無視せず、かといって自分の問題として抱え込みすぎないこと」だ。

私は街角に立ち、夫が約束の時間に迎えに来るのを待っている。春の冷たい雨が降り注ぎ、傘はない。薄手のジャケットが約束の時間を過ぎるにつれてずぶ濡れになっていく。

通り過ぎるどの車も私たちの車ではないことに苛立つ。私は何度も夫に電話やメッセージを送った。「どこにいるの？」「会議に遅れちゃう」「パソコンが壊れるかも」

「お昼が冷めちゃう」……最悪だ。寒さが体に染みるにつれ、苛立ちはどんどん募っていく。

やがて、恐怖が怒りを上回る。彼からの返事はない。一体何が起きているの？もしかして事故？いや、まさか死んだの？

14分後、夫が車で到着する。車を見ると恐怖は消え去る。よかった、彼は無事だ。だが今度は再び怒りが湧き上がり、ドアを開けながら怒りの言葉が口をついて出てくる。

以前の私たちの関係では、反応の連鎖が始まっていただろう。彼は私の怒りに反応する。彼の視点ではそれは不公平だとか理不尽だと感じるからだ。彼が私の反応にさらに反応し、私がその反応にまた反応し……、その日の午後はずっと負のスパイラルだ。

でも今日は、彼がこう言ってくれた「なんてこった、こんなに濡れちゃって……。本当にごめん。最悪だったよね」。私の不満に耳を傾け、後部座席をかき回して髪を拭くためのタオルを見つけてくれる。「まだ会議、間に合いそう？本当にひどい目にあったね。すごく不安だったよね」

私がようやく一息ついたところで、彼は自分の話を始めた。

彼は予定通り、私を迎えに来る途中で食料品店に立ち寄った。店に着いて、スマホの買い物リストを確認しようとポケットに手を入れたが……。スマホがない。その日は3軒の店を回っていたので、戻って探さなければならない。でもまずは急いで買い物を済ませて、私を拾い、それからスマホを探しに行こうと決めた。

12分後、買い物を終えた彼は、ちょうど私を迎えに来れる時間に車に駆け戻る。ところが、別の車が私たちの車の後ろに停まっていて動けない。運転席のドアは開いているが、運転手はいない。

夫は駐車場を歩き回り、その迷惑な運転手を探す。「おーい！」と叫ぶが誰もいない。彼は店に戻り、カスタマーサービスデスクの列に苛立ちながら並ぶ。彼の前にはリンゴを返品している人がいる。リンゴの人が去ると、係員に運転手を呼び出すよう頼む。

「ああ！」と彼女は言う。「その方、胸の痛みを訴えてふらふらと店に入ってきたんです。救急車を呼んでほしいって。今、救急隊が向かっているところです。もし車に鍵が残っていれば、こちらでどなたかに動かしてもらいますね」

外に出ると、向かいの駐車スペースにあった車はすでにいなくなっていた。夫はそこから車を前進させ、安全運転を心がけながらも、雨の中で立ち尽くしている私のことを思って急いだ。

以前の私なら、自分の怒りや苛立ち、混乱が的外れだったと気づくと、そんな感情を抱いたこと自体に罪悪感を覚えて、それを押し殺してしまっていただろう。雨の中でお弁当がびしょ濡れになって、夫とも連絡が取れない――それでも私は、もっと落ち着いていられるべきだったのでは？会議なんかより、胸の痛みを訴えていた方を心配すべきだったんじゃないの？

私たちの関係性を変えたのは、たった一つの小さなマントラだった。「物語が同じである必要はない」

私たちが学んだのは、相手が「実際に」経験したことに共感することだ。それは、「もしこうだったら」といった仮定の経験や、自分が「こうあるべき」と思う経験ではない。彼を悪者にする必要も、自分を責める必要もない。この状況は、関係した全員にとってフラストレーションを生むものだった。妨害車両の運転手さえも、非難されるべきではない。

私たちが反応しているとき、ほとんど常に誰かを非難している。私たちは常に自分の物語を他人に投影しているのだ。何が起きているのか理解できないとき、その空白を非難で埋めようとするのだ。非難が正確であることもあるが、それが問題解決に役立つことはほとんどない。

システム思考とは、雨の中で立ち尽くしていた私の物語と、携帯も持たずに店で立ち往生していた夫の物語を統合することだ。それはまた、ビジネス的な視点と技術的な現実を統合することでもある。そうすれば、上流のシステム変更が他のチームに与える痛みを理解できるようになる。自分の視点がどれほど現実的で重要であっても、それが全ての物語ではないことを認識することだ。

あの日は一連の出来事が重なっただけで、対処すべき再発するシステム的な問題はなかった。夫が遅刻することなんて、めったにない。非難の気持ちは、「何とかしなきゃ」と私たちを駆り立てる。時にはシステムパターンそのものを見直す必要があるだろうし、解決すべき問題が実際に存在することもある。

時には、単に体を乾かして家に帰ることが正しいだろう。

持論主導のネガティブな側面

持論を強く持つことの副作用として、次が挙がっていた。

• 大抵の場合、二元論で議論している（賛否のどちらかしか許されず、「場合による」という曖昧な回答は許されない）
• みんな正しいと思われたい（持論を守る）
• 文脈を無視する（常に正しい、間違っていることはほぼなく、文脈に依存している。正しいことを明らかにするより、文脈を明らかにするほうが有益）
• 間違いに注目する（とくにテクノロジー分野の人は、アイデアに対して間違い探しを始めがち）
• 感情的である

正しい持論を持つことで評価されるのではなく、むしろ議論を通して持論を変化させられるかで評価されるほうが、システム思考的だと感じた。

思考を構造化する

思考を構造化するための簡単なモデルとして、価値、主張、論拠、裏付け、対立する価値、という図が出てくる。

価値と対立する価値を置き、主張を論拠と裏付けで支え、「したがって」へ収束させる。
同時に、ネガティブな結果や既知の未知、何もしないより良い理由も併記する。

「私たちが作るものの品質は、私たちの思考の品質に等しい」という一文も残しておきたい。

私たちが作るものの品質は、私たちの思考の品質に等しい。
それをアイデアに対するテストカバレッジのようなものだと考えるとよい。
思考の隙間を残したまま本番に出すと、その隙間を埋めるように技術的負債が雑草のように広がる。

他者の思考にフィードバックを与える

他者の思考にフィードバックを与える能力を向上させる基本スキルとして、次が挙がっていた。

• 積極的な傾聴
• 進んで考慮する姿勢
• 論拠と向き合うこと
• 論理的誤謬を探すこと

解決策に飛び込む前に、問題を定義する。
それを解決する価値がある論拠を明確にする。

フィードバックは、改善点の指摘やルールの強制だけではない。
提言の論拠を強くするためのフィードバックとして設計する必要がある、という整理もあった。

「フィードバックを与える」は、業績批判やルール遵守の指導だけではない。
必要なのは提言を強化するフィードバックであり、考えている内容に応じて異なるフィードバックループを設計する。
目標は、提案を理解しやすく、信頼性があり、関連性が高く、一貫性があり、説得力のあるものにすることだ。

論理的誤謬の例として、次が並んでいた。

• わら人形論法
• 事例証拠論法
• 権威に訴える論法
• 多数派論法
• 白か黒か論法
• 中間論法（車とボートの中間を取り、カーボートを作ってしまう）
• 立証責任（提案者に立証を押し付ける。指摘した人が立証まですべき）
• 個人攻撃
• 感情への訴え
• 滑り坂論法