## AWSのセキュリティは万全か？

皆さん、よくご存知のAWSはAmazonが展開する世界最大のクラウドサービスですが、セキュリティ面でも世界最高クラスのサービスが提供されています。そのため、AWSを利用する際には、利用者側で用意するものが無いと信じている方も少なくありません。確かに、AWSにはセキュリティ面でもさまざまな強固なセキュリティ対策が施されており、利用者側はセキュリティ対策が不要と考えがちですが、それは大きな誤りです。

**AWSには「責任共有モデル」と呼ばれるものがあり、利用者側もクラウド内のセキュリティ確保に一定の責任を負っています**。基本的に、AWSは不沈艦と言えるほどの強固なセキュリティによって守られていますが、搭乗員の健康管理に関しては自己管理と認識しておく必要があります。ここでは、*AWSのウィルス対策をはじめとするセキュリティ対策*について解説していきます。

### AWSを利用してセキュリティ事故を起こすとどうなる？

セキュリティ事故は、報道されないものを含めると膨大な件数があると言われています。自社の機密情報漏洩・サーバー攻撃によるサービス停止・データの改ざんや破壊などさまざまありますが、**最も影響が大きいのは個人情報の漏洩**です。

*個人情報が漏洩すると、顧客に直接被害が及び、企業のブランドイメージの失墜ばかりか、株価下落、売上低下、さらには顧客への補償などで、時には企業の経営そのものが危うくなることすらあります*。また、被害がAWSやAWS利用者に及び、*損害賠償請求を受けるリスク*もあります。これほどセキュリティ事故は多大な損害を被るということをまず認識しておきましょう。

AWSには「責任共有モデル」という考え方があります。**「責任共有モデル」は、AWSが提供する数々のインフラやサービスについて、AWSが直接責任を負うべき部分と、利用者が責任を負うべき部分を明確に分けて、責任の分界点を明らかにする考え方**です。*AWSが責任を負っている範囲は具体的にはハードウェア・ソフトウェア・ネットワーク関連・AWSのサービスを提供している施設（データセンター）*です。AWSの責任範囲で発生した障害や事故で、利用者に損害を与えた場合にはAWSが損害賠償責任を負います。

一方、AWSが提供しているサービス以外の部分が利用者側の責任範囲となりますが、責任を負う範囲は、AWSクラウドサービスの利用している範囲によっても異なります。

参照：*[責任共有モデル – アマゾン ウェブ サービス (AWS)](https://aws.amazon.com/jp/compliance/shared-responsibility-model/)*

「責任共有モデル」のAWS側の責任範囲について、もう少し詳しく述べます。「責任共有モデル」における**AWS側の責任範囲は、主にAWSサービスの基本となっているインフラの部分**です。以下、主な責任範囲を列挙します。

AWSの施設（データセンター）は、非常に強固な物理的セキュリティによって守られていますが、万が一、*データセンターそのものが災害などによって停止という事態に陥ると、他のAWSのデータセンターで処理を継続できるような仕組み*になっています。これを**ディザスタリカバリ（disaster recovery - DR）**と言います。この施設の管理はAWSの最初の責任範囲です。

### 2：インフラストラクチャの管理

AWSのデータセンター内には、さまざまなインフラ設備があります。*電源・空調・ネットワーク・サーバー・ストレージなどは24時間監視下にあり、冗長化も含めて完全無停止を前提に設計され、稼働*しています。**このインフラストラクチャの管理は、AWSの2つめの責任範囲**です。

### 3：ハイパーバイザー（ホストOS）

**AWSはホストOSの稼働を保障しています**。これがAWSの3つ目の責任範囲です。そのために*厳格なアクセス管理が行われるよう、多要素認証に基づき、外部からのアクセスが非常に厳しい仕様*となっています。利用者側が作業を完了した後は、都度システムへの付与特権とアクセス権を削除するとともに、全てのアクセスのログが保管される仕組みです。

AWSの「責任共有モデル」では、**AWSが提供しているサービス以外の部分はユーザー側で責任**を負うことになります。

IaaSのようなホスティングサービスでは、**ゲストOSの管理や運用は利用者側の責任範囲**です。

*仮想サーバーであるAmazon EC2 インスタンスを利用する場合は、ゲストOSの更新・セキュリティパッチの適用・アプリケーションなどの管理・ファイアウォールの構成については利用者が責任を負う*形となります。

Amazon EC2 のサービスはIaaS（Infrastructure as a Service ）のため、**ネットワークの設定を含むセキュリティ構成や管理は利用者側の責任**で行う必要があります。

Amazon EC2では、利用者がEC2のインスタンス内に**インストールしたアプリケーションは、利用者側で管理したり、運用したりする責任**を負います。

**AWSサービスの中で扱うデータは、暗号化を含めてそのデータの管理は利用者責任**となります。また、データはオーナー（利用者）以外の者がその管理方法を決めることはできません。

前記のデータの暗号化と同様、AWSのサービスの利用者の**アカウント・アカウントに紐づくシステム・利用者側のデータに対するアクセス権限の管理や運用も、利用者が責任をもって行う**必要があります。

## AWSで利用者が行うべきセキュリティ対策とは

では、これらの問題を防ぐための対策としては、どのようなものがあるのでしょうか？ここでは、**AWSを使用する際の具体的なセキュリティ対策**をご紹介します。詳しくは、*[AWS アカウントのセキュリティを改善するための 10 個の項目](https://aws.amazon.com/jp/blogs/news/top-10-security-items-to-improve-in-your-aws-account/)*を参照してください。

### セキュリティグループをしっかり設定する

利用者に際して、まず初めに**セキュリティグループの設定**を行いましょう。*AWSが標準装備しているファイアウォールのことをセキュリティグループと称し、EC2インスタンスに対して適用*します。

セキュリティグループでは、EC2インスタンスへの*アクセス許可の範囲とトラフィックの制御*が行えます。特に開発環境ではセキュリティ被害に遭いやすい傾向があるため、*インバウンドルール（アクセス制限のルール）は厳しく設定*し、必要がない人には公開しないことです。

### 認証情報を定期的に確認し、無効化する

ログの管理も重要なセキュリティ対策の1つです。**定期的に認証情報を確認し、怪しい認証がないかどうか確認**しましょう。また、1度発行したIDで90日間以上利用されていないものは、確認をとって削除するようにします。休眠状態のIDが不正アクセスに利用されるケースがよくありますので、*不要なIDは極力使わない*ようにすべきです。

さらに、*ソフトウェアのバージョン管理もしっかり行いましょう*。セキュリティに脆弱性が発見されると、その脆弱性が攻撃の標的になりがちです。セキュリティパッチの有無を定期的にチェックし、ソフトウェアのバージョンを常に細心に保つことが重要です。

### マルウェア・ウィルス対策を施す

AWSは強固なセキュリティ対策が施されているとはいえ、インターネットに向けて公開された環境にあります。ソフトウエアの脆弱性を利用して、*マルウェアやウィルスなどの不正プログラムが侵入してくるリスクはゼロではありません*。また、自社のシステム内で利用しているメールシステムやWebシステムを経由してウィルス感染するリスクもあります。**マルアェア対策、コンピューターウィルス対策は利用者の責任と心得て、アンチウィルスソフトなどの適用を図る**必要があります。

### 多要素認証（MFA）を利用する

**MFAとは、簡単に言えば2段階認証のような仕組み**です。一般によく使われるログインIDとパスワード認証に加えて、さらにもう別の認証要素を組み合わたものです。*これを有効にしておくと、第三者による不正ログインを防ぐ*ことができます。

上記以外にもセキュリティレベルを高めるための方法は幾つかあり、AWSは10項目のセキュリティ対策を提唱しています。その他には**脆弱性診断サービスを利用して、自社のシステム特有の脆弱性がないか否かを検証することが求められます**。AWSには脆弱性診断のオプションサービスとして*[Amazon Inspector](https://aws.amazon.com/jp/inspector/)*がありますので、こちらを利用しても構いませんし、自社の協力会社などのサービスを利用しても構いません。いずれにせよ、*自社システムの脆弱性を定期的に診断することで、セキュリティの強化を図る*ことができます。

## AWSを正しく利用し、クラウド利用の効果を最大化しよう

いかがでしたか？AWSは鉄壁のセキュリティで守られているから、セキュリティ対策は不要と思われていた方にはがっかりされた方がいるかもしれません。しかし、実は*AWSはオンプレミスの場合と比べて、利用者側が行うべきセキュリティ対策はかなり限定されており、その負担も軽減されています*。セキュリティ基準の厳しい金融系のシステムでもAWSを利用しているほどです。

AWSは直ぐに利用できて大変便利なクラウドサービスですが、*利用する側がセキュリティ管理を疎かにすると、大きな事故につながる可能性を排除することはできません*。AWS側は、AWSの責任による事故などは補償をしますが、逆に利用者側の責による事故に対して一切補償はありません。さらに、事故がAWSや他の利用者に影響を及ぼした場合は、損害賠償請求の可能性を否定できません。

**AWSは「責任共有モデル」という両者の責任の分界点を明確にしています。つまり双方が責任の分担をしなければ、安全の確保やセキュリティの担保ができないということ**です。セキュリティ確保の責任は、この記事をお読みになったITエンジニアの皆さん1人1人にあるという自覚を持ち、AWSを正しく利用して、その*利用効果の最大化*を図っていきましょう。

AWSは強固なセキュリティ対策が施され、ユーザー側はセキュリティ対策が不要と考えがちですが、これは大きな誤りです。AWSは「責任共有モデル」により、ユーザーもクラウド内のセキュリティに一定の責任を負います。ここでは、AWSのウィルス対策について解説します。

AWSには「責任共有モデル」という考え方があり、セキュリティ対策の責任はそれぞれが負うことになっている

AWS利用で、利用者側の対策不備によってセキュリティ事故が発生した場合は利用者がその全ての責任を負う

セキュリティ対策で利用者側が行うべき10の項目があり、これらを正しく行ってAWS利用効果の最大化を図ろう

AWSの利用で、セキュリティやウィルス対策の責任は誰が負う？

AWSのストレージサービスである*Amazon S3*は*Amazon Simple Storage Service*の略で、オブジェクトストレージのサービスを指します。*オブジェクトストレージ*とはデータをオブジェクトとしてWebアクセスするもので、簡単にいえば**ファイルを保管する倉庫**の役割を持ちます。
参考：[AWS Amazon S3](https://aws.amazon.com/jp/s3)

### Amazon S3の特徴とメリットは？

*Amazon S3*は*スケーラビリティ*と*データの可用性*を高めたサービスで、最大*5TB*までのオブジェクトを**データ総量の制限なく利用できる**特徴を持ちます。

具体的な特徴としては*99.999999999%の耐久性*を実現できる設計がされており、安定したサービス提供がされています。さらに、S3 ストレージクラスの分析機能により階層化できるので*性能を維持*しながら*コストを低減*することが可能です。加えて、*セキュリティを維持*しながら*安価*にサービスが利用できる点もメリットとして挙げられます。

Amazon S3の利用料金は、*従量課金制*を取っています。以下の**6つのコスト要素**により料金が計算され、料金は安価に設定されています。

・*ストレージ料金*
　S3バケットという保存領域に保存するオブジェクトのサイズ・オブジェクトを保管した期間の長さ・ストレージクラスにより計算されます。
・*リクエストとデータ取り出しの料金*
　S3 バケットとオブジェクトに対して行われた、PUT・COPY・POST・LIST・GET・SELECT・ライフサイクル移行・データ取り出しに対して費用が発生します。
・*データ転送と転送高速化の料金*
　インターネットおよびS3バケットで発生した転送データが料金支払いの対象となります。
・*データ管理機能および分析機能の料金*
　ストレージ管理機能と分析 （Amazon S3 インベントリ・S3 ストレージクラス分析・S3 Storage Lens・S3 オブジェクトタグ付け）により費用が発生します。
・*レプリケーション*
　プライマリコピーとレプリケーション PUT リクエストのストレージに関して、データ転送料金が発生します。
・*S3 Object Lambda*
　AWS Lambda 関数の利用とアプリケーションに戻るデータ量に応じて費用が発生します。

Amazon S3では、*AWS無料枠*が設定されていますので有効活用しましょう。新規サインアップにより、S3標準ストレージクラスで 5GB の Amazon S3 ストレージ・20,000 GETリクエスト・2,000 PUT・COPY・POSTあるいは LISTリクエスト・データ送信15GB を毎月、1年間に渡りAWS無料枠として利用できます。*無料利用枠の使用量*は毎月計算され、*自動的に請求額に適用*されます。未使用分は持ち越しできないのでご注意ください。

*Amazon S3*では、ストレージサービスを構成するに当たりいくつかの用語が定義されています。ここでは、Amazon S3を有効活用する上で必要となる**代表的な用語**を説明していきます。

・*バケット*
　バケットとは、Amazon S3に格納するオブジェクトの入れ物（コンテナ）を指します。バケットにより格納先のネームスペースが確定し、アクセスコントロールや使用状況レポートの集計に活用されます。

・*オブジェクト*
　オブジェクトとはAmazon S3に格納される単位となります。オブジェクトはデータ自体を指すオブジェクトデータとデータ管理用メタデータから成ります。

・*キー*
　キーとはバケット内のオブジェクトを管理するための固有の識別子を指します。URLからバケットとキーを参照することでオブジェクトへアクセスすることが可能となります。
参考：[AWS Amazon S3 ユーザーガイド](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/s3-userguide.pdf)

### Amazon S3のストレージクラスとは？

Amazon S3では、*サービスレベル・条件に応じて*いくつかのクラスが設定されています。それを*ストレージクラス*と呼びます。各クラスは以下のように分類されます。

・*S3 標準*
　汎用的な一般使用を想定したストレージクラス
・*S3 Intelligent - Tiering*
　アクセスパターンを分析し階層化することで自動コスト削減するストレージクラス
・*S3 標準 - 低頻度アクセス*
　長期保管でアクセス頻度の低いデータ、アクセス速度は標準的なストレージクラス
・*S3 1 ゾーン - 低頻度アクセス*
　アクセス頻度の低いデータで再作成可能なデータ、アクセス速度は標準的なストレージクラス
・*S3 Glacier*
　長期バックアップとアーカイブ用、1分から 12 時間の取り出しを想定したストレージクラス
・*S3 Glacier Deep Archive*
　長期アーカイブ用、1年に 1-2 回の頻度で12 時間以内の復元を想定したストレージクラス
・*S3 Outposts*
　オンプレミス用ストレージクラス

各ストレージクラスは耐久性設計は同一であるものの、アクセスパフォーマンスや可用性に違いを持ちます。したがって、**用途に応じてストレージクラスを選択する**必要があります。

*Amazon S3*を使うには、*S3バケット*を**最初に作成**しておきます。その後バケットにオブジェクトを*アップロード*して追加したり、オブジェクトの*ダウンロード*やフォルダへの*コピー*が可能となります。詳細は以降でお話しします。

*Amazon S3*を利用するためには、**事前準備が必要**です。利用にあたり以下のステップに従い*構築を進めていきます*。

（1） *AWSアカウントのサインアップ*
AWSではサービス利用のためにAWSアカウントが必要です。Amazon S3においても同様にアカウントサインアップを行ってください。

（2） *S3バケットの作成*
Amazon S3では、データ保存庫としてS3バケットを最初に作成します。作成するためにはAWSマネジメントコンソールより、Amazon S3コンソールを起動し「バケットの作成」を選択します。ここでバケット名を指定し、バケットを作成します。

（3） *バケットの削除*
バケットが不要になった場合は、Amazon S3コンソールからバケットの削除が可能です。しかし、バケットの削除は元に戻りません。そのため同じバケット名を使いたい場合はバケットを空にするかオブジェクトを削除し、むやみにバケット自体の削除をしないよう注意しましょう。

### オブジェクトのアップロード方法は？

*Amazon S3*では、**ファイルタイプを問わず**バケットにオブジェクトを追加することで*アップロードが可能*です。

AWS SDKやREST APIおよびAWS CLIからのアップロードは、1回あたり最大*5GB*のオブジェクトをアップロード可能です。同様に、マルチパートアップロードAPIを利用することで、最大*5TB*のサイズのオブジェクトがアップロード可能となります。
Amazon S3コンソールを用いたアップロードでは、最大*160GB*のオブジェクトをアップロード可能です。

*Amazon S3コンソール*を用いたアップロードの場合は、AWSマネジメントコンソールよりAmazon S3コンソールを起動し「バケットリスト」からバケットを指定します。オブジェクトタブからアップロードを選択し、ファイル追加により**アップロード**を行います。

*AWS SDK*を使用する場合は、.NET・Java・JavaScript・PHP・Ruby等の開発言語でPUTオブジェクトリクエストを発行することでアップロードが可能です。*REST API*の場合は、PUTリクエストによりアップロードできます。*AWS CLI*の場合もPUTリクエストを用います。

### オブジェクトのダウンロード方法は？

*Amazon S3コンソール*を用いてオブジェクトのダウンロードを行う場合は、AWSマネジメントコンソールより、Amazon S3コンソールを起動し「バケットリスト」からバケットを指定します。オブジェクトタブからオブジェクトを選択し、オブジェクトアクションにより**ダウンロード**を行います。

*AWS SDK*を使用する場合は、.NET・Java・JavaScript・PHP・Ruby等の開発言語でGETオブジェクトリクエストを発行することでオブジェクトのダウンロードが可能です。*REST API*の場合は、GETリクエストによりダウンロードできます。*AWS CLI*の場合もGETリクエストを用います。

留意点としては、*オブジェクトダウンロード*については*データ転送料金が適応される*ことです。オブジェクトダウンロードの**範囲やサイズは最低限に留める**のが良いでしょう。

### オブジェクトのフォルダへのコピーの方法は？

オブジェクトのフォルダへのコピーするには、コピーオペレーションを実行します。コピーできるサイズは最大*5GB*です。

*Amazon S3コンソール*を用いたコピーの場合は、AWSマネジメントコンソールより、Amazon S3コンソールを起動し「バケットリスト」からバケットを指定します。必要に応じてフォルダ作成により新規にターゲットフォルダを作成します。次に、オブジェクトタブからオブジェクトを選択し、オブジェクトアクションにより**コピー**を行います。コピー先は例として以下のように指定可能です。
s3://バケット名/フォルダ名/.

*AWS SDK*を使用する場合は、.NET・Java・JavaScript・PHP・Ruby等の開発言語でCOPYオブジェクトリクエストを発行することでオブジェクトのコピーが可能です。*REST API*の場合はPUTリクエストによりコピーできます。*AWS CLI*の場合もPUTリクエストを用います。

### オブジェクトのフォルダへの移動の方法は？

*Amazon S3コンソール*を用いてオブジェクトを移動する場合は、AWSマネジメントコンソールより、Amazon S3コンソールを起動し「バケットリスト」からバケットを指定します。必要に応じてフォルダ作成により新規にターゲットフォルダを作成します。次に、オブジェクトタブからオブジェクトを選択し、オブジェクトアクションにより**移動**を行います。移動先はコピー操作時と同様の指定を行います。

*AWS SDK*を使用する場合は、.NET・Java・JavaScript・PHP・Ruby等の開発言語でCOPYオブジェクトリクエストとDELETEオブジェクトを併用することでオブジェクト移動が可能です。*REST API*の場合は、PUTリクエストにより同等の処理ができます。*AWS CLI*の場合は、MVリクエストを用います。

### オブジェクトを削除するには？

*Amazon S3コンソール*を用いてオブジェクトを削除する場合は、AWSマネジメントコンソールより、Amazon S3コンソールを起動し「バケットリスト」からバケットを指定します。次に、オブジェクトタブからオブジェクトを選択し、「最新バージョン」や指定バージョンのオブジェクトを選択し「**ゴミ箱**」アイコンをクリックします。同様に、*バケットを空にする*ことも可能です。

*AWS SDK*を使用する場合は、.NET・Java・JavaScript・PHP・Ruby等の開発言語でDELETEオブジェクトリクエストを発行することでオブジェクト削除が可能です。*REST API*の場合は、RESTリクエストにより削除できます。*AWS CLI*の場合もDELETEリクエストを用います。

## Amazon S3を用いてデータ保存の最適化を図りましょう

AWSのAmazon S3は、格安なストレージサービスとして*ウェブサイトやモバイルアプリケーション*から汎用的に利用することができます。また、*データレイク・IoT デバイスやビッグデータ分析*の大容量ストレージとしての活用や、*企業向けストレージシステム*としても利用者が多いです。他にも*バックアップおよび復元、アーカイブ*等多岐に渡る利用用途が挙げられます。

Amazon S3は多岐に利用することが可能であるため、AWSのサービスを有効活用するためにもAmazon S3による*データ保存や格納先*として**最適化を図る**ことをお勧めします。

AWSのストレージサービスとなるAmazon S3は、あらゆるタイプのデータを安価に格納することができるため利用者が増えています。ここではAmazon S3の特徴に加えて、実際のアップロードやダウンロード等の使い方について説明していきます。

Amazon S3は、AWSのオブジェクトストレージのサービスを指します

Amazon S3の使い方はAmazon S3コンソールの他、AWS SDKやREST APIおよびAWS CLIを用います

Amazon S3は、保存するデータのファイルタイプは問わないため多用途に活用可能です

Amazon S3の使い方は？AWSのストレージサービスを解説！

## フルスタックエンジニアとは

皆さんは「フルスタックエンジニア」という言葉を聞いたことがあるかと思います。では、「フルスタックエンジニア」とはどんなエンジニアを指すのでしょうか。

フルスタックのスペルは、""full-stack""です。Stackは「積み重ね」を意味する英語で、**フルスタックエンジニアとは、複数の分野における技術や知識を身につけたエンジニアのことです**。

例えばWeb系エンジニアでは、Webサーバやソフトウェア環境に関わるインフラの知識を持ちながら、コーディングやデータベース設計、さらにはWebデザインなどにも精通し、*1人でほぼ全ての業務を担えるようなエンジニアを「フルスタックエンジニア」と称します。*

ただ、「フルスタックエンジニア」という明確な定義はなく、その資格要件もありません。「フルスタックエンジニア」はまったく新しいエンジニアの概念で、そのイメージ像が固まっていくには少し時間が掛かりそうです。ここでは、この*フルスタックエンジニアがなぜ注目されているのか・将来性はあるのか・目指すにはどんな資格を取れば良いのか*、などについて解説していきましょう。

### フルスタックエンジニアが今注目されている理由

「フルスタックエンジニア」は元々アメリカで生まれた言葉ですが、最近になって日本でも使われるようになりました。今や、注目のエンジニアとしてIT業界では注目されつつあるのには理由があります。

従来のIT開発や運用では、分業が当たり前でした。設計フェイズはSE（システムエンジニア）が行い、コーディングはプログラマーが行い、データーベース設計はデータベースエンジニアの領域でした。しかし、この分業によってIT開発の要員確保やコスト面が足かせとなり、市場のニーズに対応できなくなってきたのです。

*DX時代を迎え、IT開発に対する市場からは「少人数・ローコスト・短納期」のニーズが高まっています*。一方で、クラウドの普及により、インフラに関わる工数やインフラ人材の必要性が低下し、クラウド環境での多様なフレームワーク活用によって、開発工数が短縮されてきたこともあり、従来は複数のエンジニアで分業していたものが、1人のエンジニアでも対応できる環境が整ってきたこともフルスタックエンジニアが登場した要因になっています。

**複数の工程を1人のエンジニアが対応できれば、タスク間の調整やマネジメントが不要になり、生産性向上やコスト低減も可能です**。フルスタックエンジニアを擁するIT企業は、その分だけ競争優位に立つことができます。

これが今、まさにフルスタックエンジニアが注目されている大きな理由です。

### フルスタックエンジニアを目指すには

この記事で初めて「フルスタックエンジニア」に興味を持たれた方もいるでしょう。フルスタックエンジニアになるためには、ITに関わる広い技術や知識が不可欠です。また、より多くの領域での経験があればなおさら有利です。しかし、経験とは単に待っていれば訪れるものではありません。

*自ら経験を積むという強い意志と、あらゆる機会を逃さないという積極性*が求められます。また、**フルスタックエンジニアには高い判断力・顧客（ユーザー）のニーズをくみ取る能力・コミュニケーション力・企画力・プレゼンテーション能力・マネジメント力など、多様な能力も求められます**。これらを念頭に置いて頂き、フルスタックエンジニアを目指す上で知っておくべきことなどをこれから解説します。

## フルスタックエンジニア出現の背景

**なぜ最近になってフルスタックエンジニアが出現したのか**、まずはその背景を探ってみましょう。背景を知ることでフルスタックエンジニアが注目されている理由も分かります。

**フルスタックエンジニアが必要とされている要因として、「アジャイル型開発」手法の普及**が挙げられます。ご承知の通り、「アジャイル型開発」は、従来型の要件定義・設計・プログラミングなどを順にこなしていく「ウォーターフォール型開発」とは逆で、機能単位で短期間に設計→開発→テストを繰り返していく開発方式です。

「アジャイル型開発」は全体として納期短縮という特徴をもっていますが、特にこの*「アジャイル型開発」においては、設計から開発・テストまでを一貫して、1人で対応できる「フルスタックエンジニア」が向いている*と考えられます。

フルスタックエンジニアの出現の背景としては、「クラウドサービス」の普及も見逃せません。それは、クラウドサービスを利用したシステム開発の増加が*フルスタックエンジニアの出現を後押し*したからです。

クラウドサービスの普及により、サーバー環境やソフトウェア環境などのインフラの構築が不要となり、エンジニアがシステム開発に専念しやすい環境が整ったからです。

### プログラミング技術の一般化

プログラミングに関する**「フレームワーク」や「ライブラリ」の進化もフルスタックエンジニア出現の背景として挙げられます**。すなわち、プログラミング技術の一般化によってプログラミングのハードルが下がり、システムエンジニアがプログラム領域に踏み込むことが可能になったことも影響しています。

また一方で、*プログラミング技術の習得に時間とエネルギーを割く必要がなくなり、プログラマーからシステムエンジニアへのキャリアアップが容易になったこと*も関係しています。

もう1つ、外してはならない要因としては、DX時代の到来も考えられます。欧米や急成長を遂げているアセアン諸国から、日本のITは遅れていると指摘されています。IT先進国に太刀打ちできなければ、日本企業の発展はあり得ないというコンセンサスが官民で共有されつつある今、*経産省主導の「DX推進」は各企業の存亡に関わる重大な課題*となっているのです。

このDX推進を図るにはIT人材が欠かせませんが、相対的にIT人材の枯渇が進んでいます。しかも、2025年までにDX達成という期限が設けられている中では、**「フルスタックエンジニア」の活躍が達成の鍵になっている**のです。

## フルスタックエンジニアの強み

かくして、「フルスタックエンジニア」に対する期待とニーズが高まっているわけですが、客観的に捉えて**「フルスタックエンジニア」の強みとは一体どこにあるのでしょうか？**

ご承知の通り、システム開発では要件定義フェイズから設計・開発・運用と様々な工程があります。しかし、工程ごとに求められるスキルや経験値があるため、各工程ごとに専門のエンジニアが担当するという形が一般的でした。

この結果として、人件費の増大や全体効率の低下を招いてきたのです。さらには、工程間の連携や調整に大きなエネルギーを取られてしまい、なかなか生産性が向上しないというジレンマがありました。

一方、*「フルスタックエンジニア」は複数の工程を1人で担当することが可能*であるため、システム開発に余分なエネルギーを費やす必要がなくなり、結果として人件費は抑制され、生産性が向上します。**この生産性の高さがフルスタックエンジニアの強みです**。

フルスタックエンジニアは不足する要員のピンチヒッター役を担うことができます。チーム作業の遅れた工程部分を手伝う、メンバーの欠けたパーツを担当する、といった柔軟な対応が取れ、*「作業停止」や「作業待ち」を招くことなく、プロジェクトの円滑な遂行を後押しすることができる*のです。この**臨機応変の柔軟な対応力が「フルスタックエンジニア」の強みの1つです**。

### リーダーを掛け持つことが可能

「フルスタックエンジニア」には開発工程をまたがって担当できる幅広い知見があります。プロジェクト全体を俯瞰することができるので、*プロジェクトリーダーとしての役割を担うことが可能*です。ほかにも、各開発工程間の橋渡しをするPM（プロジェクトマネージャ）として活躍することも可能であり、**PMの兼務をしながら、各工程を担当できるのも強みです**。

## フルスタックエンジニアの条件と年収

以上、「フルスタックエンジニア」について述べてきましたが、非常に期待の大きいエンジニアであることが分かりました。では、フルスタックエンジニアは正当な評価を受け、妥当な年収を得られているのかが気になるところです。この**フルスタックエンジニアの年収について見ていきましょう**。

### フルスタックエンジニアの条件

フルスタックエンジニアの一般的な概念としては「システム開発の複数以上の工程を担当できる」という、大変アバウトなものであり、明確な基準はありません。

ここで、システム開発の工程について改めて確認しておきましょう。*開発工程は要件定義から始まり、設計・開発・運用の4つです。*

フルスタックエンジニアはこの4つの工程に関して、*一貫して一通り行えるだけのスキルと知識が求められるエンジニア*と考えて良いでしょう。その内2つの工程に関しては、リーダーとして担えることが求められます。

また、**それぞれの工程におけるスキルや知識以外に、インフラ・ソフトウェア開発・サービス運用・プロジェクトマネジメントの領域におけるスキルや知識も必要**です。広範囲のスキルや知識が求められることから、フルスタックエンジニアはスーパーエンジニアとも称されます。

### フルスタックエンジニアの年収

フルスタックエンジニアが注目されていることは理解できましたが、果たして年収はどのくらいなのか気になるところです。今現在では「フルスタックエンジニア」という職種の定義が完全に定まっておらず、年収に関する統計情報からは見つけることはできませんでした。そこで、**募集ベースの情報から年収を求めてみました**。

[求人ボックス](https://xn--pckua2a7gp15o89zb.com/%E3%83%95%E3%83%AB%E3%82%B9%E3%82%BF%E3%83%83%E3%82%AF%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E4%BB%95%E4%BA%8B-%E6%9D%B1%E4%BA%AC%E9%83%BD)によると、**「フルスタックエンジニア」の募集ベース（東京）での平均年収は645万円です**。

ちなみに、システムエンジニアは575万円・プログラマー478万円・データベースエンジニア625万円と比較しても明らかに高くなっています。

## フルスタックエンジニアの将来性

現在、フルスタックエンジニアに対する需要は急速に高まっています。実際にIT系の求人情報には、以前にはあまり見かけなかった「フルスタックエンジニア募集」の広告が頻繁に見られるようになりました。*「フルスタックエンジニア」という職種が社会に広く認知されてきた証*です。

では、フルスタックエンジニアに対する需要は今後も続くのでしょうか？**将来性はあるのでしょうか？**フルスタックエンジニアを目指すエンジニアの皆さんには大きな関心事なはず。これからそれを探っていきます。

### フルスタックエンジニアの需要

DX推進・DXの実現が、日本企業にとっても日本経済にとっても最重要課題の1つとなっている今日、*開発期間の短縮・開発生産性向上に強いとされるアジャイル型開発が脚光を浴びています*。実は、フルスタックエンジニアはこのアジャイル型開発に最も適したエンジニアなのです。

スピード開発を売りにしているITベンチャー系企業、アジャイル型開発に強いITベンダーでは、**特にフルスタックエンジニアに対する需要が高まっています**。
フルスタックエンジニアに対する求人は右肩上がりで増加しており、今後も一層その需要が高まっていくことでしょう。

### フルスタックエンジニアのキャリアパス

このように大きな脚光を浴びている「フルスタックエンジニア」ですが、単なる便利屋と見られ、使い捨てにされてしまうリスクはないのでしょうか？

客観的に見れば、フルスタックエンジニアは時代の申し子です。*ITの環境変化や、社会の変化が「フルスタックエンジニア」を生み、市場が「フルスタックエンジニア」を必要としています。*

現在、AIの発達によって消えていく職種がいくつか想定されています。プログラミングや運用などはAIが担う時代が来るかもしれません。しかし、マネジメントの領域はまさに人が最も得意な分野です。**フルスタックエンジニアには無限の可能性がある**ので、将来を担うITエンジニアの皆さんはぜひこのフルスタックエンジニアに挑戦してみてください。

<center>*＼転職するか迷っていてもOK！／*<br/>[*マイナビエージェントに無料登録して*<br/>*転職サポートを受ける*](https://mynavi-agent.jp/entry/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv17)</center>

ITエンジニアの業務が多様化し、DX時代を迎えてITとエンジニアが不足する中、「フルスタックエンジニア」が注目されています。この記事では、1人で複数のエンジニア業務をこなすフルスタックエンジニアが注目される理由・出現の背景・年収・将来性について解説します。

フルスタックエンジニアとは、複数の分野における技術や知識を身につけたエンジニアのこと

フルスタックエンジニアは市場の期待やニーズが高まっているエンジニア職種である

フルスタックエンジニアは将来性が高い職種であり、AIに置き換わることはない

フルスタックエンジニアとは？必要な条件・年収・将来性を解説

**アジャイル開発とは、迅速で適応的にシステム開発を行う開発手法のことです。**ここでは、アジャイル開発のメリットについて詳しく紹介します。メリットを把握することで、アジャイル開発が適しているプロジェクトの判断ができるようになります。

**アジャイル開発は、ウォーターフォール開発と比較して柔軟に仕様変更ができます。**ウォータフォール開発とは、開発手順を1つずつ確認して工程を進めていく手法のことです。開発を工程ごとに分けて進めるため、次のフェーズに進むと手戻りが難しい手法ともいえます。そのため、ウォーターフォール開発ではプロジェクトを進めていく中で、仕様変更が起きないように最初に念入りな要件定義を実施します。

*一方、機能ごとに計画・設計を実施するアジャイル開発の場合は、仕様変更にも柔軟に対応が可能です。例えば、クライアントが開発途中に仕様変更の要望があったとしても、その内容を次のイテレーションで要望を反映させることができます。*

### システムリリースまでの時間を短縮できる

**アジャイル開発では、システムをリリースするまでの時間を短縮させることができます。**システムを機能単位で、計画・設計・開発・テストの一連の工程を繰り返し行い、システム開発を進めていきます。*クライアントの要件を随時リリース計画に取り込むことで、迅速にクライアントのニーズを満たしたシステムを開発することが可能です。*

また、迅速なリリースができれば、競合他社と比較して優位に立つこともできます。そのため、アジャイル開発はリーンスタートアップと相性が良い開発モデルといえるでしょう。リーンスタートアップとは、コストをかけずに最低限の製品・サービス・機能を実装した試作品を短い期間で作成し、クライアントの要望を随時反映させて、クライアントが満足できる製品・サービスを開発していくマネジメント手法のことを指します。

### クライアントに寄り添った開発ができる

**アジャイル開発は、プロジェクトの進捗がわかりやすい特徴があります。**一方、ウォーターフォール開発ではプロジェクトの最後にシステムがリリースされるため、クライアントにとって、途中の成果はブラックボックスの状態ともいえるでしょう。

*アジャイル開発では短期間で成果物をリリースするため、クライアントは進捗状況について的確に把握でき、プロジェクトチームは随時フィードバックを得ることが可能です。次のイテレーションの際に、クライアントからの要望をシステムに反映させることで、クライアントに寄り添った開発を行うことができます。*

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

アジャイル開発はメリットだけではなく、デメリットもあります。ここでは、アジャイル開発のデメリットについて詳しく紹介します。

### スケジュール・工程管理が難しい

仕様や要件の大枠を決めて、開発を進めていくアジャイル開発では、柔軟性な仕様変更や迅速な開発ができるメリットの反面として、**スケジュール・工程管理が難しいというデメリットがあります。**クライアントの要望に応じて、随時対応しなければならないため、場当たり的なプロジェクトになる可能性があります。

*この課題を解決するためには、プロジェクトをまとめるプロジェクトマネージャーの存在が必要不可欠です。プロジェクトマネージャーは臨機応変にプロジェクトを進めていかなければならないため、高度なスキルが要求されます。*また、チームで情報伝達・共有するためのマネジメントツールを活用することも大切です。

さらに、パートナー会社を選定する際には、アジャイル開発の経験が豊富にあり、ノウハウ・リソースを充分に備えたシステム開発会社がおすすめといえます。

アジャイル開発には、クライアントの要望を取り入れやすいメリットがあります。**その一方で、仕様の変更や修正を何度も繰り返してしまうと、当初に作成した計画からプロジェクトの方向性が大きくブレてしまう可能性もあります。**

*方向性を見失ってしまうと、終着地点が見えない状態で、開発が延々と継続されることも少なくありません。*その場合、納期に遅れてしまったり、コストが多くかかったりするデメリットがあります。当初の目的を見失わないように、プロジェクトを進めていくことが重要です。

アジャイル開発には、さまざまな手法があります。ここでは代表的なアジャイル開発の手法について解説します。

**スクラム開発は、アジャイル開発の中で最もメジャーな手法で、チームで開発を進めるためのフレームワークのことを指します。**チームでプロジェクトを進めていく点から、ラグビーのスクラムをイメージさせることから名付けられました。

*スクラム開発では、プロジェクトメンバーがイテレーションごとに計画立案や設計・実装を行います。イテレーションごとに開発の進捗状況や機能の動作を確認するため、メンバー同士のコミュニケーションが重要です。*コミュニケーションが上手くいかないと、認識齟齬が生じ、機能が正しく動作しないなどの不具合やトラブルが発生する可能性があります。

### エクストリームプログラミング（Extreme Programming）

**エクストリームプログラミングは、アジャイル開発の中でも、仕様変更・要件追加に対する柔軟性を重要視した開発モデルです。**エクストリームプログラミングは、「XP」と呼ばれることもあります。*エクストリームプログラミングでは、クライアントの担当者もプロジェクトチームの1人として参画するのが特徴です。*

クライアントの担当者は、企画や計画の段階などのシステム機能を決定する工程に参加するだけではなく、システムリリースした後のレビューなども行います。固定した役割を設けるスクラム開発とは異なり、プロジェクトメンバー全員が参加するのが、エクストリームプログラミングの特徴です。また、初期計画よりも技術面を重視するため、プログラマー中心の開発手段ともいえます。

### ユーザー機能駆動開発（Feature Driven Development）

**ユーザー機能駆動開発は、クライアントのビジネスを可視化して必要な機能を洗い出し、適切な間隔でシステム開発を繰り返す手法です。**よって、ユーザー機能駆動開発は、クライアントの機能価値を重要視した開発を行います。ユーザー機能駆動開発は、英語の頭文字を取り「FDD」と呼ばれることもあります。*ユーザー機能駆動開発は、アジャイル開発とウォーターフォール開発の中間的なモデルともいえます。*

## アジャイル開発を成功させるために重要なポイント

多くのメリットがあるアジャイル開発ですが、もちろんデメリットもあります。アジャイル開発に見合ったシステム開発のプロジェクトであったとしても、目的意識を持たずにいると、プロジェクトが失敗してしまうこともあるでしょう。ここでは、アジャイル開発を成功させるために重要なポイントについて詳しく紹介します。

### システム開発プロジェクトの目的を明確にする

**アジャイル開発に限らず、プロジェクトを成功させるためには目的を明確にすることが最も重要です。**アジャイル開発では、柔軟性とスピード開発を重視するため、仕様や要件の大枠しか決定しないことが多いです。*ここで重要なのが、プロジェクトの目的まで曖昧にしてもよいと勘違いしてはいけません。あくまでも仕様・要件は大まかに決定し、システム開発プロジェクトの目的はきちんと明確化することが大切です。*

例えば、クライアントの好みに合わせて、変化が要求されるWebサービスがあったとします。その際に、ターゲットとする顧客や提供している機能を変更・修正することはあったとしても、目的は変わらないようにすることが重要です。*目的を曖昧にしていると、アジャイル開発のデメリット面が強調されることになるため、注意が必要です。*

### クライアントの担当者もプロジェクトチームの一員

スクラム開発・エクストリームプログラミング・ユーザー機能駆動開発など、採用する開発モデルによって異なることはありますが、**アジャイル開発ではクライアントの担当者がプロジェクトチームの中の一員と考えることは大切です。**PDCAサイクルを細かく回すことで、理想とするシステムに近づけていけるアジャイル開発では、クライアントの担当者が積極的にプロジェクトチームに関与して、システムをブラッシュアップしていく意識をもつことが重要といえます。

## アジャイル開発のメリット・デメリットを把握してプロジェクトを成功させよう

これまでに、アジャイル開発のメリット・デメリット、代表的な手法、アジャイル開発を成功させるための重要なポイントについて解説しました。アジャイル開発とは、システム開発におけるプロジェクト開発手法の1つで、大きな単位でシステムを区切らず、小さな単位で実装・テストを繰り返して開発を進めていきます。

**アジャイル開発のメリットは、柔軟な仕様変更ができることやシステムリリースまでの時間を短縮できることなどが挙げられます。一方、アジャイル開発のデメリットは、スケジュール管理が難しいことや開発の方向性がブレやすいことです。**

アジャイル開発の代表的な開発モデルは「スクラム開発」「エクストリームプログラミング」「ユーザー機能駆動開発」です。*アジャイル開発でプロジェクトを成功させるためにも、プロジェクトの目的を明確にすることや、クライアントの担当者もプロジェクトメンバーの一員と考えることが大切といえます。*

アジャイル開発とは、システム開発を行う開発手法の1つです。アジャイル開発のメリットを把握することはプロジェクトを成功させるためにも重要です。当記事では、アジャイル開発のメリット・デメリット、代表的な手法などについて詳しく解説します。

アジャイル開発のメリットは、柔軟な仕様変更ができることやシステムリリースまでの時間を短縮できること

アジャイル開発のデメリットは、スケジュール管理が難しいことや開発の方向性がブレやすいこと

アジャイル開発の代表的な開発モデルは、「スクラム開発」「エクストリームプログラミング」「ユーザー機能駆動開発」

アジャイル開発のメリット・デメリットや代表的な手法について解説！

AWSの特徴は、*サービスの豊富さ*と*提供範囲の広さ*です。自社サービス提供エリアにおいて*均一なサービス*を提供するために、地域を**物理的なロケーション**に分割してサービス提供しています。その物理的なロケーション分割単位を「*リージョン*」と言います。

AWSは継続的にサービス提供地域を拡大し、その地域をカバーするリージョンを開設しています。
参考：[AWS グローバルインフラストラクチャ](https://aws.amazon.com/jp/about-aws/global-infrastructure/regions_az/)

### AWSのアベイラビリティゾーンとは？

AWSの*アベイラビリティゾーン（AZ）*とは、1つのリージョンを*冗長性・信頼性・可用性*を確保した、*1つ以上のデータセンター*で構成する単位を指します。アベイラビリティゾーンは、*複数の独立した場所*に設置されており、冗長的な電力源・ネットワーク、そして接続機能により*相互に接続され運用されています*。

*アベイラビリティゾーン*により、自然災害やデータセンター障害発生時においても**ビジネス影響を最小にすること**を目的としています。

### AWSのサービスエンドポイントとは？

AWSの*サービスエンドポイント*とは、AWSのサービスにプログラム接続するための**接続情報**を指します。具体的には、以下のリージョンエンドポイントに対して接続リクエストを発行します。

「*protocol://service-code.region-code.amazonaws.com*」

protocolはhttps等で、service-codeとは利用サービスの名称です。region-codeとは、指定するリージョンコードを指します。この*AWS サービスエンドポイント*を指定することで、リージョンとその提供サービスが利用可能となります。
参考：[AWS サービスエンドポイント](https://docs.aws.amazon.com/ja_jp/general/latest/gr/rande.html)

お役立ち記事