1. 【7.5．80-10-10の法則④】
次のうち「パレートの法則（80/20）」の例として正しいものはどれか？
解説： 使用頻度や売上などの成果は、全体のごく一部（約2割）に集中しているというのがパレートの法則の主旨である。
AIでは制御できない法則をクイズで学ぶ！
プリンシプル オブ プログラミング 第7章：法則
公開日：
最終更新日：
AIが加速しても、開発には避けられない「法則」があります。そこを知らないと、AIで効率化したつもりが逆にハマります。本ページでは、『プリンシプル オブ プログラミング』第7章「法則」で紹介される設計・開発の判断を助ける法則を、要点を押さえた要約と4択クイズで整理します。
要約で「罠の形」をつかみ → 4択クイズ（10問・全問解説付き）で回避力をチェック → 気になったところは解説で復習。「読む→解く→わかる」で、AI時代のプロジェクト運営で迷いがちな場面でもブレない判断基準を作りましょう。
第7章：AIでは制御できない「法則」クイズ！ 目次
- プログラミング クイズ一覧へ
- 次のクイズへ(第1章：AI時代の「前提」をクイズで速習！)
- 前のクイズへ(第6章：AIを使いこなす「手法」クイズ！)
- 『プリンシプル オブ プログラミング』101の原理・原則総まとめ
第７章：法則
～プログラミングのアンチパターン～
7.1 ブルックスの法則（Brooks's Law）
要旨
炎上して遅れているプロジェクトに、あとからどんどん人を追加しても、たいていはもっと遅延するだけ、という法則。「人月（人数×月数）は足し算できる」とは限らない。理由
結論
遅れているからといって、安易に人を投入して解決しようとしない。早めにリスケ（スケジュールの組み直し）を行い、やるべきことの優先順位をつけて段階的にリリースする方向に切り替える。その他（アンチパターン）
- アンチパターンとは、やりがちな「失敗パターン」を名前とセットでまとめたもの。あらかじめ知っておくことで、「あ、これはあのパターンだ」と気づき、同じ失敗を避けるための反面教師として使える。
💡AIワンポイント
ブルックスの法則を踏まえ、遅延時はAIで受け入れ基準を再分解して優先度を付け直します。人を足す前にスコープを削る方が効きます。関連用語（用語集で復習）
7.2 コンウェイの法則（Conway's Law）
要旨
システムのアーキテクチャ（全体構造）は、組織の形やコミュニケーションの流れをそのまま映し出しやすい、という法則。理由
設計の話し合いは、ふつう組織の線引きに沿ったメンバー同士で行われる。その結果、自然に「組織の分かれ方＝システムの分かれ方」になってしまい、何も意識しないと組織構造と設計構造が同じになりやすい。結論
まず先になってほしいシステムの形（理想のアーキテクチャ）を描いてから、それに合わせてチームや担当の区切り方を決める。できるだけチームの境界＝プロダクトやモジュールの境界になるよう意識する。その他（組織×プロセスの相性）
- 技術ごとに縦割り（DBチーム・メインフレームチーム・Webチーム・テストチーム…）の組織でアジャイル開発（短いサイクルで回す開発）をしようとすると、チーム間の依存が多くなり、結局大きな塊でのウォーターフォール（計画から実行までを段階的に進め、原則として後戻りしない開発手法）に戻りがち。
- 機能をまたいでメンバーを集めたクロスファンクショナルチーム（機能横断チーム）を作り、1つのユースケース（利用シナリオ）がそのチーム内で完結するような体制を目指す。
💡AIワンポイント
コンウェイの法則では、AI提案アーキテクチャをチーム境界と突き合わせます。担当境界とコード境界がずれると調整コストが跳ねます。関連用語（用語集で復習）
7.3 割れた窓ガラスの法則（Broken Windows Theory）
要旨
小さな乱れ（雑な設計・微妙なコード・中途半端な対応）をそのまま放置すると、だんだんと全体がボロボロになっていく、という法則。理由
コードの中に「割れた窓」（あきらかに良くない部分）が残っていると、「ここも汚いし、ちょっとくらい適当でもいいか…」という気持ちが入り込みやすくなる。その結果、風紀が乱れ、悪い変更が連鎖して全体が劣化していく。結論
割れた窓を見つけたら、できるだけすぐに直す。もし今は直せなくても、TODOコメントなどで見える形にして記録し、時間ができたときに早めに修正する。できれば、ボーイスカウトの規則にならって「来たときより少しきれいに」して返すことを心がける。その他（運用のコツ）
- 小さな改善をコツコツ続ける（命名の見直し・重複コードの削除・関数の切り出し・テスト追加など）。
- 放置しない文化をチームで共有し、「気づいたら直す」「せめてメモを残す」を当たり前にして、技術的負債（後回しにしたツケ）がたまらないようにする。
💡AIワンポイント
割れ窓対策として、AIが触った周辺の小さな警告や命名乱れを同時に直します。微小な乱れを放置しない習慣が品質低下を防ぎます。関連用語（用語集で復習）
7.4 エントロピーの法則（Law of entropy increase）
要旨
コードは放っておくと、自然とごちゃごちゃして無秩序になっていく。エントロピー増大（物事は放置すると散らかる）を前提に、早めに乱れに気づき、手を入れていく必要がある。理由
ソフトウェアは人間が作り、時間とともに何度も変更されるので、最初は整っていても、だんだんと崩れやすい。しかも、乱れが増えるほどさらに乱れやすくなるという悪循環が起きる。結論
コードの腐敗のサインを見逃さないようにし、小さなリファクタリング（振る舞いを変えずにコードを整理・改善すること）とテストをくり返して秩序を保つ。アジャイル開発のように、設計も常にシンプル＆変えやすい状態にしておく。その他（兆候・対策）
- 腐敗の兆候（見逃さない）
アジャイルで腐敗を許さない
最初の設計にしがみつかず、シンプルさを維持しながら、頻繁にユニットテスト・受け入れテストを回して柔軟性を保つ。チーム文化で腐敗を止める
その場しのぎの修正をそのままにせず、割れた窓を早めに直す意識を共有する。リファクタリング（振る舞いを変えずにコードを整理・改善すること）に前向きに取り組む人を評価する。
💡AIワンポイント
エントロピー対策では、AI生成後に定期リファクタ枠を確保します。変更のたびに少し整える運用で崩壊速度を抑えられます。関連用語（用語集で復習）
7.5 80-10-10の法則（80-10-10 rule）
要旨
ユーザーからの要求のうち、だいたい80％はわりと短時間で実現できるが、次の10％はかなり大変で、最後の10％はそもそも実現が難しいことが多い、という目安の法則。理由
どんなにすごいツールやソフトでも、すべての要求を完全に満たすことは難しい。何故なら万能な「銀の弾丸（これさえあれば全部解決）」は存在しないから。結論
100％ぜんぶの要求を満たそうとしすぎない。本当に大事なところに優先順位をつけ、どの分野に強くするか（適用範囲）をはっきりさせる。必要に応じて、専用ツールやライブラリを組み合わせて効率よく解決する。その他（パレートの法則／ホットスポット活用）
- パレートの法則（80:20の法則の例）
- 売上の8割は、2割の主力商品から出ている。
- 道路の交通量の8割は、2割の主要道路に集中している。
- 所得の8割は、2割の富裕層が持っている。
- あるソフトの利用時間の8割は、2割の機能に集中している、など。
- ソフトウェアへの適用
- 障害（バグ）の8割は、2割のコードに集中している（品質ホットスポット）。
- 処理時間の8割は、2割のコードが占めている（性能ホットスポット）。
- → まず計測してホットスポットを見つけ、そこにレビュー・テスト・チューニングを重点的に行うと効果が大きい。
- パレートの法則（80:20の法則の例）
💡AIワンポイント
80-10-10では、AIに要件を重要度順で渡して上位から実装します。残り10%の難所を早く可視化すると計画が現実的になります。関連用語（用語集で復習）
7.6 ジョシュアツリーの法則（Joshua Tree Principle）
要旨
名前を知ると、急に世界がよく見えるようになる。逆に、名前がついていないものは、そこにあってもなかなか意識できない、という考え方。理由
ある考え方やパターンに名前が付くと、それを意識して探したり、人と共有したり、もう一度使ったりしやすくなる。デザインパターン（よくある設計パターン）も、いちばんの価値は「共通の名前をつけたこと」にあると言われる。結論
重要な考えやパターンには、意識して名前をつける。そしてその名前をチームで共通語として使い、ユビキタス言語（みんなが共通で使う専門用語集）として育てていく。その他（実践・効果）
実践
- そのプロジェクト特有の概念（ドメイン概念）には、一貫性のある用語を付ける。
- コード・設計書・日常会話・ドキュメントで、同じ言葉を使うようにそろえる。
- コードレビューで名前の使い方がブレていないかをチェックし、必要なら用語集に追記する。
- 新しい発見があれば、積極的に名付けて、チームに共有する。
効果
- いままで漠然としていてよく見えなかった問題が、名前をつけることで見えるようになり、意思疎通や設計の質が上がる。結果として、学びと再利用のスピードが上がる。
💡AIワンポイント
ジョシュアツリーの法則に従い、AIとの会話でも曖昧事象へ名前を付けます。エラー群を分類名で扱えると対策の再利用が進みます。関連用語（用語集で復習）
7.7 セカンドシステム症候群（Second system syndrome）
要旨
最初のバージョン（v1）を作った人が、次のバージョン（v2）を作るとき、機能を欲張りすぎて、結果として多機能で使いにくく、品質も下がったシステムになりやすい、という症状。理由
v1で入れられなかった機能や、新しく思いついた機能を全部盛り込みたくなる欲求が強く働く。また、「見た目を大きく変えて進化を示したい」という気持ちも働き、必要以上に作り変えてしまいがち。結論
自分たちの欲張り心を自覚してブレーキをかける。次の質問に立ち返り、常にユーザー中心に考え直す。- ユーザーは誰なのか？
- ユーザーは何をするためにこのソフトを使うのか？
- ユーザーは本当は何を必要としているのか？
- ユーザーは何が必要だと「思って」いるのか？
- ユーザーは何を望んでいるのか？（たいていは、派手な新機能より基本機能の安定と使いやすさ）
その他（フィーチャークリープ対策）
💡AIワンポイント
セカンドシステム症候群を避けるため、AIが提案する追加機能を用途ごとに棚卸しします。初版で必要性が証明できないものは外します。関連用語（用語集で復習）
7.8 車輪の再発明（Reinvented wheel）
要旨
すでによくできたライブラリやツールがあるのに、それとほとんど同じ機能を一から自作してしまうこと。たいていの場合、既存のほうが品質も信頼性も高い。理由
- 車輪を知らない…世の中にすでにあるライブラリ・OSS（オープンソースソフトウェア）などの情報を知らない／調べていないため。
- 車輪を作りたい…あえて自分で作りたいというこだわりやエゴから、「自分のライブラリを作ってみたい」となってしまう場合。
結論
何かを作り始める前に、まず標準ライブラリやOSS（オープンソースソフトウェア）に似た機能がないか必ず調べる。そして、チームに相談してから採用・不採用を決める。本当に価値のある部分に、時間とパワーを集中させる。その他（再発明が妥当な場合）
- ビジネス目的
- プロダクトの中核や差別化ポイントはあえて自作して、外部ライブラリへの依存リスクを減らす場合。
- 特定の会社やサービスに強く依存しすぎないよう、自分たちでコントロールできる部分を確保しておきたい場合。
- 学習目的
- 勉強として、あえてゼロから設計・実装・テスト・不具合修正まで一通り経験し、しくみの理解やスキルアップを狙う場合（ただし本番にそのまま使うかは別問題）。
- ビジネス目的
💡AIワンポイント
車輪の再発明を防ぐには、AIに既存OSS比較表を先に作らせます。差別化点が説明できる時だけ自作へ進む判断が妥当です。関連用語（用語集で復習）
7.9 ヤクの毛刈り（Yak Shaving）
要旨
本来やりたかった作業とは別の、前提タスクの連鎖にどんどん巻き込まれてしまい、気づいたら最初の目的から大きくそれている状態のこと。理由
実際の問題は、1つだけではなく芋づる式（次々に関連して）に現れることが多い。依存の連鎖に引きずられ、時間や集中力が横道の作業に吸い取られてしまう。結論
「これはヤクの毛刈りだな」と気づいたら、いったん手を止めて、最初の目的は何だったかを確認する。必要なら別のルートを考えたり、他の人に相談したり、状況を共有して、ムダな時間を減らす。その他（例・対策）
- 典型例
- 「Webサーバーをインストールしたい」→ ファイルが大きくてダウンロードが遅い → 高速なダウンロードツールを入れよう → なぜか動かない → 事前に必要なモジュールを入れよう → そのためのユーザー登録が必要 → 登録ページがエラー → ブラウザをアップデート…と進むうちに、最初の目的が何だったか分からなくなる、など。
- 対策
- 最初に目的・制約・かけてよい時間（タイムボックス）を書き出しておき、そこから外れていないかを意識する。
- 行き詰まったら、抱え込まず早めに相談・エスカレーション（上司や専門部署など上位の者に判断や対応を仰ぐこと）する。
- これまでにやったことをメモしておき、同じところをぐるぐる回る思考ループや、頭のオーバーフローを防ぐ。
- 今回の経験をふり返って、手順書やナレッジ（有益な知識や知見のこと）として残し、次回は同じ毛刈りをしなくて済むようにする。
- 典型例
💡AIワンポイント
ヤクの毛刈り対策として、AIタスクには終了条件を明記します。目的外の前提作業が増えたら、そこで止めて別経路を選び直します。関連用語（用語集で復習）
プリンシプル オブ プログラミング(第７章：法則)
1. 【7.5．80-10-10の法則④】
2. 【7.7．セカンドシステム症候群⑤】
『フィーチャークリープ』とは何を指すか？
解説： フィーチャークリープとは、ユーザーの要望を無秩序に取り入れることで、結果として機能過多になる現象である。
3. 【7.9．ヤクの毛刈り⑩】
『ヤクの毛刈り』という言葉が象徴しているものは何か？
解説： 『ヤクの毛刈り』は、次々と発生する副次的な作業に巻き込まれ、目的達成が遠のく様子を象徴的に表現している。
4. 【7.9．ヤクの毛刈り④】
『ヤクの毛刈り』に気づいたときに最も重要な行動は何か？
解説： 目的を見失っていないか立ち止まって確認することが、時間の浪費や混乱を防ぐ鍵となる。
5. 【7.1．ブルックスの法則⑦】
「人と人も交換不可能」とされる理由として不適切なのはどれか？
解説： 人は能力も背景も異なるため、簡単に入れ替えができるものではない。
6. 【7.3．割れた窓ガラスの法則⑩】
『割れた窓』に対応する姿勢として最も重要なのはどれか？
解説： すぐ修正するか、できない場合は明示的にコメントを残すことで、チーム全体の健全性が保たれる。
7. 【7.3．割れた窓ガラスの法則⑦】
次のうち『タグ付きコメント』の例として適切なのは？
解説： 「FIXME」「TODO」などの定型タグを用いたコメントは、チームで共有しやすい明示的な記法である。
8. 【7.9．ヤクの毛刈り⑧】
『ヤクの毛刈り』状態に陥ったとき、相談することの利点は？
解説： 他人の経験や知見によって、遠回りせず解決の近道が見つかることがある。
9. 【7.7．セカンドシステム症候群④】
次のうち『セカンドシステム症候群』が招く結果として最も適切なものは？
解説： 本質から外れた機能追加により、操作性や利便性が低下してしまうことが多い。
10. 【7.2．コンウェイの法則⑤】
「DBチームの作業が終わらないとWeb側が動けない」といった状態が示す問題は？
解説： 各工程が互いに依存しており、進行に待ち時間が発生してしまう。
参考文献・出典
- プリンシプル オブ プログラミング ～3年目までに身につけたい一生役立つ101の原理原則～
- 上田 勲（著）／秀和システム／第1版14刷／2025年／ISBN978-4-7980-4614-3
※本ページは学習支援を目的とした要約です。実務適用時は原典もご参照ください。
このサイトの運営者
もちもちみかん（社内SE）
運営者は、グループ企業向けの業務アプリを要件定義から運用まで担当している社内SEです。PHP・JavaScript・MySQL・CSSを使った実務経験をもとに、一次情報や実際の運用で得た気づきを整理しています。
AIにコードを書かせて終わりではなく、どこで迷ったか・どこを人がレビューすべきかまで含めて、 やさしく噛みくだいてまとめています。
経験：Webアプリ・業務システム
得意：PHP・JavaScript・MySQL・CSS
制作・運用中：フォーム生成基盤・クイズ学習プラットフォーム・htmx逆引きレシピ 等
AI時代のエンジニアタイプ診断：CSPF/とろとろみかん
詳しいプロフィールはこちら！ もちもちみかんのプロフィール
