1. 【3.16．アーキテクチャ根底技法⑤『関心の分離④】
次のうち、『関心の分離』の考え方に**最も反する**設計はどれか？
解説： UIとロジックを分離しない設計は、関心の分離の原則に反し、保守や再利用を困難にする原因となる。
設計の10の技法をクイズで学ぶ！
「アーキテクチャ根底技法」要約＆クイズ
公開日：
最終更新日：
本ページでは、『プリンシプル オブ プログラミング』第3章「アーキテクチャ根底技法」で紹介される、アーキテクチャ設計の土台となる10の設計技法について、要点を押さえた要約と4択クイズで整理します。
要約で各技法のねらいと使いどころをつかみ → 4択クイズ（10問・全問解説付き）で理解度をチェック → 気になった部分は解説で復習。「読む→解く→わかる」のサイクルで、アーキテクチャ設計で迷ったときに頼れる10の技法をしっかり身につけていきましょう！
3-2.設計の10の技法をクイズで学ぶ！ 目次
-
3-2.設計の10の技法をクイズで学ぶ！の要点・要約を読む(5分)
- 3.11 アーキテクチャ根底技法（Architecture core techniques）
- 3.12 抽象（abstraction）
- 3.13 カプセル化（Encapsulation）
- 3.14 情報隠蔽（Information Hiding）
- 3.15 パッケージ化（Packaging）
- 3.16 関心の分離（Separation of Concerns）
- 3.17 充足性・完全性・プリミティブ性（Sufficiency / Completeness / Primitiveness）
- 3.18 ポリシーと実装の分離（Separation of Policy and Implementation）
- 3.19 インターフェースと実装の分離（Separation of Interface and Implementation）
- 3.20 参照の一点性（Single Point of Reference）
- 3.21 分割統治（Divide and Conquer）
- クイズに挑戦する(10問)
- プログラミング クイズ一覧へ
- 第3章：思想とセオリーの全体像をつかむ！ 目次へ
- 次のクイズへ(3-3.6つの非機能要件をクイズで学ぶ！)
- 前のクイズへ(3-1.設計セオリーをクイズで定着！)
- 『プリンシプル オブ プログラミング』101の原理・原則総まとめ
第３章：思想②
～アーキテクチャ根底技法～
3.11 アーキテクチャ根底技法（Architecture core techniques）
要旨
良いコードや設計を支える土台となる考え方（基礎原理のセット）をチームで共有し、どんな場面でも迷いにくい共通の判断基準にする。理由
この基礎原理を共有しておくと、誰が設計しても、複雑さのコントロール・再利用のしやすさ・変更のしやすさに一貫性が生まれ、プロダクト（製品）全体の質がそろいやすくなるから。結論
これらの原理を、プロダクト（製品）共通のチェックリストとして扱い、設計やコードレビューのときに「ちゃんと守れているか？」を確認する道具として使う。その他（基礎原理リスト）
- 抽象（abstraction）…本質だけを取り出して「分かりやすい概念」にまとめる。
- カプセル化（Encapsulation）…関連するデータと処理を1つのまとまりとして包む。
- 情報隠蔽（Information Hiding）…中身の細かい構造は隠し、外側には最小限の情報だけ見せる。
- パッケージ化（Packaging）…モジュールを意味ごとにグループ分けし、整理する。
- 関心の分離（Separation of Concerns）…役割ごとにコードを分け、混ざらないようにする。
- 充足性、完全性、プリミティブ性（Sufficiency, Completeness, Primitiveness）…「十分・漏れなし・純粋」な抽象にする。
- ポリシーと実装の分離（Separation of Policy and Implementation）…「何をするか」と「どうやるか」を分ける。
- インターフェースと実装の分離（Separation of Interface and Implementation）…「使い方」と「中身」を分ける。
- 参照の一点性（Single Point of Reference）…同じことは1か所で定義し、何度も書かない。
- 分割統治（Divide and Conquer）…大きな問題を小さく分割してから解いていく。
3.12 アーキテクチャ根底技法①抽象（abstraction）
要旨
ごちゃごちゃした現実から、共通して大事な部分だけを取り出して「1つの概念」としてまとめること。これにより、モジュール同士の役割や境界をはっきり区別できる。理由
良い抽象は、ムダな情報をそぎ落としつつ、使いやすい形にまとまっているので、いろいろな場面で広く再利用できるし、考えるときも「この抽象として捉えればいい」となり、思考がスッキリするから。結論
本質に関係ない細かさは思い切って捨て（捨象）、抽象の境界に対して分かりやすい名前と契約（どう振る舞うべきか）を与える。その他（実践）
- 「捨てる勇気」を持つ：めったに使わない特殊ケースや、細かすぎる属性・分岐は抽象から外し、共通部分に集中する。
- ドメイン（業務・問題領域）の言葉で境界に名前をつけ、抽象に対して契約テスト（「この抽象はこう振る舞うはず」というテスト）を用意しておく。
3.13 アーキテクチャ根底技法②カプセル化（Encapsulation）
要旨
強く関係しているデータとロジックを、1つのモジュールの中にまとめて包み込むこと（外側からはひとまとまりとして扱えるようにする）。理由
バラバラに置いておくと、関係ないものが紛れ込んだり、あちこちから勝手に触られたりして全体が分かりづらくなる。カプセル化しておけば、見通しがよくなり、変更の影響もそのモジュール内部に閉じ込めやすくなるから。結論
関係の強い要素（データ＋処理）を同じモジュールにグルーピングし、その中で完結するように設計することで、変更範囲と影響範囲を分かりやすくする。その他（たとえ・効果）
- 例：じゃがいも・にんじん・玉ねぎなどの材料を、その都度「カレー用」「シチュー用」とバラバラに扱うのではなく、「野菜セット」という単位でカプセル化しておけば、カレーにもシチューにも肉じゃがにも使い回しやすくなる。
- 効果：コードの見やすさ／影響範囲の局所化／変更のしやすさが向上する。
3.14 アーキテクチャ根底技法③情報隠蔽（Information Hiding）
要旨
モジュールの中身の細かいしくみはできるだけ外から見えないように隠し、外側からは最低限のインターフェースだけで扱えるようにする。理由
外から何でも見えて何でも触れてしまうと、使う側も覚えることが増え、全体のつながりが複雑になる。情報隠蔽を徹底すると、やり取りする情報がシンプルになり、システム全体の複雑さを下げられるから。結論
外に公開するのは利用に本当に必要な部分だけに絞り、実装の細部は隠しておくことで、あとから中身を変えても外側との約束（インターフェース）は守れる余地を残す。その他（指針）
- モジュールの利用者には、「どう使えばよいか」が分かる情報だけを渡し、それ以上の内部事情は見せない。
- モジュールの実装者には必要な内部情報を見せてよいが、その情報を外部に漏らさないよう設計する。
3.15 アーキテクチャ根底技法④パッケージ化（Packaging）
要旨
たくさんのモジュールを、意味のある単位でまとめてグループ化し、「この束は何を担当するのか」が分かるように整理すること。理由
モジュールが増えてくると、そのままでは「森の中で木を見ている」状態になってしまう。関連したものを1つのパッケージとして束ねると、全体像がつかみやすくなり、複雑さを下げられるから。結論
まずは小さなモジュールを作りながら、徐々に関連の強いもの同士をボトムアップに集合化してパッケージにまとめ、開発が進むにつれてパッケージ構造も成長・整理していく。その他（位置づけ）
- モジュール化…1つ1つの機能や責務に注目した、ミクロな複雑性の削減。
- パッケージ化…モジュール群をどうグループ分けするかという、マクロな複雑性の削減。
3.16 アーキテクチャ根底技法⑤関心の分離（Separation of Concerns）
要旨
「画面表示」「データ保存」「ログ」「認証」など、性質や目的が違う関心ごとを、きちんと別々のモジュールに分けておき、できるだけ混ざらないようにする。理由
実際の変更は「画面を変えたい」「保存方法を変えたい」のように、関心ごと単位で起こることが多い。あらかじめ分離しておけば、その関心に関係するところだけを直せば済むから。結論
役割が違うものはきちんと分ける（例：MVC＝Model-View-Controllerなど）。「どこにでも顔を出す共通処理」（ログ、エラー処理など）のような横断的関心事は、AOP（＝Aspect Oriented Programming）などで別枠に切り出す。その他（例）
- DBとのやり取り（永続化）／UI（見せ方）／その間をつなぐ処理（アプリケーションロジック）を分離する。
- 本体の処理と、ログや監視の処理を分離しておき、必要に応じてあとから差し込める形にしておく。
3.17 アーキテクチャ根底技法⑥充足性・完全性・プリミティブ性（Sufficiency, Completeness, Primitiveness）
要旨
モジュールが表す抽象は、充足性（やりたいことを十分に表せているか）、完全性（必要な機能に漏れがないか）、プリミティブ性（余計な合成が混じっておらず、素の操作になっているか）を満たしているべき、という考え方。理由
充足性が足りないと「やりたいことがこのモジュールでは表しきれない」状態になる。完全性が足りないと「結局ここにも別の処理を足さないといけない」となり使いづらい。プリミティブ性がないと、操作がごちゃごちゃして再利用しづらくなる。結論
モジュールの抽象を見直し、提供する関数やメソッドのセットが十分・漏れなし・純粋になっているかを確認する。余計な機能や例外的操作が混ざっている場合は、別モジュールに切り出したり削除したりして整理する。その他（判断基準の再掲）
充足性
このモジュールを使えば、その抽象がやりたいことを一通り表現できるか？完全性
本来その抽象が持つべき機能を取りこぼしていないか？プリミティブ性
操作が混ぜ込み料理のようになっていないか？もっと小さく素の操作に分けられないか？
3.18 アーキテクチャ根底技法⑦ポリシーと実装の分離（Separation of Policy and Implementation）
要旨
「ポリシー」＝ビジネスルールや前提条件にもとづいた「どの選択肢を選ぶか」という決めごと と、「実装」＝前提に依存しない汎用的な処理ロジックを、同じモジュールの中にごちゃまぜにしない。理由
ポリシー（ビジネスルール側）は状況の変化で変わりやすく、実装（一般的なロジック側）は比較的安定しやすい。ここを混ぜてしまうと、ポリシーを変えたいだけなのに実装まで巻き込まれて、再利用しづらくなり、変更も重くなるから。結論
ポリシーと実装を別々のモジュールとして切り分け、設定ファイル・DI（Dependency Injection＝依存性注入）・戦略パターンなどを使って連携させる。その他（範囲・効果）
ポリシーモジュール
前提条件・ビジネスロジック・選択ルールなどを持つ部分。実装モジュール
前提に依存しない、汎用的な処理ロジック。ポリシーは引数やインターフェースとして注入して使う。- 効果：ポリシー変更の影響を局所化できる／テストしやすくなる／他プロジェクトへの流用もしやすくなる。
3.19 アーキテクチャ根底技法⑧インターフェースと実装の分離（Separation of Interface and Implementation）
要旨
モジュールには、「インターフェース＝使い方の約束（どんなメソッドがあり、どんな引数・戻り値か）」と、「実装＝その中でどう動いているか」という2つの面がある。利用側はインターフェースだけに依存し、実装には直接依存しないようにする。理由
インターフェースと実装を分けることで、公開する面がシンプルになり、使う人にとって理解しやすくなる。また、実装は裏側で自由に改良・最適化できるので、差し替えやバージョンアップに強くなる。結論
「インターフェースに対してプログラムし、実装に対してではない」という原則を徹底する。利用側のコードから、具体クラスや中身の詳細に直接べったり依存する書き方を避ける。その他（範囲・効果）
- インターフェースは契約、実装はその契約を満たすための隠れた仕組みと考えると分かりやすい。
- テストでは、インターフェースを基準にした契約テストと、具体的な実装についてのユニットテストを組み合わせることで、安心して差し替えられる構造を作れる。
3.20 アーキテクチャ根底技法⑨参照の一点性（Single Point of Reference）
要旨
1つの情報や定義は必ず1か所だけに置き、何度もコピーして書かない。また、変数にはできるだけ一度だけ代入し、その後は変更しないようにする（単一代入）。理由
同じ情報が複数箇所にあると、どこか1つだけ更新し忘れたときに不整合やバグを生む。再代入や共有の書き換えが多いと、「いつ・どこで値が変わったのか」を追うのが大変になり、バグの温床になるから。結論
同じ意味の情報は1か所に集約し、変数の再代入を避けて、できるだけ参照透過な関数（同じ入力なら必ず同じ結果が返り、副作用がない関数）と不変なデータを中心に設計する。その他（概念整理）
単一代入
変数には一度だけ値を入れ、その後は書き換えないスタイル。値を変えたいときは、新しい変数として扱う。参照透過性
- ① 関数の戻り値が引数だけに依存して決まる（隠れた状態を使わない）。
- ② 関数を呼び出しても、他の部分の動作に副作用を与えない（グローバル変数の書き換えなどをしない）。
3.21 アーキテクチャ根底技法⑩分割統治（Divide and Conquer）
要旨
一度に解くには大きすぎて複雑な問題を、解きやすい小さな問題に分割し、それぞれを解いてから組み合わせて全体を解決する、という考え方。理由
大きな問題をそのまま眺めていても、全体が複雑すぎて最適解にたどり着きにくい。分割統治を使って、問題を小さく区切ることで、見通しがよくなり、並列作業もしやすくなり、検証もしやすくなるから。結論
問題の粒度（大きさ）を調整しながら、「ここまでなら1人で理解できる」「ここまでなら1回でテストできる」と感じるサイズまで分割し、それぞれを各個撃破してから、結果を組み合わせて全体を完成させる。その他（適用例）
- 全体設計：システム全体を、それぞれ独立して設計できる部分に分ける。
- モジュール設計：1つの巨大なクラスではなく、責任や役割ごとにモジュールを分ける。
- アルゴリズム：大きな処理を、より小さいサブ問題に分けてボトムアップに解いていく。
- 大量データ処理：データを小さい単位に分割し、分散処理や並列処理を検討する。
- 補足：「まず外側をざっくり固めてから、内側を順に細かくしていく」ようなアプローチも、分割統治の一種と考えてよい。
プリンシプル オブ プログラミング(第３章－アーキテクチャ根底技法)
1. 【3.16．アーキテクチャ根底技法⑤『関心の分離④】
2. 【3.14．アーキテクチャ根底技法③『情報隠蔽』②】
情報隠蔽を適切に行うことで得られる**主な効果**として不適切なものはどれか？
解説： 内部構造を公開しすぎると他モジュールとの結合度が高まり、再利用性・保守性が損なわれる。隠蔽により変更の影響範囲を限定できる。
3. 【3.12．アーキテクチャ根底技法①『抽象』②】
抽象設計において重要な視点である『捨象』とは何か？
解説： 『捨象』とは、抽象の過程で必要ない詳細を取り除くことであり、本質だけを見極めて設計に活かす重要なステップである。
4. 【3.13．アーキテクチャ根底技法②『カプセル化』②】
カプセル化により実現される設計上の**利点**として不適切なものはどれか？
解説： 関係のない処理を集中させるのはカプセル化の目的ではなく、逆に可読性や保守性を損なう。カプセル化は関連する処理をひとつにまとめる技法である。
5. 【3.13．アーキテクチャ根底技法②『カプセル化』④】
「じゃがいも・にんじん・たまねぎ」を素材のまま『カプセル化』することで得られるメリットとして最も適切なものはどれか？
解説： 比喩的に言えば、素材ごとに整理（カプセル化）しておくことで、再利用性・柔軟性が高まり、様々な用途に対応できる。
6. 【3.12．アーキテクチャ根底技法①『抽象』⑤】
抽象によって設計がうまく整理されている状態として**最も適切なもの**はどれか？
解説： 抽象がうまく設計されていれば、複数の実装に依存せず、共通化されたインターフェースやルールをもとに統一的に扱える。
7. 【3.20．アーキテクチャ根底技法⑨『参照の一点性』③】
次のうち、『参照の一点性』の考え方に**最も反する設計**はどれか？
解説： **変数の再代入**は『単一代入』の原則に反し、**参照透過性を損ねる原因**となるため、『参照の一点性』に反する。
8. 【3.18．アーキテクチャ根底技法⑦『ポリシーと実装の分離』④】
『ポリシーと実装が混在しているモジュール』の**リスク**として最も適切なものはどれか？
解説： ポリシーと実装が混在していると、**仕様変更のたびに汎用処理まで巻き込んで修正が必要**となり、再利用性や保守性が著しく低下する。
9. 【3.13．アーキテクチャ根底技法②『カプセル化』①】
『カプセル化』の主な目的として最も適切なものはどれか？
解説： カプセル化は、関係するデータと処理を1つのモジュールに閉じ込めることで、整理された構造・変更の影響範囲の限定・インターフェースの明確化を実現する。
10. 【3.12．アーキテクチャ根底技法①『抽象』④】
抽象設計が**うまく行われていない**場合に起こりやすい問題として適切なものはどれか？
解説： 抽象が適切に行われないと、どこで責任を分離すべきか不明瞭になり、モジュールの再利用や保守が困難になる。
参考文献・出典
- プリンシプル オブ プログラミング ～3年目までに身につけたい一生役立つ101の原理原則～
- 上田 勲（著）／秀和システム／第1版14刷／2025年／ISBN978-4-7980-4614-3
※本ページは学習支援を目的とした要約です。実務適用時は原典もご参照ください。
このページの著者
もちもちみかん（システムエンジニア）
社内SEとしてグループ企業向けの業務アプリを要件定義〜運用まで一気通貫で担当しています。
経験：Webアプリ／業務システム
得意：PHP・JavaScript・MySQL・CSS
個人実績：フォーム生成基盤／クイズ学習プラットフォーム 等
詳しいプロフィールはこちら！ もちもちみかんのプロフィール
