*AWS*の特徴は、**膨大な提供サービスの数**にあります。各サービスは、AWSマネジメントコンソールと呼ばれる管理メニューから簡単にサービスを利用できます。

AWSでは、*コンピューティング・ストレージ・データベース・分析・ネットワーキング・モバイル・デベロッパー用ツール・管理ツール・IoT・セキュリティ・エンタープライズアプリケーション*などに分類しています。これらの分類に応じた*AWSのサービスを利用することが可能*です。
参考：[AWS クラウド製品](https://aws.amazon.com/jp/products/)

通常アプリケーションを実行するためには、*アプリケーション実行コード*が必要です。加えて、アプリケーションが実行する*ランタイムライブラリー*や、内部で使用する*依存ライブラリー*等を用意します。そして、アプリケーションの*設定ファイル*も必要です。

これらのファイル群は、サーバーの数が少ない場合はあまり気にする必要はありません。しかし、大量のサーバーを用いてアプリケーションを分散し起動したり、あるいは開発環境の様に設定を差し換えて起動したりとなると色々と問題が出てきます。まず、環境や設定が不統一の場合はサーバーを立ち上げるのに一苦労です。

それを解消するのが、*コンテナ*です。アプリケーションに必要とされる*アプリケーション実行コード*と*ランタイムライブラリー*および*依存ライブラリー*をコンテナ化し、まとめることでデプロイが簡単になります。*実行環境に合わせてコンテナの設定をカスタマイズ*するだけで**準備が完了**です。

### 仮想サーバーとコンテナの違いは？

一方の*仮想サーバー*とは、*ハイパーバイザーや仮想化ソフトウエア*を用いて実装したサーバーです。アプリケーション実行は、*ハイパーバイザー*によって構成させた*仮想マシン上のゲストOS*上で稼働させます。

他方コンテナの場合は、*ホストOS上のコンテナエンジン*で*コンテナ化したアプリケーション*を実行するだけです。そのため、ゲストOSのオーバーヘッドの影響を受けません。さらに、ゲストOSが起動しないため*起動時間が短縮*され、*メモリー消費量も節約*できます。

システム運用者のメリットとしては、運用の分担がしやすいことが挙げられます。具体的には、*仮想サーバー*の場合は*ホストOSとゲストOS*は*システム運用担当者が分担*するために、アプリケーション変更に伴い作業を*システム運用担当者と調整する必要*があります。*コンテナ*の場合は新たに*ゲストOSを仲介しない*ため、**開発者がコンテナ化したアプリケーションを実行するだけ**です。*DevOps*と呼ばれる開発と運用を連携させる開発手法においては**コンテナの採用率が非常に高まっています**。

### 代表的なコンテナソフトウエアは？

コンテナエンジンとしては、*Docker*が有名です。必要なコンテナソフトウエア機能が含まれますので、シングルノード環境でよく活用されています。しかし、利用が拡大してくると*コンテナ間で処理を連携するオーケストレーション*のニーズが高まってきました。

*Kubernetes*は*仮想サーバー間にまたがるコンテナを管理*し、*大規模システムに適したクラスターを構成可能*です。そのため、*コンテナオーケストレーション*を重視する場合は**Kubernetes利用者が多数を占めています**。

## AWSのコンテナサービスとは？

AWSでは、以下の**コンテナサービスを提供**しています。

・*Amazon Elastic Container Registry（Amazon ECR）*
　コンテナイメージの圧縮保存・管理・デプロイ
・*Amazon Elastic Container Service（Amazon ECS）*
　完全マネージド型のコンテナオーケストレーションサービス
・*Amazon Elastic Kubernetes Service（Amazon EKS）*
　完全マネージド型のKubernetesサービス
・*AWS Fargate*
　Amazon ECSとAmazon EKSで動作する、コンテナ向けサーバーレスコンピューティング

コンテナサービスの実際の利用方法については、以降で説明します。

### AWSのコンテナサービスの役割は？

AWSのコンテナサービスの役割は大きく、3つに分類されています。

（1）*レジストリ*
　各サーバーで実行するコンテナイメージを蓄積し、一元管理します。
（2）*コントロールプレーン*
　デプロイ・スケジューリング・スケーリングのオーケストレーション・アプリケーション管理を行います。
（3）*データプレーン*
　コンテナの実行環境、実行サーバーを指します。

コンテナではこの役割に応じて**処理を分担し連携動作させています**。

### AWSのコンテナサービスの区分は？

AWSの**コンテナサービスの役割区分に応じて**、以下のサービスを選択していきます。

・*レジストリ*
　Amazon ECRまたはDocker Hub等を利用して、コンテナイメージを蓄積します。通常AWSサービス連携性の高いAmazon ECRを選択するのが良いでしょう。

・*コントロールプレーン*
　Docker向けのAmazon ECS、またはKubernetes向けAmazon EKSを必要に応じ選択します。小規模なコンテナではAmazon ECS、大規模システムあるいはKubernetes愛好者はAmazon EKSを選択するのが良いでしょう。

・*データプレーン*
　Amazon Elastic Compute Cloud（Amazon EC2）を利用するか、サーバーレスであるAWS Fargateを選択します。お試しの場合はAWS Fargateを検討し、商用サービスで実行時間がそれなりに見込まれる場合はAmazon EC2を選択しましょう。

### AWSでのコンテナ活用方法は？

ここでは、**コンテナの代表的な活用例**について解説していきます。

・*アプリケーションの開発と運用*
　DevOpsのように開発と運用を協調して進める場合は、動作環境の調整や切り替えを円滑にする必要があります。この場合、コンテナを活用することにより開発と運用の効率性を高めることができます。

・*アプリケーションのクラウドへの移行*
　既存アプリケーションを異なる環境で動作させるには、アプリケーションのみならずランタイムや依存ライブラリーを準備する必要があります。これらのモジュールをパッケージ化することで、移行作業が大幅に簡素化できます。そのため、コンテナ活用によりクラウドへの移行性が向上するでしょう。

・*アプリケーション連携性の向上*
　コンテナのデプロイを用途に応じてオンプレミス環境とクラウドを使い分けし、コンテナのオーケストレーションにより処理に応じてスケールさせることが可能です。これにより、ワークフロー管理が効率的に実施できるでしょう。

・*アプリケーションのマイクロサービス化促進*
　従来のモノリシックアプリケーションをマイクロサービス化することで、よりコンテナオーケストレーションに適したモジュール構成をとることができます。将来に向けてアプリケーションの見直しを予定している場合は、コンテナの活用がより効果的でしょう。

AWSでは利用者のニーズに応じて、*豊富なサービス提供*を特徴としています。そのため、AWSでは初めて利用される方のために*概念や利用方法*を整理し、学習コンテンツとして提供しています。また、*スキルレベルに応じた学習コンテンツ*が用意されているので、*経験者*においても**チュートリアルが有効な学習方法**です。
参考：[AWS ご利用開始のためのリソースセンター](https://aws.amazon.com/jp/getting-started/)

この「*ご利用開始のためのリソースセンター*」の「*カテゴリ別のサービス学習*」に、「*コンテナ*」の情報が用意されています。このページでは、初心者からより深く学習する方を含めて「はじめに」「基礎」「学習リソース」「その他のリソース」と学習情報が整理されています。**これから学習を始める方はご一読をお勧めします**。
参考：[AWS カテゴリ別のサービス学習 コンテナ](https://aws.amazon.com/jp/getting-started/deep-dive-containers/)

さらに、*ハンズオンや動画*を*チュートリアル*として提供しています。内容は*10分程度から2時間以上*までの幅があり、*難易度に分けて学習コンテンツを提供*しています。
*AWSチュートリアル一覧*は「*ご利用開始のためのリソースセンター* 」の「*ハンズオンチュートリアル*」で表示されます。

「*コンテナ*」カテゴリでは、*クラウドレベル100（初心者）*向けコンテンツとして「*最新のアプリケーションを構築*」が用意されており、所要時間は2.5時間程度です。さらに、*クラウドレベル200（中級者）*向けコンテンツとして「*Kubernetes アプリケーションをデプロイ*」が用意されており、所要時間は30分程度です。*AWSにサインアップ*することで学習コンテンツが利用可能となります。その他に「*コンピューティング*」カテゴリも**コンテナ構築では必要**となりますので、このチュートリアルをぜひご活用ください。
参考：[AWS ご利用開始のためのリソースセンター ハンズオンチュートリアル](https://aws.amazon.com/jp/getting-started/hands-on/)

## AWSのコンテナサービスを活用し更なる生産性向上を図ろう

AWSでは、*Amazon EC2*が主要なコンピューティングサービスです。ニーズの広がりに応じて、サーバーレスサービスとして*AWS Lambda*が用意されています。同様に、コンテナの利用者に対して*Amazon ECSやAmazon EKS*を提供、さらにサーバーレスコンテナの*Amazon Fargate*を用意しています。この*製品群は非常に多岐に渡ります*ので、*コンテナの活用*により**AWSのサービス利用が最適なものになる**でしょう。

AWSは豊富なサービス数が特徴で、ニーズに応じてさらにサービスを拡大しています。この記事では、コンテナの利用者ニーズを満たすAWSのコンテナサービスについてまとめました。また、初心者向けの学習手順やハンズオンについても解説しているので、ぜひ参考にしてください。

AWSは豊富なサービスが特徴で、Amazon EC2が主要なコンピューティングサービスです

コンテナサービスとして、AWSではDockerとKubernetes向けサービスを提供しています

コンテナ初心者から経験者を対象に、学習コンテンツ用チュートリアルが活用できます

AWSのコンテナについて初心者にも分かりやすく解説！

## ITパスポート試験合格に必要な問題集とは？

**ITパスポート試験の資格を取得することで、IT技術を利用する社会人・学生が身に付けておく必要のある「ITに関する基礎知識」を証明することができます。**ITに関する資格の中では最も初歩的な資格です。しかし、ITパスポート試験に合格するための必要な問題集について疑問を抱いている方は少なくないでしょう。

ここでは、ITパスポート試験の概要とITパスポート試験を突破するための勉強方法について詳しくご紹介します。

**ITパスポート試験とは、国家資格である「情報処理技術者試験」の1つです。通称「iパス」と呼ばれることもあります。**独立行政法人情報処理推進機構（IPA）が主催している試験で、IT資格の中では難易度が比較的低いため、若手の社会人や学生でも充分に合格を目指せます。

### ITパスポート試験を突破するための勉強方法

**未経験の方がITパスポート試験を合格するために必要な勉強時間は、100時間～150時間程度が目安と言われています。ITパスポート試験を突破するために必要となる教材の基本が「参考書」と「問題集」です。**

ITパスポート試験における対策の初期段階では、参考書を利用して基礎を固めることが重要です。参考書を利用すれば、忘れたときに素早く振り返ることができます。基礎固めが終わったら、実際のITパスポート試験の問題傾向を掴むために、問題集や過去問で対策を行いましょう。*他の資格試験と比較すると、過去問と同様もしくは似た問題が多く出題される傾向があります。*

## ITパスポート試験の試験概要

ITパスポート試験の勉強方法では、問題集・過去問を活用することが大切なことはご理解できたでしょうか。ここでは、ITパスポート試験概要について詳しく解説します。

### ITパスポート試験の出題範囲・合格点は？

**ITパスポート試験は「ストラテジ系」「マネジメント系」「テクノロジ系」から問題が出題されます。**それぞれの配分は、ストラテジ系35問程度・マネジメント系20問程度・テクノロジ系45問程度となっています。そのため、ITに関する知識だけではなく、*経営やマネジメントの知識も必要となるため注意が必要です。*

合格するには、それぞれの分野で基準点である*1,000点中300点以上、かつ全体で60%以上の得点率を取得する必要があります。*ITパスポート試験の**合格率は50％程度**で、上位資格である基本情報技術者試験の合格率は20%～30％程度であるため、比較的合格率は高いといえます。

### ITパスポート試験の試験日程・試験時間

**ITパスポート試験は、各都道府県で毎月数回ほど開催されています。試験会場ごとに、IPAの公式サイトから試験日程の確認が可能です。**地域によって異なりますが、試験は最低でも月に1回、多いと週に1回開催されていることもあります。そのため、仮に1度不合格であったとしてもすぐに再受験できるのがITパスポート試験の特徴です。

*ITパスポート試験の試験時間は120分です。また、問題数は100問なので「1問1分程度」で回答していく必要があるでしょう。*

### ITパスポート試験の受験方法とは？

**ITパスポート試験では、コンピュータを利用する「CBT（Computer Based Testing）」方式で試験が実施されます。**試験当日には試験時間になったら、指定されたパソコンで試験を受験します。問題は4つの選択肢の中から1つを選択する形式であるため、迷いが生じた問題があったら飛ばして先に進みましょう。

### ITパスポート試験の受験料・申し込み方法

**ITパスポート試験の受験料は、5,700円（税込み）です。支払い方法は、クレジットカード・コンビニ・バウチャーから選択することができます。**大人数で受験する場合には、バウチャ―で支払いを行うのがおすすめです。

また、ITパスポート試験の申し込み方法は、郵便・電話などでは対応していません。*公式サイトから登録を行い、試験に応募してください。申し込みを行ってからITパスポート試験の勉強をすると、モチベーション維持にもつながるためおすすめです。*合格発表は試験日から1ヶ月程度で、合格証書が発行されるのは2ヶ月後程度となります。

## ITパスポート試験合格におすすめな問題集は？

ここでは、ITパスポート試験におすすめな問題集を厳選して詳しくご紹介します。自分に合う問題集を見つけることが重要なので、自身のIT知識のレベル確認や勉強に割くことができる時間などを明確にしておきましょう。

**問題集を購入する前の注意点として、過去問のみで対応できる方も多いです。**これまでにも説明したように、ITパスポート試験では過去問と似ている問題が多く出題されます。そのため、参考書で基礎を固めて、過去問で演習を行うだけで合格できる方もいるでしょう。ITパスポート試験の過去問については、下記のサイトからダウンロードできます。また、解答も一緒にダウンロードできます。*しかし、デメリットは解答はあっても解説がついていないことです。そのため、解説が欲しい方は問題集の購入がおすすめです。*
（参考：https://www3.jitec.ipa.go.jp/JitesCbt/html/openinfo/questions.html ）

### キタミ式イラストIT塾ITパスポート令和03年

この書籍は、情報処理技術者試験向けの本「キタミ式イラストIT塾」の中のITパスポート試験向けの書籍です。**全ての解説がイラストを使いながら記載されているため、未経験の方でも理解しやすい本といえます。**この書籍を利用して勉強することで、問題が多岐にわたるITパスポート試験にとって大切な用語や計算に慣れることが可能です。

*また、過去問から抜粋した練習問題および解説も記載しているため、1冊でITパスポート試験の対策を行うこともできます。ITパスポート試験に関する書籍を探している方でどの本を選べばいいかわからない方におすすめの書籍です。*
（参考：https://www.amazon.co.jp/dp/4297117797/ ）

### 令和2-3年度版 ITパスポート試験 対策テキスト&過去問題集 (よくわかるマスター) 

この書籍は、2018年8月に改訂が実施されたシラバス「Ver.4.0」の内容を網羅している、ITパスポート試験に合格するための参考書の1つです。**AI・IoT・ビックデータ・クラウドなどの最先端IT技術の内容も盛り込んであるため、徹底的に対策することができます。他にも、近年注目されているセキュリティ技術の内容も豊富に掲載しています。**

また、800問の過去問を収録した問題集プログラムのCD-ROMも添付しています。*自動採点機能や詳細な解説も付いている*ため、ITパスポート試験の本番にしっかり備えることが可能です。さらに、*解説動画として「つまずきやすい10のポイント」を用意しており、書籍だけでは理解するのが難しい箇所を動画視聴でわかりやすく勉強できます。*
（参考：https://www.amazon.co.jp/dp/4865104208 ）

### 【令和3年度】 いちばんやさしいITパスポート 絶対合格の教科書+出る順問題集

**この書籍は、ITパスポート試験に短期間で合格するための対策本です。試験に合格することのみを目的に作成されているため、ITパスポート試験の資格がどうしても必要な方におすすめといえます。**IT知識が全くないような未経験者・学生・新社会人の方でもスムーズに学習が進められるように、ITの初歩的部分から丁寧に本の中では解説しています。

また頻出の過去問を徹底解説して、厳選し掲載しているため、問題集としても活用することが可能です。*さらに、読者専用のWebサイトもあり、サポート体制も万全で疑問や質問があったら回答してもらうことができます。モチベーションを維持した状態でITパスポート試験に合格することができるでしょう。*
（参考：https://www.amazon.co.jp/dp/4815608776/ ）

### 徹底攻略ITパスポート教科書+模擬問題 令和3年度 (徹底攻略シリーズ) 

**この書籍は、ITパスポート過去問題集に関して実績豊富な著者が丁寧に解説しています。**デジタルトランスフォーメーション・スマートファクトリーなどの、最新のITパスポート試験で出題されたことのある問題も記載されています。*また今後の試験の出題予測も行っており、模擬試験も用意されているため、徹底的にITパスポート試験の対策をすることが可能です。*

加えて、過去問題集と解説によって理解度をきちんと高めることもできます。この書籍を活用することで、ITパスポート試験に合格できる自信が身に着けられるレベルに達することができるでしょう。

（参考：https://www.amazon.co.jp/dp/4295011029/ ）

## 問題集を効率よく利用して、ITパスポート試験を突破しよう！

これまでに、ITパスポート試験に合格するために必要な問題集について徹底的に解説しました。また、ITパスポート試験の試験概要についてもご紹介しました。**ITパスポート試験に合格するためには、「参考書」と「問題集」を活用することがおすすめです。ただし、問題集の代わりに過去問を解くだけでも十分に対応できる方も少なくありません。**そのため、自分が求めている問題集を見つけることが重要です。例えば、解説が必要な場合や、模擬試験が必要な場合などが挙げられます。*近年では多種多様なITパスポート試験対策本があるため、自分に合った書籍を見つけましょう。*

ITパスポート試験に合格するためには、「参考書」と「問題集」を活用することがおすすめです。当記事では、ITパスポート試験に合格するために必要な問題集について解説します。また、ITパスポート試験の試験概要についても併せて紹介します。

ITパスポート試験とは、国家資格である「情報処理技術者試験」の1つ

ITパスポート試験を突破するために必要となる教材は「参考書」と「問題集」

問題集がなくても過去問のみで対応できる可能性もある

ITパスポート試験に合格するための必要な問題集は？試験概要も紹介

## コードレビューにおける重要な観点

**コードレビューとは、作成したソースコードをレビューすることで、記述ミスやバグがないかを確認する作業のことです。**プログラムの品質を向上させるために、必要不可欠な工程といえます。ここでは、コードレビューの重要な観点を把握するために、まず概要や目的について詳しくご紹介します。

**端的に説明すると、コードレビューは記述したソースコードを自分以外の誰かに問題ないかを確認してもらうことです。**レビューを行う側の人を*レビュアー*、レビューされる側の人を*レビュイー*といいます。レビュアーは複数いる場合もあります。

*システム開発の際にコードレビューはよく実施されます。*例えば、システムの品質を担保するために、レビュアーの許可がない場合にはコードを修正することができない、というルールを作るプロジェクトもあります。プロジェクト発足した最初に、レビューのルールを決めることが一般的です。

**コードレビューの大きな目的は、システム品質の向上です。**レビュアーに作成したコードに対して指摘してもらうことで、コードをより良い方向に修正することが可能です。例えば、人間がコードを記述する場合、ケアレスミスは必ずといってもいいほどあります。そのため、*コードレビューを行うことで客観的にコードを見てもらえるため、ケアレスミスに気づきやすく*、結果としてシステム品質の向上が期待できます。

**また、コードレビューは新人教育のために実施されることも多いです。**新人社員の場合、実務経験が豊富な上司と比較するとコードの実装スキルがありません。そのため、ソースコードを読む作業を通じて、新人社員はコーディングについて多くのことを学ぶことができます。例えば、他人のコードを読むことによって「コードの設計」「コードの書き方」「フレームワークのスキル」などを勉強することが可能です。*コードレビューを通じて開発者の意図を学べるため、スキルアップにつながります。*

新人社員の場合はコードを丁寧に読むことが多く、実務経験が豊富な社員だとコードレビューを行うことに慣れていることが多いため、ケアレスミスを見逃してしまうこともあります。そのため、新人社員がコードレビューを行うことで小さなミスを拾えることもできるので、**新人教育も兼ねてコードレビューを行うことも少なくありません。**

**コードレビューの目的が理解できたら、次は方法が重要です。**コードレビューの方法はプロジェクトによって異なることも多く、ここでは一般的なコードレビューの方法について詳しく紹介します。例外もあるので、注意が必要しましょう。

**コードレビューをする際のコメントは、主にレビュイーが対応しやすいように記述します。**そのためには、行間のない短文で理解しやすいコメントが大切です。*コメントは、対応必須の「MUST」とレビュアーの意見「IMO（In My Opinion ）」の2つに分類するとよいです。*また、細かい指摘を行う項目など他の要素を使うこともあります。

**コードレビューにおけるコメントは、コミュニケーションの一貫にもなります。**そのため、コミュニケーションがスムーズになるようなコメントの仕方も大切です。文字のみだけではなく、絵文字や記号を使用することもプロジェクトによってはあります。

*また、コードレビューでは相手の良い点を褒めることも大切です。*例えば、上司がレビュアーで新人社員がレビュイーの場合に、新人社員が成長した点をコメントしてあげると、新人社員のモチベーションアップにもつながります。*またコメントをメンバーに共有することで、チーム全体の学びにもなるでしょう。*

**レビュアーがコードレビューの際にコメントを記載するときは、理由や根拠もきちんと記述しましょう。**コメントで「〇〇に修正してください」だけだと、レビュイーは「なぜ？」と疑問を抱いてしまうことがあるので、*根拠を示すことで新人社員の学びにもつながります。*インターネット上の信用できる参考文献を利用して、コメントをした理由を記述しましょう。

### 進捗に応じて確認するポイントを変える

**進捗状況によって、コードレビューをするポイントを変えることも重要です。**作業途中のコードを「WIP」として、プルリクエストを出す方法もあります。WIPとは、「work in progress」の略称で、進行中や作業中のことを指します。プルリクエストとは、コードの修正をレビュワーに通知して、マージを依頼することです。*WIPの場合は、変更の前提となるところを重点的に確認します。*

例えば、コードの設計や実装の方針について問題はないかを確認することが多いです。また、この段階では細かい部分の指摘は不要です。コーディングが完了した後に、細かい部分についてもレビューを行います。

### マージ後でも修正可能かを意識する

**マージを行った後でも、修正可能かどうかを意識することは大切です。**レビューの修正はマージを実施した後でも少ない工数で修正することができます。一方、データベースの変更は修正するための工数が大きくなるので、マージ後に修正が大変かどうかを意識してレビューを行うことも重要です。

### 口頭でのレビューも利用する

**コメントのみでのレビューが難しいこともあります。その場合は対面レビューの口頭でレビューを行うことがおすすめです。**ただし、指摘内容についてはコメントとして残しておいた方が、後でエビデンスとして活用できます。また、プロジェクトメンバーに共有することもできるので、チーム全体の学びにもつながるでしょう。

### コードレビュー観点のチェックリストを用意する

**コードレビューをする際には、チェックリストの準備も大切です。**チェックリストを用意することで、*コードレビューする際の抜けや漏れを減らすことができます。*また、コードレビューをどのような観点で行うか、チームで認識合わせが可能です。

**コードレビューは、工数やコストが多くかかることも少なくありません。**近年ではIT人材の人手不足が深刻化していることもあり、納期などの問題からコードレビューができないことも多いです。品質を一定に保つためには、レビュー効率を上げる必要があります。*ここからは、レビュー作業の効率向上に用いられるコードレビューツールを2つご紹介します。*他にも多数のコードレビューツールが存在しているので、ぜひニーズに合うツールを探して利用してみましょう。

**GitHubには、プルリクエストの画面にコードレビューのツールがあります。**無料でも使用できますが、データ量やアクション数などに制限があるため、企業単位でツールを活用する場合には有料プランの選択がおすすめです。GitHubを利用することで、レポジトリへのアクセス権があるメンバーに対して、プルリクエストごとにレビュアーとして割り当てることができます。プルリクエストを行ったエンジニアは、管理者に対してコードレビューの依頼が可能です。

*コードレビューツールを活用すれば、Gitにおけるコンフリクトをインターフェース上で解決できます。また、追加したレビューツールと統合させることもでき、レビュー機能を拡張することも可能です。*したがって、GitHub付属のコードレビューのツールは、すでにGitHubを利用している場合には、追加のインストールや設定が不要なことから最適なツールといえます。

**Review Boardとは、オープンソースのコードレビューツールで**コードとドキュメントのレビューができます。また、コードの比較を画面でわかりやすく表示することもできます。さらに、Webサイト上で試験版を利用でき、ソフトウェアをインストールして自身のサーバーで設定することも可能です。

*Review Boardはオープンソースということもあり、バージョンは日々更新されているため、使いやすいツールに日々発展しています。*また、Review Boardは他のツールと比較して学習曲線が緩やかなことも特徴です。

## コードレビューはシステム開発において大切な工程の1つ！

これまでに、コードレビューの詳細・やり方・ツールについて詳しく解説しました。コードレビューとは、記述したソースコードを他の方が問題ないか確認する作業のことです。**コードレビューの最大の目的はシステム品質の向上です。また、新人社員の教育としてコードレビューを利用することもあります。**

**コードレビューのやり方として、コメントの仕方が特に重要です。**コミュニケーションの一貫ともなるので、コメントで絵文字の活用や対面レビューもおすすめです。また、コメントではよかった点について積極的に褒めてあげましょう。*近年ではコードレビューツールも多くあるので、コードレビューに割ける時間がない方はぜひニーズに合わせて活用してみてください。*

コードレビューとは、記述したソースコードを自分以外の誰かに問題ないかを確認してもらう作業を意味します。また、コードレビューの最大の目的はシステム品質の向上で、新人社員にも任されることが多いです。当記事では、コードレビューの重要な観点について詳しく解説します。

コードレビューとは、記述したソースコードを自分以外が問題ないか確認する作業のこと

コードレビューの最大の目的は、システム品質の向上

コードレビューツールを利用することでレビューの効率の向上が期待できる

コードレビューの観点とは？やり方や便利なツールについても紹介！

## クラウドサービスとAWSのメリット

AWSのメリットを知る前に、*クラウドコンピューティングとAWSの関係、AWSの特徴*について確認しておきましょう。

### クラウドコンピューティングとは

**「クラウド コンピューティング」はサーバー・ストレージ・データベース・ネットワーク・ソフトウェアなどをインターネット（クラウド）経由で提供するコンピューティングサービスのこと**です。提供形態としては、パブリック クラウド・プライベート クラウド・ハイブリッド クラウドの3つのパターンがあります。

企業や個人を問わず、*不特定多数のユーザー*に対して提供するクラウドサービスのことです。

企業などが*自社専用のクラウド環境*を構築して、社内やグループ会社にクラウド環境を提供する形態です。パブリッククラウドにもさらに2パターンあり、自社内でインフラの構築や運用を行う「オンプレミス型」と、クラウド事業者から自社専用のインフラをサービスとして提供を受ける「ホステッド型」があります。

*「パブリッククラウド」と「プライベートクラウド」を組み合わせて利用*するクラウドコンピューティングの形態で、それぞれが持つメリットを活かし、補完しあえるという特徴があります。

クラウドサービスには提供するサービスの範囲として、次の3パターンがあります。AWSの中心はIaaSです。

*1.Infrastructure as a Service（laaS）*

サーバーやストレージ、ネットワークなどの**インフラ部分のみを提供するクラウドサービス**です。インフラ以外のOSやミドルウェア、アプリケーションなどのソフトはユーザー側で用意し、インストールした上で利用します。

サーバーやネットワークなどの**プラットホームに加え、OSやミドルウェアまでを提供するサービス**の形態です。アプリケーション以外の環境が整っているため、ユーザーはソフトウェア開発に専念できます。

**プラットホームやミドルウェアに加えてアプリケーションまでを含むクラウドサービス**で、ユーザー側で用意するものは特にありません。代表例としてMicrosoft Office 365やSalesforceなどが挙げられます。

AWSは世界最大の通販サイト**Amazon社が提供する世界最大のクラウドサービス**で、「*Amazon Web Services*」の略称です。Amazon社が自社のサイト「Amazon.com」運営ノウハウを活用し、2006年7月に一般公開されました。

AWSは、*Amazonの利益の半分以上をAWSが稼いでいます*。2020年の第4四半期でシェア32％を獲得しており、売上も前年同期比で28％増加するなど依然好調をキープしています。AWSが独り勝ちの理由としては、他の企業に先駆けて2006年からサービスを提供していることが大きいでしょう。

AWSは*世界25 のリージョンに 80 のアベイラビリティーゾーン（データセンター）を展開*し、個人やスタートアップ企業から大企業・米国政府機関・日本政府まで100万以上のユーザーがAWSを利用しています。

AWSは約90のサービスが提供されています。その内の主要なサービスは、**AWSアカウントを取得すれば直ちに利用することができます。AWSアカウント自体は無料で作成が行え、個人でも取得できます**。AWSの主要サービスであるAmazon EC2やAmazon S3などには一定の条件で*無料利用枠*が設けられ、1年間（12カ月間）サービスの利用料金がかかりません。

例えば、仮想サーバーを利用したい方はAmazon EC2を月間750時間×12カ月間無料で利用できます。また、ストレージサービスであるAmazon S3はストレージを5GBまで12カ月、データベースサービスのAmazon RDSも12カ月無料で利用が可能です。

すなわち、*お試しの利用からシステム構築までの12カ月間、ほぼすべて無料で利用できるという点がAWSの人気の秘密*と言えるでしょう。 

AWSにはさまざまなメリットがありますが、ここでは代表的なメリット3つを挙げてみました。

### *1.初期コストを抑えられる*

サーバー構築を自前で行うオンプレミス環境の場合、必ず初期コストが掛かりますが、クラウドサービスの場合は**基本的に初期コストは最小限で済み、単期間でのスタート**ができます。

しかし、クラウドサービスの基本であるIaaS（Infrastructure as a Service）の場合、提供されるのは仮想サーバーやネットワークなどのインフラだけであり、OSやミドルウェアなどは別途ライセンス費用が発生します。

自前でコンピューター設備を保有する*オンプレミス環境*では、サーバーのダウン・ハッキングなどのリスクによる損失や被害はすべて*自己責任*です。それを避けるためにはある程度の投資を行って、災害対策・セキュリティ対策を施さなくてはなりません。AWSに移行することで、こうした責任の多くがAWSに移転します。すなわち利用者側から見ると**AWSはリスクヘッジとなり、AWS側の責任による事故や問題はAWSが補償してくれる**のです。

### 3.スケーラビリティが担保される

オンプレミスでは、事業拡大に伴うデータ量の増加への対応として、サーバーやストレージ増強などを自前で手配しなければなりません。それに合わせて**サーバーの増強、リブレイスといった対応を迫られますが、AWSでは企業側はその心配がほぼ不要**となります。

もちろん、*AWSは従量課金制を基本*としていますので、データ量の増加などに伴いランニングコストは増加しますが、*サーバーがキャパシティオーバーでパンクするといった心配をする必要がありません*。

AWSは利用のメリットが大きく優れたサービスですが、あえて挙げるなら以下の*2つのデメリット*があります。

### 1.ランニングコストは決して安くない

初期コストの安さがAWSの大きなメリットですが、反面AWSのランニングコストは決して安くはありません。2万円のプリンターのインク代が年間1万円も掛かったという話と似ています。

**AWSは装置産業でもあり、自前で大きな投資を行って利用者を増やし、ランニングで利益を上げるという収益モデルになっている**からです。しかし、AWSの大きなメリット部分を費用換算してみると、オンプレミスよりもコストが安いことが分かります。

オンプレミスでは、*家賃・水光熱費・人件費・セキュリティ対策費用・災害対策費用*などが掛かります。*AWSの料金の中には、これらの項目がすべて包含されている*ことを見落とすべきではありません。そこを見誤ってしまうと、「AWSは高い」というAWS批判に与することになってしまいます。

### 2.AWS利用はコスト削減の手段ではない

AWSは箱（ハードウェア）は用意してくれますが、中身（ソフトウェア）は基本的にユーザーが用意（負担）します。

AWSを利用すれば、情報システム部門の縮小ができると考える経営者がいますが、あくまでもAWSが提供するのはインフラであり、情報システム自体は企業側が用意すべきものです。

また、そのコンテンツ（情報システム）については企業側が全責任を負う必要がありますので、AWSの利用が必ずしもコスト削減に繋がるわけではありません。

AWSのメリット・デメリットについて解説しましたが、AWSのメリットを最大限活かすことがデメリットを帳消しにする方法です。ここでは、AWSの効果的にな利用方法について解説します。

### AWSの拡張性を活かしてスモールスタートする

AWSのメリットである*拡張性（スケーラビリティ）*を活かしましょう。システムはスモールスタートし、完成度が高まった時点で全面稼働するという方法を採用することがあります。

また、成長途上の企業では、拠点数・利用者数・データ量などが急激に増えていくケースもあります。

オンプレミスの場合は頻繁にハードウェアの拡張をすることが難しいため、導入段階から3年～5年先を見据えて高スペック、高容量のサーバーやストレージを導入しがちですが、**AWSでは途中で簡単に拡張が行えるため、費用を抑えてスモールスタートをさせることが可能**です。

### AWSの可用性を活かし障害や災害に備える

企業の基幹システムは、あらゆる事態の中でもシステムを稼働し続けなくてはなりません。AWSでは、前述のとおり2021年3月時点で25リージョン、80カ所のアベイラビリティーゾーン（データセンター）を展開しており、それらの拠点を**ディザスタリカバリ（災害対策）センターとして利用することが可能**です。

これにより、*大規模災害への備え*をすることができ、稼働率確保や耐障害性の高いシステムの構築が行えます。

### 無料枠を活かして開発期間を設ける

AWSには前述の通り、「無料利用枠」というものが設けられています。これを利用することで*自社システムとの相性確認や、稼働確認が容易*に行えます。さらに**新システムの開発環境としても無料で利用できる**のは大きなメリットです。

AWS利用者によるコミュニティとして、JAWS-UGがあります。JAWS-UGとは「AWS Users Group-Japan」の略称です。**JAWS-UGでは技術的な情報交換や相談**などが行えて、大変心強いコミュニティです。JAWS-UGに利用登録をすると、*「Ask An Expert」カウンターでAWSエキスパートに相談*も行うことができます。

ユーザーからの圧倒的な支持を得てクラウドサービスのトップを快走するAWSですが、今後もこの動きは止まらないのでしょうか？*AWSに転職してみたい・AWSの利用を検討しているエンジニアの方*のために、**AWSの将来性について考察**しました。

[企業におけるクラウドサービスの利用動向（総務省）](https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h30/html/nd252140.html)によれば、すでに利用している企業は約6割、利用予定企業を含めると7割を超えています。この割合は年々増加しており、**これからもクラウドは需要は高まっていく**と考えられます。

AWSは世界でのシェアがNo.1のクラウドサービスですが、*MicrosoftのAzure*や*GoogleのGCP*などがAWSを猛追しています。今後は、さらにその差を縮めてくることが予想されますが、これからは**クラウドサービスの使い分けや共存が主流**になってくるとの見方もあります。

それは	*マルチクラウド*と呼ばれる、複数のクラウドサービスを、それぞれの特性やメリットを上手に組み合わせるという考え方です。

例えば、MicrosoftのディレクトリーサービスAD「Active Directory」を採用している企業や、SaasでMicrosoft365を利用している企業は親和性や継続性を考慮するとMicrosoftのAzureが利用しやすいでしょう。このように*業務特性、システム特性などによって、1つの企業が異なるクラウドサービスを利用するマルチクラウドが増加*してきますので、AWSとAzureの共存共栄が続くと想定されます。

また、AWSは規模が大きいということだけではありません。既に数多くのサービスを提供していますが、**現在も新たなサービスが提供され続けており、AWSは常に進化**しています。

AIの分野においても個人が利用できるサービスを提供するなど、個人と企業を問わず期待が高まっており、これからもAWSはその期待に応えて成長発展を続けていくことでしょう。

世界最大のクラウドサービス、AWSは多くの個人や企業・組織が利用しています。ITエンジニアの皆さんもAWSの利用やAWSへの転職を検討している方はいるでしょう。今回は、AWSに興味がある方のために利用メリット・活用策・AWSの将来性などについて解説します。

AWSは世界最大の通販サイトAmazon社が提供する世界最大のクラウドサービス

AWSの利用にはさまざまなメリットがあり、そのメリットを理解した上で活用することが大切

AWSなどのクラウドサービスの利用は益々増加しており、AWSの将来性は高い

AWSのメリットは何？そのメリットを最大限活用してみよう

システム開発の中で、*要件定義フェイズの機能要件*は初期段階の工程です。ユーザー（顧客）がシステムの完成形に対して具体的なイメージを作り上げている場合は、この機能要件の洗い出しは容易ですが、基本的には具体的なイメージが無いという前提で進めるべきでしょう。以下、その具体的な手順を紹介します。

要件定義を行う前の段階では、ユーザーのシステムイメージはまだ漠然としています。まずは、その漠然としたものを具象化するためにシステム化の**背景・理由・目的を明確にします**。背景と目的がしっかり理解できていないと議論がまとまらず、要件を絞り込む際の判断材料が不足することになります。

背景や目的が明らかになったら、ユーザーが求める機能を1つずつヒアリングするところからスタートします。**ヒアリングした内容を文書・図・表にまとめ、具体的な画面や帳票のイメージを作成しながらユーザーの抱くイメージをより具体化**していきます。業務改善をメインとする仕組みであれば、現状の業務フローと導入後の業務フローを対比させるなどして、必要な機能を洗い出していきます。

**必要な機能を全て洗い出したら、その中から機能単位で優先度を付けていきます**。すべての機能を網羅できれば良いのですが、予算・納期・技術的な問題などの制約条件がありますので、すべての要求を飲むことは難しいでしょう。

機能毎に概算の工数や費用を提示し、カットする機能に対しては延期・機能縮小・業務の見直しなどの代替案を検討していきます。

予算が足らずに代替案を提示する場合は、開発フェイズを分けて予算確保が出来るという条件で2次フェイズに回すという方法が、ユーザーにも受け入れられやすくなります。

## 機能要件に書く項目と書き方

**機能要件はユーザー（顧客）とのヒアリングを通じて、聞き取り・確認を行いながら記述**していきますが、視点を外さず手順に気を付けて行ってください。

*1. ユーザー要求の背景や目的は何か*
ユーザー（顧客）の要求やニーズには必ず背景があり、目的があります。その点を理解しておかないと、認識のズレや齟齬を招く危険性があります。例えば、ユーザーから「顧客の買い物動向について、本社で前日の状況を翌日に把握できるようにてほしい」という要求があったとします。

その目的が、単に集計作業を軽減したいのか、或いは分析をしたいのか、報告用のレポートを作成したいのかによって実装する機能が異なっていきます。

また、それは非機能要件にも大きく関わってくることです。**ユーザーの要求がどのような背景から生じたのか、その目的や狙いは何なのか、ここで明らかにすることが大切です**。

*2. 必要な機能は何か*
ユーザー要求のレベル、温度感をつかむことは重要です。「システムに対して何か求めるものはありますか？」という問いに対して、「〇〇を実現してほしい」という要求が出された際、それは単なる願望レベルのものから、非常に強い要求であるものまで、温度差があると見なければなりません。**実装すべき機能は何か、可能であれば実装した方が良い機能はなにか、特に必要性のない機能は何かを正しく見極めることが重要**です。

*3. 機能要件の確定*
機能要件を確定するフェイズでは、その最終確定が難航するケースがあります。必要と思われる機能を正しく洗い出せたものの、全ての機能を実装すると予算内に収まらないという問題に直面した時です。

何を残し、何を削るのかをユーザーと話し合って決めるのですが、ユーザーにしてみれば、折角出した案や要求を断られるというのは大変残念なことです。削る場合はユーザーを納得させられる理由や代替案を示さなければなりません。**ユーザーの立場に立って、ユーザーが納得できる方策を詰めていくこと**が重要です。

機能要件を進める上で、ゼロから始めるというのは現実的ではありません。ネット上にアップされている**サンプルを参考にしてカスタマイズして利用**することをおすすめします。

機能要件一覧表については、これがベストだというものはありませんが、**独立行政法人の情報処理推進機構（IPA）が公表しているものが参考になる**でしょう。

[機能要件定義一覧表](https://www.ipa.go.jp/files/000046672.pdf)

若手プロマネの羅針盤 運営事務局の記事、[要件定義における成果物一覧と書き方](https://pm-rasinban.com/rd-write)にも要件定義書サンプルがいくつか紹介されています。ぜひ参考にしてみてください。

また、同じく若手プロマネの羅針盤 運営事務局の記事、[機能要件・非機能要件の書き方【サンプル有り】](https://pm-rasinban.com/kinou-hikinou)に機能要件のテンプレートが用意されています。前述の記事で**要件定義について学び、その後にこちらの記事を参考に機能要件を策定する**と良いでしょう。

機能要件の書き方については理解されたでしょうか？機能要件は要件定義の重要な要素です。機能要件を正しく書けるようにするためには、要件定義について押さえておかなくてはなりません。ここでは要件定義について解説をします。

システム化において、**要件定義はユーザー（顧客）がシステム化に求めるものを明確にするものであり、システム開発側がユーザーの要求を正しく認識・理解する**上で、双方が*意識合わせを行う重要な工程*です。双方の意識合わせに重要なのは*機能要件*、非機能要件てあり、これらを正しく書けること、*書き方*を習得することが大切です。

精度の高い、正しい要件定義がシステム成功の鍵です。ここでは、要件定義をどのような手順で行うのかについて押さえておきましょう。以下、要件定義の基本的な流れについて解説します。

*1.ユーザー要求のヒアリング*
基本的に多くのITベンダーでは、最初に営業担当がユーザー（顧客）を訪問して、システム化に対する要求事項をヒアリングし、大まかな要件を確認することでシステム案件がスタートします。

この後、システムエンジニア帯同で改めて詳細のヒアリングを行い、*ある程度の要件定義を行って提案書作成し、提示*します。

お役立ち記事