IT-Skills

基本設計(外部設計)と詳細設計(内部設計)の違いは?

本ページでは、基本設計と詳細設計の記載内容の例を説明しつつ、それぞれの違いをなんとなく理解できるよう解説していきます。

基本設計は、現場によって「外部設計」、詳細設計は「内部設計」とも呼ばれますが、本ページでは「基本設計」「詳細設計」の用語で統一します。

基本設計と外部設計は同じです、現場によって呼び方が異なるだけです。

基本的には、呼び方が変わるだけなので深く考えなくてOKかと思います。

また、前提として基本設計と詳細設計の区別は「現場によって多種多様である」ことをご理解いただければと思います。

前の現場では基本設計で決めるものなのに、今は詳細設計で決めなきゃいけないらしい・・・・

なんてことが、往々にして起こるのです。

これは、システム開発には「法令」がなく、各社独自の方法論で開発を進めるため、結果として「基本設計」と「詳細設計」の区別も独自の理解で整理されているためです。

ただし、そのうえで一般的な理解としての「基本設計」と「詳細設計」が何者であるかは全社・全エンジニア共通で知っている必要があるのです。

「1社単独で」「1人だけで」システムを全ての開発はできません。

必ずあらゆる場面で他者とのコミュニケーションが必要となります。その際に、自分独自の誤った理解で作業を進めてしまうと思わぬ弊害を引き越してしまうかもしれません。

(これは、詳細設計で決めればいいことだよね!みたいな常識が他の人には通用せず何も決まっていない・・・・みたいな)

したがって、本ページでは「筆者独自の解説」に加えて、他のページへのリンクも合わせて記載し「どうやらこれが一般的な区別らしい」という定義を示したいと思います。

結論:基本設計と詳細設計の違い

最もよくある誤解から示します。

IT初心者が一番陥りがちなのが以下の理解です。

  • 基本設計 ⇒ 大雑把な設計
  • 詳細設計 ⇒ 細かい設計

これは深く考えれば、近からずも遠からずな解釈かもしれません。ですが、これでは、最初から細かい設計だけしておけば良いのでは?という疑問に答えることができません。

基本設計・詳細設計にそれぞれの役割があるからこそ、両者が別物として存在するわけであり、それぞれの作業の目的は違うはずです。

では、その区別とは何か?

私は「基本設計・詳細設計の目的(ゴール)」を考えた際に、以下の区別が最も的確であると考えます。

基本設計は、「詳細設計を行うために必要な情報(INPUT)を整理」することを目的とする。詳細設計は、「プログラミングをするために必要な情報を整理」することを目的とする。

こう定義したとき初めて、両者の区別が明確になります。

では、詳細設計に必要な情報、プログラミングに必要な情報とは何でしょうか?

Vモデルからその答えを探りましょう。

Vモデルから考える

Vモデルから、基本設計と詳細設計の立ち位置を考えてみます。下記の図は、Vモデルを一般的なイメージで表したものです。

Vモデル

Vモデルでは、V字の左側に「開発ステップ」を。右側に「テストステップ」を並べることになります。色別に区分した開発ステップが、それぞれのテストと対応します。

ここで、ポイントとなるのが「前の工程のOUTPUT」が「次の工程のINPUT」になるということです。すなわち、「要件定義」の結果を基に「基本設計」が行われ、「基本設計」の結果を基に「詳細設計」が行われ、「詳細設計」をもとに「プログラミング」が行われるということです。

Vモデルから考えた際に、基本設計が「詳細設計を行うために必要な情報(INPUT)を整理」することを目的とし、詳細設計は「プログラミングをするために必要な情報を整理」することを目的とする、という定義はぴったり当てはまりそうです。

実際にそのVモデルにしたがって、基本設計・詳細設計の例を示したいと思います。

例)基本設計・詳細設計の記載内容

ここからは具体例を用いて、詳細設計・基本設計に必要なINPUT情報とはどのようなものかを検討していきたいと思います。

例として、「じゃんけんプログラム」で考えてみます。

「じゃんけんプログラム」では、コンピュータとじゃんけんをし、勝敗の結果を画面に表示することとします。

じゃんけんプログラム:基本設計

基本設計では、以下のような設計を行ったとします。

① コンピュータと「じゃんけん」を行う。

② じゃんけんの結果を画面に表示する。

詳細設計者は上記の情報を基に、実際のロジックを考えます。

じゃんけんプログラム:詳細設計

詳細設計者は、基本設計を基に以下のようなロジックを整理しました。

① コンピュータに「任意の手(グー・チョキ・パーのいずれか)」をセットする

② ユーザに「手」を選択させる

③ コンピュータの「手」とユーザが選んだ「手」を比較する

  ③-1.ユーザが「グー」を選んだ場合

   (ア)コンピュータが「グー」なら「あいこです」を表示し、①に戻る。

   (イ)コンピュータが「チョキ」なら「あなたの勝ちです」と表示する

   (ウ)コンピュータが「パー」なら「あなたの負けです」と表示する

   ・・・・以下選択「手」ごとに同様・・・・

これで、何とかプログラミングに落とし込めそうです。

プログラマーも、この詳細設計を基にプログラミングを行い、コードレビューもクリア、単体テストも完了していきます。

結合テストで発覚した欠陥

結合テストも順調に進み・・・・かと思いきや、基本設計者がこんな指摘をします。

「なぜあいこの場合に勝負が続かないのか?バグである!」

さて、この欠陥の責任は基本設計者にあるか?詳細設計者にあるか?はたまた、プログラマーにあるか?

本定義に沿って、考えてみましょう。

基本設計で犯したミスとは?

基本設計では、

① コンピュータと「じゃんけん」を行う。

② じゃんけんの結果を画面に表示する。

という設計内容を記載しておりました。

基本設計者曰く「じゃんけんであいこになったら、普通じゃんけんを続けるだろう!」と。

では、詳細設計者のミスなのか?はたまたプログラマーのミスなのか?

答えは「基本設計者のミスである」となります。

なぜなら、「あいこの場合にじゃんけんを続ける」という設計情報はどこにも記載されていないからです。もしこれが、基本設計にその情報が書かれていれば、詳細設計のミスとなります。

ですが、今回の例で言えば出来上がったプログラムは詳細設計ともたがわず、詳細設計は基本設計とも異なりません。

基本設計では、あいこの場合にどうするか?という視点が欠けていました。詳細設計に必要な情報を整理することができていないのです。

このように考えた際もやはり、以下の公式は的を射てそうです。

WHAT/HOWの説

別のサイトでの区別も見てみましょう。

基本設計は、システムを外から見たときどういう動きをするか(=外部設計、What)を決めるもの。
詳細設計は基本設計で決められた動きを、どうやって実現するか(=内部設計、How)を決めるもの。

https://www.widesoft.co.jp/technology/3536

いかがでしょうか?

この説は非常にシンプルで分かりやすいです。基本設計では「WHAT」を決め、詳細設計ではその「WHAT」を実現する方法「HOW」を決める、とする説です。

さきほどのじゃんけんプログラムに当てはめてみます。

① コンピュータと「じゃんけん」を行う。

② じゃんけんの結果を画面に表示する。

上記は、基本設計できめた内容です。確かにこれを見るとその機能が何をするのか?を定義しているものです。

一方で下記詳細設計での内容は、その2つをどのように実現するか(HOW)?を決めています。

① コンピュータに「任意の手(グー・チョキ・パーのいずれか)」をセットする

② ユーザに「手」を選択させる

③ コンピュータの「手」とユーザが選んだ「手」を比較する

  ③-1.ユーザが「グー」を選んだ場合

   (ア)コンピュータが「グー」なら「あいこです」を表示し、①に戻る。

   (イ)コンピュータが「チョキ」なら「あなたの勝ちです」と表示する

   (ウ)コンピュータが「パー」なら「あなたの負けです」と表示する

したがって、WHAT/HOW説も言葉は違いますが、同じことを言っているように見えます。

WHAT/HOW説で分かりにくいこと

ただし、一見シンプルに見えるWHAT/HOW説ですが、分かりづらい部分があるのではないかとも感じます。

基本設計で、以下を決めました。確かにこれは、確実にWHATです。

① コンピュータと「じゃんけん」を行う。

② じゃんけんの結果を画面に表示する。

では、詳細設計の内容はどうでしょうか?捉え方によっては、これもWHATに見えてきます。

① コンピュータに「任意の手(グー・チョキ・パーのいずれか)」をセットする

② ユーザに「手」を選択させる

③ コンピュータの「手」とユーザが選んだ「手」を比較する

そうです。WHAT/HOWの定義では、両者の区別が不明瞭な場合があるのです。

画面の入力チェック」は基本設計に入るでしょうか?詳細設計に入るのでしょうか?

WHAT/HOWの区別の場合では、曖昧な線引きと言わざるを得ない箇所が出てきます。

次工程を考慮した開発が重要

やはり、WHAT/HOW説などのように基本設計と詳細設計を一言で区別することは難しいのです。

したがって、基本設計は詳細設計のため、詳細設計はプログラミングのため、というようにVモデルにもとづいた形で考えることが重要です。

会社ごとに、プロジェクトごとに記載内容は違っても良いのですが、原則として「その設計書で次工程が遂行できるか?」という点をしっかり吟味する必要があるのではないでしょうか?

新着記事はこちら

【SAP】ビュー(view)を1から説明

さて、ざっくりビューとは何でしょうか?と …
続きを読む

【ABAP】内部テーブルのテーブルデータ型とは?

内部テーブルと一口に言っても、ABAPを …
続きを読む

【SAP】SE11―ABAPディクショナリでできること一覧

本ページでは、トランザクションコード:S …
続きを読む

【SAP】アドオンテーブル作成―全6ステップ解説

検索しても意外と出てこない「アドオンテー …
続きを読む