1. 導入：システム思考との出会い
技術的負債が10倍困難になった理由
過去のプロジェクトで、印象的な経験がありました。
3ヶ月前なら1日で修正できたはずの問題が、今では2週間の見積もりに。周辺のコードが複雑に絡み合い、影響範囲を特定するだけで数日かかる状態でした。
なぜ、こうなったのか？
同じコードベースなのに、時間が経つほど修正が困難になる。この「加速度的な悪化」には、何か構造的な理由があるはずでした。
その答えを見つけるヒントが、意外な1冊の本にありました。
エンジニアリングマネジメントの名著が推奨する一冊
ウィル・ラーソン著「エレガントパズル」は、エンジニアリングマネジメントの実践書として高く評価されています。
この書籍の第2章「Tools」の冒頭で、作者はこう語っています
「私の人生を良い方向に変えたものは、ドネラ・メドウズの『Thinking in Systems: A Primer』を読んだことです」
その書籍がこちらです
世界はシステムで動く ―― いま起きていることの本質をつかむ考え方
著者：ドネラ・H・メドウズ
ラーソンは、システム思考を「最も普遍的に有用なツールキット」と呼び、ストック（蓄積）とフロー（流れ）の概念を使って、エンジニアリングマネジメントの課題を解決する方法を示しました。
エンジニアリングマネジメントの名著がなぜここまでシステム理論を重視するのか？両書を読んでみることにしました。
メタ的思考の獲得
読んでみた結果、メタ的な思考が身につきました。
以前より問題解決がうまく進む体感があります。特に、以下のような「なぜ？」に答えるフレームワークが手に入りました。
- なぜ技術的負債は後から返済が困難になるのか
- なぜ「動く」と「良い設計」は違うのか
- どこに手を入れれば最も効果的か
本記事では、システム思考の基礎を紹介し、実際の開発経験を通じてその威力を示します。
2. システム思考の基礎
「技術的負債が加速度的に悪化する」
「人を増やしても問題が解決しない」
これらの「なぜ？」に答えるのが、システム思考です。まずは最もシンプルな例から見ていきましょう。
システムとは何か：バスタブで理解する
システムとは、要素、相互関係、目的からなる構造です。
最もシンプルな例がバスタブです。
構成要素
- ストック（蓄積）: バスタブ内の水量
- フロー（流れ）: インフロー（蛇口）とアウトフロー（排水口）
- フィードバック: 水位を見て蛇口や排水口を調整
重要な洞察
- 水位（ストック）は、フローの差で決まります
- インフロー > アウトフロー → 水位上昇
- インフロー < アウトフロー → 水位低下
- フローを見るだけでは、ストックの変化はわかりません
この単純な構造が、システム思考の基礎となります。
フィードバックループ：強化ループ
システムの振る舞いを決定するのがフィードバックループです。
例：銀行預金の利子
- 預金が増える → 利子が増える
- 利子が増える → 預金が増える
- 雪だるま式に増幅（強化ループ）
強化ループは、良い方向にも悪い方向にも働きます。借金の利子も同じ構造で、悪循環を生みます。
遅延（ディレイ）：最も見落とされる危険要素
システム思考で最も重要かつ見落とされやすいのが遅延です。
システムに遅延があると、フィードバックが遅れるため、行き過ぎや振動が発生します。
例：温度調節 - 遅延がない → すぐに温度変化を確認 → 適切に調整 - 遅延がある → 変化が見えるまで時間がかかる → 過剰に調整してしまう
結果：行き過ぎた調整が繰り返され、システムが不安定になります。
遅延の危険性
- 問題が見えた時には手遅れ
- 対処が遅れるほど、影響が増幅
- フィードバックが役に立たない（むしろ逆効果）
システムの不安定さの多くは、遅延が原因です。遅延を短くすることが、システムの改善で最も効果的な手段の一つとなります。
レバレッジポイント：どこに手を入れれば効果的か
ドネラ・H・メドウズは、システムへの介入点には階層があると説明しています。
書籍では12段階で説明されていますが、本記事では実務で使いやすい4階層に整理します。
Lv1：数値調整（効果：小） - パラメータの変更 - 数値の調整 - 例：バスタブの蛇口の流量を変える
Lv2：プロセス・ルールの追加（効果：中） - フィードバックメカニズムの追加 - 新しいルールの導入 - 例：水位計を追加して自動調整
Lv3：構造の変更（効果：大） - システムの接続関係を変える - 要素間の関係を再設計 - 例：バスタブ自体の形状や配管を変える
Lv4：目的の再定義（効果：最大） - システムの目的そのものを変える - 問題の再定義 - 例：「お風呂」ではなく「シャワー」にする
重要な洞察
「システムの振る舞いは構造から生まれる」
構造を変えずに数値だけ調整しても、根本的な解決にはなりません。
実務での応用
- 同じ問題が繰り返し発生する → 構造に問題がある可能性
- Lv1の調整で対処している → 一時的な効果、再発リスク
- Lv3の構造変更 → 時間はかかるが、根本解決
次のケーススタディでは、これらの概念が実際のソフトウェア開発でどう現れるかを見ていきます。
ラーソンの応用：エンジニアリングマネジメントへ
ウィル・ラーソンは、このシステム思考をエンジニアリングマネジメントに応用しました。
例：訓練されたマネージャーの育成
構成要素
- ストック: 訓練されたマネージャーの数（組織の記憶）
- インフロー: 新しいマネージャーの育成プログラム
- アウトフロー: マネージャーの退職や異動
- 情報リンク: マネージャー数がプロジェクト開発速度に影響
システム思考で見えてくること
「なぜプロジェクトが進まないのか？」という問いに対して
- 表面的な対処（Lv1）: 外部からマネージャーを急遽採用
- プロセス改善（Lv2）: 育成プログラムを追加
- 構造的解決（Lv3）: 育成速度 < 退職速度という構造を変える
- なぜ退職するのか？（アウトフローの原因）
- 育成が遅いのはなぜか？（インフローの障壁）
- マネージャーに依存しすぎる構造自体を変えられないか？
ラーソンの洞察
「システム思考は、実際の作業を実行せずに『物事がどう機能するか』についての仮説を素早くテストする場を提供する」
ストックとフローで可視化することで、リソースを投入する前に改善機会を特定できます。
では、この枠組みを使って、実際のソフトウェア開発の問題を見ていきましょう。
3. ケーススタディ1：チーム生産性のボトルネック
背景：成長するチームとレビュー待ち時間
プロジェクトが成長し、開発メンバーが増加していきました。それに伴いPR（Pull Request）の数も増え、コードレビューがボトルネックになり始めていました。
問題の可視化
- レビュー待ち時間が徐々に増加：数時間から、やがて数日に
- シニアエンジニアにレビュー依頼が集中
- 開発者は待機中に別タスクに着手 → さらにPRが溜まる
チーム全体の開発速度が、「レビュー待ち」という遅延に支配されている状態でした。
試行錯誤の過程
Phase 1（Lv1: 数値調整）: レビュアーを増やしたが、品質のばらつきで手戻りが発生し、むしろ悪化。
Phase 2（Lv2: プロセス追加）: ガイドラインを整備し品質は安定したが、シニアへの依存という構造は変わらず、ボトルネック解消せず。
Phase 3（Lv3: 構造変更）: チーム構造の変更
ここで気づきました。問題は「レビュアーのスキル」や「プロセスの不備」ではなく、「レビューに依存する構造」そのものでした。
構造的な変更を実施しました。
1. ドメイン別オーナーシップの明確化 - 各メンバーが特定領域の責任を持つ - その領域のレビューは優先的に担当 - レビュー依頼の分散
2. ペアプログラミングの導入 - レビュー前にペアで実装 - レビュー負荷そのものを軽減 - 実装中に知識共有が進む
3. 自動化の強化 - CI/CDで機械的チェックを自動化 - レビューは設計判断に集中 - 人間の判断が必要な部分を削減
結果：ボトルネック解消
- レビュー待ち時間が大幅に短縮
- ジュニアエンジニアの成長が加速（ペア実装で学習）
- チーム全体の開発速度が向上
- シニアの負担も軽減
システム思考で読み解く
この問題を、ラーソンのストックとフローで整理してみましょう。
ストック（蓄積）: レビュー待ちPRの数 ← これが増え続けている！
フロー（流れ）
- インフロー（PR作成） > アウトフロー（レビュー完了） ← ボトルネック
- この不均衡が、遅延を生み、強化ループで悪化
Phase 1-3の介入をシステム思考で分析
Phase 1-2は構造を変えていない - Phase 1: レビュアー数を増やしたが、「訓練された」レビュアーではない → アウトフローは増えない - Phase 2: 品質は安定したが、「シニアに集中する」構造は変わらない → ボトルネック残存
Phase 3は構造を変えた - ペアプログラミング → レビューが必要なPR自体が減る（インフローの質変化） - オーナーシップ分散 → 複数のアウトフロー経路が生まれる（構造変更） - 自動化 → 機械的チェックはシステムが処理
→ インフロー < アウトフローに転換 → ストック（レビュー待ち）が減少
システム思考の核心: 「システムの振る舞いは構造から生まれる」
「レビューが遅い」という症状ではなく、「レビューに依存しすぎる構造」という原因を変えることで、根本解決しました。
マネジメントへの示唆
- 人を増やせば解決するか？ → 構造が悪ければ解決しない
- プロセス改善で十分か？ → Lv2の介入では、Lv3の問題は解決できない
- 構造を変えるタイミングは？ → 同じ問題が繰り返し発生するとき
システム思考の深い洞察：レジリエンスと情報の流れ
Phase 3の成功を、システム思考の視点からさらに深掘りしてみましょう。実は、この改善には2つの重要な概念が隠れています。
1つ目はレジリエンス（適応力）です。Phase 3の成功は、単に「レビュー待ちを減らした」だけではありません。
重要なのは、レビュー待ちPRが「ゼロ」を目指したわけではないことです。
なぜストックがゼロではない方が良いのか？
ストックがゼロの世界： - PR作成とレビュー完了が完全に同期する必要がある - reviewerが休んだら、開発者はPRを出せない - 1人が病欠したら、システム全体が停止する - → レジリエンス（適応力）がゼロ
適度なストック（2-3件）の世界： - インフローとアウトフローが独立して変動できる - reviewerは自分のペースでレビューできる - 開発者は、reviewerの都合を気にせずPRを出せる - 外部のショック（病欠、緊急対応）に耐えられる - → レジリエンスがある
「世界はシステムで動く」第3章の核心：
「ストックは、バッファー（緩衝材）として機能する。インフローとアウトフローを独立させることで、システムにレジリエンスを与える」
PR分割は「情報の流れ」を改善している
2つ目の重要な概念は情報の流れです。Phase 3で推奨した「PRの分割」は、実はシステム思考における高次のレバレッジポイント（Lv6）に該当します。
大きいPR： - 変更の影響範囲が見えづらい - reviewerの認知負荷が高い - 何をレビューすべきか不明確
小さいPR： - 変更の意図が明確 - reviewerに必要な情報が届きやすい - 1つのPRは1つの明確な変更
これはレバレッジポイントLv6「情報の流れ」の改善です。
メドウズは書籍の中で、情報の流れが持つ力を示す印象的な事例を紹介しています。
メドウズの有名な事例：
「電力メーターを地下から廊下に移動させただけで、消費量が30%減少」
この事例の重要なポイントは、システムの構造を変えていないことです。同じ電力供給システム、同じ住人、同じ家電製品。変えたのは「情報の可視性」だけです。
なぜこれで行動が変わったのか？適切な情報が、適切な人に、適切なタイミングで届くようになったからです。
PR分割も同じ構造： - 適切な情報（小さく明確な変更）が - 適切な人（reviewer）に - 適切なタイミング（すぐにレビューできる）で届く
→ 行動が変わる（レビューが速くなる）
驚くべき非線形関係
直感的には「PRを細かくする → PR数が増える → レビュー待ちも増える」と思いがちです。
しかし現実は：
- PR数は増える（一時的な振動）
- でもreviewしやすくなる → アウトフローが速くなる
- 最終的にストック（レビュー待ち）が減少
これが「世界はシステムで動く」第4章「なぜシステムは私たちを驚かせるのか」の核心： - 非線形関係：原因と結果が比例しない - 遅延：効果が出るまで時間がかかる - 直感に反する結果：システムは私たちを驚かせる
Phase 3の成功は、単なる「数値調整」や「プロセス改善」ではなく、システムの構造（Lv3）と情報の流れ（Lv6）を同時に変えた結果でした。
チーム運営において、どのレベルの介入をしているかをメタ的に意識することで、長期的な効果を予測できます。
4. 実践への示唆
システム思考で変わること
システム思考を学ぶ前と後で、問題への向き合い方が変わります。
変化1：症状ではなく構造を見る
ケーススタディ1のレビュー待ち問題を思い出してください。
従来の思考
- 「レビューが遅い」→ レビュアーを増やす
- 「まだ遅い」→ ガイドラインを追加
- 症状への対処
システム思考
- 「なぜレビューに依存する構造になっているのか？」
- 「レビュー負荷そのものを減らせないか？」
- 構造への介入
同じ問題でも、見ている層が違います。
変化2：「繰り返し」に敏感になる
問題が繰り返し発生するのは、構造が変わっていないサインです。
- 同じようなバグが何度も出る → 構造に問題がある
- 同じボトルネックが再発する → 構造を変えていない
- 対処が「またか」と感じる → 症状への対処になっている
「また同じ問題だ」と感じたら、それは構造変更のチャンスです。
変化3：レバレッジポイントを意識する
どのレベルの介入をしているか、メタ的に意識できるようになります。
作業前に自問する
- 「これは数値調整（Lv1）か、構造変更（Lv3）か？」
- 「時間をかけて構造を変えるべきか？」
- 「この対処で再発は防げるか？」
ケーススタディ1のチームボトルネックでも、Phase 1-2（人を増やす、ガイドライン）では構造が変わっていませんでした。Phase 3で構造を変えたことで、根本的に解決しました。
よくある罠
システム思考を知らないと、以下の罠に陥りがちです。
罠1：症状への対処で満足してしまう
「動くようになった」で満足して、構造を変えない。
例
- バグを修正したが、なぜそのバグが生まれたか考えない
- タイムアウトを延ばしたが、なぜタイムアウトするか考えない
- エラーハンドリングを追加したが、なぜエラーが出るか考えない
結果
同じような問題が別の場所で再発します。
罠2：「人を増やせば解決」という幻想
ケーススタディ1で見たように、構造が悪ければ、人を増やしても解決しません。
むしろ以下のような問題が発生します。
- コミュニケーションコストが増える
- レビュー品質がばらつく
- 新たな問題が発生する
システムの速度は、最も遅い部分（ボトルネック）で決まります。
人を増やす前に、構造を見直す必要があります。
罠3：遅延を見落とす
システム思考で最も重要かつ見落とされやすいのが遅延です。
遅延がある系では以下のような問題が起きます
- 問題が見えた時には手遅れ
- 対処しても効果が出るまで時間がかかる
- 行き過ぎや振動が発生する
例
- コードレビューが遅い → 開発者は別タスクに着手 → 手戻りコスト増大
- バグ発見が遅い → 影響範囲が広がる → 修正コスト指数関数的に増加
- デプロイが遅い → 問題のフィードバックが遅れる → 誤った方向に進む
遅延を短くすることが、最も効果的な改善の一つです。
実践での問いかけ
システム思考を実務で使うための、シンプルな問いかけです。
問い1：「この問題は繰り返し起きているか？」 - YES → 構造に問題がある可能性が高い - YES → Lv3（構造変更）を検討すべき - NO → 一時的な問題、Lv1の対処で十分かもしれない
問い2：「今の対処は構造を変えているか？」 - 条件分岐を追加している → 構造は変わっていない - パラメータを調整している → 構造は変わっていない - 接続関係や責務を変えている → 構造を変えている
構造を変えていなければ、同じ問題は再発します。
問い3：「遅延はどこにあるか？」
問題発見から修正までの時間を測定してみてください。
- 本番デプロイ後に発見 → 数日〜数週間の遅延
- ステージング環境で発見 → 数時間〜1日の遅延
- CI/CDで発見 → 数分の遅延
- 実装中に気づく → ほぼ遅延なし
遅延が長いほど、問題は増幅します。
フィードバックループを短くする仕組み（CI/CD、ペアプログラミング、小さいPRなど）への投資は、遅延を短くする投資です。
問い4：「時間とのトレードオフをどう判断するか？」 - 緊急かつ重要 → Lv1で即対処、後でLv3で根本解決 - 重要だが緊急でない → 最初からLv3を目指す - 緊急だが重要でない → Lv1で対処、根本解決は不要
すべてをLv3で解決する必要はありません。しかし、「どのレベルの介入をしているか」を意識することで、技術的負債の蓄積を防げます。
ケーススタディから学んだこと
ケーススタディ：チームのボトルネックから得られた教訓
- 人を増やす（Lv1）では解決しない
- ガイドライン（Lv2）でも構造は変わらない
- チーム構造の変更（Lv3）で根本解決
- 遅延（レビュー待ち）が強化ループを生んでいた
- レジリエンス（適度なバッファー）の重要性
- 情報の流れ（Lv6）の改善が行動を変える
- 非線形関係（PR分割→レビュー待ち減少）
核心的な教訓
「システムの振る舞いは構造から生まれる」
症状を抑えるのではなく、構造を変えることが根本解決への道です。
5. まとめ
システム思考という武器
エレガントパズルの作者ウィル・ラーソンが「世界はシステムで動く」を推奨していた理由がわかりました。
システム思考は、開発の「なぜ？」に答え、より効果的な介入点を見つける力を与えてくれます。
この記事で紹介した概念
フィードバックループと遅延 - 遅延が長いほど、問題は増幅する - フィードバックループを短くすることがCI/CDの真の価値
レバレッジポイント - システムへの介入点には階層がある - 構造を変えることが最も効果的 - 症状ではなく、原因を変える
メタ的に思考する価値
単に問題を解決するだけでなく、「どのレベルの介入をしているか」をメタ的に意識することで、長期的な効果まで見通せるようになります。
あなたの開発で、明日から
次にあなたが「またこの問題か」と感じたら、それは構造を変えるチャンスです。
次にあなたが条件分岐を追加しようとしたら、一度立ち止まって問いかけてください：「これは構造を変えているか？」
次にあなたが「人を増やせば解決する」と考えたら、まず構造を見直してください。ボトルネックはどこにあるのか？
システム思考は、魔法の杖ではありません。しかし、問題を見る解像度を上げてくれる強力なレンズです。
さらに学びたい方へ
本記事で紹介したシステム思考の概念は、記事冒頭で紹介した2冊の書籍から得たものです
- 「世界はシステムで動く」 - システム思考の古典的名著
- 「エレガントパズル」 - エンジニアリングマネジメントへの応用
両書を手に取ることで、さらに深い理解が得られます。
