システム開発の流れとは…

今回は、システム開発の流れを説明します。

まずは、“難しく”フェーズ別に流れを書くと次のようになります。

さて、聞きなれない言葉が並んでいますね。

これをもう少しわかりやすく“簡単に”説明しましょう。

いかがでしょう？

イメージできました？

なんとなく、各フェーズのイメージができたでしょうか。

システム開発と言っても、モノ作りと基本的には同じ流れですね。（システムもモノなので当たり前でした。）

概要設計、詳細設計、プログラム設計…？

システム設計フェーズに「概要設計（基本設計）」「詳細設計（外部設計）」「プログラム設計（内部設計）」とあるのに気がついたでしょうか。

実は、システム開発には明確なルールはなく、各フェーズの呼び名も企業風土やプロジェクトによって異なるのです。

「概要設計」と呼ぶプロジェクトもあれば、「基本設計」と呼ぶプロジェクトもあります。同じことを言っているのだと思ってください。

また、ルールが決まっていないために、全てのフェーズを必ずしも行う訳ではありません。「プログラム設計（内部設計）」や「総合試験」は省略されることも多いですし、テストの工程がもっと多いこともあります。

各工程の詳細の説明

各工程をもう少し詳しく見てみましょう。

1.要件定義（要求分析）

クライアントからどのようなシステムを作りたいのか話を聞くフェーズです。希望や要望、現在の運用方法などを聞き、どのようなシステムを作るのか大まかにまとめます。

ここで、しっかりと話を聞いておかないと実際にシステム設計や開発に入ったときに、「機能が足りない」とか「イメージとちがう」と言われ、もう一度クライアントから話を聞くことになります。

不要な後戻りをしないためにも、聞き上手になることが大切です。聞き上手は、三文の徳。

2.システム設計

どんなものを作るのか紙に書きます。実際は Word や Excel、Webのツールなどを使います。

2-1.概要設計（基本設計）

大まかなシステムの設計をします。要件定義で聞いた内容を具体化するチカラが求められます。

また、それぞれの画面の連携などシステム全体をみるチカラが必要です。

2-2.詳細設計（外部設計）

画面別に、どのような動きをするのかを決めます。抜け穴がないように細かく物事を決めるチカラが求められます。

2-3.プログラム設計（内部設計）

プログラムを書く前に、フローチャートなどを利用して動作を決めます。プログラミング言語で書くことを代わりに日本語で書く、と思ってください。

3.開発

実際にプログラムを作ります。要件定義から始まり、だんだんとプロジェクトに参加する人が増えてきます。

昨今では、「開発」フェーズを海外で行うこと（オフショア開発）もあります。その場合、「受け入れ」というフェーズが追加されます。実際に海外で開発したものが動くかどうか確認をします。

3-1.プログラミング

ひたすら無口に設計書をもとにプログラムを書くフェーズ．．．ではなく、実際は設計書の指示通りに書くのですが、論理矛盾や設計漏れがあった場合に開発者にどうしたらいいのか聞く必要があり、プログラミング能力以外にコミュニケーション能力が求められます。

3-2.単体試験

自分が制作したプログラムが、詳細設計書の指示通りに動くか確認をします。

データを受け取ったりして動作するときには、ダミーデータを作成します。考えられる全てのパターンをテストしないといけないため、プログラミングと同じかそれ以上の時間が必要です。

4.テスト

開発フェーズで製造したプログラムが実際に動くかどうか調査します。

4-1.結合試験

関連する画面同士で連携試験をします。

このとき、開発者とは別の人がテストすることが好ましいと思います。

4-2.総合試験

システム全体を通して連携試験をします。

4-3.運用試験

実際の運用を想定して、クライアントと一緒にテストをします。ここで利用するのは、本番と同じデータです。

5.検収

クライアントに納品の許可をもらいます。検収が終わると実際にシステムが稼働します。

成果物のまとめ…

各フェーズにおける成果物の一覧をまとめておきます。

制作する会社、プロジェクトによって作成するものしないものがあります。

全てのドキュメントが必須な訳ではありません。また、ここに記載のないドキュメントを作成することもあります。

ドキュメントの量が多いですが、どのドキュメントを納品するかクライアントに確認する必要があります。