基本設計・詳細設計とは？発注者が承認前に見る5つのポイント

「今週から基本設計フェーズに入ります」。開発会社からそう連絡を受けて、戸惑っていないでしょうか。要件定義までは業務知識でついていけたのに、設計フェーズに入った途端、ER図・画面遷移図・インタフェース設計書といった見慣れない単語が次々と出てきて、打ち合わせについていくだけで精一杯になりがちです。

さらに悩ましいのが、基本設計書のドラフトが届いて「レビューして承認してください」と言われたときです。ページをめくっても、何を見て、どこに目をつけて、どのタイミングで「OKです」と言えばよいのか判断できず、「見落としのせいで後でトラブルになったらどうしよう」と不安を抱えたまま承認してしまう、という発注者の方は少なくありません。

しかし、安心してください。基本設計と詳細設計は、役割も発注者の関与度合いも明確に異なります。結論から言うと、発注者がしっかりレビューすべきは基本設計です。詳細設計は原則としてエンジニアに任せる領域で、確認すべきポイントも限定されています。この線引きを先に理解しておけば、どこに力を入れるべきかが見えてきます。

また、基本設計フェーズは「発注者が仕様に口を出せる事実上の最後のチャンス」でもあります。IPAのソフトウェア開発データ白書でも示されているとおり、下流工程に進むほど仕様変更のコストは跳ね上がります。基本設計で気付けなかった漏れを詳細設計・実装フェーズで発見すると、工数・費用ともに大きなロスになります。

本記事では、基本設計・詳細設計とは何か、両者の違いと成果物、そして何より非エンジニアの発注者担当者が各フェーズで確認・承認すべきポイントをチェックリスト形式で解説します。次の打ち合わせで自信を持って発言できる状態を目指して、一緒に整理していきましょう。

執筆者

秋霜堂株式会社 代表 石川瑞起

中学生でプログラミングを独学で習得し、HP制作やアプリ開発の事業を開始。 大学入学後に事業を売却し、トヨクモ株式会社へ入社。 3年間にわたり1製品の開発責任者を務めたのち秋霜堂株式会社を設立し、多数の企業をサポートしている。

無料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

詳しく見る

お名前

お名前

会社名

会社名

メールアドレス

メールアドレス

電話番号（任意）

電話番号（任意）

具体的なお悩みがあればご記入ください

具体的なお悩みがあればご記入ください

プライバシーポリシーに同意する

無料ダウンロード

基本設計・詳細設計とは？開発フェーズ全体の中での位置づけ

基本設計と詳細設計は、システム開発の「設計フェーズ」を構成する2つの工程です。まずは開発全体のどこに位置しているかを押さえておきましょう。

ウォーターフォール開発の全体工程と上流/下流

ウォーターフォール型のシステム開発は、一般的に以下の順序で進みます。

1. 要件定義
2. 基本設計
3. 詳細設計
4. 実装（プログラミング）
5. 単体テスト
6. 結合テスト
7. 総合テスト
8. リリース・運用

このうち「要件定義」から「詳細設計」までを上流工程、「実装」以降を下流工程と呼びます。基本設計と詳細設計は上流工程の後半を担い、要件定義で決めたシステム要件を、実装者が手を動かせるレベルまで具体化していく位置づけです。

基本設計・詳細設計に割かれる工数と期間の目安

システム開発全体の工数を100とした場合、各フェーズの配分は次のように整理されています。

出典: システム開発の工程比率とは？主要工程の配分と工数の目安をわかりやすく解説（Sun* Inc.）

中規模の業務システムであれば、設計フェーズ全体で1〜2か月程度を見込むのが一般的です。規模によって大きく変動するため、開発会社から提示されたスケジュールが平均に照らして妥当かどうかの目安として使ってください。

発注者の関与が強いのは基本設計まで

設計フェーズのもう一つ重要な特徴は、発注者の関与度合いがフェーズによって大きく変わる点です。要件定義と基本設計は「発注者と開発会社が会話しながら進める」工程ですが、詳細設計に入ると「開発会社が社内のエンジニア向けに詳細化する」工程に切り替わります。

つまり、発注者が仕様に影響を与えられるのは基本設計までが基本です。ここを理解しておくと、次のセクション以降で紹介するチェック観点の濃淡が腑に落ちます。

基本設計（外部設計）でやること・主な成果物

基本設計は「要件定義で決めた要求（WHAT）を、発注者にも見える形で具体化する」工程です。ユーザーから見たときのシステムの振る舞いを決めるため、別名で外部設計とも呼ばれます。

基本設計の目的とゴール

基本設計のゴールは、「システムの外側から見た挙動」がすべて合意された状態を作ることです。具体的には、画面で何ができるのか、どんな帳票が出力されるのか、他システムとどう連携するのか、障害時にどう振る舞うのか、といった問いに答えを出していきます。

完成したシステムの姿を発注者が紙の上で確認できるレベルまで落とし込むことで、認識のズレを詳細設計に進む前に解消するのが狙いです。

発注者に見える代表的な成果物

基本設計の成果物は、ひとくくりに「基本設計書」と呼ばれることが多いですが、実際には複数のドキュメントで構成されています。代表的なものは次のとおりです。

出典: 基本設計における成果物とは？ 開発工程の流れや注意点を含めて解説（GeNEE） ／ 【保存版】基本設計の成果物一覧｜詳細設計との違いと作成ポイントを徹底解説（Y's）

ここで覚えておきたいのは、これらの成果物はすべて「発注者がレビューして良し悪しを判断すべきもの」という点です。技術用語が多くても、自分の業務に照らして読み解けば判断できます。

非機能要件（性能・セキュリティ）も基本設計で確定する

基本設計で忘れられがちなのが、非機能要件です。具体的には、同時に使う人数（同時接続数）、画面表示までの応答時間、災害時の復旧目標、個人情報の取り扱いルール、パスワードポリシーといった項目を指します。

「見た目に現れない」ため発注者が見落としやすいのですが、後から「やっぱり応答時間は2秒以内でお願いします」と言うと、設計のやり直しが発生します。非機能要件も基本設計フェーズで数値として確定させておきましょう。

詳細設計（内部設計）でやること・主な成果物

詳細設計は、基本設計で決まった仕様を「実際のプログラマーが実装できるレベル」まで落とし込む工程です。ユーザーからは見えない内部の処理を設計するため、別名で内部設計とも呼ばれます。

詳細設計の目的とゴール

詳細設計のゴールは、「プログラマーが設計書を見れば、迷わずコードを書き始められる状態」を作ることです。基本設計が「WHAT（何を作るか）」を決めるフェーズだとすれば、詳細設計は「HOW（どう作るか）」を決めるフェーズと理解してください。

対象読者は社内の開発者です。そのため、ドキュメントも技術用語中心で、発注者が読んでもすぐには意味がとれない表現が多くなります。

代表的な成果物（エンジニア向け資料）

詳細設計で作成される主な成果物は以下のとおりです。

出典: 詳細設計の成果物一覧を徹底解説｜基本設計との違いとドキュメント作成のポイント（Y's） ／ 詳細設計とは？進め方と要件定義／基本設計との違いを解説（ICD）

原則として発注者のレビューは不要

詳細設計の成果物はエンジニア向けのものが中心であり、発注者がレビューして承認する性質のものではありません。むしろ、発注者が細かく口を出すと「基本設計で合意した仕様の蒸し返し」になりやすく、プロジェクトを混乱させる原因にもなります。

詳細設計フェーズは、基本的には開発会社に任せ、発注者は完了報告を受け取る立場で問題ありません。ただし、後述するように最低限の整合性チェックだけは行うと安心です。

基本設計と詳細設計の違いを対比表で整理

ここまでの内容を一覧表にまとめます。次の打ち合わせで「基本設計と詳細設計って何が違うんでしたっけ」と聞かれたら、この表を思い出してください。

この表で一番重要なのは「発注者の関与」と「仕様変更コスト」の行です。基本設計フェーズで気付けるかどうかが、プロジェクトの成否を大きく左右します。

無料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

詳しく見る

お名前

お名前

会社名

会社名

メールアドレス

メールアドレス

電話番号（任意）

電話番号（任意）

具体的なお悩みがあればご記入ください

具体的なお悩みがあればご記入ください

プライバシーポリシーに同意する

無料ダウンロード

発注者が基本設計フェーズで確認すべき5つのポイント

ここからが本記事の核です。基本設計書のドラフトが届いたときに、発注者として必ず確認すべき5つのポイントを紹介します。この順序でチェックすれば、重要な見落としは防げます。

1. 機能一覧が要件定義書の要求とすべて紐づいているか

最初に行うべきは、要件定義書と機能一覧表の突き合わせです。要件定義で「この機能を入れてほしい」と伝えた項目が、機能一覧に漏れなく反映されているかを確認してください。

特に、要件定義書の後半に補足として記載された機能（例: 月次帳票の自動送信、管理者向けのダッシュボード等）は抜けやすい傾向があります。要件定義書を開いて、1項目ずつ指差し確認するのが確実です。

2. 画面遷移・業務フローが現場の運用と一致するか

画面遷移図と業務フロー図は、実際にシステムを使う現場担当者の運用実態と合っているかを確認します。発注窓口の担当者だけで判断せず、一次利用者となる現場メンバーにも画面のモックを見せてレビューしてもらいましょう。

「この順序でボタンを押すのは、現場の流れと違う」「確認画面が1枚多い」といった指摘は、現場担当者でないと出てきません。発注窓口の役割は、現場の声を基本設計に反映させることです。

3. 帳票・画面項目が現場の業務用語と一致するか

帳票設計書と画面設計書の項目名は、現場の業務用語と一致しているかを必ず確認します。開発会社側は一般的な表現で書いている場合があるため、社内の呼称と違っていることがよくあります。

例えば「顧客コード」と「取引先ID」、「受注日」と「契約日」のように、現場で使っている言葉と違うと、システム稼働後の現場教育コストが跳ね上がります。業務用語集（ドメイン辞書）を作って開発会社に共有するのも有効な方法です。

4. 外部システム連携の仕様が他部署・取引先と合意済みか

外部インタフェース設計書は、連携先の他部署や取引先と仕様が合意できているかを確認します。自社内の別システムとの連携であれば情報システム部門、取引先の基幹システムとの連携であれば先方の担当者に、書面で仕様を確認してもらいましょう。

「言った・言わない」のトラブルが発生しやすい領域なので、メールで合意の証跡を残すのが基本です。

5. 非機能要件が数値で明記されているか

非機能要件定義書は、「数値として確定しているか」を確認します。「そこそこの速度で動くこと」「通常時に耐えられる性能」といった曖昧な表現ではなく、「同時接続100ユーザー、応答時間3秒以内、稼働率99.5%」のように数値が入っているかを見てください。

非機能要件の詳細を自社だけで判断するのが難しい場合は、情報システム部門や外部のITコンサルタントに相談するのも一つの方法です。この段階でセキュリティやバックアップ要件を詰め切れていないと、後工程で大きな手戻りを生みます。

承認前に議事録とメールで合意内容を残す

5つのポイントを確認し、質疑応答を経て納得できたら、基本設計完了の承認を出します。このとき、必ず議事録とメールで「何を」「いつ」「誰の責任で」合意したかを残してください。

基本設計は発注者が仕様に影響を与えられる事実上の最後のフェーズです。議事録に残さないまま口頭で承認すると、後から「そんなこと言っていない」というトラブルの火種になります。

基本設計レビューのより詳しいチェック観点は、基本設計レビューの必須チェック観点と進め方（Hakky Handbook）や設計書レビューで指摘される観点まとめ（Qiita）も参考になります。

発注者が詳細設計フェーズで確認すべき3つのポイント

詳細設計は原則として発注者が深く関わるフェーズではありませんが、「完全放任」にすると思わぬトラブルの原因になります。ここでは最低限おさえておきたい3つの確認ポイントを紹介します。

1. 基本設計で合意した仕様と矛盾がないか

詳細設計が進む中で、基本設計との矛盾が見つかることがあります。多くの場合は開発会社側から「この仕様について詳細設計段階で課題が見つかったので相談したい」と連絡が来ますが、まれに無断で仕様が変更されているケースもあります。

進捗報告のたびに「基本設計との差分はないか」を一度確認する習慣をつけましょう。もし差分が発覚したら、必ず議事録を残した上で合意を取り直してください。

2. 外部インタフェース仕様が確定し、連携先に渡せる状態か

外部インタフェース仕様は、基本設計段階では概要レベルでも、詳細設計フェーズで項目の型や桁数など細部が確定します。このタイミングで確定仕様書を受け取り、連携先の取引先や他部署に渡して最終レビューをしてもらいましょう。

連携先で「この項目の桁数では足りない」といった指摘が出た場合、実装が始まる前に修正したほうが圧倒的に安く済みます。

3. テスト計画書のドラフトが詳細設計と整合しているか

詳細設計と並行して、単体テスト・結合テストの計画書が準備されていきます。ドラフトを受け取ったら、基本設計で合意した機能が網羅されているか、想定する業務シナリオがテストケースに含まれているかを確認してください。

発注者がチェックする観点は「自分たちが使うときのパターンが漏れていないか」です。技術的な網羅性は開発会社に任せて問題ありません。

設計フェーズを乗り越えるための発注者の心得

最後に、非エンジニアの発注者が設計フェーズを安心して乗り切るための心得を4つ紹介します。

1. 分からない用語はその場で聞く

打ち合わせ中に分からない用語が出たら、その場で必ず聞いてください。「ER図」「シーケンス図」「バッチ処理」「トランザクション」など、専門用語を曖昧なまま流すと、後からの認識ズレにつながります。

開発会社の担当者は、用語を説明する責任も負っています。聞くのは恥ずかしいことではなく、発注者としての当然の権利です。

2. 承認は口頭ではなく議事録とメールで残す

「口頭で了承したつもりだったが、開発会社側には伝わっていなかった」というトラブルは非常に多く起こります。承認はすべて議事録に記録し、必要であればメールで念押しするようにしましょう。

議事録には、決まったこと・次回までの宿題・担当者・期日を明記するのが基本です。

3. 現場担当者を巻き込んでレビューする

システムを実際に使うのは現場の担当者です。発注窓口だけで基本設計をレビューするのではなく、現場メンバーも交えて画面・帳票を確認してもらってください。

一次利用者の視点を入れずに承認してしまうと、稼働後に「使いにくい」「業務にフィットしない」という声が噴出し、追加改修のコストが発生します。

4. 基本設計の承認は「後戻りコストを跳ね上げるポイント」と認識する

基本設計の承認後は、仕様変更のコストが一気に上がります。詳細設計以降で「やっぱり〜にしたい」と言うと、設計のやり直し・実装済みコードの破棄・テストケースの修正と、連鎖的に工数が膨らみます。

承認前に、もう一度腰を据えて成果物を読み込む時間を取りましょう。「急かされているからとりあえず承認」は、プロジェクト全体で見ると最もコストの高い判断になります。

まとめ：基本設計は「発注者の最後のチャンス」

基本設計と詳細設計の違いと、発注者が確認すべきポイントを整理しました。最後に、本記事のキーメッセージを再確認します。

• 基本設計は「WHAT（何を作るか）」を決める工程で、発注者が主体的にレビュー・承認する
• 詳細設計は「HOW（どう作るか）」を決める工程で、原則として開発会社に任せる
• 基本設計の承認後は、仕様変更のコストが大きく跳ね上がる
• 基本設計フェーズでは「機能一覧・業務フロー・用語・外部連携・非機能要件」の5点を必ず確認する
• 合意内容は議事録とメールで証跡を残す

基本設計フェーズは、発注者が仕様に口を出せる事実上の最後のチャンスです。少し面倒に感じても、成果物を丁寧に読み込み、現場担当者も巻き込んでレビューを行うことで、その後のプロジェクトが格段にスムーズになります。

システム開発の工程全体をさらに深掘りしたい方は、システム開発の流れ、要件定義と要求定義の違い、システム開発の成果物一覧の記事もあわせてご覧ください。設計フェーズの理解を、プロジェクト全体のマネジメントにつなげていきましょう。

無料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

詳しく見る

お名前

お名前

会社名

会社名

メールアドレス

メールアドレス

電話番号（任意）

電話番号（任意）

具体的なお悩みがあればご記入ください

具体的なお悩みがあればご記入ください

プライバシーポリシーに同意する

無料ダウンロード