1. 【2.6．OCP（Open-Closed Principle）④】
次のうち、OCPに反している設計はどれか？
解説： 条件分岐を増やす方法は、既存コードの変更を伴うためOCPに違反している。拡張性のある構造に切り替えるべきである。
プリンシプル オブ プログラミング
第２章：原則 要約＆クイズ
公開日：
最終更新日：
プログラミングの質を高める重要な原則（DRY, YAGNI, KISSなど）を要点要約で簡潔に解説します。原則は知識ではなく、実践の道具です。
要約で概念をインプットし、4択クイズ（20問・全問解説）で知識を定着。現場で役立つ実践的な基礎力を身につけましょう！
目次
第２章：原則
～プログラミングのガイドライン～
2.1 KISS（Keep It Simple, Stupid.）
- 要旨：常に単純性・簡潔性を最優先し、「動かすための最小」を選ぶ。余計なことはしない。
- 理由：場当たりの修正は無秩序と複雑化を招き、理解・保守・信頼性を損なうため。
- 結論：最小構成で設計・実装し、削る姿勢で品質を守る。
- その他（指針）：
- 新技術の無理な導入はしない。
- 今不要なものは今書かない（多くは結局不要）。
- プログラマが勝手に要件変更しない。
- Less is more（より少ないことは、より豊かなこと）。
- オッカムの剃刀（必要以上に多くの前提を仮定すべきでない）。
2.2 DRY（Don't Repeat Yourself.）
- 要旨：重複をなくす。同じコードも、コードをなぞるだけの重複コメントも避ける。
- 理由：重複は読み手と修正を迷わせ、テストの抜けや不整合を生むため。
- 結論：抽象化により重複を排除し、一箇所の変更で済む構造にする。
- その他（手段と適用範囲）：
- ループ化／関数化／モジュール化で要素を最小単位へ（素因数分解の発想）。
- DRYはビルド／テスト／デプロイ工程などプロセスにも適用（共通化・自動化）。
2.3 YAGNI（You Aren't Going to Need It.）
- 要旨：「多分必要」は多くの場合必要にならない。今必要なものだけ実装する。
- 理由：将来想定の盛り込みは、未使用機能と無駄な複雑さを生みやすい。
- 結論：現時点の要件に集中し、必要になった時にその時点のコストを支払う。シンプルさは結果的に変更に強い。
- その他（実践のコツ）：
- 将来拡張の余地は残しても、複雑さは増やさない。
- 過剰汎用化や早すぎる最適化を避ける（KISS/DRYと整合）。
2.4 PIE（Program Intently and Expressively.）
- 要旨：コードは人が読む。意図を明確かつ表現的に伝える。
- 理由：読み手が理解できてこそ変更が始まる。ただし、コードは主にWhat/Howしか示せず、Whyは失われやすい。
- 結論：読みやすさ最優先。コードで誤解を減らし、Why（設計理由）はコメントや補足で補完する。
- その他（実践ポイント）：
- 明確な命名と一貫した構造、短い文・小さな関数。
- コメントは意図・前提・トレードオフを記す（コードの繰り返しはしない：DRY）。
2.5 SLAP（Single Level of Abstraction Principle.）
- 要旨：関数やブロックごとに抽象化レベルを揃える。同じ高さの記述を並べて、読む/要約する負荷を下げる。
- 理由：レベルが揃っていれば要約性＋閲覧性が同時に高まり、処理の流れが自然に立ち上がって読みやすくなるため。
- 結論：プログラムを文書のように構造化し、上位は下位のみを呼ぶ（横刺し・逆流は避ける）。
- その他（指針）：
- 序章：プログラムの趣旨を述べるコメント。
- 目次：関数一覧（外形を先に示す）。
- セクション：モジュール群のまとまり。
- 章：各関数。
- 段落：関数内のコードブロック。
- 文：ステートメントは短く、1文1責務。
- 呼び出し規律：上→下はOK／横・上方向の直接呼び出しは避ける。
2.6 OCP（Open-Closed Principle）
- 要旨：コードは拡張に開き、既存のコード修正には閉じるよう設計する。
- 理由：ソフトウェアの寿命は想定より長く、変化に晒され続けるため、安定運用と変更容易性の両立が必要。
- 結論：インターフェース／抽象を境界に据え、実装を直接呼ばずに差し替える。必要最小の抽象でシンプルさも維持。
- その他（適用指針・割り切り・戦略）：
- 境界設計：ポリモーフィズム/DI/プラグイン等で新機能は追加で注入。
- 割り切り：過剰抽象は禁物。まずはシンプルに、最初の一撃（初回修正）は受け入れ、次から同種変更を受けない構造へ整える。
- 関連原則：カプセル化やクラス化で影響範囲を局所化。
2.7 名前重要（Name is important）
- 要旨：命名は最重要。名前は読み手にとってのUIであり、意味を不可逆に伝える。
- 理由：適切な名前は仕様理解を直接支援し、誤読・手戻り・変更コストを大きく減らすため。
- 結論：まず仕様を深く理解し、その理解から命名→コードへ落とす。実装を読み返し、命名が最適か随時検証する。
- その他（実践ポイント）：
- 説明→命名→説明の検証（ループバックチェック）を回す。
- ドメイン語彙に合わせ、一貫性と具体性を優先（曖昧語・略語乱用を避ける）。
- 名前で意図と契約を伝える（単位・範囲・前提を含意）。
プリンシプル オブ プログラミング(第２章：原則)
1. 【2.6．OCP（Open-Closed Principle）④】
2. 【2.4．PIE（Program Intently and Expressively.）②】
PIE原則に基づき、「Why（なぜ）」の情報を補足する適切な方法はどれか？
解説： コードは「What」「How」は表現できても、「Why（なぜその設計なのか）」までは表しきれないため、コメントで補足するのが望ましい。
3. 【2.3．YAGNI（You Aren't Going to Need It.）⑤】
YAGNIと矛盾しない設計上の配慮はどれか？
解説： YAGNIは「今は実装しない」が原則だが、「将来的な拡張の余地（柔軟性）」を構造として残すことは、矛盾しない設計的配慮である。
4. 【2.3．YAGNI（You Aren't Going to Need It.）③】
次のうち、YAGNI原則に従った適切な対応はどれか？
解説： 「今本当に必要なものだけを実装し、必要になったらそのときに書く」というのがYAGNIの核心である。
5. 【2.5．SLAP（Single Level of Abstraction Principle.）④】
SLAPに基づいたコード構成の説明として、正しいものはどれか？
解説： SLAPでは、関数の中身がすべて同じレベルの抽象度で書かれていることが重要であり、階層の上下関係を守ることで構造が明確になる。
6. 【2.3．YAGNI（You Aren't Going to Need It.）②】
YAGNI違反によって起きやすい問題はどれか？
解説： 将来のために実装したコードが実際には使われないことは多く、コードベースが不要に複雑化し、理解・修正・テストの負担が増す。
7. 【2.2．DRY（Don't Repeat Yourself.）③】
「DRY原則を破ると、テスト漏れが発生しやすくなる」とされる理由として最も適切なものはどれか？
解説： 同じロジックが複数に分散して存在すると、修正漏れやテスト漏れが発生しやすくなり、結果として品質の低下を招く。
8. 【2.2．DRY（Don't Repeat Yourself.）④】
DRY原則の本質に最も近い考え方はどれか？
解説： DRY原則では「1つの事実は1箇所にのみ記述する」ことを重視し、保守性・信頼性を高めるために、コード・作業・構造の重複を回避する。
9. 【2.1．KISS（Keep It Simple, Stupid.）③】
KISS原則において「Less is more」が示す本質的な意味は何か？
解説： 「Less is more」は、機能やコードの量を絞り込むことで、逆に本質が明確になり、理解・保守・品質が向上するというKISSの核心を表す。
10. 【2.5．SLAP（Single Level of Abstraction Principle.）③】
SLAP原則の実践として「1つのステートメントには1つのことだけを書く」理由として最も適切なのはどれか？
解説： 短く明快なステートメントは、意図の把握を容易にし、変更やバグ修正時の影響範囲も限定しやすくなるため、保守性が高まる。
11. 【2.7．名前は最重要③】
命名に必要なスキルとして最も適切なものはどれか？
解説： 命名には、仕様を正しく理解する力と、それに基づいた直感的な命名を行うセンスが必要である。
12. 【2.6．OCP（Open-Closed Principle）①】
OCP（Open-Closed Principle）の基本的な設計指針はどれか？
解説： OCPの原則では、コードは新たな要件に「拡張」できるようにしつつ、既存の安定したコードを「修正」しないようにすることが求められる。
13. 【2.6．OCP（Open-Closed Principle）②】
OCPの実践例として最も適切なものはどれか？
解説： インターフェースや抽象クラスを使った設計により、コードの拡張が可能になりつつ、安定している既存コードへの直接修正を避けられる。
14. 【2.7．名前は最重要①】
プログラミングにおいて「命名」が最重要とされる主な理由は何か？
解説： 命名はコードを読む人にとってのUIであり、意図や仕様を不可逆的に伝える重要な役割を持つため、最も重要な設計要素の一つとされる。
15. 【2.5．SLAP（Single Level of Abstraction Principle.）⑤】
次のうち、SLAP原則に反するコード構造はどれか？
解説： SLAPでは、抽象度の異なる処理が1つの関数に混在することは避けるべきであり、適切に委譲・分離しておくことで構造の整合性が保たれる。
16. 【2.7．名前は最重要②】
命名の質を高めるために効果的とされる手法はどれか？
解説： 「ループバックチェック」は、命名後にその意味を説明できるかどうかを検証するプロセスであり、命名の妥当性を高めるのに役立つ。
17. 【2.6．OCP（Open-Closed Principle）③】
OCPが重要とされる理由として最も適切なのはどれか？
解説： OCPは、変更が繰り返される現実のソフトウェア運用において、安定性と柔軟性を両立させるために不可欠な原則である。
18. 【2.1．KISS（Keep It Simple, Stupid.）②】
次のうち、KISS原則と最も対立する設計思想はどれか？
解説： KISS原則は「今必要な最小限」にフォーカスする考えであり、将来の予測に基づく過度な設計や抽象化は、往々にして不要で複雑さを招く。
19. 【2.7．名前は最重要⑤】
命名が「不可逆的に意味を伝える手段」であるという主張の意図として適切なものはどれか？
解説： 「不可逆的に伝える」とは、名前を見た瞬間に意味が明瞭に伝わり、曖昧な解釈を許さないという命名の重要性を示している。
20. 【2.3．YAGNI（You Aren't Going to Need It.）④】
YAGNI原則の精神として最も近いものはどれか？
解説： YAGNIは「You Aren't Going to Need It.（それは必要にならない）」の略で、今の要件にのみ集中し、将来の可能性には過剰に備えない方針を指す。
参考文献・出典
- プリンシプル オブ プログラミング ～3年目までに身につけたい一生役立つ101の原理原則～
- 上田 勲（著）／秀和システム／第1版14刷／2025年／ISBN978-4-7980-4614-3
※本ページは学習支援を目的とした要約です。実務適用時は原典もご参照ください。
このページの著者
もちもちみかん（システムエンジニア）
社内SEとしてグループ企業向けの業務アプリを要件定義〜運用まで一気通貫で担当しています。
経験：Webアプリ／業務システム
得意：PHP・JavaScript・MySQL・CSS
個人実績：フォーム生成基盤／クイズ学習プラットフォーム 等
詳しいプロフィールはこちら！ もちもちみかんのプロフィール