基本設計と詳細設計の違いとは？要件定義や設計書についても解説【2024年最新版】

要件定義や基本設計、詳細設計の違いがわからないという方も多いのではないのでしょうか。システム開発を依頼する場合、依頼者が設計書のレビューを行うこともあるため、システム開発の流れや詳細などの知識を深めておくことは大切です。

この記事では、さまざまな分野の発注先を比較検討できる「アイミツ」が、それぞれの違いや基本設計を行う上で重要なポイントについて解説していきます。

【関連ページ】
システム開発にかかる費用・相場感のご紹介。あなたの目的別にシステム開発会社をお探しいただけます。

システム開発の費用・相場
システム開発ができる会社一覧

システム開発は内容によって進め方はさまざまで、ウォーターフォール型・アジャイル型・プロトタイピング型・スパイラル型・DevOps（デブオプス）型・MVCモデル型などがあります。

最もオーソドックスなウォーターフォール型の場合、「要件定義」「基本設計」「詳細設計」「プログラミング・構築」「単体テスト」「結合テスト」「システムテスト」「保守・運用」の順番で開発していくことが特徴です。

要件定義や基本設計、詳細設計は「上流工程」と呼ばれ、プログラミング・構築やテスト、運用・保守は「下流工程」と呼ばれます。上流工程は、プロジェクト全体の方針を決定する役割を担っているため、ミスがあると下流工程で大きなトラブルにつながる可能性もある重要な工程です。

次に、要件定義とは何かと目的について紹介します。

要件定義とは、開発を進める前段階にあたり、開発者側の視点から顧客の要求をまとめ、具体的な開発方針を定めることです。

まずは、顧客の要望をヒアリングし、実装すべき機能や性能を洗い出していきましょう。そして、要件定義では、業務フローやシナリオ、ユースケース図などを作成し、顧客と開発者側で認識の擦り合わせを行った上で、開発を進めていきます。

要件定義は、顧客の正確な要望や要求を定義し、プロジェクトを成功に導くことが主な目的です。そのため、システムの機能や性能を要件定義書として文章化し、落とし込むことが重要といえます。

システム開発では、顧客や下請会社、チームメンバーなど数多くの人が関わるため、記載内容を明確にし、読み手によって解釈が異ならないようにすることが大切です。後述する基本設計と目的が被らないように注意しましょう。

ここでは、基本設計とは何かと目的について紹介していきます。

基本設計とは、顧客の要求を機能ごとに分割し、機能の実現方法を決める工程を指します。また基本設計の成果物には、基本設計書がありますが、プロジェクトによって仕様や作成の仕方は大きく異なる場合があるため注意が必要です。

基本設計で定めたことは、次の工程である詳細設計に影響を与えます。そのため、細かい部分まで確認しながら設計することが大切です。外注先の担当者と意見交換をしながら進めていきましょう。

基本設計の目的は、外部から見たときのシステムの動きを決めることです。そのため基本設計は、顧客と開発者側が認識を擦り合わせながら進める作業が多くなっています。

そして基本設計では、要件定義で定めた内容をもとに基本設計書を作成して、顧客の要求する機能を具体化することが一般的です。そのため、要件定義の時点で認識の違いがあると、効率的に開発を進めることができなくなるため注意しましょう。

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

ここでは、詳細設計とは何かと目的について紹介します。

基本設計では、顧客や利用者の視点で設計を行いますが、詳細設計では、開発者側の視点で設計を行うことが一般的です。そのため詳細設計は、エンジニアやプログラマーなどの開発者側が中心となりプロジェクトを進めていきます。

そして詳細設計では、プログラムを構築するためにシステムの内部構成についての設計も必要です。具体的には、内部処理を行うタイミングや動作などの細かな調整も含まれます。

詳細設計の目的は、基本設計で定めた具体的な機能の実装方法を明確化することです。そのため詳細設計では、具体的なプログラムの組み立て方など、実際に構築するために必要な要素の設計を行います。

また詳細設計で定めた内容は、詳細設計書として文書化します。詳細設計書は、プログラマーなどが実際にプログラムを構築するためのインプット情報として使用されます。テスターや保守・運用担当者がシステムの内容を把握するために、インプットとして利用することもあります。

要件定義・基本設計・詳細設計の違いには、主に内容の違いが多く挙げられます。内容以外にも誰をターゲットとしてアウトプットを作成するのかも大きく異なる特徴です。

要件定義では、主に顧客向けにアウトプットを作成していきます。基本設計では、顧客と開発者側の両方に向けてアウトプットを作成し、詳細設計では主に開発者側に向けてアウトプットを作成するというそれぞれターゲットの違いを覚えておきましょう。

要件定義では、システムのあるべき姿の合意を顧客に取るための工程であるため、利用者の目線に立ち、わかりやすい文章や図・イラストを使用して要件定義書を作成します。

一方、基本設計では、要件定義をもとに顧客の要求を満たすための機能を明確にすることが特徴です。そのため基本設計書は、顧客が実際のできあがるシステムを把握するために使用されるだけではなく、開発者側がシステム構成を明確にするために作成されます。

基本設計では、顧客の要求を満たすためにシステムの実現方法を定める工程であり、システムの全体像や概要などを設計していくことが特徴です。

一方、詳細設計では、基本設計の内容をもとに実際にプログラムを作成できる状態にするための設計をしていきます。そのため、詳細設計書で使用する文章や図・イラストの多くは専門的な内容になりやすいことが特徴です。それぞれ求められる内容とタイミングに違いがあるため混同しないように注意しましょう。

基本設計は外部設計、詳細設計を内部設計と呼ぶことがあります。その理由について気になる方も多いのではないのでしょうか。基本設計では、システムの操作画面や操作方法など、利用者から見える部分の設計が一般的です。そのため、システム外部で目に触れる部分の設計を行うことから外部設計と呼ばれます。

一方、詳細設計では、基本設計をもとに実際にプログラムを構築できる状態まで、細かく落とし込むことが特徴です。システム内部で利用者や顧客の目には見えない部分の設計を行うことから内部設計と呼ばれます。

基本設計書は、システムの機能を具体化し、落とし込むために作成されることが特徴です。また、基本設計書は、顧客と開発者側で認識を擦り合わせる目的もあります。

ただし、プロジェクトによっては基本設計書を作成しない場合や、基本設計書と詳細設計書を同じ文書で作成するなど、成果物としての形はさまざまです。そこでここからは、基本設計で作成される成果物について詳しく紹介していきます。

基本設計では、全体の流れを把握するための主な成果物を解説していきます。まずは機能一覧として、実装するシステムを機能ごとに分割して一覧化します。

次に、業務フロー図として実装するシステムを使用した業務の流れや作業手順を表現した図を作成し、状態遷移図（ステートマシン図）として状態の移り変わりを図面化して表現した図も作成します。また、データフロー図（DFD）として、データの流れを表現した図の作成。入出力関連図として、画面や帳票などがどういったテーブルを参照・更新しているかを表現した図も作成します。

基本設計では、どのような画面があるのか、その画面で実現できることは何か、画面同士のつながりはどのようになっているのかなどを設計していきます。

また、ユーザーインターフェイスの使い勝手によって顧客のシステムに対する印象や評価は大きく異なることもあるため、重要な要素です。実装するシステムにおける画面一覧や画面が表示される順序や画面同士の関連性を表現した画面遷移図（画面展開フロー）、画面に表示される項目・レイアウト・操作方法・遷移ページなどを表現した画面設計書などがあります。

帳票を出力する機能のあるシステムの場合には、帳票関連のアウトプットは必須です。なお、ここでいう帳票とは、受注伝票や入金伝票などを指しています。

基本設計における帳票設計では、いつ、誰が、どのような情報を、どういった形式で、どこから出力するのかを決めることが一般的です。主な成果物には、実装するシステムの出力する帳票一覧や帳票に表示される項目や構成などを表現した帳票設計書などがあります。

基本設計では、バッチ処理の入出力データや処理のタイミング、バッチ処理同士の関連性などを設計します。バッチ処理とは、コンピューターでひとまとまりのデータを一括で処理する方式のことです。バッチ処理は、基本的に顧客の目には見えない部分で動きます。

主な成果物は、実装するシステムにおけるバッチ処理一覧やバッチ処理のタイミング・順序を表現したバッチ処理フロー図。バッチ処理の入出力データや、実行される処理の内容、参照・編集するデータなどを表現したバッチ処理設計書などがあります。

基本設計では、使用するデータベースの種類や、データの保存や処理などの管理方法を設計します。データを使用するシステムであれば、データベース関連のアウトプットは必須です。

例えば、大規模なシステムとなると、数百以上のテーブルを用意しなければならない場合もあります。主な成果物は、実装するシステムで構成されるテーブル一覧、データベースのテーブル定義書（項目名・データ型・キー情報など）、データ同士の関係性を表現したER図（ERD）などが一般的です。

基本設計では、実装するシステムが外部のシステムと連携する場合、連携方法や連携する要素を決めます。ほかのシステムと連携するシステムを開発する場合には、他システムとの連携関連のアウトプットは必要です。

主な成果物には、実装するシステムと連携するシステムのインターフェースの外部インターフェース一覧や インターフェースでやり取りするデータや、連携方法などを表現した外部インターフェース仕様書などがあります。

基本設計では、実装するシステムを安定的に稼働させるために、サーバーやネットワーク、セキュリティなど、ITインフラを整備するための設計が必要です。ただし、開発の規模によっては作成されない場合もあります。

主な成果物には、サーバーやデータベース、ネットワークなど、ITインフラの構成を表現したシステム構成図、実装したシステムを安定して稼働させるための運用ルールや運用方法、障害対応などの情報をまとめてフレームワーク化した運用設計書などがあります。

基本設計は、上流工程に位置し、設計にミスがあると、その後の工程でトラブルが発生し、手戻りが生じてしまう可能性もあります。そのため、失敗を防ぐためにはあらかじめ基本設計を行う際のポイントを押さえておくことが大切です。

ここからは、基本設計を行う上で、押さえるべき重要なポイントについて詳しく紹介していきます。はじめて基本設計を行うという方は参考にしてみてください。

基本設計を進めていく際に、要件定義とズレがないかどうかを定期的に確認することが大切です。基本設計は、要件定義をもとに作成するため、ズレがあると顧客の要求を満たすことができなくなってしまう可能性もあります。

例えば、基本設計を進めていくと、要件定義で詰めきれていない箇所や実現が困難な箇所が生じることは少なくありません。このような場合は、基本設計の担当者の判断で進めるのではなく、顧客と話し合い問題の解決に努めるのが得策です。

基本設計では、顧客や設計担当者、開発担当者、テスター、運用担当者などシステム開発に関する幅広い視点をもって設計を行うことが大切です。そのため、基本設計などの上流工程に関わる担当者は、これまでのシステム開発に関する経験やノウハウが問われます。

例えば、実際にシステムを使用する利用者を意識せずに基本設計を行うと、リリースした後に使い勝手の悪いシステムとなってしまう可能性があります。そのため、開発者側の視点だけではなく実際に使用する利用者の視点をもち、基本設計を行うことが重要です。

基本設計では、システムの具体的な形ができていないために、あらゆる機能を含めてしまうことは少なくありません。ただし、理想だけで進めていくと、下流工程で機能を実装できないなどの問題が生じるという恐れがあります。

そのため、工数が増えて納期に間に合わなかったり、品質が落ちてしまったりする可能性もあります。例えば、基本設計で明確な機能の実現方法が思い浮かばない場合には、有識者にレビューしてもらうことがおすすめです。

基本設計は、顧客と開発者側がシステムのあるべき姿を擦り合わせる最後のタイミングとなることも多いでしょう。

基本設計の後で修正が必要となった場合には、手戻りが発生し、顧客とシステム会社の間で、改めてスケジュールやコストの調整を行わなければなりません。手戻りのないシステム開発が理想ではありますが、現実的には限界があります。

そのため、設計の精度を上げることに加え、手戻りが生じる事態を想定しながら、スケジュールを管理したり、代替手段を用意したりしておくことも大切です。このように基本設計が問題なく完成し、プロジェクトを成功に導くためには、設計担当者のエンジニアとしての経験やスキルが要求されます。

ここでは、詳細設計で作成される成果物について紹介します。詳細設計では、基本設計で考えた大枠をもとに、実際のプログラムを構築するまでの部分を細かく設計することが特徴です。主な成果物をそれぞれ紹介します。

画面に関する成果物には、反映を表す画面一覧や画面ごとの移動を表す画面遷移図、レイアウトや総合的な情報を表す画面設計書などがあります。また、売り上げや入金などの帳票一覧表、テーブルを把握するための一覧表や設計書、ER図、CRUD図などはデータベースを把握、管理するための成果物です。

さらに、ドキュメントとしてデータの場所や名称を把握するためのファイル一覧表やファイルレイアウトも作成します。システム全体の構成を把握するために、項目定義書やコード定義書、システム構成図も必要です。

大規模なシステム開発の場合は、スケジュール管理や予算管理の観点からウォーターフォール型を採用することが多くなっています。しかし、小規模なシステム開発の場合やスピードが求められる開発の場合は、ウォーターフォール型が適していないこともあるため慎重に選択することが必要です。

例えば、小規模なシステム開発の場合、要件定義・基本設計・詳細設計の作業が一体となっており区別がないこともあります。このような場合は、顧客と合意が取れて、実装するシステムが明確であれば問題はありません。そのため、システムの規模や顧客との距離感などを踏まえて、適切な開発手法を選択するのがおすすめと言えます。

最後に、システム開発を外注した際にかかる費用相場をご紹介します。

システム開発の費用相場をご紹介しました。より正確な費用を知りたい方は料金シミュレーターをご利用ください。

要件定義・基本設計・詳細設計は、それぞれ目的が異なります。特に基本設計は、システムを顧客とシステム会社で擦り合わせる最後の機会となるため、重要な工程です。

システム開発を依頼する場合は、複数の会社を比較して実績やノウハウを確認することが大切。ただし、手間や時間がかかり大変な作業になってしまいます。外注選びに迷われている方は、まずはアイミツに問い合わせください。アイミツではご要望を伺った上で、条件に合うシステム開発会社を無料で複数社ご紹介可能です。システム開発で困りごと・悩みのある方は、お気軽にご相談ください。

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

【費用感を知りたいという方はこちら】
システム開発の費用・相場