ソフトウェア設計書とは？基本設計書の概要や目的について解説

システム
エンジニア

ソフトウェア設計書のついて教えてください。

プロジェクト
マネージャー

ソフトウェア設計書の概要や基本設計書の要素など紹介しますね。

1. ソフトウェア設計書とは

ソフトウェア設計書は、ユーザー要件のシステムの機能としての実装方法を記載する文書です。エンタプライズ系システム開発では通常、基本設計（外部設計）、詳細設計（内部設計）の2段階の設計書が作成されます。

基本設計ではシステムを使った業務の流れや画面のレイアウトなど、システム導入後のユーザーの業務に直接関わる事項やデータモデル設計などシステム実装の根幹となる部分を設計します。

詳細設計は基本設計に基づいたシステム開発者への指示で、設計書の種類や詳細度は構築されているシステムの特性や開発者のスキルなどにより異なります。本文書では大規模システム開発における基本設計について説明します。

2. 基本設計の代表的な要素

情報処理推進機構（IPA）が2010年3月に発行した「機能要件の合意形成ガイド（ver.1.0）」では、基本設計（外部設計）の設計要素として、「システム振る舞い」、「画面」、「データモデル」、「外部インターフェース」、「バッチ」、「帳票」の6つの技術領域を定義しています。

それぞれの概要を下記に示します。

また、成果物の名称は上述の「機能要件の合意形成ガイド（ver.1.0）」に準じますが、上述文書にも書いてあるとおり、これらの文章がすべて存在しないといけないというわけではありません。

例えば「システム化業務フロー」と「システム化業務説明」が１つの文書として作成される場合もあります。

出典：機能要件の合意形成ガイド｜情報処理推進機構
参照：https://www.ipa.go.jp/sec/softwareengineering/reports/20100331.html

1：「システム振る舞い」設計

「システム振る舞い」の設計はユーザーがシステムを活用してどのように業務を行うかを設計するもので、代表的な成果物として「システム化業務一覧」、「システム化業務フロー」、「システム化業務説明」、「システム振舞い共通ルール」があります。

「システム振る舞い」の設計により、業務の中でシステム化される部分とされない部分の切り分け、システム化後の業務の流れ、該当業務に関わる部署が複数ある場合の部署間の連携などについてユーザーと認識を合わせます。

単体テスト完了後のテスト工程では、このシステム化業務フローに基づきテストケースが作成されます。

2：「画面」設計

画面設計はユーザーが実際にシステムを操作する画面を設計するもので、代表的な成果物として「画面一覧」、「画面レイアウト」、「画面遷移」、「画面入出力項目一覧」、「画面アクション明細」、「画面遷移・レイアウト 共通ルール」があります。

画面設計においては、画面の見た目だけでなく、情報の表示され方やユーザーがどのような操作を行うかなどにも注意してユーザーと確認する必要があります。

3：「 データモデル」設計

データベースに関する設計を行うもので代表的な成果物として「ER図」、「エンティティ一覧」、「エンティティ定義」、「CRUD図」があります。

データモデルは一般ユーザーにとって感覚的に理解しやすいものではありませんが、業務で使用されている用語の定義や各種コード体系、どのようなデータが存在するか（キー値）など、システム設計に大きく関わる部分です。

ユーザーのシステムへのリテラシーを考慮して、ユーザーの理解と合意を得られるように設計のレビューを進める必要があります。

4：「外部インタフェース」設計

外部インタフェース設計では、新規導入するシステムとシステム導入後も稼働し続ける既存システムとのデータ連携を設計します。なお、外部インタフェースは同一企業内のものだけでなく、他企業のシステムとの連携も含みます。

データ連携のタイミングや連携方法、連携するデータ項目などを設計します。代表的な成果物として「外部システム関連図」、「外部インタフェース一覧」、「外部インタフェース項目説明」、「外部インタフェース処理説明」があります。

5：「バッチ」設計

「バッチ」とは、日次や月次など特定のタイミングでデータを一括処理することです。バッチ設計では、バッチ処理のタイミングや処理内容、入出力のデータ項目や想定されるデータ量などについて設計します。

また、「24時時点のデータで作成した製品出荷計画を朝8時までに開示する」など、バッチ処理の開始時刻及び終了時刻について運用上の制約がある場合、そのような制約も明確にする必要があります。

代表的な成果物として「バッチ処理一覧」、「バッチ処理フロー」、「バッチ処理定義」、「バッチ処理共通ルール」があります。

6：「帳票」設計

印字されるデータやPDF、CSVなどで保存されるデータの項目やレイアウト、再出力の可否などの印刷条件などについて設計します。代表的な成果物として「帳票一覧」、「帳票概要」、「帳票レイアウト」、「帳票項目説明」、「帳票編集定義」があります。

3. ソフトウェア設計書/基本設計書作成の目的

ここでは「ユーザーとの合意形成」「詳細設計以降の担当者への指示」「システム運用保守」といった、ソフトウェア設計書/基本設計書作成の目的を説明しますので、ご参考ください。

1：ユーザーとの合意形成

構築するシステムがユーザー要件に合致したものになっているか、導入するシステムを利用した業務フローはどのようなものになるかなど、ソフトウェア設計書/基本設計書の作成とレビューを通してユーザーと合意します。

2：詳細設計以降の担当者への指示

大規模システム開発では、基本設計までの担当者と詳細設計以降の担当者が異なる場合もあり、プロジェクトによってはオフショアでの開発が行われる場合もあります。この場合、基本設計書は詳細設計以降の担当者への情報伝達を確実に行うための重要な文書となります。

3：システム運用保守

システム運用保守は開発業者とは異なる業者が担当することもあり、システムが長く運用される中で担当者自体も交代していきます。

また運用保守中にシステム改変が必要になることもありますので、正しく記載されたソフトウェア設計書は、システム運用保守の負担を軽減するための手段となります。

4. ソフトウェア設計書/基本設計書作成時に留意すべき点

ここでは「システム要件についてユーザーと漏れなく合意する」「基本設計以降の変更管理を考慮する」といった、ソフトウェア設計書/基本設計書作成時に留意すべき点について説明します。

1：システム要件についてユーザーと漏れなく合意する

詳細設計以後の手戻りを防ぐためには、如何にユーザー要件を漏れなく聞き取り、開発者とユーザー（発注者）の認識を合わせるかが大切となります。

「機能要件の合意形成ガイド（ver.1.0）」の「分冊2 システム振舞い編」、「分冊3 画面編」、「分冊4 データモデル編」、「分冊5 外部インタフェース編」、「分冊6 バッチ編」、「分冊7 帳票編」があります。

各分冊では、ユーザーとの合意形成を確実に漏れなく進めるための各文書の記載方法のコツや、開発者と発注者（ユーザー）それぞれが留意すべき点、効果的なレビューの進め方についての非常に具体的な施策が記されていますので、質の高い基本設計を行うための参考文書となるでしょう。

2：基本設計以降の変更管理を考慮する

システムはビジネス環境の変化やバグ改修などで改修が行われていくものですが、改修が行われた際にソフトウェア設計書に反映されていないと、「ソフトウェア設計書は古いので信用できない」ということになってしまいます。

これを避けるためには改修が行われた際に設計書も併せて変更していく必要があります。そのためにはシステム改修の際に変更した設計書もレビューを行うなど、設計書の品質を保つための仕組が必要となります。

一方でソフトウェア設計書/基本設計書を作成する際に、以後の変更管理の行い安さを考慮する必要もあります。例えば分かりやすい変更履歴の記載欄を作成する、各設計文書の役割を明確にする、同じ情報の複数の設計文書への記載を極力避ける、などといった配慮が必要です。

システム
エンジニア

ソフトウェア設計書、基本設計書の要素や目的がわかりました。

プロジェクト
マネージャー

ソフトウェア設計書や基本設計書の目的などを参考に実践し、使い方をマスターしましょう。

5. まとめ

以上、ウォーターフォール型のエンタプライズ系大規模システム開発におけるソフトウェア設計書/基本設計書の概要と目的、留意すべき点について記載しました。

なお、中小規模システム開発やERPなどの既存のパッケージシステムを利用したシステム開発など、ここで記されている文書すべてを作成する必要がない場合もあると思います。その場合でもシステム開発者とユーザーとの合意形成は必要で、運用保守も必要となります。

また、アジャイル開発手法を採用する場合はそもそもソフトウェア設計書が作成されないことが多いですが、その場合でも運用保守のために何らかの文書を作成することにより、運用保守の負担を減らすことができる場合もあります。