プログラマーが気になるけど知識はゼロな人にまず押さえておいてほしい業界キーワード

▼誰に向けて書いてる？

・未経験でプログラマー就職を目指している方。
・プログラマーになることに興味はあるが業界の勉強はあまり捗っていない方。何から調べればいいかわからない方。
・求人票に書いていることがよくわからない方。

▼あなたは誰？

既卒・第二新卒・フリーター専門の人材紹介会社でプログラマー就職支援をしています。
運営している研修 → https://college.daini2.co.jp/programmer
twitterやってます → https://twitter.com/kikushige3
Javaの講座動画撮ってます → http://bit.ly/2Scxpvf

▼本題に入る前に

言葉の定義についてなのですが、ここではプログラミングで作るもの（WEBサービス、スマホアプリ、組み込みソフトウェア など）をまるっと「IT資産」と表現したいと思います。

組み込みソフトウェアとは簡単に言えばカメラやテレビなどの機械製品の中身のことです。

また、IT資産を構成する一つ一つの部品を「プログラム」と表現したいと思います。

▼これだけ押さえてて①：「プロジェクト」

IT資産の開発業務に携わる人（と言うより、もはやエンジニアという生き物全般）はほとんどが「プロジェクト」という「ある目的を達成するために集められた即席のチーム（あるいはチーム活動）」に所属して働きます。

基本的にプロジェクトは発注サイドと受注サイドの間で以下が合意されてからスタートします。

ゴール：何をもってプロジェクト完遂とするか
納期　：いつまでにゴール達成しなければならないか
予算　：ゴール達成に必要なお金
チーム：ゴール達成に必要なメンバー

プロジェクトに未経験の新人を入れるメリットはお金を払う発注サイドからすると「安さ」くらいしかありません。

そのため、始めに入るプロジェクトはかなり安い金額で（場合によっては育成枠として2ヵ月無償などの条件で）アサインされることが多いです。

▼これだけ押さえてて②：開発工程（＋運用／保守）

顧客がどんなIT資産を欲しいのかヒアリングし、設計書作って、実物作って、チェックOKだったら納品する。

プロジェクトの流れは基本的にこんな感じなのですが、このIT資産を作りあげるまでのプロセスを「開発工程」と言いまして、各フェーズには以下のような名前がつけられています。

▽要求分析
どのようなものを作る”べき”かを決めます。
「顧客の目的を叶えるIT資産がどのようなものか」「ユーザーはどのようなIT資産を欲しているか」「そもそもそのIT資産は必要なのか」などについてウンウン考えたり調査＆分析したりする、いわゆるコンサルっぽいことをするフェーズです。
特にビジネスフローをIT化するような場合、顧客の業務について深いレベルで理解している必要があります。
ここが雑だと「誰にも使われない粗大ごみ」が顧客に納品されることになります。

▽要件定義
「どのような機能を持つか」「どれくらいの性能か」などを明確化＆文書化します。
今回作るIT資産のゴール像を発注サイドと受注サイドで意識合わせするフェーズです。
ここが雑だと後の工程で大きな手戻りや訴訟などの不幸が双方に訪れます。

▽基本設計（または外部設計）
IT資産の外面をメインに設計していきます。
ユーザーが見て触る部分（画面、ダウンロードファイル、操作手順など）や環境（ハードウェア、ネットワーク、データベースなど）など、IT資産の全体像を具体化していくフェーズです。
イメージと相違ないか、要件定義で考慮の漏れていた点についてどう対処するかなど、確認・相談・共有といった顧客とのコミュニケーションが頻繁に発生します。

▽詳細設計（または内部設計）
プログラムの中身を設計していきます。
「こうやってプログラム書いてね」「加工したデータはこのプログラムに渡してね」のようなプログラマーのための設計書（詳細設計書）を作ることがメインになるフェーズです。
詳細設計書は新人プログラマーにとっての命綱です。
玄人プログラマーからすると「もっといい書き方あるだろ」「自由に書かせてくれ」みたいなストレスの種になることもありますが…

▽実装
設計書を見ながら実際にIT資産を作っていきます。
プログラム別にプロジェクトメンバーで分担してコーディングしていきます。
難易度の低いプログラムを割り振ってもらえれば新人でも活躍の余地があるフェーズと言えます。

▽単体テスト
プログラム単位で動作確認をします。
作成したプログラムが詳細設計書どおりかを確認することがメインになるフェーズです。
私が以前いた現場では以下のように実施されていました。
・テストの計画や実施はプログラム作成者が実施
・詳細設計書どおりに書けているか、テストに漏れがないかのチェックをプログラム作成者とは別のメンバーが実施

▽結合テスト／システムテスト
メンバーがそれぞれ作ったプログラムを組み合わせ、顧客と決めた要件を満たすIT資産になっているかを確認します。
私が以前いた現場では以下のように実施されていました。
・テストの計画は要件定義／基本設計の担当者（全体像をよく理解している人間）が実施
・テストの実施はプロジェクトメンバー全員で役割分担して実施

▽受け入れテスト（UAT）
顧客が欲しかったものであるかを顧客自身に最終確認してもらいます。
納品前の最後の関門であり、ここで顧客がOKを出せば晴れて納品となります。

また、IT資産は作る＆納品して終わりではなく、その後もずーっと稼働し続けるものです。

IT資産を継続的に稼働させていくためには基本的にエンジニアのサポートが必要になりまして、このサポート業務を「運用／保守」と言います。

▽運用
「IT資産を稼働させ続ける」ために必要な業務を「運用」と言います。
定期的にメンテナンスを行ったり、異常がないか監視したり、システム停止や不具合からの復旧を行ったりします。
顧客の質問に答えるカスタマーサポート的な業務も含まれ、そのIT資産に関する深い知識が必要になります。

▽保守
「計画的なIT資産のアップデート」を目的とした業務を「保守」と言います。
IT資産は運用し続けていれば必ずアップデートが必要になります。例えば元号を使用しているIT資産は2019年5月以降、新たに「令和」の要素を追加しなければなりません。ここで発生するソースコードやデータベースの修正対応が保守業務になります。
他にも、緊急でない不具合の修正、ユーザーの「もっとこうしてほしい」に応える機能追加や修正なんかも保守業務に入ります。
これらは規模は小さいながら開発業務であるため、しっかり 要件定義→設計→実装→テスト の工程を踏んで納品されます。

これらがIT資産の開発における業務領域のすべてとなります。

この開発工程はしばしば「V字モデル」というもので説明されます。

V字になっている理由は設計⇔テストの対応をわかりやすくするためです。

詳細設計で扱うプログラム（部品）単位のチェックは単体テストで、基本設計で扱う機能単位のチェックは結合テストで、要件定義で扱う顧客の要望どおりになっているかのチェックは受け入れテストでそれぞれ行います。

▼これだけ押さえてて③：「上流工程」と「下流工程」

開発工程に広がる様々な業務は大きく「上流工程」と「下流工程」というグループに分けることができます。

▽上流工程
開発工程における前半戦「要求分析」「要件定義」「基本設計」あたりを「上流工程」と言います。
「こんなIT資産が欲しいなぁ」と思っているお客さんの相談に乗ったり、提案したり、デザインや使い心地を確認しながらお客さんの理想のIT資産を形作っていったりする仕事がメインとなります。
一言で言えば「顧客との距離が近い仕事」になります。
上流を担う人の多くはプロジェクトの責任者として開発チームを率いてスケジュールや各メンバーの作業進捗を管理をしてみたり、できあがったプログラムが顧客の要望どおりになっているかチェックしたりもします。
ITコンサルタント、SEのような肩書きの人たちがここを担当します。
以下のページを見てもらうとわかるとおり、非常に資料作成の多いフェーズです。
https://qiita.com/chocode/items/fd51dd8f561e2a0fbd70
上流工程では「開発に関する知見」「設計スキル」「マネジメント能力」「IT戦略策定」「顧客との関係性構築」などなど…様々スキルや知見が必要になるため、上流工程で鍛えられた人は「何でもそこそこデキる人」になります。
「何でもそこそこデキる人」はよく「ゼネラリスト」と表現されますので覚えておきましょう。

▽下流工程
開発工程における後半戦「詳細設計」「実装」「テスト」あたりを「下流工程」と言います。
上流工程でお客さんと擦り合わせたITサービスのイメージに従って、実際に作りこんでいくお仕事です。
一言で言えば「技術との距離が近い仕事」になります。
専門的なスキルが必要になる工程であり、プログラマー、○○エンジニアのような肩書きの人たちがここを担当します。
キャリアを進めるに従い、いわゆる「スペシャリスト」という立場になっていきます。己の腕っぷしで生きていく職人という感じですね。
基本的に保有している技術力＝市場価値＝給料 といった実力主義の世界なので、技術が好きな人間でないと不利な戦場と言えます。

上流工程と下流工程で求められるスキルやキャリアが大きく変わってくるのがお分かりいただけたでしょうか？

上流方向に進んでゼネラリストを目指すのか、下流で技術を磨いてスペシャリストを目指すのか。

エンジニアとしてのキャリアを考える際は、まずどちらの方向に進むか一旦決めてしまうのがオススメです。

なお、未経験がそれなりに価値を出せる仕事は「実装」「テスト」「運用／保守」といった主に下流工程の部分に転がっていまして、ほとんどのエンジニアはまず下流工程の業務からキャリアをスタートさせます。

ゼネラリストを目指す人は下流の業務から徐々に上流の業務に領域を広げていく、スペシャリストを目指す人は更に高いレベルの下流スキルを積んでいくというのがそれぞれのキャリアの王道となっています。

▼これだけ押さえてて④：「業務系」と「WEB系」

さて、突然なのですが今からものすごく大切なことを言います。

それは 扱う技術や働き方は「誰のためのIT資産を作るか／サポートするか」で全く異なってくる ということです。

例えば銀行のシステムは絶対に落ちてはいけないし外部からの悪意あるアクセスは確実に遮断しなければなりません。

そうなると使われる技術はお堅くセキュリティもガチガチな方向に寄っていきますし、情報が漏れぬようリアルでもPCはオフィスから持ち出し禁止&セキュリティキーによる細かな勤怠管理が必要になります。

IT業界の中でもWEBアプリケーション（インターネットなどのネットワークを介したIT資産）の開発を行う人たちはこの基準で大きく2種類に分けられていまして、企業のためのIT資産を作る人たちを「業務系」、一般消費者のためのIT資産を作り人たちを「WEB系」とそれぞれ呼びます。

IT業界における○○系は他にもいっぱいありまして、意味が重複していたり人によって解釈が違っていたりと扱いがややこしいのですが、とにもかくにもまずはこの2つを押さえておきましょう。

▽業務系
企業が業務で使用するWEBアプリケーションを作る仕事がメインです。
物流管理システム、金融系システム、販売管理システム、経理システムなどなど。
ざっくりと代表的な特徴をあげると・・・
・スーツで9時～18時勤務なサラリーマンっぽい働き方
・大規模なIT資産の開発案件が多い ／ 大きなチームになることが多い
・IT資産は長期に運用されるケースが多い
・技術やツールは古いものが採用されるケースが多い（技術の流行り廃りが遅い）
・よく採用されるプログラミング言語：Java ／ VB ／ C++ ／ C# など
・開発手法はウォーターフォール型が多い
・品質 ＞ 開発スピード であることが多い
・上流工程で作成される資料が細かく膨大
・技術や仕事が食うための手段になっている人（サラリーマンエンジニア）が多い印象
・未経験が活躍できる仕事が多い

▽WEB系
一般消費者が使用するWEBアプリケーションを作る仕事がメインです。
わかりやすいもので言うとYoutube、Amazon、クックパッド、パズドラ など。
ざっくりと代表的な特徴をあげると・・・
・服装、働く時間や場所に寛容な自由な働き方
・小規模なIT資産の開発案件が多い ／ 小さなチームになることが多い
・IT資産は短い命になるケースが多い
・技術やツールは新しいものが採用されるケースが多い（技術の流行り廃りが速い）
・よく採用されるプログラミング言語：PHP ／ Ruby ／ Python ／ Kotlin など
・開発手法はアジャイル型が多い
・品質 ＜ 開発スピード であることが多い
・上流工程で作成される資料は簡略化された最低限のものが多い
・技術や仕事が趣味や生きがいになっている人が多い印象
・未経験が活躍できる仕事が少ない

これだけ見るとWEB系の方が魅力に映る要素が多いですねｗ

ただ、未経験からWEB系への就職は「可能だが難易度はかなり高い」と思っていただければと思います。この解説はいずれ書きたいと思います。

▼これだけ押さえてて⑤：「請負」と「準委任」

開発の受注サイドでは多くの会社が協力しあってIT資産の完成を目指すのですが、この会社同士で交わされる「契約」はそこで働く社員の働き方に大きな影響を与えます。

この契約において特に押さえてほしいのが「請負」と「準委任」です。

▽請負
「IT資産を期日までに完成させること」に対して報酬が支払われる契約です。
IT業界で「受託」と言えば大体請負を指します。
プロジェクトを動かす立場なので自分の会社のオフィスで働くことが多いです。
発注サイドと受注サイドで「いつまでに、どれだけの予算で、コレコレの基準を満たすIT資産を完成させる」というゴールを決め、お互いに同意してから開発がスタートします。
アクシデントが発生して期日に間に合わなかったり、納品物が完成基準を満たさない品質だったりするとペナルティーを受けます。最悪のケースだと報酬を受け取れないばかりか訴訟に発展したりします。
プロジェクトが計画通りに進んでいればいいのですが、そうでない場合残業やプレッシャーの増えやすい契約形態と言えます。
責任が大きいため色々と大変ですが、裁量大きく働けるところは魅力の一つでしょう。
請け負った業務の一部を別の会社に請負契約で切り渡し、切り渡された会社側でも同様に業務の一部を別の会社に切り渡す・・・という請負の連鎖が業界では横行しており、こういった業界構造を「多重下請け構造」と言ってブラックな現場が生まれる元凶としてしばしば叩かれています。
これは完全に個人的な感覚なのですが、1～2次請けだと真っ当な環境であることが多く、3次請けくらいで「大丈夫かな？」となってきて4次請け以降になると漆黒に染まっていく印象があります。
求人情報などでたまに登場するドヤりキーワード「プライム案件」は要するに1次請け案件のことを指します。

▽準委任
「業務への稼働時間」に対して報酬が支払われる契約です。
専門家としてプロジェクトを手伝いにいく立場（技術派遣）であるため、自分の会社ではなく他人の会社で働くことが多いです。
発注サイドと受注サイドで「この開発業務をこれだけの期間遂行してもらう」という契約を結び、お互いに同意してから開発がスタートします。
担当した業務の成果に対する責任がないため、納期に間に合わなくても自分の成果物にバグがあると発覚したとしてもわかりやすいペナルティはありません。ただし、期待される能力に見合わないポカをしていたりすると訴訟やクビになる可能性はあります。（善管注意義務）
契約にない稼働はする必要がないため、プロジェクトが燃えても基本的に残業に付き合う必要のない立場です。
ただし、実際の現場では「プロジェクトが燃えてるから手伝ってくれよ（発注サイド）／手伝おうかな・・・（受注サイド）」「自分の仕事終わってないなら残業しろよ（発注サイド）／残業しようかな・・・（受注サイド）」のような空気が流れ、モラルのない現場では準委任という枠組みをはみ出した労働実態となることも実際問題あります。
こうしたブラックな話がインターネットやメディアで誇張され、準委任の働き方はしばしば叩かれることになります。

▼これだけ押さえてて⑥：「SIer」と「SES」

システム開発を専門とする会社は「SIer」と「SES」の大きく2種類に分けられます。

▽SIer（ エスアイアー と読みます）
IT資産を欲しいと考える企業をトータルでサポートする企業です。
IT戦略の策定、導入前の検証、IT資産の構築と納品、納品後の運用サポート・・・ありとあらゆる顧客企業のITニーズに応えます。
Wikipediaによると、IT資産構築の請負を意味するSI（システムインテグレーション）に「～する人」の意味の「er」がついてSIerらしいです。
ここで働く人たちが、かの有名な「SE（システムエンジニア）」です。
基本的に「SIer ＝ 請負」というイメージで大きくズレないと思います。（コンサル的な業務や単純な運用業務など、成果がハッキリとしない業務や発注者もプレーヤーとして関わるような業務は準委任契約で働くこともあります。）
納期までにIT資産を完成させるべくプロジェクトを率いていく立場なので上流工程をメインで担っていきます。
新人の頃は下流工程で技術やプロジェクト推進の何たるかを学び、徐々に上流工程の仕事を覚えていって「PL（プロジェクトリーダー）」「PM（プロジェクトマネージャー）」といったプロジェクトを指揮する立場になっていく人が多いです。
キャリアを進めるに従い管理職の要素が大きくなってくるため、SEは「ITを飯のタネにするサラリーマン」くらいのイメージを持っておくとズレが少ないんじゃないかなと思います。

▽SES（システム・エンジニアリング・サービスの略らしいです）
早い話が技術者（プログラマー、○○エンジニアのような肩書きの人たち）の集団です。
技術者集団なので当然下流工程がメインの戦場となります。
「SES ＝ 準委任」でして、エンジニアの手を借りたい現場に客先常駐して働くことが多くなります。
SES企業に所属している技術者のスキルレベル＝その企業の価値であるため、スキルレベルの低いSES企業は質の低い仕事しか請けることができません。
そこであてがわれる案件で働いているだけでは「技術力＝市場価値＝給料」を上げることが難しいため、質の低い案件しか請けられないSES企業は（生き残るために必死とは言え）従業員を不幸にしてしまっているケースが散見します。
また、不利な立場で請けた案件はブラック率が高まることもあり、こうした状況が過剰にクローズアップ＆尾ひれはひれが付くことで現在SES全体がひどく風評被害を受けているように思えます。
ただし、間違ってほしくないのはこれは一部の話であり、しっかりとスペシャリスト集団しているSES企業は噂と全く違う状況にある点です。
即戦力級のエンジニアが不足している昨今、スキルレベルの高いSES企業は発注サイドからパートナーとしてとても大切にされていますし、「技術力＝市場価値＝給料」を上げていく土壌も十分用意されています。
また、SES企業は未経験の採用＆教育にも積極的であり、日本のIT業界において若手エンジニアを育てる土壌にもなっています。
未経験の活躍機会の多い下流工程がメイン戦場であること、社員のスキルレベルが上がると企業の価値もダイレクトに上がることなどから未経験を採用して育てるメリットが大きいためです。
未経験からプログラマーを目指すならお世話になる可能性の高い業態だと思っておきましょう。（何の育成枠にも無条件になれる新卒キップを持っているなら話は別ですが。）

▼これだけ押さえてて⑦：「情シス」と「自社」

さて、これまでは開発の受注サイドの話をしてきましたが、少し視点をズラして発注サイドに目を向けていきましょう。

ある企業においてIT絡みの仕事を一手に請け負う人たちを「情シス（情報システム部）」と呼び、ここで社内のIT課題を解決したり社内システムを作ったりする人を「社内SE」と呼びます。

世の情シスの多くは自前でIT資産を作るだけの開発力を持ち合わせておらず、企画（どんなIT資産が欲しいかというビジョン）と予算だけ準備したら後は請負なり準委任なりで開発会社に投げてしまうのが一般的です。

しかし、中には作る部分まで自分たちでやってしまおう、プロジェクトを自分たちで回そうという会社も存在しまして、そういった会社を特別に「自社」と呼びます。（「自社開発企業」「自社系企業」と同義）

自社については語るべきことが非常に多いので別の機会で詳しく解説していきたいと思います。

▼その他、注意が必要な言葉：「ITベンダー」

業界について調べているとよく出てくるキーワード「ITベンダー」。

IT用語辞典（http://bit.ly/2Kldfvt）ではこんな感じで説明されています。

ITベンダー 【 IT vendor 】
ITベンダーとは、企業が必要とする情報技術に関連した機器やソフトウェア、システム、サービスなどを販売する企業。
情報機器やソフトウェア、コンピュータシステムなどの製品を販売したり、それらの製品を組み合わせてオーダーメイドのシステムを開発・構築したり、付随するIT関連サービスを提供する企業が含まれる。
特に、単にITベンダーといった場合は企業の情報システム開発・構築を請け負う企業のことを指すことが多く、そのような企業はシステムインテグレータ（SIer：System Integrator）とも呼ばれる。

うーん・・・

色々調べてみましたが

・本来の意味は販売会社という意味
・他社の製品やサービスを販売しているエンジニアの存在しないピュアな販売会社もITベンダー
・自分たちで製品やサービスを作っている自社系に該当する会社もITベンダー
・他社の製品やサービスを使って開発業務を行っている会社もITベンダー
・他社の製品やサービスを作る専門のSIer（ピュアな開発会社）もITベンダー

ということで、どうもIT資産の提供側にいる会社は総じてITベンダーということになりそうですね。

曖昧な意味を持つ言葉は便利っちゃ便利ですが、少なくとも何かを説明する側の人間は聞き手に混乱を与えるのであまり使用しない方がいいのではないかなと個人的に思います。