エンジニアとして働き始めて3年経った。その間、曲がりなりにも「システム」というものをずっと扱ってきた。

そして扱えば扱うほど、システムは複雑だと実感する。技術的な問題だけではなく、ビジネスや組織、市場や法律、いろんなものが絡み合っている。 その複雑さを肌に感じつつも、じゃあシステムを全体としてどう捉えていけばいいのか、という問いにはずっと答えられずにいた。

その答えの一女になるかと思って、『Learning Systems Thinking』を読み始めた。まだ1〜5章の途中だが、読んでみると自分がこの3年で経験してきたこと、あるいはエンジニアになる前に経験してきたことも、実はシステム思考の言葉で説明できることに気づいた。その気づきを一度整理しておきたい。

システム思考の第一人者であるドメラ・メドウズによると、システム思考の定義は以下である。

ここで大事なことは2点ある。一つは「目的がある」ということ、もう一つは「要素同士が相互に連結している」ということだ。要素の数や性質よりも、要素間の関係性の構造がシステムをシステムたらしめている。

この本が強調していることの一つが、システムは基本的に非線形だということだ。

これを理解するには、そもそも線形なものがどういうものかを分かっておく必要がある。ここで言う線形とは「前がこうだったから次はこうなる」という一次関数的な予測が成り立つもののことを指す。例えば、昨日の気温から明日の気温を予測するとか、先月の売上から来月を予測するとか。

ではシステムはというと、ほとんどの場合そうはならない。これまでずっとある傾向で動いてきたのに、ある瞬間にまったく別の挙動をすることがある。だからシステムは過去の傾向からの予測や直感から外れて我々を驚かせることがしばしばある。

自分のエンジニアとしての経験上、一番わかりやすい例は、バーストリクエストだと思っている。リクエスト数の増加というのはそもそも線形ではなくて、何かのイベントがきっかけだったり、市場の反応だったり、自分たちのシステムの外にある何かが引き金になって、突然ドンと上がることがある。その結果としてシステムがダウンするというアウトプットが起きる。ここに「昨日がこうだったから今日もこうだろう」という読み方は通じない。

自分は高校大学と合唱をひたすらやっていたが、その時にも似たような体験をしている。高校3年生のとき、朝日の全日本合唱コンクール中部大会に向けてひたすら練習していた。それまでの自分たちの練習量からすると、今年こそは全国に行けるんじゃないかと思っていた。しかし結果はダメ金。このときの努力と結果は比例しなかったということになる。

一方、逆の体験もある。社会人になってから別の団体でコンクールに出たとき、全員がそれほど金賞を強く意識していたわけでもないのに、客員指揮者と合唱団の相性が良かったからか、金賞が取れてしまった。なんとなく「いいかもね」という雰囲気があったのかもしれないが、練習量でも意欲でも、過去の状態からは説明がつかない結果で、結果発表のときには喜びより驚きの声が多く上がっていた。

「これぐらいの練習量で、今こういう状況だから、こういう結果になるよね」という説明がつかない——これがまさに非線形性の典型例だろうと思う。

システム思考というのは、システムを観察し、その観察にもとづいて判断し、意思決定やアウトプットにつなげていく思考の流れそのもののことだ。

この本はシステム思考の実践にあたって、特に2つのことを強調している。

一つ目はモデリングだ。

モデリングとは、自分の思考を言葉・図・コードなどで「外に出す」活動のことだ。なぜこれが必要かというと、私たちが扱うべきシステムのスコープが広いからだ。

企業でエンジニアとして働く以上、技術的なシステムだけでなく、組織、市場、ユーザー、コミュニケーション——これらを全部含んだ「ソシオテクニカルなシステム」が本当の対象になる。一人の頭ではそんな全体を見渡せないから、自分が見えているものを表に出して、他者と共有し、お互いの視点・アイデアを統合していく。それがモデリングの目的だ。

二つ目は思考の自己意識だ。

自分の思考が今どういう状態にあるかを意識すること。これを欠いた思考はほぼ「直感」や「反応」になってしまう。直感というのは過去の傾向をもとにした線形的な予測だ。でもさっき書いたようにシステムは非線形だから、直感に任せると典型的な結論にしか至らない。

だから、自分が今直感や反応に引っ張られているということをまず意識することが、システム思考の出発点だと著者は言っている。考え方が横に逸れそうになったら真ん中に戻してあげる、という瞑想の考え方とも重なる部分があって、なるほどと思った。

ただ、ディープワークや瞑想はシステム思考に固有の話というよりも、現代の知的労働者が働くうえでの前提条件として著者は置いているのだと理解した。集中して考え続けられること、それ自体がどんな知的作業にも必要で、思考を話題にするからこそ、まずその前提を確認したかったのだと思う。

「要素の性質よりも関係性の構造がシステムの挙動を決める」という話は、合唱を見ているとすごく腑に落ちる。

自分の高校はそんなに個々の歌唱力が高い集団ではなかった。でも、何百時間も一緒に練習して、同じ空間を共有した仲間同士だと、不思議と声や響きが合ってくる。全体で聴くと、個々のスペックから想像するよりずっといい音楽になった。逆に、個人としての技術は高いのに、合わせる時間が足りないまま本番を迎えた団体が、全体では散漫な演奏になることもよくある。一人一人を聴けばうまいのに、全体で聴くとばらばら、という具合に。

要素の性質だけを足し合わせても、システムの挙動は出てこない。関係性の構造が全体のアウトプットを決める、ということの典型例だと思っている。

日本のリレーが国際大会で強い、という話も多分同じ構造だ。個々のスプリンターのタイムでは勝てない相手に、バトンパスの精度という「関係性」で勝つ。個体の性能ではなく、個体間のやりとりがシステムの力を決めている。

エンジニアとして働いていると、つい技術的なシステムにしか目が向かない。でも自分が本当に扱うべきシステムはもっと広いと改めて感じた。

一緒に仕事をしている人たち、チームの構造、プロダクトのユーザー、市場の動向——それらが互いに影響し合っていて、その総体が自分たちのアウトプットを決めている。この「関係性を見る」ということが、エンジニアとしての次のレイヤーだという気はしている。

ただ正直、まだわかっていない部分がある。

「非線形だから予測できない」はわかった。「だからモデリングしろ」「ディープワークしろ」「思考を自覚しろ」もわかった。でも、じゃあ実際に複雑なシステムにぶつかったとき、具体的にどう思考すればいいのかというところがまだぼんやりしている。

心構えや習慣の話は出てきた。でも、目の前の複雑な問題に対してどう反応するか、どういう順番で考えるか、という具体的なプラクティスがまだ見えていない。氷山の一角モデルみたいな考え方も3章に出てきたけれど、それをいつどう使うのか、他にどんな思考パターンがあるのか、という部分は読んでいてもあまり掴めなかった。

後半にフィードバックループの話があるらしいので、そのあたりで具体的な手がかりが出てくるといいなと思っている。

一点、本の構成についても引っかかりがある。「概念の統合」という章タイトルがついているのに、読んでいるとレバレッジポイントの話が中心になっていたりする。章立てと内容のつながりがやや見えにくくて、「で、結局何が言いたかったんだっけ」と戻って確認することがあった。モデリングの章でようやく「概念の統合のためにモデリングが必要なんだ」と繋がった、という感じで、もう少し早めに見取り図を示してほしかった。

この本を読んで、具体的に意識しようと思ったことが2つある。

一つはディープワークの習慣化だ。著者はシステム思考にはディープワーク——深く集中する思考——が必要だと言っている。浅い注意では関係性はなかなか見えない。集中する訓練として瞑想を続けること、考えが横に逸れたら今意識していることに戻してあげる、その繰り返しを土台にしていきたい。

もう一つは常にモデリングを意識することだ。自分が今見ているものはどうモデル化できるかを考え続けること。著者は「書くこと」の重要性を強調していて、それはそうだと思う。自分も以前、毎朝ノートを1ページ書くという習慣をやろうとしたことがあった。でも続かなかった。書くのが遅いし、何をどう書けばいいかわからなくなって、気づいたらやめていた。今回これを読んで、またやってみてもいいかもしれないと思い始めている。紙でもいいし、図でもいいし、言葉で整理するだけでもいい。「モデルにする」という意識を持つだけで、見えるものが変わってくるはずだ。

システム思考を学ぶというのは、複雑なものの複雑さを受け入れて、それになんとか対処する、その実践であるということが分かった。複雑なものを単純化して予測しようとするのではなく、関係性を見て、モデル化して、皆で考えていく。

「予測できない」というのは決して諦めではなく、だからこそ謙虚に全体を見ようという話。バーストリクエストも、合唱コンクールも——全部、関係性を見ていなかったから驚いた出来事だった。小さな実践を繰り返しながら、システム思考を当たり前にできるエンジニアになりたいものだ。