基本設計と詳細設計の違い｜開発工程の全体像

01はじめに｜この記事でわかること

要点：この記事は、システム開発を発注する側の方に向けた設計工程の読み方です。基本設計と詳細設計がどう違うのか、どちらをどこまで確認すればよいのか、承認の重みはどう違うのかを、開発工程の全体像とあわせて整理します。

「設計書ができたので確認をお願いします」。開発会社からそう言われて、100ページを超えるファイルが届いた。開いてはみたけれど、どこを見ればいいのか分からない。そんなご相談をよくいただきます。

困る理由ははっきりしています。設計書には二種類あって、性格がまったく違うからです。片方は発注者が読むために書かれています。もう片方は、開発者が手を動かすために書かれています。この違いを知らないまま全部を同じ力で読もうとすると、時間だけがかかって、肝心なところを見落とします。この記事では、2000年創業のWeb制作・システム開発会社ZenWeb Japanが、Webシステム開発のご相談で実際にお伝えしている読み分け方をご紹介します。

まずは設計の流れをつかめる解説動画をご紹介します。

02基本設計と詳細設計の違い｜見る向きが逆

要点：基本設計は、システムを外から見たときの姿を決める工程です。詳細設計は、そのシステムを内側からどう作るかを決める工程です。基本設計は外部設計、詳細設計は内部設計とも呼ばれます。向いている方向が、外と内で逆になっています。

建物にたとえると分かりやすくなります。基本設計は、間取り図と外観のイメージ図です。部屋がいくつあって、どこに窓がついて、玄関から入るとどう見えるか。住む人が見て「これでいい」と言える図面です。

詳細設計は、その裏にある構造計算書や配線図にあたります。柱をどの太さにするか、配線をどこに通すか。住む人が読んでも判断できませんし、読む必要もありません。設計士と職人のあいだで通じていれば十分です。

• 読む相手が違います。基本設計書は発注者に向けて書かれます。詳細設計書は、実装を担当するプログラマーに向けて書かれます。
• 使う言葉が違います。基本設計書には業務の言葉が並びます。詳細設計書には技術の言葉が並びます。
• 承認の重みが違います。基本設計書は発注者の承認をもって確定します。詳細設計書は開発会社の内部で確定させるのが一般的です。
• 直したときの影響が違います。基本設計を直すと作る量が変わります。詳細設計を直しても、作る量はあまり変わりません。

この「向きの違い」を押さえておくと、設計書が届いたときに迷わなくなります。自分の業務の言葉で書かれているページは自分が読む場所、技術の言葉で埋まっているページは開発会社に任せる場所。まずはその線引きだけで十分です。開発の進め方そのものを比べたい場合は、アジャイル開発とウォーターフォールの違いもあわせてご覧ください。

03開発工程の全体像｜設計はどこに入るか

要点：開発工程は、要件定義、基本設計、詳細設計、実装、テスト、リリースの順に進みます。設計は前半の2工程です。要件定義で決めた「何を作るか」を、基本設計で「どう見えるか」に、詳細設計で「どう動かすか」に落としていきます。

順番には意味があります。ひとつ前の工程で決まったことを受け取って、次の工程がその中身を細かくしていく形になっています。

1. 要件定義。解決したい業務の課題と、必要な機能の一覧を決めます。ここがずれると、あとの工程がすべてずれます。
2. 基本設計（外部設計）。画面、帳票、業務の流れ、他システムとのつなぎ方を決めます。発注者が承認する工程です。
3. 詳細設計（内部設計）。プログラムの内部構造、処理の順番、データの持ち方を決めます。開発会社が担当します。
4. 実装。詳細設計書のとおりにプログラムを書きます。
5. テスト。単体、結合、総合と段階を上げながら、決めたとおりに動くかを確かめます。
6. リリースと運用。本番環境に載せ、実際の業務で使い始めます。

要件定義が固まらないまま設計に進むと、決められない箇所が次々に出てきます。前の工程は要件定義とは？システム開発で失敗しない進め方、後半のテストはシステム開発のテスト工程の種類と流れで説明しています。

04工程別の工数配分｜設計に使う時間の目安

要点：受託開発の工数を工程ごとに分けると、基本設計と詳細設計で全体のおよそ3分の1を使います。実装より設計のほうが軽いと思われがちですが、実際にはほぼ同じくらいの重さがあります。

設計に3分の1を使うと聞くと、多いと感じるかもしれません。ですが、この配分は特別なものではありません。IPA（情報処理推進機構）は、5,546件のプロジェクトデータをまとめたソフトウェア開発分析データ集2022を公開しています。そこでは基本設計から総合テストまでの5工程について、工期と工数の比率が分析されています。設計工程が相応の比重を占めることは、公的なデータでも裏づけられています。

設計に使う時間を削っても、総額は下がりません。実装とテストに移るだけです。

見積書で「設計費」が高いように見えても、それ自体は不自然ではありません。むしろ設計費が極端に少ない見積りのほうが、あとから追加費用が出やすい形です。金額の読み方はシステム開発の見積もりの見方で詳しく解説しています。

05基本設計で決まること｜発注者が読む文書

要点：基本設計では、画面の構成、入力する項目、帳票の様式、業務の流れ、他システムとのつなぎ方を決めます。どれも日々の業務に直接ひびく内容です。ここで決めたことが、そのまま使い勝手になります。

基本設計書に並ぶのは、業務を知っていれば読める内容ばかりです。専門用語が分からなくても、次の観点なら判断できます。

• 画面の構成と項目。どの画面で何を入力し、何が表示されるか。現場が毎日触る部分です。
• 業務の流れ。誰が入力し、誰が承認し、どこで完了になるか。承認が一段足りないだけで運用が回らなくなります。
• 帳票の様式。請求書や納品書の並び、印字位置、集計の単位。取引先に出す書類は特に注意が必要です。
• 権限の分け方。誰がどこまで見られて、誰が編集できるか。人事や給与に関わる情報では必ず確認します。
• 他システムとのつなぎ方。会計ソフトや在庫システムへどう受け渡すか。手作業が残る設計になっていないかを見ます。

画面の見た目や配置をあらかじめ絵にしておくと、この工程がぐっと進みやすくなります。考え方はワイヤーフレームとは？作り方と制作の流れと共通です。在庫や受発注のように業務ごとの型がはっきりしている領域では、在庫管理システムの開発で決めておく機能も参考になります。

06詳細設計で決まること｜読まなくてよい文書

要点：詳細設計では、プログラムをどの単位に分けるか、処理をどの順番で走らせるか、データをどう保持するかを決めます。発注者が読んでも判断材料にはなりません。開発会社に任せてよい領域です。

詳細設計書には、クラスの構成、処理のフロー、エラーが起きたときの分岐、データベースへの問い合わせ方などが書かれます。同じ画面を作るにも、内部の組み立て方は何通りもあります。そのどれを選ぶかは、メンテナンスのしやすさや処理速度をふまえた技術判断です。

ここを発注者が細かく確認しても、良いことはあまりありません。判断できない内容に時間を使うと、そのぶん基本設計書の確認が薄くなります。設計書の確認が止まっている案件をたどると、詳細設計書まで読もうとしている例がよくあります。

ただし、まったく無関心でよいわけでもありません。次の2点だけは、開発会社に口頭で確認しておくと安心です。

• 詳細設計書を作るかどうか。小規模な案件では省略されることがあります。省略する場合、あとで担当者が代わったときに引き継ぎが難しくなります。
• 納品物に含まれるかどうか。契約書に記載がないと、あとから別料金になることがあります。メンテナンスを他社に頼む可能性があるなら、必ず含めてもらってください。

07成果物の一覧｜どこを読み、どこを任せるか

要点：設計工程で作られる文書のうち、発注者が読むべきものは半分もありません。ページ数で見ると、確認が必要なのは全体の3割ほどです。残りは開発会社の作業用の文書です。

合計すると222ページ。そのうち必ず読むべきなのは、画面設計書、業務フロー図、帳票設計書の71ページだけです。テーブル定義書は、項目名の一覧に業務で使う言葉が正しく入っているかを見れば十分です。

08基本設計書で必ず見る5つの箇所

要点：基本設計書を確認するときは、月末や期末のいちばん面倒な業務を頭に置いて読んでください。ふだんの業務は設計に反映されています。抜けるのは、例外的な処理と、担当者しか知らない手順です。

順番に見ていくと漏れが減ります。上から確認してみてください。

1. いちばん面倒な業務が通るか。月次の締め、期末の棚卸し、返品や値引きの処理。この手順が画面のどこで完結するかを追ってください。ここが通らない設計は、稼働後に必ず手作業が残ります。
2. 承認の段数が実態と合っているか。設計書では一段の承認でも、実務では課長と部長の二段を通していることがあります。段数が足りないと、運用でごまかすことになります。
3. 入力項目に必須の指定が付いているか。必須にしすぎると現場が止まり、緩すぎると空欄だらけのデータが溜まります。埋まらない項目が必須になっていないかを見ます。
4. 取引先に出す帳票の並びが今と同じか。請求書の項目順や合計の出し方が変わると、先方の経理から問い合わせが来ます。現物と並べて確認してください。
5. 他システムへの受け渡しが自動か。「CSVを出力して取り込む」と書かれていたら、その作業を誰が毎月やるのかを確かめます。担当者が代わると止まる仕組みになりがちです。

この5点は、技術の知識がなくても判断できます。逆に、開発会社には判断できません。御社の業務を知っているのは御社だけだからです。

09契約の形が変わる境目でもある

要点：基本設計と詳細設計の境目は、契約の切れ目になることがあります。基本設計までは発注者と開発会社の共同作業、詳細設計以降は開発会社が完成させる作業。この違いが契約の形にも表れます。

この区切りには根拠があります。IPAが公開している情報システム・モデル取引・契約書（第二版）は、ユーザー企業とITベンダーそれぞれの役割と責任を整理したうえで、開発の局面ごとに契約を分ける考え方を示しています。発注者が主体的に関わる工程と、開発会社が成果物の完成に責任を負う工程を分けて考える、という発想です。

実務では、次の点を契約前に確かめておくと安心です。

• 契約が分かれているか。要件定義と基本設計を一本目、詳細設計以降を二本目とする形は珍しくありません。分かれている場合、二本目の金額は一本目の結果を見て確定します。
• 承認の期限が書かれているか。設計書の確認に何日もらえるのかが決まっていないと、催促される形になります。実態に合う日数を最初に交渉してください。
• 承認後の変更がどう扱われるか。基本設計書を承認したあとの仕様変更は、原則として追加費用になります。無償の範囲がどこまでかを文書にしておきます。

契約形態そのものの違いは、請負と準委任の違いと費用で整理しています。発注前の資料づくりを進めたい場合は失敗しないRFPの書き方もあわせてご覧ください。

10見落としが見つかる時期と手直しの重さ

要点：同じ見落としでも、見つかる時期で手直しの重さがまったく違います。基本設計のレビュー中なら文書を直すだけですが、稼働後に見つかるとデータの移し替えまで必要になります。

注目していただきたいのは、41%という数字です。見落としのうち4割は、基本設計のレビューの段階で見つかっています。つまり、しっかり読めば見つかるものが大半だということです。

一方で、実装中に見つかる22%は重さが5倍になります。この差が、設計書の確認に時間を使う理由です。1日でも早く見つけたほうが、あとの負担が軽くなります。

11設計のつなぎ目で起きやすいこと

要点：トラブルは工程の中ではなく、工程と工程のつなぎ目で起きます。要件定義から基本設計へ、基本設計から詳細設計へ。渡すときに落ちた情報が、あとで問題になります。

よくあるのは次の三つです。

• 口頭で決めたことが設計書に載っていない。打ち合わせで合意した内容が、議事録止まりになっている状態です。設計書に反映されているかを、その場で確かめる習慣をつけてください。
• 例外処理が「別途検討」のまま進む。返品や取消のような例外は、決めにくいので後回しにされがちです。後回しにしたまま実装に入ると、あとで作り直しになります。
• 非機能の条件が抜ける。同時に何人が使うか、どのくらいの速さで返るか、データを何年保存するか。書かれていないと、詳細設計の担当者が勝手に想定します。

防ぎ方は単純です。レビューを、開発会社の説明を聞く場にしないこと。こちらから業務の場面を出して、設計書のどこに書かれているかを指してもらうと、抜けが表に出ます。工程の受け渡しについては見積もりから納品までの進め方でも触れています。

12規模別の設計期間と社内の手間

要点：設計にかかる期間は、規模によって3週間から数か月まで開きます。あわせて見ておきたいのが、発注者側で必要になる時間です。中規模の案件でも、社内の担当者に延べ15人日ほどかかります。

15人日は、通常業務をこなしながらだと3週間から1か月ぶんの負荷です。担当者を1人だけ立てて他の仕事を減らさずに進めると、たいてい設計の確認が遅れます。

おすすめは、業務ごとに読む人を分ける形です。経理の帳票は経理の担当者、倉庫の画面は現場のリーダーというように割り振ると、1人あたりの負担は2〜3人日で収まります。規模ごとの費用感はシステム開発の費用相場にまとめています。

13設計書がない開発で起きること

要点：設計書を作らずに進める開発もあります。短期間で安く仕上がる代わりに、あとで直すときの費用が跳ね上がります。特に、作った会社以外に頼めなくなる点が大きな負担になります。

小規模な開発では、画面のイメージだけ共有して実装に入ることがあります。速さの面では確かに有利です。問題が出るのは、数年後です。

担当したエンジニアが退職し、プログラムだけが残る。そこに「消費税率が変わったので直したい」という依頼が来る。設計書がないと、プログラムを読んで仕様を推測するところから始まります。この調査だけで数十万円かかることも珍しくありません。古いシステムの改修を引き継ぐご相談では、最初に見積るのがこの復元作業です。老朽化への対応は基幹システムの刷新と2025年の崖対策、表計算ソフトからの移行はExcel業務をWebシステム化すべきサインで扱っています。

14相談前に整理しておきたい4項目

要点：開発会社に相談する前に、対象業務、いちばん面倒な処理、確認できる人、譲れない条件の4つを整理しておくと、設計工程が短くなります。資料は手書きでも十分です。

次の4項目をまとめておいてください。完璧である必要はありません。

1. 対象にする業務の範囲。どこからどこまでをシステムに載せるか。隣の業務との境目をはっきりさせます。
2. いちばん面倒な処理。月末の締めや例外的な取引など、手間がかかっている作業を書き出します。ここが設計のいちばん難しい部分になります。
3. 設計書を確認できる人。業務ごとに誰が読むかを決めます。名前まで決まっていると、設計工程がとても速く進みます。
4. 譲れない条件と譲れる条件。法律や取引先の都合で変えられないものと、社内の慣習で続いているだけのもの。この区別があると、設計の選択肢が広がります。

4番目は特に効果的です。「前任者がこうしていた」だけの手順に合わせて特別な作りにすると、費用も期間も増えます。分けて考えるだけで開発の範囲が小さくなる例は、よくあります。

15まとめ｜確認の力の入れどころ

要点：基本設計と詳細設計の違いは、読む相手の違いです。発注者が読むのは基本設計書だけで十分です。そのぶん、いちばん面倒な業務が通るかどうかを、時間をかけて確かめてください。

この記事の内容を、短くまとめます。

• 基本設計は外から見た姿を決める工程、詳細設計は内側の作り方を決める工程です。
• 発注者が読むべきなのは基本設計書だけ。ページ数でいえば全体の3割ほどです。
• 見落としの4割は基本設計のレビューで見つかります。実装後に見つかると重さが5倍以上になります。
• 基本設計書への承認は、事実上の発注確定です。押す前に変更の扱いを確認してください。
• 読む人を業務ごとに分けると、1人あたりの負担が大きく下がります。

設計書が届いたら、まず表紙の次の目次を見てください。そこに業務の言葉が並んでいれば、それが読むべきページです。

16よくある質問

1. 基本設計と外部設計は同じものですか？

同じ工程を指します。基本設計は「開発の土台を決める」という意味合いの呼び方で、外部設計は「システムを外から見た部分を決める」という意味合いの呼び方です。会社によってどちらを使うかが分かれるだけで、中身は変わりません。詳細設計と内部設計の関係も同様です。用語が混ざっていても心配はいりません。

2. 詳細設計書は必ず作ってもらうべきですか？

将来の改修を考えるなら、作って納品してもらうことをおすすめします。設計書がないと、担当エンジニアが退職したあとの改修でプログラムの読み解きから始まり、その調査だけで数十万円かかることがあります。契約書の納品物一覧に含まれているかを、発注前に確認してください。小規模で使い捨てに近い開発であれば、省略する判断もあり得ます。

3. 基本設計書のどこを重点的に見ればよいですか？

月末の締めや期末の棚卸しなど、いちばん面倒な業務を頭に置いて読んでください。ふだんの業務はたいてい設計に反映されています。抜けるのは例外的な処理と、担当者しか知らない手順です。あわせて、承認の段数が実務と合っているか、取引先に出す帳票の並びが今と同じかを確認すると、大きな見落としはほぼ防げます。

4. 設計書を承認したあとで仕様を変えられますか？

変えられますが、原則として追加費用と期間の延長が発生します。ZenWebの集計では、実装中に見つかった見落としの手直しは、設計書の修正だけで済む場合とくらべて5倍ほどの作業量になります。だからこそ、承認の前に無償で変更できる範囲がどこまでかを文書で決めておくことが大切です。承認までに何日もらえるかも、あわせて確認してください。

5. 設計にはどのくらいの期間がかかりますか？

ZenWebの集計では、300万円未満の小規模な案件で基本設計3週間・詳細設計2週間、300〜1,000万円の中規模で基本設計6週間・詳細設計4週間が中央値です。あわせて、発注者側にも中規模で延べ15人日ほどの時間が必要になります。この社内工数を見込まずに進めると、設計の確認が遅れて全体の期間が延びます。