システム開発工程における詳細設計は、どんな作業をすればいいのか、どんなアウトプットを出せばいいのか疑問を持つことも多いと思う。
そこで今回は詳細設計のサンプルを紹介しつつ書き方も簡単に説明していく。
なお、詳細設計は内部設計と呼ばれることもあるが、当サイトでは詳細設計という呼び方で統一する。
目次
詳細設計を必要なのか？ →「時と場合による」
詳細設計は『機能の内部構造を整理する』工程である。実装前に内部構造を整理することで同じようなロジックが乱立されることを防ぎ、生産性の確保や保守性の向上へとつながっていく。
ただ、詳細設計のアウトプットを目に見える形で出すかは、重視するもの（スピードor品質）やプロジェクト規模、組織のルール等によって変わってくる。
例えばスピードを重視するWebメディア開発では、詳細設計書を整理するよりも実装・テストを優先して素早く公開する傾向にある。SIerのシステム開発でも詳細設計書を必ず作成するとは限らないが、品質重視のシステム開発では構造や処理の流れを整理するために詳細設計書を作成することが多い。
また、詳細設計書は「プログラムソースを日本語で書くこと」では無い。そういった資料は「コーディング仕様書」と呼ばれ、オフショア活用（海外へのシステム開発委託）で作成することもあったが、品質とコストのバランスから近年ではほとんど作られなくなった。
詳細設計書の進め方
エンジニアやプログラマーの方々は無意識で使い分けていると思うが、実は詳細設計には２つの作業が存在する。
・プラットフォームまで考慮したレベルの詳細設計
プラットフォームとはシステムを動かすことの土台のことで、広義で言えばハードウェア等まで含まれるが、この記事ではアプリケーションエンジニアに特に関係するプログラミング言語だったり、フレームワークだったりを指すこととする。
どちらを先に行うかは決まっていないが、私は「①プラットフォームに依存しないレベルの詳細設計」を先に整理することが多い。
プラットフォームに依存しないレベルの詳細設計
例えば、画面レイアウトであればヘッダーやフッターは同じ表示のため共通ロジックとなることが多い。ビジネスロジックも同じで似たような処理は共通化される。そして実装（プログラミング）工程では最初に共通部品を作ることで生産性を確保する。このように、共通化作業はどのようなプラットフォーム（言語やフレームワーク）でも必要となる作業であるため、「プラットフォームに依存しないレベルの詳細設計」なのである。
なお、処理の部品を整理するにあたっては、クラス図やモジュール構造図といったものを用いることが多い。
プラットフォームまで考慮したレベルの詳細設計
基本設計で作成した画面設計書や前述の作業で整理したクラス図等を見ながら、どこにどういう処理を実装していくのかを割り振っていく。
例えば、画面機能は「ユーザー側に実装する処理」と「サーバー側に実装する処理」に分けられる。”ユーザー側”というのはプラットフォームによって言い方が変わり、Webアプリの場合はフロントエンドと呼ぶし、ネイティブアプリの場合はスマホアプリと呼んだりする。
Webアプリの場合はサーバーサイドに画面遷移を含めた大半の処理を実装し、ネイティブアプリの場合はスマホアプリに画面遷移や画面アクション等の処理を実装しつつ、サーバーサイドにAPI（スマホとサーバーのインターフェス機能）という形でデータベースの参照・更新機能を実装する。
このようにプラットフォームに合わせた内部構造の決定も詳細設計に含まれる。
詳細設計書のサンプル
それでは、詳細設計書のサンプルを紹介していく。
下記は情報処理推進機構が掲載している教育用の詳細設計資料である。
情報処理技術者試験を開催しているだけあって、他のどのサイトよりも信用できる資料が充実しており実務者の私から見ても参考になる。ただ、資料が大量にあって探すのに苦労するため、特に役立つサンプルを下記に述べる。
> ユースケース/アクティビティ図
> クラス図/画面レイアウト/ER図
> シーケンス図等
詳細設計書の成果物（例）
前述の情報処理推進機構が取り上げている詳細設計書を具体的に紹介していく。
ただ、身も蓋もない話をすると詳細設計で作成する成果物は組織やプロジェクトによって異なるため、実務をする上では上位者に確認をした方がいいだろう。
当記事では、私が実際に作った経験のある資料をピックアップして紹介していく。
■静的な資料（構造を表現）
・クラス図
・モジュール構造図
■動的な資料（流れを表現）
・アクティビティ図
・フローチャート
・シーケンス図
・IPO
クラス図
システムを構成するクラスの関係を表す資料で、プログラミングする際の見取り図になり、作業の優先順位をつけたり、複数名で作業を分担する際に有効である。
画面設計書やアクティビティ図から必要なクラスを洗い出しながら各クラスの関係を整理していく。（記載ルールは下記を参照）
クラス図は自分の頭の整理に役立つだけでなく、プロジェクトメンバーとの対話にも有効である。ただ、細かく整理すると時間を要するため主要なクラスに絞って整理するのも良いだろう。
モジュール構造図
モジュール構造図はメインフレームのシステム開発で用いられる資料で、COBOL等のモジュールの関連性を表現している。メインフレームのシステム開発のため作成する機会のある人は少ないだろう。
作成の手順としては、基本設計書の資料（画面設計・帳票設計・バッチ設計等）をもとに各機能を実現するために必要な処理を書き出しながら下位レベルにブレークダウンをしていく。その後、共通化できる処理を考えるとい流れである。
アクティビティ図
アクティビティ図はユーザーの操作とシステム処理の流れが分かる資料。処理の流れが分かることはもちろん、操作に応じた処理をどこに実装するかが分かるため、「スマホアプリ＋サーバーAPI」のようにそれぞれで実装しなければならない場合の役割分担に役立つ。
なお、より詳細なメッセージのやりとり（どのクラスで実現するか等）を整理する場合は、シーケンス図にて整理する。
基本的な書き方はフローチャートと同じで、利用者のアクションやシステム処理を枠で囲み、それを矢印でつないでいく。作成するための情報源は、基本設計で作成した業務フローや画面設計書である。
シーケンス図
シーケンス図はアクティビティ図よりもシステム内部処理をさらに細かく記載した資料で、クラスやオブジェクト間のやりとりを時間軸に沿って表す。
資料の使い方としては、アクティビティ図でざっくりと利用者と機能の流れを把握し、より詳細な処理を把握するためにシーケンス図を見る。
縦軸が時間、横軸がユーザーやシステム機能（オブジェクト）である。ユーザーからのアクションを受けて、オブジェクトがどのような情報を受け取り、次のオブジェクトにどのような情報を渡しているのかを矢印で表現する。
その他にも処理構造を表現するための記述があり、上記サンプルでは「loop」と「opt」が用いられている。「loop」とはその操作・処理が繰り返し行われることで、「opt」とは特定の条件を満たした場合に行われるもの。上記サンプルではloopで商品検索、optで商品詳細画面への遷移を表現している。
シーケンス図の作成にあたっては、基本設計工程で作成した業務フローや画面設計書だけでなく、同じ詳細設計工程で作成するクラス図も必要となる。
IPO（処理機能記述）
IPOは機能の入力・処理・入力を記載したもの。入力=Input、処理=Process、出力=Outputの頭文字をとってIPOと呼ばれる。
私の経験上、バッチ処理はIPOで内部処理を整理することが多いように思う。（基本設計工程でバッチ処理定義書として整理することが多い）
出力データを作成するために、入力データを用いてどのような処理を行うかを記載する。あまり細かく書きすぎると「ロジックを日本語に訳した資料」となってしまうため、処理の概要が理解できる程度で良い。
さいごに
今回は詳細設計書のサンプルや書き方を紹介してきた。
各資料は内部構造を整理するための手段でしかないため、どのような資料で整理しても基本的に問題ない。ただ、組織で誰も見たことのない資料は受け入れられにくいため、過去のプロジェクトで作成した資料を参考に作っていく方が無難だろう。
あるいは、組織のルールや企業間の契約によって作成すべき資料が取り決められている場合もあるので、まずはプロジェクトマネージャや組織の上位者に確認することをお勧めする。
以上、参考になれば幸いだ。
要件定義〜設計工程の関連記事はこちら。
参考文献
IPA『開発技法の実践的演習コース教材（オブジェクト指向）』
コメントを残す