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

AIを導くセオリーをクイズで定着！
第3章：思想｜プログラミングセオリー

公開日：
最終更新日：

AIに設計を任せるほど、まず必要になるのは「何を価値として守るか」という判断軸です。本ページでは、『プリンシプル オブ プログラミング』第3章「プログラミングセオリー」で語られる3つの価値と、それを支える6つの原則を、要約と4択クイズで整理します。

要約でセオリーの全体像をつかみ → 4択クイズ（10問・全問解説付き）で腕試し → 迷ったところは解説で復習。「読む→解く→わかる」で、AI生成コードの品質を支える思考プロセスを定着させていきましょう。

今すぐクイズに挑戦
（10問・約3分・解説つき）
プリンシプルオブプログラミング
AI時代を生き抜く「101の設計原則」

3-1：AIを導くセオリーをクイズで定着！ 目次

  1. 3-1：AIを導くセオリーをクイズで定着！の要点・要約を読む(5分)
    1. 3.1 プログラミングセオリー（Programming theory）
    2. 3.2 ３つの価値①：コミュニケーション（Communication）
    3. 3.3 ３つの価値②：シンプル（Simplicity）
    4. 3.4 ３つの価値③：柔軟性（Flexibility）
    5. 3.5 ６つの原則①：結果の局所化（Local consequences）
    6. 3.6 ６つの原則②：繰り返しの最小化（Minimize repetition）
    7. 3.7 ６つの原則③：ロジックとデータの一体化（Logic and Data together）
    8. 3.8 ６つの原則④：対称性（Symmetry）
    9. 3.9 ６つの原則⑤：宣言型の表現（Declarative Expression）
    10. 3.10 ６つの原則⑥：変更頻度（Rate of Change）
  2. クイズに挑戦する(10問)
  1. プログラミング クイズ一覧へ
  2. 第3章：思想とセオリーの全体像をつかむ！ 目次へ
  3. 次のクイズへ(3-2：AI共創の土台、10の設計技法クイズ！)
  4. 前のクイズへ(第2章：AIコードを見抜く「原則」クイズ！)
  5. 『プリンシプル オブ プログラミング』101の原理・原則総まとめ
  1. 参考文献・出典
  2. このページの著者
  3. シェア

第３章：思想①
～プログラミングセオリー～

3.1 プログラミングセオリー（Programming theory）

  • 要旨

    「最高のコード」とは、拡張しやすく、ムダが少なく、読みやすく、理解しやすいコードのこと。その土台になる考え方が「セオリー（理論・考え方の枠組み）」で、3つの価値（コミュニケーション／シンプル／柔軟性）を大事にしている。

  • 理由

    「大事にしたい価値」→「守るべき原則」→「具体的なコード」というつながりをはっきりさせておくと、読みやすさ・拡張しやすさなどの品質と、日々の「この書き方でいいかな？」という細かい判断を結びつけやすくなるから。

  • 結論

    3つの価値をスタート地点（動機）にして、6つの原則を中継地点（考え方のルール）として使い、最終的にコードという形の解決策に落とし込んでいく。

  • その他（範囲・効果・構成要素）

    • 3つの価値（Three values）
      • コミュニケーション（Communication）…人に意味が伝わることを重視する。
      • シンプル（Simplicity）…ムダな複雑さを削ることを重視する。
      • 柔軟性（Flexibility）…あとから変えやすいことを重視する。
    • 6つの原則（Six principles）
      • 結果の局所化（Local consequences）…変更の影響を狭い範囲に閉じ込める。
      • 繰り返しの最小化（Minimize repetition）…同じことを何度も書かない。
      • ロジックとデータの一体化（Logic and Data together）…処理とデータを近くにまとめる。
      • 対称性（Symmetry）…同じ種類のものは同じパターンで書く。
      • 宣言型の表現（Declarative Expression）…「どうやるか」より「何をしたいか」を書く。
      • 変更頻度（Rate of Change）…同じ理由・同じタイミングで変わるもの を同じ場所に集める。

3.2 ３つの価値①コミュニケーション（Communication）

  • 要旨

    コードはコンピュータに命令するためのものであると同時に、人に見せるドキュメント（説明書）＝コミュニケーションの道具でもある。

  • 理由

    開発にかかるコストの多くは、新規開発よりも保守（あとから直したり追加したりする作業）で発生する。そこで、他の人（＝未来の自分も含む）がコードを読みやすいかどうかが、作業の速さ・バグの少なさにそのまま効いてくるから。

  • 結論

    常に「他の人はこのコードを見てどう感じるだろう？」を想像し、読みやすさと意図（Why）が伝わることを最優先にする。

  • その他（効果・実践）

    • 効果：コードレビューのスピードアップ／変更着手のハードルが下がる／バグに早く気づきやすくなる。
    • 実践：
      • 命名を一貫させる（同じ意味には同じ単語を使う）。
      • コードだけでは分かりにくい部分は、「なぜそうしているか（Why）」をコメントで補う。
      • インターフェース（外から見える入口）は必要最小限にしてシンプルに保つ。
      • 驚き最小の原則（予想外の動きをさせない）を意識する。

  • 💡AIワンポイント

    コミュニケーション重視なら、AI生成PRには変更意図と非採用案を必ず添えます。コードだけより、判断理由がある方が将来の修正判断が速くなります。

3.3 ３つの価値②シンプル（Simplicity）

  • 要旨

    ここで言う「シンプル」とは、機能を削ることではなく、必要以上の複雑さを取り除いた状態のこと。動かすために必要な最小限で設計する。

  • 理由

    余計な複雑さは、ユーザーにとっても開発者にとってもあまり価値を生まず、バグ・読みづらさ・話が通じにくくなる原因になりやすいから。

  • 結論

    本当に必要な部分（玉）を見きわめて取り出し、不要な部分（石）は勇気を持って捨てる設計を徹底する。「毒をもって毒を制す」のように、「一時しのぎのパッチを何枚も当てる」ようなコードでごまかすのではなく、根本原因を直してシンプルにすることを優先する。

  • その他（範囲・指針）

    • KISS（Keep It Simple, Stupid）やYAGNI（You Aren't Going to Need It）を守り、足し算より引き算で考える。
    • 同じ処理の重複や、暗黙の依存関係を減らす（DRY・対称性の考え方を使う）。
    • 場当たり的な例外処理や「とりあえず」のコードは、期限やメモを付けて管理し、放置せずできるだけ早く整理する。

  • 💡AIワンポイント

    シンプルの価値を守るには、AI提案から副作用の多い便利関数を除去します。入力と戻り値が追える純粋関数へ寄せると、挙動確認が一気に楽になります。

3.4 ３つの価値③柔軟性（Flexibility）

  • 要旨

    柔軟性とは、あとから変更しやすいかどうかという性質。コードは最初から完成ではなく、変わり続ける前提で書くべきもの。

  • 理由

    現実の要求や環境は常に変化するので、コードも必ずどこかで変更が入る。そこで、変更しやすさ（変更容易性）が、長期的な品質（壊れにくさ・続けやすさ）を大きく左右するから。

  • 結論

    「拡張には開き、既存の修正には閉じる」というOCP（Open-Closed Principle）の考え方を意識する。関係が深いコードは近くにまとめ、関係が薄い部分同士は、できるだけ依存しないように設計する。

  • その他（効果・実践）

    • 効果：変更が決まった部分だけで済むようになり、デグレード（前は動いていたところが壊れること）と工数を減らせる。
    • 実践：
      • 1つのモジュールの中で役割をはっきりさせて凝集度(４章参照)を上げ、モジュール同士の結合度を下げる。
      • インターフェース（抽象的な窓口）やDI（Dependency Injection＝依存性の注入）を使って、差し替えやすい構造にする。
      • 変更が起きやすい部分とあまり変わらない部分でレイヤーを分けておく。
      • テストで振る舞いを固定し、安心して中身を作り替えられるようにする。

  • 💡AIワンポイント

    柔軟性を狙うなら、AIに変更予定の高い箇所だけ抽象化させます。滅多に変わらない部分まで抽象化すると、読みにくさだけが残ります。

3.5 ６つの原則①結果の局所化（Local consequences）

  • 要旨

    1か所を直したときに、その影響ができるだけ小さい範囲（局所）の中でおさまるようにコードを組み立てる考え方。

  • 理由

    変更の影響が広いと、「ここを直したら、あっちもこっちも動かなくなった…」という状態になり、テストも修正も爆発的に大変になってしまうから。

  • 結論

    「修正に対して閉じる」（OCP）の考えを取り入れ、変更は特定のモジュールの中だけで完結させられるように設計する。

  • その他（指針・効果）

    • 指針
      • 一緒に変わりやすいコード同士は、近くにまとめて配置する。
      • 1つのモジュールの責務（役割）を明確にしておく。
      • モジュールの境目（インターフェース）では、責任の範囲をはっきり分ける。
    • 効果：回帰バグが減る／レビュー・テストの「見るべき場所」を絞りやすい／リリース時のリスクが下がる。

  • 💡AIワンポイント

    結果の局所化では、AIが提案した修正の影響ファイル数を計測して判断します。影響が広いなら境界が漏れているので、先に責務分割を入れてから機能追加します。

3.6 ６つの原則②繰り返しの最小化（Minimize repetition）

  • 要旨

    同じ意味や同じ処理を何度も書かないようにする原則。1か所を変えれば、関連するところがまとめて変わる構造（DRY原則）を目指す。

  • 理由

    同じ内容があちこちにバラバラに書かれていると、「結果の局所化」が壊れてしまい、変更のたびに修正漏れや不整合（片方だけ直し忘れなど）が起きやすくなるから。

  • 結論

    コードを小さい部品に分解して整理し、共通する部分は1つにまとめて再利用する。

  • その他（手段）

    • ループ化／関数化／モジュール化で、処理を「最小の意味のかたまり」に分ける（数式の素因数分解のイメージ）。
    • よく使うパターンは、テンプレートやコード生成、ライブラリとして切り出し、コピペではなく再利用する。

  • 💡AIワンポイント

    繰り返し最小化の観点では、似たテストデータ生成をAIにまとめさせると効果が大きいです。fixtureビルダーを作れば仕様変更時の修正点が一箇所に集まります。

3.7 ６つの原則③ロジックとデータの一体化（Logic and Data together）

  • 要旨

    処理の流れ（ロジック）と、その処理が扱うデータを、できるだけ近い場所（同じ関数・同じモジュールなど）にまとめておく。

  • 理由

    実際の変更では、ロジックだけ・データだけが変わることは少なく、多くの場合「データの形」と「それをどう扱うか」がセットで変わる。離れた場所にあると、修正漏れやズレが起きやすくなるから。

  • 結論

    関連するロジックとデータを物理的に近く（コロケーション）に置き、データの近くにそのデータ用の処理を持たせる（カプセル化）ようにする。

  • その他（実践）

    • 特定のデータ型に対しては、そのデータに関するメソッド（操作）を一緒に持たせる。
    • 関連するデータとロジックの集まりを、1つのモジュールやクラスとして扱う。
    • DTO（Data Transfer Object＝データの入れ物）や生データをアプリ全体にバラまくのではなく、境界部分で専用の型や構造に変換してから内部で使う。

  • 💡AIワンポイント

    ロジックとデータの一体化として、AI生成の変換ロジックをDTO近くへ寄せます。別層に散ると仕様変更時にマッピング漏れが起きやすくなります。

3.8 ６つの原則④対称性（Symmetry）

  • 要旨

    同じ種類の処理や機能は、同じルール・同じ形で書くようにそろえる（API名／引数／抽象度などの対称性を意識する）。

  • 理由

    対称性があると、「この関数がこうなら、あっちもきっとこうだろう」と予想しやすくなり、読みやすさが一気に上がるから。

  • 結論

    パターン・命名・引数・抽象度を意図的にそろえて設計し、「例外的な書き方」をなるべく減らす。

  • その他（具体例）

    • 「追加する関数」があるなら、対になる「削除する関数」もそろえて用意する。
    • 同じグループに属する関数は、同じような引数の取り方にそろえる。
    • ある関数の中で呼ぶ関数たちの抽象度レベルをそろえる（SLAPの考え方：高いレベルの説明と低レベル詳細を混ぜない）。

  • 💡AIワンポイント

    対称性では、AI提案に add があるなら remove の契約も同時に確認します。片側だけ実装されると運用時に回復経路がなくなります。

3.9 ６つの原則⑤宣言型の表現（Declarative Expression）

  • 要旨

    コードでは、できるだけ「どうやるか」より「何をしたいか」を中心に書く（命令型より宣言型のスタイルを選ぶ）。

  • 理由

    命令型（「まずAをして、そのあとBをして…」のような書き方）は、順番・分岐・状態を頭の中で追いかけないと理解しづらい。一方、宣言型は「こういう条件を満たすデータがほしい」のように、事実そのものを読む感覚で理解しやすいから。

  • 結論

    使える場面では積極的に宣言的な記述やデータ駆動（設定で動作を変えるスタイル）を取り入れ、意図が一目で分かるコードを目指す。

  • その他（手段）

    • アノテーション（属性・メタ情報）で設定をつけて、コードから離れた場所にルールをまとめる。
    • 特定の問題領域に特化したDSL（domain-specific language＝ドメイン特化言語）で、「何がしたいか」を短い記述で表す。
    • if文だらけのコードではなく、設定ファイルやテーブルに条件と結果をまとめるデータ駆動設計を使う。

  • 💡AIワンポイント

    宣言型を活かすなら、AIに分岐ロジックをルールテーブルへ落とさせます。if連鎖より設定差分でレビューできる形の方が誤りを見つけやすいです。

3.10 ６つの原則⑥変更頻度（Rate of Change）

  • 要旨

    「なぜ変えるのか（変更理由）」と「どのタイミングで変わるのか」が同じもの同士を、同じ場所に集めておくという考え方。

  • 理由

    1つのモジュールが、いくつも違う理由でしょっちゅう変更されていると、そのモジュールは壊れやすく、設計も分かりづらいものになっていくから。

  • 結論

    単一責任の原則（1モジュール＝1つの変更理由）に従って配置し、モジュール同士はできるだけ疎結合に保つことで、「何のためのモジュールか」を明確にする。

  • その他（実践・効果）

    • 実践：
      • 頻繁に変わる部分（例：画面や文言）と、あまり変わらない部分（例：ドメインルール）を別レイヤーに分ける。
      • 設定値・定数・メッセージなど「一括で変えたいもの」は、専用の場所に集約する。
    • 効果：同じファイルを複数人で編集して衝突することが減る／どこを直せばいいか分かりやすい／変更にかかる時間を見積もりやすくなる。

  • 💡AIワンポイント

    変更頻度で分けるなら、AIに直近で頻繁に変わる設定値をコード外へ退避させます。毎回リリースが必要な設計は、運用負荷の増幅点になります。

プリンシプル オブ プログラミング(第３章－プログラミングセオリー)

1. 【3.2．３つの価値①『コミュニケーション』①】
プログラミングにおける「コードの本質」として、最も適切なのはどれか？

2. 【3.4．３つの価値③『柔軟性』⑤】
次のうち、**柔軟性の低いコード**の特徴として最も適切なものはどれか？

3. 【3.1．プログラミングセオリー⑨】
「構造や命名に一貫性を持たせる」ことで得られるのは？

4. 【3.5．６つの原則①『結果の局所化』⑤】
結果の局所化を高めるための有効な方法として最も適切なものはどれか？

5. 【3.10．６つの原則⑥『変更頻度』⑤】
『変更理由がひとつに絞られているモジュール』の特徴として**最も適切なもの**はどれか？

6. 【3.9．６つの原則⑤『宣言型の表現』⑤】
宣言型のコードが有効とされる**主な理由**はどれか？

7. 【3.10．６つの原則⑥『変更頻度』①】
『変更頻度』の原則に最も合致する設計方針はどれか？

8. 【3.1．プログラミングセオリー⑥】
「副作用の影響範囲を最小限に抑える」原則はどれか？

9. 【3.3．３つの価値②『シンプル』①】
プログラミングにおいて「シンプルなコード」とは、どのような状態を指すか？

10. 【3.6．６つの原則②『繰り返しの最小化』③】
『繰り返しの最小化』を実現するために**適切でない**手法はどれか？

次のクイズ(3-2：AI共創の土台、10の設計技法クイズ！)へ

プログラミングセオリー
採点結果

正答率：0%

-

-

参考文献・出典

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

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

このページの著者

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

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

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

得意：PHP・JavaScript・MySQL・CSS

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

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

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

もちもちみかん.comとは


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

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