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

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

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

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

はじめに

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

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

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

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

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

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

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

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

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

本書を読んだ背景

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

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

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

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

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

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

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

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

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

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

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

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