- 更新日 2024.03.15
- カテゴリー システム開発
ソフトウェア開発の設計工程とは|位置付け・重要性・設計項目を解説!
ソフトウェア開発のなかでも設計工程は非常に重要だと聞いた。しかし、ソフトウェア設計とは具体的になにをするものなのか?なぜ重要なのかよくわからない。そんな企業担当者に向け、位置付けや重要性から、設計項目、企画者 / 発注者がどう関与すべきかまで、ソフトウェア設計の全体像を解説していきます。
なお、ソフトウェア開発会社の探し方・選び方がわからない!という方はシステム幹事にお気軽にご相談ください。貴社の目的・予算にあった最適な会社を厳選してご紹介します。相談料・会社紹介料などは無料です。
ソフトウェア開発の設計工程とは
ソフトウェア設計とは、PCやスマートフォンなどのコンピューター・ハードウェアになんらかの処理を実行させる「ソフトウェア・プログラム」を設計すること。つまり設計工程とは、コンピューターにどのような機能を持たせるのか仕様(設計)を決め、ソフトウェアを開発するための設計書に落とし込む工程です。
ソフトウェア設計の重要性
ソフトウェア開発の手法にはいくつかの種類がありますが、どの手法を採用するにしても設計工程は非常に重要です。なぜなら、設計工程はソフトウェアを開発(プログラミング)するための設計図を作る工程だから。設計図がなければソフトウェアを開発できないのはもちろん、設計時の問題は以降の開発工程すべてに影響してしまいます。
たとえば、設計に不備があれば、開発したソフトウェアは計画した通りの機能 / 性能を発揮できません。設計のやり直しが必要になれば、ソフトウェア開発の予算 / スケジュールにも大きく影響します。特に設計工程の影響を受けやすいのが、日本でよく採用されるソフトウェア開発手法「ウォーターフォール型」です。
ウォーターフォール型ソフトウェア開発
ウォーターフォール型ソフトウェア開発とは、企画からリリースまで、ソフトウェアの開発工程を1つずつ順序立てて進行させていく開発モデル / 手法のこと。上流から下流に水が流れる様がウォーターフォール(落水)に例えられることから命名された開発モデルです。
ウォーターフォール型では、1つの工程を完了させてから、次の工程へ進むことが原則。工程の手戻り(前の工程に戻る)を想定しないことも特徴です。また「要件定義」および、設計工程となる「基本設計」「詳細設計」を上流工程と呼び、どのようなソフトウェアを開発するかを明確化する重要な工程とされています。
それでは、なぜウォーターフォール型ソフトウェア開発では、基本設計 / 詳細設計という2つの設計工程があるのか。それぞれの設計工程では、ソフトウェアのなにを設計するのか。以下から解説していきましょう。
ウォーターフォール型開発については以下の記事もあわせてご覧ください。
関連記事:ウォーターフォール開発とは?開発工程・メリット・向いているプロジェクトも解説
ソフトウェア開発の基本設計:ウォーターフォール
ソフトウェア開発の基本設計(Basic Design)とは、機能 / システム構成など、開発するソフトウェアの基本的な仕様を明確化していく作業工程のこと。ユーザーの目に触れる「ソフトウェアの外部」を設計することから、外部設計(External Deisgn)と呼ばれる場合もあります。
基本設計と要件定義の関係
要件定義のアウトプットとなる成果物「要件定義書」は、基本設計のインプットとして利用されるという関係性にあります。要件定義とは、企画者 / 発注者がソフトウェアに求める条件を、機能要件 / 非機能要件定義する作業工程のことです。
機能要件とは、開発するソフトウェアに実装されるべき機能の絶対条件。非機能要件とは、可用性 / パフォーマンスなど、機能要件以外に求められるソフトウェアの絶定条件のこと。つまり、機能 / 非機能要件をもとに、ソフトウェアの基本的な仕様を明確化していく作業工程が基本設計です。
機能要件 / 非機能要件については以下の記事もあわせてご覧ください。
関連記事:機能要件とは|システム開発プロジェクトにおける重要性や非機能要件との違いを解説!
基本設計の設計項目
それでは、基本設計工程では、具体的にソフトウェアのなにを設計するのか?開発するソフトウェアによって異なりますが、一般的にはソフトウェアの仕様に関する以下の項目を設計します。
主な設計項目 |
概要 |
システム設計 |
ソフトウェアが機能要件 / 非機能要件を満たすのに 必要なシステム構成を設計(ハードウェア含む) |
画面設計 |
ユーザーが操作するインターフェースの設計。画面レイアウト、遷移図など |
帳票設計 |
請求書 / 納品書などの帳票画面を設計 |
バッチ設計 |
データの処理の手順や方法を設計 |
テーブル / ファイル設計 |
データベースの型、取り扱うファイルの形式などを設計 |
外部インターフェース設計 |
外部システムと連携するためのインターフェースを設計 |
アウトプットされる基本設計書
基本設計工程で実施される設計作業の成果は「基本設計書」としてアウトプットされます。設計項目ごとにアウトプットされる設計書(ドキュメント)の具体例、および設計書のサンプルを紹介しておきましょう。
設計項目 |
設計書(ドキュメント)の具体例 |
システム設計 |
システム / ネットワーク構成図など |
画面設計 |
画面一覧、画面レイアウト図、画面遷移図など |
帳票設計 |
帳票一覧、帳票レイアウト図、帳票編集定義など |
バッチ設計 |
バッチ処理一覧、処理フロー図、処理定義など |
データベース設計 |
テーブルファイル一覧、ER図、CRUD図など |
ファイル設計 |
ファイル一覧、レイアウト図など |
外部インターフェース設計 |
外部インターフェース一覧、レイアウト図など |
システム設計書のサンプル
画像出典:富士通
画面設計書のサンプル(画面一覧、画面レイアウト図、画面遷移図)
画像出典:IPA(独立行政法人 情報処理推進機構)
帳票設計書のサンプル(帳票一覧、帳票レイアウト図)
画像出典:IPA(独立行政法人 情報処理推進機構)
バッチ設計書のサンプル(バッチ処理一覧、バッチ処理フロー図)
画像出典:IPA(独立行政法人 情報処理推進機構)
データベース設計書のサンプル(ER図、CRUD図)
画像出典:IPA(独立行政法人 情報処理推進機構)
外部インターフェース設計図のサンプル(外部システム関連図)
画像出典:IPA(独立行政法人 情報処理推進機構)
ソフトウェア企画者は基本設計にどう関与すべきか
操作画面であるインターフェース、操作結果の振る舞いなど、基本設計では「ユーザーの目に見える」ソフトウェアの外側を設計します。つまり、基本設計は「ソフトウェア企画者 / 発注者の要求が満たされているかを確認」し、開発者と合意する重要なステップ。以下のことを念頭に、企画者 / 発注者は積極的に基本設計工程に関与しなければなりません。
- 基本設計はソフトウェア企画者 / 発注者が関与できる最後の上流工程
- 設計書を確認して開発工程の手戻りリスクを排除する
ソフトウェア開発の詳細設計:ウォーターフォール
ソフトウェア開発の詳細設計(Deatil Design)とは、ソフトウェアに実装される機能をどのように開発するかを定義する作業工程のこと。ユーザーの目に触れない「ソフトウェアの内部」を設計することから、内部設計(Internal Deisgn)と呼ばれる場合もあります。
詳細設計と基本設計の関係
基本設計のアウトプットとなる成果物「基本設計書」は、詳細設計のインプットとして利用されるという関係性。基本設計が企画者と開発者の間でソフトウェアの機能を確認 / 合意することを目的とするのに対し、詳細設計は実際の開発を担当するエンジニアの指標作成を目的とします。
特に、ソフトウェア開発を外注する場合は、企画者 / 発注者が詳細設計に関与することはほとんどありません。
詳細設計の設計項目
それでは、詳細設計工程では、具体的にソフトウェアのなにを設計するのか?一般的には、ソフトウェアに実装される機能をモジュールに分割し、それぞれを開発する際の構造やルールを設計します。
主な設計項目 |
概要 |
クラス設計 |
ソフトウェアを構成するクラスの関係を設計 |
モジュール構造設計 |
機能を実現するためのモジュール構造を設計 |
アクティビティ設計 |
ソフトウェアが命令を処理する流れを設計 |
開発方針 / ルール設計 |
採用するフレームワーク / ライブラリ、プログラミング言語、記述ルールなど |
アウトプットされる詳細設計書
詳細設計工程で実施される設計作業の成果は「詳細設計書」としてアウトプットされます。設計項目ごとにアウトプットされる設計書(ドキュメント)の具体例を紹介しておきましょう。
設計書(ドキュメント)の具体例 | 概要 |
クラス図 | クラスの関係を示す静的資料 |
モジュール構造図 | モジュールごとの処理を示す動的資料 |
アクティビティ図 | 処理の流れを示した動的資料 |
シーケンス図 | クラス / オブジェクトのやり取りを時間軸で示した動的資料 |
IPO(処理機能記述) | 入力・処理・出力の流れを示した動的資料 |
クラス図のサンプル
画像出典:Cacoo
モジュール構造図のサンプル
画像出典:若手エンジニアの羅針盤
アクティビティ図のサンプル
画像出典:Cacoo
シーケンス図のサンプル
画像出典:Cacoo
アジャイル型ソフトウェア開発の設計工程
ここまでは、ウォーターフォール型ソフトウェア開発の設計工程を解説してきましたが、もう1つの主流といえるアジャイル型ソフトウェア開発の設計工程も解説しましょう。アジャイルとは「素早い、迅速」などの意味を持つ英単語のこと。その名の通り、主要機能から素早く開発 / リリースを繰り返し、ソフトウェアの完成を目指していく開発手法です。
具体的には、ソフトウェアを2週間程度で開発できる機能に分割し、計画 > 開発 > リリース > レビューを1単位とした「イテレーション」を繰り返すというもの。アジャイル型開発モデルには「スクラム」「XP」などの複数種類がありますが、いずれもウォーターフォール型のような「明確な設計工程」はありません。
もちろん、明確な設計工程がないからといって、ソフトウェアの設計書をまったく作らないわけではありません。ただし、ソフトウェアの開発前に作るというよりは、イテレーションレビュー後の結果として設計書を作るといった方が適切です。
ソフトウェア開発の主な手法については以下の記事もあわせてご覧ください。
関連記事:システム開発の手法4つの特徴・メリット・デメリットを解説
XP(エクストリームプログラミング)とは
それでは、アジャイル型ソフトウェア開発の設計は、具体的にどのように実施されるのか?XP(エクストリームプログラミング)を例に解説していきます。XPとは、開発途中のソフトウェア仕様・要件の変更・追加対応に重点を置いたアジャイル型開発モデルのこと。XPでは、企画 / 発注側の担当者が開発チームの一員として参画します。
計画 > 開発 > リリースというイテレーションの流れは同じですが、レビュー後のノウハウを次のイテレーションへ積極的に活かしていくことがXPの特徴。チームスタッフには特別な役割を持たせず、全員参加 / 情報共有を基本とします。では、XPのソフトウェア設計はどうなっているのか?それが「ペアプログラミング」「モブプログラミング」です。
ペアプログラミング
ペアプログラミングとは、ソースコードを書くドライバー / 指示をするナビゲーターの2人1組でプログラミングを進めるXPの開発手法のこと。ナビゲーターを設計者、ドライバーをプログラマーに見立て、設計と開発をリアルタイムに進行させていくと考えればわかりやすいでしょう。
モブプログラミング
一方のモブプログラミングとは、ソースコードを書くタイピスト / 指示を出す複数人のモブというチームでプログラミングを進めるXPの開発手法のこと。タイピストは指示に対する意見をいえないというルールがあり、モブという複数の設計者の知見を取り入れることを重視した手法です。
アジャイル型ソフトウェア開発には、まだまだ異なる設計手法もありますが、共通しているのはアジャイルのメリットを活かすリアルタイム性です。開発モデルが異なれば、ソフトウェア設計の考え方 / 手法も異なることを覚えておきましょう。
【まとめ】ソフトウェア開発の設計工程を解説しました
ソフトウェア開発のなかでも設計工程は非常に重要だと聞いた。しかし、ソフトウェア設計とは具体的になにをするものなのか?なぜ重要なのかよくわからない。そんな企業担当者に向け、位置付けや重要性から、設計項目、企画者 / 発注者がどう関与すべきかまで、ソフトウェア設計の全体像を解説してきました。
なお、ソフトウェア開発会社の探し方・選び方がわからない!という方はシステム幹事にお気軽にご相談ください。貴社の目的・予算にあった最適な会社を厳選してご紹介します。相談料・会社紹介料などは無料です。
この記事を書いた人
梓澤 昌敏
専門分野: 音楽・映像制作、オウンドメディア、ビジネス
音楽・映像制作の現場を経て、スタジオ構築側の業界へ。マネージャー・コンサルタントとして制作現場の構築に携わる一方、自社オウンドメディアの立ち上げを含むマーケティングも担当してきました。現在アメリカ在住。作曲を含む音楽制作も提供しています。
このライターの記事一覧