基本設計と詳細設計の違いは？進め方や注意点などシステム開発の工程別に解説！

システム開発を行う際は多数の企業が複雑に絡み合うこともあり、各プロジェクトの進捗状況を逐次把握し、決められた工程を確実かつ慎重に進めていかなければなりません。

エンジニアのなかには、「システム開発において全体像がイメージできない」「他のエンジニアが担当する箇所のことについて深く知らない」という方もいるのではないでしょうか。

システム開発では、基本的な工程として「要件定義」「基本設計」「詳細設計」「プログラミング」「単体テスト」「結合テスト」「総合テスト」「運用テスト」「システム移行」「保守・運用」が存在します。

各工程で実施している内容は複雑で、他の工程と絡み合うことでさらに構造が分かりにくくなってしまうため、実際に全体像をイメージするのに苦労するエンジニアも少なくありません。

本記事では、そんなシステム開発における工程のうち、基本設計と詳細設計の違いにフォーカスして解説しています。

また、システム開発の全体的な進め方や注意点などについても紹介しています。

ぜひ、最後までご覧ください。

1.システム開発全体のイメージ像

システム開発全体のイメージ像が想像できない人もいるでしょう。

ここでは、システム開発全体のイメージ像について詳しく解説していきます。

概要を下記にまとめました。

• 要件定義（要求定義）

• 基本設計（外部設計）

• 詳細設計（内部設計）

• プログラミング

• 単体テスト

• 結合テスト

• 総合テスト（システムテスト）

• 運用テスト

• システム移行（リリース）

• 保守・運用

それぞれの工程を詳しくみていきましょう。

要件定義（要求定義）

要件定義は、クライアントと打ち合わせをしながら導入方法・開発手法の種類・予算など、システム開発に必要な要件を決定していく工程です。

細かな情報までヒアリングしなければ、要件が相違してしまうこともあるため注意しなければなりません。

トラブルを未然に防ぐためにも、入念な打ち合わせが必要です。

基本設計（外部設計）

基本設計（外部設計）は、要件定義の工程内容をもとに、相互に改善・フィードバックしながらエンジニアが完成を目指す工程です。

エンドユーザーが主に触れる部分ですので、ユーザビリティや操作性が問われます。

また、レイアウトや色彩など細かく設計しなければなりません。

詳細設計（内部設計）

詳細設計（内部設計）は、各システム会社の技術者向けの設計のことをいいます。

具体的な実装を想定したデータフロー図・データベース物理設計書・機能仕様書など、専門的な資料を作成します。

プログラミング

プログラミングは、詳細設計書の内容をもとに、各開発会社のシステムエンジニア・プログラマーが実際にコーディングを行います。

システム開発の根幹を担う工程であり、コードを最適化する技術が求められるでしょう。

要件定義（要求定義）以降の工程でつくりあげてきた構想が、形になる瞬間です。

単体テスト

プログラミング工程完了後は、作成したプログラムが要件定義で定めた通りの動きをするかの確認をするため、テスト工程に入ります。

比較的規模の小さなソースコードから走らせて行うことから、単体テストと呼ばれています。

結合テスト

単体テストで各モジュールの不具合の有無を確認後、結合テストを行います。

サブシステムに不具合が生じないかどうかを確認します。

また、各サブシステムの連携・各サブシステムのインターフェースのズレの有無などもチェックしましょう。

総合テスト（システムテスト）

結合テストで各サブシステムの不具合がないことを確認したら、次は総合テスト（システムテスト）を行います。

システム全体に不具合がないかの確認をするシステムテストを総合テストと呼びますが、運用前のテスト工程における最終調整前の段階です。

運用テスト

運用テストは、システム開発において最終工程といえます。

クライアントの要望も考慮し、機能が正常に稼働するか・誤操作しにくい仕様になっているかなど、ユーザーが使う際に起こりうる不具合などを想定してチェックしていきます。

仮にトラブルやエラーが発生した際には、前工程に差し戻すこともあります。

システム移行（リリース）

各テスト工程が完了すれば、いよいよシステム移行の工程に進みます。

開発したシステムをリリースする際は、旧システムから新システムに移行する必要があるため注意が必要です。

互換性を見極めながら、ミスしないようにリリースの準備に入りましょう。

保守・運用

保守とは、サーバダウンなどのトラブルが発生したときに対応手順書に従って処理を行うことです。

一方で運用とは、システムのアップデートや改修など、システムに変更を加えることをいいます。

無事にシステムがリリースされた後は、保守・運用にて管理していきます。

2.基本設計と詳細設計のシステム工程でやるべきこと

基本設計と詳細設計のシステム工程でやるべきことはそれぞれ違います。

その内容を下記にまとめました。

• 基本設計でやるべきこと

• 詳細設計でやるべきこと

それぞれについて、詳しくみていきましょう。

基本設計でやるべきこと

要件定義にもとづいて外側からみて動きを確認することが、基本設計の役割です。

基本設計で設計する項目について下記にまとめました。

• ER図：データベースのER図の作成

• テーブル定義：データベースのテーブルの定義

• 帳票レイアウト：帳票のイメージ

• 画面レイアウト：画面イメージ

• 機能一覧表：開発範囲となる機能の一覧

• 業務フロー：業務の流れを理解し機能を探り出す

• ネットワーク構成図：ネットワークの構成

詳細設計でやるべきこと

社内開発者がクライアントを意識せずに、開発向けに作られることが大半なのが詳細設計の特徴です。

詳細設計で設計する項目について下表にまとめました。

3.基本設計と詳細設計の進め方の違い

要件定義の内容を反映させるために、工程で実装する機能を具体化していくことを基本設計といいます。

一方、詳細設計は基本設計のあとに行い、設計で機能をどのように実装するのかの工程です。

基本設計の進め方

基本設計を行う際の進め方について詳しく解説していきます。

内容を下記にまとめました。

1. 要件定義書の内容を確認する

2. 設計を行う

3. 基本設計書を作成する

4. レビューを行う

それぞれについて、詳しくみていきましょう。

1.要件定義書の内容を確認する

メンバー同士の情報を調整して妥協点を見出していき、要件定義をもとに設計します。

2.設計を行う

確認した要件をもとに設計を行います。主な設計作業は「画面レイアウトの決定」「実装する機能の洗い出し」「必要なデータの明確化」です。

システムの骨組みを決定することは重要なため、必要な作業といえるでしょう。

3.基本設計書を作成する

基本設計書はシステムの具体的な仕様をクライアントに伝えて、問題ないか確認を促す役割があります。

4.レビューを行う

設計者が気付きにくい修正点をみつけるために、クライアント側とメンバー内、それぞれの評価者からレビューを受けます。

そのため、改善につながりやすくなります。

詳細設計の進め方

詳細設計は、基本的にエンジニア向けに作成するものです。

進め方について下記にまとめました。

1. 基本設計書の内容を確認する

2. 設計を行う

3. 詳細設計書を作成する

4. レビューを行う

それぞれについて、みていきましょう。

1.基本設計書の内容を確認する

詳細設計では、システムの全体像を具体化します。

認識をメンバー内ですり合わせなければなりません。

2.設計を行う

詳細設計書に記載された各機能をプログラムでの実現を目指します。

下記に主な作業についてまとめました。

• 機能やビジネスロジックの整理

• 実装する機能の割り振り

• 共通化できる部分の設計

• プラットホームに合わせた設計

3.詳細設計書を作成する

詳細設計書はエンジニアに向けた指示書となるため、専門用語が並ぶことも特徴の1つです。

4.レビューを行う

誤字や仕様の問題以外にも、等号・不等号の明確さ・渡される値の範囲など細かい部分まで確認しなければなりません。

詳細設計書の完成後に、メンバー内からのレビューを受けることもあります。

4.基本設計と詳細設計で注意するべきポイント

基本設計と詳細設計の違いを理解したうえで、注意するべきポイントも意識しなければなりません。

ここでは、基本設計と詳細設計の注意点をまとめました。

詳しくみていきましょう。

基本設計の注意点

基本設計を行ううえで、留意すべきポイントについて下記にまとめました。

• さまざまな視点から全体像を意識する

• 要件定義との整合性

• 実現方法は適切か

基本設計で重視すべきは、広い視野を持ちさまざまな角度から考えることです。

クライアント視点からみることや開発以降の工程や詳細設計も考慮して、要望に沿うシステムを実現するよう意識しなければなりません。

要件定義との整合性が取れていなければ、完成したシステムはクライアントのニーズとは離れてしまうため、基本設計と要件定義の整合性を取ることは重要です。

そして、要件定義書に記載された要件にはさまざまな実現方法があります。

基本設計の段階で、適切な実現方法を選択する必要があるため留意しましょう。

詳細設計の注意点

詳細設計の注意点については、「曖昧な表現は避ける」「説明文はシンプルに」です。

エンジニアが詳細設計書をみて、すぐにプログラミングに取り掛かれるような発信を目指すことが重要です。

疑問をもたれないように曖昧な表現は避ける必要があります。

また、説明文は可能な限りシンプルなほうが望ましいです。

どうしても長文になる場合は、表や図を用いたり箇条書きにしたりして、表現方法を工夫するとよいでしょう。

5.基本設計と詳細設計の課題

基本設計と詳細設計の注意すべきポイントについて理解したところで、次に基本設計と詳細設計の課題について解説していきます。

その内容を下記にまとめました。

• 設計の基準が存在しない

• 課題の本質を探りにくい

• 標準化の仕組みが上手く機能していない

それぞれについて、詳しくみていきましょう。

設計の基準が存在しない

基本設計と詳細設計の課題の1つは、設計の基準が存在しないことです。

基本的には世界標準の言語を使用するため、ある程度の属人化は防げる傾向にあるところに特徴があります。

システムを構築するためのプログラミングを理解しておく必要がありますが、開発チームごとにコードに違いがあることから断続的に属人化することもあるため注意が必要です。

課題の本質を探りにくい

基本設計と詳細設計には、課題の本質を探りにくい傾向があります。

ソフトウェア開発における設計は、顧客へのヒアリング内容をもとに作成した要件定義をベースにします。

そうすることで、顧客が持つビジネス上の課題を解決可能なソフトウェアの図面を作れるでしょう。

標準化の仕組みが上手く機能していない

基本設計と詳細設計の課題として、標準化の仕組みが上手く機能しないことも挙げられることから注意が必要です。

設計から属人化を排除するためには組織が定めるルールを作成する必要があることを標準化といいます。

徹底した属人化の排除には標準化の仕組みが重要となるでしょう。

6.基本設計と詳細設計における問題解決のその先にあるもの

次に、基本設計と詳細設計における問題解決のその先にあるものについて解説していきます。

内容を下記にまとめました。

• 設計にかかる時間短縮

• 容易にデータベース管理できる

• 属人化の排除

• 設計後における成果物の品質向上

それぞれについて、詳しくみていきましょう。

設計にかかる時間短縮

基本設計と詳細設計の課題を解決することは、企業にとって高い生産性をもたらします。

例えば、システム設計にSI Object Browser Designerを導入することで時間短縮の効果が得られ、従来、開発設計に費やしていた時間を半分以下にできます。

問題が解決すれば、労働環境の改善や業務の最適化が図れるところは大きなメリットになるでしょう。

容易にデータベース管理できる

基本設計や詳細設計の問題が解決すると、プロジェクトを介した開発環境において、「いつ」「何を」「誰が」変更したのかなどをトレースしやすくなります。

データベースですべての設計情報を一元管理できるところは、特徴的といえるでしょう。

属人化の排除

基本設計もしくは詳細設計での属人化は、システム開発においても課題として残ります。

もし、それらの課題が解決できれば属人化を排除するきっかけとなるでしょう。

属人化とは、特定の人しかその業務が行えないという状況のことです。

フォーマット形式や記述ルールが決まっていない会社では、属人化が起きやすくなるところが懸念されます。

設計後における成果物の品質向上

基本設計や詳細設計の工程において、問題を解決できれば成果物の品質向上につながります。

また、システム設計ツールを使用すれば、質のよい設計書を作りやすいでしょう。

設計書作成を自動化するツールなど、便利な機能が組み込まれているため、短時間で作成可能となります。

7.基本設計と詳細設計の課題を解決する方法

基本設計と詳細設計の課題を解決する方法は、設計を平準化することです。

社内ルールだけフォーマットや設計書の記述を縛ることは難しいため、基本的にはどこかで設計者独自のものが組み込まれてしまいます。

少しでもそうしたケースがあれば、設計の平準化は不可能になってしまうため注意しましょう。

システム開発ツールを活用する

システム開発ツールを活用することで、基本設計と詳細設計の課題を解決しやすくなります。

システム開発ツールは、さまざまありますが、設計を平準化するために最適なツールを選ぶことが重要です。

例えば、SI Object Browser Designerを導入することでシステム開発における時間短縮の効果が得られ、もともと設計に費やしていた時間を最適化できるでしょう。

ベンダーレベルで設計のフレームワークを構築する

ベンダーレベルで設計のフレームワークを構築するのも、基本設計と詳細設計の課題を解決する方法としては有用です。

ベンダーが抱える課題に対して、フレームワークを当てはめることで解決への道筋がみえてくるでしょう。

システム開発の流れが可視化され、各工程における問題も明確に判別しやすくなるだけでなく、従業員の行動も把握しやすくなるため、ぜひ活用することをおすすめします。

8.まとめ

今回は、要件定義などいくつか存在するシステム工程のうち、基本設計と詳細設計の違いについて解説してきました。

基本設計は外部要因から工程を進める一方で、詳細設計は内部的目線でシステムを構築していきます。

つまり、基本設計ではシステムの動きを外部から確認して「どのように動いているのか？」という視点で捉える必要があるということです。

それに対して、詳細設計では基本設計で得られた情報から「どう実現するのか？」という視点で考えていかなければならないところに違いがあります。

また、基本設計と詳細設計はシステム開発における全工程の一部でもあることから、要件定義でヒアリングした情報はしっかりと定義する重要な役割を担います。

もし、不備が発覚すれば下流工程に上手く情報が伝わらず大きな損害に繋がることもあるため、注意しましょう。

本記事が皆様にとって少しでもお役に立てますと幸いです。