40代からのフリーランスエンジニア向け・案件検索サイト【SEES】
40代からのフリーランスエンジニア向け・案件検索サイト【SEES】
システム開発における基本設計と詳細設計にはどのような違いがあるのでしょうか。この記事ではシステム開発の主な工程、各工程での設計内容、成果物、設計についての課題などを紹介します。設計業務に携わるエンジニアを目指す方、理解してお役立てください。
＜業界実績18年＞
ミドル・シニアフリーランス専門
エージェントSEES
40～60代以上のシニアエンジニア案件探しは、私たちにお任せください！
ご登録者様限定で、Webに公開していない非公開案件をご提案いたします。
目次
「基本設計では何を定める？」
「基本設計と詳細設計の違いはどこにある？」
「基本設計、詳細設計の成果物は？」
システムやサービスなどのソフトウェア開発の工程のうち「基本設計」と「詳細設計」は両方とも設計が名前に含まれています。ITエンジニアならばこの二つの工程の違いや作成対象となる成果物について詳しく知っておきたいところです。
この記事では、基本設計や詳細設計で定める内容、成果物やシステム開発の工程などを説明します。本記事を読むことで、基本設計や詳細設計で作成するドキュメント種別、各工程のつながりなどがわかり、エンジニアの業務に活用することが可能です。
基本設計と詳細設計の違いについて詳しく知りたいエンジニアは、ぜひ参考にしてください。
システム開発の工程はプロセスモデルによって異なります。広く利用されているプロセスモデルとしてはウォーターフォールモデルやアジャイルがあげられます。
ウォーターフォールモデルでのシステム開発の工程は、下記の7段階に分けることが多いです。※組織やプロジェクトにより詳細は異なる場合があります。
| 要件定義 | システムに必要な機能やプロジェクトの方針を定める |
| 基本設計 | 要件定義で定めた内容をもとに、システムの外部から見える輪郭を設計する。外部設計とも呼ばれる。 |
| 詳細設計 | 基本設計をもとに、より具体的にシステムを構築するための内部構造、データの取り扱いなどを設計する。内部設計とも呼ばれる。 |
| プログラミング | 設計に沿ってプログラムの開発を行う。開発や実装と呼ばれることもある。 |
| 単体テスト | 開発したプログラムを単体レベルでテストする。ユニットテスト（UT）とも呼ばれる。 |
| 結合テスト | 単体のプログラムを結合し、複数のプログラムを連携させたレベルでのテストを行う。 |
| システムテスト | システムとしての機能レベルでのテスト。 |
テストまで完了後は、システムをリリースして運用・保守へと続きます。
ウォータフォールモデルでの開発では、基本的に前工程のアウトプット（成果物）が次工程のインプットとなります。つまり、前工程で決定した内容に基づき次の工程を進めることが重要な前提です。通常は工程は順序通りに進められ、前の工程に戻ることはできません。
アジャイルはさらに細かくスクラム、FDD、プロトタイプなどに分類されますが、ウォーターフォールと比べ小さな単位での開発とリリースを繰り返す場合に採用されます。設計も細かく分類を分けることは少ない傾向にありますが、考え方としておおむね同様です。
基本設計では、要件定義で決めた内容を基にシステムの全体像を構築していきます。人の目に触れる部分について具体的に決めていくことから、外部設計と呼ばれることもあるでしょう。
ここでは、顧客にシステムの概要を伝えることが目的になってくるため、基本設計で作られた基本設計書などの成果物は、顧客が読んでも伝わるようにわかりやすいものを作る必要があります。
詳細設計では、プログラムの実装に向けて仕様の詳細を定めます。具体的には、プログラムの構造、処理やデータの流れ、異常系のハンドリングといったレベルまでの設計です。
詳細設計書は、クライアントの目には触れることは少なく、プログラマーなどの開発者へ向けたドキュメントです。この詳細設計に基づいて、開発者はプログラムを実装し、システムなどを実現します。プログラムなどのシステムの内部的な部分を設計するため、内部設計とも呼ばれます。
基本設計と詳細設計の大きな違いとして、基本設計はシステムの外部から見える部分を定め、詳細設計はプログラムの構造やデータなど具体的にプログラミングを行う際に必要な内部的な情報を定めることが挙げられます。基本設計ではシステムの概要や機能レベルでの動作など大まかな内容、詳細設計ではより小さいプログラムなどの単位に分割して具体的に作ることができるレベルの内容を定めます。
また、想定する読者にも違いがあります。基本設計はクライアント向け、詳細設計はプログラマーなどの開発者向けに作成します。このため、基本設計は、専門的知識を持たない人でも作成される機能などが想定できるドキュメントにします。詳細設計は、専門的な知識を持った開発者が実際にプログラムを作成するための情報が記載されていることが必要です。
システム開発では、単にプログラムの実装のみを行うわけではなく、段階的にさまざまな工程を経てシステムを作り上げます。実際にプログラムを作成するのは開発工程ですが、それ以前にプログラムを使った機能の大枠やその内部的な構造などを定める基本設計や詳細設計という重要な工程が存在しています。
開発対象によって異なりますが、基本設計では機能一覧表やシステム構成図、画面設計図などの設計書を作成することが一般的です。設計内容を文書化したドキュメントが基本設計工程の成果物となります。
以下では、基本設計で作成する各ドキュメントについて詳しく紹介します。
機能一覧表とは、要件定義を基にシステムに必要な機能をまとめたものです。より具体的には、画面一覧、帳票一覧、バッチ一覧などが該当します。
この機能一覧表は、システム全体の機能を網羅した全体像の把握、開発ボリュームの把握や作業の割り振りなど幅広い用途で使われます。また、クライアントとシステムが必要な機能を十分に満たしているか、足りない機能はないかを確認するツールとしても重要です。
システム方式設計書は、システムが用いるハードウェア、ソフトウェア、ネットワーク、外部との連携インタフェースなどを記載するドキュメントです。インフラまでを含んだ、広い視点でシステム全体を定義します。
システム方式が定まるとセキュリティへの対策なども大まかに定まるため重要性の高いドキュメントです。構成要素を図形にして線でつないだシステム構成図なども、方式設計書に含まれます。
画面設計書は、システムがもつ画面の表示、機能、操作などを定めた設計書です。画面設計書では、Webアプリや業務アプリなどのそれぞれの画面のデザイン、ボタンや入力部品の配置などを記載します。
画面設計書は、実際にユーザーが触れる部分のため、基本設計の中でもクライアントも重要視するドキュメントです。
画面を持つシステムの場合、一つの画面に多くの機能を持たせると使い勝手が悪くなります。このため、機能ごとに画面を分割し、複数の画面間を遷移して利用することが想定されます。この画面間の遷移を定義するのが画面遷移図です。
画面の遷移にはボタンのクリックや項目への入力などのアクションを関連付けます。業務の導線と合わせて、ユーザーの利便性を考慮した設計が必要です。
バッチ設計書とは、バッチ処理のフローやI/O、ジョブスケジューリングなどを表したドキュメントです。バッチとは、あらかじめ決められた時間に作動して一連の処理を自動的に行うプログラムを指します。
バッチ設計書では、要件定義でまとめられたバッチの一覧を基にバッチの種類や起動時間などをまとめていきます。バッチ設計図もクライアントも確認する設計書であるため概要レベルの記載にとどめ、処理の詳細は詳細設計書で記載します。
帳票設計書とは、システムが出力する帳票をまとめたドキュメントです。たとえば業務アプリを開発する場合、請求書や見積書、受発注書などさまざまな書類を扱うことになるため、どんな内容を記載した帳票がどのような形式で必要か、わかりやすくまとめます。
帳票設計書では、帳票に出力する項目、帳票のレイアウト、出力の条件などを記載します。なお、帳票を出力しないシステムの場合、帳票設計書は不要です。
基本設計の段階でシステムで扱うデータの概要が判明しますが、多くのシステムではこれらのデータをデータベース上に格納します。一般的に広く用いられているRDBでは、テーブルというデータの格納形式を用い、このレイアウトを定めるのがテーブル定義です。
基本設計でのテーブル定義ではシステム内でデータを扱う単位や関係性を概念レベルで定め、RDB上の項目名やデータ長などは詳細設計で定めるケースが多いです。
詳細設計では基本設計で定められた内容をもとに、以降の工程でプログラムとして作成できるレベルまでブレイクダウンを行います。したがって、作成される成果物は、プログラマーなどの開発者向けのドキュメントとなります。
ここでは詳細設計の成果物の例を紹介します。詳細設計で作成するドキュメントや記載レベルは企業やプロジェクトによって異なるため参考としてください。
アクティビティ図とは、システムの流れをまとめた図です。システムが動き出してから終了するまでの処理を順番に記載していきます。フローチャートもプログラムなどの処理を図式的に表した図です。
アクティビティ図やフローチャートを作成することで、処理の流れを把握・整理し、処理に無駄があった場合にも気づきやすくなります。また、他の開発者と認識の共有を図る上でも有用です。
なお、アクティビティ図の作成は、より詳細なシーケンス図の作成につながります。
クラス図とは、クラスの定義や関係性などの構造を表した図です。
オブジェクト指向は、プログラムとして実現するモノを中心に考えて設計する考え方です。オブジェクト指向におけるクラスとは、オブジェクトの設計図にあたります。
特に規模の大きなシステム開発では、複数人のプログラマーが分業しながら開発を進めるため、オブジェクト指向を採用するケースが多いです。クラス図を作成して、プログラムの構造を分割して設計し、プログラムの開発を分担することでスムーズな開発を実現します。
クラス図では、クラスで定義する値やメソッドをまとめることにより、クラス同士の関連性をわかりやすくすることができます。処理の共通化を図る際にも、クラス図による整理は重要です。
シーケンス図とは、時系列でクラスやオブジェクト同士のやり取りを示した図です。システム内部の処理を細かく記載したもので、時系列で処理を記載するため、処理の流れを把握しやすくなります。
アクティビティ図よりも、より詳細に処理を把握するために用いられます。作成するコストは大きいですが、保守運用のフェーズでも役立つドキュメントです。
詳細設計フェーズでは、基本設計で定めたテーブル設計に詳細な情報を付加して完成させます。データベース上の具体的な項目名や項目の型、桁、データ格納上のルールなどが設定内容です。このテーブル定義をもとに、DBMS上にテーブルなどのオブジェクトを構築します。
ER図は、英語では「Entity Relationship Diagram」でデータベース上のテーブル間の関係を表現する際に利用するドキュメントです。システム上で利用するデータを俯瞰して参照できる点が最大の特徴です。
テーブル定義がデータ一つ一つの個別の設計にあたるのに対し、ER図は一つのドキュメントでシステム内で扱うデータ全体を参照することができます。開発者やシステムの管理者にとっても重要な役割を果たすドキュメントの一つです。
システム開発において設計は非常に重要な工程です。しかし、設計にはいくつかの課題があると言われています。
ここでは、設計についての課題を紹介します。
システム開発に使用するプログラミング言語は、世界共通であり、多くのプロジェクトでフレームワークを導入しているためルールに沿った開発が必要となります。したがって、開発時の属人化はある程度防ぐことが可能です。
しかし、設計の場合にはエンジニア共通の基準などが明確に定められていない場合が多く、属人化が起きやすいという問題があります。このような理由から、組織の中でもプロジェクトチームごとに設計方法に違いが出るケースも存在しています。
世界標準のような大きな決まりがない分、組織ごとの標準などをたてることが一つの対策です。インターネット上のサンプルなどを活用して定めてみるとよいでしょう。
設計に関してはISOなどの大きな規格はありますが、世界標準となるほど浸透した基準が存在していません。そのため、属人化を防ぐためには組織としてルールを作成する標準化を行う必要があります。その実現には、違う人が作成しても同じように設計ができるツールの導入など、標準化のための仕組みも重要です。
例えば、開発プロセスの標準としてIPAの共通フレーム2013があげられます。しかし、詳細な設計内容については組織やプロジェクトによって異なり、テーラリングが必要です。
また、サンプルとして大阪市情報システム開発ガイドラインなどの個別の組織による標準も役立ちます。
システム開発の本質は開発ではなく設計です。開発対象をあいまいな状態から具体化していく仕事といえます。
ITエンジニアが数ある選択肢の中から、適切な選択を組み合わせてシステムというモノづくりをする工程なのですが、そこには柔軟性があり要件を満たすための方法が複数ある場合もあります。要件を考慮した最適な選択は簡単ではなく、今後AI技術が発達していったとしても代替が難しいと考えられる由縁です。
しかしながら、何のためのシステム開発、設計なのかを十分に理解していない場合には、品質の低いシステムが構築されたり、クライアントの希望とは異なったものとなってしまう事態が発生します。プロジェクト全体でシステムの目的について共通認識を共有し、設計者はそれに向けた設計を行うことが求められます。
40代からのフリーランスエンジニア向け・案件検索サイト【SEES】にて掲載中の案件より、「基本設計、詳細設計」を業務に含む例を紹介します。
▼基本設計
SEESで基本設計関連の案件を探す
▼詳細設計
SEESで詳細設計関連の案件を探す
基本設計、詳細設計の各工程とその違いについて、よくある質問と回答をまとめています。詳細については本文内に記載しておりますので、そちらもご参照下さい。
要件定義に基づき、システムの大枠となる概要を定めます。ユーザーや連携する他システムなどの外部から見える部分の設計を行うため外部設計とも呼ばれ、成果物として作成されることの多いドキュメントは以下です。
基本設計で定めた内容を詳細化し、プログラミングが可能なレベルまで細分化を行います。プログラムの構造、データの保有の仕方など内部を定めるため、内部設計とも呼ばれ、作成した設計書は主に開発者に参照されます。代表的な成果物の例として、下記が挙げられます。
基本設計、詳細設計ともにITシステムやサービス、アプリケーション構築のためのプログラムの設計を行うことは共通しています。違いとして、設計の粒度や対象の読者が挙げられます。
システム開発の工程では、要件定義、基本設計、詳細設計という順序が一般的です。順番に細分化していくことから、ドキュメントの粒度が異なります。
基本設計はクライアントの承認を得ることも目的となるため、専門的知識を持たない相手も理解しやすい記載が求められます。一方の詳細設計で作成するドキュメントは開発者に向けたものです。
システム開発における設計の工程には、基本設計と詳細設計という2つの設計フェーズが存在しています。記載の細かさや対象とする読者が異なり、設計のアウトプットとなる成果物にも違いがあります。
基本設計、詳細設計の違い、成果物に関する理解を深めることでエンジニアとしてのスキルが高まります。ポイントを押さえておきましょう。
40代～60代向けミドル・シニアフリーランスエンジニアの案件サイト『SEES』
40代～60代でエンジニアとして活躍したいと考えている方におすすめなのが、株式会社Miraieが運営する、ミドル・シニアエンジニア向けの案件サイト『SEES』（https://miraie-group.jp/sees/）です。
SEESとは-Senior Engineer Entrustment Service-の略称で、40代～60代エンジニア向けの案件紹介サービス。
エンジニア業界は、40代以上の転職はなかなか厳しい市場だと言われています。
転職ではなくフリーランスとして案件を獲得することを視野にいれてみてもいいかもしれません。
SEESの場合、掲載している案件は主に年齢不問ですので、年齢制限に関係なく、純粋にスキルや希望条件での案件を探すことが可能です。
会社員よりも個人事業主としてプロジェクトを請け負う形であれば、働き方としても選べる立場にありますよね。
給与の支払いサイトは30日で統一されています。
また、取引社数が5,000社以上と多く、新しい案件が集まりやすくなっています。
さらに、SEESに登録をすると最新・未公開案件を獲得することができます。
独立してフリーランスになっても仕事が途切れる心配はありません！
『SEES』（https://miraie-group.jp/sees）を利用して新しい働き方を手に入れてみては…！？
皆さまから選ばれてミドル・シニアエンジニア向け検索サイト三冠達成しております！
株式会社Miraieが運営する『SEES（https://miraie-group.jp/sees）』は、 「シニアエンジニア向け検索10サイトを対象にしたサイト比較イメージ調査」のなかで、
上記3項目においてNo.1を獲得ししております。
株式会社Miraie
2007年設立のシステム開発会社。首都圏を中心にWeb・IT関連事業、コンサルティングサービス、人材派遣サービスなどを展開。 SES事業や受託開発などを中心にノウハウを蓄積しながら、関連事業へとビジネスの裾野を広げています。
監修者インフォメーション
SEESは
非公開案件が80%以上
ITに特化したコーディネータが
あなたにぴったりの案件をご提案
SEESってどんなサービス？
＼ 簡単60秒 ／
