1. 【3.12．アーキテクチャ根底技法①『抽象』⑤】
抽象によって設計がうまく整理されている状態として**最も適切なもの**はどれか？
解説： 抽象がうまく設計されていれば、複数の実装に依存せず、共通化されたインターフェースやルールをもとに統一的に扱える。
設計の10の技法をクイズで学ぶ！
「アーキテクチャ根底技法」要約＆クイズ
公開日：
最終更新日：
本ページでは、安定したソフトウェアを支えるアーキテクチャの根底技法について、要点要約で解説します。技術選定やフレームワークに依存しない、普遍的な設計の土台を学びましょう。
要約で技法の概念をインプットし、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.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.12．アーキテクチャ根底技法①『抽象』⑤】
2. 【3.18．アーキテクチャ根底技法⑦『ポリシーと実装の分離』②】
『ポリシーと実装の分離』を行う**最大の目的**として最も適切なものはどれか？
解説： ポリシーと実装を分離することで、**頻繁に変化する方針（ポリシー）と、汎用的な処理本体（実装）**の影響範囲を分けられ、結果として保守性・再利用性が高まる。
3. 【3.21．アーキテクチャ根底技法⑩『分割統治』⑤】
以下の戦略のうち、『分割統治』の考え方に**最も合致するもの**はどれか？
解説： 「外堀から埋める」ように段階的に構築する戦略は、**『分割統治』の代表的な実践例**である。全体を一気に構築するよりも効果的である。
4. 【3.20．アーキテクチャ根底技法⑨『参照の一点性』④】
関数の**「参照透過性」**とは何を意味するか？
解説： 『参照透過性』とは、**引数だけに依存し、同じ引数に対して常に同じ出力を返す性質**を意味する。副作用がなく、テストしやすくなる。
5. 【3.13．アーキテクチャ根底技法②『カプセル化』⑤】
カプセル化を適切に行うことで得られる**設計上の効果**として最も適切なものはどれか？
解説： カプセル化されたモジュールは、内部の実装が他から隔離されているため、変更が外部に波及しづらくなり、保守性が向上する。
6. 【アーキテクチャ根底技法⑨】
『参照の一点性』の原則が保たれていない場合に起こりやすい問題はどれか？
解説： 『参照の一点性』とは、同じ情報を複数箇所に持たず、1か所に集約することで、変更や参照のミスを防ぎ、整合性を維持するための設計原則である。
7. 【3.16．アーキテクチャ根底技法⑤『関心の分離②】
『Model-View-Controller（MVC）』パターンは、どのアーキテクチャ技法の代表例とされるか？
解説： MVCは「モデル（データ）」「ビュー（表示）」「コントローラー（制御）」という異なる関心を分離して実装する、典型的な『関心の分離』の設計例である。
8. 【3.13．アーキテクチャ根底技法②『カプセル化』③】
次の例のうち、『カプセル化』の考え方に**最も近いもの**はどれか？
解説： クラスにおけるカプセル化の代表的な実装は、内部の状態や処理を隠蔽し、必要最小限のインターフェースだけを外部に提供するというもの。
9. 【3.20．アーキテクチャ根底技法⑨『参照の一点性』⑥】
本文中の「参照透過性」を最も適切に説明しているものはどれか？
解説： 参照透過性とは、(1) 呼び出し結果が引数のみに依存し、(2) 呼び出しが副作用によって他の処理に影響を与えない性質。単一代入・不変化はこの性質を支え、予測可能性とテスト容易性を高める。
10. 【アーキテクチャ根底技法⑦】
『ポリシーと実装の分離』の説明として最も正しいものはどれか？
解説： 『ポリシーと実装の分離』とは、方針（ルール・戦略）と、それを実現する手段（コード）を分けることで、柔軟で拡張可能な設計を目指す技法である。
参考文献・出典
- プリンシプル オブ プログラミング ～3年目までに身につけたい一生役立つ101の原理原則～
- 上田 勲（著）／秀和システム／第1版14刷／2025年／ISBN978-4-7980-4614-3
※本ページは学習支援を目的とした要約です。実務適用時は原典もご参照ください。
このページの著者
もちもちみかん（システムエンジニア）
社内SEとしてグループ企業向けの業務アプリを要件定義〜運用まで一気通貫で担当しています。
経験：Webアプリ／業務システム
得意：PHP・JavaScript・MySQL・CSS
個人実績：フォーム生成基盤／クイズ学習プラットフォーム 等
詳しいプロフィールはこちら！ もちもちみかんのプロフィール
