ＩＴ業界のエンジニア職の仕事をどこよりもわかりやすく解説

昨今、ちまたで「ＩＴ」という言葉を見聞きしない日はないという時代になりましたが、では「ＩＴ」とはいったい何を意味しているかご存知でしょうか。 一般的に「ＩＴ」とは「Information Technology」の略で「情報技術」と表現されます。また最近では「ICT」という言葉も多用されるようになりました。 これは「Information and Communication Technology」の略で「情報通信技術」と表現されますが、「ＩＴ」とほとんど同義と思って間違いありません。 どちらも具体的にはコンピュータや通信技術などを使って各種基幹システムや業務システムを構築したり、情報コンテンツを制作してＷＥＢ上に公開したり、情報自体を送受信する仕組みを作ったり、またそれらを様々な分野で活用したりすることを意味します。 そしてそのような仕事を扱う業界を一般的に「ＩＴ業界」と呼んでいます。 では「ＩＴ業界」には、どのような職種があって、それぞれどのような仕事をしているのでしょうか。それらは多岐に渡っており、その内容は一般的にはあまり理解されていないのが現状です。 「プログラマ」や「ＳＥ（エスイー）」という言葉はよく見聞きするものの、それがＩＴの世界でどのように関わっているかを理解している人は（関係者を除けば）あまり多くはないと思います。 ここでは、いわゆる「ＩＴ業界」における各職種と、それぞれの職種がどのような仕事をしているかを一般的なシステム開発プロジェクトを例に、できるだけ初心者の方にも理解できるよう説明いたします。

ＩＴ業界における職種と仕事内容

以下にＩＴ業界には、どのような職種が存在し、それぞれがどのような仕事を担当しているかを説明します。

ＩＴコンサルタント

「ＩＴアーキテクト」と称される場合があり、後述する「システムエンジニア」と被る部分が多々ありますが、顧客が業務における、どこの何をどうコンピュータシステム化したいのか（例えば現行は主に電話で行っている受発注業務をインターネットとタブレットを使ったシステムで行うようにしたいなど）といった要望なりをヒアリングし、それをもとにどのような技術やインフラを使うか、またどのようなシステムを構築するかを検討・調査・提案する職種です。 また併せてシステム構築など、プロジェクトとしてかかる費用のおおまかな見積もりなどを行って提案するといった仕事も担当する場合があります。 ＩＴコンサルタントには誰しもがなれるわけではありません。特に資格が必要というわけではありませんが、後述するプログラマやシステムエンジニアといった技術職、そしてマネージャーなどの管理職、の両方の豊富な経験が必要で、かつ直近の技術に精通しているなど高度な技量と責任が求められます。ゆえに待遇面では他の職種と比べて優遇されているケースが少なくありません。

プロジェクトマネージャー

「ＰＭ（ピーエム）」と、よく称されます。 プロジェクトマネージャーはプロジェクトにおける最高責任者という位置付けですが、通常は単一のプロジェクト自体の管理を行うというよりは同時進行している複数のプロジェクトを取りまとめて管理する業務を行うことに重きを置いています。 具体的には各プロジェクトの進捗管理、関連機関との調整、人的配置調整、総予算の管理、対顧客折衝といった業務を後述する「プロジェクトリーダー」と密接に連携して行います。 プロジェクトマネージャーも前述した「ＩＴコンサルタント」同様、技術面及び管理面での多くの業務経験が必要です。また実質上開発業務は行わないものの、やはり常に最新技術に関する豊富な知識が必要となりますので「単なる管理職」という意識では務まりません。

プロジェクトリーダー

「ＰＬ（ピーエル）」と、よく称されます。 プロジェクトリーダーとは当該プロジェクトを遂行するにあたっての実質上の責任者を指します。 具体的には担当するプロジェクトのスケジュール管理、進捗管理、仕様管理、人員管理、対顧客折衝などを担当します。基本的にはプロジェクトに対する管理業務が主な仕事になりますが、現実的にはプロジェクトの低予算化や短期間での完遂といった諸事情により、後述する「システムエンジニア」や「プログラマ」としての業務をも兼任せざるを得ない状況が中小ソフトウェア開発会社を中心に多々見られます。よって実質上プロジェクトのキーマンともなります。 技術面でも管理面でも重責を伴うポジションであるため肉体的にも精神的にも負荷が多くなりますが、その分プロジェクトを完遂した際には非常に高い達成感が得られます。 プロジェクトリーダーも前述した「プロジェクトマネージャー」や「ＩＴコンサルタント」同様、それまでにシステムエンジニアやプログラマとしての多くの業務経験がなければ務まりません。

システムエンジニア

「ＳＥ（エスイー）」と、よく称されます。 具体的には前述したＩＴコンサルタントやプロジェクトマネージャー、プロジェクトリーダーと共にシステムの企画を行ったり、開発業務にて具体的にシステムの仕様要件を定義したり、実際にシステムを設計・開発したり、開発後のシステム運用やシステム保守を担当するなどします。もちろん様々な局面で顧客と打合せを行うなど、対顧客折衝という職務もこなす必要があります。 システムエンジニアは、後述する「プログラマ」とは別（プログラマの仕事はしない）というイメージを持たれることが未だに多いのですが、実際はシステムの企画提案からプログラミング、テストまでの一連の開発業務を担当するケースがほとんどで、（顧客との契約にもよりますが）本番導入作業や運用開始後のメンテナンスまでの一連の業務をも行うケースが多々見られます。よって現在ではシステムエンジニアという職種は上級プログラマとしての職務も要求されると考えた方がよいでしょう。 更には上級システムエンジニアともなると前述したプロジェクトリーダーを兼任するケースも少なくありません。そういう意味ではシステムエンジニアはプロジェクトの中核的な位置にある職種と言えるでしょう。 他にもシステムエンジニアは、顧客の業務に関するアプリケーションソフトを設計開発する業務アプリケーション系システムエンジニアと、ハードウェアに関わるシステムを設計開発する組み込み系システムエンジニアという分け方をされる場合があります。いずれにしろシステムエンジニアは後述する「プログラマ」を経由してなるケースがほとんどです。

プログラマ

「ＰＧ（ピージー）」と、よく称されます。 基本的にはシステムエンジニアが設計した内容をもとに、詳細なシステム設計を行って実際のプログラムを製造し、そのプログラムが仕様どおりに動くかのテストを行います。各種プログラミング言語や最新の開発環境、ツール類などに対する高度な知識と使用経験など、高い技術力が求められます。 なお、プログラマは単純に「プログラムを作る人」、「プログラムさえきちんと作れればいい職種」というようなイメージを持たれがちな職種ですが、実際はそういうわけではありません。前述しましたとおりプログラマとしてのレベルが上がれば併せてシステムエンジニアとしての素養が要求され、ひいてはシステムエンジニアへと成長することが求められるケースが多々あります。よってプログラムを作るという技術面だけでなく管理力や折衝力などのヒューマンスキル面においても成長することが求められます。単に「プログラムが作れる」というだけでは務まりません。 また外国では「プログラマは終身プログラマ」という専門職的な意識や考えがありますが、日本においては「プログラマよりはシステムエンジニア」、「システムエンジニアよりはプロジェクトリーダー」といった職種間の上下関係の意識が依然として非常に強いため、ずっとプログラマという職種のままでいるというケースは企業に属さないフリーのプログラマを除いて、ほとんど見受けられません。

ネットワークエンジニア

例えば企業内におけるコンピュータを相互に繋ぐためのネットワークやインターネットに繋ぐための仕組みなどを設計・構築したり、そのための各種サービスや機器の選定を行ったり、構築したネットワークシステムを実際に運用したり管理したりする職種です。技術職ではありますがプログラミングというよりはプロトコル（通信に関する決め事）や 各種機器の設定、通信操作などコンピュータによる通信技術に関する豊富な知識や実践経験が必要です。 なおネットワークエンジニアは、ＩＴ業界における職種の一つではありますが、単にネットワークエンジニアとして仕事をするというケースよりも、システムエンジニアがネットワークエンジニアの仕事を兼任するというケースの方が実際には多く見られます。そういう意味では職種ではありますが、システムエンジニアの枠に内包されたものと言えます。

データベースエンジニア

基本的にコンピュータシステムにはデータベースというものが必須になります。データベースには各種情報が格納されますが、その情報量は極めて大量です。そのためほぼすべてのシステムにはデータベースを効率よく活用するためにＤＢＭＳ（Database Management System）、いわゆる「データベース管理システム」が導入されています。代表的なものとして「Oracle」や「MySQL」、「PostgreSQL」、「SQLServer」などがあります。 データベースエンジニアは、それらのデータベース管理システムを使用したデータベースの設計・構築、管理、運用を行います。また必要に応じてデータベースを最適な状態にするための各種チューニングやデータベースアクセス時間の短縮のための施策など、データベースに関するあらゆる作業を担当します。そのためデータベースに関する高度で専門的な知識や技術が必要とされます。 なおデータベースエンジニアもＩＴ業界における職種の一つではありますが、ネットワークエンジニア同様、単にデータベースエンジニアとして仕事をするというケースよりもシステムエンジニアがデータベースエンジニアの仕事を兼任するというケースの方が実際には多く見られます。ネットワークエンジニア同様データベースエンジニアも職種ではありますが、システムエンジニアの枠に内包されたものと言えます。

オペレーター

主にシステムを運用する職種になります。 システムの開発が終わって本番運用が始まると必要とされる職種となりますので、システムの開発段階では必要とされません。 またプログラマやシステムエンジニア経験者が携わるケースが多く見られますが、運用に関する各種サービスやシステムの操作方法を実際の運用業務にて習得できる能力があれば、オペレーター業務自体はシステム開発経験やプログラミング経験は特に必要とはされません。但しオペレーターといえどもシステムを扱う仕事には違いがありませんので、プログラマやシステムエンジニアの経験があるに越したことはないでしょう。

ＷＥＢディレクター

主にインターネット上のＷＥＢサイトの構築やＷＥＢコンテンツの制作といったプロジェクトの場合に存在する職種で、プロジェクトの指揮・監督を行います。細かな点で違いはあるものの、前述したプロジェクトマネージャーやプロジェクトリーダーと同様の位置付けと考えていいでしょう。

ＷＥＢデザイナー

主にインターネット上におけるＷＥＢサイトなどのデザイン（画面、構成、キャラクター作成など）を担当します。またＷＥＢを使ったシステムであれば、その画面のデザインなども担当します。 デザインを行うにあたり、HTML（「HyperText Markup Language」ハイパーテキスト マークアップ ランゲージ）やＣＳＳ（「Cascading Style Sheets」カスケーディング・スタイル・シート）に関する技術や知識が必須となりますが、最近ではJavaScriptなどのプログラム言語に関する知識も必要とされています。 またデザイン作業を行うためにIllustratorなどのイメージ編集ソフトやPhotoshopなどの画像編集ソフトの使用経験や知識も必要です。

セールスエンジニア

場合によっては「システム営業」とも称されますが、簡単に言うと「営業担当者」もしくは「セールス担当者」です。 具体的には定期的に顧客を訪れたり新規顧客を開拓するなどして、自社開発システムの提案を行ったり、自社で抱えている技術者を紹介したり、システム構築の提案を行ったりします。 単に営業をするのではなく顧客が抱える問題点や課題に対して、システムをどう取り入れて解決するかというような提案営業が主流です。そのためコンピュータシステム全般に関する知識はもちろん、場合によっては更に深い技術的な知識が求められますので、プログラマやシステムエンジニアを経験した後にスキルチェンジしてセールス部門に回るケースが一般的です。 もちろんプログラマやシステムエンジニアを経験することなくセールス担当になる場合もありますが、やはり実経験がない分、活躍の範囲は限られてしまうのが実情です。   以上、ＩＴ業界における職種とその仕事内容を説明しましたが、これらは一般的なものですので業界によっては呼称が変わったり別の職種が発生したりする場合もあります。とはいえ結局最終目標に変わりはなく、顧客からの要望に迅速に対応して最適なシステムを構築し提供するということになりますので、職種の区分けには拘らず臨機応変に対応しているのが実際のところでしょう。

一般的なプロジェクトにおける工程と各職種の関わりについて

一般的なシステム開発プロジェクトの工程には契約によって範囲は様々ですが、通常は工程順に「顧客からの依頼」、「要件定義」、「基本設計」、「詳細設計」、「製造」、「テスト」、「本番導入」、「運用」、「保守」があります。（一般的なものですので、実際は呼称が違ったり更に細かく分類されていたりする場合があるなど様々です。） では前述した各職種はそれぞれの工程でどのように関わっているのでしょうか。 以下にプロジェクトの各工程では、どのような作業を行うのか、そして前述した各職種がどの工程で関わっているのか、を工程ごとに説明します。

顧客からの依頼（プロジェクトの発足）

例えばある企業に、その基幹業務の一部をコンピュータ化したいだとか、自社製品を売る通販サイトを構築したい、といった考えが発生すると、企業の多くはコンサルタント会社やシステム開発会社に相談するなどします。この際に登場するのが、ITコンサルタントや、後々にプロジェクトマネージャーやプロジェクトリーダーを担当することになるようなレベルにあるシステムエンジニア、そして営業担当者です。（業界によってはＷＥＢディレクターが登場する場合もあります。） 彼らは依頼のあった企業（以下「顧客」と表記）に対してどのような要望なのかをざっくりとヒアリングし、その後自社に持ち帰って、どのようなシステムを構築するか、またその費用がどれくらいかかるかというような資料を作成して顧客に提案（プレゼンテーション）します。 顧客はその提案に対して変更を行ったり更に要望を加えたりしますが、ITコンサルタントやシステムエンジニア（場合によってはＷＥＢディレクター）は、その内容を把握して再度提案資料を作ると共に営業担当者と再度費用見積もりを行って顧客に再提案します。 このやりとりを何度か繰り返し、最終的に提案内容に対して合意が取れれば「受注」となり、正式にプロジェクトとして発足することになります。

要件定義

顧客からの要望を細かくヒアリングして構築するシステムの機能や性能などを明確にしていきます。例えば顧客がどのような業務をシステム化したいのか、その業務をシステム化するにあたって、どのような機能を持たせるのか、また画面はどのようなデザインにするか、帳票などの印刷物はどのようなものが必要か、またそれらによって顧客の要望がシステム的に実現できるのかなどを検討し、例えば機能単位毎や画面単位毎に要件として確定させていきます。そしてその結果を「要件定義書」としてまとめます。 また併せて具体的な開発スケジュールの検討も行います。 この工程は引き続きITコンサルタントやプロジェクトマネージャーやプロジェクトリーダークラスのシステムエンジニア、ＷＥＢディレクタークラスが担当します。

基本設計

要件定義に基づき、構築するシステムに関する基本的な設計を行います。 具体的には「要件定義」の工程にてまとめられた要件定義書をもとにして、定義された要件を満たすにはどのようなシステム構成とするかを具体的な機器構成やサービス構成を含めて検討すると共に、どのようなプログラムを実装するか、またどのような操作画面が必要で、それはどのような内容・構成とするか、併せてどのような帳票が必要で、そのフォーマットや構成をどうするか、更には扱う情報をどのような構造のデータとして保持するかなどなど、構築しようとするシステムに関するすべての基本的な仕様を設計していきます。 もちろんその都度、その設計内容を顧客とレビューし、問題があれば検討・修正を行ってクリアさせます。それを繰り返して最終的に顧客から了承を得ると「基本設計書」の完成となり、この工程が完了となります。 なお「基本設計書」は場合によっては「外部設計書」と呼称される場合がありますが、いずれにせよ、この工程で作成される設計書の総称になります。 「基本設計書」には以下のような設計書が含まれます。（一例になります。） ・業務フロー（システム全体を対象とした業務のフロー） ・システム構成図（使用するサービスや機器を含めたシステム全体の構成や概念を図示したもの） ・テーブル定義書、ＥＲ図、（データベースに関するおおまかな設計書） ・機能一覧表（どのような機能があるかを一覧にまとめたもの） ・基本設計書（機能の概要、入力/出力に関する設計、画面レイアウト、帳票レイアウトなどをまとめたもの） 並行して具体的な開発スケジュールもこの時点で確定させますので、以降の工程管理を行うために大日程表や中日程表のようなスケジュール表を作成します。またＷＢＳ（「Work Breakdown Structure」：作業分解構成図）などを利用して、より正確な工程管理を行う場合もあります。 この工程は一般的にはプロジェクトリーダークラスのシステムエンジニア（場合によってはＷＥＢディレクター）を中心とする複数のシステムエンジニア（含ネットワークエンジニアやデータベースエンジニア）が担当しますが、スケジュールや経費が関わる場合はプロジェクトマネージャーも参画しますし、技術的な検討が必要であれば上級プログラマが参画する場合もあります。他にもＷＥＢ系システムでデザイン重視のサイトを構築するのであればＷＥＢデザイナーが参画する場合もあります。

詳細設計

基本設計工程にて設計したシステムの各機能を更に詳細化する作業を行います。 具体的には基本設計にて確定した各機能に対して以下のような作業を行います。 ・各機能に対してどのようなプログラムを作るかを検討し、その詳細な処理内容（何を入力し、何を出力するかなど）を設計します。 ・基本設計にて確定した画面に対する詳細設計を行います。具体的には画面のデザイン（例えば各種ボタンを画面上のどこに配置するかなど）や画面上の操作による処理内容（ボタンをクリックした場合、どのプログラムにて何の処理がされるかなど）を詳細に設計します。 ・基本設計にて確定した帳票に対する詳細設計を行います。 ・データベースに関する詳細（データベースの構成やデータフォーマットなど）の設計を行います。 ・必要であればネットワークに関わる詳細な処理などの設計を行います。 他にも開発するシステムに関して必要と思われるものに対する詳細な設計をこの工程で行い、最終的には「詳細設計書」を完成させます。 なお「詳細設計書」は場合によっては「内部設計書」と呼称される場合がありますが、いずれにせよ、この工程で作成される設計書の総称になります。 「詳細設計書」には以下のような設計書が含まれます。（一例になります。） ・業務フロー図（システムにおける各業務処理の流れを図示したもの） ・機能一覧表（どのような機能を持つかの一覧表で基本設計から更にブラッシュアップさせたもの） ・機能設計書（機能ごとに何をするか、どんな処理を行うか、何を入力し何を出力するかなどを詳細に記載したもの） ・画面設計書（画面レイアウト図や画面上の各種ボタンやフォームなどの動きに関して詳細に記載したもの） ・画面遷移図（各画面の繋がりや遷移（どの画面からどの画面に移るかなど）に関して詳細に記載したもの） ・帳票設計書（帳票レイアウト図や印刷項目に関して詳細に記載したもの） ・テーブル定義、ＥＲ図（データベースに関する詳細な設計書） ・ネットワーク構成図（使用するネットワークサービスや機器を含めた上でのシステムのネットワーク構成を図示したもの） その他、必要に応じて必要とする詳細設計書を作成します。 作成した「詳細設計書」は顧客とレビューし、問題があれば検討・修正を行ってクリアさせます。それを繰り返して最終的に顧客から了承を得ると「詳細設計書」の完成となり、この工程が完了となります。 この工程は一般的にはプロジェクトリーダークラスのシステムエンジニアを中心とする複数のシステムエンジニア（含ネットワークエンジニアやデータベースエンジニア）が担当しますが、プログラマが参画するケースも少なくありません。またデザイン重視のサイトを構築するのであればＷＥＢデザイナーも参画します。

製造（プログラミング及び単体テスト）

まず、詳細設計にて確定した各機能に対するプログラムを各種詳細設計書に記載された内容に沿って製造していきます。また併せて画面や出力帳票など関連する処理に関するプログラムなども製造します。 プログラムを製造した後は、そのプログラムに対するプログラム単体テストを行います。 具体的には作成したプログラムが要求どおりに動くかを確認するために「プログラム単体テスト仕様書」（プロジェクトによって呼称は様々です）を作成し、それをもとに実際にプログラムを動かしてテスト（プログラム単位で要求された機能が正しく組み込まれているか、例えば入力値に対して出力された値が妥当な値か、出力すべき帳票が仕様どおりに出力されるか、エラー発生時の処理がきちんとなされているかなどを詳細なレベルで確認するテスト）を行います。 テストを行った結果、問題（バグや不具合など）が発生した場合はプラグラムの修正などを行って再度テストを行い、問題が解消されることを確認します。 最終的に問題が発生せず、要求されている機能がプログラムに正しく組み込まれていることが確認されると単体プログラムの製造完了となります。 この工程は一般的にはプログラマが担当しますが、予算面や人員面の諸事情でシステムエンジニアが引き続きこの工程を担当するケースも珍しくありません。（そういう意味ではプログラマとシステムエンジニアの境界線は曖昧なものになっているのが現状と言えますし、プログラミングにも長けているシステムエンジニアが重宝されていると言えるでしょう。） その他、この工程で詳細設計にて確定した機能仕様に対する不備や漏れが発覚したり、変更が発生したりすることが珍しくないため、その場合はシステムエンジニアが対顧客折衝などの事の対処に当たることになります。

テスト

テスト工程にはプロジェクトによって様々ですが、一般的には以下のような種類があります。 ・結合テスト ・総合テスト ・運用テスト ・その他テスト

結合テスト

機能的に関連する一連のプログラムを連続して稼働させ、要求された仕様どおりに動くか（最終アウトプットが想定した結果になるかなど）を確認するテストになります。 例えばＡのプログラムで出力された値をＢのプログラムの入力とし、その処理結果をＣのプログラムに入力した場合、Ｃのプログラムで出力される値が、これら３つの機能的に関連するプログラムを通しで動かした場合に想定される結果となっているかなどを確認します。 もちろん「結合テスト仕様書」（プロジェクトによって呼称は様々です）を先に作成し、それに沿ってテストを行っていきます。 このテストは一般的にはシステムエンジニアとプログラマが中心となって行われます。

総合テスト

総合テストは、システム全体を対象にして行うテストです。 具体的にはある機能にて出力された結果が別の機能の入力になった際、その機能の処理結果が想定された結果になるかというような、複数の機能にまたがった処理結果がシステムとしての仕様どおりになっているかを確認するテストになります。また、もちろん画面や出力帳票がある場合は、それらが連動したテストも行います。 このテストにおいても、まずは「総合テスト仕様書」（プロジェクトによって呼称は様々です）を先に作成し、それに沿ってテストを行っていきます。 このテストは一般的にはシステムエンジニアが中心となって行われます。

運用テスト

開発したシステムの実際の運用を想定したテストを行います。（「日回しテスト」と称される場合もあります。） 例えばシステムにおける各種機能を数日間に渡って稼働させ、日単位の処理結果（通常は「日次処理」と呼称されます）や週単位の処理結果（通常は「週次処理」と呼称されます）や月単位の処理結果（通常は「月次処理」と呼称されます）、年単位の処理結果（通常は「年次処理」と呼称されます）、更には半期、四半期などの特殊な期間単位の処理結果など、 それら処理結果がシステムとして想定された結果になっているかを確認するテストになります。 また運用時に発生する障害に対する障害運用の確認なども行います、 このテストにおいても、まずは「運用テスト仕様書」（プロジェクトによって呼称は様々です）を先に作成し、それに沿ってテストを行っていきます。 このテストは一般的にはシステムエンジニアが中心となって行われますが、運用に絡むため実際の運用に関わる顧客が加わって行うことも珍しくありません。

その他

他にもプロジェクトによって、（呼称は様々ですが）「本番前導入検証」（本番時の各種セットアップ操作の確認などを行う）や「性能テスト」（処理速度や画面のレスポンス速度の確認など）、「外部システム連携テスト」（他のシステムとの連携に関するテスト）など、様々なテストが行われる場合があります。 テスト工程においては総じてシステムエンジニアが中心となって行われるケースがほとんどと言っていいでしょう。

本番導入

開発したシステムを実際に顧客環境に入れ込む工程です。 具体的には顧客先に導入されているサーバーやパソコンに、開発したシステムをインストールしたりセットアップしたりする工程です。 「導入手順書」の類を作成した上で、一般的にはシステムエンジニアクラスの人員が中心となって行いますが、営業担当者クラスの人員が導入操作を行い不都合が出た場合のみシステムエンジニアクラスの人員が対応するというケースもありますので対応内容としてはプロジェクトによって様々と言えるでしょう。

運用

開発したシステムが顧客先で本番を迎えると、そのまま実運用のフェーズに入ります。 運用に関しては開発担当会社が、そのまま運用業務をも引き続き請け負うケースがあれば、まったくの別会社が担当するケースや顧客が担当するケースもあるなど様々です。 主にオペレーターがその任にあたりますが、場合によっては顧客側の社内ＳＥクラスが担当したりもします。

保守

運用開始後にシステムに何かしらの不具合が発生した場合、その不具合を修正する必要があります。また運用時に障害が発生した場合、早急にそれを復旧して正しい処理が行われるようにしなければなりません。 そのような場合、データの内容やシステムが出力する各種ジャーナル（履歴情報）などを確認して、その原因を調査したり、復旧のための具体的な対処（プログラムの不良個所の修正やデータの操作など）を行ったりします。 またシステムに仕様変更や機能追加が発生した場合、システムに対する改修作業（具体的には開発時の各種工程で行われた作業と同様の作業）を行います。 これらが一般的に「保守」と呼ばれる工程（業務）になり、開発担当会社がそのまま保守業務をも引き続き請け負うケースがあれば、まったくの別会社が担当するケースや顧客が担当するケースもあるなど様々です。 この工程（業務）は主にシステムエンジニアクラスの人員とプログラマクラスの人員が担当します。

まとめ

以上、普段よく耳にする「プログラマ」や「システムエンジニア」などのＩＴ業界の職種に関して、一般的なプロジェクトの工程に絡ませながら、どのような仕事にどのように関わっているのかを説明しました。ＩＴ業界のことをあまりご存知でない初心者の方々にもある程度理解して頂けたのではないかと思います。 しかしながら、ここで挙げた内容が必ずしもすべてのプロジェクトに適用できるわけではありません。周知のとおりＩＴの世界は日進月歩の世界です。この間まで当たり前だった技術が、気が付けば陳腐化していたということが珍しくありません。それはつまり技術だけではなく技法や工程、実際の作業にも言えることです。特定のやり方や特定の考え方のままでは取り残されてしまいます。ゆえに実際の現場では過去の慣例に囚われることなく様々な試みや取り込みが行われていて、各人が受け持つ範囲も多種多様になり固定された職種定義の範疇では収まらなくなってもいます。そのような現状ではありますが、ここで説明した内容が少しでも皆様のお役に立てば幸いです。