ソフトウェア設計とは？設計書の書き方と品質を高めるコツを解説
こんにちは。Wakka Inc.のWebディレクターの安藤です。
品質の高いソフトウェアを開発するためには、ソフトウェア設計が重要です。しかし、重要とは理解しているつもりでも、
「具体的に何が重要か聞かれるとうまく答えられない」
「設計はしているが、正しいやり方でできているかは自信がない」
という方も多いのではないでしょうか。そこで本記事では、
- ソフトウェア設計が重要な理由
- ソフトウェア設計書の種類と書き方
- ソフトウェア設計書の品質を高めるコツ
について詳しく解説します。ソフトウェア設計を適切に進めるため、ぜひとも本記事をお役立てください。
ソフトウェア開発にはラボ型開発がおすすめ。
SaaSにラボ型開発が最適な理由の資料では、ラボ型開発を活用した柔軟な体制構築ノウハウを解説しています。まずはお気軽にダウンロードしてみてください。
【おすすめ資料】ソフトウェア開発体制にお悩みなら？
・SaaSにラボ型開発が最適な理由
＞SaaSサービスの開発をしている企業の経営者・プロジェクトマネージャーの方に向けて、ラボ型開発を通じてサトータルコストを下げ、柔軟な開発体制を構築するノウハウを紹介しています。
ソフトウェア設計とは
ソフトウェア開発において、ソフトウェア設計は必ず実施すべき工程です。
では、どのような目的で実施するのでしょうか。この章ではまずソフトウェア設計の目的と、進め方の概要について解説します。
ソフトウェア設計の目的
ソフトウェア設計とは、開発するソフトウェアに実装する機能を実現するための、具体的な構造を決めることです。
具体的な構造を決めることで初めて、開発するソフトウェアの製品としての形が明らかになります。構造が曖昧なまま開発してしまうと、最終的に完成するソフトウェアの形がイメージできません。
完成形がイメージできない状態では、ソフトウェアの品質も明確にならないため、品質を保証するのが難しくなります。ソフトウェア設計では、開発するソフトウェアの構造を明確にすることで品質を作りこむのです。
つまり、ソフトウェア設計の目的とは、開発するソフトウェアの品質を決めることと言っても過言ではないでしょう。
ソフトウェア設計の進め方
ソフトウェア開発のプロジェクトはまず、
- 業務上の問題を解決する
- 新規サービスを提供する
などの課題を受け、課題を解決する案を企画するところからスタートすることが多いでしょう。企画段階でソフトウェアに対する要求が洗い出されるので、要求をもとに要件定義を実施します。
要件定義ではユーザーの要求を満たすために必要な機能を明確にします。
ユーザーの要求を満たすためには、ユーザーが持っている課題や実現したい内容についてヒアリングし、具体的な内容を把握しておくことが欠かせません。
次に、外部設計と内部設計では、要件定義で決まった機能を実現するために、ソフトウェアに実装すべき具体的な仕様を決めていきます。
ユーザーの目に見える機能の概要を決めていくのが外部設計。機能の詳細な内部構造を決めていくのが内部設計です。
先に外部設計を実施し、ソフトウェアに実装する機能の概要が決まったら、次に外部設計の内容をもとに内部設計を進めていく流れになります。
ソフトウェア設計が重要な理由
ソフトウェアの開発手法には開発工程を順番に進めるウォーターフォール型、開発工程を短期間に何度も繰り返すアジャイル型など様々なものがあります。
しかしどの開発手法にも、決まって設計工程があります。開発工程の中で設計がそれだけ重要と言えるでしょう。ではなぜ、開発工程の中でソフトウェア設計が重要なのでしょうか。
発注者と開発ベンダーの認識ずれを防ぐため
ソフトウェアは自社で内製される場合もありますが、開発規模が大きくなると、開発ベンダーに発注して開発されるケースが多いでしょう。
開発ベンダーに発注する場合、開発したいソフトウェアの仕様を正しく伝えられないと、希望していたものと異なる製品ができあがるリスクが高くなります。
せっかく開発費を支払って開発ベンダーにソフトウェア開発を依頼するなら、できるだけ希望どおりのソフトウェアに仕上げたいものです。
希望どおりのソフトウェアを開発してもらうためには、発注者と開発ベンダーで認識がずれるのを防ぐことが欠かせません。
認識ずれを防ぐためにはソフトウェア設計をしっかり実施し、発注者と開発ベンダーの間で認識を合わせるのが有効です。ソフトウェア設計によって開発するソフトウェアの形が明確になっていれば、発注者の意図が開発ベンダーに正しく伝わり、希望と異なる製品ができあがるリスクを減らせるでしょう。
内部設計以降の担当者に設計内容を正確に伝えるため
ソフトウェアの開発規模が大きくなると、外部設計と内部設計で担当者が異なる場合があります。
また、大規模な開発でなくても、内部設計からはプログラミングの担当者が実施するケースは多いのではないでしょうか。
発注者と開発ベンダーで認識ずれを防ぐのが重要なのと同様に、開発するソフトウェアの仕様を内部設計以降の担当者が正しく認識することも重要です。
なぜなら、いくら発注者と開発ベンダーで認識が合っていても、内部設計以降の開発担当者がソフトウェアの仕様を正しく理解していないと、思っていたとおりの製品にならないからです。
開発担当者がソフトウェアの仕様を正しく理解し、意図したとおりの製品を開発するためにも、ソフトウェア設計は重要だと言えるでしょう。
ソフトウェアの品質と開発効率を高めるため
前述したとおり、ソフトウェア設計では開発するソフトウェアの品質を作ります。開発するソフトウェアの構造が明確になっていないと、できあがったソフトウェアの品質を保証できないからです。
品質とは、意図的に作りこむことで保証できるものであって、行き当たりばったりで偶然できるものではありません。
高品質のソフトウェアを開発したいのであれば、狙った品質を達成するために入念なソフトウェア設計を実施すべきです。
また、ソフトウェア設計をしっかり実施しておくことで、以降の工程において開発効率が高くなる効果も見込めます。もし、ソフトウェア設計が中途半端なまま開発に入ったとしたら、開発工程の中で試行錯誤することが多くなるでしょう。
開発担当者から設計担当者に対して、不明点の問い合わせや設計不具合の指摘なども増え、開発現場が混乱しかねません。
ソフトウェア設計を入念に実施することで、開発工程では決まったものを迷いなく開発するだけの状態になり、開発効率を上げられるのです。
ソフトウェア設計の工程
ソフトウェア開発の工程は前述したとおり、企画から始まって要件定義、設計、開発、テストと進みます。本記事では、要件定義と設計の工程をソフトウェア設計と位置づけて解説しています。
設計工程は外部設計と内部設計に分けるのが一般的です。この章では、ソフトウェア設計で実施する各工程の役割と流れについて簡単に見ておきましょう。
要件定義
要件定義では、企画段階で洗い出されたソフトウェアに対する要求を分析し、要求を満たすために必要なソフトウェアの機能を洗い出します。
また、洗い出した機能を実現するのに必要となる性能やセキュリティ、運用など、機能面以外の潜在的な要求についても非機能要件として明確にしておかなければなりません。洗い出した機能、非機能は要件定義書にまとめます。
要件定義はソフトウェア開発ですべての工程の土台となるため、最も重要な工程のひとつと言えるでしょう。
なお、外部設計以降の工程を開発ベンダーに発注する場合は、要件定義書をRFP（Request For Proposal：提案依頼書）と合わせて提示するのが一般的です。
外部設計
外部設計は、要件定義で決まった機能を実現するための、具体的な仕様を決めていく工程です。
画面レイアウトや画面遷移、帳票レイアウトなど、ユーザーの目に見える部分を中心に具体的な機能の構造を決めていきます。ユーザーの目に見える部分を中心に設計するため、ソフトウェアの完成形がイメージしやすくなるでしょう。
- 画面のデザイン
- レイアウト
- ボタンやリンクの配置
- メニュー構成
上記のような項目の構造が目に見えることで、違和感があれば修正できるため、徐々に理想に近づいていきます。開発ベンダーに発注する場合、外部設計は基本的に発注者と開発ベンダーの共同作業となる工程です。
主導的に作業を進めるのは開発ベンダーですが、発注者はレビューを実施して改善要望を出すことによって認識のずれを補正し、最終的には発注者の意図した設計を目指します。
内部設計
内部設計は、外部設計で決定した機能の振る舞いを実現するために、ソフトウェアの内部構造を機能ごとに作りこんでいく工程です。
家電製品に例えると、製品のデザインや搭載する機能を決めるのが外部設計で、機能を実現するために内部の機械構造を決めるのが内部設計と言えるでしょう。
機能の内部構造を決めるとともに、開発しやすいよう機能の単位を適切に分割したり、同じ振る舞いをする機能が複数箇所にあるものを共通化したりするのも内部設計の役割です。
目には見えませんが、完成したソフトウェアの体感的な品質を決定づける意味で、内部設計も重要な工程だと言えるでしょう。
ソフトウェア設計書の種類と書き方
ソフトウェア設計の工程と流れについてはご理解いただけたでしょうか。この章ではソフトウェア設計書に含まれるドキュメントの種類と、記載すべき具体的な内容について解説します。
全体概要設計
例えば絵を描くときには、まずは
- 全体の構図を決める
- 描くものの大きさや配置を決める
- 輪郭から描く
のように、全体から描いていくと思います。ソフトウェア設計も基本的に同じと考えて良いでしょう。最初から機能の細部を設計するのではなく、全体の概要を決めることから始めます。
個別機能を設計する前に、各機能のつながりやデータの流れといった全体像を俯瞰するためです。
全体を俯瞰せずに各機能の設計を始めてしまうと、全体がいびつな構造になってしまいかねません。個別機能の設計が全体の構造に影響しないよう、まずは全体の概要を設計するのが重要です。
全体概要設計では次のようなドキュメントを作成します。
業務フロー図
開発するソフトウェアが利用される業務の範囲について、業務全体の流れを図示します。部門や担当者など、対象の業務に関係するユーザーごとに、誰が何をいつ実施するかを時系列で表現します。
ソフトウェアが利用されるタイミングについても記載するため、利用される業務と場面が明確になるでしょう。
機能一覧
開発するソフトウェア機能の一覧を記載します。機能名称と簡単な機能概要を記載するのが一般的です。
ソフトウェアが複数の業務をカバーする場合は、業務ごとに分類して記載すると整理されてわかりやすくなるでしょう。
データフロー図
ソフトウェアで扱うデータが機能を通じてどのように流れるか、データの流れに焦点を当てて記載します。
例えば、受注→在庫引き当て→出荷→請求のように、データの流れを中心に記載してソフトウェアの機能と扱うデータの関係を明確にします。
全体機能構成図
ソフトウェアの各機能のつながりを明確にするため、全体を俯瞰できるように構成を記載します。外部システムとの連携がある場合は、外部システムも含めた形で表現します。
画面設計
ソフトウェアに必要な画面の構成と具体的な動きを決めるのが画面設計です。画面の入出力項目、画面デザイン、ボタンやリンクなどの配置を決め、画面レイアウトを作成します。
メニュー画面や複数の画面間のつながりと動作を把握するため、画面遷移図も作成することが多いでしょう。画面設計では次のようなドキュメントを作成します。
画面一覧
開発するソフトウェアに含まれる画面の一覧を記載します。
画面レイアウト
各画面のイメージを作成します。
画面の入出力項目、およびボタン、リンク、チェックボックスなどのコントロールの配置を、具体的な操作がイメージできるように記載します。
画面設計書
画面レイアウトに配置される各項目について、下記のように具体的な仕様の説明を記載します。
- 入力項目に何を入力するか、入力可能な値の範囲など
- 入力形式がチェックボックスなどのコントロールであれば、値の選択肢や、単一選択か複数選択かなど
- 出力項目に何が表示されるか
- ボタン、リンクをクリックしたときに実行される処理や、画面の遷移など
画面遷移図
開発する画面の数が多い場合は、各画面の関連を明確にするため、画面遷移図を作成します。
画面間を矢印線などで結び、遷移を発生させるアクションも合わせて矢印線の付近に記載して関連性を表現します。
帳票設計
ソフトウェア機能で出力された帳票を業務で使用する場合は、帳票設計を実施します。帳票を出力する形式（CSV、PDFなど）やレイアウトを決めるのが帳票設計です。
帳票設計では次のようなドキュメントを作成します。
帳票一覧
開発するソフトウェアに含まれる帳票の一覧を記載します。
帳票レイアウト
帳票に出力する項目の配置を、具体的にイメージできるように記載します。
帳票設計書
帳票レイアウトに配置される各項目について、出力される内容の説明を記載します。
データ設計
ソフトウェアで取り扱う画面や帳票などのデータを保存するために、データベースの構造を設計するのがデータ設計です。
データの持ち方はしっかり整理しておかないと、データの参照や更新の仕様が非常に煩雑になり、ソフトウェアの内部構造自体が複雑になりかねません。
データ設計では扱うデータ同士の関係を見極め、論理的に整理するために正規化という作業を行います。正規化を行うことによって、データベースに持つデータが重複なく効率的に扱えるようになるでしょう。
データ設計では次のようなドキュメントを作成します。
テーブル一覧
ソフトウェアで扱うデータはデータベースのテーブルとして実装するため、実装するテーブルの一覧を記載します。
ER図
ERとはエンティティ・リレーションシップ（Entity Relationship）の略称です。
エンティティとは実在するモノのことですが、ソフトウェアではモノをデータとして扱うため、テーブルのことと考えて良いでしょう。
リレーションシップとは関係のこと。つまり、ER図とはテーブル間の関係を表現する図です。
テーブル間の関係を図で表現すれば、ソフトウェアで扱うデータの構造が明確になります。
テーブル設計書
テーブル一覧に記載した各テーブルについて、項目名とデータ型（文字型、数値型など）、桁数などを定義します。
バッチ設計
夜間などに、定期的なタイミングでデータを一括更新する場合は、バッチ設計を実施します。
バッチとは大量のデータを、人手を介さず自動的に一括処理することです。バッチ設計では、処理タイミングやスケジュール、処理対象データの条件や処理内容について設計します。
画面のサービス提供時間帯に実行できない場合は、サービス提供時間外に実行することになるため、許容できる処理時間など、運用上の制約についても明確にしておくべきでしょう。
バッチ設計では次のようなドキュメントを作成します。
バッチ処理一覧
開発するソフトウェアに含まれるバッチ処理の一覧を記載します。
バッチ処理フロー図
各バッチ処理について、具体的な処理の流れを記載します。
バッチ処理プロセス設計書
バッチ処理フローに記載した各処理について、下記のような具体的な仕様の説明を記載します。
- 入力データの内容、処理対象とする条件
- 入力データをもとに実行する具体的な処理内容
- 処理の期待結果（ファイルの出力内容、テーブルの更新内容など）
インターフェース設計
インターフェース設計は、外部システムとのデータ連携が必要な場合に実施します。
自社の既存システムと連携する場合はもちろんですが、取引先企業とのシステム連携や、EDI*を使用する場合もインターフェース設計が必要です。
インターフェース設計では外部システムと連携するデータのレイアウトや連携手順、連携タイミングなどについて、連携先の外部システムと共同で設計します。
EDIなど、すでに連携手順が確立されている場合は、決められた設計に従うことになるでしょう。インターフェース設計では次のようなドキュメントを作成します。
※EDI……Electric Data Interchange：電子データ交換
外部システム関連図
ソフトウェアの機能と、外部システムの関連を明確にするため、関連性を図示します。
インターフェース一覧
開発するソフトウェアに含まれる、外部システムとのインターフェースを一覧として記載します。
インターフェース項目設計書
インターフェース一覧に記載した各インターフェースについて、項目とデータ型、桁数などを定義します。
ソフトウェア設計書一覧
最後に、この章で解説したソフトウェア設計書を一覧にまとめておきます。
| NO | 設計種類 | 成果物 |
| 1 | 全体概要設計 | 業務フロー図、機能一覧、データフロー図、全体機能構成図 |
| 2 | 画面設計 | 画面一覧、画面レイアウト、画面設計書 |
| 3 | 帳票設計 | 帳票一覧、帳票レイアウト、帳票設計書 |
| 4 | データ設計 | テーブル一覧、ER図、テーブル設計書 |
| 5 | バッチ設計 | バッチ処理一覧、バッチ処理フロー図、バッチ処理プロセス設計書 |
| 6 | インターフェース設計 | 外部システム関連図、インターフェース一覧、インターフェース項目設計書 |
ソフトウェア設計書の品質を高めるコツ
ソフトウェア設計書の書き方を知るだけで、質の高い設計書が作成できるわけではありません。
設計を担当する技術者はスキルレベルが必ずしも一定ではないため、品質を保つための工夫が必要です。この章では、ソフトウェア設計書の品質を高めるコツをいくつかご紹介します。
テンプレートを使用する
ソフトウェア設計で作成するドキュメントのフォーマットを技術者任せにしていると、技術者によって記述する内容やレベルに差が出てくるのは想像に難くありません。
技術者のスキルレベルによっては、本来必要な観点が設計書に盛り込まれないこともあります。設計に必要な観点が漏れてしまっては、ソフトウェア設計の品質を保つのが難しいでしょう。
そこで、設計書のテンプレートを使用し、技術者によって記述内容が大きくブレないようにするのがおすすめです。テンプレートを使用すれば、
- 設計書の記述レベルが均一化される
- 設計で意識すべき観点が漏れにくくなる
などの効果が見込めるでしょう。
自社で使用している設計書のテンプレートがあれば、発注先の開発ベンダーにも自社のテンプレートを使用してもらうと良いでしょう。
ドキュメントのサンプルや書き方ガイドを作成する
テンプレートを使用すると、設計書の記述項目は均一化されていきますが、記述内容については技術者によってバラバラになることがあるでしょう。
テンプレートの項目を見ただけでは、具体的に記述すべき内容が直観的にわかりにくい場合があるからです。記述すべき内容が明確であっても、人によって表現方法が異なることも多いでしょう。
そこでおすすめなのが、ドキュメントのテンプレートだけでなく、具体的な記述内容についてサンプルを用意しておくことです。
サンプルを参照することでイメージが明確になり、人によって記述内容が大きくブレることがなくなります。
また、記述すべき内容と観点について、設計書の項目ごとに書き方のガイドを作成するのも有効でしょう。
サンプルやガイドがあると、技術者がそれぞれ独自の視点で記述するのではなく、サンプルやガイドの視点に合わせるようになります。結果として記述内容のブレが防げ、ドキュメントの品質も担保しやすくなるでしょう。
設計ツールを利用する
ソフトウェア設計の品質向上に投資できるのであれば、有料の設計ツールを購入して利用するのもひとつの手です。
種類はあまり多くないですが、デンソークリエイト社のNext Design、システムインテグレータ社のSI Object Browser Designerなど、ソフトウェア設計を強力にサポートするツールがいくつか販売されています。
またLucid社のLucidchartなど、データ設計をサポートするツールもあります。中には無料で利用できるツールもあるので、検討してみてはいかがでしょうか。
ただし、ツールを利用するだけでソフトウェア設計の品質が上がるわけではありません。ソフトウェア設計に必要な技術を身に付け、ツールを上手に使いこなしてはじめて品質向上が達成できるのです。
ソフトウェア設計で発注者が注意すべきこと
発注者と開発ベンダーの認識ずれをなくす上で、ソフトウェア設計が重要であることは前述しました。
では、ソフトウェア設計において発注者が注意すべきことは具体的に何でしょうか。この章では、ソフトウェア設計で発注者が注意すべきことを解説します。
発注者と開発ベンダーの共同作業であることを認識する
ソフトウェア設計の中で、要件定義は基本的に発注者が主導的に進めますが、外部設計以降は開発ベンダーが主導で進めます。
しかし、外部設計については開発ベンダーが主導するものの、最終的には発注者が設計内容を承認しなければならないため、開発ベンダーに任せきりではいけません。
開発ベンダーの認識不足などによる設計の誤りがあれば、誤りを指摘して是正していくのは発注者の役割です。設計作業の中で自社の業務に関する課題が出てきたら、解決するための対応を検討する必要もあるでしょう。
したがって発注者は、外部設計を開発ベンダー任せにして、最後にレビューをするだけというわけにはいきません。開発ベンダーが主導するとは言え、発注者と開発ベンダーが共同で設計するものと認識しておくのが重要です。
開発ベンダーに伝えるべき情報を出し切る
発注者と開発ベンダーの認識ずれをなくすために、発注者は開発ベンダーに伝えるべきあらゆる情報をきちんと出し切るのも重要です。
ソフトウェア設計に直接関わる情報だけではありません。自社の組織や事業部門の業務内容について、ソフトウェア設計の背景となる情報も伝えておきましょう。
設計に直接関わらない情報であっても、開発ベンダーに背景情報をきちんと把握しておいてもらうことが、設計の品質に好影響を与えることは大いにあり得るからです。
設計レビューを通して合意レベルを上げる
外部設計の内容を、発注者が責任を持って承認しなければならないことは前述しました。発注者は、開発ベンダーが作成した設計書をレビューし、最終的に設計内容を承認します。
しかし、最終的にレビューするだけでは、認識合わせが不足していることも考えられるでしょう。
設計書に書かれている内容が間違っていなくても、しっかり掘り下げられていなければ、同じ内容でも人によって解釈が違っている可能性があるからです。
レビューの目的は、設計内容を承認することだけではありません。場合によっては、設計を進める間に何度か同じ機能のレビューを繰り返し、認識を合わせていくことも必要です。
レビューを繰り返すと徐々に開発ベンダーの理解が深まり、設計書の記述内容も充実してくるため、双方の合意レベルが上がっていきます。
人によって違った解釈ができるような曖昧な記述の設計書では、合意のレベルが表面的で浅くなりがちです。レビューを繰り返し、詳細で明確な情報が記述された設計書へとブラッシュアップすれば、完成物の品質向上も期待できるでしょう。
ソフトウェア設計の重要な要素を押さえて手堅く開発を進めよう
ソフトウェア設計に必要な観点を満たし、正確な設計書を作成することは、ソフトウェア開発を成功させる上で非常に重要です。観点が漏れたまま次工程へ進むと、検討できていなかった部分が影響して手戻りが発生するリスクが高くなるからです。
必要な観点を漏れなく検討するには、ソフトウェア設計の重要な要素をしっかり押さえておくことが欠かせません。
ソフトウェア設計の重要な要素を押さえておけば、レビューで設計の漏れを指摘でき、結果的に漏れのない高品質なソフトウェア設計ができるでしょう。高品質なソフトウェア設計は、ソフトウェア開発の成功に直結します。
「何から手を付ければ良いかわからない」場合には、まずはソフトウェア開発の経験が豊富なベンダーに相談するのが良いのではないでしょうか。
【おすすめ資料】ソフトウェア開発体制にお悩みなら？
・SaaSにラボ型開発が最適な理由
＞SaaSサービスの開発をしている企業の経営者・プロジェクトマネージャーの方に向けて、ラボ型開発を通じてサトータルコストを下げ、柔軟な開発体制を構築するノウハウを紹介しています。
学生時代にWebサイトを自作したことがきっかけでWebの世界に。制作会社でデザイン、WordPressテーマ開発の実務を経て、テクニカル・ディレクターとして大規模サイト構築のディレクションを経験。2021年からWakka Inc.の日本拠点でWebディレクターとして参画。最近はブロックエディタになったWordPressをもう一度、勉強しています。
