システム開発における詳細設計は、システムに各種機能を実装するための専門的な内容を決定する非常に重要な工程です。詳細設計の内容次第で、システムの品質からバグ・エラーの発生まで左右するといわれています。
当記事では、詳細設計の概要・前後の工程との違いから、詳細設計で作成される主な成果物、従来の成果物作成・管理の方法で発生する課題と解決方法までを解説しています。詳細設計を含む開発プロジェクトで作成されるドキュメントの作成・管理におすすめのツールも併せてご紹介しています。
詳細設計を含む設計業務の効率化・合理化を図りたい方や、汎用ツール使用による課題にお悩みの方は、ぜひ参考にしてみて下さい。
詳細設計（内部設計）とは？
詳細設計とは、実際にシステムの実装を行うプログラマ・エンジニアを対象とした、システムの内部構造等の専門的な内容を設計することです。システムの内部を設計することから、内部設計とも呼ばれています。
そして、詳細設計書とは、詳細設計の成果物となるドキュメントのことを指します。
詳細設計書には、主に以下のような内容が記載されています。
|
詳細設計では、基本となる設計書以外にもさまざまな種類の成果物が作成されます。各種成果物については、次章で解説します。
要件定義との違い
システム開発の上流工程では、詳細設計以外にも要件定義・基本設計といったフェーズがあります。ここでは、要件定義と詳細設計の違いについて解説します。
要件定義とは、クライアントからシステムに求める機能を引き出して、実装する機能を整理・把握することです。
要件定義の成果物を基に、基本設計から詳細設計へと段階を追って進むため、要件定義は設計フェーズのベースとなるフェーズであると位置付けられます。
要件定義は設計工程以降の開発・テスト・納品といった後工程全てを左右するため、システム開発において、最も重要なフェーズであるといわれています。
基本設計（外部設計）との違いは？
基本設計と詳細設計は、どちらも要件定義を基に行われる設計フェーズである点では共通していますが、両者は設計する内容が違います。
|
|
基本設計は詳細設計のために行い、詳細設計は実装（コーディング）ができるために行うと考えることもできます。詳細設計については次章から詳しく解説していきます。
基本設計の成果物についてはこちらの記事でまとめています。
詳細設計における成果物
詳細設計で作成される成果物にはたくさんの種類があり、企業の方針やプロジェクトに合わせて使用されるドキュメントが決定されます。
ここでは、詳細設計で作成される代表的な成果物の概要・用途・書き方についてそれぞれご紹介します。
画面遷移図
画面設計に関するドキュメントは基本設計（外部設計）で作成されることが一般的ですが、画面遷移図については詳細設計で作成される場合もあります。
画面遷移図とは、システムの各画面の遷移と呼び出し関係を図示したもので、画面の遷移を直感的に把握することができるドキュメントです。
複雑な画面遷移を行うシステム開発においては、不自然な画面遷移を防ぎ正確な処理を実装するために重要なドキュメントとなります。
クラス図
クラス図とは、システムを構成するクラスの関係を可視化できるように図示したドキュメントで、システム全体像の把握や他の成果物作成にも使用される、詳細設計で作成する中でも重要度の高い成果物です。
実装を行う際には、プログラミング作業の道標としても使用されます。
クラス図を書く際には、クラス名・属性・操作をワンセットに記載したボックスを矢印で結ぶことで、各クラスの関係性を整理します。
シーケンス図
シーケンス図は、プログラムの概要や処理の流れを時間軸で図示したドキュメントです。実際のシステムが行う処理の概要・流れを把握するために作成されます。
シーケンス図を書く際にはUMLと呼ばれる明確なルールに従い、特定の図形・記号を用いて処理の概要や流れを表現することが特徴です。
シーケンス図は、詳細設計の中心的な成果物であると同時に、実装工程から保守・運用・管理まで幅広く使用される非常に重要度の高いドキュメントとなります。
状態遷移図
状態遷移図とは、ある状態がどのように変化するかを図示した図で、一覧性を高めるために状態遷移表とセットで使用するドキュメントです。作成したシステムが設計仕様と通りに動くかを確認するテスト工程で使用されます。
状態遷移図の作成は必須ではありませんが、仕様書・設計書を頼りにテストを行うよりも、システムの機能や処理の抜け漏れが無くなり、テストの品質・精度を高めることができます。
堅牢性や品質を重視したシステム開発においては、状態遷移図・状態遷移表は作成しておいた方がいいでしょう。
データベース物理設計書
多くのシステムでは、データ格納場所としてデータベースを使用するため、設計フェーズではデータベースの設計を行う必要があります。
データベースの設計は大きく分けて論理設計と物理設計に分かれており、前者は基本設計で、後者は詳細設計で行われることが一般的です。
物理設計では、テーブル定義書・ER図等を作成して、システムに最適な処理ができるようにデータベースの物理領域・格納方法を決めるパフォーマンス設計を行います。
入出力設計書
システムが入出力するさまざまな情報を、あらゆるケースを想定してレイアウトを決定します。
入出力設計で決める内容の例としては、エラー発生時のプログラム停止・エラーメッセージ・原因のアウトプットなどが挙げられます。
入出力設計は、基本設計で決定したインターフェースを具体的に実装するための設計となります。
バッチ処理詳細定義
バッチ処理詳細定義は、バッチ処理フローで行われる一つひとつの処理に対して、入力・処理・出力の情報を整理したドキュメントです。
バッチ処理に関するバッチ処理一覧・バッチ処理フロー・バッチ処理定義は基本設計で作成されることが一般的ですが、細かい部分まで記載したバッチ処理定義については詳細設計で作成される場合もあります。
バッチ処理詳細定義のドキュメントは、実装時・テスト時にバッチ処理の要件を参照するために使用されます。
詳細設計における成果物の作成方法
詳細設計で作成される各種成果物は、テキストだけではなく図形・記号を用いて作成される図表が多いことが特徴です。
各種成果物には特定のフォーマットや明確なルール・書き方が決められていないため、図形・記号を自在に配置しながらドキュメントを作成できることから、多くの設計現場では成果物の作成にExcel等の汎用ツールが多く用いられています。
しかし、汎用ツールは手軽に使える反面、設計業務においてさまざまな課題が発生している実情があります。次章以降で、汎用ツールで詳細設計の成果物を作成する際の課題について解説していきます。
詳細設計の成果物作成における課題
従来のWord・Excelといった汎用ツールで詳細設計の成果物作成を行うと、スムーズな実務遂行を妨げるさまざまな課題が発生します。汎用ツール使用時に発生する課題の多くは解決可能であるため、汎用ツールの活用が当たり前となっている方ほど、別の視点を手に入れてみることがおすすめです。
ここでは、汎用ツール使用時に発生する課題と解決方法について解説します。詳細設計業務で課題を抱えている方は、ぜひ参考にしてみて下さい。
属人化が発生する
汎用ツールで詳細設計の成果物を作成する際に最も懸念しなければならない課題が、属人化の発生です。属人化とは、特定の人物しか業務の内容や進捗について把握していない状況のことを言います。
詳細設計を含むシステム開発の設計工程では、ドキュメント作成の明確な基準やルールが無いため、設計者の裁量に委ねられる範囲が大きくなることで属人化が発生します。属人化が発生すると、詳細設計書を参照するたびに設計者への確認が発生したり、設計書の意図を誤認したりといった問題が生じるため、生産性の低下を招きます。
属人化を防ぐには、社内でドキュメント作成の基準やルールを設けることもひとつの方法ですが、難易度が高く、多くの手間と時間が必要となるため現実的ではありません。設計専用のツールを活用すれば、テンプレートや設計フォームの活用により、書式や作成手順を標準化できるため、属人化の解消には非常におすすめです。
リアルタイムで共有できない
汎用ツールで作成した詳細設計書は、手作業でメンバーに配布することで共有されます。そのため、修正や調整が発生した際は、詳細設計書の更新後に再配布を行う必要があり、リアルタイムでの共有が難しいことが多くの現場が抱えている課題です。
詳細設計書は開発現場のメンバーが参照した後での修正・調整のフィードバックが発生しやすいため、リアルタイム共有ができないことは作業効率低下を招きます。
このような課題を解決するためには、設計書をデータベースで一元管理することが必要です。更新を行った最新の設計書を常時共有・参照できるため、情報共有にかかる労力や時間を大幅に短縮することが可能です。
セキュリティリスク
汎用ツールで作成したドキュメントを配布して共有することは、セキュリティリスクの問題を孕んでいることにも留意しておく必要があります。
配布後のドキュメントの動向までは完全に管理することはできないため、基本的にはドキュメントを受け取ったメンバーに管理を一任するしかありません。万が一開発メンバーが詳細設計書をメールで誤送信したり、社外に持ち出したりすると、機密情報漏洩に繋がる恐れがあるため注意が必要です。
情報漏洩のリスクに対処するには、情報セキュリティのルール設定や社内教育を行う方法もあります。しかし、完全にリスクを防ぐことは難しいため、アクセス権などの管理ルールを設定できる専用ツールを活用する方法がおすすめです。
データ量の問題
Excel等の汎用ツールで作成した詳細設計書は、データ量・ファイルサイズが肥大化して非常に重いことがネックです。
ファイルが重いと、以下のような問題が発生して開発業務に支障をきたします。
|
詳細設計書は常時参照しながら開発業務を進めていくため、上記のような現象はストレスの原因となります。また、使い勝手が悪いために、あまり参照されなくなったり、使い捨てになったりする場合もあります。
解決方法としては、設計業務に必要な機能に絞られている専用ツールの活用がおすすめです。ファイルが無駄に肥大することもなく、軽快で使いやすい成果物を作成できます。
変更時の工数負担
上述のリアルタイム共有が難しい課題でも述べた通り、詳細設計書は開発メンバーが実際に作業を行う過程でさまざまな修正・追加・調整が発生しやすい性質を持つドキュメントです。
汎用ツールで作成したドキュメントを配布していると、情報共有に手間と時間がかかるため、ドキュメントを更新している間に次の修正・追加・調整が発生する場合もあります。
また、設計書の参照ができない場合は、開発現場は影響範囲を手作業で調べて修正したり、更新前のドキュメントで誤った作業を行なってしまうケースも発生します。
このような開発現場の工数負担増や混乱を解決するには、やはり専用ツールを導入するなどして、常に最新のドキュメントを共有できる環境を構築することが重要です。
まとめ
詳細設計の成果物は、実装に携わるプログラマ・エンジニア向けであることから、さまざまな種類のドキュメントがあることが特徴です。いずれのドキュメントも、システム開発のプロジェクトにおいて重要な役割を持っています。
従来では詳細設計を含む設計工程の成果物はExcelのような汎用ツールで作成されることが一般的でしたが、当記事で解説したようにさまざまな課題が発生することがネックです。
