バーニィの徒然なるままに

※スマホで表示がおかしくなる方はコチラ ※本サイトはJavaScriptを有効化して御覧ください
最終更新日:2014/04/22

プログラマー、システムエンジニアというお仕事


まず、プログラマーやシステムエンジニアと分ける前に、
情報業界で一つのシステムや、ソフトウェアを作る際の基本的な作業の流れを説明します。

各作業での細かい内容は、それぞれのページで説明します。
具体的な作業内容が知りたいんだという方は、メニューから知りたい作業内容のページに遷移してください。

なお、情報業界自体がまだ歴史の浅い業種であり、技術革新も頻繁に起こっている業界なため、
効率のいいやり方を常に試行錯誤しています。

ここでは基本的な作業の流れを説明しますが、
これは会社やプロジェクトリーダーの判断などによって、大幅に異なる場合もありますのでご了承ください。

情報業界の構造
一つのシステムやソフトウェアを作る際の基本的な作業の流れ
システムエンジニアの作業内容
プログラマーの作業内容
システムエンジニアとプログラマーの違い
おまけ 人月という考え方と問題点
おまけ 「会社B」「会社C」はなぜ「お客様」から直接仕事を受けないのか?
最後に



情報業界の構造


作業内容の前に一つ、情報業界は複雑怪奇な構造をしていますので、その説明だけしておきます。

まず、仕事を発注する「お客様」がいます。
こういうことがしたいので、お金を出すからこんなシステムを作ってほしいという、一番上位の会社になります。

次にその仕事を受注する「会社A」があります。
そのシステムを作るには1,000万円かかりますが、当社なら問題なく作れますよ!と仕事を受ける会社です。

ここでその「会社A」が設計・開発をすれば何も複雑にならないのですが、ここからおかしくなります。

仕事を受けた「会社A」はそもそも社内に設計・開発できる手の空いた社員はいません。
そのため次に「会社B」にこんなシステムを作りたいので、500万円で作ってくれ。
と仕事を発注します。

会社Bはこの仕事を500万円で受けますが、ちょうど社内に手が空いている作業者が少ないため、
「会社C」に助っ人として、何人かを100万円で借り受けて作業をします。

1.「お客様」
↓1,000万円で仕事発注
2.「会社A」
↓500万円で仕事発注
3.「会社B」
↓100万円で助っ人を借り受け
4.「会社C」

と、このような形になります。
規模の大きいプロジェクトになると、「会社A」が「会社B」「会社X」「会社Y」の3社に発注するようになるなど、
さらに複雑になります。

一応何故このような状態になっているのかも、説明しますが、
それよりも、ここで説明している「お客様」「会社A」「会社B」「会社C」の、
どこに就職するかで仕事内容や給料が変わるということは知っておいてください。


1.「お客様」
1,000万円で仕事を発注しても十分元が取れる。と判断して仕事を発注しますので、
大手企業の場合がほとんどです。
TVでよく見かける企業などもほぼここになります。

「お客様」の仕事とは、どんなシステムを作りたいのかを、社内の人間などと相談し、
具体的なものにしていくこと。
開発が順調に進んでいくか、定期的に確認すること。
開発途中のものが、意図したものであるのかを実際にテストさせてもらったりして、確認すること。
などがあります。

設計を見たり、質問することはありますが、まず設計・開発には携わりません。

大手企業でしかも、大きい仕事を発注・監督する立場にあるので、
一番給料がいいでしょう。
(まあ就職+出世が一番難しいとも思いますが)


2.「会社A」
一括で仕事を受注できる資金力があります。
(今回の例の1000万円では規模が小さいので、中小企業の場合もありますが^^;)
この立場も大手企業がほとんどです。
TVでは見かけないかもしれませんが、上場企業だったり、中小企業ではなく大企業の分類に入っている会社が多いです。

「会社A」の仕事とは、「お客様」がに作りたいシステムの概要を聞いてまとめたり、
作りたいシステムの見積もりを行ったり、下請けの「会社B」に作業を発注したりします。

場合によっては、要件定義や設計なども行うこともありますが、
逆に見積もりも「会社B」に任せて、それを確認して「お客様」に見せるだけの場合もあり、作業内容はまちまちです。
運用・メンテナンスはここがやる場合もあります。
(その場合、簡単なことなら会社Aが対応して、技術的なことは会社Bなどに相談したり対応させます)

ここも大企業の場合が多いため、給料はかなりいいです。


3, 4.「会社B」「会社C」
「会社B」「会社C」は下請けの企業となり、企業数や人口はここが一番多いでしょう。
中小企業や、派遣会社などはここになります。

作業内容は様々です。

「会社A」からシステムの内容を聞いて、具体的なシステムを設計・開発・テストまで行いますし、
場合によっては見積もりを行う場合もあります。

給料は安いところから高いところまでまちまちですが、設計工程が出来た方が高くなる傾向があります。

このサイトでは主にこの下請け企業の作業内容を説明します。


おまけ
会社Aと下請けの会社B, Cを見分ける方法は簡単です。

企業情報の売り上げを従業員数で割ってください。

社員1人当たりの売り上げが数百万から千万円くらいの企業は、
上流工程を行う「会社A」の企業です。


逆に社員1人当たりの売り上げが100万円かそれ以下の企業が、
下流工程を主に行う「会社B」「会社C」の企業です。


上流工程の会社は、数人で数千万円規模のプロジェクトを扱うことが多いため、
このような差が出てきます。
(売上での比較なので、利益はまた別です)



一つのシステムやソフトウェアを作る際の基本的な作業の流れ


一つのシステムを作る際、主に以下のような作業工程で行います。

人数はだいたいの参加人数をイメージしてもらうための例として書きました。
30人が一人一工程のみ作業を行った場合、各工程にだいたいこれくらい参加するよという例です。

同じ30人でも、システムの規模や作業のやり方、納期によって数値はかなり変わる場合がありますし、
一人が複数工程を担当するのは当たり前のようにあることなので、本当にただの人数比率の目安としてみてください^^;

1.見積もり (1人)

2.要件定義 (3人)

3.論理設計 (4人)

4.物理設計 (5人)

5.プログラム (8人)

6.テスト (7人)

7.運用・メンテナンス (2人)


作業の流れと人数比率はだいたい上記のようになります。

上流工程とよばれる見積もりから設計までの作業は人数が少なく、
下流工程であるプログラム、テストは人数比率が多くなり、
システムが完成したあとのメンテナンスで一気に人数が減ります。

ただし、次期バージョンアップの規模が大きい場合や、完成した直後でバグも残ってる場合などは、
完成した後も設計者やプログラマーなどが残り、再度見積もりから作業がスタートすることもよくあります。
そのため、運用・メンテナンス専任の担当者はいない場合もよくあります。

以下、流れを大雑把に説明します。

1.見積もり
作成するシステムにはだいたいこれくらいの人数で、これだけの期間かかりそうなので、
この値段になります。という見積もりを出します。
主に、経験豊富なベテランや、プロジェクトマネージャーなどの偉い人がやります。

2.要件定義
このシステムを実現するには、こういう機能が必要で、だいたい何画面くらいの画面作る必要があります。
などの概要を考える段階です。
論理設計と合わせて作成する場合もあります。

3.論理設計
要件定義よりもう少し踏み込んだ設計を行います。
機能毎にどんなことを行うかを設計します。
画面間の遷移を考えたり、画面のイメージを考えたりもします。
「曖昧設計」「基本設計」「外部設計」など、呼び方は会社、プロジェクトごとに違ったりします。

4.物理設計
実際の機能毎の動作を設計します。
プロジェクトによってどこまで細かく書くかはまちまちですが、
「if文をここで書く」「この処理を10回繰り返す」など、ほぼプログラムの内容を書くほど細かい場合もあります。
(逆に論理設計並みの曖昧な設計書の場合もあります。)
これも「プログラム設計」「詳細設計」など、呼び方は会社、プロジェクトごとに違ったりします。

5.プログラム
実際に設計書を見ながら、プログラミングをしていきます。
C言語やJavaなど、どのプログラム言語を使用するかは、そのプロジェクト毎に違います。
このプログラミングと、後工程のテストが一番人数比率が多くなります。

6.テスト
プログラムされたシステムをテスト仕様書とよばれるどんなテストをすればいいのかが記述されている設計書を見ながら、テストします。
プログラマーがここを兼任する場合もよくあります。
ちなみにテスト仕様書は、本来は設計者が設計段階で作成するのがベストだと思うのですが、
物理設計で作成されたり、プログラム段階で作成されたり、テストをする人が自ら作成したりとバラバラです^^;

7.運用・メンテナンス
作成したシステムをお客様に納品後、
実際にシステムを稼働したり、お客様やユーザーから苦情が来た場合の対応を行います。
設計とプログラムを両方行った人が、このメンテナンスに残る可能性が高い気がします。
(仕様もわかって、実際にプログラムの修正も行えるため)


以上が作業の流れになります。
次にシステムエンジニア、プログラマーの実際の作業範囲はどこなのかを説明します。



システムエンジニアの作業内容


作業の流れなどを説明してきましたが、
では実際にシステムエンジニアはどの作業を行うのか?というと
上流工程の企業はまた変わりますが、
下流工程の企業では、見積もり、設計、プログラム、テスト、メンテナンス全て行う可能性があります。

この中でも、見積もりはベテランにならないとほぼ経験することはないですし、
メンテナンス要員は設計からテストまでプロジェクトに関わっている人がなる場合も多く、
これまた経験することはあまりないかもしれません。

ですが、設計、プログラム、テストの作業はほぼ必ず経験しますし、メインの業務内容になります。

システムエンジニアだから設計メインという印象もあるでしょうが、
全くそんなことはありません。
それは大企業でのイメージです^^;



プログラマーの作業内容


では実際にプログラマーはどの作業を行うのか?というと
主にプログラム、テストになります。

ただし、その二つしかしないのかというと、そんなこともありません^^;

プログラムをしていて、設計書の誤りに気付くことは多々あります。
その時に、設計した人に設計書を直してもらうことになりますが、
設計者が忙しくて直している暇がなく、プログラマーが直すこともあります。

直すだけならともかく、必要な機能自体が設計から漏れていて、プログラマーが設計書から作る場合もあります。

そのため、確かに設計初期からプログラマーが設計するということはないですが、
設計書の作成を行うこと自体はよくあります。



システムエンジニアとプログラマーの違い


フリーでプログラムしかしないよっていう契約しかしない人でもない限り、
ほとんどの場合、システムエンジニアとプログラマの分け方に意味はないです^^;

作業内容にほとんど差がないためです。
設計の作業が多ければシステムエンジニア、プログラムの作業が多ければプログラマー。程度の考え方でいいと思います。

実際、システムエンジニアとして企業に就職したとしても、
経験と積むまではプログラムかテストしかやらせてもらえない場合もあります。

経験を積んで設計が出来たとしても、会社が受けている仕事と空き要員のタイミングによっては、
プログラムとテストだけやって、終わったら次のプロジェクトへ。
という場合もよくあります。



おまけ 人月という考え方と問題点

情報業界では作業量の単位として、「人月」(にんげつ)や「人日」(にんにち)「人時」(にんじ)という単位を使います。

1人が1か月(20日)に出来る作業を1人月としている単位です。

10人が1か月(20日)で出来る作業は10人月。
1人が10か月で出来る作業も10人月。
という計算になります。

人日は1人が1日(8時間)に出来る作業量です。

1時間で出来る作業なら0.1人日などの書き方をします。
(厳密には0.1ではないですが、細かい数値をいちいち計算するのは時間の無駄なので、仕事でもだいたいの人日で計算します。)


で、何がいいたいのかというと、
情報業界ではこの人月での計算で見積もりを行ったり、普段の仕事の割り振りを考えるのが主流なのですが、
この人月という考え方には重大な問題点があります。

これが情報業界がブラックな業種になる要因の一つだと管理人は思っていますが・・・

問題点1
一つは、仕事の出来る人、出来ない人の作業速度は考慮されないことです。

この業界、仕事の出来る人と出来ない人の差は20倍以上の差があるなどといわれたりもしますが、
実際に数倍程度の実力差は当たり前のように見かけます。

人によっては2時間かける作業を、出来る人は数分で終わらせる。みたいな感じです。
これは本サイトの作業効率アップで説明しているような、便利なツールを知っているか知らないかで明暗を分ける場合もありますし、
メニューの「あると便利なスキル」で紹介している正規表現を知っているかどうか、などの場合もあります。
もしくは、パソコンスキルではなく、別の簡単なやり方を思いつく、「応用力」「発想力」などの場合もあります。

見積もり時に出来るだけ、作業が遅い人を基準に見積もりを行う努力はしますが、
「お客様」側としては当然、人月を減らして少しでも料金を安くしてほしいわけです。

そうなると、営業や見積もり担当の人の腕の見せ所になりますが、
お金を出す方が当たり前ですが偉いので、大抵負けます^^;

そうなると、普通の技術者か少し出来る人の作業量、もしくは「お客様」が前に別の企業と取引した時の作業速度が基準になったりします。

それでも、実際に業務する側の能力が高い人ばかりが集められていれば問題ありません。
が、大抵作業が空いている人から選ばれますので、仕事の出来る人と出来ない人が混合してプロジェクトはスタートします。

この時のメンバーによっては、プロジェクトが始まる前から負けている場合があります^^;

平均して1人月の仕事を1か月で出来ればいいのですが、平均したら1人月の仕事を1.5か月かけないと終わらせられない。という場合です。

こうなってしまうと、どう乗り切るかというと、1か月で1.5人月分働くしかありません^^;
休日出勤や、残業で頑張るしかないのです。

上の人は締め切りを延ばしてもらうという努力はするのですが、
お客様にダメと言われればそれまでですし、
伸びたとしても、遅れれば遅れた分だけ、会社は赤字です。

そうなると遅れさせないようやっぱり頑張るしかありませんorz


問題点2
例えば、100人月のプロジェクトで考えます。

これは10人で作業すると、10か月かかりますが、
100人投入すると、なんとたったの1か月で終わる計算です。

・・・ええ 100人投入すれば1か月で終わるなんて無理です。

でも、ここまではひどくなくても、納期が短い場合は近いことが行われます。

33人で3か月で終わらせる。くらいは普通にありえます。

こうなった場合にどうなるかというと、
33人をしっかりまとめ上げて作業の無駄を作らないリーダーやマネージャーがいて、
メンバーもあまりにひどいメンバーでさえなければ問題ありません。

3か月という期間があれば結構なことが出来ます。

しかし、うまくチームが機能しない場合、
これもまた休日出社や、残業によって、遅れを取り戻すしかありませんorz

あまりにひどいと、リーダーやマネージャーが別の人に変わるということもよくありましたが、
新しいリーダーは、引き継ぎや作業状況の把握などをしなければならず、
やはり効率はよくありません。

1か月目くらいですぐリーダーが変わった。など、早めの対応がされていれば挽回も可能ですが、
よっぽど新しいリーダーが出来る人でないと、まず無理です^^;


人月の計算にはこれらの問題点があり、
納期が遅れた場合は、「お客様」にも下請け企業にもダメージがあるため、
この人月での計算は問題視されていますが、
この単位だと、わかりやすい。考えやすいという利点が大きく、情報業界でのメジャーな計算方法になっています。



おまけ 「会社B」「会社C」はなぜ「お客様」から直接仕事を受けないのか?


これは経営者の立場からだとまた別の理由があるような気はしますが、
管理人が理解している範囲では、単純に「会社B」「会社C」にはお金がないからです。

「お客様」から直接仕事を受けるということは、仕事に失敗した時には違約金を払う可能性が出てきます。
また、違約金は払わなくても、納期に遅れるということは会社の信用にかかわります。

そのため、納期に遅れそうなら別の下請けに頼んででも、納期に間に合わせる必要が出てきます。

上流の会社は安く下請けに仕事を発注して丸儲けしているように見えますし、
まあ実際に一番利益も高いですが、一番リスクも背負っているのです。

資金力のない中小企業では、違約金を払うなんてことになったら倒産の可能性もでてきますし、
納期の遅れを取り戻そうと思うと、残業で頑張るしか取れる方法がなくなってきます。

そのため、リスクは少ないが儲けも少ない下請けという立場に立たざるを得ない。
というのが管理人の理解です。



最後に

最後まで読んでくれた方、ありがとうございます。

これで一応大雑把な情報業界の説明は終わりますが、
もっと詳細な作業内容が知りたい場合は、メニューから各作業のページに遷移してみてください。

管理人が経験した内容を元に、記載していますので、実際の業務の雰囲気はつかめるかと思います。

情報業界は決して楽な職業ではありませんが、
システムが完成した時の喜びなど、いいところもある職業です。

就職するか検討している方の参考になれば幸いです。




Copyright © 2014 barney.webcrow.jp All Rights Reserved.
ご意見、ご要望はこちらまで→webbarney80@gmail.com