昨今、ITエンジニアになりたいと考える人は多く、最初のキャリアをどうスタートすべきかを悩む人も多いでしょう。そのような方々のために、ITエンジニアとしてのキャリアの始めた方について解説していきたいと思います。
■ ITエンジニアの入口
ITエンジニアとして働く市場を決めます。現状、ITエンジニアが主に働く業界を以下に示します。
①コンサルティング’
②メーカー系
産業機械
携帯電話事業者
自動車
複写機・プリンター
電気・家電
③ITサービス・ソフトウェア
④フィンテック（電子決済）
⑤サービス系
Webサービス
アプリ・ネットサービス
情報セキュリティ
⑥ゲーム
⑦AI
これらの業界は、開発するソフトウェアの対象から見ると、②の電気・機械などの装置を使う「組込ソフトウェア」、それ以外の汎用のPCを使う「業務ソフトウェア」の２つにわかれます。
前者の場合、ソフトウェアは量産ラインでハードウェアにインストールされ「商品」として販売されます。その商品ラインが存在する限り、その商品に詳細まで精通したITエンジニアを育成し、維持することになります。そのためポテンシャル重視の採用が行われます。
後者の場合、ドキュメンテーションを含む広い意味でのソフトウェアだけが「商品」として販売されます。ソフトウェアは、ユーザ毎にカスタマイズされたり、短いライフサイクルでバージョンアップを繰り返すことになります。そのため、即戦力で、実務能力重視の採用が行われます。
・各業界に入る条件
②メーカー系
新卒であれば、理系のS～Aクラスの高学歴（高専・大学・大学院）と好成績が必要となります。
中途であれば、高学歴とメーカー系での地道な経歴を兼ね備えなければなりません。
①コンサルティング
新卒であれば、文系、理系問わずSクラスの高学歴（大学院）と高成績が必要となります。
中途であれば、高学歴と他者に自慢できるような実績を兼ね備えなければなりません。
③ ITサービス・ソフトウェアに入る条件
ITエンジニアを供給源としての役割を担う業界であり、ITエンジニアだけしかいない業界です。
ＩＴベンダーによって構成される下請分業構造によって、頂点のＩＴベンダーから下流のＩＴベンダーへと裾野が広がっています。
富士通、日立、NEC、NTTデータ、日本IBM、野村総研など、名の知れた幾つかのITベンダーを頂点とし、以下、無数のＩＴベンダーが生息する下請分業構造が構成されています。
上位のITベンダーに入るには、①コンサルティング、②メーカー系と同様な条件が必要となります。
しかし、それ以外は、新卒であれば、専門学校など、高学歴でなくとも、文系・理系問わず、ITエンジニアと採用されます。
中途では、学歴は関係なく、設計・プログラミング経験の有無が問われます。
④フィンテック（電子決済）、⑤サービス系、⑥ゲーム、⑦AI
この業界は、現在、スタートアップなどのベンチャー企業が中心となっています。マッチするスキルさえ持っていればすぐに採用されるでしょう。求められるスキルのレベルが高く、学歴問わず、腕に覚えのあるITエンジニアしか参画しにくいと言えるでしょう。
上記の業界の中で、ITエンジニアのボリュームゾーンであり、参入するハードルも低い「③ ITサービス・ソフトウェア」業界が、ITエンジニアとして働くチャンスがあります。したがって、学歴がなく、経歴のない「未経験者」であれば、「③ ITサービス・ソフトウェア」業界がITエンジニアの入口となります。
以降では、 「③ ITサービス・ソフトウェア」業界 を想定し、ITエンジニアのイロハについて、解説したいと思います。
■ ITエンジニアの「イロハ」の「イ」：キーワード学習
ITエンジニアにとって、続出する略語と横文字の意味を知らないと話にもついていけません。まずは、単語＝キーワードを覚えましょう。覚えるまでもなく、インターネットで検索すれば、すぐに調べることができますが、必要最低限のキーワードは頭に入れておくべきです。そうでいないと、日常会話が成り立ちません。
代表的なキーワードは以下に列挙します。
・ハードウェア
| CPU | プログラムを実行するチップ。コンパイル・リンク後のマシン語を実行 |
| RAM/DRAM/DRAM | プログラムやデータを一時的に配置し、頻繁に読み書きするためのメモリ |
| ROM/FROM | プログラムやデータを恒久的に書き込み、読み出すためのメモリ |
| ハードディスク | メモリには保持できない大容量・複数のプログラムやデータを読み書きする記憶デバイス |
| USB | 周辺機器とのシリアル通信機能。高速（480Mbps～）であり、周辺装置への給電が可能 |
| RS232C | 周辺機器とのシリアル通信機能。低速（～115200bps）であるが、古い周辺装置でも接続可能 |
| BlueTooth | 周辺機器との近距離無線機能。中速（～24Mbps）であり、電波状況によって変化 |
・ソフトウェア
| ロジック | 論理的に矛盾のない一連の手順 |
| プログラム | ある機能を実現するために実行されるロジックの集合体 |
| プログラミング言語 | 人が容易に理解できるためのロジックの記述方法 |
| ソースファイル | プログラミング言語で書かれたテキストファイル |
| ヘッダファイル | 定数、データ構造定義、関数定義など、ソースファイルで使われる定義だけを集めたファイル |
| オブジェクトファイル | ソースファイルをコンパイルし、マシン語に変換されたファイル |
| 実行ファイル | オブジェクトファイル群をリンクさせたOS上で実行可能なファイル |
| コンパイル | ソースファイルにプログラミング言語で書かれたソースコードをマシン語に変換すること |
| リンク | オブジェクトファイルの中にある関数を呼び出しの整合性をとって結合すること |
| デバック | プログラムを動作させながら、バグの原因を探ること |
| バグ | ソースコードのロジック的な矛盾 |
| エラー | プログラムを動作させたときに、発生する想定内の異常 |
| 例外 | プログラムを動作させたときに、発生する想定外の異常 |
| プロセス指向 | 処理をプログラミングすること |
| オブジェクト指向 | オブジェクトをプログラミングすること |
| オブジェクト | データの定義と、そのデータに対する処理を一体化させた構造体 |
| OS(Operating System) | プログラムが動作できる環境を与える基本プログラム |
| システムコール | OSが提供する関数群 |
| ライブラリ | 第三者が開発した機能を提供するための関数群 |
| シングルスレッド | 複数の処理を順番に実行していくこと |
| マルチスレッド | 複数の処理を同時に実行していくこと |
・データ
| 文字型 | 文字コードで記述されるデータ |
| 文字コード | 各国言語を記号（コード）で表現したデータ |
| ASCIIコード | 英語（アルファベット）の文字コード |
| S-JIS | 日本語（50音、漢字）の文字コード |
| UTF-8 | 英語、日本語など多言語を表現した文字コード |
| 数字型 | 正負の10進数のデータ |
| バイナリ型 | 0か1の2進数のデータ |
| テキストファイル | 文字型のデータだけのファイル |
| バイナリファイル | バイナリ型のデータだけのファイル |
| CSV | 個々の文字列がカンマで区切られた一行の テキストデータ |
| TSV | 個々の文字列がTABで区切られた一行のテキストデータ |
| XML | タグでデータに名前を付与した形式の テキストデータ |
| JSON | タグでデータに名前を付与した形式の テキストデータ （XMLより形式が簡易） |
・ネットワーク
| Web | HTMLで書かれた画面やデータをインターネット・イントラネットを介して処理する仕組み |
| HTML | データの表示方法をタグで指定するテキストデータ |
| HTTP | HTMLをWebサーバから取得するための通信プロトコル |
| HTTPS | HTTPの暗号化版 |
| CGI | Webサーバ内で実行されるプログラム（PHPなどのスクリプト言語を使って作成） |
| インターネット | プロトコルにTCP/IPを使ったネットワーク |
| イントラネット | インターネットのローカル版 |
| TCP/IP | パケットを転送するIP層、その上位のコネクションを管理するTCP層の通信プロトコル |
| IPアドレス | IP層のパケットの送信元、送信先を識別するデータ |
| ポート | TCP層のコネクションを識別する整数 |
| イーサネット | TCP/IPの下位層にあたり、パケットを転送するプロトコル |
| MAC | イーサネットパケットの送信元、送信先を識別するデータ |
| SMTP | 電子メールを送信するためのプロトコル |
| POP | 電子メールを受信するためのプロトコル（メールサーバにメールを残さない） |
| IMAP | 電子メールを受信するためのプロトコル （メールサーバにメールを残さない） |
| リピータ | イーサネットパケットを中継するだけの通信機器 |
| スイッチングハブ | イーサネットパケットを宛先のMACに従って転送する通信機器 |
| ルータ | IPパケットを宛先のIPアドレスに従って転送する通信機器 |
| LANケーブル | PC、リピータ、スイッチングハブ、ルータをつなぐケーブル |
| 無線LAN | ケーブル（有線）ではなく、無線によってつなぐLAN |
| 3G/4G/5G | 第３世代/第４世代/第５世代の携帯電話プロトコル |
・データベース
| SQL | リレーショナルデータベース（RDB）を使うための言語（スキーマ定義言語、データ操作言語に分かれる） |
| RDBMS | データを表形式（テーブル）で定義し、テーブル間の関係性を定義できるデータベース。管理機能も付随 |
| NoSQL | RDB以外のデータベースのこと。全文検索型、ネットワーク型などデータベース |
・セキュリティ
| SSL | TCP/IPの暗号化通信プロトコル。HTTPSで使われる |
| RSA | 公開鍵暗号方式の暗号アルゴリズム。鍵ペア（秘密鍵・公開鍵）、公開鍵証明書、認証局（CA）を使う |
| DES | 共通鍵暗号方式の暗号アルゴリズム。秘密鍵のみを使う |
| ハッシュ値 | ある長さのデータから生成される固定長の固有値（原則、ユニーク） |
| SHA256 | ハッシュ値の生成アルゴリズム |
| トークン | カード番号などキーになるデータの一時的なハッシュ値。実データを隠蔽化する |
・ソフトウェアエンジニアリング（プロジェクトマネジメント）
| QCD | 品質、コスト、納期のこと |
| 品質 | バグの発生確率 |
| レビュー | 品質を確保する目的で行う成果物（設計ドキュメント、プログラムなど）の読み合わせ確認作業 |
| テスト | 品質を確認する目的で行う成果物の動作確認作業 |
| 人月 | 必要な人数と月数をかけたもの |
| 人月単価 | １人月（１人が１月間稼働すること）当たりの価格 |
| スケジュール | 納期までのタスクの実行計画 |
| リリース | 納期など決められた時期にプログラムを顧客に渡すこと |
| 進捗 | タスクの進み具合 |
| 工程 | タスクの作業を分割したステップ（設計、プログラミング、テストなど） |
| ウォータフォール | 決められた工程を順番通りに実施する開発手法 |
| アジャイル | 設計、プログラミング、テストの一連の作業を、仕様を決めながら、何度も繰り返す開発手法 |
| 仕様変更 | 決められた仕様を途中で変更すること |
| リポジトリ | バージョン管理ツールで一元管理されたソースコードのこと |
| チェックイン | リポジトリにソースコードを登録・更新・削除すること |
| チェックアウト | リポジトリからソースコードを取り出すこと |
■ ITエンジニアの「イロハ」の「ロ」：プログラミング
自分の軸となるプログラミング言語をつくりましょう。
ただし、目指す技術分野によって、最初に学ぶべきプログラミング言語が異なります。
以下に、各業界で主に使用されるプログラミング言語を記載します。
「③ITサービス・ソフトウェア」業界にいるITエンジニアは、経験を重ねるごとに、様々な業界で仕事をすることになりますから、否応なしに、複数プログラミング言語を使えるフルスタックエンジニア化していくことになります。
そこで、プログラミング言語に関係なく、共通したプログラミングを学ぶ手順を紹介します。
①文法を覚える
②データ型を覚える
プログラミング言語の文法は、条件、関数、データ、構造体、クラスの表記ルール、他の関数や各種定義を利用するためのインクルードの方法を把握します。
ひとまず、これだけ分かれば、プログラムを書くという行為に移ることができます。
③システムコールの使い方を知る
④ライブラリの使い方を知る
プログラミングの手足となるシステムコールやライブラリの関数の仕様を把握します。そして、想定する結果を得るために、どんな関数を組み合わせればよいか、想定できるようにします。
ただし、単に机上で関数仕様を眺めるだけではダメで、実際にテスト用のプログラムを書いて、関数を呼び出して動作を確認してみる必要があります。
なぜならば、関数を実際に動かすことで、理解の間違いを知ることができるだけでなく、「動いた」という実績をつくることができるからです。
これによって、プログラミングをする際に、後で関数を使うとき、デバックすることばく、コピペすれば動作させることができます。精神的にも、「本当に動作するのか？」という不安を抱くこともなくなります。
コンピュータである以上、文法やデータ型は共通ですが、Windows、Linux、iOS、Android、iTronなどOSによって、使えるシステムコール、ライブラリが全く変わります。そして、それらが、プログラミング言語からどのように使えるのかを知る必要があります。
プログラミング言語を覚えるということは、システムコールとライブラリの関数の使い手になることと言っても過言ではありません。
⑤エラーハンドリングの必要性を理解する
ほとんどの関数からは、エラーが返却されます。関数の結果である正常は一つだけしかありませんが、エラーにはたくさんの種類あって、関数毎に異なります。
個々のエラーの意味を把握し、適切な後処理をプログラミングしないと、エラーが発生した時にプログラムがデッドロックしたり、想定外の動作をすることになります。
たとえば、エラーで処理を終了させる、再度呼び出し（リトライ）をする、別の関数を呼び出す、他のプログラムに通知をするなど、正常系の動作だけではなく、エラーハンドリングをプログラミングする必要があります。
これらは、プログラミングする前に、設計しておく必要がありますが、プログラミングしている段階で、設計から漏れているエラーが検出されることも少なくありません。
そのような場合、いったん設計にフィードバックし、エラーハンドリングの整合性をとってからプログラミングしていきます。
⑥マルチスレッドを理解する
通常、プログラミングで書く一連の処理は、逐次処理と言って、順番に実行されることを想定しています。たとえば、処理Aの後、処理Bの後、処理Cというように、順列に実行されます。これは、シングルスレッドです。
シングルスレッドは、時系列なので、デバックしやすく、わかりやすいですが、処理時間がかかります。
マルチスレッドは、複数の処理を同時に実行させ、処理時間を削減します。たとえば、処理A、処理B、処理Cを同時に実行できれば、単純に言えば、シングルスレッドの1/3で処理時間が済みます。
現在、PCのCPUは、マルチコアが当たり前ですので、処理時間を削減するためにマルチスレッドによるプログラミングは、当たり前です。ただし、プログラミングの難易度は上がります。
シングルスレッドの処理を、マルチスレッド化するには、以下のことを考えます。
・待ちのある処理を洗い出す
・その間にできる処理を見つける
・両者を重ね合わせる
・同期をとる手段を考える
ここでもやはり、テストプログラムによって事前にプロトタイプを作り、想定通りの並列処理がされるかを検証しておく必要があります。
マルチスレッドは、プログラムのデッドロックを招く可能性がある処理方法です。連続で動作させ、入念に動作を検証し、デッドロックが発生しないことを担保する必要があります。
■ ITエンジニアの「イロハ」の「ハ」：設計
プログラミングの前に行われる設計では、「何を、どうやって、プログラミングすればいいのか」が記述された指示書をつくっていきます。その際、図表で書かれたイメージが使われます。
ある意味、「ITエンジニアとは、図を書く商売です」と言ってもいいくらい、図表を書くことは重要です。
ある程度の規模のプログラムになると、最初から左脳でロジックを考えることが難しくなります。そのため、設計を行い、右脳を使ってプログラムを「イメージ」化していきます。その後で、プログラミングによって、イメージがロジックへと書き換えられます。
プログラムをイメージ化できるようになるには、逆に、プログラミングの経験が必要です。プログラミングを経験していないと、設計の際にイメージが湧くことができません。仮に、イメージできたとしても現実性に欠け、どうプログラミングしていいかわからないイメージしか書けません。プログラミングをしたら、その動作や構造をイメージへと書きこ越してみることを繰り返すことで、設計するスキルを高めることができます。
設計で作られる主なイメージの種類には、以下のようなものがあります。
１）システム構成図
システム構造とは、必要とされるハードウェアやネットワーク、そこに配置されるプログラムを明確にしたものです。プログラムの位置づけを示す最上位の概念図です。システム・アーキテクチャのことです。
当然のことですが、プログラムを動かすにはハードウェアが必要です。どのハードウェアでプログラムが動作し、他のプログラムと連携するのかを知っておくことは、以降の設計、プログラミング、テストの作業に影響を与えます。
２）プログラム構造図
プログラム構造図とは、システム構成図で示された各プログラムの内部構成を可視化したものです。プログラム・アーキテクチャのことです。
基本、プログラムの内部は、下位の機能（モジュール）を使って、上位の機能（モジュール）を組み上げる階層構造をとります。プログラム構造図によって、プログラミングすべき機能（モジュール）の階層が明確となります。
２）シーケンス図
プログラムは、各処理のインプットとアウトプットを繋ぎ、手順を組み上げ、目的とする機能を実現します。この手順を時系列に描いた図が、シーケンス図です。
シーケンス図は、理解もしやすいため、プログラムの動作を表現するイメージとして、最も頻繁に使われるものです。そういう意味では、シーケンス図は、ITエンジニアとして最初に書き方を覚えるべき図と言えます。
３）フローチャート
フローチャートは、各処理の順番の他、ロジックの要となる条件分岐を記述できる図です。そのため、フローチャートは、ソースコードに最も近い図であり、それこそ、１ステップ毎にフローチャートに表現することもできます。
ただし、条件分岐が多くなると、各々のパスを追っていかないと処理の流れがわからないため、一見しただけでは理解し難いというデメリットもあります。
４）ＥＲ図（Entity Relationship Diagram）
通常、情報は、文字列、数字、実数まど、様々なデータ型を持つ複数のデータから構成されます。このような情報を構成する各データ型を列挙したものがデータ定義です。そして、情報と情報の間には、関係性（リレーション）を持つものもあり、データ定義とともに、リレーションとしてリンクを記述するのがＥＲ図です。
ＥＲ図によって、プログラムで扱う主な情報を洗い出し、他の情報とのリンクをつくるキーとなるデータを明確にすることで、意図しないデータの重複や不整合を防止します。
５）画面仕様
画面仕様により、表示レイアウト、表示内容、ボタンの機能、画面遷移など、ユーザが直接目にし、操作する画面を決めます。
画面は、プログラムの最初のインプットであり、最終のアウトプットでもあります。
ユーザ操作を伴うプログラムでは、画面仕様に、すべての処理の手順と条件、データが集約されるため、画面仕様が設計の重要な位置を占めます。
操作性が高い画面とは、必要な情報が必要なタイミングで提供されること、入力するデータが最小限であることを満たす画面仕様のことです。画面仕様を先に決めるのは、画面仕様によって、内部のロジックが大きく変わることがあるためです。
６）通信プロトコル仕様
ネットワークを使った通信によって、サーバへ処理をさせる場合、通信プロトコル仕様を決めます。
通信プロトコルとは、リクエストとレスポンスの電文フォーマットと手順のことを指し示します。
これら、電文フォーマットと手順も、図表を使って、設計します。
電文フォーマットは、ヘッダとデータで構成されます。ヘッダとデータの中に、設定する項目を決めます。
一対のリクエストとレスポンスで一つの機能を実現できる場合もありますが、幾つかの種類の電文を組み合わせ、一つの機能を実現する場合もあります。接続と切断のタイミングも含め、このような電文を送受信する手順をシーケンス図に記載し、規約化します。
■ ITエンジニアの出口
ITエンジニアの行き着く先としては、以下のようなポジションがあります。
・PM（プロジェクトマネージャ）
プロジェクトを統括するジェネラリスト。利害関係者とのコミュニケーション、QCD（品質・コスト・スケジュール）の管理を行う。
・ITコンサルタント
ITに関する技術的課題、マネジメント的課題の解決を行うスペシャリスト。
これらは、「上流職」と呼ばれるもので、開発工程の最初から参画し、開発ライフサイクル全体に渡って関与します。これらのポジションは、新しいプロジェクトが立ち上がらないと必要とされません。そういう意味では、ハイリスク・ハイリターンの出口と言えます。最新のITに関する知識だけでなく、社内外の人脈も重要になり、人間関係の構築にも時間をかける必要があります。
それ以外のPL（プロジェクトリーダ）、エンジニア、プログラマ、テスタは、すべて開発現場に張り付いて作業をする「ソフトウェア労働者」です。
実際、あえて出口を目指さずに、現場で学び続け、生涯現役を通すという人が大多数だと思います。日銭を稼ぐことを目標に、ローリスク・ローリターンで、コツコツと仕事を続けていけるようにスキルを磨き続けることが必要となってきます。
そう考えると、実際のところ、ITエンジニアの出口は存在せず、30代、40代でPMやITコンサルタントというポジションについたとしても、その後、50代で現場に戻り、最終的には自営業（フリーランス）になるという道が現実的ではないでしょうか。
