ソフトウェア設計とは？工程や設計書作成ポイントも【2024年最新版】

ソフトウェアは現代のビジネスには欠かせない存在。自社の業務改善や新規サービス提供のためにソフトウェア開発を行いたいけれども、設計についてよく分からない方もいるのではないでしょうか。当記事では、ソフトウェア設計の概要・工程・ポイントについて解説しています。ソフトウェアの設計・開発を検討している方は是非ご参考ください。

【関連ページ】
システム開発にかかる費用・相場感のご紹介。あなたの目的別にシステム開発会社をお探しいただけます。

システム開発の費用・相場
システム開発ができる会社一覧

ソフトウェアを開発するためには、必ず設計を行う必要があります。しかし、まだソフトウェア開発を行ったことが無い方や経験の少ない方は、ソフトウェア設計の意味についてよく分からないといった方もいるのではないでしょうか。

一般的にソフトウェア開発は、「企画＞要件定義＞設計＞実装＞テスト＞リリース＞保守・運用」という流れで進められます。要件定義と設計はともに上流工程で行われる作業であるため混同されがちですが、両者は別物であることを理解しておく必要があります。

企画段階で顧客がソフトウェアに求める要件をまとめたものが要件定義であり、要件定義をもとにソフトウェアの仕様・機能を決定していくことを設計と呼びます。

ソフトウェア開発において設計が重要である理由は、いかなる開発手法においても以下のように設計工程の成果物があとの工程ならびにソフトウェアの品質を左右するためです。

・実装
設計品質が優れていると確認や手戻りが減り、スムーズな実装が可能。生産性・確実性向上や工数削減に繋がる。

・テスト
テストも設計書に従って行われるため、テスト品質を確保するには設計品質が重要。

・保守、運用
設計が優れているとバグや障害が少なくメンテナンスも容易。保守・運用の難易度低減・工数削減に繋がる。

パフォーマンス・ユーザビリティ・メンテナンス性に優れた有用性の高いソフトウェアを開発するためにも、設計工程で品質を確保しておくことが重要となります。

ソフトウェア開発は、一般的に「企画＞設計＞開発＞テスト＞リリース＞保守・運用」という流れで行われます。そのうち設計工程は、大きく分けて次の3つの工程から構成されています。

・要件定義
ソフトウェアに求める要素を明確化。
・基本設計（外部設計）
主にソフトウェアの外見的な部分を設計。
・詳細設計（内部設計）
ソフトウェアの内部まで詳細に設計。

上記3つの工程の具体的な内容や成果物について、それぞれ以下に解説します。

ソフトウェア開発では、開発の目的・用途・スケジュール・予算・必要な機能・人員など検討すべきことが数多くあります。

要件定義とは、ソフトウェア開発の企画と設計の中間に位置する、上記の各項目を整理してドキュメント化する工程のことです。要件定義で決定された内容は成果物として要件定義書にまとめます。要件定義書に従って設計・実装・テストといったあとの工程が進められるため、要件定義はソフトウェア開発の土台にして最も重要な工程となります。

品質の高い要件定義を行うためには、ソフトウェア開発の工程から開発対象のイメージまで幅広い知識が求められるため、一般的には開発経験が豊富なシステムエンジニアが担当します。

ソフトウェア開発における基本設計とは、要件定義書をもとに開発対象となるソフトウェアの全体像・アウトラインを決定する工程です。

ソフトウェアに求める要件を実現するために、どのような方法で具体化するのか、どのような製品を作ればよいのかという基礎的な内容を検討していく作業となります。ユーザーから見える部分・操作する部分を中心に設計が行われるため、外部設計とも呼ばれます。基本設計で作成される成果物には、次のようなものが挙げられます。

・機能一覧
・画面一覧
・帳票一覧
・業務フロー図
・状態遷移図
・入出力関連図
・データフロー図

基本設計で決定されたアウトプットは、次の工程である詳細設計のインプットとなります。

詳細設計とは、ソフトウェアの内部構造を機能単位で設計していく工程です。ソフトウェアを構成する機能・各機能が行う処理・機能間の連携方法などを具体的に作り込んでいく作業となります。ソフトウェアの内部まで詳細に設計を行うことから、内部設計とも呼ばれます。

詳細設計の代表的な成果物としては、以下のようなものがあります。

・クラス図
・モジュール構造図
・フローチャート
・アクティビティ図
・シーケンス図

いずれの成果物も、ソフトウェアの内部構造を整理したドキュメントであることが特徴です。詳細設計は上流工程の最後尾に位置しており、作成した成果物をもとにソフトウェアの実装（プログラミング）が行われます。

「自社にあった会社が見つからない」「会社選びに時間が割けない」とお悩みの方は、お気軽に「アイミツ」にお問い合わせください。数あるシステム開発会社からあなたの要望にあった会社をピックアップして無料でご紹介いたします。

ソフトウェア設計の工程では、開発対象についてさまざまな検討を行い成果物を残します。成果物の内容次第で完成するソフトウェアの品質が左右されるため、作成には高度な知識・スキル・経験が求められます。作成されるドキュメントは、大きく分けて以下の9種類。

・ソフトウェア構成図
・ネットワーク構成図
・機能一覧
・業務フロー図
・画面一覧
・画面遷移図
・画面レイアウト
・コード一覧
・インタフェース一覧

ここでは、各ドキュメントの概要・用途についてそれぞれ解説していきます。

ソフトウェア構成図とは、ソフトウェア全体の構成を記載した図です。サーバー・データベース・外部システムなどのハードウェアとその機能を中心に記載を行います。全体像を把握することを目的に作成されるため、個々の情報は端的に記載することが特徴です。

ソフトウェア開発は多くのメンバーが携わっており、考え方・方向性がバラバラではスムーズに進めることが困難。ソフトウェア構成図は、メンバー間の情報・認識の共有をスムーズに行うためにも重要なドキュメントとなります。

ネットワーク構成図とは、ソフトウェアに使用するネットワークの情報を視覚化した図。ネットワーク機器の物理的な配置を示した物理構成図と、通信の流れや関係性を示した論理構成図の2種類があります。

■物理構成図
・配置フロア
・配線
・接続ポート
・物理サーバー

■論理構成図
・IPアドレス
・サブネット
・ルーター
・スイッチ
・サーバー（仮想・物理）

ネットワークの構成は複雑であるため、開発をスムーズに行うためにも、分かりやすい構成図を作成しておくことが重要です。

機能一覧とは、ソフトウェアに搭載する機能を一覧表形式でまとめたドキュメントです。提案・見積・契約・設計・開発・テスト・マニュアル作成といったソフトウェア開発の各段階において、機能の把握・進捗管理・作業分担などに使用されます。

機能一覧表はプロジェクト全体で使用されるため、ミスや抜け漏れが無いように正確に作成を行うことが重要ですが、最初から完成形を作ることは困難。そのため、まずはプロトタイプの作成を行い、プロジェクトの段階が進むごとに徐々に内容を充実させていきます。

業務フロー図とは、実際に行われる業務の手順・内容を分かりやすいように視覚化した図のことです。決まった作成方法はありませんが、より詳しく業務の流れを把握できるように、「誰が」「いつ、何をきっかけに」「どのような場合に」「どのような作業を行うか」という4つの要素を時系列に合わせて表現する手法が多く用いられています。

業務フロー図を作成することで、課題発見・ソフトウェア化のポイント・導入後の業務イメージなど、ソフトウェア設計に必要なさまざまな要素を把握することができます。

画面一覧は、ソフトウェアで表示される画面すべてを一覧としてまとめた表形式のドキュメントのことで、画面関係の最も基本的な成果物となります。画面一覧では、画面名に対して次のような項目の記載を行うことで、必要な情報を分かりやすく整理します。

・画面名
・画面ID
・分類
・画面階層
・機能名
・機能ID
・説明

画面一覧はプロジェクト全般に渡ってソフトウェアの規模間・全体像を把握する際に使用されるため、漏れなく正確に作成してことが重要です。

画面遷移図とは、ソフトウェアに表示される画面の順序・階層構造・画面間の関連性を視覚化した図のことです。ソフトウェアで使用する画面の全体像を感覚的に理解・把握できるため、開発メンバー間での情報共有や設計ミス・抜け漏れの防止に役立てることができます。

画面遷移図はソフトウェアの企画・設計時だけでなくプロジェクト全体で重要な役割を果たすため、クオリティの高いソフトウェア開発を行うには必須のドキュメントとなります。

画面レイアウトとは、ソフトウェアに実装する画面の表示イメージ・操作要素をどのように配置するのかを定めたドキュメントです。クライアントならびに実装を行うプログラマーに対して、開発するソフトウェアがどのような画面を使用してどのような処理を行うのかを分かりやすく伝えるために作成されます。

画面イメージが視覚的に理解できるように作成を行うだけでなく、実装時に必要となるID・ラベル・要素・仕様・制限といった詳細な情報の記述も行います。

コード一覧とは、ソフトウェア・データベースで使用する各種コードならびに記述のルールをまとめたドキュメントです。コード設計では、例えば次のようなコードが用いられます。

・シーケンスコード
連続した数字を付与するコード

・ブロックコード
上位の桁数でブロック分けを行い、下位の桁数で連番を付与するコード

・桁別コード
桁別に特定の意味を持たせて組み合わせるコード

開発・運用時にコードを分類・識別するためにも重要なドキュメントとなります。

インターフェース一覧とは、ソフトウェアを構成するのに必要となる外部インターフェース（ソフトウェア・ファイル・データベースなど）との連携方法・連携先・データ参照方法などを整理してまとめたドキュメントのことです。

直接的に開発対象のソフトウェアの仕様を記述するドキュメントではありませんが、ほぼすべてのソフトウェアは少なからずほかのシステムとの連携を行うため、設計・開発をスムーズに進めるためにも重要なドキュメントとなります。

ソフトウェア設計書はあとの工程や製品の完成度を左右するため、高い品質で作成を行っておくことが重要。しかし、検討すべき項目が多く複雑であるため、スムーズに作成するには次のようなポイントを押さえておく必要があります。

ポイント1：詳細なスケジュールを決めてから着手する
ポイント2：業務の実際の担当者にヒアリングする
ポイント3：設計書の読み手を意識する
ポイント4：フォーマットを統一する
ポイント5：イメージ図を活用する

以下に、上記5つのポイントについて具体的に解説します。

ソフトウェア開発プロジェクトは、予算・納期を十分に確保できないケースも多くあります。そのため、設計書作成を行う際には、事前に作業内容・担当者・納期を明確化したスケジュールの作成を行ってから着手することがポイントです。

スケジュールに従い進捗管理を行うことで、品質と工数のバランスがとりやすくなり、設計工程をスムーズに完了させることができます。スケジュールが曖昧なまま着手を行うと工数の遅延や品質低下を招くため、スケジューリングは必ず実施するようにしましょう。

ソフトウェア開発は、顧客の課題解決・目標達成のために行われるので、設計工程では顧客の業務実態を加味することがポイントとなります。そのため、設計書を作成する際には実際の業務担当者へヒアリングを行い、業務フロー・業務実態を明確化しておくことが非常に重要です。

顧客が状況や業務を把握できていないケースにおいては、開発者側から情報を引き出すことも必要となってきます。厳密な設計書は開発者のみでは作成できないため、推測・憶測で進めないように注意しましょう。

ソフトウェア設計書を行う際には、読み手が作成者と同じ知識・経験を有しているわけではないので、以下のように誰が読み手であるのかを意識して作成することが重要です。

・クライアント向け
専門用語、難解な用語を避けて分かりやすい表現で作成。

・開発メンバー向け
チームのITリテラシーに合わせて作成。

・保守、運用メンバー向け
平均的なエンジニアのスキルを想定して作成。

作成者の主観で書いた設計書では有用性を発揮できない場合があるため、必ず意識しておきましょう。

ソフトウェア設計書は複数のメンバーが協業して作成が行われるため、各種ドキュメントに使用するフォーマットを統一しておくことや、ドキュメント間で使用する定義を統一しておくことが重要なポイントです。もし各メンバーがバラバラのフォーマットで設計書の作成を行うと、属人化と呼ばれる作成者しか分からない部分が発生してしまうため、情報共有や業務効率が難しくなるためです。

設計書作成業務の生産性向上・品質向上を行うためにも、フォーマット・記述ルールは必ず統一しておきましょう。

ソフトウェア設計書を作成する際には、必要事項を詳細に記載することも重要ですが、読み手が理解しやすいように作成することも非常に重要。分かりにくく読み取るのに時間が掛かってしまっては、プログラミング作業もスムーズに行うことができません。

そこでポイントとなるのが、テキストばかりに注力するのではなく、概要イメージ図を活用することです。視覚的に表現した方がスムーズに理解できる内容も多いため、図表を上手く活用すれば設計書の視認性・可読性を大幅に高められます。

ソフトウェア開発を成功させるためには、発注者側と開発会社側が情報・認識の共有を行い、不要なトラブルや齟齬を防ぎ着実にプロジェクトを推進することがポイントです。ソフトウェア設計フェーズはそのあとの工程すべてに影響するため、開発会社任せにするのではなく、発注者側も主体性を持って確認や発言を行っていくスタンスが重要となります。

ここでは、ソフトウェア設計フェーズにて、発注者が特に注意して確認しておくべきことを3点解説します。

ソフトウェア開発プロジェクトで最も避けるべきリスクは、実装後に不備や抜け漏れが発覚して手戻りや作り直しが発生することです。そのため、発注者側は納品された各種設計書について、依頼した要件・機能が漏れなく記載されているか、十分な品質で設計書が作成されているかを入念に確認しておくことが重要です。

設計フェーズから実装フェーズに移行する前であれば、例えミスや抜け漏れがあったとしても比較的スムーズにリカバーできるため、必ず確認を行っておきましょう。

ソフトウェア開発の設計フェーズは、開発者が発注者の要求を十分に汲み取り、情報・認識を擦り合わせながら設計書を作り上げて行きます。そこで重要となるのが、両者の間で十分な量のコミュニケーションを行うこと。

開発するソフトウェアの大枠だけでなく詳細な部分までコミュニケーションを行っておくと、大きな失敗やリスクを回避できます。設計フェーズの成否はコミュニケーション量に比例するといっても過言ではないため、発注者側はコミュニケーション量については随時確認するようにしましょう。

発注者と開発者では、ソフトウェアに対する知識・経験・視点が大きく異なることから、情報・認識を共有したようでいて実際は認識のズレが生じているケースは多くあります。また、企画の段階で擦り合わせを行っていても、プロジェクトを進行していく過程で認識のズレが明らかとなることは珍しくありません。

そのため、発注者側は、設計のフェーズごとに認識のズレが生じていないかこまめに確認を行い、もしズレがある場合は開発者側に都度修正を求めることが重要となります。

最後に、システム開発を外注した際にかかる費用相場をご紹介します。

システム開発の費用相場をご紹介しました。より正確な費用を知りたい方は料金シミュレーターをご利用ください。

ソフトウェア開発の設計工程は、開発・テスト・保守・管理といったあとの工程やリリース後の業務にまで影響を及ぼすため、品質が問われる重要な工程です。しかし、ソフトウェア設計には専門的な知識・スキルを要するため、内製を行うのは非常に困難。開発を行う際には、いかに専門家の力を上手く借りるかがポイントとなります。

アイミツでは、きめ細やかなヒアリングをもとに、安心して発注できる開発会社の紹介を行っています。ソフトウェア開発の発注に不安を感じている方は、ぜひご相談ください。

【相談前にまずは会社一覧を見たいという方はこちら】
システム開発ができる会社一覧

【費用感を知りたいという方はこちら】
システム開発の費用・相場