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

順番に見ていきましょう。
まずは予備知識として

・ウォーターフォール型
・上流工程
・下流工程

について簡単に説明します。
「そんなの説明されなくても知ってるよ！」な人は適当に読み飛ばしてください。

ウォーターフォール型は、システム開発のやり方のひとつで「工程を1つずつ順番に終わらせていく やり方」です。
水が高いところから低いところに流れ落ちるように、最初の工程から最後の工程に向かって1つずつ順番に終わらせていきます。



ウォーターフォール型の開発では、全体の作業がいくつかの工程に分けられます。
一般的なのは

１．要件定義
２．基本設計
３．詳細設計
４．プログラム設計
５．プログラミング
６．単体試験
７．結合試験
８．総合試験

のような分け方でしょうか。



各工程の中身が分からない人は、それぞれの用語の説明を ご覧ください。
また、お仕事現場によっては一部の工程がなかったり工程の呼び名が違ったりします。
そこら辺は、ゆるく捉えてください。

上流工程は「システム開発において前半でやることになる作業」です。
要件定義や設計などの「どんなものを作るか考える作業」が該当します。

下流工程は「システム開発において後半でやることになる作業」です。
プログラミングや試験などの「実際にものを作る作業」が該当します。

先ほどの工程分けを もう一度 見てください。

１．要件定義
２．基本設計
３．詳細設計
４．プログラム設計
５．プログラミング
６．単体試験
７．結合試験
８．総合試験

です。

実は、これらの工程は大きく2つに分けられます。
それは

１．要件定義
２．基本設計
３．詳細設計
４．プログラム設計

と

５．プログラミング
６．単体試験
７．結合試験
８．総合試験

です。



開発の前半にやる

１．要件定義
２．基本設計
３．詳細設計
４．プログラム設計

は「考える作業」です。
頭をウンウン悩ませて「何を作る？」や「どう作る？」といった内容を決めます。



開発の後半にやる

５．プログラミング
６．単体試験
７．結合試験
８．総合試験

は「実際に作る作業」です。
「考える作業」で決まった内容をもとにして、プログラムを作ったり、作った物がおかしくないかテストします。



この2つに分類した工程のうち、前半の

１．要件定義
２．基本設計
３．詳細設計
４．プログラム設計

が上流工程です。
システム開発の作業工程を川の流れに見立てると、上流の方でやる作業ですよね。



後半の

５．プログラミング
６．単体試験
７．結合試験
８．総合試験

が下流工程です。
システム開発の作業工程を川の流れに見立てると、下流の方でやる作業ですよね。



お仕事現場によっては、区切り方が違う場合もありますけどね。
基本的には、そんな感じです。

以上を踏まえて

システム開発における下流工程をやるのが主な仕事の職業

が「プログラマ」です。
「programmer（プログラマ）」を省略して「PG」と呼ばれる場合も あります。



あと、ついでなので書いておくと、上流工程をやるのが主な仕事の職業は「システムエンジニア」や「SE」と呼ばれています。



とか言いつつ、結合試験以降の大事なテストはシステムエンジニアが中心になってやることが多いですけどね。
プログラマさんが中心になってやる仕事は、詳細設計やプログラム設計から単体試験くらいまでが多いはずです。



プログラマの主な仕事は「手を動かすこと」です。
いわゆる「実装」と呼ばれる作業が中心になります。

システムエンジニアの主な仕事は「考えること」です。
いわゆる「設計」と呼ばれる作業が中心になります。

システムエンジニアさんが考えた構想をプログラマさんが現実化するイメージです。

……というのが基本ですけどね。
実際のお仕事内容は現場次第です。



一般的に、上流工程と下流工程では上流工程の方が重要視される傾向にあります。
それは上流工程の方が

ミスるとヤバい

からです。

新作料理の発表会で考えるとイメージしやすいかもしれません。

新作料理の発表会において、料理がレシピ通りに作れませんでした。
どうしましょうか？

簡単ですね。
作り直せば良いだけです。
時間が足りなかったら、人を増やすとかの対応も考えられます。

それでは、レシピ自体が間違っていたら、どうでしょうか？
これは、もう、お手上げですよね。
一から考え直さなくては、いけないわけですから。

システム開発も同じです。

下流工程のミスは比較的、簡単に取り戻せます。
決して喜ばしい状況では ありませんけどね。
プログラムに不具合（バグ）があったとか、作るのが遅くて時間が足りないとかであれば、人を増やせば何とかなります。

一方で上流工程のミスは取り戻すのが大変です。
必要な機能が漏れていたとか、機能同士の関係性に矛盾があったとかが発覚すると考え直しです。
考える作業は人を増やせば何とかなるとも限りません。
しかも、間違った状態ですでに物を作っていたら、その作った物は全部、使えません。
工数が無駄になります。

そんなわけで、上流工程は比較的ベテランの人が担当する傾向にあります。
経験が少ない人は、最初は下流工程から関わることが多いはずです。

そのため、システム開発の仕事に携わると、最初はプログラマから始まるのが一般的です。
他の人が作ったプログラムをテストしたり、他の人が設計したのを実際に作ったりするのが、お仕事です。

経験を積むに従い、作業の質と量が重くなってきます。
テストしかやらせてもらえなかったのが実際に作らせてもらえるようになり、簡単な機能しか作らせてもらえなかったのが重要な機能を作らせてもらえるようになったりします。

そして、あるとき「設計もやってよ」と言われるのです。

そこから先も似たようなものです。

作る仕事（プログラマ的な仕事）が中心だけど簡単な設計もやらせてもらえるようになり、そのうち重要な設計もやらせてもらえるようになり、設計が忙しくなるにつれて作る仕事（プログラマ的な仕事）をやっている暇がなくなったりします。

ですから、まぁ、その人が「プログラマ」なのか「システムエンジニア」なのかは

どちらを名乗っているか次第

です。

プログラムを作ったことがないのに「プログラマ」を名乗ったり、テストしかやったことがないのに「システムエンジニア」を名乗るのは、さすがに微妙ですけどね。
そうでなければ、自己申告な職業です。

人が足りなくてプログラマな人が設計したり、あるいはスケジュールが遅れていてシステムエンジニアな人が実際にプログラムを作ることも多々あります。
地続きになっている職業なので、明確に区別するのは難しかったりします。