詳細設計書とは？基本設計書との違いと書き方

当サイトの記事は編集部が国土交通省・IPA・デジタル庁などの公的機関の情報、規格や業界団体の公開情報を調べて独自に執筆しています。記事内にIT・Webエンジニアの転職サービスへの案内（広告）を含みます。

詳細設計とは？詳細設計書で決めること

『基本設計書があれば、プログラムは書けるんじゃないの？』と思う方もいますよね。実は、基本設計書は利用者から見た形を決めた文書なので、中の処理の順番や条件の細かい所までは書かれていないことが多いんです。

厚生労働省の職業情報提供サイト job tag（2025年時点の掲載）では、受託開発のSEの仕事として、詳細設計ではデータ形式やファイル形式、詳細な内部処理の方法、操作画面の詳細などを決め、処理の流れを細分化した設計書を作ると紹介されています。

同じjob tagでは、プログラマーは「SEが作成した詳細設計書に基づいてコーディングし、プログラムを作成する」とされています。詳細設計書は、まさにプログラムを書く人への橋渡しの文書なんです。

公的な資料に出てくる詳細設計

デジタル庁のDS-100（デジタル・ガバメント推進標準ガイドライン）では、画面や帳票などの基本設計を行った後に「機能を実現するための詳細設計を行う」としています。

IPAの共通フレーム2013にも、「ソフトウェア詳細設計プロセス」という工程名があります。ソフトウェアの組み立て方を決める「ソフトウェア方式設計プロセス」の次に置かれ、そのあとに「ソフトウェア構築プロセス」が続きます。

英語では、ソフトウェアの用語を集めた ISO/IEC/IEEE 24765:2010 に detailed design description という言葉があり、同義語として detailed design specification が挙げられています。

基本設計書のほうの書き方は基本設計書とは？書く項目と書き方、設計書全体の種類は設計書とは？システム開発の設計書の種類と役割で紹介しています。

基本設計書と詳細設計書の違いを「読む人・書く粒度・決めること」で比べる

『違いは分かったような気がするけど、実際に書く時に線が引けない』という声もよく聞きます。そこで、3つの切り口で並べてみますね。

3つの切り口の比較表

次の表は、編集部が一般的な開発の進め方をもとにまとめたものです。会社によって境目は少しずつ違うので、目安として見てください。

境目に迷った時の考え方

『この内容は基本設計書と詳細設計書、どっちに書くの？』と迷ったら、「発注側に確かめてもらう必要があるか」で考えてみてください。利用者の目に触れる動きなら基本設計書、目に触れない中の処理なら詳細設計書、と分けると線が引きやすくなります。

詳細設計書に書く項目とテンプレートの使い方

『詳細設計書って、具体的にどんな項目を書けばいいの？』という方のために、編集部が考えた項目の例を並べます。

データの読み書きでテーブルの中身まで書く時は、テーブル定義書と分けて管理することが多いです。書き方はテーブル定義書・データベース設計書の書き方で紹介しています。

処理の流れの記入例

例えば、社内の備品を貸し出すシステムで「貸出を申し込む」処理なら、処理の流れはこんな形になります。編集部が作った架空の記入例です。

このくらい書いてあれば、プログラマーは『重なっていたらどうするの？』と聞きに来なくて済みます。条件の分かれ目ごとに「どうなったら、どうする」を書くのがコツです。

入力と出力の記入例

同じ「貸出を申し込む」処理で、入力と出力を表にするとこうなります。前後の処理とつなぐ時に、ここがいちばん見られる所です。

出力の「いずれか」を全部書いておくと、呼び出す側の画面も、どの結果の時に何を表示するかを決めやすくなります。

詳細設計書のテンプレートを使う時の注意

詳細設計書のテンプレートは、社内に過去の形式があればそれを使うのがいちばんです。同じ形式でそろっていると、保守する人が別の機能の設計書を読む時も迷いません。

テンプレートの形式の選び方は設計書のテンプレート・サンプルで紹介しています。

プログラムの設計書の書き方：どこまで細かく書く？

『どこまで細かく書けばいいのか分からない』という悩みは、詳細設計書でいちばん多い悩みかもしれません。書きすぎるとプログラムの写しになり、書かなすぎると作る人が困ります。

細かさを決める目安

書き方の手順

最後の「単体テストの担当者になったつもりで読み直す」は、ぜひやってみてください。テストケースを作れない所があれば、そこが書き足りない所です。

設計書づくりに使うツールは無料の物でも十分

プログラムの設計書を作るツールは、表計算ソフトや文書作成ソフト、無料で使える作図ツールやテキストエディタでも十分です。大事なのはツールより、チームで同じ形式をそろえることです。

処理の流れを図にするならフローチャートを描ける作図ツール、文章が中心ならMarkdownで書いて履歴を残す方法もあります。Markdownでの書き方は仕様書・設計書をMarkdownで書く、ツールの選び方は仕様書の作成ツールで紹介しています。

詳細設計書でよくある相談

知恵袋には、詳細設計書の書き方についての相談がたくさん寄せられています。閲覧の多いものを要約してお答えしますね。

相談1：プログラミングに縁がなかったのに、詳細設計書を書くことになった

『社内SEとして働いているけれど、プログラミングとは縁がなく、機能設計書や詳細設計書の書き方が分からない』という相談です。

プログラムを書いた経験が少ない場合は、処理の流れを「普通の業務の手順」として書くところから始めてみてください。例えば「申込を受け付ける時、まず日付が入っているかを見る」のように、窓口の人がする手順として書くと考えやすくなります。

そのうえで、データをどこから取り、どこに残すかを足していけば、詳細設計書の形に近づきます。発注側として要件をまとめる仕事の進め方は社内SEと仕様書でも紹介しています。

相談2：プログラムの設計書は「です・ます調」と「である調」のどちらがいい？

『プログラムの設計書の文体は、です・ます調とである調のどちらがいいの？』という相談です。

決まりはありませんが、設計書では文を短く言い切れる「である調」や「〜する」の形で書くことが多いです。

参考までに、規格の書き方を定めたJIS Z 8301:2019では、要求を「…しなければならない」「…する」「…とする」のような形で書くとしています。また「十分に強い」のような、客観的に確かめられない表現は使わないという考え方も示されています。

大事なのは、一つの設計書の中で文体をそろえることです。社内の過去の設計書に合わせておけば、まず間違いはありません。

相談3：詳細設計書どおりに作ったはずなのに、実装もれやミスが多い

『詳細設計書をプログラムにする時に、実装もれや実装ミスがよく起きる』という相談です。

これは、設計書の側に原因があることも少なくありません。条件の分かれ目が文章の中に埋もれていると、読む人が見落としやすくなるんです。

相談4：プログラムの設計書を作るのは時代遅れ？

『数人で開発している職場で、プログラムの設計書を作るのはもう時代遅れなの？』という相談です。そう感じる気持ちも分かりますよね。

結論から言うと、文書の形は変わっても、「何を決めたか」「なぜそうしたか」を残す役目は今も変わりません。プログラムを読めば「何をしているか」は分かりますが、「なぜそうしたか」はプログラムからは読み取りにくいからです。

チームの人数や、システムをどれくらい長く使うかで、ちょうどいい残し方を選んでみてください。

詳細設計書の経験を、次の一歩につなげる

『詳細設計ばかりで、この先どうなるんだろう』と不安になる方もいますよね。job tag（2025年時点の掲載）では、受託開発のSEは一般的に3年目頃には一人で詳細設計を書けるようになり、5年目頃には基本設計を含め開発全体ができるようになると紹介されています。

詳細設計書をきちんと書ける力は、その先の基本設計に進むための大事な一段なんです。単体テストの文書との対応は単体テスト仕様書の書き方で紹介しています。

設計書を書く経験は、上流工程を任される職場で評価されやすい経験です。今の担当工程から一歩進みたい方は、求人の仕事内容で「詳細設計」「基本設計」がどう書かれているかを比べてみると、道が見えてきます。

今の職場で担当を広げていく道も、もちろん十分ありです。上流工程への進み方は上流工程とは？でまとめています。

よくある質問

まとめ

あわせて読みたい

基本設計書とは？書く項目と書き方（外部設計）

単体テスト仕様書の書き方｜テスト項目の作り方とテンプレート

仕様書とは？意味と目的、設計書・要件定義書との違い