システムを開発するにあたって必要な工程の１つである詳細設計。なんとなく開発の流れは理解しているものの、成果物が明確になっていないケースや基本設計との違いがあいまいな方も多いのではないでしょうか。ここでは詳細設計と基本設計の違いや、詳細設計における具体的な成果物を解説します。
詳細設計とは？
まずは、詳細設計とはどのようなものなのか紹介していきます。
目的
詳細設計とは実際にシステムを構築する前段階に行う工程です。そして、プログラミングによる開発ができるように、システムの内部構造を検討する目的で行われます。システム開発においてはこの詳細設計書がもとになって開発が行われると考えてよいでしょう。
たとえば、各プログラムの処理フローやデータの流れなどを設計書にまとめる必要があります。基本的にはプログラマー視点の成果物であるため、明確なフォーマットはプロジェクトによって異なることがほとんどです。納品物として提出する必要がなく、内部でのみ管理すればよいケースも存在します。
役割
詳細設計の役割は、基本設計で定義したことを開発者視点で取りまとめることです。詳細設計を作成することにより、プログラマーは自身のやるべきことが明確になり、効率よく作業を行うことができます。そのため、システム開発においては顧客の要望とシステム開発を繋ぐ重要な役割を果たしている資料になります。
基本設計との違い
ここでは詳細設計と基本設計の違いを紹介します。基本設計はユーザー視点でシステムを確認し、どのような挙動を求めているのかを明確にする工程です。その一方で、詳細設計は開発者視点で求めている基本設計の要件を詳細化し、開発者がプログラミングできるレベルまで落とし込んでいくフェーズになります。
例えば、基本設計を「郵便番号から住所の一部を自動導出するボタンを設置する」と定義すると仮定しましょう。そうすると、詳細設計では「郵便番号と住所関係性のテーブルを作成し、どのようなロジックでデータを取得するのかを決める」といった感じになります。
詳細設計の成果物一覧
詳細設計工程では、様々な成果物が求められます。ここからは詳細設計で求められる成果物を紹介します。
状態遷移図
システムの状態を定義しておくことはテストの際に抜け漏れを防いだり、重複を可能な限り減らしたりするうえで重要です。状態遷移図はそのようなシステムの状態を図で表したものになります。
状態遷移図とはシステムの状態が遷移する様子を図に書いて図形や矢印などで表現したものです。状態遷移図では四角で表現された「状態名」、矢印で表現された「遷移」、その矢印のそばにどういう動作を行ったのか記入する「イベント（アクション）」で構成されます。
シーケンス図
シーケンス図とはアクティブ図よりもシステムの内部処理に着目して、より詳細に表記した資料になります。システムの概要・仕様・処理の流れを記載し、システム開発の設計書として使用されます。細かな粒度で記載を行うため、クラスやオブジェクト間のやり取りまで時間軸に沿って詳細に定義している点が特徴と言えるでしょう。
クライアントとのコミュニケーションにおいてもアクティブ図で大きな流れを確認し、詳細な処理をシーケンス図で問題がないか確認していくことになります。改修などの議論をする際にも、アクティブ図とシーケンス図をベースに話をすると円滑に進むでしょう。
画面遷移図
画面遷移図とは、Webアプリケーションやその他業務システムの開発において、どのように画面遷移が行われるかを表した図になります。画面遷移図は要件定義の段階や基本設計の段階で作成することもありますが、最終的に決定するのは詳細設計の工程になることもあります。
どのくらいの画面数があるのか、どのような画面遷移になるのかも必要ですが、各画面で責任部門を明確にしたりする必要が出てきます。また、完成後のマニュアル作成やサポート体制を検討する上でも重要な要素となります。
クラス図
クラス図とは、システムを構成するクラスの関係を表す資料です。プログラミングをする際の元データとなり、作業の優先順位や複数名で優先順位をつけたりするのに重要な資料になります。このクラスはインターフェースで送信されてきたデータを受け取るなど、インターフェースともつながりが深いです。そのため、インターフェース設計書や入出力設計書をベースに検討をすることもあります。
アクティブ図
アクティブ図とは、ユーザーの操作とシステム処理の流れがわかる資料になっております。システムが複数ある場合やフロントとバックエンドでそれぞれ処理がある場合には、どこで何の処理を行うのかまでを明記します。これにより、それぞれで実装しなければならない機能を明確にすることができます。
一方、詳細な情報のやり取りなどはここでは作成しません。ここでは、全体の処理の流れがわかるような資料を作成することを目的とします。詳しい処理の流れやどのクラスで何を実現するかといった細かな定義はシーケンス図で整理をするのが一般的になっています。
書き方はフローチャート図などと同じで、利用者やシステム処理を枠で囲んでおき、線でつないで処理の流れを明確にしていきます。
モジュール構造図
モジュール構造図とは、モジュール化が用いられたシステムで必要になってくる構造図です。構成するモジュールがどのように分割されて、各モジュールがどのような処理を行うのかを示した図になります。
他の設計書と同じように各モジュールを線で繋いで関係性を表していきます。そのため、視覚的にわかりやすい資料になります。
モジュールの関係性や相互作用を把握していないと開発はできないため、詳細設計で必要な成果物の１つです。
入出力設計書
入出力設計書とは各機能でどのような情報がインプットとして用いられ、どのような情報がアウトプットとして出てくるかを表した設計書になります。画面設計書と連動して定義され、画面のインプット項目、アウトプット項目を制御する設計書になります。
バッチ処理設計書
大きなシステムになるほど、夜間に自動で処理をしたり、システムの裏で自動で処理する機能が増えてきます。この機能を定義するのが、バッチ処理設計書になります。バッチ処理設計書では、バッチの入力・加工・出力の３つに分けて検討を進めます。また、バッチのトリガー（定時起動なのか、何かしらのトリガー起因なのか）の定義も行います。また、並列処理ができないかの検討を行い、バッチの処理時間を短縮することも求められます。バッチ処理設計書はこのような検討を繰り返し行いながら、構築するシステムにおける最適化を目指します。
テスト設計書
テスト設計仕様書はテスト対象の全体を見据えて、テストの指針や骨格を定めることを指します。その後、テスト設計仕様書に合わせてテストの詳細な定義を決めていくのがテスト設計書になります。単体テストや結合テストにおいてはこのテスト設計書をベースにテストを行います。
テスト設計仕様書を作成し、テスト設計書を定義する目的としては以下の通りです。
- 誰がやっても迷わずにテストができること
- 誰がやっても結果が同じになるようにすること
- テストの結果が明確にわかるようにすること
テストはプログラムが正しく機能しているかを判定する意味合いがあるために、明確な基準が求められます。そのためにテスト設計書を作成します。
データベース物理設計書
データベースの論理設計書作成では要件定義で定めたER図をもとに正規化やテーブル変換を行い、論理的に要件を満たしているテーブルが出来上がっているかを確認します。一方、物理設計書では実際のデータベース環境にあてはめ、予定通り機能するか設計書を作成しながら検証していきます。可用性などを考慮しながら、インデックスを付与したり、それぞれの項目のデータ型を決定したりします。また、想定されるデータ量などを確認して、データベースのスペックやデータ容量の設定も行います。
外部インターフェース設計図
外部IF設計図では社内外の他システムと連携するときの仕様を定義します。外部IF設計図を作成する際には以下のような項目を定義します。
- 接続先
- プロトコル・手段
- タイミング
- インターフェース項目仕様
- 認証・セキュリティ
- 例外処理
また、この設計書を作る段階までにインターフェースのインとアウトの項目をそれぞれ定義し、正しく必要な項目が網羅されているかマッピングを行い検証します。
IPO（処理機能記述書）
IPO（処理機能記述書）とは、システムの機能・ビジネスロジックの処理内容を入力（Input）、処理（Process）、出力（Output）の３形式で表現した図式のことです。
各機能において、どのような情報がインプットとなり、どのようにデータを加工して、どこに出力を行うのかを定義します。どのステップで入出力を行うのかを明らかにするため、プロセスを重視したい場合に適した書き方になります。また、わかりやすく書くことで、修正が発生した場合の影響範囲の特定などにも役に立ちます。また、システム処理の概略もわかってきて、開発の難易度も明らかになってくるので、開発工数の試算にも役立ちます。
詳細設計の進め方
ここでは詳細設計の進め方を基本設計の具体化と詳細設計書の作成といった２ステップに分けて解説します。
基本設計の具体化
詳細設計は基本設計をベースにして詳細化していく作業になります。まずはチームメンバー全員が基本設計の内容を丁寧に読み込み、基本設計の内容を明確にしましょう。またチームメンバーで読み合わせを行い、今後の作業で認識相違が発生しないようにしましょう。
全員が資料を読み込んで、認識合わせが完了したら、基本設計を具体化していきましょう。各機能を開発者視点で確認し、プログラミングができるレベルまで１つ１つの機能を落とし込んでいきます。また、オブジェクトを共通化するなど、して効率化できないかも検討していきましょう。
詳細設計の作成
一通り検討が完了したら、詳細設計書を作成しましょう。詳細設計書は開発者が確認する資料になるので、開発者の目線でわかりやすく、明瞭な書き方にするように心掛けましょう。また、理解しやすいように図や表を用いることも重要です。
詳細設計書の作成が完了したら、他のメンバーからフィードバックを受けることも重要です。詳細設計の後は開発工程になってしまうので、ここでミスがある場合には影響が大きくなります。
詳細設計の成果物を作成する上で注意すべきポイント３選
ここでは詳細設計の成果物を作成する上で注意するポイントを３つ紹介します。
変更時の工数負担を考慮
詳細設計では検討を進めている中で設計書の変更が入ることが多々あります。場合によっては検討が完了した資料までも再検討を行わなければならないこともあります。ユーザーと協働で検討を進める場合、追加の要件が発生することもあるでしょう。詳細設計をまとめる過程で、ミロ・ジャパン社が提供するツールは使い勝手がよく、成果物作成に貢献してくれるはずです。（詳細はこちら）要件定義工程や設計工程を担当されている上流工程のエンジニアの方は是非一度ご確認してみてください。
要件定義との整合性確認
詳細設計では細かな仕様を中心に検討を行います。小さな要件の実現方法などの検討を中心に行っているため、知らず知らずのうちに要件からずれてしまう可能性もあります。定期的に要件定義時の資料と突合し、要件から反れていないか確認しましょう。
Can Beモデルになっているか
Can Beモデルとは実現可能なレベルであるということです。詳細設計の次は開発ですので、この工程までに要件が実現できるのか確認しなければなりません。工数の精査を行う、導入するシステムのスペックの精査を行う、ビジネスロジックが実現可能か机上で確認するなどを行い、実現可能性を検証するようにしましょう。
まとめ
ここでは詳細設計と基本設計の違いや、詳細設計における具体的な成果物、詳細設計のポイントを紹介しました。詳細設計はこの後の開発工程がスムーズに進むように開発者視点で資料を落とし込むことが重要です。
また、注意したいポイントを意識することも重要です。意識をして効果的に詳細設計を行いましょう。
—————————————————————————————————————
システム開発、スマホアプリ開発、MVP開発、新規事業立ち上げ、DX化の推進でお困りではありませんか？
日本全国には開発会社が無数にありますが、Webサービスやアプリサービスのスケール（規模拡大）を実現するビジネス推進力やシステムの堅牢性、可用性を意識した設計力・技術力を合わせ持つ会社は、全国で見ても多くはなく、弊社は数少ないその一つ。お客様のご要望通りに開発することを良しとせず、お客様のビジネス全体にとって最適な解を模索し、ご提案ができるビジネス×テック（技術力）×デザインの三位一体型のシステム開発/アプリ開発会社です。ITやDX全般に関して、何かお困りのことがございましたら下記の「GeNEEへのお問合せ」フォームからお気軽にご連絡いただけたらと思います。
—————————————————————————————————————
