ソフトウェア設計とは？工程や設計書の種類・書き方について解説

ソフトウェア設計とは？工程や設計書の種類・書き方について解説

ソフトウェア開発において、設計は全工程における軸となる作業です。しかし、ノウハウや知識がない場合は「なにから始めるべきかわからない」「重要性を理解できていない」などの疑問・課題があるでしょう。

そこで今回は、ソフトウェア設計の基本や工程、設計書の種類・書き方などを解説します。ソフトウェア設計の重要性も解説するので、開発を始める際はぜひ参考にしてみてください。

基本的な知識を身につけることで、開発ベンダーへの依頼時に、必要十分な情報を提供できます。プロダクトの品質向上にもつながるため、開発目的・目標の達成に向けて、予備知識を頭に入れておきましょう。

ソフトウェア設計とは

ソフトウェア設計の目的や重要性について解説します。

ソフトウェア設計の目的

ソフトウェア設計の目的は、プロダクトの品質を担保することです。ソフトウェア設計では、依頼者の要件をもとに、実装すべき機能の洗い出しや仕様の明確化を行います。

設計を疎かにした場合、ソフトウェアの方向性が定まらず、不要な機能が実装されるかもしれません。開発のゴールとなる完成系をイメージすることで、依頼者とベンダーで共通認識を持ち、要件・ニーズを満たす高品質なプロダクトへとつながります。

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

ソフトウェア設計が重要な理由は、次のとおりです。

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

• ソフトウェア開発の軸（方向性）を定め、開発途中の修正を防ぐ
• 依頼者のニーズや課題を満たしやすくなる
• 開発したソフトウェアに不具合が起きた際、担当者が変わってもメンテナンスできる

前述したとおり、ソフトウェア設計は開発の方向性を定める重要な工程です。依頼者のニーズ・課題をクリアするには、設計書を依頼者・ベンダーで共有し、共通認識を持って開発に取り組まなければなりません。

また、設計書がなければ、ソフトウェア開発が属人化します。特定の担当者しか内部を理解していなければ、不具合への対処に時間がかかるでしょう。

これらの理由から、ソフトウェア設計は開発工程において欠かせない作業です。

ソフトウェア設計の5つの工程

ソフトウェア設計の5つの工程について、段階的に解説します。

➀ヒアリング

まずは依頼者へのヒアリングが行われ、求める機能や解決すべき課題など、開発の方向性の軸となる要素を洗い出します。ベンダーとの共通認識を持つ重要な工程なので、依頼者は事業課題や目的、完成系のイメージなどを事前に具体化しておきましょう。

②要件定義

要件定義は、依頼者からの要求を整理・分析し、ニーズを満たす機能を洗い出す工程です。依頼者からのヒアリング内容を設計書にそのまま反映すると、矛盾点や技術的な制約などが無視されるため、設計書として機能しません。

要件定義によって、実装すべき機能やセキュリティ、運用方法など、ソフトウェアの完成系を具体化させ、文書化する必要があります。

③基本設計（外部設計）

基本設計（外部設計）では、要件定義をベースに以下の設計を行います。

＜基本設計の例＞

• ソフトウェアの操作方法
• 各機能の処理の流れ
• 画面のデザイン/レイアウト

基本設計では、依頼者向けの設計書を作成するため、上記のような目に見える箇所を設計します。懸念点や不足する箇所があれば、レビューの際に指摘しましょう。

④詳細設計（内部設計）

詳細設計（内部設計）では、基本設計をベースにエンジニア向けの設計書を作成します。

＜詳細設計の例＞

• ソフトウェアの基本構造を定義する
• 機能ごとに処理されるデータを定義する

機能実装は詳細設計書をもとに行われるため、この工程がプロダクトの品質を左右します。

⑤レビューの実施

設計完了後はレビューを行い、依頼者・ベンダーで認識の相違がないかを確認します。開発は設計書をもとに進められるため、レイアウトや実装される機能などが自社要件にマッチしているか、必ず確認してください。

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

ソフトウェア設計書の種類別に、それぞれの特徴を解説します。

全体概要設計

全体概要設計では、開発するソフトウェアの輪郭について、以下のドキュメントが作成されます。

＜全体概要設計で作成されるドキュメントの例＞

• 業務フロー図：業務フローを図式化する
• 機能一覧：実装される機能を名称/概要と併せて分類・記載する
• データフロー図（DFD）：各種データのフローと機能の関係性を明確化する
• 全体機能構成図：各種機能や連携する外部システムの構成を図式化する

ソフトウェアの概要を上記のように定義することで、設計の矛盾を軽減しつつ、開発に移れます。

画面設計書

画面設計書では、ソフトウェアの操作画面に関して、以下のドキュメントが作成されます。

＜画面設計で作成されるドキュメントの例＞

• 画面一覧：操作画面を一覧形式で提示する
• 画面レイアウト：操作画面の各種レイアウト（ボタンやリンク、チェックボックスなど）をまとめる
• 画面設計書：画面レイアウトの仕様を説明する
• 画面推移図：各アクションにおける画面遷移を図式化する

上記のとおり、画面設計書は依頼者の要件を満たすよう、操作性を軸とした設計が行われる工程です。

帳票設計書

請求書や納品書など、帳票を扱うソフトウェアを開発する場合は、帳票設計書として以下のドキュメントが作成されます。

＜帳票設計で作成されるドキュメントの例＞

• 帳票一覧：ソフトウェアで扱う帳票を一覧形式で提示する
• 帳票レイアウト：帳票に表示される項目の配置をイメージとして具体化する
• 帳票設計書：各項目の出力内容を定義する

上記のように、出力される帳票を設計段階で具体化することにより、依頼者の業務フロー・プロセスにフィットするかを確認できます。

データ設計書

データ設計書として、ソフトウェアで扱うデータベースを正規化するため、以下のドキュメントを作成します。

＜データ設計で作成されるドキュメントの例＞

• テーブル一覧：ソフトウェアで扱うテーブル（データを扱う基本単位）を一覧形式で提示する
• ER図：各テーブルの関係を図式化する
• テーブル設計書：各テーブルの詳細（項目名や文字・数値型など）を定義する

データ設計を行わなければ、データが煩雑化し、効率的に扱えない恐れがあります。そのため、上記のようなドキュメントを作成して、正規化します。

バッチ設計書

バッチ設計書では、処理のスケジュールやタイミング、条件などの設計が行われます。

＜バッチ設計で作成されるドキュメントの例＞

• バッチ処理の一覧：実行されるバッチ処理を一覧形式で提示する
• バッチ処理のフロー図：バッチ処理のフローを図式化する
• プロセス設計書：処理対象の条件や入力データ、実行内容などの仕様をまとめる

バッチ処理は、自動的にデータの一括更新を行う処理なので、正しく動作するよう上記のような設計図が作成されます。

ソフトウェア設計における注意点

ソフトウェア設計における注意点を3つ解説します。

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

ソフトウェア設計は、依頼者と開発ベンダーが共同で進めなければ、理想のプロダクトが完成しません。要件定義～基本設計にかけて、自社要件が正しく反映されているか、依頼者はレビューをとおして確認する必要があります。

ベンダーに依存していては、機能や画面操作、扱えるデータの種類などが、ソフトウェアの開発目的と合致しないかもしれません。ソフトウェア設計は、依頼者とベンダーの共同作業であることを理解し、理想のプロダクトを完成させましょう。

開発ベンダーに必要な情報をすべて伝える

開発ベンダーとの認識を一致させるため、ソフトウェア設計に入る際は、必要な情報をすべて伝えましょう。ベンダーは依頼者の要件をもとに、設計書を作成します。

ソフトウェア開発の背景や導入目的、活用する事業などの必要な情報を伝えなければ、要件に沿ったソフトウェアは開発できません。依頼者・ベンダーで認識を一致させるためにも、すべての情報を伝えるよう意識してください。

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

設計レビューの際は、設計書の理解・承認ではなく、合意レベルを上げることで、依頼者・ベンダーの認識の相違を軽減できます。設計レビューは、設計書に目を通し、要件を満たすか確認するだけでは不十分です。

双方の認識を合致させるには、設計書の内容を掘り下げつつ、誰が読んでも同じ認識になるよう調整する必要があります。合意レベルを上げることで、より理想的なプロダクトへと近づくでしょう。

ソフトウェア開発は専門会社への依頼がおすすめ！

高品質かつ自社要件を満たすソフトウェア開発を求める場合は、専門会社への依頼がおすすめです。

＜専門会社へ依頼するメリット＞

• 予算やスケジュールに合わせて開発を進めてもらえる
• 競合他社の開発実績があれば、ベストプラクティスを活用できる
• 社内で新規人材や設備を用意する必要がない

専門会社へ依頼する場合、スキルやノウハウ、環境を自社で用意する必要がありません。自社要件に沿って対応してもらえるため、品質はもちろん、予算・スケジュールにも合わせてもらえます。

品質とニーズ両方のバランスを求める際は、専門会社への依頼を検討しましょう。

まとめ

ソフトウェア設計は、プロダクトの品質を左右する重要な工程です。依頼者は自社の要件を伝えるだけでなく、レビューにも積極的に参加して、品質向上を目指しましょう。

依頼者・ベンダーの認識を一致させ、合意レベルを上げることで、より自社要件を満たすプロダクトの完成に近づきます。

また、ソフトウェア開発は内製化もできますが、環境構築や人材雇用に時間とコストがかかります。品質も担保できないため、開発を始める際は専門会社への依頼も検討してみてください。