詳細設計書のサンプル・書き方




詳細設計書の書き方(サンプル付き)

プロジェクト開発は「要件定義→基本設計→詳細設計→プログラミング→単体テスト→結合テスト→総合テスト→運用テスト→本番移行・フォロー」という流れで進みます。

このようなシステム開発の流れは一般的ですが、詳細設計でどのような成果物を作成すれば良いのか悩んでいる方も多いのではないでしょうか。

そこで、この記事では詳細設計のサンプルを紹介しつつ書き方も簡単に説明していきます。

はじめに

詳細設計は内部設計と呼ばれることもありますが、当サイトでは詳細設計という呼び方で統一しています。

詳細設計は勘違いをしやすい工程で、ネットで詳細設計について調べると「詳細設計は不要」という主張が多く見られます。

まず、詳細設計は「プログラミングコードを日本語で書くこと」ではありません。そういった資料は「コーディング仕様書」と呼ばれ、オフショア開発(海外への開発委託)時に作られることがありますが、国内での開発においてはコーディング仕様書は不要と考えます。

詳細設計は機能の内部構造を決定する重要な工程です。

システム規模が小さく1人で開発するような場合はプログラミングをしながら頭の中で内部構造を考えていく方が生産性が良いですが、複数名で開発をする場合には詳細設計をしておかないとコードの重複が生じて下記のようなリスクが生じてしまいます。

 ・無駄なテストの発生
 ・修正時のメンテ箇所の増大
 ・保守時の調査工数の増加

詳細設計書を作ることが重要なのではなく、詳細設計という作業をすることが重要なのです。

それでは、ここからは詳細設計書のサンプルや書き方について述べていきます。

詳細設計のサンプル

私が参考にした詳細設計書のサンプルを紹介します。

下記は、情報処理推進機構(以下、IPA)が掲載している教育用の詳細設計資料。

IPA『ソフトウェア開発技法実践的演習教育コンテンツ』

情報処理技術者試験を開催しているだけあって、他のどのサイトよりも資料が充実しています。

実務者の私から見てもここ以上のサンプルは無いかと。加えて、教育用の資料とだけあって各資料の整合性も整っているのでとても参考になります。

資料が大量にあるのでピックアップして紹介しておきます。

アクティビティ図,pp.2-3
シーケンス図
クラス図,p.30
処理機能記述(IPO),pp.2-6

詳細設計書の成果物

詳細設計書の成果物は企業や組織あるいはプロジェクトによって異なるため、どんな成果物を指すのかを明確にしておきましょう。

ここでは下記の資料を詳細設計書として紹介します。

詳細設計書の成果物(例)

・アクティビティ図
・シーケンス図
・クラス図
・処理機能記述書(IPO)
・モジュール構造図

続いて、資料の書き方を簡単に紹介していきます。

アクティビティ図

 

アクティビティ図はフローチャートに似た図で、フローチャートがプログラムの流れのみを書くのに対して、ユーザーの操作とプログラムの動きの両方を書く。

ユーザーの操作を記載することで、どの処理がどのタイミングで動くのかが見えるようになる。

書き方

基本的な書き方はフローチャートと同じ。

利用者のアクションやシステム処理を枠で囲み、それを矢印でつなぐだけ。

条件分岐もフローチャートと同じく、ひし形で表現する。

シーケンス図

 

シーケンス図はアクティビティ図よりもシステム内部処理をさらに細かく記載した資料で、クラスやオブジェクト間のやりとりを時間軸に沿って表す。

資料の使い方としては、アクティビティ図でざっくりと利用者と機能の流れを把握し、より詳細な処理を把握するためにシーケンス図を見る。

書き方

サンプルを見れば分かるように、縦軸が時間になっており、横軸がユーザーやシステム機能(オブジェクト)になる。

ユーザーからのアクションを受けて、オブジェクトがどのような情報を受け取り、次のオブジェクトにどのような情報を渡しているのかを矢印で表現する。

その他にも処理構造を表現するための記述があり、上記サンプルでは「loop」と「opt」が用いられている。

「loop」とはその操作・処理が繰り返し行われることで、「opt」とは特定の条件を満たした場合に行われるもの。上記サンプルではloopで商品検索、optで商品詳細画面への遷移を表現している。

クラス図

 

システムを構成するクラスとクラス間の関係を表す。

プログラミングする際の見取り図になり、作業の優先順位をつけたり、複数名で作業を分担する際に有効な資料。

なお、クラス図ではシステム構成を理解できるものの、処理の流れを把握するには前述のシーケンス図が必要となる。

書き方

クラス図の書き方

クラス図を書くには上記のようなルールに従う。

アクティビティ図やシーケンス図からクラスを洗い出し、各クラスの関係性を考えながら親クラスを作ったり、集約や依存関係を書き出していく。

処理機能記述(IPO)

処理機能記述は、機能の入力・処理・入力を記載したもの。入力=Input、処理=Process、出力=Outputの頭文字をとってIPOと呼ばれる。

私の経験上、メインフレームのシステムでは処理機能記述が成果物として定義されていたが、Web系のシステムでは作成する機会は多くないように感じる。

書き方

出力データを作成するために、入力データを用いて、どのような処理を行うかを記載する。

あまり細かく書きすぎると「ロジックを日本語に訳した資料」となってしまうため、処理の概要が理解できる程度で良い。

モジュール構造図

 

こちらもメインフレームで利用される資料で、COBOLなどのメインフレーム系の言語をコンパイルした後のモジュールのことを指す。

各システム機能がどのようなモジュールによって構成されているかを表現したもので、ロジックの共通化による生産性の向上が期待できる。(ロジックが共通化されることで運用保守の生産性も上がる)

書き方

機能を構成する処理を書き出し、処理の下位レベルにブレークダウンをしていきつつ共通化できる処理を考える。

なお、共通化する処理はメインモジュールから呼ばれるサブモジュールとなり、サブモジュールを作り出すことを「モジュール分割」と呼ぶ。

上記サンプルで考えてみると、集約リストは「データ抽出・リスト発行・データ更新」の3つのモジュールから構成されていることが分かる。(それぞれの処理が開始・メイン・終了の処理を有している)

さいごに

今回は詳細設計書の書き方を紹介してきました。

冒頭に述べたように、プロジェクトによっては詳細設計書は必須ではありません。また、詳細設計書の定義も様々です。(クラス図だったり処理機能記述だったり)

プロジェクトの特性や開発を委託する企業との契約に応じて資料を作成することになると思います。

ただ念押ししたいのは、詳細設計書は不要であっても、詳細設計という作業自体は必要ということ。プロジェクトのQCD(品質・コスト・納期)に関わる問題になりかねないですし、運用保守の生産性の低下にも繋がってしまいますので。

この記事が参考になりましたら幸いです。

 

要件定義〜設計工程の関連記事はこちら。

基本設計書の書き方(サンプル付き)

基本設計書サンプル・書き方

2019年6月15日
要件定義工程の成果物

要件定義工程の成果物一覧

2019年6月4日
要件定義の進め方

要件定義工程の進め方

2019年6月2日
要件定義の目的

【結論】要件定義の目的は「プロジェクトの失敗を減らすこと」

2019年6月2日
要件定義書の書き方

要件定義書サンプル・書き方

2019年6月2日
機能要件と非機能要件の書き方〜サンプル付き

機能要件・非機能要件の書き方【サンプル有り】

2018年8月17日

参考文献

IPA『ソフトウェア開発技法実践的演習教育コンテンツ』

IPA『開発技法の実践的演習コース教材(オブジェクト指向)』

IPA『開発技法の実践的演習コース教材(構造化技法)』

日経BP『システム開発の工程とUML』






コメントを残す

メールアドレスが公開されることはありません。

CAPTCHA