ソフトウェア設計とは？設計書の書き方と品質を高めるコツを解説

こんにちは。Wakka Inc.のWebディレクターの安藤です。
品質の高いソフトウェアを開発するためには、ソフトウェア設計が重要です。しかし、重要とは理解しているつもりでも、
「具体的に何が重要か聞かれるとうまく答えられない」
「設計はしているが、正しいやり方でできているかは自信がない」
という方も多いのではないでしょうか。そこで本記事では、

• ソフトウェア設計が重要な理由
• ソフトウェア設計書の種類と書き方
• ソフトウェア設計書の品質を高めるコツ

について詳しく解説します。ソフトウェア設計を適切に進めるため、ぜひとも本記事をお役立てください。

ソフトウェア開発にはラボ型開発がおすすめ。
SaaSにラボ型開発が最適な理由の資料では、ラボ型開発を活用した柔軟な体制構築ノウハウを解説しています。まずはお気軽にダウンロードしてみてください。

【おすすめ資料】システム開発会社が利用する、プロジェクト計画書のテンプレートです！

PMBOKを意識した内容になっており、プロジェクトの概要からスコープ、マネジメント、リスク管理といった項目が盛り込まれる計画書テンプレートです。

ソフトウェア設計とは

ソフトウェア開発において、ソフトウェア設計は必ず実施すべき工程です。
では、どのような目的で実施するのでしょうか。この章ではまずソフトウェア設計の目的と、進め方の概要について解説します。

ソフトウェア設計の目的

ソフトウェア設計とは、開発するソフトウェアに実装する機能を実現するための、具体的な構造を決めることです。
具体的な構造を決めることで初めて、開発するソフトウェアの製品としての形が明らかになります。構造が曖昧なまま開発してしまうと、最終的に完成するソフトウェアの形がイメージできません。
完成形がイメージできない状態では、ソフトウェアの品質も明確にならないため、品質を保証するのが難しくなります。ソフトウェア設計では、開発するソフトウェアの構造を明確にすることで品質を作りこむのです。
つまり、ソフトウェア設計の目的とは、開発するソフトウェアの品質を決めることと言っても過言ではないでしょう。

ソフトウェア設計の進め方

ソフトウェア開発のプロジェクトはまず、

• 業務上の問題を解決する
• 新規サービスを提供する

などの課題を受け、課題を解決する案を企画するところからスタートすることが多いでしょう。企画段階でソフトウェアに対する要求が洗い出されるので、要求をもとに要件定義を実施します。
要件定義ではユーザーの要求を満たすために必要な機能を明確にします。
ユーザーの要求を満たすためには、ユーザーが持っている課題や実現したい内容についてヒアリングし、具体的な内容を把握しておくことが欠かせません。

次に、外部設計と内部設計では、要件定義で決まった機能を実現するために、ソフトウェアに実装すべき具体的な仕様を決めていきます。
ユーザーの目に見える機能の概要を決めていくのが外部設計。機能の詳細な内部構造を決めていくのが内部設計です。
先に外部設計を実施し、ソフトウェアに実装する機能の概要が決まったら、次に外部設計の内容をもとに内部設計を進めていく流れになります。

株式会社Wakka Inc.

ITにおけるシステム設計とは？重要性と開発成功のポイントを解説

こんにちは。Wakka Inc.のWebディレクターの安藤です。ITプロジェクトにおいて、システム設計はプロジェクト成功のカギを握る重要な工程です。それほど重要なシステム設計ですが、「システム設計で実施すべき内容の理解が漠然としている」「開発ベンダーにシステム開発を発注するときに、何を注意すべきかわからない」と感じることも多いのではないでしょうか。本記事では、システム設計を円滑に進めるために必要な、システム設計で実施すべきことシステム設計を上手く進めるポイントなどについて解説します。システム開発を成功させる...

ソフトウェア設計が重要な理由

ソフトウェアの開発手法には開発工程を順番に進めるウォーターフォール型、開発工程を短期間に何度も繰り返すアジャイル型など様々なものがあります。
しかしどの開発手法にも、決まって設計工程があります。開発工程の中で設計がそれだけ重要と言えるでしょう。ではなぜ、開発工程の中でソフトウェア設計が重要なのでしょうか。

発注者と開発ベンダーの認識ずれを防ぐため

ソフトウェアは自社で内製される場合もありますが、開発規模が大きくなると、開発ベンダーに発注して開発されるケースが多いでしょう。
開発ベンダーに発注する場合、開発したいソフトウェアの仕様を正しく伝えられないと、希望していたものと異なる製品ができあがるリスクが高くなります。
せっかく開発費を支払って開発ベンダーにソフトウェア開発を依頼するなら、できるだけ希望どおりのソフトウェアに仕上げたいものです。

希望どおりのソフトウェアを開発してもらうためには、発注者と開発ベンダーで認識がずれるのを防ぐことが欠かせません。
認識ずれを防ぐためにはソフトウェア設計をしっかり実施し、発注者と開発ベンダーの間で認識を合わせるのが有効です。ソフトウェア設計によって開発するソフトウェアの形が明確になっていれば、発注者の意図が開発ベンダーに正しく伝わり、希望と異なる製品ができあがるリスクを減らせるでしょう。

内部設計以降の担当者に設計内容を正確に伝えるため

ソフトウェアの開発規模が大きくなると、外部設計と内部設計で担当者が異なる場合があります。
また、大規模な開発でなくても、内部設計からはプログラミングの担当者が実施するケースは多いのではないでしょうか。
発注者と開発ベンダーで認識ずれを防ぐのが重要なのと同様に、開発するソフトウェアの仕様を内部設計以降の担当者が正しく認識することも重要です。
なぜなら、いくら発注者と開発ベンダーで認識が合っていても、内部設計以降の開発担当者がソフトウェアの仕様を正しく理解していないと、思っていたとおりの製品にならないからです。
開発担当者がソフトウェアの仕様を正しく理解し、意図したとおりの製品を開発するためにも、ソフトウェア設計は重要だと言えるでしょう。

ソフトウェアの品質と開発効率を高めるため

前述したとおり、ソフトウェア設計では開発するソフトウェアの品質を作ります。開発するソフトウェアの構造が明確になっていないと、できあがったソフトウェアの品質を保証できないからです。
品質とは、意図的に作りこむことで保証できるものであって、行き当たりばったりで偶然できるものではありません。
高品質のソフトウェアを開発したいのであれば、狙った品質を達成するために入念なソフトウェア設計を実施すべきです。

また、ソフトウェア設計をしっかり実施しておくことで、以降の工程において開発効率が高くなる効果も見込めます。もし、ソフトウェア設計が中途半端なまま開発に入ったとしたら、開発工程の中で試行錯誤することが多くなるでしょう。
開発担当者から設計担当者に対して、不明点の問い合わせや設計不具合の指摘なども増え、開発現場が混乱しかねません。
ソフトウェア設計を入念に実施することで、開発工程では決まったものを迷いなく開発するだけの状態になり、開発効率を上げられるのです。

ソフトウェア設計に必要なこと

ソフトウェアを設計するにあたり、プログラミングをはじめとしたIT関連の知識が必要と漠然としたイメージを抱える人が多いのではないでしょうか。
本章では、ソフトウェア設計にはどのような経験・スキルが必要なのかを解説します。

IT全般に関する幅広い知識

ソフトウェア開発では、プログラミング言語を中心とした幅広いITの知識が求められます。
ソフトウェア開発で用いるプログラミング言語は、PHP・JavaScript・Python・C++ ・Goなど様々です。

プログラミング言語だけでなく、開発周辺の知識やOSに関する知識も欠かせません。
最適なソフトウェアを提案するには、複数のプログラミング言語やOSの最適解を考え、システムを構築する必要があります。

課題解決に導くコミュニケーションスキル

クライアントやプロジェクトのチームメンバーとの連携力を高めるためには、高いコミュニケーションスキルが求められます。
クライアントとの打ち合わせでは、クライアントの要望や抱えている課題をいかに上手く聞き取れるかがプロジェクトの成功を左右する重要なポイントです。

チームでソフトウェア開発を進めるときは、進捗状況の共有や改善点の話し合いが効率化のポイントです。
スムーズな情報共有や話し合いを実施するためにも、コミュニケーションスキルが必要です。

ソフトウェア設計の工程

ソフトウェア開発の工程は前述したとおり、企画から始まって要件定義、設計、開発、テストと進みます。本記事では、要件定義と設計の工程をソフトウェア設計と位置づけて解説しています。
設計工程は外部設計と内部設計に分けるのが一般的です。この章では、ソフトウェア設計で実施する各工程の役割と流れについて簡単に見ておきましょう。

要件定義

要件定義では、企画段階で洗い出されたソフトウェアに対する要求を分析し、要求を満たすために必要なソフトウェアの機能を洗い出します。
また、洗い出した機能を実現するのに必要となる性能やセキュリティ、運用など、機能面以外の潜在的な要求についても非機能要件として明確にしておかなければなりません。洗い出した機能、非機能は要件定義書にまとめます。
要件定義はソフトウェア開発ですべての工程の土台となるため、最も重要な工程のひとつと言えるでしょう。
なお、外部設計以降の工程を開発ベンダーに発注する場合は、要件定義書をRFP（Request For Proposal：提案依頼書）と合わせて提示するのが一般的です。

株式会社Wakka Inc.

ソフトウェアの要件定義とは？システム開発時のプロセスやコツを解説

こんにちは。Wakka Inc.のWebディレクターの安藤です。ソフトウェアやシステムを開発する上で、実施する業務を固めるのが要件定義です。開発のプロジェクトを成功に導くには、必要な要素を落とし込んだ要件定義を作成する必要があります。本記事では要件定義はどのようなものか、また開発時のプロセスや要件定義のまとめ方のコツなどを解説いたします。「ソフトウェアやシステムを発注したが、納品物が思っていたものと違う」「現在開発中のシステムは、どのような仕様で発注したか確認したい」といった悩みをお持ちの方はもちろん、自...

外部設計

外部設計は、要件定義で決まった機能を実現するための、具体的な仕様を決めていく工程です。
画面レイアウトや画面遷移、帳票レイアウトなど、ユーザーの目に見える部分を中心に具体的な機能の構造を決めていきます。ユーザーの目に見える部分を中心に設計するため、ソフトウェアの完成形がイメージしやすくなるでしょう。

• 画面のデザイン
• レイアウト
• ボタンやリンクの配置
• メニュー構成

上記のような項目の構造が目に見えることで、違和感があれば修正できるため、徐々に理想に近づいていきます。開発ベンダーに発注する場合、外部設計は基本的に発注者と開発ベンダーの共同作業となる工程です。
主導的に作業を進めるのは開発ベンダーですが、発注者はレビューを実施して改善要望を出すことによって認識のずれを補正し、最終的には発注者の意図した設計を目指します。

内部設計

内部設計は、外部設計で決定した機能の振る舞いを実現するために、ソフトウェアの内部構造を機能ごとに作りこんでいく工程です。
家電製品に例えると、製品のデザインや搭載する機能を決めるのが外部設計で、機能を実現するために内部の機械構造を決めるのが内部設計と言えるでしょう。
機能の内部構造を決めるとともに、開発しやすいよう機能の単位を適切に分割したり、同じ振る舞いをする機能が複数箇所にあるものを共通化したりするのも内部設計の役割です。
目には見えませんが、完成したソフトウェアの体感的な品質を決定づける意味で、内部設計も重要な工程だと言えるでしょう。

【おすすめ資料】システム開発会社が利用する、プロジェクト計画書のテンプレートです！

PMBOKを意識した内容になっており、プロジェクトの概要からスコープ、マネジメント、リスク管理といった項目が盛り込まれる計画書テンプレートです。

ソフトウェア設計書の種類と書き方

まずはソフトウェア設計書の種類と成果物の一覧を見てみましょう。

ソフトウェア設計書で作成するドキュメントは多岐にわたり、それぞれの役割は異なるため、読み解いて理解するのが難しい場合もあります。
しかし、ソフトウェア設計書の重要性を考慮すると、各種設計書の内容と役割を理解することは大切です。

本章では、ソフトウェア設計書に含まれるドキュメントの種類と、記載する具体的な内容を解説します。

全体概要設計

例えば絵を描くときには、まずは

• 全体の構図を決める
• 描くものの大きさや配置を決める
• 輪郭から描く

のように、全体から描いていくと思います。ソフトウェア設計も基本的に同じと考えて良いでしょう。最初から機能の細部を設計するのではなく、全体の概要を決めることから始めます。
個別機能を設計する前に、各機能のつながりやデータの流れといった全体像を俯瞰するためです。
全体を俯瞰せずに各機能の設計を始めてしまうと、全体がいびつな構造になってしまいかねません。個別機能の設計が全体の構造に影響しないよう、まずは全体の概要を設計するのが重要です。
全体概要設計では次のようなドキュメントを作成します。

画面設計

ソフトウェアに必要な画面の構成と具体的な動きを決めるのが画面設計です。画面の入出力項目、画面デザイン、ボタンやリンクなどの配置を決め、画面レイアウトを作成します。
メニュー画面や複数の画面間のつながりと動作を把握するため、画面遷移図も作成することが多いでしょう。画面設計では次のようなドキュメントを作成します。

なお、画面設計書に記載される仕様説明の詳細は以下の通りです。

• 入力項目に何を入力するか、入力可能な値の範囲など
• 入力形式がチェックボックスなどのコントロールであれば、値の選択肢や、単一選択か複数選択かなど
• 出力項目に何が表示されるか
• ボタン・リンクをクリックしたときに実行される処理や、画面の遷移など

帳票設計

ソフトウェア機能で出力された帳票を業務で使用する場合は、帳票設計を実施します。帳票を出力する形式（CSV、PDFなど）やレイアウトを決めるのが帳票設計です。
帳票設計では次のようなドキュメントを作成します。

データ設計

ソフトウェアで取り扱う画面や帳票などのデータを保存するために、データベースの構造を設計するのがデータ設計です。
データの持ち方はしっかり整理しておかないと、データの参照や更新の仕様が非常に煩雑になり、ソフトウェアの内部構造自体が複雑になりかねません。
データ設計では扱うデータ同士の関係を見極め、論理的に整理するために正規化という作業を行います。正規化を行うことによって、データベースに持つデータが重複なく効率的に扱えるようになるでしょう。
データ設計では次のようなドキュメントを作成します。

テーブル一覧

ソフトウェアで扱うデータはデータベースのテーブルとして実装するため、実装するテーブルの一覧を記載します。

ER図

ERとはエンティティ・リレーションシップ（Entity Relationship）の略称です。
エンティティとは実在するモノのことですが、ソフトウェアではモノをデータとして扱うため、テーブルのことと考えて良いでしょう。
リレーションシップとは関係のこと。つまり、ER図とはテーブル間の関係を表現する図です。
テーブル間の関係を図で表現すれば、ソフトウェアで扱うデータの構造が明確になります。

テーブル設計書

テーブル一覧に記載した各テーブルについて、項目名とデータ型（文字型、数値型など）、桁数などを定義します。

バッチ設計

夜間などに、定期的なタイミングでデータを一括更新する場合は、バッチ設計を実施します。
バッチとは大量のデータを、人手を介さず自動的に一括処理することです。バッチ設計では、処理タイミングやスケジュール、処理対象データの条件や処理内容について設計します。
画面のサービス提供時間帯に実行できない場合は、サービス提供時間外に実行することになるため、許容できる処理時間など、運用上の制約についても明確にしておくべきでしょう。
バッチ設計では次のようなドキュメントを作成します。

バッチ処理一覧

開発するソフトウェアに含まれるバッチ処理の一覧を記載します。

バッチ処理フロー図

各バッチ処理について、具体的な処理の流れを記載します。

バッチ処理プロセス設計書

バッチ処理フローに記載した各処理について、下記のような具体的な仕様の説明を記載します。

• 入力データの内容、処理対象とする条件
• 入力データをもとに実行する具体的な処理内容
• 処理の期待結果（ファイルの出力内容、テーブルの更新内容など）

インターフェース設計

インターフェース設計は、外部システムとのデータ連携が必要な場合に実施します。
自社の既存システムと連携する場合はもちろんですが、取引先企業とのシステム連携や、EDI*を使用する場合もインターフェース設計が必要です。
インターフェース設計では外部システムと連携するデータのレイアウトや連携手順、連携タイミングなどについて、連携先の外部システムと共同で設計します。
EDIなど、すでに連携手順が確立されている場合は、決められた設計に従うことになるでしょう。インターフェース設計では次のようなドキュメントを作成します。
※EDI……Electric Data Interchange：電子データ交換

外部システム関連図

ソフトウェアの機能と、外部システムの関連を明確にするため、関連性を図示します。

インターフェース一覧

開発するソフトウェアに含まれる、外部システムとのインターフェースを一覧として記載します。

インターフェース項目設計書

インターフェース一覧に記載した各インターフェースについて、項目とデータ型、桁数などを定義します。

ソフトウェア設計書一覧

最後に、この章で解説したソフトウェア設計書を一覧にまとめておきます。

ソフトウェア設計書の品質を高めるコツ

ソフトウェア設計書の書き方を知るだけで、質の高い設計書が作成できるわけではありません。
設計を担当する技術者はスキルレベルが必ずしも一定ではないため、品質を保つための工夫が必要です。この章では、ソフトウェア設計書の品質を高めるコツをいくつかご紹介します。

テンプレートを使用する

ソフトウェア設計で作成するドキュメントのフォーマットを技術者任せにしていると、技術者によって記述する内容やレベルに差が出てくるのは想像に難くありません。
技術者のスキルレベルによっては、本来必要な観点が設計書に盛り込まれないこともあります。設計に必要な観点が漏れてしまっては、ソフトウェア設計の品質を保つのが難しいでしょう。
そこで、設計書のテンプレートを使用し、技術者によって記述内容が大きくブレないようにするのがおすすめです。テンプレートを使用すれば、

• 設計書の記述レベルが均一化される
• 設計で意識すべき観点が漏れにくくなる

などの効果が見込めるでしょう。
自社で使用している設計書のテンプレートがあれば、発注先の開発ベンダーにも自社のテンプレートを使用してもらうと良いでしょう。

ドキュメントのサンプルや書き方ガイドを作成する

テンプレートを使用すると、設計書の記述項目は均一化されていきますが、記述内容については技術者によってバラバラになることがあるでしょう。
テンプレートの項目を見ただけでは、具体的に記述すべき内容が直観的にわかりにくい場合があるからです。記述すべき内容が明確であっても、人によって表現方法が異なることも多いでしょう。

そこでおすすめなのが、ドキュメントのテンプレートだけでなく、具体的な記述内容についてサンプルを用意しておくことです。
サンプルを参照することでイメージが明確になり、人によって記述内容が大きくブレることがなくなります。
また、記述すべき内容と観点について、設計書の項目ごとに書き方のガイドを作成するのも有効でしょう。
サンプルやガイドがあると、技術者がそれぞれ独自の視点で記述するのではなく、サンプルやガイドの視点に合わせるようになります。結果として記述内容のブレが防げ、ドキュメントの品質も担保しやすくなるでしょう。

設計ツールを利用する

ソフトウェア設計の品質向上に投資できるのであれば、有料の設計ツールを購入して利用するのもひとつの手です。
種類はあまり多くないですが、デンソークリエイト社のNext Design、システムインテグレータ社のSI Object Browser Designerなど、ソフトウェア設計を強力にサポートするツールがいくつか販売されています。
またLucid社のLucidchartなど、データ設計をサポートするツールもあります。中には無料で利用できるツールもあるので、検討してみてはいかがでしょうか。
ただし、ツールを利用するだけでソフトウェア設計の品質が上がるわけではありません。ソフトウェア設計に必要な技術を身に付け、ツールを上手に使いこなしてはじめて品質向上が達成できるのです。

ソフトウェア設計で発注者が注意すべきこと

発注者と開発ベンダーの認識ずれをなくす上で、ソフトウェア設計が重要であることは前述しました。
では、ソフトウェア設計において発注者が注意すべきことは具体的に何でしょうか。この章では、ソフトウェア設計で発注者が注意すべきことを解説します。

発注者と開発ベンダーの共同作業であることを認識する

ソフトウェア設計の中で、要件定義は基本的に発注者が主導的に進めますが、外部設計以降は開発ベンダーが主導で進めます。
しかし、外部設計については開発ベンダーが主導するものの、最終的には発注者が設計内容を承認しなければならないため、開発ベンダーに任せきりではいけません。
開発ベンダーの認識不足などによる設計の誤りがあれば、誤りを指摘して是正していくのは発注者の役割です。設計作業の中で自社の業務に関する課題が出てきたら、解決するための対応を検討する必要もあるでしょう。
したがって発注者は、外部設計を開発ベンダー任せにして、最後にレビューをするだけというわけにはいきません。開発ベンダーが主導するとは言え、発注者と開発ベンダーが共同で設計するものと認識しておくのが重要です。

開発ベンダーに伝えるべき情報を出し切る

発注者と開発ベンダーの認識ずれをなくすために、発注者は開発ベンダーに伝えるべきあらゆる情報をきちんと出し切るのも重要です。
ソフトウェア設計に直接関わる情報だけではありません。自社の組織や事業部門の業務内容について、ソフトウェア設計の背景となる情報も伝えておきましょう。
設計に直接関わらない情報であっても、開発ベンダーに背景情報をきちんと把握しておいてもらうことが、設計の品質に好影響を与えることは大いにあり得るからです。

設計レビューを通して合意レベルを上げる

外部設計の内容を、発注者が責任を持って承認しなければならないことは前述しました。発注者は、開発ベンダーが作成した設計書をレビューし、最終的に設計内容を承認します。
しかし、最終的にレビューするだけでは、認識合わせが不足していることも考えられるでしょう。
設計書に書かれている内容が間違っていなくても、しっかり掘り下げられていなければ、同じ内容でも人によって解釈が違っている可能性があるからです。

レビューの目的は、設計内容を承認することだけではありません。場合によっては、設計を進める間に何度か同じ機能のレビューを繰り返し、認識を合わせていくことも必要です。
レビューを繰り返すと徐々に開発ベンダーの理解が深まり、設計書の記述内容も充実してくるため、双方の合意レベルが上がっていきます。
人によって違った解釈ができるような曖昧な記述の設計書では、合意のレベルが表面的で浅くなりがちです。レビューを繰り返し、詳細で明確な情報が記述された設計書へとブラッシュアップすれば、完成物の品質向上も期待できるでしょう。

ソフトウェア設計の重要な要素を押さえて手堅く開発を進めよう

ソフトウェア設計に必要な観点を満たし、正確な設計書を作成することは、ソフトウェア開発を成功させる上で非常に重要です。観点が漏れたまま次工程へ進むと、検討できていなかった部分が影響して手戻りが発生するリスクが高くなるからです。
必要な観点を漏れなく検討するには、ソフトウェア設計の重要な要素をしっかり押さえておくことが欠かせません。
ソフトウェア設計の重要な要素を押さえておけば、レビューで設計の漏れを指摘でき、結果的に漏れのない高品質なソフトウェア設計ができるでしょう。高品質なソフトウェア設計は、ソフトウェア開発の成功に直結します。
「何から手を付ければ良いかわからない」場合には、まずはソフトウェア開発の経験が豊富なベンダーに相談するのが良いのではないでしょうか。

【おすすめ資料】システム開発会社が利用する、プロジェクト計画書のテンプレートです！

PMBOKを意識した内容になっており、プロジェクトの概要からスコープ、マネジメント、リスク管理といった項目が盛り込まれる計画書テンプレートです。