『プリンシプル オブ プログラミング』原則編を10問で学べるクイズサイト

良い設計の原則をクイズで学ぶ！
第2章：原則 要約＆クイズ

公開日：
最終更新日：

本ページでは、『プリンシプル オブ プログラミング』第2章「原則」で紹介される、良いコードを書くための7つの設計原則（DRY, KISS など）について、要点を押さえた要約と4択クイズで整理します。

要約で各原則の狙いをつかみ → 4択クイズ（10問・全問解説付き）で理解度をチェック → 気になったところは解説で復習。「読む→解く→わかる」のサイクルで、日々のコーディングにすぐ活かせる良い設計の軸を身につけましょう！

今すぐクイズに挑戦
（10問・約3分・解説つき）
プリンシプルオブプログラミング
1分で理解＆101の原則総まとめ！

第2章:良い設計の原則をクイズで学ぶ！ 目次

  1. 第2章:良い設計の原則をクイズで学ぶ！の要点・要約を読む(5分)
    1. 2.1 KISS（Keep It Simple, Stupid.）
    2. 2.2 DRY（Don't Repeat Yourself.）
    3. 2.3 YAGNI（You Aren't Going to Need It.）
    4. 2.4 PIE（Program Intently and Expressively.）
    5. 2.5 SLAP（Single Level of Abstraction Principle.）
    6. 2.6 OCP（Open-Closed Principle）
    7. 2.7 名前重要（Name is important）
  2. クイズに挑戦する(10問)
  1. プログラミング クイズ一覧へ
  2. 次のクイズへ(第3章：思想とセオリーの全体像をつかむ！)
  3. 前のクイズへ(第1章：プリンシプル オブ プログラミングの前提をクイズで学ぶ！)
  4. 『プリンシプル オブ プログラミング』101の原理・原則総まとめ
  1. 参考文献・出典
  2. このページの著者
  3. シェア

第２章：原則
～プログラミングのガイドライン～

2.1 KISS（Keep It Simple, Stupid.）

  • 要旨

    KISSとは、「とにかくシンプルに」という考え方である。できるだけ少ない部品と考え方で作り、必要なことだけをやる。

  • 理由

    その場しのぎで機能を足していくと、ルールがバラバラになり、コードがごちゃごちゃして読みづらくなる。結果として、バグが増えたり直すのが大変になったりする。

  • 結論

    まずは最小限の構成で設計・実装する。「足すより削る」を意識して、余計な分岐・設定・機能を持ち込まないことで、品質（分かりやすさ・直しやすさ）を守る。

  • その他（指針）

    • 新技術の無理な導入はしない。（「流行っているから」という理由だけでは入れない）
    • 今いらない機能は今は書かない。（多くは本当に使われないままになる）
    • プログラマが勝手に要件を盛らない。（「あったら便利そう」だけで仕様を増やさない）
    • Less is more（レス・イズ・モア：少ないほど良いという考え方）。
    • オッカムの剃刀（必要以上に多くの前提を持ち込むべきではない、という考え方）。

2.2 DRY（Don't Repeat Yourself.）

  • 要旨

    DRYとは、同じことを何度も書かないという原則。コードのコピペも、コードをそのまま言い換えただけのコメントの重複も避ける。

  • 理由

    同じ内容があちこちにあると、どれが最新か分からなくなり、読む人も直す人も迷う。どこか１か所を直し忘れると、テスト漏れや不具合につながる。

  • 結論

    抽象化（共通部分を１つにまとめること）によって重複を減らし、「１か所直せば全体がそろう」構造にする。

  • その他（手段と適用範囲）

    • ループ化／関数化／モジュール化で処理を分解し、最小の部品にまとめる。
      （モジュール：部品としてまとめたファイルやクラスなど）
    • 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.）

  • 要旨

    １つの関数やブロックの中では、できるだけ同じ高さの話だけを書く。ざっくりした説明と細かい処理をごちゃまぜにしない。

  • 理由

    抽象度（どれくらいざっくり書くかのレベル）がそろっていると、コードをひと目で要約しやすくなり、流れも追いやすくなるから。

  • 結論

    プログラムを文章や本のように構造化し、上のレベルの関数は下のレベルの関数だけを呼ぶようにする。（横からの呼び出しや、下から上への「逆流」は避ける）

  • その他（指針）

    • 序章
      プログラム全体の目的や前提を書くコメント。
    • 目次
      関数やクラスの一覧など、外形を先に示す部分。
    • セクション
      関連するモジュールのまとまり。（モジュール：部品の集まり）
    • 章
      各関数。１つの「役割」を担当する。
    • 段落
      関数の中のコードブロック（処理のかたまり）。
    • 文
      ステートメント（１行の命令）。なるべく１文１つの役割にする。
    • 呼び出し規律
      基本は「上 → 下」方向だけを呼び出す。横や上方向への直接呼び出しは、構造を分かりにくくするので最小限にする。これはモジュール同士の疎結合（ゆるいつながり）を保つ助けにもなる。

2.6 OCP（Open-Closed Principle）

  • 要旨

    コードは新しい機能の追加には開いていて、既存コードの書き換えには閉じているのが理想、という原則。

  • 理由

    ソフトウェアは想定より長く使われ、次々に変更や追加が入る。そのとき毎回広い範囲を直していては、安全性（バグが出ないか）と作業コストの両方が厳しくなる。

  • 結論

    インターフェース／抽象（共通の窓口や考え方）をしっかり決め、その境界の外側に新しい実装を「差し込む」形にする。むやみに抽象を増やさず、必要最小限でシンプルさも保つ。

  • その他（適用指針・割り切り・戦略）

    • 境界設計
      ポリモーフィズム（同じ呼び出しで中身だけ変えられる仕組み）やDI（Dependency Injection）（依存性の注入：使う部品を外から渡すこと）、プラグイン方式などで、新しい機能はできるだけ追加で入れられるようにする。
    • 割り切り
      最初から完璧な抽象を目指すとやり過ぎになりがち。まずは少し素直な実装で始めて、同じような変更が２回目・３回目と続いたところで、はじめてOCPを意識した構造に整える。
    • 関連原則
      クラス化やカプセル化（中身を隠して外からは決められた操作だけさせること）で、影響範囲をできるだけ小さく閉じ込める。

2.7 名前重要（Name is important）

  • 要旨

    命名はとても重要。名前は読み手にとってのUI（ユーザーインターフェース：人がふれる窓口）であり、そのものの意味を一瞬で伝えるラベルになる。

  • 理由

    よい名前は、「このコードは何をするのか」「どんな値なのか」といった仕様理解を直接助ける。結果として、誤解・やり直し・修正コストを大きく減らせる。

  • 結論

    まず仕様（何を実現したいか）をしっかり理解し、その理解から名前を決めてコードを書く。書いたあとに読み返し、名前と中身が本当に合っているかを何度も見直す。

  • その他（実践ポイント）

    • 説明 → 命名 → 説明に戻ってチェック（ループバックチェック）というループを回す。（言葉で説明した内容と、付けた名前がズレていないかを確認する）
    • その分野で普通に使われているドメイン（ビジネス領域）の言葉に合わせて命名する。一貫した用語を使い、あいまいな単語や意味の分からない略語は控える。
    • 名前には意図と約束も含める。（例：単位・範囲・前提条件などが分かるようにする）

プリンシプル オブ プログラミング(第２章：原則)

1. 【2.3．YAGNI（You Aren't Going to Need It.）①】
YAGNI原則の主な主張として最も適切なものはどれか？

2. 【2.1．KISS（Keep It Simple, Stupid.）⑤】
次の記述のうち、KISS原則違反となる可能性が最も高い行動はどれか？

3. 【2.4．PIE（Program Intently and Expressively.）④】
次のうち、PIEの原則に最も適合するプラクティスはどれか？

4. 【2.7．名前は最重要③】
命名に必要なスキルとして最も適切なものはどれか？

5. 【2.2．DRY（Don't Repeat Yourself.）④】
DRY原則の本質に最も近い考え方はどれか？

6. 【2.2．DRY（Don't Repeat Yourself.）⑤】
次のうち、DRY原則をコード以外に適用する事例として最も適切なものはどれか？

7. 【2.6．OCP（Open-Closed Principle）②】
OCPの実践例として最も適切なものはどれか？

8. 【2.3．YAGNI（You Aren't Going to Need It.）③】
次のうち、YAGNI原則に従った適切な対応はどれか？

9. 【2.3．YAGNI（You Aren't Going to Need It.）⑤】
YAGNIと矛盾しない設計上の配慮はどれか？

10. 【2.7．名前は最重要②】
命名の質を高めるために効果的とされる手法はどれか？

次のクイズ(第3章：思想とセオリーの全体像をつかむ！)へ

第２章：原則
採点結果

正答率：0%

-

-

参考文献・出典

  • プリンシプル オブ プログラミング ～3年目までに身につけたい一生役立つ101の原理原則～
  • 上田 勲（著）／秀和システム／第1版14刷／2025年／ISBN978-4-7980-4614-3

※本ページは学習支援を目的とした要約です。実務適用時は原典もご参照ください。

このページの著者

もちもちみかん（システムエンジニア）

社内SEとしてグループ企業向けの業務アプリを要件定義〜運用まで一気通貫で担当しています。

経験：Webアプリ／業務システム

得意：PHP・JavaScript・MySQL・CSS

個人実績：フォーム生成基盤／クイズ学習プラットフォーム 等

詳しいプロフィールはこちら！　　もちもちみかんのプロフィール

もちもちみかん0系くん
TOPへ

もちもちみかん.comとは


このサイトでは、コーディングがめんどうくさい人向けのお助けツールとして、フォームやCSSをノーコードで生成できる、
　もちもちみかん.forms
　もちもちみかん.css1
　もちもちみかん.css2
と言ったジェネレーターを用意してます。

また、このサイトを通じて、「もちもちみかん」のかわいさを普及したいとかんがえてます！