ソフトウェア設計における原則とは？原則の種類や主な設計図について解説

ソフトウェア設計とは、「システムをどのような構造・仕組みで作るかを事前に決める活動」のことです。建物を建てる前に設計図を作るのと同じように、ITシステムもいきなり作りはじめるのではなく、全体像や内部構造を整理し設計を固めてから開発を進めます。

経営層の視点で見ると、ソフトウェア設計は単なる技術作業ではありません。設計の良し悪しは、次のような経営課題に直結します。

・将来の機能追加にどれだけ柔軟に対応できるか
・障害発生時の影響範囲を小さくできるか
・開発コストや保守コストを抑えられるか
・特定の担当者に依存しない体制を作れるか

つまり設計は、IT投資の回収効率を左右する重要な経営要素といえるでしょう。

ソフトウェアは目に見えないため軽視されがちですが、設計が不十分なまま開発を進めると、後から機能追加がむずかしくなったり、修正のたびに不具合が発生したりします。設計時に検討が不足していると、結果として「改修のたびにコストが膨らむシステム」になってしまいます。これはいわゆる「技術的負債」の蓄積です。

一方で、設計が整理されているシステムは、

・変更に強い
・担当者が変わっても理解しやすい
・品質を保ちながらスピーディーに改善できる

といった特徴をもちます。そして、ソフトウェアの設計の良し悪しは企業の競争力にも直結します。市場環境の変化に合わせてサービスを進化させるには、「変えやすいシステム構造」が前提になるからです。

ソフトウェア設計は、大きくわけると「何を作るかを具体化する設計」と「どう作るかを技術的に決める設計」にわかれます。それが次に説明する「基本設計」と「詳細設計」です。

ここでは、「基本設計」と「詳細設計」について詳しくご説明します。

ソフトウェア設計は段階的に行われますが、特に重要なのが「基本設計」と「詳細設計」です。この2つはそれぞれ「外部設計」、「内部設計」とも呼ばれ、役割が明確に異なります。

■基本設計（外部設計）
基本設計は、要件定義で整理された業務要件をもとに、ユーザーや業務に近い視点でシステムの仕様を具体化する工程です。主に次のような内容を整理します。
・画面レイアウトや入力項目
・帳票のイメージ
・システムが提供する機能の一覧
・画面で入力された情報が、どのような業務処理につながるか
・入力内容の確認、登録、検索、更新などの基本的な処理の流れ

つまり、「利用者から見える部分」や「利用者の操作に対してシステムがどう動くか」を中心に設計する工程です。ここでは「現場で本当に使えるか」「実際の業務に合っているか」が重要になります。

なお、業務フローそのものや、どのような業務処理が必要かといった内容は、本来は要件定義で整理しておくべきものです。基本設計では、それらの要件をもとに、システム上でどのように実現するかを具体的に落とし込んでいきます。

経営層にとってのポイントは、基本設計が業務改革や生産性向上に直結する領域であることです。ここが曖昧なまま進むと、「システムはできたが業務が楽にならない」という事態が起こります。

■詳細設計（内部設計）
詳細設計は、基本設計で決めた仕様を、実際に開発できるレベルまで技術的に具体化する工程です。たとえば以下のような内容を定義します。
・処理のアルゴリズム
・機能をどの単位で関数やメソッドに分割するか
・クラスやモジュールの構成
・データの保持方法や内部的な受け渡し方
・プログラム同士の連携方法
・例外処理やエラー制御の考え方

こちらは主にエンジニア向けの設計ですが、経営的にも無関係ではありません。詳細設計が整理されていないと、以下のような問題が起きやすくなります。

・小さな改修でも大きな影響が出る
・バグが多発する
・保守に時間がかかりコストが増える

詳細設計の質は「システムの保守費用」に直結するため、非常に重要な工程です。

ここまでご説明したとおり、要件定義で業務上の目的や必要な処理を整理し、基本設計でユーザーから見える仕様や処理の流れを固め、詳細設計で実装方法を具体化していきます。この流れが整理されてはじめて、企業にとって価値のあるITシステムになります。

設計は開発工程の一部ではありますが、実際にはシステムの寿命とコスト構造を決める最重要フェーズといえるでしょう。

ソフトウェア設計には、経験則から体系化された「原則」があります。これらは単なる技術ルールではなく、将来の変更コストを抑え、品質を安定させるための考え方です。

経営層にとって重要なのは、これらの原則が守られているかどうかで、

・開発スピード
・障害発生率
・保守コスト
・外部ベンダーへの依存度

などが大きく変わる点です。原則に沿って設計されたシステムは「変えやすく壊れにくい」構造になり、事業環境の変化に強くなります。

ここでは代表的な設計原則についてご紹介します。

SOLID原則とは、オブジェクト指向設計における以下の5つの基本原則の頭文字を取ったものです。

・単一責任の原則 (Single-Responsibility Principle)
・オープン・クローズド（開放・閉鎖）の原則 (Open/Closed Principle)
・リスコフの置換原則 (Liskov Substitution Principle)
・インターフェース分離の原則 (Interface Segregation Principle)
・依存性逆転の原則 (Dependency Inversion Principle)

これら原則は、システムを整理された構造に保ち、変更に強くするための基礎ルールといえます。

ここでは、5つのSOLID原則について解説します。

関数やクラスなどのコンポーネントがもつ責務は、1つに絞るべきだという原則です。これは単に「1つのクラスが1つのことしかしてはいけない」という意味ではなく、「ある変更理由に対して、修正対象となる場所をできるだけ1ヶ所にまとめる」という考え方です。

たとえば、税額計算に関する処理は「Tax Calculator」のような1つのクラスにまとめ、請求書の出力クラスや会員情報の管理クラスには書かないようにします。こうしておけば、税率や計算ルールが変わったときも、税額計算を担当するクラスだけを見直せばよくなります。

逆に、1つのクラスの中に「税額計算」「帳票出力」「データ保存」など複数の役割が混在していると、どれか1つを変更しただけでも他の機能に影響しやすくなります。修正箇所が広がり、バグや手戻りの原因にもなります。

単一責任の原則を守ることで、修正の影響範囲を局所化し、保守しやすく、変更に強い設計にすることが可能です。

ソフトウェアは拡張には開き、変更や修正には閉じているべき、という原則です。つまり、機能追加の際に既存コードを書き換えるのではなく、追加によって対応できる構造にする、ということを表しています。

これにより、既存機能を壊すリスクを減らしながら新機能を実装していくことが可能になります。

インターフェースを変えることなく機能を使えるようにする、という考え方のことです。

たとえば、コンセントやUSBポートなどはどれも同じ形状ですが、さまざまな家電製品や機器で使うことができます。コンセントやUSBポートというインターフェースを変えることなく使えており、リスコフの置換原則が守られていることがわかります。

ソフトウェア開発においては、親クラスを利用している部分は、そこから派生した子クラスに置き換えても問題なく動作するべき、という原則です。このルールが守られていないと、部品の差し替え時に予期せぬ不具合が起きます。

これは、再利用性を高めるための重要な考え方です。

不要な機能まで含んだ大きなインターフェースに依存することを避けるべき、という原則です。すべての機能を含んだ大きなインターフェースを提供するのではなく、小さく分割されたインターフェースを使うことが重要です。

インターフェース分離の原則を守ることで、変更時の影響範囲が限定され、機能追加や機能変更、修正がしやすくなります。

上位モジュールが下位モジュールの具体的な部品に直接依存してはいけない、という原則で、上位モジュールと下位モジュールはどちらも「抽象」に依存するべきという考え方です。

上位モジュールが下位モジュールに直接依存する設計だと、下位モジュールだけを変更する場合に上位モジュールも影響を受けてしまいます。

依存関係逆転の原則を守ることで、下位モジュールの変更による上位モジュールへの影響を少なくし、ソフトウェアの保守性を高めます。

YAGNIは、「You
Aren’t Gonna Need It」という文章から来ている言葉で、「将来使うかもしれない」機能を先回りして作らない、という原則です。必要になった時に作ると、結果的に無駄が少なくなります。

たとえば、顧客データの項目を設計する際に、名前、年齢、性別、生年月日、住所、電話番号、メールアドレスなどの項目を設計したとします。「後の機能追加でLINEやSNSのアカウントと紐づけるかもしれないから」とLINEやX、FacebookのID情報の項目を設けておいても、実際に機能追加する際には別のテーブルを作成することになり無駄になってしまった、などということも起きます。

このような過剰な設計はコスト増加と複雑化を招くため、いま必要なものだけを実装するという考え方は重要です。

KISSの原則は「Keep It Simple, Stupid」から来ており、「できるだけシンプルに設計する」ことを重視する原則です。

複雑な構造は理解しにくくバグの原因にもなり、障害を起こしやすくなります。

DRYとは「Don’t Repeat Yourself（同じことを繰り返すな）」から来ており、同じ処理を何度も書かないという原則です。

同じコードが複数存在するとコードの量が多くなり、コードを理解する時間や修正や保守にかかる時間が増えてしまいます。そのため、処理のまとまりは共通化するなどにより、シンプルな構成にすることが重要です。

ただし、本質的に異なる処理を無理に共通化すると逆に複雑になる場合もあります。

メソッドは、「状態を変更するが結果は返さない（コマンド）」か「結果を返すが状態は変えない（クエリ）」のどちらかにわけるべき、という原則です。

たとえば、「口座残高を更新する処理」はシステムの状態を変更する「コマンド」とし、「現在の残高を取得する処理」は状態を変更せず値だけを返す「クエリ」とします。ここで、「出金処理」が残高を更新すると同時に、その結果を取得する処理までを1つのメソッドにまとめてしまうと、予期せぬ問題が起こる可能性があります。処理の呼び出し順序や利用方法によっては、残高の更新と参照が混在し、動作が把握しづらくなったり、不具合の原因になったりするのです。

メソッドをコマンドとクエリに明確にわけることで、動作がわかりやすくなり不具合を防ぐことが可能です。

ソフトウェア設計では、内容を言葉だけで伝えるのではなく、「図」を使って整理します。図にすることで、関係者全員が同じ理解をもちやすくなり、認識のずれや手戻りを減らせます。

設計図は品質保証の証拠ともいえます。設計図が整っているプロジェクトは、属人化が少なく、保守や引き継ぎがスムーズです。

ここでは、ソフトウェア設計でよく使われる代表的な設計図を紹介します。それぞれの設計図の特徴を理解することで、設計に活かせるでしょう。

ソフトウェア設計でよく使われる図のうち、特に代表的なものがUML（統一モデリング言語）です。UMLは、システムの構造や振る舞いを標準化された記法で表現するためのモデリング手法で、設計内容を関係者間で共有しやすくする役割があります。

要件整理から基本設計、詳細設計にいたるまで幅広く活用されており、設計の意図を視覚的に伝えるうえで有効です。ここでは、代表的なUML図を紹介します。

システムの静的な構造を表す図です。クラス（部品）、属性（データ）、操作（機能）、それらの関係を示します。

すべてを細かく書くのではなく、主要な構造や関係の概要を整理するために用いることもあります。記述レベルはプロジェクトの段階によって変わります。

どちらもオブジェクト間のやり取りを表す図で、動的な振る舞いを示します。以下のように用途によって使い分けます。

・処理の順序を重視する場合：シーケンス図
・オブジェクトの関係性を重視する場合：コミュニケーション図

業務の流れや処理の流れを表す図で、要求分析や業務フローの整理によく使われます。バッチ処理の大まかな流れを表すときに使う場合もあります。

オブジェクトの状態とその遷移を表す図です。外部仕様の説明に使われることが多く、「どんな状態があり、何がきっかけで変わるのか」を整理します。

構造化分析・設計の手法で、データの流れに着目した図です。処理機能、データの流れ、外部要因などが表現され、システム全体の把握に向いています。

処理手順を順番に表す基本的な図です。アルゴリズムの説明や単純な処理の流れの共有に適しています。近年は詳細設計書で用いられるケースは少なくなりましたが、プログラミングの初心者が処理の流れを理解するために使うこともあります。

データベース設計に使われる図です。主に3種類に分けられます。

・概念ER図：システム化する対象の領域の概念をモデル化したもの
・論理ER図：概念モデルをインプットとしてRDBMSのテーブルに変換するための中間モデル
・物理ER図：RDBMS上のテーブルと対応する詳細なモデル

ER図を用いた設計内容は、データの整合性や将来の拡張性に大きく影響します。

UI（ユーザーインターフェース）を設計するためのものです。具体的には以下のような成果物を作成します。

・画面一覧
・画面項目定義
・画面遷移図
・ワイヤーフレーム

UI設計は、開発するソフトウェアの使いやすさに直結します。

▽あわせて読みたい▽
＞＞UIテストとは？メリットやテスト項目、手順について解説。自動化はするべきか？のページへ

要求（what）と詳細設計（how）の間をつなぐ図で、シーケンス図やクラス図を書く前の整理に使われます。

オブジェクトを以下の3つに分類し、処理をどう実現するかを設計します。

・境界オブジェクト（画面など）
・実体オブジェクト（データ）
・制御オブジェクト（処理制御）

ソフトウェア設計は、単なる技術作業ではなく経営品質を左右する重要な活動です。設計がよければ変更に強くなり保守コストが抑えられますが、設計が悪いと改修のたびにトラブルが増えるという結果になります。

この記事でご紹介したSOLIDやYAGNIなどの原則は、将来の負債を減らすための指針です。また、ここでご紹介した設計図を用途にあわせて適切に用いることで関係者の認識を揃え、品質を担保できます。

企業が持続的にITを活用するには、「機能」だけでなく設計の質に目を向けることが不可欠です。設計への投資はコストではなく、将来のリスクを減らす経営判断といえるでしょう。

＞＞お問い合わせ
＞＞料金について

大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。

担当講座

・コンポーネントテスト講座
・テスト自動化実践講座
・DevOpsテスト入門講座
・テスト戦略講座
・設計品質ワークショップ
など多数

――――――――――
ヒンシツ大学とは、ソフトウェアの品質保証サービスを主力事業とする株式会社SHIFTが展開する教育専門機関です。
SHIFTが事業運営において培ったノウハウを言語化・体系化し、講座として提供しており、品質に対する意識の向上、さらには実践的な方法論の習得など、講座を通して、お客様の品質課題の解決を支援しています。
https://service.shiftinc.jp/softwaretest/hinshitsu-univ/
https://www.hinshitsu-univ.jp/
――――――――――