詳細設計は詳しく設計書を書く事です！
システム開発では、基本設計書の次に作成するのが詳細設計書です。
基本設計書がどんなものかまだよくわかってない人は以下の記事を参考にしてください。
詳細設計書から少し技術よりの設計書を作成しなくてはなりません。
SEもしくはプログラマーさんの持っているプログラミング知識を
うまく駆使して設計書を作成するのが詳細設計書です。
SE・システムエンジニアを目指している皆さん。
こんにちは！
現役SEで当サイトを管理しているariariです☆彡
今回は、詳細設計について詳しく解説していきます。
詳細設計書からは新人や初心者の方が実際に作成する機会は意外に多いです。
詳細設計書がうまくできていないと正しいプログラムが作れない事も。。。
今回は、そんな詳細設計書の作業内容について丁寧に解説をしていきます！
今すぐにでもIT企業に就きたい！という希望の方は、IT業界に特化した無料転職エージェント「マイナビ IT AGEN」・「社内SE転職ナビ
」・「ウズキャリIT」などのエージェントを活用するのをおすすめします。
詳細設計書の具体的な作業内容を初心者向けに解説！
はじめまして。将来SE希望の文系女子
清水満里奈です♡
はじめまして！
僕もSEを目指しています未経験者の遠藤修一です♪
了解です☆彡
今回も少し詳しく解説します。
頑張って最後まで付き合ってくださいね(*^▽^*)
詳細設計を必要としない開発現場もある？
詳細設計は『システム機能の内部構造を作成する』開発工程です。
プログラミングの前にシステムの内部構造を整理することで同じような処理が増えることを防ぎ、
生産性の確保や保守性の向上へとつながっていきます。
ただ。。。詳細設計を目に見える形で作成するかは、重要なんですが、プロジェクトの規模、
開発組織のルール等にいくぶん変わってきたりします。
開発スピードを重要視するWebメディア等の開発では、詳細設計書を作成するよりも
プログラミングやテストを優先して素早くリリース（公開）する傾向もありますね(;^_^A
実は企業などのシステム開発でも詳細設計書を必ず作るとは限らないです。
品質を重視したシステム開発では構造や処理の流れをまとめるために詳細設計書を作成することが多いですね。
詳細設計書作成の進め方について
SEやプログラマーの方々は案外無意識で使い分けている方が多いと思いますが、
詳細設計にはおおよそ２つの作業がありますね☆彡
すみません。プラットフォームとは何ですか？
ここでいうプラットフォームとはシステムやアプリを動かすことの土台のことです。
ひらたく言えばハードウェア等まで含まれますが、今回はアプリケーションSEに特に関係する
プログラミング言語やフレームワークの事を言ったりしますね。
■プラットフォームに依存しない詳細設計
例えると、画面レイアウトだとヘッダーやフッターは同じ表示のため共通処理となることが多いです。
内部処理(ビジネスロジック)も同様に同じような処理は共通化されますね。
実際の実装（プログラミング）工程では、最初に先ほどの設計した共通処理の部分を作成する事で
生産性をあげます。
つまり作業をスムーズに進められると言う事ですね☆彡
そうです♪このように、共通化作業はどのようなプラットフォーム（言語やフレームワーク）でも
必要な作業の為、「プラットフォームに依存しない詳細設計」となるのです。
あと、処理の部品をまとめるにあたっては、クラス図やモジュール構造図を用いることも多いです。
■プラットフォームを考慮した詳細設計
基本設計で作成した画面設計書や先ほどの作業でまとめたクラス図やモジュール構造図を参照しながら、
どこでどういう処理をするのかを割り振っていきます。
え～とどういうことですか(;^_^A
例えば、システムやアプリ等の画面では
『使う人側によった処理』と『サーバ側によった処理』に分けられますね。
使う人側とは業界では「ユーザー側」といいますが、プラットフォームによって言い方が変わります。
例えばWebアプリの場合だとフロントエンドと言いますし、ネイティブアプリの場合は
スマホアプリと呼んだりしますね。
Webアプリの場合はサーバーサイドに画面遷移を含めた大半の処理を実装し、ネイティブアプリの場合は
スマホアプリに画面遷移や画面アクション等の処理を実装しつつ、サーバーサイドに
API（スマホとサーバーのインターフェス機能）という形でデータベースの参照・更新機能を実装する。
このようにプラットフォームに合わせた内部構造の決定も詳細設計に含まれる。
いろいろな詳細設計書を紹介
それでは、ここからはいろいろな詳細設計書を紹介していきますね☆彡
色々な詳細設計書を説明
それでははｈでｄれｒそｓ詳細設計書を具体的に紹介していきます☆彡
ただ実施は、詳細設計で作成するドキュメントは組織やプロジェクトによって異なるため、
実務をする上では上位者に確認をした方がいいでしょう☆彡
■クラス図
システムを構成するクラスの関係を表す資料で、プログラミングする際の見取り図になり、
作業の優先順位をつけたり、複数名で作業を分担する際に有効です。
画面設計書やアクティビティ図から必要なクラスを洗い出しながら各クラスの関係を整理していきます。
クラス図は自分の頭の整理に役立つだけでなく、プロジェクトメンバーとの対話にも有効です。
ただ、細かく整理すると時間を要するため主要なクラスに絞って整理するのも良いでしょう。
■モジュール構造図
モジュール構造図はメインフレームのシステム開発で用いられる資料で、COBOL等のモジュールの関連性を
表現しています。
メインフレームのシステム開発のため作成する機会のある人は少ないでしょう。
作成の手順としては、基本設計書の資料（画面設計・帳票設計・バッチ設計等）をもとに各機能を
実現するために必要な処理を書き出しながら下位レベルにブレークダウンをしていきますね。
その後、共通化できる処理を考えるとい流れです。
■アクティビティ図
アクティビティ図はユーザーの操作とシステム処理の流れが分かる資料。
処理の流れが分かることはもちろん、操作に応じた処理をどこに実装するかが分かるため、
「スマホアプリ＋サーバーAPI」のようにそれぞれで実装しなければならない場合の役割分担に役立ちます。
では、より詳細なメッセージのやりとり（どのクラスで実現するか等）を整理する場合は、
シーケンス図にて整理します。
基本的な書き方はフローチャートと同じで、利用者のアクションやシステム処理を枠で囲み、
それを矢印でつないでいく。作成するための情報源は、基本設計で作成した業務フローや画面設計書です。
■シーケンス図
シーケンス図はアクティビティ図よりもシステム内部処理をさらに細かく記載した資料で、
クラスやオブジェクト間のやりとりを時間軸に沿って表現します。
資料の使い方としては、アクティビティ図でざっくりと利用者と機能の流れを把握し、
より詳細な処理を把握するためにシーケンス図を見ます。
縦軸が時間、横軸がユーザーやシステム機能（オブジェクト）である。ユーザーからのアクションを受けて、
オブジェクトがどのような情報を受け取り、次のオブジェクトにどのような情報を渡しているのかを
矢印で表現します。
その他にも処理構造を表現するための記述があり、上記サンプルでは「loop」と「opt」が用いられています。
「loop」とはその操作・処理が繰り返し行われることで、「opt」とは特定の条件を満たした場合に
行われるもの。上記サンプルではloopで商品検索、optで商品詳細画面への遷移を表現しています。
シーケンス図の作成にあたっては、基本設計工程で作成した業務フローや画面設計書だけでなく、
同じ詳細設計工程で作成するクラス図も必要となりますね。
■IPO（処理機能記述）
IPOは機能の入力・処理・入力を記載したもの。入力=Input、処理=Process、出力=Outputの頭文字を
とってIPOと呼ばれます。
私の経験上、バッチ処理はIPOで内部処理を整理することが多いように思います。
出力データを作成するために、入力データを用いてどのような処理を行うかを記載します。
あまり細かく書きすぎると「ロジックを日本語に訳した資料」となってしまうため、処理の概要が理解できる
程度で良いです。
まとめ
詳細設計書は内部構造を整理するための手段でしかないため、どのような資料で整理しても基本的に問題ないです。ただ、組織で誰も見たことのない資料は受け入れられにくいため、過去のプロジェクトで作成した資料を参考に作っていく方が無難ですね♫
あるいは、組織のルールや企業間の契約によって作成すべき資料が取り決められている場合もあるので、
まずはプロジェクトマネージャや組織の上位者に確認することをお勧めします。
はい！よく理解できました。
管理人さん本日のご教授ありがとうございました。
今すぐにでもIT企業に就きたい！という希望の方は、IT業界に特化した無料転職エージェント「マイナビ IT AGEN」・「社内SE転職ナビ」・「ウズキャリIT」などの複数のエージェントを活用するのをおすすめします♪
複数エージェントを利用するメリット
- 相性の良い担当者と出会える確率が上がる
- 1回で複数の企業や開発案件に応募ができる
- 自分のスキルに見合う求人や案件を見つけてもらい提案してもらえる
- etc…
コメント