詳細設計とは？詳細設計書の書き方を徹底解説！成果物の作成方法や記載すべき項目は？内部設計や仕様書との違い・サンプルも紹介
システム開発に欠かせない詳細設計
現在のITシステム開発の現場では、詳細設計が欠かせません。
この詳細設計を疎かにしてしまうと、システム上に重大な欠陥が生まれることも考えられ、クライアントからの信頼を損ねることにもなりかねません。
詳細設計をうまく進めるためには詳細設計書の書き方などをしっかり押さえておく必要があります。
この記事を通して、詳細設計についての知識を増やしていきましょう。
◯◯設計などの似たような言葉が多いので、それぞれの違いにも意識してみて下さい。
システム開発のフローを整理
詳細設計の解説に入る前に、そもそものシステム開発工程のフロー（流れ）を押さえておきましょう。
今回のテーマである「詳細設計」そして「基本設計」よりも前のタイミングでは、まず「要件定義」が行われます。
クライアントがどのような機能を備えたシステムを要求しているのか、それを把握するのが要件定義です。
顧客とのコミュニケーションで得た情報を元に、現場でエンジニアによる設計が行われていきます。
要件定義では実際にプログラミングを行うわけではありませんが、担当エンジニアは専門知識を持っておく必要があります。
＜関連記事＞
要件定義の意味と必要性を徹底解説！必要な基礎知識とスキルとは？スムーズな進め方と確認すべき重要なポイント3点も紹介。
「要件定義→設計→プログラミング」という流れ
要件定義が済んだら設計フェイズに移り、外部設計や内部設計・プログラミングへと入っていきます。
もちろん、設計が完了すればそれで終了というわけではありません。
設計したシステムが正常に稼働するかどうか・問題ないかどうかのテストにも多くの時間が費やされます。
大まかにまとめると、「要件定義」「設計・実装」「テスト」がシステム開発の3大フェイズということになるでしょう。
どのフェイズもシステム開発においては重要であり、前工程で欠陥があると後ろのフェイズに大きな影響が及ぶ恐れがあります。
基本設計とは何か
では、基本設計と詳細設計の知識をまとめていきます。
この両者の知識が曖昧なままだとプロジェクト進行にも支障を来しかねないので、正確に押さえておきましょう。
まずは「基本設計」について説明していきます。
システムの全体像を設計していく
基本設計は「開発対象であるシステムの全体イメージを構築していくフェイズ」だと思って頂ければOKです。
システムの具体的内容というよりはアウトライン、輪郭を設計していくことになります。
要件定義のポイントを満たしているかが大切
前フェイズの要件定義を通じて、「要件定義書」が生まれます。
この要件定義書をもとに基本設計書をアウトプットしていくのが基本設計の目的です。
基本設計は後に控える詳細設計・プログラミングに直接影響してくるフェイズなので、この段階でクライアントの希望と乖離が生じてはいけません。
大規模システム開発はウォーターフォール型（上から下へと工程が進む）で行われることがほとんどなので、「後で基本設計を見直し…」というのは困難です。
後に控える詳細設計をスムーズに行うためにも、基本設計は綿密に行っておく必要があります。
＜関連記事＞
基本設計の意味と作り方を徹底解説！必要な視点は？仕様書と要件定義の違いにも迫る。設計課題の解決方法とサンプルも紹介
ウォーターフォール・モデルを徹底解説！メリットと好まれるケース、アジャイル・モデルとの違いとは？時代遅れといわれる理由も紹介
クライアントに適宜確認してもらうこと
基本設計が進んでいく過程で「こういった全体像で問題ないか？」をクライアントに確認してもらうことになります。
クライアント側としても、設計が全て終わってから成果物をいきなり見せられるより、何回かに分けて途中経過を確認できたほうが安心なはずです。
基本設計のプロジェクト担当者は、クライアントとのコミュニケーションを重視する必要があります。
詳細設計に入ってからの方向修正は困難を極めるので、基本設計のうちにクライアントと相互理解を図っていくべきです。
詳細設計とは
各機能をどう実現させるかを決める
次の詳細設計は、基本設計で固めたシステムの全体像を「具体化」させるフェイズです。
各機能がどのように動作すれば良いのか・この機能を満たすにはどう設計すれば良いのかを具体的に落とし込んでいきます。
「プログラムで実現できるように」設計する
詳細設計で決まったことは、そのままプログラム設計・プログラミング作業へとつながっていきます。
もしここで現実離れ（=実現が難しい）した設計をしてしまうと、後工程のプログラミング作業でトラブルを生むことにもなりかねません。
これは基本設計でも同じことがいえます。基本設計で実現の難しいシステム像を作ってしまうと、詳細設計でつまづくことになるでしょう。
基本設計でクライアントに了承してもらった以上、詳細設計でそれを翻すのは相当ハードルが高いです。
どの設計フェイズであっても、「後工程のことを考えて設計すること」が重要なポイントになってきます。
基本設計書と詳細設計書
基本設計書はクライアントに見せる前提で作られるため、専門的すぎる記述は避けた方が無難です。
このことから、基本設計書は「外部向けの書類」であるといえるでしょう。
クライアント企業が非IT系である場合、専門用語ばかりの設計書を見せても担当者からの理解を得られません。
一方で詳細設計書は、「内部向け」になります。
実際にプログラム設計や実装を行うエンジニア向けに作られるものなので、専門系の用語もズラリと並びます。
詳細設計書の記載内容
詳細設計書には多くの内容が書かれていますが、ここではいくつかのモノについて触れておきます。
コンポーネント構成
まずはコンポーネント構成について。コンポーネントは「構成要素・部品」という意味です。
システム開発で使用されるソフトの一覧、そしてそれらシステムがどのような形で積まれているのかを表します。
機能の一覧
開発対象となる機能と、その内容を一覧形式で表示します。
機能名だけで具体的内容が書かれていないと、エンジニアが「これはどういう機能なのか？」が分からず、開発に戸惑いが生じることも考えられます。
コーディング等の規約
コーディングを行っていく際の注意点や規約を記載します。
コーディング以外にも、各プロジェクトごとに規約が必要となってくる場合はそれらも含まれます。
詳細設計書の作成のポイント
曖昧な表現は用いない
プログラム担当のエンジニアたちが詳細設計書を見たときに「これ、どうなってるの？」と感じるようではいけません。
曖昧な表現は用いず、知識のあるエンジニアなら全員が「ここはこれを使えばいいのか」と理解できるように設計書を作成していきます。
一文はシンプルに
詳細設計書の説明文は「簡潔・明瞭」であることが望ましいでしょう。
一文が長すぎると読み手が負担と感じるだけでなく、内容把握にも時間がかかります。
また、曖昧な表現を多用してしまうと、自分自身は理解できても他者が誤って読解してしまうかもしれません。
詳細設計なのである程度の専門用語は使っても構わないものの、表現が難解過ぎたりしないように注意すべきです。
文字数や言葉選びだけでなく、表現方法も工夫してみましょう。ポイントを紹介する場合は、例えば箇条書きで羅列したほうが伝わりやすくなります。
図や表を利用する
設計内容が伝わりやすくするための工夫として、図表を活用していくことも忘れてはいけません。
文章だと難しい内容であっても、図表を用いてイメージ化すれば読み手が理解しやすくなります。
詳細設計における成果物の例
アクティビティ図
アクティビティ図は、システム一連の動作を順序立てて示した図のことです。
アクティビティ図の特徴は「動作の開始状態・終了状態が決められている」という点になります。
四角形やひし形などの図形を用い、条件分岐を表現していきます。
シーケンス図
シーケンス図は、オブジェクト間でのメッセージのやりとりを時間軸に沿って表現した図のことです。
オブジェクト指向においてよく用いられる図の代表格といえます。
クラス図
クラス図は、システムの構造や関係性を表現するために用いられる図のことです。
クラスはオブジェクト指向プログラミングにおいて欠かせない要素であり、明確に表現しておく必要があります。
オブジェクト指向とは？
ここで「オブジェクト指向」というワードを用いましたが、念のため解説しておきます。
プログラミングにも種類がある
プログラミングはプログラムを作ることですが、その表現方法にもいくつかの種類があります。
「オブジェクト指向型プログラミング」はその内の1つで、他にも「手続き型」「関数型」プログラミングも実際に使用されている表現方法です。
オブジェクト指向プログラミング
オブジェクト(Object)は”モノ”という意味で、オブジェクト指向は「モノ」を重視したプログラミングということになります。
物を組み立てていくようなイメージでプログラミングを行っていく手法です。
オブジェクト指向については、以下の記事で詳しく解説しています。興味がある方はぜひ併せてご参照ください。
オブジェクト指向とは？オブジェクト指向の基本を徹底解説！メリットやカプセル化の概念は？おすすめオブジェクト指向言語も紹介
外部設計と内部設計
基本設計・詳細設計以外に、「外部設計」「内部設計」という言葉もシステム開発の世界では使われます。
これらの言葉の意味に違いはあるのでしょうか。
外部設計とは何か
外部設計を行う目的は、システムの仕様を決定することです。
要件定義で得られた情報をもとに仕様を定めていくという点では、基本設計と同じような意味で使われることも多いです。
どういった機能を導入するか？だけでなく、開発言語はどれにするのか・プラットフォームの選定はどうするか…などといった点も検討されます。
内部設計とは何か
一方で内部設計は、詳細設計と似た意味で使われることがほとんどです。
クライアントから見えない部分、つまりプログラムの詳細な仕組み決めなどを行っていきます。
実のところ、基本・詳細設計/外部・内部設計に違いはさほどありません。
どちらの方向（クライアントか現場か）を見て作業しているのかを押さえるときに外部・内部という言葉を使っていくと良いでしょう。
仕様書とは何か
詳細設計書と似たものに「仕様書」がありますが、これはどういったことを示しているのでしょうか。
仕様書の意味とその性質について、ここでは説明していきます。
要件定義と基本設計をもとに作られる
システム開発ではクライアントとの要件定義を踏まえ、そこから基本設計（=外部設計）に入っていきます。
その結果としてクライアントに報告するのが、「システムの大まかな仕様」になります。これが仕様書です。
仕様書は「結果」を示すもの
詳細設計書はこのシステムをどのように作っていくかという「過程」が記述されているのに対し、仕様書では「結果」を書いていきます。
このシステムにはAという機能があり…といった内容を、クライアントでも分かるように書く必要があります。
アジャイル開発における設計書
ウォーターフォール開発とアジャイル開発
国内のSIer企業で行われるような大規模システムの開発は、ほとんどが「ウォーターフォール型」をとっています。
基本設計・詳細設計といった基本的なフェイズを踏んで開発が進められていくわけですが、「アジャイル型」ではどうなのでしょうか。
＜関連記事＞
ウォーターフォール・モデルを徹底解説！メリットと好まれるケース、アジャイル・モデルとの違いとは？時代遅れといわれる理由も紹介
アジャイル開発とは？要件定義やメリットを徹底解説！他の開発手段との違いは？失敗事例とその理由から正しい対策方法もご紹介！
アジャイル開発の特徴
アジャイル開発は、ウォーターフォール開発と比べスピード感が特徴的な手法となっています。
細部をきっちりと定めて開発を進めるウォーターフォールに対し、アジャイルは全体の大まかな仕様だけ決めてすぐ実装フェイズへ移っていきます。
開発の単位も小規模になっており、実装とテストを短いスパンで繰り返していくのがアジャイル開発の特徴です。
国内の大手SIerではそれほど見られませんが、新興企業やベンチャーではアジャイル開発も珍しくはありません。
アジャイルでは設計書が重視されない？
アジャイル開発はウォーターフォールよりも細部に拘らず、「走りながら修正」というイメージの開発手法です。
しかし設計書が重視されないのかというとそうでもなく、ある程度の基本設計は行われているようです。
Web系の新興企業ではドキュメント (書類)を重視しない文化もありますが、これも企業によって様々となっています。
詳細設計はシステム開発において重要
システム開発の中でも、詳細設計はその中核部分を担う大切なポイントです。
詳細設計・設計書の内容が不充分になってしまうとプロジェクト全体に支障を来たしてしまうので、しっかりと習得しておくようにしましょう。
現時点でプログラムの実装を担っているエンジニアであっても、詳細設計書はきちんと読めるようになる必要があります。
SIerの開発現場では上流工程に行くほど報酬UPもしやすいので、設計フェイズも行えるエンジニアに成長することは収入面でもオススメできます。
SHIFTフリーランスは、SHIFTグループがプライムとして参画している独自案件をフリーランスエンジニア向けに紹介する唯一のプラットフォームサービスです。
エージェントによるサポートもありますので、ご利用を検討してみてはいかがでしょうか。
