IT系エンジニア
2021/10/25 18:02
エンジニア系
IT 系エンジニアがどのような職種なのか、簡単に説明する資料を作ってみました。
以下で、それぞれの枠について説明したいと思います。
システム開発
システムエンジニアを大雑把にいえば、システムの組み合わせと調整を主に行います。小さな運用スクリプトやマクロ等は作ることがありますが、大規模なアプリケーション開発は行いません*1。
システム開発において「要件定義」「設計」「構築」「検証」といったフェーズで、それぞれの成果物を要求されます。
要件定義は、お客様から聞いた内容を要件として整理するフェーズです。
どんな要求があり、何を使って解決するのか、システムの大枠を整理します。
プロジェクトによっては、コンサルタントが既に済ませていることもあります。
アウトプットとして、要件定義書が求められます。
設計は、要件定義を具体的に落とし込むフェーズです。
細かい設定値はさておいて、要件に沿った方針を決める基本設計と、基本設計をもとに設定値に落とし込む詳細設計に分けることが多いです。
アウトプットとしては設計書（基本設計書/詳細設計書）になるのですが、実際に構築するための作業手順書が含められることも多いです。
構築は、設計値を元に、実際にシステムをくみ上げていくフェーズです。
作業手順書をもとに作業するため、アウトプットとして、いつ、手順書のどこを、どのように実行したかを示すエビデンスと、第三者が設定値を検証可能なエビデンスを求められます。
よく利用されるのは、ツーマンセルで一人が実行役、一人が記録役になります。記録役が、印刷された手順書に実行時刻を記載することが多い *2 です。
専用のアプリを作るまでもない、運用のためのスクリプトを作ることもあります。
最低限、フローチャートは読めないと困るでしょう。
システムで利用する機器とそれに付属する OS /専用アプリはもちろん、アプライアンス（システム用の製品）関係の知識も必要です。
非常に幅広い知識と応用力などが要求されます。
なお、システムエンジニアは基本的にプレイヤーなので、マネジメントも行うようになるとマネジメントプレイヤーもしくは何でも屋という名称で呼ばれたりします。
インフラエンジニア
システムエンジニア内でも専門性があり、次のように分かれます。サーバエンジニア
コンピュータでサービスを動かし、システムに必要なサーバを提供するのが主な仕事になります。サーバの物理的なスペックから載せる OS についての知識、サービス用のアプリケーションインストール、状況に拠ってはチューニングといった仕事を行います。
サーバには UNIX や Linux といった POSIX 準拠の OS 上で動くものや、Windows で動くものなどがあります。
Linux しか触れない、Windows しか触れないといったエンジニアもいます。
POSIX で共通仕様は決められていてもベンダーごとに特徴はあるので、HP-UX は使えても Solaris は分からないといったことはあり得ます。
ネットワークエンジニア
ネットワークケーブルを敷設し、お客様とサーバが円滑に通信できるネットワークを提供するのが主な仕事になります。実績と信頼性の高さから、商業用には主に Cisco 製品の知識が求められます。
普段は bps (bit per sec) の単位でネットワークを見ているので、Byte 単位が基本のアプリ側とやり取りするときは変換が必須です。
データベースエンジニア
システムが利用する情報を整理し、適切に応答するデータベースを提供するのが主な仕事になります。商業用には主に Oracle 製品の知識があると良いでしょう*3。
OSS としては mariaDB が採用されることも多いです。
SQL という、DB 向けの言語であってもアプリ毎の設計方針から方言の癖がつよいので、この DB しか使えないという DB エンジニアもいます。
セキュリティエンジニア
システムに含まれる脆弱性と、無数のアタッカーからシステムを守るシステムを提供するのが主な仕事になります。ネットワーク、OS、アプリそれぞれのセキュリティ情報や、防御用アプライアンスの知識などが求められます。
ソフトウェアエンジニア
ソフトウェエンジニアもシステムエンジニアに数えられますが、ここでは割愛して別項目にします。ウェブエンジニア(未掲載)
ウェブエンジニアもシステムエンジニアに数えられます。ただし、ウェブ上で利用されるシステムという、分かるような分からないような曖昧な定義になっています。
共通するのは、WebUI *4 をもつシステムに携わるというところです。
WebUI のデザインを行っているかと思えばネットワークのボトルネックを調べていたり、アプリケーション開発をしていたり、サーバのチューニングをしていたりします。
扱う範囲が広すぎるので、お客様が直接扱うソフトウェア側をフロントエンド、フロントエンドを構成するためのインフラ側をバックエンドと呼ぶようです。
上の図には未掲載です。
フロントエンドエンジニア
ブラウザで直接操作するアプリと、その UI を主に扱うエンジニアを、フロントエンドエンジニアと呼びます。お客様の前に立つ、ホテルのフロントをイメージすると理解しやすいかもしれません。
HTML / CSS / XML / JSON といった、ブラウザで直接扱うマークアップ言語や、そのコードを出力するためのアプリケーションに Java / Ruby / PHP といったスクリプト（インタプリタ型言語）が使われています。
まれに、高速な応答が必要なシステムで C 言語といったコンパイラ言語（コンパイル型言語）が使われることもあるようです。
担当する業務によっては、ネットワークを意識することがないとか、他にもウェブデザイナー業務を担当することがあると聞いています。
バックエンドエンジニア
ブラウザ操作で意識しない、裏方のシステムを主に扱うエンジニアを、バックエンドエンジニアと呼びます。インフラエンジニアと業務内容が被るのですが、インフラエンジニアはウェブ操作とは全く関係ないシステムも扱うため、微妙な差異で使い分けられています。
クラウドエンジニア(未掲載)
IaaS を中心としたサービスを主に扱うシステムエンジニアです。コーポレートエンジニア
どちらかというと発注側のエンジニアで、社内システムに特化しているのがコーポレートエンジニアです。社内エンジニアとも呼ばれます。
外注のために浅くても広い知識や、査収といった業務を行います。
このため、会社の業務知識だったり、他社への発注手続きだったりと、庶務系に比重が置かれることも多くなります。
また、次のツイートが参考になると思います。
言及のある、タスクディクショナリは、こちら。
https://icd.ipa.go.jp/icd/icd
コンサルタント
コンサルタントは、経営者やプロジェクトの責任者などが抱える課題について、アドバイスやソリューションを提供するのが主な仕事になります。コンサルタントも専門で分かれるのですが、システムエンジニアからすると上流の仕事になります。
提案書を求められることがあります。
プリセールスエンジニア
プリセールスエンジニアはインフラエンジニアのなかでも営業に近く、システムの知識を持ちつつ、知識を生かした提案や、経営課題のソリューションを提供するのが主な仕事になります。システムを見ながら、コンサルティングできるエンジニアです。
提案力（プレゼン能力）やコミュニケーションといった、政治力が強く求められます。
ワーカー
出来上がっている手順書の通りに、システムを構築したり検証したりといった作業を行います。設計がおかしければ指摘したりする必要はありますが、基本的には事前にやることが決まっています。
そのため、エンジニアとは呼ばれません。
組込エンジニア
システムとしては少し毛色が変わりますが、組み込みエンジニアもエンジニアです。サービスが動くのではなく、マイコンなどのデバイスで動くシステムを作ります。
どちらかというと、デバイスを制御するためのシステムですね。
ハードウェアの知識が必要になるため、デバイスの開発を行うこともあるようです。
コンピュータを内蔵する機械であれば組込システムが存在するため、目立ちませんが必要な役割です。
デバイス
組込エンジニアでも、身近な製品（デバイス）を開発するのがメインのエンジニアです。IC やら抵抗やら、基盤設計を行う人がいると思えば、出来上がった基盤を制御するソフトウェア開発を行う人もいます。
もちろん、全部面倒みる人もいます。
マイコン（マイクロコンピュータ）や、組込 Linux もあって、外部からはかなり混沌とした業界のように見えます。
制御ソフト
ミシンや自動車といった身近なものから、工業ロボットのような大型の機械を制御するソフトウェア開発も、組込エンジニアのようです。ステークホルダー
アプリ開発
ここでは、システムエンジニア視点でのステークホルダーとしてくくっています。デベロッパ
開発する人たちの総称です。BIND、Apache/nginx、Sendmail、Samba、Docker/CRI-Oなどサーバとして動かすアプリを開発する人たちが含まれます。
彼らがいなければ、システムエンジニアは成り立ちません。
アプリに対する深い理解が必要不可欠です。
アプライアンス
特定目的のアプリを、想定されるユースケースにおいて使いやすいシステムで提供するベンダーです。条件によっては採用するほうがコストが安く品質を上げられるため、彼らが世に出す製品は広く知っておくべきです。
あまり詳細を知れないので、雲の向こう側として表現しています。
その他
ソフトウェアエンジニアという呼称が存在する、立派なエンジニアです。こちらもシステム開発動揺、要件定義、設計、コーディング、検証といった流れが存在します。
Web アプリを開発するなら、Web エンジニアと呼ばれたりするようです。
書いている人がソフトウェアエンジニアではないので外から眺めた感じの表現になってしまいますが、概ね間違っていないと思います。
ソフトウェアエンジニア
要件定義から検証まで、一貫して行えるアプリケーション開発者がソフトウェアエンジニアだと考えています。プログラマ
要件定義の済んでいるアプリケーションを、設計から行うのがプログラマだと考えています。コーダ
コーダは設計済みのフローチャート通りにコーディングする人のことだと考えています。システムエンジニアにおけるワーカーのようなものですね。
テスタ
開発の済んだコードが、要件を満たす挙動をするかどうか試験するのがテスタだと考えています。デバッガ
ほぼほぼテスタなのですが、開発の済んだコードの検証に加えて、開発者の想定外の挙動までチェックするのがデバッガのイメージです。運用・保守
システムを作っても、それを維持したり、状況の変化に応じてメンテナンスしたりしなければ、動かないシステムになってしまいます。基本的には想定される状況がすべて網羅された手順書があり、就職先としてのハードルは低いです。
問題が起きたら即座に対応しなければならないサービスの場合、システムエンジニアが兼任することもあります。
ヘルプデスク
クライアントの設定から故障対応まで、ユーザが操作するコンピュータを責任範囲とします。理不尽が多いのも特徴です。
オペレータ
運用（オペレーション）を行います。運用とは、たとえばユーザアカウントの追加や定期的な稼働確認といった内容になります。
24時間365日、システム監視ツールが動き、問題を検出したら状況確認から対応することになります。
対応は、関係部署への連絡です。
手順書はありますが、簡単に障害箇所を切り分ける能力が、ある程度求められます。
サーバが不通であればシステムエンジニアへ連絡。
ネットワークに問題があれば、ネットワークエンジニアに連絡。
物理機器が故障しているようであれば、保守員へ連絡。
そういった連絡が主な仕事です。
ただし、切り分けの結果によってはその場で対応しなければならないことも多く、運用と保守はひとまとめにされることも多いです。
保守員
保守（メンテナンス）を行います。勤務時間は保守契約により日中対応だけのものから、24時間対応のものもあります。
保守とは機械が壊れたときに交換するといった内容になります。
基本的には連絡待ちになりますが、初期稼働を早めるためにシステム監視を行うことがあります。
内容的に運用と被るものが多いので、運用と保守はひとまとめにされやすいです。
管理
プロジェクトやプレイヤーのマネジメントを行う人たちです。PM
PM はプロジェクトマネージャーの略で、プロジェクトを管理します。管理とは、予定をたてたり、進捗状況をみてテコ入れをしたり、お客様と交渉したり、成果物を見て改善を指示したりといった内容です。
進捗管理や品質管理といった呼称が使われます。
PMO
PMO はプロジェクトマネジメントオフィスの略で、PM が担当するプロジェクトをチームとして支援します。PM は一人ですが、PMO は複数人でプロジェクトにあたります。
大規模な開発では一人で進行を管理しきれないため、必要となります。
PL
PM の立てた計画を遂行する立場です。場合によってはシステムエンジニアが兼任することもありますし、システムエンジニアに PL の能力を求める人もいますが、基本的に PL はマネジメント側になります。
発注
ビジネスオーナー
ここでは、プロジェクトを定義して、システムを発注するのがビジネスオーナーであると定義しています。システムエンジニアが直接話す機会は少なく、雲の上の存在となっています。
