1. 【7.4．エントロピーの法則⑨】
腐敗の兆候を見つけたがすぐ修正できない場合の対応として適切なのは？
解説： タグ付きコメントにより「認識されている問題」としてチームで共有でき、放置とは区別される。
プリンシプル オブ プログラミング
第７章：法則 要約＆クイズ
公開日：
最終更新日：
ソフトウェア開発における普遍的な法則を、要点要約で整理します。これらの法則を知ることは、予測不能な問題に対応する知恵となります。
要約で法則の概念を理解し、20問のクイズで知識を定着。開発を成功に導くための判断力を磨きましょう！
目次
第７章：法則
～プログラミングのアンチパターン～
7.1 ブルックスの法則（Brooks's Law）
- 要旨：炎上プロジェクトへの人員の逐次投入は、むしろさらなる遅延を招く（人月は可換ではない）。
- 理由：
- 依存関係によるオーバーヘッド：分割に伴う調整・確認・コミュニケーション経路の増加で遅くなる。
- 教育コスト：新規メンバーの学習に既存メンバーの時間が割かれ、総合生産性が低下。
- 人≠人の非交換性：能力差、領域知識、ハイコンテキスト未醸成などで置き換えが効かない。
- 結論：遅延の解消を人員投入で図らない。早期にリスケし、優先順位付け→段階的リリースへ舵を切る。
- その他（アンチパターン）：
- アンチパターン＝陥りやすい罠の定義集。反面教師/転ばぬ先の杖として活用し、同じ失敗を避ける。
7.2 コンウェイの法則（Conway's Law）
- 要旨：アーキテクチャは組織を反映する。情報伝達の構造がそのまま設計に現れやすい。
- 理由：組織構造に沿ってコミュニケーションが形成され、その経路で設計判断が行われるため、自然放置で組織＝設計になる。
- 結論：まず望ましいアーキテクチャを描き、組織をそれに従属させる（チーム境界＝プロダクト境界に合わせる）。
- その他（組織×プロセスの相性）：
- 技術縦割り組織（DB/メインフレーム/Web/テスト等）でアジャイルを行うと依存が過多になり、結局ウォーターフォール化しがち。
- 機能横断（クロスファンクショナル）な編成で、ユースケース単位の完結を目指す。
7.3 割れた窓ガラスの法則（Broken Windows Theory）
- 要旨：小さな乱れ（悪い設計/意思決定/コード）の放置が、全体の腐敗を加速させる。
- 理由：「割れた窓」があると、「他もガラクタだから適当に…」という心理が忍び込み、風紀が崩れ、劣化が連鎖するため。
- 結論：発見即修復。時間がなければタグ付きコメントで可視化し、可能なときに速やかに直す。できれば来た時より美しく（ボーイスカウトの法則）。
- その他（運用のコツ）：
- 小さな改善を継続（命名の是正、重複排除、関数抽出、テスト追加）。
- 放置しない文化を醸成し、品質の負債化を未然に防ぐ。
7.4 エントロピーの法則（Law of entropy increase）
- 要旨：コードは放置すると無秩序（腐敗）へ向かう。エントロピー増大を前提とし、兆候を早期に捉えて対処する。
- 理由：人が作る以上、時間と変更で秩序は崩れやすく、無秩序は加速度的に拡大するため。
- 結論：腐敗の兆候を監視し、小さく継続的なリファクタリングとテストで秩序を回復・維持する（アジャイル的に設計を常にシンプル＆可変に）。
- その他（兆候・対策）：
- 腐敗の兆候（見逃さない）：
- 硬さ：小変更でも依存連鎖で広範囲修正（高結合）。
- 脆さ：一部の変更で無関係箇所が壊れる。
- 移植性のなさ：環境依存が強く切り離せない。
- 扱いにくさ：設計が硬直/開発環境が遅く非効率。
- 複雑さ：不要要素の増殖（YAGNI違反）。
- 繰り返し：重複コードの散在（DRY違反）。
- 不透明さ：読み手にとって分かりにくい。
- アジャイルで腐敗を許さない：初期設計に固執せず、シンプル維持＋頻繁なユニット/受け入れテストで柔軟性を保つ。
- チーム文化で腐敗を止める：場当たり修正を放置しない（割れた窓の即修復）。率先リファクタリングを推奨。
- 腐敗の兆候（見逃さない）：
7.5 80-10-10の法則（80-10-10 rule）
- 要旨：要求の80％は短時間で実現、残り10％は大きな努力を要し、最後の10％は実現不能になりがち。
- 理由：万能な単一ツールで全要求を満たす発想は、対象の広さに対して現実的でないため（銀の弾丸はない）。
- 結論：100％充足に固執せず、優先度・適用分野を絞る。必要に応じてツール/ライブラリを導入して効率化する。
- その他（パレートの法則／ホットスポット活用）：
- パレートの法則（例）：
- 売上の8割は2割の商品。
- 交通量の8割は2割の道路。
- 所得の8割は2割の富裕層。
- 機能利用時間の8割は2割の機能に集中。
- ソフトウェアへの適用：
- 障害の8割は2割のコード（品質ホットスポット）。
- 処理時間の8割は2割のコード（性能ホットスポット）。
- → 計測でホットスポット特定、重点レビュー/テスト/チューニングを集中実施。
- パレートの法則（例）：
7.6 ジョシュアツリーの法則（Joshua Tree Principle）
- 要旨：名前を知ると見えてくる。逆に名づけなければ見えない。
- 理由：概念に名前が付くと認知・共有・再利用が可能になる（デザインパターンの最大成果は命名にあり）。
- 結論：物事に名前を与え、チームで共有語彙（ユビキタス言語）を育てる。
- その他（実践・効果）：
- 実践：
- ドメイン概念に一貫した用語を付与し、コード/設計/会話/文書で統一。
- レビューで命名の整合を確認、用語集を更新。
- 新しい発見に対しても積極的に名づけ、チームに展開。
- 効果：見えなかった問題が可視化され、意思疎通と設計の質が向上。学習・再利用が加速。
- 実践：
7.7 セカンドシステム症候群（Second system syndrome）
- 要旨：v1の作者がv2を作ると多機能・低品質・使い勝手悪化に陥りやすい。
- 理由：v1で保留した機能や新機能を盛り込みたくなる欲求、見た目を変えて「進化」を示したい衝動が働くため。
- 結論：自制し「多機能主義」を回避。次の問いでユーザー中心へ立ち返る。
- ユーザーは誰か？
- ユーザーは何をするのか？
- ユーザーは何を必要としているのか？
- ユーザーは何が必要だと考えるのか？
- ユーザーは何を望んでいるのか？（多くは基本機能の安定と使い勝手改善）
- その他（フィーチャークリープ対策）：
- 定義：要望を無秩序に導入し機能過多に陥ること＝破滅の第一歩。
- 方針：NOと言える勇気。どうしても入れる場合は
- 本体をラップ/拡張で対応（アドオン、設定、外部統合）。
- プラグインでコア非改変の拡張を許す。
- コアはシンプルさを死守（KISS・YAGNI）。
7.8 車輪の再発明（Reinvented wheel）
- 要旨：既存ライブラリで足りるのに同等機能を自作してしまうこと（多くは既存の方が高品質）。
- 理由：
- 車輪を知らない（情報・学習不足）。
- 車輪を作りたい（確信犯的な自己実装＝エゴ）。
- 結論：着手前に標準ライブラリ/OSSを必ず調査し、チームへ相談。本来やるべき作業に注力する。
- その他（再発明が妥当な場合）：
- ビジネス目的：
- プロダクトの核/差別化領域は自作し、依存リスクを回避。
- サプライヤ問題に備えコントロールを確保。
- 学習目的：
- ゼロから設計/実装/テスト/不具合修正まで経験し、知見と技能を獲得。
- ビジネス目的：
7.9 ヤクの毛刈り（Yak Shaving）
- 要旨：本来の課題に着手したはずが、連鎖する前提タスクに追われ、目的から逸脱してしまう現象。
- 理由：問題は芋づる式に現れ、依存の連鎖が解決資源を消費するため。
- 結論：毛刈りだと気づいたら立ち止まり、目的を再確認。別ルート検討・他者に相談・情報共有で時間ロスを抑止。
- その他（例・対策）：
- 典型例：
- WebサーバーDL→容量大→DLツール導入→動かない→前提モジュール→ユーザー登録→登録ページ不具合→ブラウザ更新→…本来目的を見失う。
- 対策：
- 目的・制約・タイムボックスを明文化し逸脱を検知。
- 詰まったら相談/エスカレーション。
- 経過をメモして思考ループ/脳内オーバーフローを防ぐ。
- 再発防止のため、手順化/ナレッジ共有。
- 典型例：
プリンシプル オブ プログラミング(第７章：法則)
1. 【7.4．エントロピーの法則⑨】
2. 【7.8．車輪の再発明⑤】
車輪の再発明を避けるために最も適切な行動はどれか？
解説： コーディング前、できれば企画段階で、既存ライブラリやOSSを調査することが重要である。
3. 【7.3．割れた窓ガラスの法則⑦】
次のうち『タグ付きコメント』の例として適切なのは？
解説： 「FIXME」「TODO」などの定型タグを用いたコメントは、チームで共有しやすい明示的な記法である。
4. 【7.7．セカンドシステム症候群⑤】
『フィーチャークリープ』とは何を指すか？
解説： フィーチャークリープとは、ユーザーの要望を無秩序に取り入れることで、結果として機能過多になる現象である。
5. 【7.9．ヤクの毛刈り④】
『ヤクの毛刈り』に気づいたときに最も重要な行動は何か？
解説： 目的を見失っていないか立ち止まって確認することが、時間の浪費や混乱を防ぐ鍵となる。
6. 【7.9．ヤクの毛刈り⑩】
『ヤクの毛刈り』という言葉が象徴しているものは何か？
解説： 『ヤクの毛刈り』は、次々と発生する副次的な作業に巻き込まれ、目的達成が遠のく様子を象徴的に表現している。
7. 【7.5．80-10-10の法則⑧】
性能上のホットスポットへの対応として最も適切なものはどれか？
解説： 性能のボトルネックは、プロファイリングによって測定・特定し、効率的にチューニングするのが定石である。
8. 【7.2．コンウェイの法則⑧】
アーキテクチャとプロセス設計の整合性が重要な理由は？
解説： プロセス設計とアーキテクチャは、チーム文化や開発の柔軟性に大きな影響を与えるため整合性が必要。
9. 【7.6．ジョシュアツリーの法則⑤】
ユビキタス言語に求められる重要な性質として最も適切なものはどれか？
解説： ユビキタス言語は、チーム全体で共通理解するための言語であり、「一貫性」や「意味の明確さ」が特に重要である。
10. 【7.8．車輪の再発明⑥】
次のうち、再発明されたコードを実務で使う際に問題となりやすいのはどれか？
解説： 再発明されたコードは十分なテストや実績がないため、品質・信頼性に課題があることが多い。
11. 【7.1．ブルックスの法則①】
ブルックスの法則が示すのは、どのような状況か？
解説： ブルックスの法則では、炎上プロジェクトに後から人員を投入すると、かえって進行が遅れるとされている。
12. 【7.3．割れた窓ガラスの法則⑤】
『ボーイスカウトの法則』の意味として適切なのは？
解説： コードも「来たときよりも美しく整える」意識で改善することが望ましい。
13. 【7.1．ブルックスの法則⑧】
「アンチパターン」とは何か？
解説： アンチパターンは「こうすると失敗しやすい」という典型的な誤りの例であり、反面教師として学びに活かす。
14. 【7.2．コンウェイの法則⑤】
「DBチームの作業が終わらないとWeb側が動けない」といった状態が示す問題は？
解説： 各工程が互いに依存しており、進行に待ち時間が発生してしまう。
15. 【7.3．割れた窓ガラスの法則⑨】
割れた窓の存在が及ぼす影響として最も適切なのは？
解説： 放置された乱れは他の乱れを呼び、最終的にプロジェクトの文化や品質を損なう。
16. 【7.7．セカンドシステム症候群⑧】
セカンドシステム症候群が特に起こりやすい対象として語られる製品はどれか？
解説： マイクロソフト製品は「次のバージョンで不要な機能を詰め込みがち」としてセカンドシステム症候群の典型とされる。
17. 【7.8．車輪の再発明①】
『車輪の再発明』とは、どのような行為を指すか？
解説： 『車輪の再発明』とは、すでに存在するライブラリやツールと同様の機能を、自分で一から作ってしまうことを指す。
18. 【7.1．ブルックスの法則④】
新規メンバーの参入により、既存メンバーの生産性が落ちる理由は？
解説： 新規メンバーの教育を既存メンバーが担当するため、その分のリソースが奪われ生産性が下がる。
19. 【7.2．コンウェイの法則③】
コンウェイの法則への対処として最も効果的な方針はどれか？
解説： アーキテクチャを先に設計し、それに合わせて組織を再編することで、整合性の取れた開発体制が実現できる。
20. 【7.9．ヤクの毛刈り⑦】
『ヤクの毛刈り』に陥らないために有効な質問はどれか？
解説： 「目的に沿った行動か？」を自問することで、無駄な作業を回避できる。
参考文献・出典
- プリンシプル オブ プログラミング ～3年目までに身につけたい一生役立つ101の原理原則～
- 上田 勲（著）／秀和システム／第1版14刷／2025年／ISBN978-4-7980-4614-3
※本ページは学習支援を目的とした要約です。実務適用時は原典もご参照ください。
このページの著者
もちもちみかん（システムエンジニア）
社内SEとしてグループ企業向けの業務アプリを要件定義〜運用まで一気通貫で担当しています。
経験：Webアプリ／業務システム
得意：PHP・JavaScript・MySQL・CSS
個人実績：フォーム生成基盤／クイズ学習プラットフォーム 等
詳しいプロフィールはこちら！ もちもちみかんのプロフィール