「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典

まずは、システム開発の基本的な流れを見ましょう。

システム開発において、スタートは お客さまの「何がしたいか」です。
自社サービスの場合は、社長とか発案者が お客さまの立ち位置になります。



ゴールは「できあがったシステム」です。



システム開発というのは、スタートの「何がしたいか」をゴールの「できあがったシステム」に変換する作業です。



とはいえ、一足飛びにゴールにたどり着くことは できません。
一歩一歩進んでいく必要があります。

最初にやるべき作業は、お客さまの「何がしたいか」を まとめることです。

お客さまだって人間です。
自分の言いたいことを きちんと伝えられるとは限りません。
あるいは、お客さま自身が自覚していない「やりたいこと」もあるはずです。

ですから、お客さまの実現したいことを詳しく聞き取ります。
そして「あなたが やりたいのは、こんなことだよね？」を お客さまと一緒にまとめます。
これができれば、後から「本当は こんなことを やりたかったのに！」と文句を言われる可能性も減るでしょう。

この工程を「要件定義」と言います。



さて、要件定義でまとめたのは「お客さまのやりたいこと」です。
「どんなシステムを作るか」では ありません。

次の工程では「お客さまのやりたいこと」を踏まえて「どんなシステムを作るか」を考えます。

ただし「木を見て森を見ず」にならないように気を付ける必要があります。
そこで、まずはシステムの全体像をざっくりと考えます。

細かい部分は後で考えることにしましょう。
まずはシステム全体の完成図を思い浮かべるのです。
例えば

・何を目的としたシステムなのか
・何をするシステムなのか
・そのシステムには、どんな機能があるのか
・そのシステムは、どんな機器で動くのか
・どうやって、そのシステムを作っていくのか

などを決めます。

この工程を「基本設計」と言います。
要件定義を参考にして「それじゃあ、実際にどんなシステムを作ろうね？」をざっくりと考える工程を指します。



さて、基本設計で考えたのは「システムの概要」です。
全体像は何となく見えてきましたが、まだ実際の物を作ることはできません。
実際のプログラムを作るには、内容が大雑把すぎるのです。

そこで、基本設計の内容をもとにして、もっと細かい部分を考えます。
どれくらい細かい部分まで考えるかというと「うん、これだけ決まっていればプログラムが作れそうだね」と思えるまでです。

この工程が「詳細設計」です。

基本設計をもとにして、実際にプログラムが作れるように詳細を詰める工程

を指します。
実際のプログラムは、詳細設計で詰めた内容をもとにして、作ることになります。



これが詳細設計の説明ですが、せっかくなので、以降の流れも書いておきますね。

詳細設計の後は、プログラミングの工程に入ります。
ただし、場合によっては、詳細設計とプログラミングの間に「プログラム設計」をやります。



プログラムができたら、それをテストします。

プログラムというのは、一塊のものを一気に作ることは ほとんどありません。
プログラムの部品を いっぱい作って、それを合体することで完成させるのが普通です。

そこで最初のテストは「合体前の部品は それぞれ ちゃんと動く？」を確認するテストです。
このテストを「単体試験」と言います。



次に、それぞれの部品が「合体して ちゃんと動く？」を確認するテストをやります。
このテストは「結合試験」です。



最後に、システム全体のテストをやります。
言わば、卒業試験みたいなものですね。
このテストを「総合試験」と言います。



これが、システム開発の一般的な流れです。



繰り返しになりますが、このシステム開発の流れにおける（実際のプログラムを作るのに必要な）システムの詳細を考える工程が詳細設計です。



なお、要件定義や基本設計、詳細設計の区切りは結構あいまいです。
同じ作業を、基本設計でやる現場もあれば、詳細設計でやる現場もあります。
工程をもっと細かく分けたり、逆にいくつかの工程を飛ばす現場もあるでしょう。
各工程で何をどこまでやるかは、そのお仕事現場のルールに合わせてください。