もちもちみかん0系くん
『プリンシプル オブ プログラミング』アーキテクチャ非機能要件を20問で学べるクイズサイト

プリンシプル オブ プログラミング
アーキテクチャ非機能要件 要約＆クイズ

公開日：
最終更新日：

システムの性能、セキュリティ、保守性など、「非機能要件」はアーキテクチャの品質を決定づけます。本ページでは、この非機能要件の要点を要約で整理します。

要約で要件の基本を習得し、20問のクイズで定着。システムの安定稼働と拡張性を考慮したプロの設計思考を確立しましょう！

今すぐクイズに挑戦
（20問・約5分・解説つき）
プリンシプルオブプログラミング
101の原理・原則を読む

目次

  1. アーキテクチャ非機能要件の要点・要約を読む(3分)
    1. 3.22 アーキテクチャ非機能要件（Architecture quality attributes）
    2. 3.23 変更容易性（Changeability）
    3. 3.24 相互運用性（Interoperability）
    4. 3.25 効率性（Efficiency）
    5. 3.26 信頼性（Reliability）
    6. 3.27 テスト容易性（Testability）
    7. 3.28 再利用性（Reusability）
  2. クイズに挑戦する(20問)
  1. クイズ一覧へ
  2. 第３章目次へ
  3. 次のクイズへ(7つの設計原理)
  4. 前のクイズへ(アーキテクチャ根底技法)
  5. 『プリンシプル オブ プログラミング』101の原理・原則総まとめ
  1. 参考文献・出典
  2. このページの著者
  3. シェア

第３章：思想③
～アーキテクチャ非機能要件～

3.22 アーキテクチャ非機能要件（Architecture quality attributes）

  • 要旨：機能以外の品質（非機能）は、アーキテクチャ設計で機能と同等に重視すべき領域。
  • 理由：非機能は運用・保守・拡張のコストとリスクを左右し、プロダクト価値の持続性を決めるため。
  • 結論：非機能観点で設計し、要件定義→設計→テストの各段で合格基準を明確化・検証する。
  • その他（範囲・観点・実践）：
    • 主要観点：
      • 変更容易性（Changeability）
      • 相互運用性（Interoperability）
      • 効率性（Efficiency）
      • 信頼性（Reliability）
      • テスト容易性（Testability）
      • 再利用性（Reusability）
    • プロセス：
      • 要件定義：各観点の必要水準を合意。
      • 設計：非機能を満たす構造（境界・分離・標準化・冗長化等）を具体化。
      • テスト：非機能テストの合格基準を設定し「How」に着目して検証。
    • セキュリティ（CIA）：
      • 機密性(Confidentiality)：未認可主体に情報を非公開（アクセス制御・暗号化）。
      • 完全性(Integrity)：資産の正確性と完全さを保護（改ざん検知・署名）。
      • 可用性(Availability)：要求時に使用可能（冗長化・ウイルス/攻撃対策）。
    • 検証・運用上の要点：
      • ペネトレーションテストの実施（必要に応じ外部診断の活用）。
      • 利便性とのバランス：過度なパスワード要求等でUXを損なわない設計。

3.23 アーキテクチャ非機能要件①：変更容易性（Changeability）

  • 要旨：修正・拡張・再構成・移植を素早く安全に行える能力。
  • 理由：ソフトウェアは長寿命で変化対応が常態。迅速な要望反映と品質維持に直結するため。
  • 結論：設計を保守性／拡張性／再構築性／移植性の観点で評価・最適化する。
  • その他（観点別の設計指針）：
    • 保守性：変更の局所化、副作用の最小化（境界/インターフェース、テスト境界）。
    • 拡張性：クライアント非影響でモジュール交換可能（OCP、DI、プラグイン化）。
    • 再構築性：実装非依存の柔軟配置（レイヤ分離、構成の宣言化/コード化）。
    • 移植性：プラットフォーム依存部の隔離（HW/OS/UI/システムAPIを専用モジュールに集約）。
  • その他（劣化対策）：
    • ソフトウェアエージング(経年劣化)を前提に、正確なドキュメント、アーキテクチャ破壊を避ける変更規律、真摯なレビュー、変更予測に基づく柔軟設計で劣化速度を低減。

3.24 アーキテクチャ非機能要件②：相互運用性（Interoperability）

  • 要旨：他システムとやり取りできる能力（機能連携・データ連携）。
  • 理由：ソフトウェアは大きなシステムの一部。高い相互運用性は用途拡大・期間短縮・コスト削減につながるため。
  • 結論：外部機能/データへのアクセス仕様を明確化し、業界標準のプロトコル・データ形式を採用する。
  • その他（実践・効果）：
    • 契約ベースのAPI設計（OpenAPI/GraphQLスキーマ等）、スキーマとバージョニングの管理。
    • データ交換は標準フォーマット（JSON/Avro/Protobuf等）と互換層で互換性を確保。
    • 効果：再利用性と拡張性の向上、内製範囲の縮小、異種環境との連携容易化。

3.25 アーキテクチャ非機能要件③：効率性（Efficiency）

  • 要旨：限られたリソースで適切な性能を引き出す能力（時間効率性＋資源効率性）。
  • 理由：リソースは有限。無駄なく使い切る設計が、体感性能・運用コストの両方を左右するため。
  • 結論：節約（ムダ削減）と拡張（スケールさせる）の両輪で設計し、必要に応じて間接化を導入して疎結合・保守性・再利用性を確保する。
  • その他（範囲・指標・設計の勘所）：
    • 時間効率性：スループット／レスポンスタイム／ターンアラウンドタイムを計測・目標化。
    • 資源効率性：CPU時間・メモリ・ストレージ・ネットワークを監視・最適化。
    • 間接化の活用：キャッシュ層、キュー、アダプタ、抽象化（「レイヤを一段深く」で解ける問題は多い）。

3.26 アーキテクチャ非機能要件④：信頼性（Reliability）

  • 要旨：例外・不正利用・異常系でも機能を維持できる能力（フォールトトレランス＋ロバストネス）。
  • 理由：現実の運用では障害も誤操作も避けられず、異常時の設計が可用性と安全性を決めるため。
  • 結論：冗長化／フェールソフト／フェールセーフを設計原則に据え、可能ならフールプルーフで誤操作自体を無害化する。
  • その他（範囲・手当）：
    • フォールトトレランス：例外時も正しい振る舞いを保証（ロールバック、再試行、二重化）。
    • ロバストネス：不正入力や誤操作時に定義状態へ退避（安全側へ遷移）。
    • 設計パターン：サーキットブレーカ／タイムアウト／アイソレーション／優先度制御。

3.27 アーキテクチャ非機能要件⑤：テスト容易性（Testability）

  • 要旨：ソフトウェアを効果的・効率的に検証できる能力（設計段階からテストを織り込む）。
  • 理由：正しく動くことに加え、容易に確かめられる構造が品質と開発速度を支えるため。
  • 結論：本体にテスト容易化の構造（依存の分離、インターフェース化、観測性）を組み込み、必要なら本番コード内のテスト支援も許容する。
  • その他（設計・検証の要点）：
    • 依存の注入（DI）、テストシーム、モック可能なインターフェース、純粋関数の活用。
    • 観測性：ログ／メトリクス／トレースで原因追跡を容易に。
    • テスト戦略：ピラミッド（ユニット中心）／契約テスト／E2Eは最小限で価値最大化。

3.28 アーキテクチャ非機能要件⑥：再利用性（Reusability）

  • 要旨：「する」と「される」の両面で再利用を最大化し、作らないことで品質と速度を上げる。
  • 理由：既知の解の活用はリードタイム短縮と欠陥低減に直結。一方、汎用部品化には固有の難しさがあるため。
  • 結論：３の法則を指針に汎用化し、APIの安定化・ドキュメント・バージョニングで採用性を高める。
  • その他（３の法則・実践）：
    • 難易度３倍の法則：再利用可能部品の設計は単用途の３倍難しい（一般化と境界設計が必要）。
    • テスト３種類の法則：共通化前に３つの異なるプロダクトで実地検証。
    • 実践：標準化（API/スキーマ）、セマンティックバージョニング、README/使用例、互換ポリシー、適正な粒度のパッケージ化。

プリンシプル オブ プログラミング(第３章－アーキテクチャ非機能要件)

1. 【3.22．アーキテクチャ非機能要件⑤】
『ペネトレーションテスト（侵入テスト）』に関して正しい記述はどれか？

2. 【3.23．アーキテクチャ非機能要件①『変更容易性』④】
『ソフトウェアエージング』の説明として最も適切なものはどれか？

3. 【3.26．アーキテクチャ非機能要件④『信頼性』⑥】
次のシナリオのうち「フェールセーフ」を最も適切に表しているものはどれか？

4. 【3.25．アーキテクチャ非機能要件③『効率性』③】
次のうち、効率性向上のための設計視点として**不適切なもの**はどれか？

5. 【3.23．アーキテクチャ非機能要件①『変更容易性』⑤】
『変更容易性』を高める具体的な設計として**最も適切なもの**はどれか？

6. 【3.28．アーキテクチャ非機能要件⑥『再利用性』①】
『再利用性』の重要性として最も適切な説明はどれか？

7. 【3.22．アーキテクチャ非機能要件⑥】
『非機能要件』の「再利用性」を高める設計として最も適切なのはどれか？

8. 【3.26．アーキテクチャ非機能要件④『信頼性』⑤】
「確認ダイアログで操作ミスを防ぐ」設計は、次のうちどの考え方に該当するか？

9. 【3.22．アーキテクチャ非機能要件⑦】
『セキュリティと利便性』のバランスとして**不適切な設計判断**はどれか？

10. 【3.25．アーキテクチャ非機能要件③『効率性』④】
「間接化（Indirection）」の設計技法に**該当するもの**はどれか？

11. 【3.22．アーキテクチャ非機能要件①】
『非機能要件』に該当するものとして最も適切なのはどれか？

12. 【3.26．アーキテクチャ非機能要件④『信頼性』①】
アーキテクチャにおける『信頼性』の説明として最も適切なものはどれか？

13. 【3.25．アーキテクチャ非機能要件③『効率性』①】
アーキテクチャにおける『効率性』の定義として最も適切なものはどれか？

14. 【3.27．アーキテクチャ非機能要件⑤『テスト容易性』④】
『テスト容易性』を高める目的として**最も適切な説明**はどれか？

15. 【3.27．アーキテクチャ非機能要件⑤『テスト容易性』⑤】
次のうち、『テスト容易性』を意識した設計の一例として最も適切なのはどれか？

16. 【3.23．アーキテクチャ非機能要件①『変更容易性』③】
『移植性』を高める設計方針として**最も適切なもの**はどれか？

17. 【3.22．アーキテクチャ非機能要件④】
『セキュリティ要件』に含まれるCIAのうち、「Integrity」に対応する説明はどれか？

18. 【3.26．アーキテクチャ非機能要件④『信頼性』②】
フォールトトレランスの具体例として**最も適切なもの**はどれか？

19. 【3.26．アーキテクチャ非機能要件④『信頼性』④】
次のうち「フェールソフト（Fail Soft）」の考え方に最も近いものはどれか？

20. 【3.23．アーキテクチャ非機能要件①『変更容易性』②】
『変更容易性』の観点として**適切でないもの**はどれか？

アーキテクチャ非機能要件の要約を読む クイズ一覧へ

参考文献・出典

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

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

このページの著者

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

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

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

得意：PHP・JavaScript・MySQL・CSS

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


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

採点結果

正答率：0%

-

-
TOPへ

もちもちみかん.comとは


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

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