『プリンシプル オブ プログラミング』プログラミングセオリーを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.1．プログラミングセオリー⑥】
「副作用の影響範囲を最小限に抑える」原則はどれか？

3. 【3.10．６つの原則⑥『変更頻度』④】
以下の設計方針のうち、『変更頻度』の原則を**守っている**ものはどれか？

4. 【3.4．３つの価値③『柔軟性』②】
柔軟性のあるコードを設計する上で**特に意識すべき原則**はどれか？

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

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

7. 【3.6．６つの原則②『繰り返しの最小化』②】
コードの繰り返しが多いと、どの原則の実現が困難になるか？

8. 【3.3．３つの価値②『シンプル』④】
次のうち、**シンプルさを損なう行動**として最も当てはまるものはどれか？

9. 【3.3．３つの価値②『シンプル』②】
コードのシンプルさが重要とされる**主な理由**はどれか？

10. 【3.5．６つの原則①『結果の局所化』④】
結果の局所化が実現されたコードの特徴として**適切でないもの**はどれか？

次のクイズ(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
と言ったジェネレーターを用意してます。

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