1. 【7.8．車輪の再発明⑥】
次のうち、再発明されたコードを実務で使う際に問題となりやすいのはどれか？
解説： 再発明されたコードは十分なテストや実績がないため、品質・信頼性に課題があることが多い。
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）
要旨
コードは放っておくと、自然とごちゃごちゃして無秩序になっていく。エントロピー増大（物事は放置すると散らかる）を前提に、早めに乱れに気づき、手を入れていく必要がある。理由
ソフトウェアは人間が作り、時間とともに何度も変更されるので、最初は整っていても、だんだんと崩れやすい。しかも、乱れが増えるほどさらに乱れやすくなるという悪循環が起きる。結論
コードの腐敗のサインを見逃さないようにし、小さなリファクタリング（振る舞いを変えずにコードを整理・改善すること）とテストをくり返して秩序を保つ。アジャイル開発のように、設計も常にシンプル＆変えやすい状態にしておく。その他（兆候・対策）
- 腐敗の兆候（見逃さない）
硬さ
ちょっとした変更でも、依存が絡み合って広い範囲をいじらないといけない状態（高結合）。脆さ
ある場所の変更が、一見関係なさそうな部分まで壊してしまう状態。移植性のなさ
特定の環境や設定に強く依存していて、ほかの環境へ持っていきにくい状態。扱いにくさ
ビルドやテストにすごく時間がかかる／開発環境の都合で作業がしづらい状態。複雑さ
「念のため」「いつか使うかも」で機能を足し続け、不要な要素が増えている状態（YAGNI違反）。繰り返し
似たようなコードがあちこちにコピペされている状態（DRY違反）。不透明さ
コードを読んでも何をしているのか分かりにくい状態。
アジャイルで腐敗を許さない
最初の設計にしがみつかず、シンプルさを維持しながら、頻繁にユニットテスト・受け入れテストを回して柔軟性を保つ。チーム文化で腐敗を止める
その場しのぎの修正をそのままにせず、割れた窓を早めに直す意識を共有する。リファクタリング（振る舞いを変えずにコードを整理・改善すること）に前向きに取り組む人を評価する。
- 腐敗の兆候（見逃さない）
💡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で入れられなかった機能や、新しく思いついた機能を全部盛り込みたくなる欲求が強く働く。また、「見た目を大きく変えて進化を示したい」という気持ちも働き、必要以上に作り変えてしまいがち。結論
自分たちの欲張り心を自覚してブレーキをかける。次の質問に立ち返り、常にユーザー中心に考え直す。- ユーザーは誰なのか？
- ユーザーは何をするためにこのソフトを使うのか？
- ユーザーは本当は何を必要としているのか？
- ユーザーは何が必要だと「思って」いるのか？
- ユーザーは何を望んでいるのか？（たいていは、派手な新機能より基本機能の安定と使いやすさ）
その他（フィーチャークリープ対策）
- 定義要望を何でもかんでも取り込んで、機能が増えすぎてしまうことをフィーチャークリープと言い、システム崩壊の第一歩になりやすい。
- 方針「NO」と言える勇気を持つ。どうしても機能を足す必要があるときは、できるだけ
- 本体コードを大きく変えず、ラッパー（外側の殻）や拡張として実現する。
- プラグイン方式で、コア部分を変えずに追加機能を差し込める形にする。
- コア（中心部分）はシンプルさを守り、KISS や YAGNI の原則を崩さない。
💡AIワンポイント
セカンドシステム症候群を避けるため、AIが提案する追加機能を用途ごとに棚卸しします。初版で必要性が証明できないものは外します。
7.8 車輪の再発明（Reinvented wheel）
要旨
すでによくできたライブラリやツールがあるのに、それとほとんど同じ機能を一から自作してしまうこと。たいていの場合、既存のほうが品質も信頼性も高い。理由
- 車輪を知らない…世の中にすでにあるライブラリ・OSS（オープンソースソフトウェア）などの情報を知らない／調べていないため。
- 車輪を作りたい…あえて自分で作りたいというこだわりやエゴから、「自分のライブラリを作ってみたい」となってしまう場合。
結論
何かを作り始める前に、まず標準ライブラリやOSS（オープンソースソフトウェア）に似た機能がないか必ず調べる。そして、チームに相談してから採用・不採用を決める。本当に価値のある部分に、時間とパワーを集中させる。その他（再発明が妥当な場合）
- ビジネス目的
- プロダクトの中核や差別化ポイントはあえて自作して、外部ライブラリへの依存リスクを減らす場合。
- 特定の会社やサービスに強く依存しすぎないよう、自分たちでコントロールできる部分を確保しておきたい場合。
- 学習目的
- 勉強として、あえてゼロから設計・実装・テスト・不具合修正まで一通り経験し、しくみの理解やスキルアップを狙う場合（ただし本番にそのまま使うかは別問題）。
- ビジネス目的
💡AIワンポイント
車輪の再発明を防ぐには、AIに既存OSS比較表を先に作らせます。差別化点が説明できる時だけ自作へ進む判断が妥当です。
7.9 ヤクの毛刈り（Yak Shaving）
要旨
本来やりたかった作業とは別の、前提タスクの連鎖にどんどん巻き込まれてしまい、気づいたら最初の目的から大きくそれている状態のこと。理由
実際の問題は、1つだけではなく芋づる式（次々に関連して）に現れることが多い。依存の連鎖に引きずられ、時間や集中力が横道の作業に吸い取られてしまう。結論
「これはヤクの毛刈りだな」と気づいたら、いったん手を止めて、最初の目的は何だったかを確認する。必要なら別のルートを考えたり、他の人に相談したり、状況を共有して、ムダな時間を減らす。その他（例・対策）
- 典型例
- 「Webサーバーをインストールしたい」→ ファイルが大きくてダウンロードが遅い → 高速なダウンロードツールを入れよう → なぜか動かない → 事前に必要なモジュールを入れよう → そのためのユーザー登録が必要 → 登録ページがエラー → ブラウザをアップデート…と進むうちに、最初の目的が何だったか分からなくなる、など。
- 対策
- 最初に目的・制約・かけてよい時間（タイムボックス）を書き出しておき、そこから外れていないかを意識する。
- 行き詰まったら、抱え込まず早めに相談・エスカレーション（上司や専門部署など上位の者に判断や対応を仰ぐこと）する。
- これまでにやったことをメモしておき、同じところをぐるぐる回る思考ループや、頭のオーバーフローを防ぐ。
- 今回の経験をふり返って、手順書やナレッジ（有益な知識や知見のこと）として残し、次回は同じ毛刈りをしなくて済むようにする。
- 典型例
💡AIワンポイント
ヤクの毛刈り対策として、AIタスクには終了条件を明記します。目的外の前提作業が増えたら、そこで止めて別経路を選び直します。
プリンシプル オブ プログラミング(第７章：法則)
1. 【7.8．車輪の再発明⑥】
2. 【7.3．割れた窓ガラスの法則③】
ソフトウェアにおける『割れた窓』の例として最も適切なのは？
解説： 設計やコードにおける一貫性の乱れは「割れた窓」となり、他の乱れを招きやすい。
3. 【7.7．セカンドシステム症候群⑤】
『フィーチャークリープ』とは何を指すか？
解説： フィーチャークリープとは、ユーザーの要望を無秩序に取り入れることで、結果として機能過多になる現象である。
4. 【7.9．ヤクの毛刈り②】
『ヤクの毛刈り』が起こる主な原因は何か？
解説： ひとつの問題を解決しようとすると別の問題が次々と発生し、芋づる式に作業が連鎖することが主因。
5. 【7.2．コンウェイの法則①】
コンウェイの法則の主な主張はどれか？
解説： コンウェイの法則では、ソフトウェアの構造は、その設計を行った組織の構造を自然と反映するとされる。
6. 【7.1．ブルックスの法則⑧】
「アンチパターン」とは何か？
解説： アンチパターンは「こうすると失敗しやすい」という典型的な誤りの例であり、反面教師として学びに活かす。
7. 【7.9．ヤクの毛刈り⑦】
『ヤクの毛刈り』に陥らないために有効な質問はどれか？
解説： 「目的に沿った行動か？」を自問することで、無駄な作業を回避できる。
8. 【7.9．ヤクの毛刈り①】
『ヤクの毛刈り』とは、どのような状態を指すか？
解説： 『ヤクの毛刈り』は、本来の目的とは無関係な作業に時間を費やし、問題解決から逸れてしまう状態を指す。
9. 【7.7．セカンドシステム症候群④】
次のうち『セカンドシステム症候群』が招く結果として最も適切なものは？
解説： 本質から外れた機能追加により、操作性や利便性が低下してしまうことが多い。
10. 【7.3．割れた窓ガラスの法則⑥】
修正の時間がないときに推奨される行動は？
解説： TODOやFIXMEなどの明示的なコメントで「ここは未修正であるが把握している」ことを共有できる。
参考文献・出典
- プリンシプル オブ プログラミング ～3年目までに身につけたい一生役立つ101の原理原則～
- 上田 勲（著）／秀和システム／第1版14刷／2025年／ISBN978-4-7980-4614-3
※本ページは学習支援を目的とした要約です。実務適用時は原典もご参照ください。
このページの著者
もちもちみかん（システムエンジニア）
社内SEとしてグループ企業向けの業務アプリを要件定義〜運用まで一気通貫で担当しています。
経験：Webアプリ／業務システム
得意：PHP・JavaScript・MySQL・CSS
個人実績：フォーム生成基盤／クイズ学習プラットフォーム 等
詳しいプロフィールはこちら！ もちもちみかんのプロフィール
