詳細設計を理解する！一般的な取り組みに必要な要素を簡単に解説！

最終更新：2020/04/03 投稿：2019/11/21

システム開発工程において詳細設計とは基本設計にて決まった内容を元に『これまでの決定事項を実現するために細かく落とし込んでいく工程』です。詳細設計は製造工程へとバトンを渡すための工程に位置づきます。それではどんな内容を細かく決めていくのでしょうか？この記事では詳細設計を理解するために一般的な取り組みに必要な要素を簡単に解説していきます。

詳細設計とは

詳細設計と基本設計の違い

MVCモデルとは

詳細設計の取り組みに必要な要素

機能分割

データフロー

データベース設計

入出力の設計

詳細設計書を作成する際のポイント

目次・見出しの作成

難しい言葉や造語の禁止

一文は短く、主語は前に

曖昧な表現の禁止

見やすさを徹底的に意識

表記ゆれが存在しないか要注意

まとめ

詳細設計とは

詳細設計の工程では基本設計の内容をもとに開発するシステムを大まかな機能ごとに分割し、それらのコンポーネント間をつなぐインターフェースの仕様などを設計します。基本設計でのユーザー側視点と反対に詳細設計においてはプログラム設計など、開発者側の視点でシステム設計をします。そのため基本設計までの工程はお客様との協議や確認などが度々発生しますが、詳細設計の工程からは通常開発者側に進行が委ねられます。
この詳細設計の工程でプログラムの仕様が細かく綺麗に書かれていると、どんなプログラマーがプログラミングを対応しても品質にズレの生じないシステムが実装されます。

英語表記は“Internal Design”
略式は”ID”
となっております。
※英語で表現される機会もあるため参考までに

また詳細設計について、“内部設計”や”機能設計”と表現する場合もあります。

システム開発の基本工程について解説された記事はこちら＞＞

詳細設計と基本設計の違い

システム設計工程における詳細設計と基本設計の違いについて説明します。詳細設計と基本設計を言い換えるとイメージがしやすいかも知れません。詳細設計は内部設計、基本設計は外部設計と言い換えられます。ようするに詳細設計は『見えないシステムの中身の部分』基本設計は『見えるシステムの外側の部分』を意味するのです。

詳細設計 / 内部設計 / 見えない部分
基本設計 / 外部設計 / 見える部分

詳細設計における見えない部分、基本設計における見える部分とは具体的にどういうことでしょうか？もう一歩踏み込んで説明をさせていただきます。

・詳細設計（見えない部分）
基本設計で決められた機能を実現するためにシステムの中身を作り上げるための設計
・基本設計（見える部分）
お客様が使用する実際に目に見える機能を構築するための設計

詳細設計、基本設計それぞれ同じ設計工程にて存在する理由はこのように役割が全く異なるためだからです。基本設計で決めた機能を実現するために詳細設計は存在すると覚えておきましょう。

基本設計の一般的な取り組みや特徴について解説された記事はこちら＞＞

MVCモデルとは

MVCモデルとはユーザインタフェースをもつシステムを構築する上でプログラムの中身を整理するためのデザインパターンです。役割ごとに分割をしてプログラミングを実施する際に向いている手法です。このMVCモデルでも基本設計と詳細設計のポジショニングを確認することが出来ます。

M（Model）/　ビジネスロジックとなる部分 / 詳細設計
V（View）/ 　画面の表示や入出力となる部分 / 基本設計
C（Controller）/　ModelとViewを制御する部分詳細設計

詳細設計の取り組みに必要な要素

詳細設計の取り組みにおいて必要な要素について解説していきます。

機能分割

基本設計にて明らかとなった”機能一覧”を各機能が最小単位となるまで仕分けを行います。
最小単位まで仕分けをすることでプログラムの作成を効率よく実践出来ます。
機能を最小単位まで分割し、インターフェースやバッチ、機能設計を実施します。

例)エンジニア向け案件紹介サイト
このWEBサイトにおける必要な機能要素を最小単位になるまで落としていきます。

モジュール	説明
検索機能	入力した条件に該当するデータを出力します。
案件一覧	検索条件に該当する案件情報を表示します。
案件詳細ページ	指定された案件情報の詳細ページを表示します。
エントリー	選択された案件へエントリーをします。
登録	必要な情報を入力し登録を完了します。

データフロー

データの流れを示す図、通称データフロー図の作成を行います。
データフローとは機能間のデータ処理の流れを指します。
詳細設計にて用いられるのはDFD（データフロー図）が一般的です。

DFD（データフロー図）
システムやプロセスの情報の流れを長方形や円などの図形を用いてマップ化する方法をDFD(データフロー図)といいます。システムに精通していない方にも分かりやすいことから長年支持を集めております。

データベース設計

データベースの物理設計、論理設計、索引設計を行います。これは主にシステム内部のファイルやデータの取り交わしなどユーザーには見えない部分です。

・物理設計
性能要件や可用性を考慮したデータベースを設計
・論理設計
データを整理し、使用するデータベースの種類に合わせて変換をさせるための設計
・索引設計
データベースの性能を向上させるための設計

入出力の設計

入出力する情報について、様々なケースに合わせたレイアウトの設計を行います。
基本設計で決めたインターフェースをどのようにプログラムを組み立てて表現するのかを落とし込むための設計です。

例①）エラー処理時
プログラムの停止、メッセージの出力、エラーの原因提示など

詳細設計書を作成する際のポイント

設計書はプロジェクトに関わる多くの方が確認する大切なドキュメントです。
この設計書一つで作業の効率や進捗を大きく左右します。
以下に記載する作成時のポイントを抑えて取り組みましょう。

目次・見出しの作成

どこに必要な情報が記載されているのか一目で分かるようにしましょう。

目次・見出しを見やすくするポイント
・フォントの変更を行う
本文と統一感を持たすように心がけ、サイズ変更やボールド（強調）なども駆使しましょう。
・段落前に余白を活用する
見出しに階層を付けて複数管理している場合、見出しと見出しの間に余白を付けて管理すると見やすくなります。

難しい言葉や造語の禁止

誰が読んでも共通認識で伝わるように言葉を選びましょう。
理解出来ないだけでなく相手にストレスを与えてしまいかねないので要注意です。

難しい言葉や造語の例
・難しい言葉
小職（しょうしょく）、齟齬（そご）、感服（かんぷく）、御意（ぎょい）など
・造語
アベノミクス、シーガイアなど

一文は短く、主語は前に

１文で伝えることは一つ、そして理解しやすいように主語を前に置きましょう。
長文にありがちなのが、１文にいくつもの意味をもたせてしまい読み手が理解が難しくなることがあります。以下の例をご覧になってイメージしてみてください。

良い例・悪い例
・悪い例✕
鬼退治に行くには仲間がいなくてはなりませんので、猿やキジを仲間にしてから旅にでようと決めた桃太郎(主語)
・良い例◎
桃太郎(主語)は猿とキジを連れて鬼退治に行きました。

曖昧な表現の禁止

曖昧な表現をすると主張がぼやけてしまったり、誤解を与えてしまうリスクがあります。
具体的な数字を用いることで複数の読み手にも共通認識を持ってもらえるようにしましょう。

良い例・悪い例
・悪い例✕
費用対効果は前年度に比べてだいぶ良くなります。
・良い例◎
費用対効果は前年比の3倍です。

見やすさを徹底的に意識

常に読み手の視点を持ち、誰もが見やすいものに細かな点への配慮をしましょう。
小説や漫画などと違いただでさえ読むのに苦労する設計書においては非常に重要なポイントです。

見やすくするコツ
・図や表の活用をする
・字体の統一をさせる
・インデントの調整をする
・色に規則性を持たせる
など

表記ゆれが存在しないか要注意

表記ゆれが原因で誤解を招くだけでなくストレスを与えない文章を心がける為にも細かな配慮をしましょう。

表記ゆれの例
「インターフェイス」　『インターフェース』
「ユーザ」『ユーザー』
「ウェブ」『Web』
「182(半角)」『１８２(全角)』
「おいしい」『美味しい』

まとめ

詳細設計を理解するために一般的な取り組みに必要な要素を紹介させて頂きました。
詳細設計とは『これまでの決定事項を実現するために細かく落とし込んでいく工程』です。
要件定義や基本設計など上流工程時のお客様向けの視点から一変し、詳細設計の工程ではお客様の要望を実現すべく、それらを開発者側の視点（特にプログラマー）で読んで理解できるように橋渡しを行う重要な工程になっております。プログラマーが迷いなく理解できる詳細設計書を作成しお客様の要望を叶えるシステム開発を実現しましょう。