著名エンジニアが、独自の視点で「おすすめ書籍」の紹介を行う本連載。

今回の語り手は、人気ブログ「おい、」シリーズの著者であり、株式会社スリーシェイクのソフトウェアエンジニア・nwiizoさんだ。

複雑化する現代のシステムに向き合い、よりよい判断へとつなげるための思考法を解説した名著『システム思考の世界へ』（オライリー・ジャパン）を紹介してくれた。

生成AIの台頭で「コードを書く量」が減りゆく今、それでもエンジニアが「技術の手触り」を持ち続けるべき本当の理由が、本書には隠されているという。

はじめに

技術書やビジネス書を読むとき、私は心のどこかで「明日から使えるもの」を探しています。

Kubernetesの設定例。マイクロサービスの分割手順。生成AIを使った開発効率化のチェックリスト。複雑な現場を少しでも前に進めるための、すぐ使えるフレームワーク。会議を短くし、設計判断を速くし、チーム間のズレを減らす便利で効果が出そうな方法。

そういうものを見つけると、少し安心します。明日そのまま作業チケットにできる「ToDoリスト」を受け取った気分になるからです。

ですが、こうした「型」は大体の場合、すぐに陳腐化します。

チームの人数、事業の段階、技術スタック、組織文化、過去の失敗。それらの前提が変わった途端、昨日までの正解はあまり良い答えではなくなるからです。ソフトウェア開発の現場では、その前提がいつも揺れ動いています。

もちろん、手順やチェックリストが不要という話ではありません。障害対応の初動やセキュリティー確認のように、失敗パターンがある程度見えている領域では、型や手順は強い武器になります。

私が疑っているのは、そうした決まった型を、前提が揺れている複雑な問題にまで無理に広げてしまうことです。本書が扱っているのは、まさにこの「前提が動き続ける世界でどう考えるか」という本質的な問い。

この本は、技術を軽く見る本ではありません。むしろ「技術を現実に機能させるためには、コードの外側にある関係性まで見なければならない」と、かなり厳しく突きつけてきます。

人や組織がどう考え、どう伝え、どう学び、どう合意するか。その構造自体も、ソフトウェアと一緒に本番環境へデプロイされていくのだ、と。

本書を読んだ背景

私は普段、Rustの検証コードを書いたり、認証認可のサンプルを組んだりしています。AIエージェントのワークフローを試すことも多いです。手触りとしてはかなり実装寄りで、コードを書き、動かし、壊す。ログを見て、また直す。その反復は今でも好きです。

ただ、仕事や開発で扱うものが大きくなればなるほど、失敗の要因はコードの中だけに収まらなくなります。

設計は間違っていない。テストも通っている。各チームはそれぞれ真面目に働いている。それなのに、リリース直前に認識がズレる。ドキュメントはあるのに読まれない。意思決定の理由は残したつもりなのに、数週間後には誰も説明できない。障害対応では、直接の原因は見つかるのに、同じ種類の手戻りがまた起きる。

こういう場面で、私は何度も「もっと良い図が必要だ」と考えてきました。あるいは「責任分界を明確にしよう」「ADRを書こう」「チームトポロジーを整理しよう」と考えます。それらは間違っていませんし、実際に必要なことも多いです。

でも、図とADRと責任分界を全部綺麗に揃えても、現場は同じ場所で詰まります。

なぜなら、図を描いても、同じ言葉を別の意味で使っていたらズレてしまうからです。ADRを書いても、判断の背景にある恐れや制約が共有されていなければ読まれません。責任分界を決めても、境界をまたぐ知識の流れが詰まっていれば、システムはそこで固まってしまいます。

私がこの本を選んだのは、まさにこうした「図やADRの外側で生じる、人や前提のズレ」を真っ向から扱っているからです。

本書で得られた学び・教訓

本書の中心にあるのは、ソフトウェアを単体の成果物ではなく、ソシオテクニカルなシステムとして見る視点です。ソシオテクニカルという言葉は少し硬いですが、要するに「コードと一緒に人の前提や合意も本番環境へ出ていく」という物の見方です。

著者のDiana Montalionは「現代のソフトウェア開発は線形思考だけでは足りない」と言います。

とはいえ、線形思考は決して悪者ではありません。バグを再現し、原因を切り分け、テストを書き、変更を入れる。そして結果を確認する。これは線形思考がよく効く領域であり、私たちはこの能力無しには仕事ができません。

本書でいう線形思考とは、予測可能で、手続き的で、原因と結果を一直線につなげて考える態度のことです。

問題を部分に分解し、順番に処理し、制御できるものとして扱う。ソフトウェアエンジニアリングは、まさにこの思考に支えられています。関数を分ける、責務を切る、コンポーネントを箱として描く、障害の直接原因を探す。どれも線形思考の力です。

私も困ったときほど、この考え方に立ち戻ります。「切り分ければ分かる、分ければ制御できる」と考える。その態度に何度も助けられてきたからです。だからこそ、線形思考を捨てれば良いとは思いません。

私が思うに、本書の主張は「線形思考から卒業しよう」ではありません。「線形思考が効く範囲を見誤るな」です。

ある変更を入れたら、別チームの運用が重くなる。効率化のために導入した標準化が、プロダクトの探索を遅くする。セキュリティーを高めるための統制が、現場では回避策を生み、かえって危険な情報共有を増やす。

こうした問題では、原因と結果が一直線につながりません。関係性の中で振る舞いが生まれます。本書が「システム思考」と呼ぶのは、まさにこの関係性を見るための実践です。

特に良いと思ったのは、システム思考を「才能」ではなく「実践」として扱っている点です。

システム思考ができる人は、壮大な全体像を一瞬で見抜く天才ではありません。出来事の下にあるパターンを見ようと考える。パターンを生んでいる構造を探り、さらにその構造を支えているメンタルモデルまで降りていく。そういう地味な訓練を続ける人です。この地味さが信頼できます。

一番刺さったのは「モデル」ではなく「モデリング」

この本を読む前の私は、モデルを成果物として見がちでした。C4、UML、シーケンス図、ADR、要件書、バックログ、Miroの付箋。どれも、頭の中にあるものを外に出すための重要な道具です。

しかし、本書はモデルそのものよりも、モデリングのプロセスに重心を置きます。

一人のアーキテクトが綺麗な全体図を描いて配っても、システムはあまり良くなりません。図の外側で、人々の前提や利害や言葉の意味がズレたままなら、その図は「正しいけれど使われない資料」になってしまう。

私もそういう資料を作ったことがあります。作った瞬間は仕事をした気分になる。でも、会議が終わると現場の判断は元の流れに戻っていく。

本当に必要なのは、関係者が同じ場に立つことです。何を問題として見ているのか。なぜそれが重要なのか。どの制約を重く見ているのか。何を怖がっているのか。どこまでなら変えられるのか。そこを互いに見える形にすることが、モデリングの価値です。

この視点で読むと、「設計する」とは図を仕上げることではなく、チームで共に考えられる状態を作ることになります。モデルは答えではありません。対話を始めるための道具です。

ここは、エンジニアの仕事の定義が静かに書き換わる場所です。

私たちは、正しい図や正しい抽象化に寄りかかりたくなります。けれど、複雑な現場では完璧な正しい図よりも、一緒に間違え方を見つけられるプロセスの方が効きます。

モデルは全て不完全です。不完全だからこそ、人前に出して、他者の視点で壊してもらう必要があります。

意見ではなく、理由を共有する

システミック・リーズニングの章も、強く印象に残っています。これは、理由を見える形にして、他者と検証できるようにする考え方です。

技術的な議論では、しばしば「A案が良い」「いやB案が良い」という形で対立が起きます。けれど実際には、A案とB案を比べているようで、別々の問題を解いていることがあります。

ある人は運用負荷を見ている。別の人は初期リリースの速度を見ている。別の人は将来の拡張性を見ている。さらに別の人は、過去に似た移行で失敗した記憶を見ている。

この状態で多数決を取っても、合意にはなりません。声の大きい人の案が通るだけです。

本書は、提案には理由が必要だと言います。しかも、単に「私はこう考える」ではなく、その提案を支える理由を明示し、他者が検証できる形にする必要がある。理由は三つから五つくらいで良い。

重要なのは、「なぜ今その提案が重要なのか、何に効くのか、どの前提に依存しているのか」を表に出すことです。これは、良いADRや良いコードレビューがやっていることと同じです。判断ではなく、判断の構造を残す。

良いレビューは「ここを直してください」だけでは終わりません。なぜその変更が将来の保守性に効くのか。どんな障害を防ぐのか。どの前提なら今の実装で十分なのか。そうした理由を共有します。

逆に、理由のない指摘は正しくても受け取りにくい。正しさだけが流れてきて、判断の構造が流れてこないからです。

ただし、理由を求める文化が機能するには条件があります。考える時間と、間違えても職を失わない安全性です。そこが整っていない場で理由を要求すると、対話ではなくただの査問になります。理由共有は、それが許される場と一緒に設計しなければなりません。

私はこの本を読んで、ADRを「決定の記録」としてだけ見るのをやめた方が良いと感じました。ADRは、本当は提案の理由を残す場所だからです。

未来の誰かが知りたいのは、何を選んだかだけではありません。なぜその時点でそれが妥当に見えたのかです。そこが残っていないと、未来のリファクタリングは過去の人間との喧嘩になります。

学習は個人の努力ではなく、流れの設計である

第6章の「学習」に関する話も、かなり良かったです。

本書では、知識を「ストック」と「フロー」に分けて考えています。知識ストックは、個人や組織が持っている知識の蓄えです。例えば、特定の言語に詳しい、クラウドに詳しい、認証認可に詳しい、運用に詳しいなど、特定の分野について「知っている人がいる状態」を指します。

一方で、知識フローは、持っている知識が「必要な人にきちんと伝わり、判断に使える状態」になっていることです。

読みながら少し手が止まったのは、ここでした。私は新しい技術を調べること自体を、学習だと思いがちだったからです。

複雑なシステムでは、「詳しい人が社内に一人いる」だけでは助けになりません。マニュアルやルール、日々の会話を通じて、その知識が必要な人の元へ届き、チームの意思決定に活かされて初めて、知識は価値を持ちます。

私自身、しばしば知識ストックを増やす方向へ逃げてしまう癖があるので、これらは非常に耳の痛い話でした。

新しい技術を調べる。検証コードを書く。仕様を読む。これらは純粋に楽しいし、成果も見えやすい。けれど、得た知識をチームのメンバーや将来の自分が使える形にして循環させない限り、その知識は局所的なキャッシュで終わってしまいます。

たとえ完璧な専門家がいなくても、「みんなで問いを立て、理由を共有し、学びをチーム内でグルグルと循環させられるチーム」の方が、結果的にずっと強い組織になります。

AI時代、この「知識フロー」の重要性はさらに増していくでしょう。AIから出てきた答えをチーム全員の判断材料として適切に循環させられるかどうかは、AIの問題ではなく、こちら側の知識フローの問題です。

同じAIを使っていても、答えを循環させられるチームと、答えが手元で死んでしまうチームに分かれる。知識を共有する仕組みが弱い組織ほど、便利なAIを使うことで、かえって浅い結論を量産してしまう危険があります。

AIがここまでコードを書き、調査し、設計案まで出してくれるなら、技術者は細かい技術に精通しなくても良いのではないか。

そう考えたくなる気持ちは分かります。私も、知らない領域の入口をAIに作ってもらうことが増えました。最初のサンプルコード、用語の整理、代替案の比較。AIに助けられる場面は確実にあります。

ですが、だからといって技術に詳しくなくて良いとは、まだ思えません。むしろ、詳しさの「役割」が変わっています。これから必要になるのは、全てを暗記しているといった詳しさではなく、AIが出してきた答えの「前提や落とし穴」を見抜くための詳しさです。

そのコードがどの実行環境を想定しているのか。認証や権限の境界をどこに置いているのか。運用時に誰の負荷が増えるのか。古い慣習をもっともらしく再生産していないか。そういう問いは、技術の手触りを持っていないと立てにくい。

AIは答えを速くします。しかし、何を答えとして受け取って良いかまでは、こちらのシステムが決めるしかありません。技術に詳しいということは、AIより多くのAPI名を覚えているという意味ではなく、生成されたものを現実の社会やチームにどうつなぎ合わせるかが見極められるということです。

システム思考は技術の代替ではありません。技術を、より広い判断の中に置き直すためのものです。

実務での活用方法

この本から明日のToDoを一つ選べと言われると、少し困ります。チェックリストへ落とした瞬間、この本の大事な部分が減るからです。

それでも、実務に持ち帰るなら、私はToDoではなく問いとして持ち帰ります。

例えば、設計レビューで議論が割れたとき、まず「どちらの案が正しいか」ではなく、「今見ている問題は同じか」と聞きたい。そこを揃えないまま結論を急ぐと、レビューは判断の場ではなく、互いの前提をぶつける場になってしまいます。

この問いが役に立ったかどうかは、会議の後に分かります。決定そのものだけでなく、なぜその決定が妥当なのかを別の参加者が説明できるなら、少なくとも知識は循環しています。説明できない合意は、合意ではありません。次の判断で別々の方向へ歩き始めるからです。

最初に置きたいのは、「今見ているのは出来事なのか？ パターンなのか？」です。

障害が起きた。仕様が漏れた。レビューが遅れた。チーム間で認識がズレた。これらは全て、出来事です。出来事への対策なら、チェックリストを増やし、承認者を増やし、ルールを追加すればよい。

しかし、同じ種類の出来事が繰り返されるなら、見るべきものはその下にあります。情報の流れ、権限、インセンティブ、言葉の定義、過去の成功体験。その層へ手を入れない限り、対処法が増えるだけで楽にはなりません。

その次に効くのは、「この提案の理由は、誰の知識で強くなるか？」です。

自分だけで考えた提案は、自分の視点に閉じます。プロダクト、運用、セキュリティー、サポート、営業、ユーザー。誰の知識を通すと、この提案は強くなるのか。誰の視点を通していないから危ういのか。ここを考えるだけで、レビューの質は変わります。

最後に、これは自分でもまだ難しいと感じている要素ですが「このモデルは誰と作ったものか？」も重要です。

一人で作った図は、説明資料としては役に立ちます。しかし、合意形成の道具としては弱いことがあります。

モデルが人を一つにするのではありません。モデリングが人を同じ場へ連れていきます。誰と一緒に考えたのか。誰の前提を取り込んだのか。誰がまだ外側にいるのか。それを問う必要があります。

これらの問いを実際に使うと、レビューは確実に長くなります。ですが長くなった議論の末に残る合意は、急いだ議論の後に残るものよりも後で説明しやすい。私はそう感じる回数が増えてきました。

どんな人に読んで欲しいか

本書は、特定の技術を短期間で身に付けたい人向けではありません。読んだ翌日に、明確な作業手順が手に入るタイプの本ではない。

なので読むことを勧めたいのは、技術面では一定の手応えがある一方で、仕事の難しさが別の場所へ移ってきたと感じている人です。

シニアエンジニア、テックリード、スタッフエンジニア、アーキテクト、エンジニアリングマネジャー。肩書きより、自分の判断が他者の前提にぶつかる場面が増えたと感じる人に効きます。

反対に「結局どの技術を使えばいいのか」を知りたいだけなら、この本は回りくどく感じるでしょう。ですが、その問いを何度も繰り返してきた人には効きます。「技術選定の前に、そもそも自分たちは何を解こうとしているのかが怪しい」と感じ始めた人です。

また、この本は場面によっても向き・不向きがあります。

障害対応の初動、SLAが切れる直前のオンコール、創業初期の高速な仮説検証。問いを立てている時間が構造より高くつく場面では、この本のリズムは合いません。「線形思考が効く範囲を見誤るな」というメッセージは、本書自体にも当てはまるのです。

若手のうちに読む意味も当然あります。今すぐ全部を使えなくても、将来ぶつかる問題へ先に名前を付けられるからです。名前を知っているだけで、違和感を放置しにくくなります。

そして最後に、コードを書き続けたい人にもお勧めしたいです。システム思考は、コードから離れるためのものではありません。より良いコードを書くために、コードの外側にある関係性まで見るためのものです。

コードは単独で存在しません。誰かの判断、誰かの制約、誰かの期待、誰かの運用によって意味を持ちます。その全体を見ようとすることは、エンジニアリングの仕事そのものです。

AIによってコードを書く量が減る人もいるでしょう。それでも、コードが分かることの価値は消えません。

むしろ、コードを読めることや動かして確かめられること、違和感のある抽象化に気付けること、障害が起きたときに層を降りていけることの価値は残ります。AIが作ったものをシステムへ入れるなら、その影響を引き受ける技術者が必要だからです。

まとめ

『システム思考の世界へ』は、便利な方法集ではありません。明日のToDoリストにもなりません。

でも、読み終えた後に残るものはあります。何かをすぐ片付けられる感じではなく、次に違和感を覚えたとき、立ち止まる場所が少し増える感じです。

方法は古くなります。ツールも変わります。組織の形も、開発プロセスも、AIとの付き合い方も変わります。そのたびに、私たちはまた新しい方法を探します。それ自体は悪くありません。ただ、方法を選ぶ側の考え方が変わらなければ、違う名前の同じ失敗を繰り返します。

この本が教えてくれるのは、特定の方法ではなく、方法を選び直すための視点です。

AI時代に技術者が技術に詳しくあるべき理由も、たぶんそこにあります。詳しさは、正解を一人で抱え込むためではありません。速く出てくる答えを疑い、現場の制約に接続し、他者と検証できる形へ置き直すためにあります。

ソフトウェアは、コードだけで本番環境へ出るのではありません。私たちの前提、議論の仕方、フィードバックの求め方、学習の仕組み、組織のコミュニケーション構造も、一緒にデプロイされています。

システムを良くしたいなら、コードだけでなく、考え方の流れも設計しなければなりません。

私たちは、もっと良いコードを書く必要があります。同時に、もっと良く一緒に考える必要があります。少なくとも私は、その二つを完全に切り離せる仕事を、まだ知りません。

明日のToDoにはならない。ただ、本書を読めば明日の会議やレビュー、設計判断で、少しだけ違う問いを持てるようになるはずです。

株式会社スリーシェイク
ソフトウェアエンジニア
nwiizo（@nwiizo）

インフラエンジニアとしてホスティングサービスの開発、運用を経て、現在は株式会社スリーシェイクにてソフトウェアエンジニアとして勤務。Webシステムの歴史、運用、開発について興味があり、SREのような信頼性の観点からのプラクティスや運用技術をプロダクトに落とし込めるように日夜開発を行っている

文／nwiizo　編集／今中康達（編集部）