6つの非機能要件をクイズで学ぶ！
「アーキテクチャ非機能要件」要約＆クイズ

要旨

理由

結論

その他（範囲・観点・実践）

• 主要な観点（例）
  • 変更容易性（Changeability）…直しやすさ・変えやすさ。
  • 相互運用性（Interoperability）…他システムとつながりやすいか。
  • 効率性（Efficiency）…速さとリソース（CPU・メモリなど）の使い方。
  • 信頼性（Reliability）…トラブルがあってもちゃんと動き続けるか。
  • テスト容易性（Testability）…テストしやすい構造になっているか。
  • 再利用性（Reusability）…作ったものを別の場面でも使い回せるか。
• プロセスとしての扱い方
  • 要件定義：各観点について「どのくらい必要か」という必要水準を関係者で合意する。
  • 設計：その水準を満たすための構造（境界・分離・標準化・冗長化など）を具体的な形に落とし込む。
  • テスト：非機能テストの合格ラインを数値や条件で決め、「どう実現されているか（How）」に注目して検証する。
• セキュリティ（CIA の３つ）
  • 機密性 (Confidentiality)：見ていい人以外には情報が見えないようにすること（アクセス制御・暗号化など）。
  • 完全性 (Integrity)：データが勝手に書き換えられたり、壊れたりしていないことを守ること（改ざん検知・署名など）。
  • 可用性 (Availability)：必要なときにちゃんとシステムが使える状態を保つこと（冗長化・攻撃対策など）。
• 検証・運用上のポイント
  • 必要に応じてペネトレーションテスト（疑似攻撃による診断）を実施し、弱点を洗い出す（外部専門家に依頼するケースも多い）。
  • セキュリティ強化と同時に、利便性とのバランスも意識する（パスワード入力を増やしすぎてユーザー体験を壊さない、など）。

要旨

理由

結論

その他（観点別の設計指針）

• 保守性

  • 変更の影響が局所で済むようにする（影響範囲の封じ込め）。
  • モジュールの境界やインターフェースをはっきりさせ、テストもその境界ごとに用意しておく。

• 拡張性

  • クライアント側をほとんど変えずに、モジュールを差し替え・追加できるようにする（OCP・DI・プラグイン構造など）。

• 再構築性

  • 具体的な実装に依存しすぎないようにし、システム構成を柔軟に組み替えられるようにする（レイヤ分離・設定ファイルやコードで構成管理など）。

• 移植性

  • プラットフォーム依存の部分（OS・ハード・UI・特定APIなど）を専用モジュールにまとめて隔離し、他の部分からは直接触らないようにする。

その他（劣化対策）

• ソフトウェアも時間が経つと複雑さがたまりやすく、経年劣化（ソフトウェアエージング）を起こす。
• これを遅らせるために、以下を意識する
  • 正確で更新され続けるドキュメント。
  • アーキテクチャを壊さないようにする変更ルール。
  • きちんとしたコードレビュー文化。
  • 「どこがよく変わりそうか」を予測し、それに合わせた柔軟な設計。

要旨

理由

結論

その他（実践・効果）

• APIは契約ベースで設計し、OpenAPIやGraphQLのスキーマなどで仕様を明文化し、バージョン管理する。
• データ交換には JSON / Avro / Protobuf などの標準フォーマットを使い、必要なら「互換レイヤ（変換層）」を用意して、相手の仕様が変わっても対応しやすくする。
• 効果：機能の再利用がしやすくなり、新しいサービスとの連携も簡単になる。結果として、自前で全部作らずに済み、開発・運用コストを抑えやすくなる。

要旨

理由

結論

その他（範囲・指標・設計の勘所）

• 時間効率性

  • スループット：一定時間あたりにどれだけ処理できるか。
  • レスポンスタイム：リクエストしてから応答が返るまでの時間。
  • ターンアラウンドタイム：処理の依頼から結果が得られるまでの全体時間。

• 資源効率性

  • CPU使用率・メモリ消費・ディスクI/O・ネットワーク帯域などを計測・監視し、ボトルネックを見つけて改善する。

• 間接化の活用

  • キャッシュ層を挟んで、同じデータへのアクセスを減らす。
  • キューを挟んで、負荷の波をならす（バーストを直接本体にぶつけない）。
  • アダプタや抽象レイヤを挟んで、実装の差し替えを簡単にする。
  • 「レイヤを一段深くするだけで解決できる問題」も多いことを覚えておく。

要旨

理由

結論

その他（範囲・手当）

• フォールトトレランス

  • 障害やエラーが起きても、できる限りサービスを継続できるようにする。
  • 例：トランザクションのロールバック、リトライ処理、多重化（2系統で動かす）など。

• ロバストネス

  • 不正な入力や予期しない操作があっても、システムがおかしな状態に落ちないようにする（安全なデフォルト状態へ戻すなど）。

• 設計パターンの例

  • サーキットブレーカ：連続エラー時は一時的に呼び出しを遮断して被害を広げない。
  • タイムアウト：返答がない相手をいつまでも待たずに区切りをつける。
  • アイソレーション：問題のある部分を他から切り離し、連鎖障害を防ぐ。
  • 優先度制御：重要な処理を優先し、軽い処理は後回しにするなどの制御。

要旨

理由

結論

その他（設計・検証の要点）

• 依存の注入（DI）

  • 外部サービス・DB・時刻・乱数などを直接呼ぶのではなく、インターフェース経由で注入できるようにしておく。
  • モックやスタブに差し替えられるようにし、テストで環境を再現しやすくする。
  • 小さな純粋関数（入力→出力がはっきりした関数）を増やすと、テストが楽になる。

• 観測性（Observability）

  • ログ・メトリクス（数値で見る指標）・トレース（処理の流れの記録）などを通して、「中で何が起きているか」をあとから追いかけられるようにする。
  • テストや障害調査のときに、原因を特定しやすくなる。

• テスト戦略

  • ユニットテストを中心としたテストピラミッドを意識し、E2E（エンドツーエンド）テスト（端から端まで）だけに頼らない。
  • インターフェースやAPIについては、契約テストで「約束どおりの振る舞い」を確認する。
  • E2E（エンドツーエンド）テストは数を絞りつつ、ユーザーにとって重要なシナリオをカバーするようにする。

要旨

理由

結論

その他（３の法則・実践）

• 難易度３倍の法則

  • 特定の1つの用途のためだけに書くコードよりも、「いろいろな場面で使い回せる部品」を設計する方が、ざっくり3倍は難しいと考えておく（抽象度・境界・拡張方法などをよく考える必要がある）。

• テスト３種類の法則

  • 共通部品にする前に、少なくとも３つくらい違うプロダクトや状況で試しに使ってみると、「本当に汎用的に使える形になっているか」が見えてくる。

• 実践のポイント

  • APIやデータ形式を標準化し、セマンティックバージョニング（意味的なバージョン管理）などでバージョンをわかりやすく管理する。
  • READMEや使用例を用意し、「どう使えばよいか」「どこに注意すべきか」を明示する。
  • 後方互換性ポリシーを決め、利用者が安心してアップデートできるようにする。
  • 大きすぎず小さすぎないちょうどよい粒度でパッケージ化し、「この単位で使うと便利」という境界を意識する。