書いた人：NEO-TAKAHASHI（システムエンジニア）
どうもこんにちは。Zooops Japan（ズープス ジャパン）一のナイスミドル（修行中）なマネージャー・NEO-TAKAHASHIです。 前回は、主に上流工程と呼ばれる「要件定義～基本設計」を少し掘り下げて紹介しました。 今回はその続き。巷で「下流工程」と呼ばれる「詳細設計」にスコープ（範囲）を当てたいと思います。▼目次 １．いざ！ 「詳細設計」! ２．本日のおさらい ～ここでちょっと寄道～ モジュール化設計 ３．あとがき ▼関連記事 ・（その１）V字モデルで「システム開発」の流れについて知ろう！ ・（その２）「要件定義」と「基本設計」 ・（その３）「詳細設計」 ・（その４）「製造」から「システムリリース」まで
いざ！ 「詳細設計」!!
いきなりですが、設計とは言葉通り設計図を書くことです。我々がシステムエンジニア（以下、SE）・プログラマー（以下、PG）をプロとしてやっていく以上、これを書けない人はモグリなんじゃないか!? と私なんかは思ってしまいます。 システムエンジニアの仕事は、よく家を建てるときの工程と比較されますが、設計書とは家を建てる際の設計図のようなものです。 建築士と呼ばれる人は、１級建築士などといった国家資格を持っていますね。でも、我々はこれといった資格を保有していなくても、SEやPGと名乗ることができます（中には、品質担保の指標として国家資格である「基本情報技術者」「応用情報技術者」といった資格を取得させる企業もありますが）。 基本設計の際には触れませんでしたが、上流工程である基本設計はユーザが理解できるように起こす、といった裏テーマがあります。それに比べ詳細設計は、PGが理解できるように起こすことが必要になってきます。 言い換えると、専門外の人（システムオーナー・ユーザ側）が理解するための設計図が基本設計であり、作り手・専門家（システムベンダー・SE・PG）が理解し、システムを構築するための設計図が詳細設計です。 前置きが長くなりましたが、設計書の意義、基本設計と詳細設計の意味がわかってくれたら嬉しいです。
システムエンジニアとプログラマーの橋渡しをするのが「詳細設計」ってイメージするとわかりやすいかもね
その１：機能分割定義 クラス図 その２：データフロー DFD図 ※詳細設計フェーズにおいてはデータの流れを示すフロー図を書きます。基本設計フェーズではワークフロー（業務フロー）を作りました。 その３：画面設計書／バッチ処理設計書（モジュール設計書） モジュール名称 役割 引数・戻り値 処理概要（※以下で詳しく記載します） 備考 などなど その４：DB関連 テーブル定義書 ストアドプロシージャ（PL／SQL）定義書 モジュール名称 役割 引数・戻り値 処理概要（※以下で詳しく記載します） 備考 などなど ※処理概要以外の項目については言葉通りです。
案件によって設計書の記載ルールは異なりますが、詳細設計書はPGが読み、プログラムを作成するためのものです（ソースコードを直接設計書に記載しているプロジェクトもあるでしょうが、二度手間になってしまうのでそのままプログラムを作成した方が効率は良いでしょう）。 ちなみに、上記の「画面設計書／バッチ処理設計書」の処理概要の部分には、新人PGにはとっつきにくい世界が広がっています。その一つに日本語に対する理解があると思います。 詳細設計書の一つの存在意義に、プログラムを作成するための設計書である、と言うのがあります。 「NEOさん、さっきからそう言ってるじゃないっすか……」と思うかもしれませんが、設計書を書くSEの所属する組織（会社だったり部署だったり）は、プロジェクトによって変わってくる場合があります。つまりプロジェクトメンバーが同じ会社の人間で、しかもPGが部下（あるいは上司）である、という保証はどこにもありません。また、PGが日本語ネイティブである、という保証もありません。 そのため、設計書は「PGであれば誰でも理解出来る」ように書く必要があります。一般的な日本語を書ければ問題ないことなのですが、これがまた難しい。なるべく簡潔に書くことが望ましいのですが、システムの機能として何かが欠如してしまっては障害の元となるため、冗長にならない程度に正確に書く必要があります。複数の意味を持つような言葉の乱用や表記ゆれも避けるようにしましょう。また、一部の組織だけで通じるような独自用語もNGです。設計書の書き手と読み手の理解が一致するような文章で表現する必要があります。仕様やロジックを正確に伝達するために、図や表で表現することも必要になってきます。 さらに、詳細設計書のもう一つの存在意義として「仕様の伝達（ナレッジトランスファー）」があります。 システムは開発して終わり、ではありません。システムがもたらす効果によって利益を上げたり、経費を削減したりしますので、システムが稼働してからは運用をしていくことになります。 運用・保守フェーズになった際にも設計書を用います。機能のひとつで障害が発生した際に、この設計書を見て仕様を確認し、プログラムの修正やデータの整備などをして、システムが障害以降も動けるようにメンテナンスをしていくことになります。もし設計書に記載されていない処理がプログラムにあって、それが障害を引き起こしていた場合、ソースコードを読み解くまで原因にたどり着けず、システム復旧までには多くの時間を要することになります（設計書に不備がある時点で、そのシステムの潜在バグの件数は計り知れません……）。 以上のように、詳細設計書の存在意義として２つ紹介しました。設計書によって、「システム開発の成否」や「システムの寿命」が決まって来るということを理解してくれると嬉しいです。 実際にコーディングをしない（したことのない）SEの書いた設計書は、仕様の漏れや処理の考慮漏れ（不足）が目立つように感じます。経験の浅いSEの設計書は、エラー発生時の考慮が不足しがちです。こうした場合、SEよりも経験豊富なPGでなければ、まともなプログラムは作成出来ません。 あらゆる外的要因（対外システム、利用環境、時事的なこと、などなど）に対応し、考慮不足を全てカバーすることは、おそらく不可能ですが、不可能であればこそ、不具合に対するカバー率を70％、80％、……99％となるように、システムを構築する要素の知識を日々蓄積していく個々の姿勢が大事になってきます。 今後は今回説明した２つの意義を意識して、「良い設計書」を書くようにしてみましょう！本日のおさらい ●設計書はPGがプログラムを書くためのもの。誰が見てもわかるように書こう！ ※ソースコードを書くのは、本来の目的から外れてしまうよ ●システムに運用はつきもの。設計書は「仕様の伝達（ナレッジトランスファー）」としても超重要
～ここでちょっと寄道～
モジュール化設計
【意味】 複雑で巨大なシステムやプロセスを設計・構成・管理するとき、全体を機能的なまとまりのある「モジュール」に要素分割すること。設計・製造時の擦り合わせ作業をできるだけ少なくするために構成要素（部品）の規格化・標準化を進め、その相互依存性を小さくすることをいう。 【つまり、どういうこと？】 ソフトウェア開発の基本原則です。機能をモジュール（部品）に分け、モジュール同士を疎結合することでシステム、ソフトウェアを構築する設計手法のことを指します。
こうした言葉を使うと、「なんのこっちゃ、わからんわい」と思う人も多いかもしれません。しかし、それは当然のことで、こうした設計手法を提唱している方はどこかの情報工学者だったり、学術的な視点で発表したりするので、全てを理解するのは難解です。ただ手法自体は、至って普通に皆さんのシステム開発に取り入れられています。 簡単に言えば「まとめることのできる機能ごとに設計をするよ」、ってことです。 例えば、ある市営の図書施設の業務システムを構築するとしましょう。 この場合、現状保持している書籍の在庫を管理する部分、登録されているユーザの管理をする部分が必要になります。だいぶ大まかですが、要はそういう部分（在庫管理とユーザ管理）をまとまりを持つモジュール（部品）として考え、システムを構築しましょう、ということです。 ただ、前述のように、こうした設計手法は学問のひとつであり、一朝一夕で理解できるものではありません。在庫管理と言っても、書籍の特徴（名前・ページ数・経過年数・出版社・作者・など）、ステータス（貸出中・在庫あり・紛失中・購入予定・廃棄予定・など）、その他にも構成する要素はあります。 システムの利用用途によっても部品のまとまりとするスコープは変わってくるでしょう。難しいのは、モジュールとは正解がひとつではない、極めて抽象的なものであるということです。 様々なプロジェクトの経験やシステム構築における設計の経験を積むことで自身での理解が深まり、反復学習を行うことで身についていくものだと思います。 自身の成長のため、日々、コツコツ努力することが大事になってきますね。
