無料で一括見積もり
電話で相談する

0120-917-819 営業時間 平日10~19時

公開日:2022年4月5日
更新日:2022年4月5日

詳細設計書とは?書き方や基本設計書との違いを紹介【2022年最新版】

システム開発を依頼する際、必ず必要になってくるのが詳細設計図です。システム開発においては多くの図面を用いることになりますが、具体的に詳細設計はどのような図を意味しているのでしょうか。今回は詳細設計の役割や、どのような図面の書き方があるのかについて、他の図面との違いに触れながらご紹介していきます。

【関連ページ】
システム開発にかかる費用・相場感や、
あなたの目的別にシステム開発会社をお探しいただけます。
システム開発の平均費用と料金相場|早見表つき【2022保存版】
システム開発会社一覧

詳細設計とは

詳細設計は、基本設計において固めていたシステムの全容を、具体的な機能に落とし込んで設計する段階です。基本設計では、必要な要件などを確認しながら、システムの全体像を構築していく必要があります。それに対し、詳細設計では開発に向けて仕様の詳細をまとめ、プログラムによってこれらを実現するためのものです。詳細設計をおろそかにしてしまうと、後々になって「機能の実装ができない」「実装したいものが曖昧でニーズに応えられているかわからない」といったトラブルが出てきてしまいます。詳細設計は、クライアントにとって満足のいくシステムにするために必要なプロセスであると同時に、現場のプログラマにとっても重要な役割を担っています。

ウォーターフォールモデル

詳細設計の書き方

詳細設計を図面に落とし込んで成果物とするためには、我流のまとめ方ではなく、ある程度フォーマットに則った書き方が求められます。詳細設計の書き方については実に多様で、目的に応じて様々なまとめ方があります。事例を挙げると、

・クラス図
・コンポーネント図
・オブジェクト図
・配置図
・パッケージ図
・ユースケース図
・コミュニケーション図
・ステートマシン図
・アクティビティ図
・シーケンス図

などといった方法が出てきます。プロジェクト毎に最適な手法を選ぶことがポイント。それぞれで表現可能な情報が異なるためです。ここでは、多岐にわたる成果物の書き方の中から、ポピュラーなものをピックアップしてご紹介します。

クラス図

システム同士の関係性や、その構造を表現する上で役に立つのが、クラス図と呼ばれる書き方です。クラスとは「構造」を意味し、クラス同士の関係性を表す言葉には、関連やコンポジション、集約といったものが存在します。クラス同士の関係性を描く際には、これらの言葉を端的な記号で表し、読み手の理解を促します。
クラス図の特徴として、簡単なテキストと記号によって関連が結び付けられているため、専門的な技術者以外でも読みやすいという点が挙げられます。実際に手を動かす業務は発生せずとも、クラス図の仕組みを理解しておくことで、スムーズな業務の遂行が実現します。

IPA
出典: IPA『良い設計例_クラス図全体像(オブジェクト指向)』https://www.ipa.go.jp/files/000056481.pdf

モジュール構成図

モジュール構成図は、システムを支えるモジュール化された構成が、どのように分けられていて、お互いに処理し合っているのか、ということをわかりやすくまとめるためのものです。モジュールの構造は、構成図においては大きく単純化され、シンプルな図形や矢印によって表現します。プログラムをバラバラにモジュール化することで、簡単に脱着や換装がシステム上で可能となるため、システム開発の現場においては重宝されています。高度化するシステム要件を満たすためには、その組み立て方にも工夫が必要になってきました。短期間で成果を獲得する上では欠かせない手法です。

IPA
出典: IPA『良い設計例_モジュール構造図全体像(構造化)』https://www.ipa.go.jp/files/000056483.pdf

アクティビティ図

アクティビティ図は、システムが実行する一連の処理について、どのような手続きが実行されるのか、およびどのような条件分布で手続きが実行されるのか、という活動状況を図面に書き起こしたものです。条件分岐によって枝分かれしている様子は、フローチャートのそれと酷似しています。そのため、以前フローチャートを書いたことがある、あるいは現在も書いているという人にとっては、比較的馴染みやすい図面となるでしょう。また、アクティビティ図の特徴として、開始時と終了時にノード(点)が用意されていることが挙げられます。これは他の図面作成方法であるステートマシン図にも見られる特徴です。両者の違いとして、アクティビティ図は一つの処理に注目していること、ステートマシン図はシステムの状態から状態への遷移を著している点が挙げられます。

IPA
出典: IPA『ソフトウェア方式設計書<良い設計例>』https://www.ipa.go.jp/files/000056487.pdf

シーケンス図

シーケンス図は、システムが特定のパフォーマンスを実行する際、オブジェクト間にどのような相互作用が発生するのかを、時系列でまとめた図面です。オブジェクト指向のソフトウェア設計において多用されている手法で、視覚的にシステムの処理を把握しやすいことから、複雑化するであろうプロジェクトに適用されることの多い手法と言えます。記述ルールはグローバルスタンダードで共通しているため、プロジェクトの規模が大きくなってもメンバー間の意思疎通をとりやすいのが特徴です。図面でわかりやすく処理の流れを追うことができるので、専門的な知識を持たない、クライアントなどにも説明がしやすい図です。

IPA
出典: IPA『サブシステム機能設計書 シーケンス図』https://www.ipa.go.jp/files/000056490.pdf

IPO(処理機能記述)

上記で挙げていない手法として、IPOと呼ばれる作成方法も存在します。IPOはシステムおよびアプリケーションにおいて、どのようなデータをインプット、あるいはアウトプットするのかを平易に記述することを目的とした手法です。どのステップで入出力を行うのかを明らかにする図面なので、プロセスを重視したい場合にはうってつけの書き方と言えます。どこにインプットとアウトプットのタイミングがあるのかが明らかになれば、後ほど修正が必要になった際も、一つ一つプロセスを辿らなければならない、ということがないため、業務の効率化にもつながります。図面の段階でシステム全体の処理が見えてくるため、テストの工数の策定にも役立ちます。

IPA
出典: IPA『ソフトウェア方式設計書<良い設計例>』https://www.ipa.go.jp/files/000056485.pdf

「自社にあった会社が見つからない」「会社選びに時間が割けない」とお悩みの方は、お気軽に「アイミツ」にお問い合わせください。数あるシステム開発会社からあなたの要望にあった会社をピックアップして無料でご紹介いたします。

他の仕様書との違い

システム開発においては、設計書の他に仕様書と呼ばれる書類も頻繁に用いられます。仕様書は完成形のイメージを描くために用いられる書類で、「システム開発の目的」「開発体制」「予算」などを盛り込みながら作成し、プロジェクトの要諦を掴めるようするものです。
一方、設計書は、完成するまでにどのようなプロセスが発生するのか、具体的に描かれた書類です。クライアントに完成イメージを共有する場合、仕様書が必要になりますが、社内プログラマ向けに共有する必要があるのは、設計書です。また、システム開発においてよく選ばれている手法として、「Vモデル/ウォーターフォールモデル」と呼ばれるものがあります。これは修正に必要な負荷を減らすために編み出された開発手法で、一度実装プロセスまで達してから、テストを行うというものです。

要件定義書

要件定義書は、クライアントであるユーザーがどのような要望をシステムに求めているか、ということをまとめた書類です。要件定義書をまとめる過程で、システム開発会社は、ユーザーニーズを満たせる機能を実装したシステムを描く必要があり、ここでまとめられたものをもとに、システム開発が進められます。ゴールにどのようなシステムを描いているのかを、要件定義の段階で固め、ニーズとの乖離を防ぐのが目的です。詳細設計書は、具体的な機能を動かすための設計をまとめたものなので、要件定義書よりも開発者向けの資料と言えるでしょう。

基本設計書

基本設計書とは、要件定義の内容を受けた上で、具体的なシステムに落とし込んでいくための基本的な設計書です。どのような機能をユーザーが求めているかを要件定義書を読みながら確認し、「機能に落とし込むとしたらどうなる?」ということを基本設計書にまとめます。システム化の背景を押さえた上で、システム化の対象範囲がまとめられているか、業務フローはどうなっているのかなどがまとめられていることが重要です。基本設計を固めておくことで、後ほど発生する手戻りのリスクを減らし、円滑なシステム開発を実現できます。詳細設計よりはカジュアルなまとめ方で構いません。

プログラム設計書

プログラム設計書とは、システムの開発を進める上で、どのようにコーディングを行えば良いのかの設計をあらわしたものです。詳細設計書における一部パートと考えられており、同義的に使われることもあります。プログラム設計書の目的は、「仕様書の通りにプログラミングすれば、問題なくシステムが完成する」という状況を作り出すためです。詳細まで設計を行うため、実用性の高い書類であると言えます。逆を言えば、詳細まで丁寧に記述しておかなければ、下流工程で修正などが多く発生する恐れもあります。

「詳細設計書という名のゴミ」といわれる理由

詳細設計書は具体性のある設計書として記述することを目的とした書類ですが、その一方で「詳細設計書はゴミ」と言われるほど、その実用性に疑問を呈する声も少なくありません。詳細設計書は不要だとされる理由としては、詳細設計書を書いてシステムを開発する、というプロセスそのものが陳腐化しつつあるためです。これまでシステム開発において採用されてきたのは、ウォーターフォール開発やVモデル開発と呼ばれる方法です。これらはスケジュール感を掴みやすい手法である反面、プロジェクトの柔軟性が低く、修正も難しいことから、運用には難も抱えていました。近年採用される傾向にあるのがアジャイル開発で、こちらは柔軟性があり、融通が利きやすいことから、多くのシステム開発会社に好んで採用されています。詳細設計書はウォーターフォール開発時代の名残であり、設計書を作成する時間もアジャイル開発では省略できることから、不要論が出てきているのです。

【まとめ】システム開発会社選びで迷ったらアイミツへ

詳細設計書は多くのシステム開発会社において採用されてきた手法です。また、詳細設計書を書くプロセス自体が有意義なことであり、教育的な側面も見受けられます。システム開発を依頼する側にとってはあまり関係のない話ではあるものの、効率的で質の高いシステム開発を行える会社を選ぶ際の、参考として知っておくと良いでしょう。
アイミツではご要望を伺った上で、条件に合うシステム開発会社を無料で複数社ご紹介可能です。会社選びでお困りの方は、お気軽にご相談ください。

【相談前にまずは会社一覧を見たいという方はこちら】
システム開発会社一覧

【費用感を知りたいという方はこちら】
システム開発の平均費用と料金相場|早見表つき【2022保存版】

システム開発会社探しで、こんなお悩みありませんか?

電話が鳴り止まない
一括見積もりサイトだと
多数の会社から電話が・・・

見積もりを取っても不安
相場がわからないから
見積もりを取っても不安・・・

情報だけを信じるのは不安
どの企業が優れているのか
判断できない・・・

アイミツなら

  • point.1

    専門コンシェルジュがあなたの要件をヒアリング!

  • point.2

    17万件の利用実績から業界・相場情報をご提供!

  • point.3

    あなたの要件にマッチした優良企業のみご紹介!