設計書とは、システム開発における設計の内容をアウトプットしたもののことです。

そもそもシステム開発は、要件定義→設計→開発→テストという工程で行われます。はじめに実施する要件定義は、クライアントが抱える課題や理想のシステムイメージなどをヒアリングし、システムの仕様を決めるために必要な重要な工程です。要件定義では要件定義書を作成し、搭載すべき機能を明確にします。この要件定義書をもとに、システム設計について具体的にまとめたのが設計書です。

設計書には「基本設計書」と「詳細設計書」がある

設計書には、外部設計をまとめる基本設計書と、内部設計をまとめる詳細設計書があります。外部設計とは画面デザインや操作方法など、ユーザーが直接見たり触れたりする部分の設計のことです。クライアント向けに行われ、基本設計書では業務フローや画面レイアウト、機能同士の関連などについてまとめます。

内部設計とは機能ごとの処理フローや処理項目など、ユーザーの目に見えない部分の設計のことです。外部設計を決めた後に内部設計を決め、詳細設計書にまとめます。詳細設計書を見ただけでエンジニアが開発を進められるように、細かい部分まで落とし込むのが特徴です。

設計書と仕様書の違い

設計書とよく似た言葉に、仕様書があります。それぞれ意味や役割が異なるため、違いを理解しましょう。

仕様書とは開発者に向けて作られる、プロダクトを作るうえで満たすべき要件をまとめた説明書のことです。仕様書は、完成イメージを明確にするために作られます。一方、設計書は設計についてまとめた資料であり、完成までの工程を明確にしたものです。つまり、「このようなシステムを作りたい」というゴールを明確にするのが仕様書であるのに対し、それまでに至る工程を明確にするのが設計書といえます。

基本設計書の書き方

以下では、要件定義の後に作成する基本設計書の書き方について、フローや項目、ポイントを解説します。

基本設計書の作成フローは以下のとおりです。

要件定義書を確認する
設計を行う
基本設計書を作成する
メンバー内・クライアントでレビューを行う

基本設計書は、要件定義で決めた内容を実現するため、システムに実装する必要がある機能を明らかにすることを目的として作成されます。そのため、まずは、要件定義書を確認しましょう。チームで設計を行う場合は齟齬が生まれないように、要件定義書に対する認識の統一が重要です。

つづいて要件定義書をもとに外部設計を行い、基本設計書を作成します。この基本設計書はExcelやWordで作成することが多いものの、フォーマットや記述方法の統一や管理が難しいため、専用のシステムを用いることがおすすめです。

基本設計書を作成したならば、メンバー内とクライアントでそれぞれレビューを実施します。レビューでは、クライアントにシステムの仕様を理解してもらい、承認を得るため、わかりやすく噛み砕いて説明しましょう。レビューには顧客から承認を得る目的のほか、実現可能性や設計の際に気づかなかった問題、メンバー内の認識のずれなどに気づいて修正するという目的もあります。

基本設計書の7つの項目

基本設計書に含める項目はプロジェクトによってさまざまですが、基本的には以下の7つの項目を含めることが多いです。

機能一覧
業務フロー図、システム構成図
画面設計図
帳票設計図
バッチ設計図
データベース設計図
外部インターフェース設計図

基本設計書は、クライアントにシステムの仕様を伝えるためにも用いられるため、専門用語は使わず、クライアントも目を通す前提でわかりやすく作成することが求められます。

ここでは、基本設計書の7項目について解説します。

1.機能一覧

機能一覧は、システムに実装する機能を一覧で表したものです。この項目では要件定義で洗い出した機能を全て含める必要があります。ただし、はじめの段階から必要な機能を網羅することは難しいため、要件定義書を参考にしながら徐々にアップデートしていくのがよいでしょう。

機能一覧によって、開発すべき機能を把握してシステムの全体像を理解できるほか、不要な機能が含まれていないかどうかのチェックもできます。開発時の進捗確認にも活用可能です。

2.業務フロー図、システム構成図

業務フロー図はユーザーが実際に行う業務の流れを記載したもの、システム構成図はシステムを利用する際のシステム側の処理をまとめたものです。業務フロー図とシステム構成図を描いてみると、開発するシステムの機能やシステムによって自動化される業務の範囲が明確化されます。概略図や記号を用いて、構成要素やフローなどをわかりやすく表しましょう。

3.画面設計図

画面設計図は、システムに表示される画面イメージを明確に定義し、デザインと操作が視覚的かつ直感的にわかるようにまとめたものです。画面ごとの構成は詳細設計書にまとめるため、ここではタイトルバーやメニューバー、画面の構成といった各画面に共通する部分の仕様をまとめます。正常時のイメージだけではなく、エラー発生時のパターンも追加しましょう。

4.帳票設計図

帳票設計図とは、販売管理システムのように帳票が必要なシステムを開発する際に作成する、システムが出力する帳票についてまとめたものです。帳票一覧や帳票レイアウト、帳票の出力項目一覧や編集方法などを記載します。帳票テンプレートごとに仕様を決める必要があり、PDFのようにファイルで出力する場合は、その仕様についても定義しましょう。

5.バッチ設計図

バッチ設計図は、ある決まったタイミングで1つのプログラムが複数のデータを一括処理する、バッチ処理についてまとめたものです。バッチ処理は処理件数や処理時間、回復可能性などを考慮して開発されます。

バッチ処理フローや関連テーブルID、関連テーブル名などを作成し、設計書に落とし込んだものがバッチ設計図です。

6.データベース設計図

データベース設計図は、システムで使うデータの処理や保管方法などを表したものです。データベース内にあるデータの保管方法についてまとめたテーブル関連図であるER図、テーブルごとに持つ機能をまとめたCRUD図などを作成します。特にER図はデータベース設計の基本であり、シンプルにシステムをまとめられ、そのままデータ構造に変換できるため便利です。

7.外部インターフェース設計図

別のシステムとシステムを連携させるためには、外部インターフェースを設計することが必要です。そのため、連携時に用いるデータややりとりについてまとめた定義書、外部サービスとシステムとの連携方法をまとめた処理概要などを作成します。連携させるデータによっては、暗号化通信が必要になることもあり、連携仕様についてまとめることが大切です。

基本設計書の書き方のポイント

基本設計書を書く際には、以下のポイントをおさえておきましょう。

要件定義書をもとに作成する
詳細設計を意識して作成する
クライアント目線で作成する

基本設計書は、前の工程で記述した要件定義書に沿って作成する必要があります。要件定義書の内容と乖離していれば、クライアントが求める要件を満たしていない、質の悪いシステムに仕上がってしまうでしょう。

また、その後に行われる詳細設計を十分に意識して作成することもポイントです。要件定義書に書かれる要件の多くは、実現方法が複数考えられることがあります。そこで基本設計の段階で詳細設計を意識し、コストや処理性能などの面から詳細設計のしやすい適切な方法を選択しましょう。

忘れてはならないのが、クライアント目線で作成することです。前述のとおり、基本設計書は顧客にシステムの仕様を理解してもらい、承認を得るために作成されます。エンジニア目線で専門用語が多くてわかりにくい設計書を書いてしまいがちですが、あくまでもクライアント目線で作成するようにしましょう。

詳細設計書の書き方

詳細設計書は、それを見ただけで担当者が認識の齟齬なく開発できるよう、非常に細かい部分まで落とし込んで作られています。そのまま開発現場に用いるため、専門用語が多く登場しやすいのが特徴です。

詳細設計書は以下のようなプロセスで作成します。

基本設計書を確認する
設計を行う
詳細設計書を作成する
メンバー内でレビュー・フィードバックを行う

まずは基本設計を確認し、システムの具体的イメージについてメンバー内で認識を統一しましょう。

次に基本設計書に書かれた各機能を実現できるようにするため、実装する機能の整理や割り振り、共通化可能な部分の設計、プラットフォームに合わせた設計といった作業を行います。

内部設計を行ったならば詳細設計書を作成し、詳細設計書が完成した段階でメンバー内でのレビューを実施しましょう。誤字や問題点、記号の使い方など、細かい部分まで入念なチェックを行います。ミスを無視して開発を進めると、システム上では不具合として現れてしまうため、細かい箇所も見逃さずにレビューすることが必要です。

詳細設計書の4つの項目

詳細設計書に含める項目もプロジェクトによってさまざまで、目的によって多様なまとめ方がありますが、基本的には以下の4つを作成します。

クラス図
モジュール構成図
アクティビティ図
シーケンス図

詳細設計書は、書き方の違いでエンジニアに誤解を与えないように、ある程度フォーマットに則って作成することが必要です。

以下では、4つの項目について詳しく解説します。

1.クラス図

クラス図は、システム同士の関係性や構造を図示したものです。チームで分業して開発を進める際に役立ちます。特に大規模なシステム開発の場合、概要を理解してスムーズな連携を実現するためにはクラス図が必須です。また、アクティビティ図やシーケンス図の作成にも用いられるため、非常に重要な役割を担います。

プログラミング言語がJavaのようなオブジェクト指向である場合には、このクラス図を用いることが多いです。しかし使用する言語によっては、次で紹介するモジュール構成図が用いられることもあります。

2.モジュール構成図

モジュール構成図は機能ごとの処理をモジュールで示し、モジュールがどのように分けられているのか、それぞれどのように関連しあっているのかなどを記したものです。図形や矢印を用い、簡略化してわかりやすく記載します。プログラムをモジュール化して開発を行う際は、その組み合わせ方も重要であるため、モジュール構成図の作成が重要です。

3.アクティビティ図

アクティビティ図は、開始から終了までのシステム処理の流れや、ユーザー操作をまとめたものです。システムで行われる一連の手続きや条件分岐などを、順番どおりに記載して矢印でつなぎます。フローチャートに似ているため、比較的馴染みすいです。アクティビティ図では、開始時と終了時にノードという点を用いるという特徴があります。

4.シーケンス図

シーケンス図は、アクティビティ図よりもさらにシステム内部の処理を細かく記載したものです。アクティビティ図はシステム処理やユーザーの流れを順番に大まかに把握できるものですが、このシーケンス図に落とし込むと、システムが特定の処理を行う際にオブジェクト間でどのような相互作用が発生するのかを視覚的に把握できるようになります。世界標準の記述方法が存在し、アクティビティ図のように開始時と終了時をノードで表すのが特徴です。

詳細設計書の書き方のポイント

詳細設計書を書く際は、以下のポイントに注意しましょう。

見た人が誰でも理解できるように書く
図や表を用いてシンプルに書く

詳細設計書は、それを見たエンジニアが誰でも開発を進められるように記述しなければなりません。曖昧な表現は避けましょう。

さらに、説明文が冗長にならないように読みやすさを工夫する必要があります。説明事項が長くなると、内容を理解するのに時間がかかったり、エンジニアが誤解したりするリスクが高まってしまうでしょう。箇条書きを用いたり、図や表を活用したりしてシンプルに書いてください。