第III部 ・ 第14章
著者は技術的な問題がまだ明確でない頃にDonella Meadowsの『Thinking in Systems: A Primer』（邦訳『世界はシステムで動く』）に出会い、システム思考をキャリアの早い段階から道具として使ってきたと述べる。システムモデリングは完璧な手法ではないが、複雑な問題をデバッグするうえで最も柔軟で効果的な道具であり続けている、という位置づけだ。
この章は、まず2分でモデリングの基礎を押さえる入門から始め、本書全体で扱ってきた戦略を洗練するために実際に作ったモデルを例に、具体的な作り方を解説する。理論そのものも面白いが、本当に学びになるのは「生きたモデル」、つまり現実のエンジニアリング戦略を支えるために作られた実例を見ることだ、という方針で進む。
システムモデリングの核は「ストック」と「フロー」の2語に尽きる。何かが蓄積されうるとき、その蓄積されるものをストックと呼ぶ。例として、ユーザー・ロードバランサー・サーバー間のリクエストの流れを表したモデル図が示される。図中の「リクエスト」「サーバー」「成功したリクエスト」「失敗したリクエスト」といった箱がストックだ。そのストックを増減させる動きの矢印（「OK」「サーバーのエラー」など）がフローである。
システムモデリングとは、ストックとフローの様々な組み合わせを使って、ある状況や振る舞いを理解しようとするプラクティスだと定義される。モデルを使わないと、そうした振る舞いが直感に反して驚きに見えたり、測定から理解に至るまでに時間がかかりすぎたりする。
このリクエストの例では、たとえば「下流のサーバーが負荷に弱いサービスのスループットに上限を設けるロードバランサー」と「上限を設けないもの」のトレードオフをモデルで検討できる。シミュレーション結果のグラフ（2つのシナリオで成功リクエストとエラーリクエストがどう推移するか）を見れば、「下流のサーバーが負荷に弱いなんて馬鹿げている」といった本質的でない議論に陥らずに済む。モデルがあれば、たとえ心配になる挙動でも守る価値があることが一目で分かる。これがモデルの役割だ。現実を完全に理解するのが大変な場面でも、低コストで理解できるようになる。
戦略を策定するうえで洗練に最も使ってこなかった3つの手法のうち、システムモデリングが効果的に効くのは特定の状況だ。第1に、複雑なシステムのどこに手を入れるのが効果的かを見極めたいとき。たとえば新規ライバーパートナーシップでUber体験（ドキュメント17-4）をモデリングするとき、オンボーディングの改善よりも、離れてしまったドライバーを呼び戻すほうが効果的だと分かったりする。
第2に、十分なデータが手元にないとき。データが豊富にあれば実データをモデル代わりに使い違いが分かるが、最先端のサービスのように比較対象すら存在しない状況では、モデルが「比較可能な数字」を作り出してくれる。第3に、ステークホルダー間に意見の相違があり、各自の前提に基づいて議論できるようにしたいとき。モデルにすることで、漠然とした感覚の議論を具体的な前提の議論へ変えられる。
これら3つのいずれの場面でも、システムモデリングを使えばチームで実際のプロセスや戦略を実装する前に近似できるという利点がある。たとえばライバーパートナーシップのRFCリリースの数か月前にこの種のモデリングが議論を方向づけ、何を作るかを定める助けになった。LLM（大規模言語モデル）が登場した近年では、システムモデリングそのものをLLMに支援させることも多くなっている。
システムモデリングの考え方自体はとても感動的だが、ツール選びは正直うんざりしがちな領域だ、と率直に書かれている。初期に大いに期待してツールを試したが長い間バグに悩まされ、その後の数年でツールは大きく改善した。最近では、グラフィカルなモデリング専用ツールよりも、むしろシンプルなツールチェーンのほうがよいと著者は考える。
具体的には、まずスプレッドシート（GoogleスプレッドシートやExcel）で、シンプルなモデルなら必要十分に組める。より凝ったことをしたければJupyterノートブックを使う。これらはモデリング専用ではないが、汎用ツールゆえに学びやすく、できることの幅も広い。専用のモデリングツール（SageModeler、Insight Maker、insightmaker.com など）も試したが、モデリング用の細かいツールにこだわる必要はなく、自分が手早く回せる道具を選ぶのが要点だ。
結局、著者が日常で自作したツールチェーンは、システムモデリングを表現して行えること（システムダイナミクスのモデリング）に振り切った構成になっている。モデルの作成とイテレーションを素早く行える、モデルを共有できる、サーバーのバグやコモディティ的な依存に煩わされない、オープンソースで自由度が高く、Jupyterのエコシステム（国産含む各種ツール）とつないで連携できる――こうした基準を満たすものを、自分で作り上げて使っている。
システムモデリングは練習が必要だが、ここでは2つの方向からアプローチを示す。第1に、一般的な進め方を手順として段階的に示すこと。第2に、本書で扱ったモデルをより細かく分解して具体例から作り方を提示すること、と書かれている。まず一般的な進め方として、紙や図示用アプリ（Excalidraw、Figma、Whimsicalなど）で「ストック」と「フロー」のスケッチを描くことから始める。手で描くのが最も自由にイテレーションでき、頭の中の構造を素早く外に出せる。
続いて、スケッチした要素を文章で書き起こし、各ストックの初期値や、ストックを増減させるフローのふるまいを規定する。フローは固定値の場合もあれば、別のストックに依存して変化する場合もある。よいシステムモデルは、こうした前提（初期値、フローの式）が明確に書き出され、一度作れば後から検証・修正できる状態になっている。
そのうえで、モデルを少し回しては結果を確かめ、現実と矛盾しないかを点検しながら改善を繰り返す。重要なのは、モデルそのものより、モデルを作って回す過程で得られる理解だという点だ。一通り組めたら、より重要なストックやフローに焦点を絞ってモデルを深め、不要な複雑さは削る。
システムモデリングの全体像をさらに具体的に学びたい人向けに、本書付随のドキュメントへの道しるべが示される。ドキュメント17-2は、LLMが理論的な共有を促す例。ドキュメント18-1は、追加費用の見積もりがスプレッドシートによるモデリング（兎の穴的に深掘りできる実例）を示す。ドキュメント16-2は、既存サービスへのプロビジョニングのワークフローを最適化するためのモデルワークフローの例だ。著者自身のブログ（systems-thinkingタグ）も参照先として挙げられている。
これらの実例は、抽象論ではなく「現実の戦略をどう近似したか」を見せるためのものだ。理論の習得よりも、生きたモデルに触れることで、自分の状況に当てはめる勘所がつかめるという狙いがある。
職場でシステムモデルを使いながらコミュニケーションするのは難しい、と率直に認められている。モデルそのものは複雑で説明しづらく、読み手の前で1枚に落とし込むのも難しい。それでも著者は、詳細を割愛しつつ要点を伝える形でドキュメント化に努めてきた。モデルの中身を全部見せようとするより、得た知見と判断のプロセスを共有する方が伝わるからだ。
具体的なドキュメント化の指針として、いくつかの節を立てることが推奨される。ストックとフローのスケッチを示し説明する、スケッチから読み取れる学びを説明する、視覚的に組み込んだモデルの作り方を要点だけ説明する、そしてモデルのストックを変更したときに結果がどう変化するか（What-if）を検証する――こうした構成で、モデルの全部を再現せずに核心と含意を伝える。
システムモデリングを学ぶ価値を強調する一方で、第二の操作方法とは何ではないかも率直に語られている。モデルは現実そのものではなく、現実を近似したものにすぎない。これは「全モデルは間違っているが、一部は有用だ」という有名な格言の通りだ。著者はモデルに描き出した振る舞いとは異なる現実に何度も遭遇しており、モデルが取りこぼした側面に気づかされてきたと述べる。
例として、Stripeでは信頼性モデルを設計したものの実際の採用プロセス（最後のハードルである「両者の握手」＝合意形成）が抜けていたこと、Uberでのジャンプスクーターの改善が想定外のインセンティブにつまずいたことが挙げられる。あらゆるモデルは情報を削ぎ落とすので、ときには重要な情報まで削られてしまうことがある。だからモデルは、現実が予測と矛盾したらすっぱり捨てるか作り直す対象であり、判断を完全に代行するものではない。モデルは現実を映す鏡ではなく、いずれのケースでも2つの事実が同時に成り立つ――モデルは極めて有用であり、なおかつ現実そのものではない。
システムモデリングは万能ではないが、すでに戦略の大枠が定まっていて細部を詰めたいときや、議論を建設的なデータの土台に載せたいときに、低コストで強力に効く道具だ。ストックとフローという最小の語彙で複雑な振る舞いを近似し、何を作るか・どこに手を入れるかを判断する助けになる。
一方、専用の重厚なツールにこだわる必要はなく、スプレッドシートやノートブックといった手早い道具で十分なことが多い。そしてモデルは現実そのものではないという限界を忘れず、現実と矛盾したら捨てて作り直す姿勢が要る。大事なのはモデルという成果物より、それを作り回す過程で得る理解である。