設計書はどうつくる?作成とメンテナンスのポイント

 2018.06.26  株式会社システムインテグレータ

設計書作成はエンジニアにとって重要かつ神経を使う仕事の一つでしょう。設計書の良し悪しによってプロジェクトの成否が変わるといっても過言ではないですから、多くのエンジニアが慎重に設計書を作ります。

では、良い設計書とは何でしょうか?今回は設計書作成の流れを整理しつつ、良い設計書を作るためのポイントと設計書メンテナンスのポイントをご紹介します。

設計書作成のプロセス

一般的なシステム開発プロジェクトは要件定義→設計→開発→テスト→納品というプロセスで進行します。設計は要件定義の次にありますが、実際には設計書作成は要件定義段階から始まっていると言ってよいでしょう。

≪要件定義≫

要件定義はクライアントから現状課題や「こういうシステムが欲しい」という要求をヒアリングするところから始まります。これを要求定義と呼びます。なのでエンジニアの最初の大切な仕事は、クライアントからプロジェクトにおける要求を明確に引き出すことです。要求定義が徹底されていないシステム開発プロジェクトでは、往々にしてプロジェクト途中で新たな要求に気づいたり、変更が発生したりします。そうなると作業の手戻りが多く発生し、プロジェクトが遅延したり、コストが増大したりする可能性があるでしょう。

要求定義としてまとめたクライアントの要求は、次に要件定義としてまとめます。これは「要求を満たすためには○○の機能が必要」など、大まかなシステム仕様書を作成する作業です。要件定義では「絶対に必要なもの」「やりたいこと」「不要なもの」を明確に分けて定義していくことが大切です。

≪設計≫

設計では要件定義でまとめた内容をもとにまずは基本設計を行います。基本設計ではユーザー視点から次のような項目を設計します。

システム設計…インフラ、ネットワーク、機器構成など

画面設計…デザイン、項目の定義など

DB設計…論理および物理設計など

インターフェース設計…他システムとの外部連携、入出力データや帳票など

処理設計…PO、CRUD、コード設計など

業務・運用設計…バックアップ、リカバリー方法、新しい業務フローの詳細など

テスト設計…テスト方法、テストツールなど

その他…補足資料の作成

新規CTA

こうした基本設計が固まったら次の詳細設計に移ります。詳細設計では次のような項目を設計します。

開発環境…各技術のバージョンを指定(サーバー、DB、言語、フレームワーク、その他)

機能分割…どの単位でモジュール化するかを定義

モジュール設計書…処理手順やワークフローについて定義

内部データ…入力と出力のフロー、モジュールの分割・結合度、モジュール間でのデータの受け渡しを明記

クラス設計書…共通化するオブジェクトの粒度と、属性やメソッドを定義

データベースのテーブルの項目定義…データベースに格納するデータを構造化して定義

通信プロトコル設計書…データの通信に関する手順を決めているプロトコルの定義

単体テスト仕様書…モジュール単位でのテストを行うためのテストケースとデータの設計

インターフェース…ユーザーが操作する画面のデザインおよび項目

以上が設計の主なプロセスです。設計が完了すると作成された設計書に従って開発が行われ、テストフェーズが完了した後に納品となります。

[RELATED_POSTS]

良い設計書を書くためには?

システム開発プロジェクトの成否を分けるのが設計書です。では良い設計書を書くためには、どういったポイントに留意すればよいのでしょうか?

ポイント①設計書の目的をハッキリさせる

設計書を作成するのはもちろんシステムを開発するためです。ただし、プロジェクトごとに開発するシステムは違いますし、それを使用するユーザーの範囲も毎回違います。開発や運用の体制も異なります。そこで設計書の目的をハッキリさせることがまず肝要です。

汎用パッケージなのか、特定のユーザーを対象にしたアプリケーションなのか

新規開発なのか、バージョンアップなのか

設計書を受け取るのはクライアントなのか、プログラマーなのか

他にも様々な項目から設計書の目的をハッキリさせることで、必要な項目や保守のサイクルなどを明確にします。

ポイント②読み手を考える

同じ設計書でも、開発者サイドだけが使用する設計書なのか、クライアントへの納品物としてクライアント側も使用してゆく設計書なのかで内容を変える必要があります。たとえば開発者であれば「○○機能の○○モジュールを○○画面からもコール」という記述だけで理解できても、クライアントに対してはそのモジュールの位置づけや目的、仕様などをすぐに参照できるように書く必要があるでしょう。設計書を読む人の立場によって作り方は違います。

ポイント③各設計書のページの位置づけを明記

細かいポイントですが、設計書の各項目では「◯◯機能の仕様について記載する」などと、当該ページの位置づけを明記することが大切です。設計書は場合によっては膨大になり、それぞれの記述がどこに影響するのかを明確にする必要があります。

ポイント④表記に一貫性を持たせる

設計書作成にあたって文章的に注意すべきことが文の調子でしょう。「です、ます調」なのか「である、だ調」なのかを統一するだけでもかなり読みやすさが違います。自身が記録するだけの文章なら文の調子をそろえる必要はないでしょうが、設計書には必ず読み手がいます。また、設計書とドキュメントなどの表記ゆれによって誤解を生じる場合もあります。使用する言葉を定義した用語集なども用意するとよいでしょう。

ポイント⑤他ドキュメントの存在

要件定義フェーズで業務フローが定義済みなのに、設計書でも同じ内容を書いていると生産性は低下します。他ドキュメントを被りがある部分はできる限り排除したいので、他ドキュメントの存在も意識しつつ作成にあたります。それぞれのドキュメントでなにを記述するのかという、「設計書の設計」も必要です。

以上が良い設計書を書くための基本ポイントです。

設計書メンテナンスのためのポイント

システム開発プロジェクトの中で作成された設計書は、定期的なメンテナンスが欠かせません。まず重要なのが変更管理です。変更管理とはシステムに生じた変更を設計書にも反映させることを指します。

たとえばシステム担当者が変わった場合、新任担当者は過去に作成された設計書を参考のシステムの内容を理解します。しかし、システムに改修が加えられているにもかかわらずそれが設計書に反映されていないと、設計書とシステムに相違が生じてトラブルの原因になります。障害が発生した際は対処までの時間が長くなってしまうでしょう。

加えて適切な保存も大切です。設計書はもちろん社外に漏れてはいけない情報なので、セキュリティが確保された状況下での管理が大切です。情報漏えいという観点だけでなく、設計書を失ってしまったという事態も避けなければなりません。最近では設計書を電子データとして保存するケースも多いため、適切な管理を行いましょう。

こうした設計書メンテナンスのポイントを見ていると、いかに標準化された設計書を作成することが大切なのかがわかります。設計書の書き方や内容、言葉遣いなどがプロジェクトによって異なっていたり、作成者によって異なっていると、作成者以外理解できなかったり、誤解が生じて新たなトラブルを生む可能性もあります。

では、設計書の標準化にはルール作りと徹底だけでよいのでしょうか。このような場合に、システムインテグレータが提供するSI Object Browser Designerがおすすめです。この製品はシステム開発の上流工程である基本設計・詳細設計をシステム化し、その合理化・標準化を実現するアプリケーションです。SI Object Browser Designerがあることで誰もが同じように理解できる設計書が完成し、設計プロセスや成果物から属人化を排除できます。

これによって生産性が大幅に向上し、プロジェクトを成功へと導けるでしょう。良い設計書を作成し、最終的にプロジェクトを成功させるためにSI Object Browser Designerの導入をぜひご検討ください。

新規CTA

RECENT POST「コラム」の最新記事


この記事が気に入ったらいいねしよう!
ブログ購読のお申込み

RANKING人気資料ランキング

RANKING人気記事ランキング

RECENT POST 最新記事

OBデザイナーで
生産性向上!