現代の社会や経済は、ITなしでは成り立たなくなっています。それを支える**ITエンジニアは将来性の高い専門職といえるはずですが、“きつい仕事”という評判が定着しています。

**きついといわれるITエンジニアのやりがいについて考えてみます。

## ITエンジニアはきついってホント？

ITエンジニアをめざして業界に飛びこんでも、きついと感じて辞めてしまう人がいるのは事実です。きついといわれる理由のひとつには、**長時間の残業や休日出勤の多さがあがるでしょう。**

そして、**クライアントの要望による急な仕様変更やシステムのトラブルなどの突発的なアクシデント**も多いです。これが長時間労働の原因にもなっています。これらは物理的なきつさといってよいでしょう。

一方で、精神的なプレッシャーもあります。**システムの不具合や遅延が、莫大な金銭的な損失や社会インフラの停止、場合によっては人命や安全保障上のリスクにつながる場合があります。**

ITエンジニアは、時間やさまざまな制約の中で納期や品質を厳守しなければなりません。また、ITエンジニアは、新しい技術に対応することが求められます。**ITエンジニアとして第一線で働くためには常に勉強していなければなりません。**

ここであげた部分が人によってはきついと感じられるのではないでしょうか。

SEの転職先は異業種もあり？転職先のパターンや企業選びのポイント｜求人・転職エージェントはマイナビエージェント

## ITエンジニアを続けられる理由

しかし、きついと思いながらもITエンジニアとして働き続ける人も少なくありません。続けていけるのはなぜでしょう。

ひとつには、**モノを作る楽しさや達成感などのやりがい**があるでしょう。

次に、会社やプロジェクトによりますが、**IT業界全体に出勤時間や服装などの面で大らかな傾向があり、カジュアルな雰囲気が性に合う**という人も多いようです。

そのほかには、**プロジェクトごとに環境が変わることもあり、常に新鮮な気持ちで仕事ができる**という声もあります。

きつさの原因である長時間労働はIT業界全体の問題ですが、働き方改革の影響もあり、少しずつ改善する傾向がみられます。

## “きつい”と“やりがい”のギャップは？

ITエンジニアの仕事を“きつい”と感じるのには、個人の感性や価値観も影響していると考えられます。**長時間労働のように物理的にきつい側面があるのは事実ですが、人によってきついと感じる度合いが異なる部分もあります。

**たとえば、新しい技術に対応するために勉強を続けなければならないことをきついと感じる人もいますが、それほど苦にならない、また楽しめるという人もいます。

また、**達成感によって苦労したことが相殺され、“きつい”と感じた出来事も思い出に昇華されることもあります。**

これはITエンジニアに限らず、プロジェクトやチームの雰囲気がよかったり、仕事の意義が明確で“やりがい”を感じられたりする環境でみられる傾向です。

このような環境では、**“きつい”と“やりがい”が共存し、両者のギャップがむしろ達成感につながっているのではないでしょうか。**

仕事によって心身に不調をきたすケースの多くは、長時間労働と同時に孤立感や精神的に追い込まれることが深刻な原因となっています。

そういう意味では、**ITエンジニアの職場は、きつくても、つらいばかりではない環境が比較的多いのかもしれません。**

## エンジニアがきついと感じたら

そうはいっても、どうしようもなくエンジニアとしてのお仕事がきつい職場もあるでしょう。もしあなたがエンジニアで、お仕事がきついと感じていたら転職を検討するのも一つの手です。

前述の通り、きつさややりがいは職場によっても大きく左右されます。今現在満足いく職場でないのなら、環境を変えることも検討してみてはいかがでしょうか？

そんな際に利用してもらいたいのがマイナビITエージェントです。

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

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

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

エンジニアとしてせっかく環境を変えるのであれば、後悔のない転職活動が望まれます。その際は、ぜひマイナビITエージェントをご活用いただけますと幸いです！

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

ITエンジニアはきつい!？"きつい"と"やりがい"のギャップと共存が特徴

エンジニアの方は"デグレ"というと分かると思います。**「デグレ」（ディグレーションの略語）は、プログラムの改修の際に引き起こされる性能劣化や品質劣化のこと**ですね。

ディグレーションによって、パフォーマンスが低下することもあれば、バグが発生して品質劣化することもあります。

大抵の場合は、ユーザーの変更要求仕様は満たしたものの、*後工程のプログラムなどで不具合を生じて、ディグレーションとなるケース*が多く見受けられます。

いずれにしても、改修の結果、性能劣化を招いたのなら、一旦元に戻し、その原因究明と正常化を図らなくてはなりません。

「ディグレーション」とよく似た用語に「リグレッション」があります。正確には「リグレッションテスト」ですが、この違いをよく認識しておきまょう。

そもそも*ディグレーションはディグレード（degrade）の名詞で、「悪化」とか「退化」を意味*します。プログラムの改修をした際に、予期せぬ新たな不具合が出てくることをディグレーションといいます。品質や性能が改修前よりも悪くなることです。

**プログラムの改修によってディグレーションが起きていないかどうかを検証するためのテストが「リグレッションテスト」です。**リグレッションテストには「ノンディグレードテスト」や「回帰検証」という呼び方もあります。

### ディグレーションの発生のパターン

**ディグレーションは主にプログラムの改修で起きますが、それ以外にもディグレーションは発生します。**主に以下のパターンで発生します。

*1.プログラムの改修ミス*
ユーザーからの変更要求に従って当該プログラムを修正し、**単体テストや連結テストにも問題が無かったのに、別のタスクに影響を及ぼすのが、このパターン**です。このタスク内では問題がなくとも、別タスクのプログラムがこの改修されたプログラムを呼び出し、正しい応答が無かったために呼び出した側のプログラムに悪影響を及ぼすというような事例もあります。

*2.ミドルウェアなどの設定誤り*
ディグレーションの大半はプログラムミスで起きますが、利用している**ミドルウェアのバージョンアップミスなどでも起きます。**ミドルウェアにバグがあり、その改修版が提供されているにもかかわらず、アップデートを忘れていた結果、ある日突然システムダウンが起きるというようなパターンです。システム担当者はメーカーからの通知で、ミドルウェアのバージョンアップの必要性を認識していましたが、*本番業務で特に問題が起きていなかったので、しばらく様子を見ようと考え、その内にバージョンアップを失念していた*のです。

*3.ドキュメントの記述誤り*
これは1.のプログラム改修ミスの原因でもあるのですが、**改修対象プログラムの影響対象プログラムがドキュメントに正しく記されていれば、防げたディグレーション**です。ドキュメントを作成した人のミスですが、ドキュメント作成者には「プログラマーが分かっているだろう」という*思い込み*があり、プログラマーにはドキュメントを盲信し、自ら影響範囲を確認しなかった責任があります。

前述のディグレーションが起きるパターンから、おおよそ発生原因は分かりますが、**根本的な原因**について整理しておきましょう。

システム開発やシステム改修の際には仕様書や指示書などのドキュメントがあり、プログラマーやシステムエンジニアはドキュメントに従って作業を行います。しかし、*ドキュメントが100%正しい、完全であるという保証はありません*。人が作成しているのですから、その人の性格やスキルに影響されます。漏れや不備もあるという前提で、改修時には影響範囲の調査をしなければなりませんが、これをシステムエンジニアもプログラマーも怠っていたことがディグレーションを招いたのです。こうした**「思い込み」や「怠慢」という人的ミスがディグレーションの主な原因**なのです。

人が行動をする際は、行動指針や行動ルールが必要です。「ミドルウェアの設定誤り」のパターンでは、「ミドルウェアのバージョンアップ」に対する対応指針やルールが定められていなかった事、担当者が勝手に判断したのがディグレーションの原因でした。**判断を必要とし、判断が人によって変わる可能性があるものは基準やルールを設けておかなければなりません。**そして、その基準やルールは関係者に*周知徹底*し、その*遵守を義務化*すべきです。また判断に迷うケース、ドキュメントに記述されていない事象が起きた時には*誰に判断を仰ぐのか*についても明記しておく必要があります。

人はミスを犯しやすい生き物です。しかし、他者とコミュニケーションを取り、互いに意見を交換し、力を合わせ、相互にチェックしあってミスを防ぐ*知恵*があります。仮にドキュメントに不備があっても、情報共有を徹底しておけばミスの多くは防げます。プログラム改修やミドルウェアの変更などは、**関係者全員に共有し、全員が影響確認を行えば、ディグレーションを防げた可能性は高い**です。システム開発にかかわらず、*情報共有の重要性*を再認識しておく必要があります。

*ディグレーションが恐ろしい*のは、一度正常に稼働していたシステムが停止や性能劣化を招くことです。リリース前のエラーであれば影響は大きくなりませんが、**リリース後ということで顧客に直接被害が及ぶ**ということです。

ディグレーションは軽微の影響で済む場合もありますが、**最悪の場合は企業の存亡危機に至るケース**もあります。例えば、銀行オンラインシステムが何年も正常に稼働していながら、軽微なシステム改修によってディグレーションが起き、オンライン業務が全て停止し、顧客に甚大な被害を及ぼしたという例もあります。この営業損失は計り知れません。*金銭的な実害以外に企業ブランドの失墜*という大きな影響を及ぼし、*顧客からの信用が一気に失墜します*。一度信用が失墜すると、それをとり戻すためには大変なエネルギーと時間が必要です。この事は関係者が予め十二分に認識しておく必要があります。

### 本来不要な工数、コストが余分にかかる

システム開発に対して対価がありますが、**ディグレーションによって発生する工数やコストに対する対価はありません。すべて開発側の自己責任、自己負担です。**ディグレーションが重大な場合には、システム開発に伴う利益が全て吹き飛んでしまい、タダ働きと同じ結果になることも珍しくありません。それでころか、*最悪の場合には損害賠償請求を受けるリスク*もあります。

### 多重事故を招き、負の連鎖に陥る

*ディグレーションが起きると、その対応に時間的猶予は許されません*。特にオンラインシステムや業務スケジュールに直接影響するシステムはできる限り速やかな対応が求められます。悠長に原因究明している場合ではありませんので、動けるエンジニアをかき集め、徹夜で復旧に当たります。こうした時に2次障害を招きがちです。ディグレーションの対応をした結果、また別のタスクに影響を及ぼし、別タスクで大規模障害を招くことすらあります。こうして**負のスパイラルに陥り、障害が長期化することすらあります。ディグレーションの恐ろしさは、予期せぬ時に予期せぬことが起きるというところにあります。**

## ディグレーションを起こさないために

以上、ディグレーションの原因や影響について述べてきましたが、経験したことがあるエンジニアは、*ディグレーションは思い出したくもないトラウマ*になっている方もいらっしゃると思います。

ディグレーションは野球で例えるなら、好投していたピッチャーが野手の連係ミスから突然乱調になり、あれよあれよという間に失点を重ねて、わけも分からず降板させられるようなものです。この事で、ピッチャーとしての自信を喪失し、ボールを投げられなくなる人もいます。名投手の呼び声が高かったのに、登板機会を失い、2軍に落ちて、そのまま消えていったピッチャーもいます。システムの世界でもディグレーションのせいで、このピッチャーと同じ道を辿るエンジニアもいます。**百害あって一利なしのディグレーション、何としても避けたいものです。**これから、その忌むべきディグレーションを避ける方法について述べていきます。

### 影響範囲の調査を着実に行う

ディグレーションの多くがプログラミングのミスで起きますが、そのプログラムミスを防ぐには、*プログラム改修の影響範囲を徹底的に調べておく事*です。自ら担当したプログラムを修正するのは比較的たやすいため、改修依頼を受けるとプログラマーは簡単に修正作業に着手しがちです。単体テストで修正指示書通りの結果も得られ、そこで安心しがちです。

それが他タスクに重大な影響があるとも知らず、既に自分の仕事は終わったと解放感に包まれます。

**プログラム修正作業に着手する前に、全員に改修内容について情報共有し、影響調査をしっかり行っておけば、ディグレーションを回避できた**のです。

### イレギュラー時の自己判断は厳禁

組織で動く時に、マニュアルなどに載っていない事象に直面した際は、*自己判断は厳禁*です。上司の判断を仰ぐ、上司が判断できな時は組織で共有し、*組織として意思決定すること*です。また、マニュアルやドキュメントの不備も必ず追記、修正をしましょう。「自分はマニュアルの担当者ではない」と言うようなエンジニアは失格です。便宜上、マニュアル担当者は決まっていますが、マニュアルのオーナーは関係者全員です。マニュアルは全員が担当者だという意識を持って、逐次改定していくことが求められます。また**マニュアルに記されていな事が起きた時の対応ルールはきちんと決めておきましょう。**

### リグレッションテストの範囲を広げてテストする

ディグレーションを回避するためにリグレッションテストがありますが、**リグレッションテストは可能な限り広い範囲で実施すべき**です。例えば、日次処理の改修だったため、日次処理範囲だけリグレッションテストを行い、月次処理でディグレーションが発生したという事例があります。これも影響調査の漏れが原因ですが、**リグレッションテストでは、システム全体図を見て繋がっている関連システムは一通りテスト対象とすべき**です。これをすることによって、影響調査の漏れもカバーできます。

### システム開発はリスクマネジメントも忘れずに

システムは経営向上や業務改善を目的に行われますが、ディグレーションが生じると、それらの目的がすべて吹き飛んでしまいます。その**ディグレーションによる損失を回避、最小限にするためのプロセスがリスクマネジメント**です。

リスクマネジメントと経営とは一体ですが、システムも経営の一部です。そのため**システム開発にはリスクマネジメントの視点が欠かせません。**エンジニアの皆さんは、常にこの視点を忘れず、ディグレーションとは無縁のシステム開発を心がけてください。

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

ディグレーション、通称「デグレ」はプログラムの改修に伴う品質や性能の劣化のことです。ディグレーションによってITエンジニアの評価は地に落ち、最悪の場合は損害賠償もあり得る恐ろしい現象です。是が非でも避けたいディグレーションの原因と対策について徹底解説します。

1.ディグレーションはエンジニアとしては絶対に避けなければならない致命的障害

2.ディグレーションの原因はほぼ人的な不注意やミスにある

3.ディグレーションを起こさないためにルールづくりとその遵守が大切

エンジニアにとって恐怖のディグレーションの原因と対策を徹底解説

Microsoft Azureは、**マイクロソフト社が提供するクラウド・コンピューティングサービス**です。2010年からサービスが開始され、現在AmazonのAWSに次いで18%のシェアを占めるメジャーなサービスです。「Azure」は"アジュール"と読み、英語で「青空」や「空色」を意味しています。

DX時代を勝ち抜くエンジニアを目指してAWS移行に詳しくなろう!

このMicrosoft Azureを端的に説明すると、「システム開発や運用の機能を備えた大規模なクラウドサーバー」と言えます。従来、企業はシステムの開発や管理を行うためにオンプレミスという形で自社にサーバーが必要でした。Microsoft Azureは、そうしたサーバーをインターネット上で一括管理できるクラウドサーバーとして提供しています。また**Azureはクラウドサーバーの提供だけにとどまらず、「仮想マシン、仮想ネットワーク構築機能」や「AI(人口知能）設計機能」など、エンジニア向けの機能が豊富に用意されています**。

クラウドサービスには様々な種類がありますが、**Azureが提供しているサービスは一般的に「IaaS」と「PaaS」、「SaaS」と呼ばれる類のサービスです**。以下、それぞれの特徴を説明しますので、クラウドを勉強しようという方はぜひ覚えておいてください。

*■IaaS*
IaaSとは「Infrastructure as a Service」の略語で、"イァース"と呼ばれています。**IaaSはサーバーやストレージ、ネットワーク機器、ファイヤーウォールなどのインフラをインターネット上で利用できるサービス**です。

*■PaaS*
PaaSは「Platform as a Service」の略語で"パース"と呼ばれています。**PaaSはアプリケーション・ソフトウエアが稼働するためのデータベース、プログラムの実行環境などを提供するサービス**です。

*■SaaS*
SaaSは「Software as a Service」の略語で"サース"と呼ばれています。従来はパッケージで提供されていたソフトウェア製品ですが、**SaaSはインターネットを経由してソフトウェアを利用する形のサービス**で、代表的なサービスとしてはOffice365があります。

AzureはAmazonのAWSと同様に従量課金の仕組みを採用しており、**「IaaS」と「PaaS」**によって主に次のサービスを提供し、多くの利用者のニーズに応えています。

*■Azure DevOps*
Azure DevOpsは開発（Development）と運用「Operations」を組み合わせた造語で、**開発からリリースまでのシステム開発を支援**するサービスです。

*■Azure Functions*
Azure Functionsは、**サーバーを構築することなく、プログラムが実行できるサービス**です。C#、JavaScript、Java、Pythonなどで組まれたプログラムが直ぐに実行できるので、タイミングやスピード重視のプロジェクトでは大変便利です。

JavaScriptとは？その特徴やメリット・デメリットを解説！

Pythonでできること・できないことは？活躍している分野を解説

*■Azure Storage*
Azure StorageはAzure専用ストレージサービスです。**さまざまな種類のデータ保存が可能**です。テキストやバイナリ形式の非構造化データを保存するBLOGストレージからファイルの共有サービスのファイルストレージなどがあります。

*■Azure Virtual Machines*
Azure Virtual Machinesは、**仮想マシン提供サービスです。OSはWindows系以外にLinux系などのマイクロソフト製以外のOSも対象**としています。

## Azureのメリット・デメリット

Azureには多くのメリットがありますが、**代表的なメリット3つは、いずれも直接コスト、間接コストの削減に役立つ**ものばかりです。

*1.初期費用を抑えられる*
Microsoft Azureを利用すると、**システム導入における初期費用をかなり抑制する**ことができ、必要な環境を直ちに整えることが可能です。また料金は従量制のため、導入や運用に余分な費用が発生しない点は、Azureのメリットです。Azureには*1カ月間の無料お試し版*があり、使い勝手を確かめてから導入することができるのもメリットです。

*2.マイクロソフト社のサービスとの連携が容易*
OneDriveやOffice 365などの**マイクロソフト製クラウドサービスを利用していた場合、Microsoft Azureは非常に親和性が高く、データ連携や統合がしやすい**というのもメリットです。初期費用の利点に加え、システム導入や移行の工数、コストを低減できる点もAzureのメリットとしてあげられます。

*3.システム管理がほぼ不要*
自社サーバー(オンプレミス)でのシステムでは機器メンテナンスやデータのバックアップなどを自前で行わなくてはなりませんが、Azureでは**マイクロソフト側で設定や機器メンテナンス、バックアップなどのすべてを行ってくれる**ため、システムの維持管理にかかる手間やコストを削減できます。

これはAWSとも共通するデメリットですが、クラウドサービスは便利で、コスト削減や効率化に役立つ反面、次のような**デメリットがあることを理解した上で、正しく利用**することが必要です。

*1.専門知識や技術が必要*
Azureにはシステム開発や運用をサポートするさまざまな機能が盛り込まれていますが、それらを理解しておかないと、宝の持ち腐れとなります。**Azureを有効活用するにはデータベースやサーバーに関する知識や技術が必須**です。Microsoftでは、これらに関する資格認定制度がありますので、Azureを利用予定の企業やエンジニアの方は積極的にチャレンジすることをおすすめします。

システムエンジニアがキャリアアップするのにおすすめの資格を解説！

*2.通信トラブルに注意*
これはAWSでも同じことが言えますが、**クラウドサービスは便利な反面、通信障害が起きると全く利用できなくなるというリスク**を抱えています。クラウド側のサーバーは基本的に冗長化されており、ハード障害が起きても自動的にバックアップサーバーに切り替わり、ユーザーは問題なく利用できるような仕組みになっています。一方WAN(インターネット)の利用についてはユーザー側の責任になっています。そのため、**ネットワークダウンに備えて、通信回線の冗長化を図っておくこと**が求められます。この分の投資については予算との兼ね合いもありますが、停止が許されない受発注や決済系システムなど、顧客に大きな影響を及ぼすシステムは安全なネットワークの確保が必須と考えてください。

AWSとAzureは完全なライバル関係にあります。AzureはシェアではAWSの後塵を拝していますが、Azureを提供するマイクロソフト社は企業を中心に急速にシェアを獲得し、シェアNo.1を目指しています。

企業のOfficeアプリといえば、MicroSoft365をイメージする方も多いと思いますが、他に企業でよく使われるものとして、OneDriveやSkype、Teamsなどがあり、こうしたサービスはすべてAzureクラウドから提供されています。こうした**マイクロソフトのサービスと基幹システムを連携させている場合には、Azureが最も親和性が高い**のです。

一方、AWSはクラウドインフラとしては圧倒的なシェアを誇っており、インフラを主眼としたクラウド利用に向いたサービスと言えます。AWSエンジニアを抱えた企業なら、AWSを利用した方が効率よくクラウド移行や運用が行えるでしょう。また**AWSは主にWeb業界でよく利用**されており、WebならAWSという選択が多いのです。

このように、それぞれに得意分野があり、可能であればAWSとAzureをうまく使い分けをしていくのがよいでしょう。

AzureとAWSには一長一短があり、どちらが優れているとは一概に言えませんが、**両者に差異がある部分について確認**していきましょう。

*1.  日本語ドキュメント:AWS*
**先発であり、圧倒的なシェアを誇るAWSに軍配が上がります**。AWSはユーザーが多く、AWSに関するコミュニティ活動が活発で、多くのノウハウが蓄積され、日本語で公開されています。

*2.可用性:Azure*
Azureには、「Azure Backup」:仮想マシン用バックアップサービスと、「Azure Site Recovery」:ディザスタリカバリサービスがあり、**可用性ではAzureに軍配が上がります**。

*3.運用管理の自動化:AWS*
AWSには「AWS Cloud Formation」:管理タスク自動化支援サービスがあり、APIが充実しています。このため**AWSは運用管理の自動化がしやすくなっています**。

*4.準拠法と管轄裁判所:Azure*
いずれもAWSは米国のため、何か法的問題が生じると、米国側の弁護士に頼ることになります。一方、**Azureは準拠法は日本、管轄裁判所は東京のため、法的問題への対応はAzureに安心感があります**。

*5.ディザスタリカバリ:Azure*
ディザスタリカバリ(disaster recovery)は災害復旧のことで、**Azureには「東日本」と「西日本」の2カ所にセンターがあるため、日本国内においてディザスタリカバリ構成を組むことが可能**です。

一方のAWSは日本国内に一拠点のため、ディザスタリカバリ構成を組むには片方は海外になる点が弱点と言えます。

AzureとAWSの比較において、機能面での差はほぼないと言ってよいので、どちらかを選択しても問題はありません。

先発である**AWSは「圧倒的シェア」と「長年の実績」「膨大なノウハウ」を誇っています**。

一方、**後発のAzureは、きめ細かい対応を図りながらAWSとの差別化を武器に、AWSを追い上げています**。どちらを選択するかは、難しいところですが、どちらが自社や自身のポリシーに近いかで判断するのもありでしょう。

エンジニアとしてニーズが高いAWS資格、その理想的な勉強方法

マイクロソフトには**MCP:「マイクロソフト認定プロフェッショナル  」という認定制度があり、所定の試験に合格すると、難易度ごとにFundamentals、Associate、Expertの認定を得られます**。もちろんAzureの認定資格もMCPプログラムに含まれています。

クラウドの技術は日進月歩で日々刷新されており、それに従って認定資格も変更されています。**Azureの認定資格は基礎からスタートし、開発者、管理者、ITアーキテクト、DevOpsエンジニアに分かれます**。他にはデータサイエンティストやAIエンジニアといった最先端技術の認定資格もあります。クラウドエンジニアを目指す方は、Azureも是非学んでください。Azureを学ぶ中で、クラウドエンジニアとしての必要な知識が身についていくでしょう。

参考:[Azureの認定資格](https://docs.microsoft.com/ja-jp/learn/certifications/browse/?resource_type=certification&term=Azure&terms=Azure)

クラウドエンジニアとは？従来型エンジニアとの違いや市場性・年収について解説します！

マイクロサービスアーキテクチャとは？詳細と課題について徹底解説！

### スタートは：AZ-900(Azure Fundamentals)から

**AZ-900はAzureの入門者向け試験です。合格するとFundamentalsの認定を受けられます**。対象はAzureの営業やAzureユーザーなど、概要を知っておけばよい人、もしくはAzureに関わる開発者や技術者の初歩的知識を確認する試験として考えてください。なお、他のAzure認定資格を受験する場合に、AZ-900の認定は前提条件とはなりません。

**Azure認定資格の学習にあたっては、マイクロソフト社は「オンライントレーニング」と「オフライントレーニング」の2つのトレーニングコースを設けています**。オンライントレーニングは英語でのコンテンツもあり、ハードルが上がってしまいますが、英語に自信がない方向けには、マイクロソフトのパートナー企業主催のトレーニングも提供されていますので、こちらを選択すると良いでしょう。

また、Azureが提供するさまざまなサービスの関係から、**仮想マシン、データベース、ネットワーク、セキュリティ、障害対策などの広範な知識も必要です。Azure認定資格と併せて国家資格や、AWS認定資格にもチャレンジすることで、スキルアップを図れますので、機会をとらえてぜひチャレンジしてみてください**。

マイクロソフト社のAzureはAWSと並ぶ代表的なクラウドサービスで、DX時代のクラウドエンジニアには必須です。Azureの特徴やメリット・デメリット、AWSとの比較、Azure認定試験などをわかりやすく解説していきます。エンジニアの方はぜひ認定資格に挑戦してみましょう。

1.Azureに関する概要、利用目的、メリット・デメリットを知る

2.AWSとの比較で、Azureの強み、弱み、選択のポイントを知る

3.DX時代のクラウドエンジニアとして活躍するためAzureの勉強法について知る

クラウドエンジニアを目指す方必見！Azureを分かりやすく紹介！

ソフトウェアの開発は、その種類や用途、プロジェクトの規模などによってそれぞれ最適な手法が異なります。ウォーターフォール開発、プロトタイプ開発、スパイラル開発、アジャイル開発などといった手法がよく聞かれますが、プロジェクトに沿った最適な手法を用いた開発がなされない場合、工数や開発費に大きな影響を及ぼしてしまうこともあります。

**ここでは、ソフトウェア開発における代表的な手法の一つである「アジャイル開発」について、そのメリットやデメリット、開発時の注意点などを紹介します。**

[【関連記事】「IT・エンジニアの職種図鑑」](https://mynavi-agent.jp/it/jobindex/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv08)

[【求人特集】「システムエンジニアの転職」](https://mynavi-agent.jp/it/systemengineer/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv08)

**アジャイル開発とは、2000年以降に登場したソフトウェア開発手法の一つです。小さなサイクルを回しながら開発を行うアジャイル開発は、従来型のウォーターフォール開発と比較して開発期間を大幅に短縮できる可能性を持ちます。**

### アジャイルソフトウェア開発宣言

アジャイルソフトウェア開発宣言とは、アジャイル開発手法を支持する著名人らによって2001年に公開された、**アジャイル開発の理念とも言うべき内容を示した宣言です。**[その全文](http://agilemanifesto.org/iso/ja/manifesto.html?_fsi=x2Y9Smax)を引用します。

```
「アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

©2001, 上記の著者たち
この宣言は、この注意書きも含めた形で全文を含めることを条件に
自由にコピーしてよい。」```

**アジャイル（Agile）は「すばやい」「俊敏な」といった意味を持つ言葉です。顧客満足度の高いソフトウェアを早く継続的に提供することが、アジャイル開発の一番の目的となります。**

ここに名を連ねた17人は、従来型のソフトウェア開発とは異なる手法でのソフトウェア開発を当時実践していた開発者たち。彼らがソフトウェア開発を行ううえで重視するマインドセットが、このアジャイルソフトウェア開発宣言です。

### ウォーターフォール開発との違い

**アジャイル開発では、反復（イテレーション）とよばれる短い開発期間を繰り返します。小さく限られた機能のソフトウェアから開発を始め、定期的にゴールを設定しながら必要な機能をつぎ足し、改良していく開発手法です。**反復の期間ごとにソフトウェアを改良していく開発手法であるため、継続して提供、改善をしていくようなサービスに向いています。反面、最終的なゴールを決めて大規模開発をする場合には向いていないと言われています。

一方、**ウォーターフォール開発は従来型とも呼ばれるソフトウェア開発手法です。水が流れるように上流工程から下流工程へ進んでいくため、この名がつけられています。**定められた機能を決まった納期で実現するのに向いているといわれる開発手法です。ただし、一度落ちた水は上に向かっては進まないのと同じで、後から出た仕様変更などには強くありません。

## アジャイル開発の特徴と3つの開発手法

アジャイル開発は迅速かつ適応性の高いソフトウェア開発手法の総称で、数多くの開発手法が生み出されてきました。その中でも代表的なもの3つについて記載します。

アジャイル開発では最も有名な手法です。**集められたメンバーが協力し、チームとなって推進します。計画立案から進行管理、動作確認などをメンバー主導で行うため、チーム内のコミュニケーションがもっとも重視されます。**コミュニケーションの不全が生じると、機能の不具合や納期遅延につながるリスクがあります。

**スクラムではスプリントという短い期間を区切り、スプリントごとに開発を完成させながら、その繰り返しでプロジェクトを推進します。**プロダクトバックログというプロジェクトで実現すべき価値とその優先順位の一覧を持ち、スプリントごとにどこまでを実現するかを定めて開発を行います。スプリントでは、スプリントバックログというタスクリストを定め開発範囲を規定します。

### エクストリーム・プログラミング（略：XP）

**計画の順守より変更に対応する柔軟性を重視する開発手法です。技術面を重視するため、プログラマー主導の開発手法とも言われます。**「コミュニケーション」「シンプル」「フィードバック」「勇気」の4つの価値を共有することが推奨され、特に仕様や設計の変更に立ち向かう「勇気」が重視されます。

また、**継続的なプロダクトの成長に主眼を置いた開発手法とも言われており、イテレーション（反復）と呼ばれる設計、実装、テストの開発工程を繰り返しながら開発を行います。**開発においては、テスト駆動開発、ペアプログラミング、リファクタリング、YAGNI（必要なソースコードのみを記述する）といった手法を取り入れています。

### ユーザー機能駆動開発（略：FDD）

**適切な間隔でソフトウェア（機能）の提供を繰り返す開発手法です。顧客にとっての機能価値（feature）という観点で開発が進められます。**そのため、最初にビジネスモデリングを実施し、ユーザーのビジネスの「見える化」を行います。モデルに対してマイルストーンを設定し、短期の開発を反復しながら、適切な間隔でユーザーに機能を提供していくことが特徴です。

ソフトウェア開発における重要課題の一つである納期短縮を実現できる点がアジャイル開発の魅力です。その詳細を記載します。

**対面のコミュニケーションによる意思疎通と実際に動くソフトウェアを進行管理の尺度とすることで、作成される文書の量が減らせます。**従来型の開発手法で大きな時間とコストをかけていたドキュメントを減らすことで、短納期、低コストにつなげます。

**(※アジャイル開発においてドキュメントの作成を否定するものではありません。必要なドキュメントは作成し、不必要となるドキュメントの削減を行います。)**

### 従来の開発手法と比較して、納期を短縮できる

**詳細な仕様の策定や進行計画などの上流工程、文書作成の工数が削減されます。**複数の反復を行っても、結果として従来型の開発手法より納期を短縮できる場合があります。

**開発対象を最小化しているため、不具合が発生した際の手戻りが少なくなります。**影響範囲が少ないうちに不具合に対処できるため、以降の開発における同様の機能作成の際に不具合対応の経験を活かすことが出来ます。

### 顧客のニーズを取り入れやすい

仕様変更や機能追加に柔軟に対応でき、開発途中でも顧客のニーズを取り入れやすくなります。ソフトウェア開発では実際にソフトウェアを使ってみてから要望や意見が出ることも多く、その声をソフトウェアに取り込めることが顧客満足につながります。

## アジャイル開発のデメリット

アジャイル開発についてはメリットだけではなく、デメリットも存在しています。それらを確認し、適用時の検討事項としましょう。

### プロジェクトの方向性がブレやすい

詳細な仕様を決めずに着手するため、顧客ニーズに応えて改善を繰り返し、仕様の追加・変更が重なって、**プロジェクトが当初の開発計画から大幅に変わってしまうことが考えられます。**終わらない改善のループが発生し、コストの超過が発生することもあります。

**チーム単位で「開発～リリース」の工程を反復するため、全体像としてのスケジュールや進捗状況が把握できなくなり、全体的な納期に間に合わなくなるケースがあります。**初期に厳密な進行スケジュールを設定しないことが進行管理の難しさにつながり発生するトラブルです。

## 何でもOKではない？アジャイル開発

**アジャイル開発の魅力は納期を短縮できることと、仕様の変更や機能追加がしやすい点にあります。**そのため、トレンドへの迅速な対応が求められるWebサービスやスマートフォンアプリの開発には適しています。変化に強い開発手法と言ってもよいでしょう。

**逆にアジャイル開発が向かないプロジェクトとしては、基幹系システムなどがあげられます。**段階的な機能追加で変化に対応するより、定められた仕様と納期を厳守してリリースすることが求められるからです。

**開発する対象や顧客のニーズに合わせて、最適な開発手法を選択する検討する必要があります。**そのため、プロジェクトの特質にあわせて、アジャイルとウォーターフォールモデルの手法を併用する企業もあるのです。

## アジャイル開発が適しているプロジェクト

**アジャイル開発は、リーンスタートアップとの相性が良い開発方法です。**リーンスタートアップとは、コストをかけず最低限のサービスでスモールスタートし、顧客の要望、反応をサービスに反映していくマネジメント手法。小さい単位で開発を行い繰り返しで改善していくアジャイルの手法と非常にマッチしています。

## アジャイル開発をする際の注意点

最後に、アジャイル開発をする際の注意点をご紹介します。

### プロジェクトの目的を明確化にする

**アジャイル開発の特徴として、全体的なゴールが定まっていないままでもプロジェクトを推進することができる点が挙げられます。**これはメリットともなりますが、企業の業務としてはデメリットとなり得ることもあります。明確なゴールや目標を立てていなければ、コストを垂れ流しながらどちらに進んでいるともわからないプロジェクトを推進し続けることになる可能性があるからです。そこに利益が生まれるかどうかはわかりません。

また、アジャイルはチームで取り組む開発手法です。メンバー間の積極的な意思疎通があって初めてスムーズに開発が進行します。半面、プロジェクトの目的が明確になっていなければ、メンバー間での意識の共有はできません。

### チームとしてプロジェクトを推進する

アジャイルでは、チームとして最終的なアウトプットを実現します。**お互いが持つスキルを有効に活用し、チームとしてプロジェクトに取り組む必要があります。**足りない部分を補い合いながら柔軟に課題に対応していく体制が必要なのです。

また、**アジャイルでの開発をアウトソースする場合は、発注元の担当者もそのチームの一員としての自覚を持ち、当事者として顧客の意向を調整する役割を果たさなければなりません。**

開発手法の選択の基準は企業やプロジェクトによってさまざまです。案件の特性、企業の体制、実績の有無などが考慮されて選ばれます。したがって、**アジャイル開発での仕事をしたい、経験を積みたいと考えて求人を探しても、希望に見合った求人は見つかりづらいかもしれません。**

**そんな場合には、転職エージェントを利用して企業の細かな情報まで提供を受け、アジャイル開発のできる転職先を探すのが近道となりそうです。**マイナビエージェントは、IT・Web業界の転職市場に精通した「キャリアアドバイザー」と、企業への営業担当として各企業と太いパイプを持つ「リクルーティングアドバイザー」がチームとなり、あなたが本当に求める転職先のご紹介や、応募書類の作成、面接対策、給与交渉」など、あなたの転職活動をすべてにわたってサポートします。エンジニアのキャリアチェンジ、キャリアアップを目指す際には、ぜひご利用をご検討ください。

[転職エージェントならマイナビエージェント｜求人・転職サイト](https://mynavi-agent.jp/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv08)

【アジャイル開発とは】特徴と3つの開発手法、メリットとデメリットを解説

AWS（Amazon Web Service）は、”GAFA”の1つであるAmazonが提供するクラウドサービスのことです。AWSは、*世界のIaaS市場で45%のシェア*を占め、2位のAzure(Microsoft)18%を大きく引き離しています。日本でも、**日本政府が行政サービスのDX化を狙いにAWSを政府共通プラットフォームとして採用する**など、注目を集めています。

本記事ではAWSの概要や活用策に触れ、エンジニアの皆さんの今後の成長に役立てて頂きたいと考えています。

AWSとはAmazonが提供するクラウドコンピューティングサービスの総称です。

クラウドコンピューティングとは、インターネットを利用してサーバーや各種ストレージ、データベースやソフトウェアなどのインフラサービスを利用することです。**クラウドコンピューティング環境を利用する場合は、1台のPCとインターネット接続環境があれば、さまざまなインフラを必要な分だけ利用できる**のです。AWSはこのクラウドコンピューティングサービスをあらゆる企業や行政組織、個人に提供することで成り立っています。

企業内システムの多くは、オンプレミスという形態で、企業内に独自のコンピューターやネットワークを設けてシステムを運用してきました。オンプレミスは初期投資のみならず、所有コストや運用コスト、セキュリティリスクなど大きな負担を抱えていました。

しかし、**AWSを採用すると、初期費用も減価償却費も掛からず、システムを稼働させることができます。システム監視、セキュリティ対策、災害対策もすべてAWSが行ってくれます。**企業規模の拡大によるハードの増強などもAWS側で柔軟に対応してくれるのです。このように、システムの自社所有に伴う問題をすべてAWSが吸収してくれることが、各社がこぞってAWSを採用する理由なのです。

AWSの対抗サービスとしてMicrosoft社が提供するクラウドサービスAzureがあります。両者はほぼ同じようなサービスを提供しており、企業がクラウド移行を図る際には常に比較検討されます。

その中で**Azureの決め手はOffice365との連携**でしょう。Microsoft製品を多く使う企業では、アカウント管理も含めてシームレスにクラウド環境への移行ができる利点があります。

AWSの概要についてより深く理解するため、ここではAWSのメリットとデメリットについて解説します。**クラウド移行を図る際は、必ず自社におけるメリットとデメリットをよく検討した上で採用**をする必要があります。

*1.初期コストを抑えられる*
自前でサーバー構築を行うオンプレミス環境では、必ず初期コストや時間が掛かりますが、**クラウドサービスでは基本的に大きな初期コストは必要なく、単期間でスタートができます。**

ただし、クラウドサービスの基本はIaaS(Infrastructure as a Service)です。提供されるのは仮想サーバーやネットワークなどのインフラであり、*OSやミドルウェアなどは別途ライセンス料が発生*します。家に例えると、建物は提供されますが内装や家具・備品などは別料金というわけです。

*2.リスクヘッジができる*
オンプレミスの場合は、サーバーダウンによる営業損失、ハッキングなどによる情報漏洩はすべて自社責任です。そのため、併せて災害対策やセキュリティ対策を施す必要がありますが、AWSに移行することで、これらの責任の多くがAWSに移転します。**AWS責任で起きた問題に対してはAWSが補償してくれる**ようになるので、リスクヘッジが可能となります。

*3スケーラビリティが担保される*
オンプレミスでは、事業拡大に伴うデータ量の増加への対応を自前で行わなければなりません。それとともに、**サーバーの増強、リプレイスといった対応を迫られますが、AWSでは企業側はその対応の必要がなくなります。**もちろん、AWSは従量課金制を基本としていますので、データ量の増加などに伴いランニングコストは増加しますが、サーバーがキャパシティオーバーでパンクするといった心配はありません。

*1.ランニングコストは決して安くはない*
**AWSは初期コストの安さがメリットですが、反面ランニングコストは安くはありません。**家庭用プリンターは2万円程度で買えるのに、インク代が数千円も掛かるのと似ています。AWSは自前で莫大な投資を行い、ランニングで利益を上げるビジネスモデルになっているのです。

しかし、コスト比較をする際に顧客側が見逃しているポイントが幾つかあります。オンプレミスのサーバーやハードの償却費用と比較して、AWSのランニング費用は明らかに高くなります。

*しかし、オンプレミスの場合の家賃、水光熱費、人件費、セキュリティ対策費用、災害対策費用などを含めるとAWSのランニング費用が低いケースが多い*のです。そこを見誤ると、「AWSは高い」というAWS批判に繋がります。

*2.コンテンツはあくまでも自前*
AWSを利用すると、システム部門を大きく縮小できると考える経営者がいますが、それは大きな誤解です。**AWSが提供するのはあくまでもインフラであり、情報システムは企業側が用意しなければなりません。**そのコンテンツについては利用者側である企業が全責任を負わなくてはならないのです。

オンプレミスからAWS移行を果たした後、**運用やインフラ管理から解放された情報システム部門は企画や情報活用面で機能を果たしていくべき**でしょう。

AWS移行とは、オンプレミスで運用している自社システムの稼働をAWSに移すことを意味します。この**AWS移行ではいくつかの確認ポイントがあり、これを行わないとAWSのメリットが半減するばかりか、場合によっては移行に失敗することがあります**ので、必ず確認を行うべきです。以下そのポイントについてまとめてみました。

### Ⅰ.移行可能な要素の洗い出し

*1.ハードウェア*
**オンプレミスで利用中のハード(サーバーやネットワーク機器)はAWSに移行できません。**AWS移行対象外のシステムでの利用、売却等の対応を検討しておく必要があります。

お役立ち記事