「情報システム」と聞くと、エンジニアの皆さんは何を思い浮かべますか？「情シス」と呼ばれているクライアントのシステム部門を思い浮かべる人がいるかもしれません。分かっている方でも、いざ説明をしようとすると、言葉に詰まってしまうかもしれません。

「情報とは？システムとは？情報システムとは何か？」、普通に使われる言葉でありながら、正確に答えるのは意外に難しい言葉です。ここでは、情報システムに関わる職種を目指す初心者の方に向けて、**「情報システム」に関する基本をやさしく解説していきます。**

よく「データ処理」や「情報処理」という言葉を耳にしますが、データと情報との違いはなんでしょうか？データは数字や文字などで表される事実や事象を示すものであり、**情報とは、人の行動や判断につながる意味を持ったデータのことです。**

たとえば、「20歳から30歳」というのは単なるデータですが、「来店客の8割が20歳から30歳」というデータは情報になります。それは後者のデータから、「来店客の年代層を対象とする品揃えにする」という戦略を導き出すことができるからです。

簡単に言うと**システムとは「インプットをアウトプットに変換するための仕組み」のことです。**例えば、会社は「人・モノ・カネ」をインプットに、アウトプットとして「利益」を生み出す仕組みを持つ組織です。

天気予報においては、インプットは気圧や気温、湿度などであり、アウトプットは天気の予報です。つまり天気予報もシステムの1つです。

ここまで、「情報」と「システム」について解説しました。続いて情報システムの定義について見ていきましょう。

**「情報システム」とは、情報の記録や処理、伝達などを行う仕組みのことです。**情報システムの代表的な事例としては、「人事システム」「経理システム」「受発注システム」「売上管理システム」など、どこの企業や組織にもあり、稼働しています。

「IT」と「情報システム」を同一のものと見る人が少なくありませんので、その違いを説明しておきましょう。「IT」とは（Information Technology）の略で、「情報技術」のことです。情報の入手、加工や編集、保存や伝達、それら一連の処理を電子的に行う技術のことです。

それらを実現するために、コンピューターとネットワークなどのインフラに加え、ハードウェア技術、ハードウェアを思い通りに動かし、管理するためのソフトウェア技術などが「IT」には含まれています。これら「IT」を使い、ビジネスの効率化や生活向上を図る仕組みが「情報システム」です。すなわち、**「情報システム」を実現するための技術が「IT」なのです。**

情報化社会と言われて久しいですが、特にこの数年は情報システム化が著しいと感じます。私たちの**身近にある情報システム、情報処理システムなどの利用例、活用例を挙げてみましょう。**

ネットショッピング、スマホによるバーコード決済、マイナンバー、ATM、チケット予約など誰もが日常的に利用しており、ないと困るものばかりです。

「情報システム」とは、情報の記録や処理、伝達などを行う仕組みであると説明しましたが、企業の「情報システム」は大別すると2つに分けられます。二つ目は以上、**情報システムには「基幹系システム」と「情報系システム」の2種類があります。**

一つ目は「基幹系システム」と呼ばれ、**事業活動そのものに関わるシステムを指します。**たとえば、売上管理システム、受発注在庫管理システム、物流システムなどです。それぞれ日々の営業活動、事業活動に関わるデータ処理やそれらの記録が行われています。

また「基幹系システム」は顧客との接点となるサービスとも密接に関係し、「基幹系システム」が停止すると、事業ばかりか顧客に対しても大きな影響を及ぼします。

「情報系システム」と呼ばれ、すべての従業員が利用するメールシステム、スケジューラー、グループウェア、Web会議など**事務の効率化や社内外とのコミュニケーション、情報共有などを図るためのシステムです。**

円滑な業務遂行に必要なシステムが多い反面、万が一システムダウンがあっても、代替手段を講じることが可能ですので、短時間の停止であれば事業活動に深刻な影響を及ぼすことは少ないでしょう。

### 基幹系システムと情報系システムは分ける

「情報システム」には大別して「基幹系システム」と「情報系システム」の2種類がありますが、この2つは分けて開発・導入・運用をすることが求められます。サーバーやネットワーク構成は十分に考慮し、外部からの**不正アクセスや障害などの影響を最小限に抑えなければなりません。**

## 情報システムを構成する3つの要素

**「情報システム」は「アプリケーション」、「プラットホーム」、「インフラ」の3つの要素から構成されており、情報システムにはどの要素も欠かせません。**それぞれの要素について、詳しく見ていきましょう。

アプリケーションとは、**ユーザーの利用目的や業務に応じて作成されたプログラムのことです。**ユーザーはパソコンやスマートフォンやインターネットを通して、さまざまなサービスを利用していますが、実際にそのサービスを動かしているのはWebアプリケーション、モバイルアプリケーションなどです。

企業などの組織で利用しているWebアプリケーションとしては、Webブラウザ上で動作するグループウェア、メールやカレンダー、ドキュメントツール、人事勤怠、顧客管理、各種申請ツールなどがあります。

モバイルアプリケーションでは、銀行アプリ、スマホ決済、、ポイントアプリ、株取引アプリ、SNSアプリ、ヘルスケアアプリなど無数にあり、企業内での活用例も増えています。

プラットフォーム（platform）とは**「アプリケーション」を動作させるための環境のことで、WindowsやmacOS、AndroidなどのOS、ミドルウェアなどが該当します。**OSはソフトウェアとハードウェアを仲介する役割を担い、アプリケーションの正確な運用と制御において中心的な存在です。OSにはWindowsのように有償のOSもあれば、Linuxのようにオープンソースで無償のOSもあります。

ミドルウェアはアプリケーションとOSの間に位置するソフトウェアの一種で、アプリケーションが要求する機能を提供します。たとえば、データベースサーバーで利用されるMySQLやOracleDB、Webサーバーで利用されるApacheなどがあります。

MySQLとは？特徴から使い方・学習方法まで詳しく解説！

インフラストラクチャー（infrastructure）は、ITインフラとも呼ばれており、**ITを活用するための基盤となる施設やハードウェアとソフトウェアなどが含まれます。**

ハードウェアにはサーバー、ストレージ、ルーターやハブなどのネットワーク機器、通信回線、電源装置など情報システムで利用するすべてのものが含まれます。ソフトウェアとはPCやサーバーを稼働させるために必要なOSやソフトウェアなどです。

またITインフラストラクチャーには従来型インフラストラクチャーと言われる企業内に設けられた「オンプレミス」と、最近主流になっている「クラウド・インフラストラクチャー」、或いはそれらを組み合わせた「ハイブリッド・クラウド」があります。

**情報システムの開発では、大きく分けて5つの工程があります。**またそれぞれの工程では役割分担があり、担当するエンジニアが異なります。

情報システムの開発工程は、顧客の要望を明らかにする「要件定義」、要件に従って情報システムを設計する「設計工程」、設計書に従ってプログラミングを行う「プログラミング工程」、システムの正常稼働を確認する「テスト工程」、そして実際にシステムを本番移行し、運用する「リリースと運用保守工程」があります。

情報システムの作成依頼者であるユーザーから、「どのようなニーズがあり、どのようなシステムを必要としてるのか？」についてをヒアリングを行い、**開発する情報システムの機能、仕様などについて方向性を決めます。**

この工程は、上流工程とも言われ、システムエンジニアの中でも主に上級エンジニアが担当します。ヒアリングは経営者やユーザー部門と対面で行うこともあり、コミュニケーション能力や経営知識、業務知識などが求められます。

要件定義書と要求仕様書の違いを解説！誰が作りどう進める？

**要件定義によって明らかになったニーズや機能要件に従って、システムの機能や仕様を決める工程です**。システム設計にはユーザー視点に基づく概要設計として「外部設計」、システムに実装する詳細機能などを設計する「内部設計」の2つがあり、システムエンジニアが担当します。

システム設計工程で作成された**「内部設計」に関するドキュメントをもとにして、プログラミング言語を用いてプログラムの作成を行います。**

プログラミングが終了すると、プログラム単位で行う単体テストを行い、内部設計通りに動作しているか、エラーやバグ（不具合）がないかを確認し、必要に応じて修正を行います。主にプログラマーが行いますが、テスターやデバッガーと言われる専門のエンジニアが行う企業もあります。

システム開発の工程の「単体テスト」と「結合テスト」の違いを徹底解説！

単体テストが完了していることを確認したら、続いて**サブシステム単位で行う結合テスト、システム全体を通して行う「総合テスト」があります。**

さらに、要件定義の際に示されたユーザーが要求した機能や仕様通りの仕上がりになっているかを確認する「システムテスト」を行い、最後に本番稼働環境で全体の動作などを確認する「運用テスト」を行ってから情報システムはリリースされます。

要件定義を行った上級のシステムエンジニアから、内部設計までを担当したシステムエンジニアなどが関わる工程です。

運用テストってどんなテスト？目的や内容、注意すべきポイントとは？

情報システムの開発が完了し、リリースされて本番に移行した後は、「運用保守工程」に入ります。**運用保守は主にインフラエンジニアが担当し、システムの稼働確認、トラブル対応やアップデート作業などを行います。**

このフェイズではシステムエンジニアからインフラエンジニアに対して引継ぎが行われます。運用引継ぎにはさまざまなドキュメントが必要であり、コミュニケーション能力に加え、ドキュメント作成能力も求められます。

## 情報システムの代表的な開発手法

情報システムの開発手法には何種類かありますが、ここでは**代表的な開発手法として「ウォーターフォール開発モデル」と「アジャイル開発モデル」について解説します。**

滝が流れるように、**上流工程から下流工程へと順番にシステム開発を行う方式がウォーターフォール開発です。**プロジェクトの種類によって例外はありますが、基本的に先ほど紹介した大きな5つの工程で進められます。

それらの各工程を順におこなっていくウォーターフォールモデルは、当初計画した工程計画に従って、システム開発を進めるため、進捗状況の把握がしやすく、品質の担保がしやすいメリットがあります。

一方ではそれぞれの工程が完了するまては次の工程に移らないため、時間的な無駄が発生することがあり、スピードを要求されるような情報システムの開発には向いていません。

アジャイル（Agile）は「素早い」という意味ですが、その名の通り**スピード重視の開発手法です。**アジャイル開発では情報システムを小さな単位に分けて、その単位ごとに実装とテストを繰り返しながら進めます。

このアジャイル開発方式では、作りながら評価、修正を行うため、スピーディーに開発が行え、また軌道修正がしやすい点はメリットですが、全体の進捗管理がしにくい点、開発の方向性を定めにくいのがデメリットです。

DX時代に脚光を浴びる「アジャイル開発」の本命「スクラム」とは？

アジャイル開発の特徴、メリット・デメリット、DXとの関係など

## 情報システムに関わるエンジニアの仕事はやりがいがある

ここまで、エンジニアとして知っておきたい、押さえておきたい「情報システム」の基礎を中心に解説をしてきました。情報システムは企業においてはビジネスを支える役目を担い、一般の人々にとっては生活を豊かに、便利にしてくれる欠かせない道具です。

そんな**情報システムの開発に携われるエンジニア職は、期待が大きくやりがいのある職種です。**情報システムの開発と運用には、システムエンジニアやプログラマー以外にも、インフラエンジニア、データベースエンジニアなどあらゆる職種のITエンジニアが関わります。

将来、情報システムに対して、どのような立場で関わるのか、しっかり目標を見据えて、情報システムに関わっていかれることを願っています。

*【参考】：[わかりやすい業種・職種別職種図鑑｜マイナビAGENT](https://mynavi-agent.jp/helpful/jobindex/?utm_medium=content-text&utm_campaign=acv02)*

情報とは何か？システムとは何か？情報システムとは何か、当たり前の言葉でありながら、正確に答えるのがなかなか難しい言葉です。ここでは、情報システムに関わる職種を目指すエンジニア初心者の方に向けて、「情報システム」に関する基本知識についてやさしく解説していきます。

情報システムとは、情報の記録や処理、伝達などを行う仕組みのこと

情報システムは「アプリケーション」、「プラットホーム」、「インフラ」の3つの要素から構成される

情報システムの開発は、「要件定義」「設計」「プログラミング」「テスト」「リリースと運用保守」の5つの工程からなる

情報システムとは？ITエンジニアとして必要な基本知識を解説！

*[【マイナビITエージェント】あなたの転職活動を無料でサポートいたします](https://mynavi-agent.jp/it/?utm_source=and-engineer&utm_medium=banner&utm_campaign=acv01)*

**PMBOKは「Project Management Body of Knowledge」の略語で、日本語に訳すと「プロジェクトマネジメントの知識体系」です。**読み方は「ピンボック」です。米国のプロジェクトマネジメント協会（PMI）が1986年にPMBOKのガイドブックの初版を刊行してから、ほぼ4年ごとに改訂され今では「プロジェクトマネジメントの世界標準」とされています。

本来「PMBOK」は体系そのものを指しますが、PMBOKのガイドブック「PMBOK GUIDE」を指す言葉としても用いられています。

【参考】[PMI日本支部](https://www.pmi-japan.org/)

### PMBOKの大改訂が及ぼすPMP資格受験者への影響

2017年に発刊されたPMBOKの*第6版はA4判750ページの大冊でしたが、第7版は250ページと1/3のボリュームになりました。*目次の構成もガラリと変わっています。この大改訂にショックを受けたのが、プロジェクトマネジメント協会が主催するPMP試験（プロジェクトマネジメント・プロフェッショナル試験）の受験勉強をしていた人たちです。

PMP受験者は主にPMBOKガイドを使って学習します。そのため、**第6版で（または第6版の解説書で）勉強してきた人にとって第7版での内容変更は、「今までの勉強が無駄になった」と感じたでしょう。**PMI日本支部は「試験は第6版を参考にすれば問題ない」としていますが、受験者の不安は拭えません。

国際資格であるPMPは2020年時点で世界で1,118,998人、日本で39,850人の資格保有者がいます。受験者数は公表されていませんが、次の試験を目指して勉強中のプロジェクトマネジャー経験者やプロジェクトリーダー経験者は数多くいるでしょう。

「資格を取るつもりはないが、有名なPMBOKとはどんなものか勉強しよう」と解説書を読んだ人にとっても、第7版での大きな内容変更は受け入れにくいものです。

【参考】[PMP(R)PMI-ACP(R)資格保有者・資格取得者は？｜2020.9更新 | PMP,プロジェクトマネジメント,CBAP,Prince2のE-PROJECT](https://www.e-project.jp/blog/pmpgoukakusya/)

## 第6版までのPMBOKの骨組みは「10の知識エリアと5つのプロセス」

PMBOKの第6版までは、プロジェクトマネジメントの骨組みを「10の知識エリアと5つのプロセス」として解説しています。*プロジェクトの成功、つまりQCD（品質・費用・納期）の目標を達成するには、プロジェクトの5つのプロセスの各段階で10のエリアに区別されるマネジメントが必要である*としています。ここでは、「10の知識エリアと5つのプロセス」について詳しく解説します。

PMBOKは、プロジェクトの進行を次の5つプロセスの遂行として捉えます。

1.立ち上げプロセス
プロジェクトの目的・ゴール・予算・期限を定めて、プロジェクトオーナーがプロジェクトの立ち上げを認可します。

2.計画プロセス
プロジェクトマネジャーによってゴールまでのハイレベルな（=おおよその）作業計画が立てられ、プロセスが進むにしたがって計画を詳細化します。

3.実行プロセス
立案した計画に基づいてチームがタスクをこなします。

4.監視・コントロールプロセス
次工程への受け渡しで、確実な検査や検証が行なわれているかを監視します。

5.終結プロセス
QCD（品質・費用・納期）を検証・評価してプロジェクトを終結します。

プロジェクトの完成までの上記プロセスは、次に紹介する「10の知識エリア」に分けられて綿密に管理されます。

プロジェクトマネジメントの10の知識エリアとは、*マネジメント（管理）の対象を業務の種類や性質によって10エリアに分けたものです。*

1.統合管理 : 他の9つのエリアを統合する全体管理
2.スコープ管理 : 仕事の範囲と成果物がを明確にするマネジメント
3.スケジュール管理：高い生産性を保つスケジュール計画
4.コスト管理：予算内でプロジェクトを終えるための費用管理
5.品質管理：プロセス・成果物の品質を高く保つための品質管理
6.資源管理 : プロジェクトを完成するための人材や物資（ヒトとモノ）の管理
7.コミュニケーション管理：プロジェクトの情報共有管理
8.リスク管理 : プロジェクトの遂行プロセスで発生するリスクの予測・回避・対処
9.調達管理 : プロジェクトを進める上で必要なサービスやツールの調達管理
10.ステークホルダー管理 : クライアント・経営層・社内関係部署などのプロジェクトに関係するステークホルダー（利害関係者）との情報共有管理

10のエリアの2〜8までは立ち上げプロセスと終結プロセスには関係しませんが、他の3つのプロセス（計画プロセス・実行プロセス・監視プロセス）に密接に関わっています。

上記のような論理的で綿密な構成は、**「きちんと計画し見通しを立ててやるべきことを積み上げて行けば、プロジェクトは成功する」という考え方**です。第7版では、上記の楽観的で人間の理性へのシンプルな信頼に疑問符をつけています。

PMBOKの10の知識エリアと5つのプロセスについて徹底解説！

第7版では「5つのプロセス」も「10の知識エリア」も完全に姿を消し、**新たに登場したのが「価値提供システム」「12の原則」「8のパフォーマンスドメイン（行動領域）」という新しい概念です。**ここでは、第7版での変更点について説明します。

### 「成果物提供システム」から「価値提供システム」へ

第6版までは、プロジェクトの最終目的をQCD（品質・費用・納期）を達成することとしていました。「予算と期限を守ってまっとうな成果物を提供することが重要である」としていたのを、**第7版ではプロジェクトの目的を「価値の提供」としています。**第6版までと第7版では全く違う概念に変更されました。

「価値提供システム」とはどのようなものなのでしょうか。簡潔に言うと、従来の*「予定していた成果物を作る」という考えから、「やりながら考え、臨機応変に価値のある成果物を作る」という考え方に変わった*ということです。

### 「5つのプロセス」から「12の原則」へ

PMBOK第7版では「5つのプロセス」という概念が消え、「12の原則」という概念が登場しました。**「プロセス重視」から「原理・原則の重視」へ概念が変更され、より現実的な考え方になりました。**

「12の原則」とは、以下のような考え方を指します。

・スチュワードシップ : 請け負ったことを責任を持って行う
・お互いを尊重し協力し合うチーム
・ステークホルダー（利害関係者）との連携
・価値の創造に焦点を当てる
・包括的思考：システムの相互作用を認識して対応する
・リーダーシップ
・テーラリング：状況に応じた調整（仕立て直し）を図る
・品質をプロセスと結果に組み込む
・事態の複雑さに対処、適応する
・リスク（好機と脅威の不確実性）に対処する
・適応性と回復力を備える
・変化することであるべき未来を達成する

第6版の5つのプロセス（立ち上げ・計画・実行・監視・終結）と比べると、「12の原則」では「調整」「複雑さ」「適応」「回復」「変化」など、*一筋縄ではいかないプロジェクトの現実をわきまえた原理・原則になっている*と言えます。

### 「10の知識エリア」から「8のパフォーマンス・ドメイン（行動領域）」へ

第7版では「10の知識エリア」という概念がなくなり、「8のパフォーマンス・ドメイン」という概念が登場しました。

8つのパフォーマンス・ドメインとは、次のようなものです。

​・Stakeholders（利害関係者）
・Team（チーム）
・Development Approach and Life cycle（開発アプローチとライフサイクル）
・Planning（計画）
・Project work（プロジェクト作業）
・Delivery（提供・納品）
・Measurement（測定）
・Uncertainty（曖昧さ・複雑さ・変動性などの不確実性への対処）

ドメインの名前を見ただけでは内容は分りませんが、**全体のくくりが「知識エリア」から「行動領域」に変わったことからも、アプローチの姿勢の違いがわかります。**特に、*あいまいさや複雑さからくる不確実性をドメインの1つに加えた*ことが注目されます。

## なぜPMBOKは大改訂されたのか

PMBOKはなぜ大改訂されたのでしょうか。理由は、従来の開発手法の限界や弱点が明らかになり、見直しの機運が高まったことにあります。具体的には、PMBOKもウォーターフォール開発の理論的基礎付けだけではなく、**アジャイル開発の思想や手法もマネジメント理論に取り入れざるを得なくなったことが大きな理由**でしょう。以下で大改訂された理由について詳しく説明します。

### アジャイル開発の有効性が評価された

2001年に17人のソフトウェア開発者のグループによって「アジャイル開発宣言」がなされてから20年を経た現在、スタートアップ企業に限らず大手ベンダー企業でもアジャイル開発の手法が取り入れられています。「アジャイル開発宣言」には、次のような有名な言葉があります。

「プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、価値とする。」

上記にある、*対話・協調・変化への対応という価値観が第7版に反映されている*ことは明らかです。

契約と計画に縛られてとことん行き詰った挙句に「炎上する」という、ウォーターフォール開発の「硬直性」を打破するのがアジャイル開発の「柔軟性」です。この流れの中でPMBOKも、**「論理的で理性的なだけではプロジェクトは上手くいかない」という現実を、マネジメント管理に取り入れようとした**と言えます。

### 実務で活用しにくい内容だった

第6版までは論理的思考が強く現実的ではなかったため、実務で活用しにくい点がありました。実際のプロジェクトではイレギュラーな事故・突発的に発生する問題がありますが、臨機応変に対応することについてあまり触れられていません。

また、大規模開発が前提とされている・複数のプロジェクトが同時進行することを考慮されていない・具体策が記載されていないなどの点もデメリットでした。

### 人間関係が考慮されていなかった

人間関係が及ぼすプロジェクトへの影響についても、第6版まででは書かれていません。プロジェクトはチームで遂行するため、論理的思考だけではスムーズに進まないこともあります。チームワークを円滑にする・ステークホルダーと友好な関係を構築するなどは、実際の業務で重要です。第7版では人間関係の重要性についても言及されており、より実務を想定した内容に変更されています。

## IТデザイナーはPMBOK第7版とどう付き合うか

第6版までのPMBOKガイドやその解説書を読んだエンジニアには「かなり精緻な理論だが、その通りには使えない」「PMBOKには人間が出てこない」と感じた人も多いでしょう。そのため第7版は親しみやすく、リアリティがあるかもしれません。

しかし、それでもPMBOKが簡単になったとは言えません。理屈を理解するより人間を理解する方が簡単だとは言えないからです。とはいえ、**第7版ではPMBOKのプロジェクト管理理論に人間性や「人間のやること」に対する洞察が加わり、深みが増した**と言えます。アジャイル開発の手法を学びたいという人も、PMBOKは勉強する価値がありそうです。

プロジェクト達成に役立つ世界標準のPMBOKと資格取得について

有名なプロジェクトマネジメントの教科書PMBOKですが、第7版で「別の書物か？」というほど大改訂され、世界中に驚きと戸惑いが拡散しています。この記事では、PMBOKとはどんな書物で、第7版でどのように変わり、なぜ変わったかについて分かりやすく解説します。

PMBOKのマネジメントの骨組みとして有名な「10の知識エリアと5つのプロセス」が姿を消した

ウォータフォール開発を念頭に置いて解説していたPMBOKが、アジャイル開発の解説にシフトした

「人間不在」と言われていたPMBOKのマネジメント理論に、人間臭さが加わった

PMBOKとは？第7版でPMBOKの内容が劇的に変更された理由

## ITエンジニアは文系でも目指せる？

ITエンジニアは理系でないと目指すことができない、といったイメージを持つ方も多いのではないでしょうか。「エンジニア 文系」で検索すると「やめとけ」「きつい」と関連ワードが表示されることもあり、文系からITエンジニアを目指すことを不安に感じる方もいるでしょう。

しかし、**実際は文系エンジニアとして活躍している方は多くいます。**そのため、文系であってもITエンジニアへの転職を諦める必要はありません。

### ITエンジニアの仕事に大学の専攻は関係ないことが多い

ITエンジニアの仕事は大学の専攻とは関係ないことが多く、文系・理系問わず活躍できる仕事です。確かに、エンジニア職の中には機械工学や物理など高度な専門技術を要求されるものもあり、その分野を大学で学んでいないと転職が難しくなってしまう可能性もあるでしょう。

しかし、**ITエンジニアに関していえば、要求されるスキルがそこまで理系寄りというわけでもないため、文系での転職も難しくありません。**たとえば、プログラマーに求められるプログラミングスキルは、特に機械や電子、コンピュータのハードウェア面の知識がなくても習得することができます。

ITエンジニアとはどんな職種？仕事内容や必要スキルを詳しく解説！

ITエンジニアとはそもそも何なのか、あやふやになっている方もいるでしょう。ここでは、ITエンジニアの定義について詳しく解説していきます。また、ITエンジニアの年収についてもまとめました。

*ITエンジニアとは、Information Technology（情報技術）を扱う技術者の総称です。*具体的には、システム開発に携わる技術者をITエンジニアと呼ぶ場合が多く、Webアプリやスマホアプリ、業務システムなどの製品をチームで協力して開発していきます。

ITエンジニアの中でも、プログラミング言語を使いプログラムを組む人はプログラマーと呼ばれます。また、顧客からシステム開発に関する要望をヒアリングし、システムの設計書を作成する人はシステムエンジニアと呼びます。

ITエンジニアとして転職する場合、基本的にはプログラマーからスタートし、徐々にシステムエンジニアなどの上流工程の仕事へとキャリアアップしていくのが一般的です。

プログラマーやシステムエンジニア以外にも、ITエンジニアに該当する職種はいくつかあるので、それらの仕事内容について簡単にまとめました。

- サーバエンジニア：サーバの設計・構築および点検や障害時の対応を行う
- ネットワークエンジニア：ネットワークの設計・構築・運用・保守を行う
- データベースエンジニア：システムで扱うデータベースの設計・開発やセキュリティ対策を行う
- テストエンジニア：ソフトウェアが正常に動作するかのテストをメインで行い、テスト計画の作成やソフトウェアの改善提案を行う場合もある
- セールスエンジニア：IT技術に関する専門知識を持ち、顧客に対し自社製品の解説や導入後のサポートを行う

ITエンジニアの種類が多すぎてわからない？ITエンジニアの職種を紹介！

ITエンジニアの年収についてですが、ここではプログラマーの年収例を紹介します。

プログラマーの年収は「マイナビエージェント職業別年収ランキング」での平均年収は344万円、経済産業省2017年発表の「IT関連産業の給与等に関する実態調査結果」から近い職種のSE・プログラマ（ソフトウェア製品の開発・実装）を参考にすると、平均年収568万円と分かりました。

国税庁2020年発表の「民間給与実態統計調査」における民間企業平均年収は433万円なので、**プログラマーは一般平均年収よりも、やや低めであることが分かります。**

Webアプリやスマホアプリ、業務システムなどの開発需要は高く、開発に必要不可欠なITエンジニアの需要は今後さらに高まると予想されます。ITエンジニアとして年収を上げていくには、資格取得やキャリアアップを重ねることが有効です。

【参考】：[マイナビエージェント職業別年収ランキング/職種図鑑](https://mynavi-agent.jp/it/jobindex/05.html?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv07)
※【平均年収 調査対象者】2020年1月～2020年12月末までの間にマイナビエージェントサービスにご登録頂いた方

【参考】：[IT関連産業における給与水準の実態① ~ 職種別（P7）](https://warp.da.ndl.go.jp/info:ndljp/pid/11623215/www.meti.go.jp/press/2017/08/20170821001/20170821001-1.pdf)
【参考】：[民間給与実態統計調査-国税庁](https://www.nta.go.jp/publication/statistics/kokuzeicho/minkan2020/pdf/002.pdf)

ITエンジニア転職のメリット・デメリットと気を付けるべきこと

## 文系がITエンジニアにおすすめな理由

ITエンジニアは文系からでも転職することが可能です。転職できる理由は大きく分けて3つありますので、1つ目の理由から順番に解説していきます。

### 高度な計算処理はライブラリで行える

プログラミング言語には「ライブラリ」という機能があります。ライブラリとはよく使うプログラムがパッケージ化されたもののことであり、中には高度な数値計算を行ってくれるものもあります。

*ライブラリを使えば自動で計算処理を行ってくれるため、自分で計算処理のコードを記述する必要がありません。*ほとんどのプログラムではライブラリを使えば問題ないため、数学知識が要求される状況は少ないです。

Pythonのよく使うライブラリ一覧！一段上の開発を目指そう

### 言語を習得するのは文系の方が向いている

プログラミング言語を使いこなすには、言語ごとの文法を覚える必要があります。**言語を習得するのは、国語力・英語力に優れた文系の方が得意かもしれません。**文法さえ覚えてしまえば、難しい処理などはライブラリに任せることができるため、それらを組み合わせるだけでプログラムが書けることも多いです。

ITエンジニアは全体的に人手不足の傾向があり、文系・理系問わず積極採用している企業も多いです。スマホアプリやWebアプリの需要が高まっているのに対し、日本ではプログラミング教育が遅れていることもあり、人材不足が懸念されています。

*そのため、プログラミングを学びたい意思があるなら、スキルレベルが高くなくても転職できる場合も多いです。*

未経験からITエンジニアになるには？ステップと効果的な転職方法を徹底解説！

## 文系からITエンジニアを目指すためのポイント

文系がITエンジニアを目指す上でのポイントについて解説します。これらのポイントを抑えれば、転職成功率をアップすることが可能です。

### プログラミングスキルを独学で身につけておく

転職する前に、プログラミングスキルを独学で身につけておくことをおすすめします。*最近ではプログラミングを手軽に学習できるサイトも増えたため、独学をしやすくなりました。

*ITエンジニアは未経験者歓迎の求人も多いですが、ある程度はスキルを持っていた方が転職には有利です*。できる範囲で良いので、転職前に技術力を高めておきましょう。

文系でもプログラマになれる？プログラミングに数学は必要か解説！

### ITエンジニアを目指す理由を明確化させる

文系からITエンジニアを目指す場合、「なぜ文系なのにITエンジニアに転職しようと思ったか」を面接で聞かれる場合があります。**こういった想定される質問には答えられるようにあらかじめ準備しておくことが重要です。**

## 文系からITエンジニアに転職する際の注意点

最後に、文系からITエンジニアに転職する際の注意点について解説します。これらの注意点を意識することで、自分にマッチした企業に転職しやすくなるでしょう。

### 数学・物理の知識が必要な分野もある

ITエンジニアは基本的には数学・物理の知識を必要としませんが、中には必要な分野もあります。たとえば、*人工知能開発では統計学や微分積分などの数学知識も要求される場合があります。*こういった分野への転職を目指す場合は、大学レベルの数学・物理を勉強する必要があるでしょう。

文系のシステムエンジニアは後悔する？向き不向きとキャリアパスとは

### 転職先は妥協しないで決める

ITエンジニアに転職する際は、転職先は妥協せずに決めることが大切です。「文系だから転職できるだけでありがたい」と考えてしまい、給与や労働条件が良くない企業に転職してしまうのはおすすめできません。

ここまで解説した通り、ITエンジニアは文系・理系問わず活躍できる仕事です。*条件の良くない企業で妥協せず、プログラミングスキルなどに見合った企業を選択することが重要です。*

## 文系からITエンジニアを目指すなら

本記事では、文系からITエンジニアへの転職を目指す方法について解説しました。**ITエンジニアは理系・文系問わず活躍することができる職種です。**一部を除いて数学や物理の知識が要求されることもなく、「言語を覚える」というのはむしろ文系の側面も強いと言えます。

とはいえ、文系からの転職に不安を感じる方もいるでしょう。また、未経験の場合、面接で何をアピールすれば良いか分からないという方も多いのではないでしょうか。

そこで利用を推奨するのが[マイナビIT エージェント](https://mynavi-agent.jp/it/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv07)です。

マイナビITエージェント【公式】IT・Webエンジニアの求人・転職エージェント

【マイナビIT AGENT】迷ったら相談すればいいんだ

マイナビIT エージェントは、IT・Webエンジニア向け、無料の転職⽀援サービスです。

IT・Webエンジニアの転職事情に詳しいキャリアアドバイザーが、あなたのご経験やスキルをお伺いし、転職活動のプランをご提案します。

アドバイザーは企業側と直接連携を取れるので、求人票に載っていない情報も確認することができます。こちらで、働き方などをしっかり確認の上、応募企業を選んでいくのが良いでしょう。

未経験からのキャリアチェンジは心身ともに本当に大変だと思います。少しでもご自身の負担を減らすべく、エージェントサービスを活用して、失敗のない転職活動に臨んでいただければ幸いです。

<center>[『マイナビ エージェント』なら、<br/>IT業界に精通した専任アドバイザーと豊富な求人で、<br/>あなたの転職を丁寧にサポートします。](https://mynavi-agent.jp/entry/?genre=26&utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv07)</center>

文系出身でもITエンジニアに転職できるか不安という方も多いのではないでしょうか。プログラマーやSEといった仕事は文系出身でも活躍できる職種です。本記事ではITエンジニアが文系でも目指せる理由や、準備すべきこと・注意点について解説します。

ITエンジニアの仕事に大学の専攻は関係ないことが多い

ITエンジニアに転職する前に基礎的なプログラミングスキルは身につけておく

「文系なのになぜエンジニアを目指すのか」という質問に答えられるようにしておく

ITエンジニアは文系でも目指せる？転職のポイントや注意点について

## フィールドエンジニアはきつい仕事？

フィールドエンジニアのフィールド（Field）とは現場のことです。**フィールドエンジニアは現場（客先）に出向いて、自社の製品やシステムが正しく動作し、それらをクライアントが有効に活用できるように最善の状態を保つ役割を担ったエンジニアです。**

一方では、フィールドエンジニアの仕事に関して否定的な見方もあります。ネット掲示板やSNSにはフィールドエンジニアの仕事は「きつい」「やめとけ」といった否定的な意見が見られますが、ITの重要性が増す中でフィールドエンジニアの必要性が高まっています。

では、なぜ否定的な見方があるのか、その理由を探ってみましょう。この記事では、フィールドエンジニアを目指す方や、 フィールドエンジニアへの転職を検討されている方にフィールドエンジニアの仕事の実像について紹介しますので、ぜひ進路選択の参考にしてみてください。

フィールドエンジニアとは？仕事内容・将来性・年収・向いている人を解説！

## フィールドエンジニアはきついと言われる理由と対策

フィールドエンジニアはITの普及や発展、その存続に欠かせない重要な職種ですが、それにもかかわらず**フィールドエンジニアの仕事はきついという厳しい見方がある理由はどこにあるのでしょうか。**その理由を以下に述べていきます。

### 24時間365日の対応が求められることがある

フィールドエンジニアの業務の1つとして、機器の故障やトラブル対応があります。**緊急性が高いものでは24時間365日の対応が求められます。**

機器によってサポート時間が異なりますが、緊急性を要するものでは対応の遅れや、対応のミスが大きな損失を招き、クレームに発展するケースもあります。このため、フィールドエンジニアには変則的なシフト勤務が求められ、これがストレスの原因となります。

働き方改革の影響、24時間営業店舗の減少、冗長構成の機器やネットワーク自動切換えルーターなどの普及により、フィールドエンジニアの夜間出動は大きく減少していると見られます。

### 常に最新技術や知識が求められる

フィールドエンジニアは製品納入や障害対応などを円滑に行うため、**最新の製品知識やITスキルが求められます。**常に知識やスキルを最新の状態に保たなければなりません。

企業の顔でもあるフィールドエンジニアは、知識とスキルによってクライアントの期待に応える役割を担っていますので、こうしたプレッシャーがストレスになり得ます。しかし、知識やスキルのブラッシュアップはキャリアアップの大きな力となりますので、前向きに取り組むことで克服できるでしょう。

転職・キャリアの記事（47ページ目）