設計品質とは？要求と制約から良い設計を判断する考え方

はじめに

高凝集・低結合にする、デザインパターンを使う、設計書を詳しく書く。これらは設計を改善する手段ですが、実施しただけで設計品質が高いとは判断できません。

設計の良し悪しは、求められる機能や品質、予算や納期、既存環境などの条件に照らして判断します。この記事では、設計品質の意味と、設計を評価するための基本的な観点を解説します。

設計品質とは、設計上の判断が要求と制約に適合し、必要な機能と品質を実現できる度合いです。責務、依存関係、データの流れ、異常時の扱いなどが整理され、実装・テスト・変更・運用へつながる状態を目指します。

設計品質は、クラス数、設計書のページ数、原則やパターンの利用数では決まりません。同じ構造でも、短期間だけ使う社内ツールと、24時間停止できない決済システムでは、必要な品質と許容できるコストが異なります。

評価の前提となるのは、「何を実現するか」と「どのような品質で実現するか」です。詳しくは、機能要件と非機能要件の違いとは？システム設計で重要な考え方をわかりやすく解説で説明しています。

用語の範囲は組織によって異なりますが、本記事では次のように整理します。

三つは独立しているわけではありません。要求を設計へ変換し、コードとして実装し、稼働結果で確かめる関係にあります。

設計は、必要な機能と品質を実現し、前提となる制約に反していない必要があります。利用者数、応答時間、権限、外部システムとの接続条件、予算、納期、既存環境など、何を実現するための設計なのかを基準に評価します。

各処理が何を担当し、どこへ依存し、データがどのように受け渡されるかを説明できる必要があります。構造を選んだ理由を要求や制約と結び付けられれば、担当者の好みではなく、設計判断として議論できます。

業務ルールと外部技術の責務を分け、ソースコード上の依存方向を整理する具体的な考え方としてクリーンアーキテクチャがあります。目的と適用時の注意点は、「クリーンアーキテクチャとは？業務ルールを外部技術から分離する設計の考え方」で解説しています。

仕様変更でどこを修正し、どこまで確認するか、障害時にどの処理と情報を調査するかを追跡できることも重要です。凝集度と結合度は、この観点を確認する判断材料になります。詳しくは、凝集度と結合度の違い｜高凝集・低結合が望ましい理由と判断方法を参照してください。

設計内容は、後続工程で利用できる具体性を持つ必要があります。「権限に応じて表示する」だけでなく権限ごとの閲覧範囲を決め、「高速に検索する」だけでなく対象データ量、応答時間、測定条件を決めます。

詳細なログは障害調査をしやすくしますが、保存容量や機密情報の管理が必要です。細かな権限制御は安全性を高める一方で、設定と運用を複雑にします。抽象化は変更を分離できますが、理解する構造が増えます。

重要なのは、すべての品質を一律に高めることではありません。目的と制約から優先順位を決め、その選択理由を説明できることです。詳しくは、設計とは、何を優先するかを決める仕事であるで解説しています。

注文履歴を検索する機能を例に、要求と設計判断、確認方法を対応させます。