# インフラエンジニアとは？
ITエンジニアと一口に言ってもたくさんの種類があります。

システムエンジニア（SE）、プログラマー、Webエンジニア、AIエンジニアなどエンジニアにも様々な種類がありますがその中でも、本日はインフラエンジニアとは何かについて共有します。

インフラエンジニアについて調べてみると「やめとけ」、「きつい」などのネガティブなワードが出てきますが実際はどうなっているのかを調査しまとめた結果について

インフラエンジニアがどんな職業なのかについて何か学びになればと思います。

### 目次

---

1. そもそもインフラエンジニアって？
    1. インフラとは
    2. インフラエンジニアの種類
2. インフラエンジニアの必要知識
3. インフラエンジニアに役立つ資格
4. 未経験からインフラエンジニアになるには？
    1. インフラエンジニアに転職するには？
5. インフラエンジニアに向いている人は？
6. インフラエンジニアの平均年収
7. インフラエンジニアの将来性

### 内容

---

## 1. そもそもインフラエンジニアって？

---

### インフラって何？

「インフラ」は「**インフラストラクチャー**」の略語で、日本語で言うと「基盤」という意味です。私たちの生活で例えると「電気・ガス・水道」などの生活基盤は生活インフラに該当します。

ITの分野においては、施設、サーバーなどのハードウェア設備、ネットワークを構築するためのインターネットなどが「インフラ」に当たります。

### インフラエンジニアの種類

インフラエンジニアは大きく分けて「ネットワークエンジニア」「サーバーエンジニア」などの種類に分けられます。ネットワークエンジニアとサーバーエンジニアの総称をインフラエンジニアと呼ぶこともあります。

ネットワークエンジニアは、ネットワークの構築・運用・保守が主な仕事で、コンピュータなどの端末同士を接続し、ネットワーク環境の構築などを行います。ルータやスイッチなどの物理的なネットワーク機器に触れる機会が多いといった特徴があげられます。

サーバーエンジニアは、サーバーの構築・運用・保守が主な仕事ですが、ネットワークエンジニアの業務領域の一部に特化した職種であるともいえます。（サーバーとは、インターネット上で他のコンピュータなどの端末に情報やサービスを提供するコンピュータのことです。）

サーバー機器をラックに固定するラッキングや、他の機器と接続するためにケーブルで配線を行ったりと言った物理的な作業も発生します。運用においては、24時間365日サーバーを稼働させなければならないため、何か障害が発生したときは休日や深夜問わず対応しなければならないため比較的きついと言われる分野の職種であるといえます。

## 2. インフラエンジニアの必要知識・スキル

---

インフラエンジニアに求められる知識やスキルは多岐に渡ります。

- **インフラ設計スキル**
    
    設計はインフラ構築において最初の段階で行う大事な過程にあたり、開発するシステムに最適なサーバーの選択やネットワーク構成を導き出す必要があるので、インフラに関する幅の広い知識や、以下に列挙する専門分野の詳細な知識が必要となります。
    
- **セキュリティ**
    
    近年はハッカーなどの攻撃者がオンライン上の顧客データなどを盗み悪用するといった事例も多くあります。大切なデータを盗まれ悪用されたとなると顧客との信用を失うという最悪の事態になってしまいます。
    
    そういった観点からも、インフラ設計を行う際はセキュリティリスクへの対策が非常に重要となるため、セキュリティに関する知識を身に着けることは必須といえます。
    
- **サーバー**
    
    サーバーにはサーバーOSが搭載されています。サーバーの運用や保守などの業務を行う必要があるため、扱うサーバーのOSにより違いはありますが、Linux・Unix・Windowsの知識やサーバーへの深い知識が必要となります。
    
- **ネットワーク**
    
    ネットワークの構築などの業務を行ったり、負荷分散（ネットワークの負荷がなるべく均等になるように処理を分散して割り当てること）を考えた設計を行う必要があるので、ネットワークに関する深い知識が必要となります。ネットワークは、専門用語も多いため、まずは基礎的な知識を固めるのが良いでしょう。
    
- **プログラミング**
    
    シェルスクリプトやPowerShellなどのプログラムを使用し、サーバーなどの構築を行うため、Linuxのシェルの知識があると仕事の幅が広がります。
    
- **クラウド**
    
    従来はオンプレミスといわれる自社で物理的にサーバーを運用するスタイルが当たり前でしたが、近年は、クラウド上で論理的にサーバーを構築するといったスタイルが主流となってきており、既存のシステムをオンプレミスからクラウドへの移行する、もしくは、クラウド上で開発する前提でシステムを構築することも多いため、Amazon Web Services(AWS)やMicrosoft Azure, Google Cloud Platformなどの各クラウドの知識を求められる機会は増えていきます。
    

## 3. インフラエンジニアに役立つ資格

---

必須というわけではありませんが、インフラ系の資格を通して実務に役立つ基礎知識が習得できます。転職の際やキャリアパスの一環として取得しておくと自身のスキルの証明になります。

- 基本情報技術者試験
    
    基本情報技術者試験は、エンジニアを目指す上での登竜門のような国家資格です。合格率は平均25％となっており、少し難しい試験と言えます。資格取得に向けて学習を進めることで、サーバーやネットワーク、セキュリティにおいての基礎知識を手広く身に着けることができます。
    
- 応用情報技術者
    
    応用技術者試験は、基本情報技術者試験の上位資格となっており、高度IT人材としてのレベルアップを図ることができます。合格率は平均して20%前半で、難しい試験と言えます。
    
- LinuC
    
    LinuCとは、Linuxに関する日本独自の民間資格で、NPO法人LPI-Japanが認定を行っています。Linuxサーバーの構築と運用に関する知識が求められ、学習を進めることでOSの技術者としてのスキルを磨くことができます。インフラエンジニアの中ではサーバー系の資格に当たります。LinuCは三つのレベルに分けられており、未経験の場合はまずはLinuC-1の取得を目指すと良いでしょう。LinuC-3を取得できるとスペシャリストとして認定され今後の活躍が見込まれます。
    
- **LPIC**
    
    LPICとは、LPIというNPO法人が主催する資格試験のことを指します。
    LPICを取得することにより、
    
    **自身のLinuxに関するスキル**を証明することができます。
    この試験はLinuxに関する試験の中でも国際的に標準となる資格です。つまり、LPICという資格は日本国内だけではなく**海外でも自身のスキルを証明**するものとしても通用します。
    
- **ネットワークスペシャリスト**
    
    ネットワークスペシャリストは、ネットワークの技術や構築から運用といった深い知識が得られる資格です。設計やセキュリティなどの網羅的な知識が問われます。位置付けとしては応用情報技術者試験よりも上位の資格となっております。合格率は12%〜15%と非常に難しい試験となっております。
    
- データベーススペシャリスト
    
    データベーススペシャリストは、データベースの企画・要件定義・開発・運用・保守などの総合的な知識が問われる資格です。こちらの試験もネットワークスペシャリストと同様に応用情報技術者試験よりも上位の資格となっており、受験者は実務経験のあるインフラエンジニアが多くを占めているにもかかわらず、合格率は10%と低く、非常に難しい試験であると言えます。
    
- **AWS認定**
    
    AWS認定資格はAmazonが提供しているクラウドの専門知識が問われる資格です。基礎コース、アソシエイト、プロフェッショナルの三段階に分かれています。未経験の場合はまずは基礎コースの、AWSクラウドプラティショナーの取得を目指すと良いでしょう。またAWS認定資格は世界共通の資格で、知名度も高いため転職にも役立ちます。
    
- **CCNA**
    
    シスコ技術者認定（CCNA）は、ネットワーク機器の業界大手であるCisco社によって認定される資格です。試験においてはCisco社の製品やネットワークに関する基礎知識が必要となります。
    

## 4. 未経験からインフラエンジニアになるには？

---

インフラエンジニアに限らずIT業界は人手が問題となっているため、未経験歓迎の企業なども多いのが現状です。採用の可能性が上がるので、未経験者は独学やスクールで知識をつける、明確な志望動機を準備した上で求人に応募してみましょう。

業務は保守や運用の業務からスタートするため学ぶ時間も確保できます。WebエンジニアやSEなどのプログラマーはプログラミング言語をある程度扱えないと仕事になりませんが、インフラエンジニアの場合は業務から学ぶことができます。

デメリットとしては、未経験から始めた場合給料が少なく、勉強量が多いなどの点が挙げられますがこれは他のエンジニア業に就いたとしても共通して言えることです。慣れるまではきついですが、資格を取得するなど前向きに頑張れば給料も上がっていきますし、フリーランスになれるほどの実力を付ければ良いだけの話ですので金銭面はさほど問題ではありません。

以上のことから未経験でもインフラエンジニアになるチャンスは十二分にあると言えます。

## 5. インフラエンジニアに向いている人は？

---

- 機械が好きな人
インフラエンジニアの業務には機械の操作も含まれるため、機械を触るのが好きな人が向いていると言えます。自分で機器を設置したり、配線作業を行うことも多いです。
- 縁の下の力持ちタイプ
    
    インフラエンジニアの仕事は、縁の下の力持ちのようにサービスの裏側で活躍します。地道なコツコツとした作業に忍耐強く取り組んでいける人が向いています。
    
- 細かい部分に気づける人
    
    インフラ領域は、細かいミスで正常に動作しなくなったり障害が発生したりするので、事前にしっかりとした準備ができたり、些細な点を大事にできる人が向いていると言えるでしょう。
    
- コミュニケーション能力が高い人
    
    インフラエンジニアは、インフラ構築時は顧客の要件を正確に聞き取り、障害が発生した場合は状況を正確に説明できるスキルが求められます。普段の業務もチームで行うため、メンバー間で円滑なコミュニケーションが取れると良いでしょう。
    

逆に向いていないのは、業務において大雑把であったり夜勤や急な障害対応をなるべく避けたいという方は悪いですが、向いてないと言わざるをえないでしょう。

## 6. インフラエンジニアの平均年収

---

転職サイトdodaの[平均年収ランキング](https://doda.jp/guide/heikin/syokusyu/)によると、インフラエンジニアの平均年収は435万です。男性で平均455万、女性で361万です。以下は年代別の比較表です。

| 年代別 | 年収 |
| --- | --- |
| 20代 | 370万 |
| 30代 | 506万 |
| 40代 | 614万 |

[年代ごとの平均年収データ](https://doda.jp/guide/heikin/age/)によると、20代の平均年収は341万、30代で437万、40代で502万となり、平均値から見てもインフラエンジニアの平均年収は高くなっています。プログラマの平均年収は400万となっており、そちらと比較した場合でも、インフラエンジニアの年収は55万も高いことがわかります。

上記のデータはあくまで平均的なデータです。インフラエンジニアは実力主義のため、常にスキルアップを意識し勉強を続け、資格取得することで年収を大幅アップさせることも可能です。例えばCiscoのCCIEというネットワーク系の高難易度の資格を保有しているインフラエンジニアの年収は750万だと言われています。

## 7. インフラエンジニアの将来性

---

IT化が推進されている現代で、インフラエンジニアの需要は今後も高まっていくでしょう。

クラウドが普及したことで、従来のオンプレミスでの構築からクラウドサービスへの移行が進んでいます。クラウドを扱うためにも基礎となるネットワークやサーバーの知識が不可欠です。

移行していくからといってインフラエンジニアの仕事がなくなるわけではありません。

最近では「ハイブリットクラウド」といってオンプレミスとクラウドを組み合わせて、自社内で抱えたい大事なものはオンプレミスで対応し、クラウドに預けるものはクラウドで構築するといった技術もあります。このの手法はそれぞれのメリットデメリットをうまく補い合うことが可能です。

### まとめ

---

以下は、インフラエンジニアについてまとめた結果です。

インフラエンジニアは、ITの基盤を支える縁の下の力持ちの大切な仕事です。未経験からでも基礎を十分に固めれば目指せる職種で、他のエンジニア職と比較した場合でも年収は高めです。人手不足やクラウドの需要が高まっていくことからインフラエンジニアの採用市場は青天井と言えます。将来性も高い仕事です。

### 宣伝

---

弊社では、インフラ学習サイトEnvader（エンベーダー）とITスクール（RareTECH）を運営しています。また、企業研修やシステム開発なども行っていますので興味がある方はHPよりご連絡下さい。

https://envader.plus/

https://raretech.site/

https://var.co.jp/

インフラエンジニアについて調べてみるとネガティブなワードが出てきますが実際はどうなっているのか気になりませんか？気になるインフラエンジニアのあれこれを紹介しておりますので、どんな職業なのかぜひ参考にしてみてくださいね

インフラエンジニアとは？

# インフラエンジニアの仕事内容について解説
インフラエンジニアの仕事内容について書いております。

インフラエンジニアがどういった業務に携わっているのかについて何か学びになればと思います。

### 目次

---

- インフラエンジニアとは (復習)
- インフラ基盤を構築する必要性
- インフラエンジニアの仕事の流れ
- インフラエンジニアのキャリアパス

### 内容

---

### インフラエンジニアとは

**インフラエンジニア**とは、主に**サーバー**というコンピュータや**ネットワーク機器**などを適切に設計・配置して**インフラ基盤**を構築し、それらが正常に動くよう管理していく仕事のことを指します。

例えばTwitterやLINEなど、私たちが普段当たり前のように利用しているアプリケーションも、先に説明したインフラ基盤がインフラエンジニアによって適切に管理されているおかげです。つまり、インフラエンジニアは様々なITに関わるサービスを提供する上で一番の基盤を築き、それを守る縁の下の力持ちのような存在と言えます。

インフラエンジニアに関する詳しい説明は、下記リンクの記事を参考にしてください。

https://envader.plus/article/2

### インフラ基盤を構築する必要性

なぜインフラエンジニアはインフラ基盤を作るのでしょうか。そもそもインフラ基盤はどのような用途に使用されているのでしょうか。この問いを理解することで、インフラエンジニアという仕事の意義と大切さについて理解することができます。

まず、インフラ基盤は主に以下の用途で使用されます。

・企業内の情報システム

・アプリケーションやシステムなどのサービス提供

・人工知能や統計分析

また、昨今では**DX化**が進んできており、ますます**デジタルデータ**という存在の大切さが顕著になっています。デジタルデータは主に企業や団体の管理するサーバーに保管されます。デジタルデータやそれを保管するサーバーを適切に管理し、うまく活用するにはきちんとしたインフラ基盤が必要となります。つまり、インフラ基盤を適切に管理するための人材が求められているわけです。以上の理由からインフラエンジニアはインフラ基盤を作り管理することが大切な仕事となっています。

### インフラエンジニアの仕事の流れ

インフラエンジニアがインフラ基盤を頼まれた場合には、以下の手順で仕事を進めていきます。

1. **設計**
2. **構築**
3. **運用・保守**

まず、**設計**工程ではインフラ基盤をどのように使うのかを定義します。この作業を**要件定義**と言います。要件定義はインフラ基盤が欲しいクライアント側(顧客)と何度も打ち合わせを重ねることで、クライアント側の望みを正確に言語化します。この作業には技術的な作業はあまり関係しませんが、先に説明した全工程の中で一番大事なものとなります。というのも、要件定義の段階でクライアント側の要望を間違って解釈してしまった場合、そのまま構築を始めてしまうと進捗が進めば進むほど、人件費などの関係上後戻りが難しくなります。

要件定義が終わったあとは、実際に**設計書**を作成します。具体的には、どのようなネットワーク機器や技術が必要なのかといった技術的な話も含まれます。設計書は要件定義で決めた内容を参考にして行います。

次に、**構築**工程ではインフラ基盤を実際に組み立てます。この作業を**環境構築**と言います。環境構築は設計書をもとに、実際にネットワーク機器の設置からサーバーの設定、ソフトウェアの導入などを行います。インフラ基盤の構築自体はこの作業で終わりで、あとは正常にインフラ基盤が動くかどうか**テスト**作業に入り、成功したら無事クライアント側に引き渡されます。

最後に、**運用・保守**工程では構築したインフラ基盤が維持できるよう管理します。インフラエンジニアの仕事は、インフラ基盤を構築して終わりではありません。構築したインフラ基盤は必ずしも永久にきちんと動くとは限りません。必ず不具合や障害などのトラブルが発生します。ですが、インフラ基盤が止まってしまったら、クライアント側が行いたい作業や提供したいサービスが正常に機能しなくなってしまいます。そこから出てしまう損失は、場合によっては非常に大きなものとなってしまう可能性もあります。したがって、インフラエンジニアがインフラ基盤を定期的に管理し、インフラ基盤の状態を監視する必要があります。それが運用・保守工程で行う作業です。

### インフラエンジニアのキャリアパス

現在、日本国内でIT人材は不足していると言われています。そのため、インフラエンジニアは仕事の経験がない業界未経験の人でも積極的に採用している企業が多いです。また、業界未経験の場合は研修期間を設けられ、平均で約2~3ヶ月企業の研修を受けてから実際に働くケースがほとんどです。

しかし、**未経験から良いキャリアを積むにはそれなりの期間と能力**を要します。したがって、きつい仕事をこなしつつ、**自分でも学習を重ねる**ほどのマインドを持った人がインフラエンジニアに向いていると言えます。逆に、与えられた仕事だけをこなすのに精一杯で自分で学習を積み重ねることのできない人は「やめとけ」と言われてしまうほどこの業界には適していないことになります。インフラエンジニアになるならば、それなりの覚悟を持つことをお勧めします。

インフラエンジニアには**上流工程**と**下流工程**というものが存在します。上流工程と下流工程は、先ほど説明したインフラエンジニアが働く工程を大まかに2つに区切ったものです。インフラエンジニアの仕事は設計から始まり、構築、運用・保守と決まった流れで進んでいきます。それを**川の流れ**のイメージで表し、言語化したものが上流(工程)と下流(工程)です。

まず、**下流工程**は主に**構築**や**運用・保守**を担当するエンジニアのことを指します。業界未経験の場合は下流工程の中でも最も下に位置する運用・保守を担当することになります。運用・保守で実務経験をして実績を積みつつ、自分でも学習を進めることで構築工程を任されるようになります。

次に、**上流工程**は主に設計の担当するエンジニアのことを指します。インフラエンジニアとしての経験量が多いと任されることが多くなる工程です。上流工程は直接クライアント側(顧客)とコミュニケーションを取る機会が増えるため、技術的な能力だけではなくヒアリング能力やコミュニケーション能力も必要とされます。そのため、上流工程に属するエンジニアは下流工程よりも単価がかなり高くなります。

インフラエンジニアとしての経験を積んだら、上流工程の他にも**プロジェクトマネージャー**という役職を目指すこともできます。プロジェクトマネージャーはインフラ基盤を作るといったひとつのプロジェクト全体を統括し、全体を上手く進めていくようサポートします。上流工程はあくまで設計工程などを担当するのに対し、プロジェクトマネージャーは上流工程だけではなく、下流工程も視野に入れて行動する必要があります。

### まとめ

---

以下は、インフラエンジニアの仕事についてまとめた結果です。

- DX化が進む今、それを支えるインフラ基盤を作ることのできる人材が必要とされている。
- インフラエンジニアの仕事の流れは**設計**、**構築**、**運用**・**保守**であり、それらは**上流工程**と**下流工程**という言葉で分けられている。
- 業界未経験の人は運用・保守から携わることになり、**仕事をこなしつつ自分でも学習**を進めて実績を積むことで、より上の構築や設計などのキャリアが目指せる。

### 宣伝

---

弊社では、インフラ学習サイトEnvader（エンベーダー）とITスクール（RareTECH）を運営しています。また、企業研修やシステム開発なども行っていますので興味がある方はHPよりご連絡下さい。

https://envader.plus/

https://raretech.site/

https://var.co.jp/

こちらはEnvaderの記事になります。

インフラエンジニアの仕事内容について解説

# インフラエンジニアに必要な資格（LinuC）
本日は、**LinuC**という自身のLinux能力を証明できる資格について共有します。

LinuCについて何か学びになればと思います。

## LinuCとは
[LinuC](https://linuc.org/)とは、LPI-JapanというNPO法人が主催する資格試験のことを指します。

LinuCを取得することにより、**自身のLinuxに関するスキル**を証明することができます。この試験はLinuxに関する試験の中でも国際的に標準となる資格です。つまり、LinuCという資格は日本国内だけではなく**海外でも自身のスキルを証明**するものとしても通用します。

## LinuCの難易度と出題範囲
LinuCの資格は**LinuCレベル1**, **LinuCレベル2**, **LinuCレベル3**といった3段階のレベルが用意されており、それぞれのレベルで出題内容や難易度が異なります。数字が増えていくにつれてレベルが上がります。

### LinuCレベル1
- 101は、[こちら](https://linuc.org/linuc1/range/101.html)参照
- 102は、[こちら](https://linuc.org/linuc1/range/102.html)参照

### LinuCレベル2
- 201は、[こちら](https://linuc.org/linuc2/range/201.html)参照
- 202は、[こちら](https://linuc.org/linuc2/range/202.html)参照

### LinuCレベル3
- 300は、[こちら](https://linuc.org/linuc3/300.html)参照
- 303は、[こちら](https://linuc.org/linuc3/303.html)参照
- 304は、[こちら](https://linuc.org/linuc3/304.html)参照


## LinuCの料金
LinuCには、レベル1・レベル2・レベル3があり、試験料金は以下のようになっております。

| 試験内容 | 料金 |
| --- | --- |
| LinuCレベル１（101試験／102試験） | 各16,500円（税込） |
| LinuCレベル２（201試験／202試験） | 各16,500円（税込） |
| LinuCレベル３（300試験／303試験／304試験） | 各16,500円（税込） |

LinuCの試験内容・料金について解説しました。

インフラエンジニアに必要な資格（LinuCについて）

# インフラエンジニアに必要な資格（AWS）
Amazon Web Services 認定資格について共有します。

Amazon Web Services (以下: AWS)とは、通販サイトとして有名なAmazonが提供しているクラウドサービスのことです。

クラウドやAWS認定資格について何か学びになればと思います。

### 目次

---

- クラウドとは
- AWSとは
- AWSの認定資格

### 内容

---

### クラウドとは

そもそも**クラウド**とは、外部からサーバーといったコンピュータ資源などを借りることで、それらを自分で用意することなく使用することができるものです。クラウドという言葉の由来には、自分の使っているものがどこにあるのか、どういう形をしているのかがまるで雲のようにハッキリと分からないことにあります。クラウドを使うことによる主な利点は以下の2つです。

1.　コンピュータなどを自分で購入する必要がなく、それを配置する場所も必要ないこと。

2.　必要な時に、必要なだけ使うことができる。

まず、1つ目の利点について説明します。

企業がシステムやアプリケーションなどのサービスを提供する場合、従来は自分でコンピュータを購入してそれをどこかに置く必要がありました。そのような用途で使われるコンピュータを**サーバー**と言います。また、サーバーを配置するために存在している施設を**データセンター**と言います。データセンターには人間の身長と同じくらいのコンピュータが何台も置かれています。

これらを動かすためには多くの電気を消費します。また、それらを置くために存在するデータセンターを維持するためには、土地代や改装費などの維持費もかかります。つまり、自分でデータセンターを構えて大量のサーバーを維持するには、莫大なお金がかかります。

そこで、**クラウドサービス**というものが登場します。クラウドを使うことで、外部の企業が用意しているコンピュータ資源を借りて、そこでシステムやアプリケーションなどのサービスを提供することができます。つまり、コンピュータ資源を借りるということは、自分でコンピュータを用意する必要がなく、それを配置するデータセンターなどの施設も必要ないということです。

次に、2つ目の利点について説明します。

クラウドのほとんどは**従量課金制**で使用料金が発生します。従量課金制とは、使った分だけお金が発生する仕組みのことです。また、コンピュータ資源などを使わなくなった場合には手数料などのお金がかかることなく、簡単に利用を止めることができます。つまり、必要な時に、必要なだけコンピュータ資源を借りることができます。

以上2つの利点から、クラウドを使うことによりコンピュータ資源の購入費用や維持費用を削減することができ、更にコンピュータ資源の使用量を増やしたり減らしたりしたい場合、すぐにそれを実行できます。したがって、クラウドサービスは現在、様々な企業や団体に使用されています。

### AWSとは

Amazon Web Services (AWS)とは、通販サイトとして有名なAmazonが提供しているクラウドサービスのことです。AWSには現在200を超える種類のサービスが存在しており、サーバーだけではなく管理不要のデータベースやアプリケーションを動かす基盤など、様々な用途に応じて最適なサービスを使うことができます。通常なら普段から定期的に管理が必要とされるサーバーやデータベースといったコンピュータ資源も、AWSの**サーバレス**や**マネージドサービス**を使えば管理の一部または全てをやる必要がなくなります。

マネージドサービスの例を1つ挙げます。例えば**リレーショナルデータベース**という、データを保管するために使用するサーバーがあります。そのサーバーでは定期的に管理者の手によって維持するためのメンテナンス作業をする必要がありました。しかし、**RDS**というリレーショナルデータベースのマネージドサービスを使うことにより、本来必要だったメンテナンス作業を自動化することができます。

これらのサービスを組み合わせることにより、効率的にアプリケーションなどのサービスを提供できるようになります。しかし、多くの種類が存在するサービスを適切に組み合わせて使用するには、それなりの知識と経験が必要となります。

### AWSの認定資格

AWSのサービスを適切に組み合わせて利用するには、AWSに関する知識と経験が必要となります。そしてそのようなスキルはクラウドを利用する企業において必要とされるものです。そこで、**AWS認定資格**を取得すれば、AWSのスキルを証明することができます。

AWSには全部で**11種類**の認定資格が用意されています。

認定資格の難易度は全部で4種類に分かれています。

| 難易度 | 必要な能力 |
| --- | --- |
| 基礎コース | AWSを用いた経験が6ヶ月ほどを想定。基本的な使い方の理解が必要。 |
| アソシエイト | AWSを用いた実務経験が1年レベル。問題解決能力が必要。 |
| プロフェッショナル | AWSを用いた実務経験が2年レベル。設計・運用・トラブルシューティングと言った包括的な経験と知識が必要。 |
| 専門知識 | 各専門分野に関する実務経験。専門分野に関する深い知識と経験が必要。 |

認定資格のうちアソシエイトとプロフェッショナルレベルでは、設計に関するアーキテクト分野、開発者に必要な能力に関するデベロッパー分野、管理者に必要な運用分野の3つに分類されます。また、専門知識レベルでは全部で5つの分野が用意されています。

| 難易度 | 資格名 | 分野 |
| --- | --- | --- |
| 基礎コース | Cloud Practitionaer | AWSの基礎全体 |
| アソシエイト | Solutions Architect Associate | アーキテクト |
|  | Developer Associate | デベロッパー |
|  | SysOps Administrator Associate | 運用 |
| プロフェッショナル | Solutions Architect Professional | アーキテクト |
|  | DevOps Engineer Profesional | デベロッパー・運用 |
| 専門知識 | Advanced networking | ネットワーク |
|  | Data Analytics | データ分析 |
|  | Database | データベース |
|  | Machine Learning | 機械学習 |
|  | Security | セキュリティ |

それぞれの資格の詳しい試験範囲は、下記AWS公式サイトの各試験の詳細から試験ガイドをご覧ください。

https://aws.amazon.com/jp/certification/exams/?nc2=sb_ce_exm

### まとめ

---

以下は、クラウドとAWSについてまとめた結果です。

- クラウドを使用することによる利点は2つある。
    
    1.　コンピュータなどを自分で購入する必要がなく、それを配置する場所も必要ないこと。
    
    2.　必要な時に、必要なだけ使うことができる。
    
- Amazon Web Services(AWS)というクラウドサービスでは200種類以上のサービスを提供しており、それらを上手く組み合わせることで効率的に自分のアプリケーションなどのサービスを提供することが可能になる。
- AWSを自分で考えて適切に使う能力が求められており、それを証明できるのがAWS認定資格である。

### 宣伝

---

弊社では、インフラ学習サイトEnvader（エンベーダー）とITスクール（RareTECH）を運営しています。また、企業研修やシステム開発なども行っていますので興味がある方はHPよりご連絡下さい。

https://raretech.site/

https://var.co.jp/

インフラエンジニアに必要な資格（awsについて）

# インフラエンジニアに必要な資格（CCNA）
本日は、**CCNA**と言う**自身のネットワークスキルを証明**できる資格試験について共有します。

CCNAについて何か学びになればと思います。

### 目次

---

- CCNAとは
- CCNAの難易度と出題範囲

### 内容

---

### CCNAとは

CCNAとは、**シスコ**という企業が主催する資格試験のことを指します。

CCNAを取得することにより、自身の**ネットワークに関するスキル**を証明することができます。

この資格試験はネットワークやセキュリティに関する知識だけではなく、シスコが開発したルーターなどのネットワーク機器の使い方に関する問題も出題されます。CCNAは**ネットワークエンジニア**や**インフラエンジニア**を目指す方にとっては登竜門と言われる資格ですが、難易度は決して簡単ではなく出題範囲も広いので、取得するには多くの学習時間を要します。

### CCNAの難易度と出題範囲

CCNAの試験で出題される範囲は他の試験よりも広く、試験時間も120分と長く設定されています。そのためCCNAはネットワークエンジニア・インフラエンジニアの登竜門と呼ばれるのにも関わらず難易度は高いです。CCNAが出しているCCNA試験v1.0(200-301)という資料によると、CCNAの大まかな範囲と全体におけるそれぞれの出題割合は以下の通りとなっています。

| 出題範囲 | 割合 | 大まかな内容 |
| --- | --- | --- |
| ネットワークの基礎 | 20% | ネットワーク機器の種類と特徴, ネットワーク設計, TCPとUDPなど |
| ネットワークアクセス | 20% | シスコのネットワーク機器の設定方法など |
| IPコネクティビティ | 25% | ルーティングテーブルの特徴, 設定方法など |
| IPサービス | 10% | NAT, DNS, DHCPなどのプロトコル |
| セキュリティの基礎 | 15% | 脅威, 脆弱性などの定義, 対策方法, セキュリティに関する設定など |
| 自動化とプログラマビリティ | 10% | ネットワーク管理の自動化, REST API, JSONなど |

参考: [CCNA 試験 v1.0（200-301）](https://www.cisco.com/c/dam/global/ja_jp/training-events/training-certifications/exam-topics/200-301-CCNA.pdf)

CCNAの出題範囲はネットワークの分野に限らず、セキュリティ分野や、JSON, REST APIなどのシステム開発に関わるプロトコルなどかなり広い範囲となっていることがわかります。

また、問題の出題形式は以下の通りとなっています。

| 出題形式 | 内容 |
| --- | --- |
| 1つ選択 | 複数選択肢の中から1つを選択する。 |
| 複数選択 | 複数選択肢の中から複数を選択する。 |
| ドラッグ&ドロップで分類分け | ドラッグ&ドロップで項目を動かし、それぞれを適切な場所に置いて分ける。 |
| 穴埋め | 空白箇所を記述して穴埋めする。 |
| 長文読解 | 長文から内容を理解し、設問に答える。 |
| ルータなどのシュミレーション問題 | まるで実機のような仮想の環境で、実際にルータの設定などを行う。 |

このように、問題の出題形式にも様々な種類が存在します。中には長文読解やルータなどのシュミレーション問題など、ただ知識を答えるのではなく実際の環境や文脈を通して状況を理解し、回答する問題が存在します。つまり、単純に答えを丸暗記するような付け焼き刃では合格するのは難しいと言えます。

### 対策

CCNAは出題範囲が広く、かつ出題形式も様々な種類があることから難易度が高い試験です。しかし、CCNAはあくまでネットワークに関する基礎能力を求める試験ですので、専門的な知識まではまでは求められません。つまり、CCNAに合格するには基礎を徹底的に叩き込むことが大事になります。

特に最初はネットワーク自体の基礎を理解することから始めることをお勧めします。
現在では、ネットワークの基礎を学ぶには以下のように様々な方法があります。

- 書籍を読む。
- CCNA対策のオンライン教材を使う。
- RareTECHなどのITスクールで講義を受ける。

このように様々な方法がありますが、まずは書籍から読むことでネットワーク全体の基礎を把握することが大切です。書籍は3000円以内で購入することができるので、金銭面で躊躇している人にとっても取り組みやすいものと言えます。以下にお勧めの書籍をリスト形式で挙げるので、興味のある方は是非調べてみてください。

- [ネットワークがよくわかる教科書](https://www.amazon.co.jp/%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E3%81%8C%E3%82%88%E3%81%8F%E3%82%8F%E3%81%8B%E3%82%8B%E6%95%99%E7%A7%91%E6%9B%B8-%E7%A6%8F%E6%B0%B8-%E5%8B%87%E4%BA%8C-ebook/dp/B07HHR6FPV/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&crid=2FHUW9ZR0Z2Y&keywords=%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E3%81%8C%E3%82%88%E3%81%8F%E3%82%8F%E3%81%8B%E3%82%8B&qid=1643614510&sprefix=%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E3%81%8C%E3%82%88%E3%81%8F%E3%82%8F%E3%81%8B%E3%82%8B%2Caps%2C180&sr=8-1)
- [マスタリングTCP/IP 入門編](https://www.amazon.co.jp/%E3%83%9E%E3%82%B9%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0TCP-IP-%E5%85%A5%E9%96%80%E7%B7%A8%EF%BC%88%E7%AC%AC6%E7%89%88%EF%BC%89-%E4%BA%95%E4%B8%8A%E7%9B%B4%E4%B9%9F-ebook/dp/B0827QNDNT/ref=sr_1_1?crid=C59ONAWKVBU3&keywords=%E3%83%9E%E3%82%B9%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0tcp%2Fip+%E5%85%A5%E9%96%80%E7%B7%A8&qid=1643614524&sprefix=%E3%83%9E%E3%82%B9%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0%2Caps%2C190&sr=8-1)
- [図解入門TCP/IP 仕組み・動作が見てわかる](https://www.amazon.co.jp/%E5%9B%B3%E8%A7%A3%E5%85%A5%E9%96%80TCP-IP-%E4%BB%95%E7%B5%84%E3%81%BF%E3%83%BB%E5%8B%95%E4%BD%9C%E3%81%8C%E8%A6%8B%E3%81%A6%E3%82%8F%E3%81%8B%E3%82%8B-%E3%81%BF%E3%82%84%E3%81%9F-%E3%81%B2%E3%82%8D%E3%81%97/dp/4815604975/ref=sr_1_1?crid=3BSB3U0HLDKY9&keywords=%E5%9B%B3%E8%A7%A3%E5%85%A5%E9%96%80+tcp%2Fip&qid=1643614545&sprefix=%E5%9B%B3%E8%A7%A3%E5%85%A5%E9%96%80%2Caps%2C203&sr=8-1)

また、CCNAに限らず言えることではありますが、試験対策はインプットだけに集中するのはあまり良いことではありません。定期的に問題集などを解くことによって、アウトプットも行うようにするとより良い効率で学習を進めることができます。

### まとめ

---

以下は、CCNAについてまとめた結果です。

- CCNAを取得することにより、自身の**ネットワークに関するスキル**を証明することができる。
- 出題範囲はかなり広く、問題形式も様々なことから難易度は難しいと言える。
- 範囲の広さに屈せず、ネットワークの基礎から勉強を始めることが大事である。
- インプットだけではなく、アウトプットも定期的に行うことが合格への鍵である。

### 宣伝

---

弊社では、インフラ学習サイトEnvader（エンベーダー）とITスクール（RareTECH）を運営しています。また、企業研修やシステム開発なども行っていますので興味がある方はHPよりご連絡下さい。

https://raretech.site/

https://var.co.jp/

インフラエンジニアに必要な資格（CCNAについて）

# 【わかりやすく解説】可用性とは？

こちらの記事では、「可用性」について解説します。

可用性は、「**システムが安定的に稼働し続けられる能力**」のことを指します。どんなに信頼性の高いシステムにも**絶対に落ちない**というシステムは存在しません。安定的にシステムを稼働するためにも、万が一障害などが発生した場合のことを考慮しておかなければなりません。

2018年に日本政府が公開した[政府情報システムにおけるクラウドサービスの利用に係る基本方針](https://cio.go.jp/sites/default/files/uploads/documents/cloud_%20policy.pdf)に可用性が取り上げられるなど、年々重要視されている「可用性」について分かりやすく説明していきます。

## 可用性の概要

可用性は、**Availability**（アベイラビリティー）の訳語です。可用性は、「可用性が高い、低い」という表現の仕方します。可用性が高い事を指して、**高可用性**（HA: **H**igh **A**vailability）と表す用語も使われています。

また、可用性は稼働率（%）で表す事ができます。例えば、あるシステムが10時間稼働した時に、「実稼働が6時間・稼働停止時間が4時間」だったとしたら、稼働率は60％と表す事ができます。

### システムの評価指標

**可用性はシステムやソフトウェアの品質を評価する際の評価指標の1つです**。システムの評価指標には可用性と似た用語も存在しており、同じような意味で捉えているケースも見受けられますので、一度整理しておきましょう。

| 評価指標の用語 | 評価指標の訳語 | 用語の説明 |
| --- | --- | --- |
| Reliability | 信頼性 | 故障しにくいこと |
| Availability | 可用性 | 使える時に使えること |
| Serviceability | 保守性 | すぐに復旧できること |
| Integrity | 完全性 | 破壊・改竄無く正確であること |
| Security | 機密性 | 不正アクセスされないこと |

システムの評価指標には**RAS**、および**RASIS**と呼ばれるものがあります。上述した表の、上から3つの評価指標の頭文字を並べたものがRASで、上から5つ全てを並べたものがRASISです。特に**RASの信頼性、可用性、保守性はシステムの評価指標で最重要視されています**ので、この3つを混同しないようにしましょう。

初めてRASをシステムの評価指標に導入したのは[IBM](https://ja.wikipedia.org/wiki/IBM)という世界最大規模のIT企業です。IBMは1970年6月に大型コンピュータの「System/370シリーズ」を発表し、この機種において新たなRASの考え方を採用し、商品としての新たな価値を訴えました。

その後、RASにISの要素を追加する形でシステムの評価指標が拡張されました。そのため、RASの3つの要素の重要度が一番高くなっており、RASISは日本独自で広まった用語であると考えられています。（参照: [IT用語辞典 RASIS](https://e-words.jp/w/RASIS.html#:~:text=%E3%80%8Crasis%E3%80%8D%E3%81%AF%E6%97%A5%E6%9C%AC%E8%AA%9E%E4%BB%A5%E5%A4%96%E3%81%AE%E8%B3%87%E6%96%99%E3%81%AB%E3%81%AF%E8%A8%98%E8%BC%89%E3%81%8B%E3%82%99%E6%A5%B5%E3%82%81%E3%81%A6%E4%B9%8F%E3%81%97%E3%81%8F%E3%80%81%E6%AC%A7%E7%B1%B3%E5%9C%8F%E3%81%A6%E3%82%99%E3%81%AF%E3%81%9D%E3%81%AE%E5%BE%8C%E3%82%82(%E7%8F%BE%E5%9C%A8%E3%82%82)%E5%B0%82%E3%82%89ras%E3%81%AE%E7%94%A8%E8%AA%9E%E3%81%8B%E3%82%99%E7%94%A8%E3%81%84%E3%82%89%E3%82%8C%E3%81%A6%E3%81%8A%E3%82%8A%E3%80%81rasis%E3%81%AF%E6%97%A5%E6%9C%AC%E3%81%A6%E3%82%99%E7%8B%AC%E8%87%AA%E3%81%AB%E6%8B%A1%E5%BC%B5%E3%81%95%E3%82%8C%E3%81%A6%E5%BA%83%E3%81%BE%E3%81%A3%E3%81%9F%E7%94%A8%E8%AA%9E%E3%81%A6%E3%82%99%E3%81%82%E3%82%8B%E3%81%A8%E8%80%83%E3%81%88%E3%82%89%E3%82%8C%E3%82%8B%E3%80%82)）

### 障害からの復旧

障害はいつ起こるか分かりません。だからこそ障害が起きた後のこと、つまり復旧に関して考える必要があります。障害復旧においてはRPO、RTOという概念があります。

![RPO・RTO.png](https://storage.googleapis.com/envader-article-images/availability-RPORTO.png)

- RPO（**R**ecovery **P**oint **O**bjective）

RPOは「目標復旧時点」という意味で、**障害が発生した際にシステムを過去のどの地点まで復元するかを定めた目標値のこと**です。

RPOを小さく（短く）すればするほど、障害時に喪失するデータを少なくすることができます。例えば、RPOを10秒とすると障害発生の10秒前までのデータを復旧できることを意味し、RPOを1日とすると障害発生の1日前までのデータを復旧できることを意味します。

前者は秒単位の頻度でバックアップを取得し続ける必要があるという事を意味し、これだけの高頻度でバックアップを行うことによるコストは大変大きくなってしまうでしょう。

対して後者は、バックアップの頻度は1日1回で良いことになり、バックアップにかかるコストは小さく出来ますが、障害発生時から最大で過去24時間分のデータを喪失する可能性があるということでもあります。

リアルタイムに更新され続けるデータと、1日1回しか更新されないデータとでは求められるPROは異なってきます。アプリケーションのデータ更新頻度やバックアップにかかるコストの双方を考慮してRPOを決定する必要があります。

- RTO（**R**ecovery **T**ime **O**bjective）

RTOは「目標復旧時間」という意味で、**システムの復旧までにかかる時間の目標値のこと**です。RTOを小さく（短く）すればするほど、システムを短時間で復旧できることを意味します。しかし、RTOを小さくするためには単純にデータのバックアップを取得しておくだけでなく、システム全体を冗長化して待機しておくなどのダウンタイムを短くするための別の工夫も必要となります。

RPOとRTOをどこまで小さくするべきかは、対象システムの経過時間による影響を考慮して、慎重に決定する必要があります。どちらの数値も小さいに越した事はありませんがコストを度外視して最小値を目指すのではなく、それぞれのビジネス規模に合わせた最適値を検討する必要があります。

### 可用性はどうやって高めるのか

システムの運用において可用性を高める方法は以下の2点です。

- より可用性の高いシステムへリプレイスすること
- 同じシステムを障害発生時の予備として別途用意しておくこと

前者の場合、耐障害性システムなどの導入を行い高可用性を求めるほどに大きな投資が必要になります。また、リプレイス自体の手間や現在使用している資産（システム）が無駄になってしまうなどの問題があります。

後者は**冗長化**と呼ばれ、可用性を高める方法としてよく使われます。冗長化の例としては、まず運用システムとは別に待機システムを用意し、両者を同期しておきます。もし障害が発生した場合に切り替えるだけで100％に近い高可用性を実現できます。（切り替えにともなうダウンタイムを考慮しない場合）つまり、あらゆるシステムにおいて障害が発生する可能性がある以上、冗長化で高可用性を担保するアプローチは基本中の基本と言って良いでしょう。

## サーバの可用性

Webサーバはアクセス状況の変化の影響を受けやすく、複雑なプログラムが動作する事からトラブルが発生しやすいです。また、インターネットに直接接続されているため攻撃のターゲットとなりやすい、といった性質もあります。サービスの可用性を高めるためには、まずはサービス提供の土台となるサーバの冗長化が必要です。サーバの可用性を以下の3つに分けて説明していきます。

- **オンプレミス**の可用性
- **仮想サーバ**の可用性
- **クラウドサービス**の可用性

### オンプレミスの可用性

- サーバが物理である点

まずはこの点から考えなくてはいけません。サーバがハードウェアである以上、故障は避けることができません。なので故障が発生する前提で故障時にもサービス全体に影響しないようにシステム設計をすることが物理サーバでの可用性を高くする基本となります。そのためには止まってしまうとサービスが利用できなくなる「SPoF（**S**ingle **P**oint **O**f **F**ailure: 単一障害点）」を無くす、あるいは少なくすることが重要になります。

- ハードウェアや回線などの予備を用意する

上記と同様の観点からではありますが、オンプレミスでは、物理的に存在するハードウェアや回線を冗長化して障害時に切り替えるという運用を行います。予備のハードウェアや回線を用意しておき、障害発生時に正常な回線に経路を切り替えることで障害による影響を最小限に抑えられます。

サーバを切り替える方法には、以下の3種類の方法があります。

- 障害時に運用系から待機系に自動的に切り替える「**ホットスタンバイ**」
- 待機系サーバは停止状態で用意しておき、障害発生時に待機系を起動してから切り替える「**コールドスタンバイ**」
- 常に複数台稼働させておき、**ロードバランサー**を用いて分散処理させる方法

ロードバランサーは、ロード（負荷）、バランサー（平衡・バランスを取るもの）といった意味があり、**負荷分散装置**のことを指します。主にWebシステムに対してかかる負荷を複数のサーバへ分散させて、処理バランスを調整するために用いられます。

複数のサーバを用意することで仮に1つのサーバがダウンしても残ったサーバでサービスの継続が可能です。この冗長化を実現するためには、複数のサーバそれぞれに対する負荷やサーバダウンに対応して処理を効率的にバランスよく割り振る必要があります。その役割を担えるのがロードバランサーであり、ロードバランサーを導入することで安定したサービス提供を維持することができます。

![オンプレミス.png](https://storage.googleapis.com/envader-article-images/availability-%E3%82%AA%E3%83%B3%E3%83%95%E3%82%9A%E3%83%AC%E3%83%9F%E3%82%B9.png)

### 仮想サーバの可用性

仮想サーバは、1台の物理サーバ上で複数のOSを動かすことで、仮想的に複数のサーバとして運用する方法です。使用する基盤はあくまでも物理サーバなので、仮想サーバを動かす物理サーバに対しての冗長化はオンプレミスと同じです。

オンプレミスとの違いとして、仮想サーバを起動させる物理サーバ自体を遠隔地かつ複数拠点に置くことが可能という点です。そうすることで災害時や事故でひとつの地点に深刻なハードウェア障害が起きた時にも安心です。仮想サーバごと別のハードウェアに移行し、マイグレーションを行うことですぐに業務を再開することができます。ですので仮想サーバで運用することは、国の定める事業継続計画（BCP）の対策にも有効と言えます。

![仮想サーバ.jpeg](https://storage.googleapis.com/envader-article-images/availability-%E4%BB%AE%E6%83%B3%E3%82%B5%E3%83%BC%E3%83%8F%E3%82%99.jpeg)

### クラウドサービスの可用性

クラウドサービスは、導入時の初期費用を抑えられることもあり、手軽に導入することが可能です。そのため、開発者の利用や企業のシステムをオンプレミスからクラウドへ移行するなどで利用されることは少なくありません。

クラウドベンダーを利用する利点は、インフラストラクチャー（システム基盤）部分をクラウドベンダー側で管理・提供してくれるので、ユーザはそれ以外に注力できるという点です。しかし、ユーザが可用性に対して気にしなくていいという話ではありません。

- クラウドの提供する3種類のサービス形態

クラウドベンダーはサービスを利用する利用者のニーズに合わせて**IaaS**、**PaaS**、**SaaS**という3つのサービスモデルを提供しています。代表的なサービス（ここではAWSのサービスを取り上げる）や、可用性の確保の難易度の違いを以下に挙げます。ユーザは利用するサービスモデルによって、可用性に対する対策範囲が変わりますで注意が必要です。

|  | IaaS | PaaS | SaaS |
| --- | --- | --- | --- |
| 正式名称 | Infrastructure as a Service | Platform as a Service | Software as a Service |
| 読み方 | アイアース・イアース | パース | サース |
| 提供するサービス | ハードウェア | 仮想マシン プラットフォーム | ソフトウェア一式 | 各種サービス |
| 自由度 | 高い | 中間 | 低い |
| 代表的なサービス（AWSの一例） | EC2 | Elastic Beanstalk|  Amazon WorkSpaces |
| 可用性の確保の難易度 | 難しい | 中間 | 簡単 |

## まとめ

今回は「可用性」について解説しました。

可用性は普段はなかなか耳にするもの機会がないかもしれませんが、サービス提供の根幹を支える大切な概念です。どんなに素晴らしいサービスがあっても、利用者が利用したい時に使えなかったらその価値を提供することができません。

安定したサービスを提供するためにも可用性をしっかり理解し、サービスの開発を行っていきましょう。

可用性について解説しました。システムにおける可用性とは一体何なのか？初心者でもわかるように解説しております。

【わかりやすく解説】可用性とは？

# 【徹底解説】非機能要件とは何かについて完全に理解する

こちらの記事では、非機能要件について解説します。非機能要件を知ることで、システムアーキテクトとしてのスキルを身につけましょう。

## 要件とは

非機能要件の解説前に、まずは**要件**とは何かについて解説します。

ITシステム開発における要件とは、実際に実現する事です。要件は、**要求**を基に定義します。

次に、ITシステム開発における要求とは、システムの買い手・利用者の「こういうことがしたい」という希望です。

ITシステム開発では様々な制約があります。金銭的な制約もあれば、納期の制約もあります。出てきた要求を全て実現できれば良いですが、制約によってはそれが無理なケースも多いです。

そのため要求を洗い出したら、そのあとは制約を踏まえて「実際に実現する事」を決める＝要件を決める必要があります。

要求・要件は、ビジネスレベル・業務レベル・システムレベルに分かれてそれぞれ定義されます。

ビジネスレベルでは、事業としての要求・要件を定義します。例えば売上や投資利益率を改善する等です。**ビジネス要求**を定義したら、制約を踏まえて**ビジネス要件**を定義します。

業務レベルでは、ユーザーの行動レベルでの要求・要件を定義します。これは上記で定めたビジネス要件を達成するための要求・要件でなければなりません。例えば、売上の停滞理由は営業の客先訪問率の低さにあるが、営業は事務業務のとある箇所に時間を取られすぎて客先訪問に集中できないためその業務を効率化する等です。**業務要求**を定義したら、制約を踏まえて**業務要件**を定義します。

システムレベルでは、システムとして何をするかの要求・要件を定義します。これは上記で定めた業務要件を達成するための要求・要件でなければなりません。例えば、業務のとある箇所を改善するためにシステムでこういう機能を実現する等です。**システム要求**を定義したら、制約を踏まえて**システム要件**を定義します。

非機能要件は、システム要件の一種です。

また、ここから先は単に「要求」「要件」と書いた場合、それぞれ「システム要求」「システム要件」を意味します。

## 非機能要件とは

要件は、**機能要件**と**非機能要件**に分かれます（要求もまた、**機能要求**と**非機能要求**に分けられます）。

機能要件とは、機能の要件です。今回解説する非機能要件とは、機能以外の要件です。

機能とは、ユーザーが実際に操作するものです。具体的に言えば、画面やCUI等のクライアントから実行可能な入出力操作です。

例えば「ユーザーは商品を注文できる」「ユーザーはディレクトリ移動を実行できる」等です。これらはユーザーの行為をサポートするため開発のコアな部分ですが、システムの要件としてはこれらを実現するだけでは不十分です。システムはそれ以外にも業務に耐えうる速度やセキュリティ等を備えなければなりませんが、これらが非機能要件に当たります。機能要件と非機能要件の違いは、「機能か、機能以外か」です。

## 非機能要件の実現方法

非機能要件の多くは、システムのインフラによって実現されます。

注意して欲しいのは、「多くは」であって「全て」ではないという点です。アプリケーションレベルで担保する非機能要件もあります。例えばセキュリティという非機能要件のためのサニタイズという処理がありますが、これはソースコードによって実現されます。

## インフラエンジニアにとっての非機能要件

インフラはITシステムが動く大前提であると同時に、非機能要件の実現手段でもあります。

そのためインフラエンジニアは、最終的には個々のインフラ技術への習熟のみならず、非機能要件の実現のためにインフラ技術を設計できるようになる事が求められます。

学習初期段階から非機能要件を理解することで、何のためにインフラを設計するのかを押さえることができます。

## 非機能要求の一覧

前述した通り、要件は要求を基に定義されます。そのため非機能要求の全体像がわかれば、非機能要件の全体像もわかります。

非機能要求を一覧化してくれている資料として、IPA（**I**nformation-technology **P**romotion **A**gency, Japanの略。日本のソフトウェア分野における競争力の総合的な強化を図る独立行政法人）の**非機能要求グレード**があります。（参照先：[システム構築の上流工程強化（非機能要求グレード）](https://www.notion.so/b23c9f86ed2746c7b8572a671042fd8f)）

非機能要求グレードに準拠すれば非機能要求には大別6種類あり、これらは非機能要求グレードでは**大項目**と呼ばれます。これらは更に**中項目**、**小項目**、**メトリクス**（小項目の達成指標）とブレイクダウンされ詳細に定義されます。

この記事では大項目にスコープを絞って解説することで、まず全体像をつかむことを目指します。

### 可用性

可用性とは、システムが安定的に稼働し続けられる能力です。

システムはトラブルによりダウンするケースがありますが、それが頻発するとユーザーは困ります。そのため可用性という指標を設け、それを保証する必要があります。

可用性についてはEnvaderに別途解説記事があるため、詳細はそちらをご参照ください。（参照先：[【わかりやすく解説】可用性とは？](https://envader.plus/article/14)）

### 性能・拡張性

まずは性能と拡張性を各自解説します。

性能とは、サービス提供におけるリソース利用の効率性です。簡単に言えば、ITシステムのスピードです。

拡張性とは、リソース増強の容易性です。リソースとは、具体的に言えばハードウェアです。システム構築後しばらくすると、ユーザー数や保持データ量が増加することで、当初のリソースでは目標の性能を達成できなくなることがあります。後々この問題を解決するためには、あらかじめリソースを増強しやすくしておく必要があります。

非機能要求グレードにおける性能・拡張性は、字面に存在する上記の2概念を主軸としながらも、これらに影響を与える前提条件・予備条件が含まれる概念です。

これらが実用に耐えないものであれば、toCシステムであればユーザーの離脱を招くでしょうし、toBの業務システムであれば期限までに業務が終了しない可能性が出てしまいます。

### 運用・保守性

まずは運用と保守性を各自解説します。

運用とは、システムが日々問題なく動くようにすることです。つまりトラブルの監視・予防です。

保守とは、システムに問題が起きた時に対応することです。つまりトラブルの解決です。

非機能要求グレードにおける運用・保守性は、字面に存在する上記の2概念をどう行っていくかを主軸としながらも、それを容易にする運用環境やサポート体制や管理方針が含まれる概念です。

システムはリリース後も想定外の事象がほぼ必ず起きるものであるため、この要求・要件を定めておかなければ安定してサービスを提供することが難しくなります。

### 移行性

移行性は、現行システム資産の新システムへの移行方針です。

現行システム＝現在使用しているシステムを新たなシステムへ置き換えるには、様々なことを決めておく必要があります。移行対象はもちろん、実行時期や方式等です。

移行は検討すべきことが多く、なおかつ各システムにより具体的にやらなければならないことがかなり違うため、入念に検討しなければ新システムを想定通り稼働させることは難しくなります。

### セキュリティ

セキュリティとは、構築対象システムの安全性です。

安全性保障のためにやらなければならないことは多岐に渡り、リスク分析や診断に始まり、アクセス制限やデータの秘匿や不正追跡・監視等を行うことになります。

適切なセキュリティ対策が講じられていない場合、システムの破壊や情報の流出等が生じて社会的・経済的損失が発生し得ます。

### システム環境・エコロジー

まずはシステム環境とエコロジーを各自解説します。

システム環境とは、実務的な制約条件です。システムに関する法令や、利用者数や拠点数、ハードウェアの制約事項等です。

エコロジーとは、自然・労働環境についての制約条件です。例えば自然環境の制約とはCO2排出量やエネルギー消費効率等で、労働環境であれば機器の発する騒音です。

これらの対応に失敗していると、国の規制に対応できず稼動が法的に許容されなかったり、近隣労働者の騒音被害に発展し得ます。

## 専門家の責務としての暗黙の要件

契約の仕方にもよりますが、システム開発プロジェクトのゴールは、要件定義で定めた要件を達成することです。それゆえお客様が発注したシステムを外部の人間＝受注者が開発する場合は、受注者の責務の一つは開発したシステムが要件を達成できているか否かにあります。逆に言えば、要件としてないものは受注者は対応しなくともよいのが基本です。要件はお客様が出す注文内容である以上はお客様が基本的に責任を持つということです。

しかし、一定レベルの要件については、仮にそれが要件定義段階で要件として挙がっていなくとも受注者は専門家としての暗黙の責務として対応しておく必要があり得ます。

SQLインジェクションというシステム攻撃手法があります。画面等のインターフェイスにSQL文を入力して利用することで、画面を介して任意のSQL文を実行しDBのデータの取得や改ざんを行う手法です。このSQLインジェクション対策は、セキュリティという非機能要件への対応ということになるでしょうが、これが要件とされておらず対策されていなかったために攻撃を受けたケースにおいて、受注者側の責任とする判決が下されたことがあります。この裁判についてはセキュリティ専門家として著名な徳丸氏のブログ記事で詳細に論じられています。

https://blog.tokumaru.org/2015/01/sql.html

どこまでが専門家としての暗黙の責務であるのかというのは明確な線引きがないのが現状だと思われますが、上記判決の根拠として、経産省・IPAが当該脆弱性についての警告を発していたことを採用しているのが一つの基準点となると思われます。専門家であるならばこれらの公的な情報はチェックし対策していることは当然という見解でしょう。

この事件はセキュリティに限られた話であり、セキュリティ問題による損害は他の要件よりも深刻なものになる可能性が高いため、他の要件についても同じように過失が認められるとは一概には言えません。しかし、お客様は基本的にはシステムのプロではない以上、機能要件はもちろん、目に見えない部分である非機能要件についてはなおさら受注者がシステムの専門家としてリードしていかなくては実現されないことの方が多くなってしまいがちです。

専門家として、非機能要求・要件の全体像を押さえ、お客様に提案し、システムの総合的な品質を保証できることを目指しましょう。

こちらでは、非機能用件について解説します。

【徹底解説】非機能要件とは何かについて完全に理解する

# スケーリングとは？垂直スケーリング・水平スケーリングを使い分ける

こちらの記事では、性能のためのスケーリングについて解説します。

## スケーリングとは

単に**スケーリング**(Scaling)と言った場合、それは拡大縮小のことです。

ITシステム開発におけるスケーリングは、**画像・映像のスケーリング**と**性能管理手法としてのスケーリング**という意味があります。この記事では後者を扱い、以降、単に「スケーリング」と記述した場合はこれのことを指します。

## 性能管理手法としてのスケーリングとは

性能管理の文脈で言うスケーリングとは、処理量に見合った性能をリソースの減増によって実現することです。

性能とは、サービス提供におけるリソース利用の効率性です。簡単に言えば、ITシステムのスピードです。性能の詳細については以下の記事をご参照ください。
https://envader.plus/article/17

スケーリングには、**垂直スケーリング**と**水平スケーリング**の2種類があります。

- 垂直スケーリング

処理を担う各コンポーネントの性能を増減させることです。例えばサーバを対象にするのであれば、ハードウェアをより良いものに交換したり、逆に必要ないのでより性能の低いものに変えたりすることです。性能を上げる場合は**スケールアップ**、下げる場合は**スケールダウン**と呼びます。

![vertical.png](https://storage.googleapis.com/envader-article-images/vertical.png)

- 水平スケーリング

分散処理を担うコンポーネントの数を増減させることです。例えばサーバを対象するのであれば、サーバを複数用意してそれらで分散処理したり、必要なければサーバ数を減らしたりすることです。増やす場合は**スケールアウト**、減らす場合は**スケールイン**と呼びます。

![horizontal.png](https://storage.googleapis.com/envader-article-images/horizontal.png)

## 垂直スケーリングと水平スケーリングの使い分け

垂直スケーリングと水平スケーリングはそれぞれメリット・デメリットが異なり、絶対的な優劣をつけられるものではありません。目的に応じて適切に使い分ける必要があります。

### 垂直スケーリング・水平スケーリングの長短

垂直スケーリングと水平スケーリングのメリット・デメリットが問題となる主要な側面は、メンテナンス量・実装難易度・ダウンタイム・性能限界の4つです。

- メンテナンス量

メンテナンス量はオンプレミスの時に問題となります。

この点ではスケールアップが優れています。スケールアウトがコンポーネントを増やすためにメンテナンス対象も増えるのに対し、スケールアップは既存コンポーネントをより高性能なものに置きかえるだけのためメンテナンス対象は増えません。

- 実装難易度

実装難易度についてはスケールアップの方が簡単です。ハードウェアを交換するだけのため、実装への影響は少ないからです。「少ない」であって「無い」と言い切れないのは、チューニング等パフォーマンスを考慮した実装が必要になったり不要になったりする可能性がゼロとは言い切れないためです。

スケールアウトする場合、複数コンポーネントで分散処理を行っているために、「どう分散するか」「コンポーネント間でデータ整合性をどう保つか」という問題が発生し、これに対応する必要があり難易度が高くなります（この件は後ほど詳述します）。

- ダウンタイム

ダウンタイムについてはスケールアウトに分があります。ダウンタイムとは、サービスの停止時間のことです。スケールアップはハードウェア自体の交換を行うためダウンタイムは避けられません。しかしスケールアウトは分散処理対象を増やすだけのため、トラブルがなければダウンタイムは必要ありません。

- 性能限界

性能限界についてはスケールアウトであればありません。一方でスケールアップはハードウェアの問題ゆえに物理的な制約が存在し、これによって向上できる性能には限界があります。

### どう使い分けるか？

どうスケーリングさせるのが良いかは、どのようなサービスかによります。

例えば比較的小規模なサービスであるがゆえにダウンタイムも性能限界も許容できるのであればスケールアップを利用するかもしれません。逆に大規模で、かつある程度データの一貫性を犠牲にしても良いのであれば、スケールアウトを利用することになるでしょう。

全てを満たすのは難しい・コストがかかる事が多く現実的ではない場合、何は必須なのか・何は許容できるのか・許容不能な部分があるとすれば何をすれば許容範囲にまで制御できるのかを自身のサービスに合わせて検討しましょう。

## 水平スケーリングの難しさ

先述のように、水平スケーリングには垂直スケーリングにはない難しさがあります。「どう分散するか」「コンポーネント間でデータ整合性をどう保つか」です。

### どう分散するか――負荷分散の問題

スケールアウトにより複数のコンポーネントが並列稼動している場合、個々のアクセスをどのコンポーネントに繋げるか＝負荷分散の設計が問題になります。どのように分散するかは要件により、適切な方式を選択する必要があります。

### データ整合性をどう保つか――データ整合性の問題

スケールアウト対象のコンポーネントがデータを持つ場合、データが分かれる以上、データ間の整合性の保持が問題になります。整合性保持の設計が必要になります。

この点で最も大きな問題を抱えるのはRDBです。一般的にRDBのスケールアウトは難しいとされます。基本的にRDBは一貫性を求められるデータを扱いますが、この特性のデータはスケールアウトと相性が良くありません。問題となるのは更新処理です。

まず、複数RDBそれぞれにまったく同じデータを保持するケースを考えましょう。この場合、全てのRDBが同値になるように処理せねばならず、余分な同期処理の分、RDBが1つしかない時よりも遅くなり得ます。性能向上になりません。これを回避するために複数RDBがそれぞれ異なるデータを保持するようにしたら、複数RDB間で一貫性を求められるデータ処理（例えばRDB1とRDB2があったとして、RDB1のデータから数値を引いてその分をRDB2に足すような処理）をした時にトラブルが起きて処理が中断してしまった場合に備える複雑な仕組みが必要となります。

DBサーバ以外のサーバは基本的にデータを保持しないため、このような問題は生じません。セッションを保持する可能性がありますが、この場合はRDBほどではありませんがRDBと類似の問題が生じます。DBでも、NoSQLで扱われるのは一貫性を求めないデータであることが基本のため、こちらでもRDBのような問題は生じにくいです。

## オンプレミス・クラウドのスケーリング

スケーリングの「容易性」「費用」は、オンプレミスかクラウドかで変わります。

### スケーリングの容易性

スケーリングの容易性では、クラウドに圧倒的な分があります。

オンプレミスではスケーリングのためにはそれなりの準備と日数を必要とします。まず必要なリソースの見積もり＝**サイジング**が必要です。いざスケーリングするとなると、ハードウェアの調達作業が必要ですし、調達できたらハードウェアの各種設定作業＝**キッティング**も必要になります。

しかしクラウドであれば設定さえすればスケーリングが完了します。

### スケーリングの費用

費用面に関しては、オンプレミスとクラウドのいずれが安いかはケースバイケースです。

スケーリング自体に必要な費用、スケーリング後の維持費用（オンプレミスであれば電気代等もかかります）、ノウハウを持つ人材の確保コスト等、様々な費用があり得ます。多角的な観点から費用を計算するべきでしょう。

こちらの記事では、性能のためのスケーリングについて解説します。

スケーリングとは？垂直スケーリング・水平スケーリングを使い分ける

# どちらを選ぶ？クラウドとオンプレミスのメリット・デメリット、違いを比較

近年、企業の社内システムもクラウドを用いた導入がますます進み、日常業務に欠かせないものになっています。本記事では、「クラウド」と、その対義語として用いられる「オンプレミス」についてそれぞれどんな意味なのか、2つを比較したメリット・デメリット、それぞれどのようなケースで利用するのか、について解説します。

## オンプレミスとは

オンプレミス（on-premise）はシステム稼働に必要となるサーバーやネットワーク機器、ソフトウェアなどを自社で保有し、運用するシステム利用形態です。自社の保有するサーバールームやデータセンターなどのスペースにサーバーを設置し、電気、空調の管理から、通信回線まで自社の責任において運用します。

かつては企業が業務用に情報システムを構築するには、自社内に資源を用意する以外の選択肢がありませんでした。それが2000年代後半以降、クラウドコンピューティングの浸透に伴い、業務用システムもクラウドで自社外に構築、運用するというケースが増えてきています。こうした時代の流れに応じて、自社外にIT資源を確保する「クラウド型」と対比する言葉として、自社内にすべての資源を確保する、「オンプレミス型」というが用いられるようになりました。

ちなみに、英単語”premise”は、「構内」「建物」などを意味する名詞で、これに前置詞”on”をつけることで、「構内に用意する」などの意味を表現した言葉になります。

## クラウドとは

クラウド(Cloud)とは、クラウドコンピューティング（Cloud Computing）やクラウドサービス（Cloud Service）を略して使われる用語です。クラウドコンピューティングとは、インターネットなどの回線を介して、社外の組織が保有するハードウェアやソフトウェアなどの資源を、サービスとして必要な時に、必要な分だけ利用するというコンピュータの利用形態のことで、利用可能なサービスのことをクラウドサービスといいます。

NIST（米国国立標準技術研究所）の定義によると、クラウドの基本的な特徴として以下の5項目を挙げており、クラウドサービスは、5項目すべてを備えなければならないとしています。

- オンデマンド・セルフサービス（On-demand self-service ）
- 幅広いネットワークアクセス（Broad network access）
- リソースの共用（Resource pooling）
- スピーディな拡張性（Rapid elasticity）
- サービスが計測可能であること（Measured Service）

英単語”Cloud”は「雲」を意味する名詞です。なぜ、Cloudという用語を使うようになったのかは諸説ありますが、実態がぼんやりしていて、ユーザーから把握しにくい、ネットワークの先にあるサーバーを表すときに、雲の絵を使ったから、という説がよく用いられます。

## メリット、デメリットの比較

近年はクラウドがますます浸透しておりますが、当然メリット、デメリットがあり、使い方に応じて、導入の仕方を選ぶことが大切です。

|  | オンプレミス | クラウド |
| --- | --- | --- |
| 初期費用 | 高 | 低 |
| 導入期間 | 長 | 短 |
| ランニング費用 | 大（利用形態による） | 小 |
| 物理的なスペース | 大 | 小 |
| サーバーの拡張性 | 難 | 容易 |
| サーバー、OS、アプリケーションの更新 | 要 | 不要 |
| カスタマイズの自由度 | 高 | 低 |
| 社内システムとの連携 | 容易 | 難の場合あり |
| 障害対応 | 自社/ベンダー対応 | ベンダー対応 |
| 災害時のリスク | 大 | 小 |

### 初期費用

オンプレミスの場合は、自社でサーバーなどを用意しなければなりません。サーバー導入には一般的に数百万円単位のマシン費用が掛かるのに加え、導入に期間がかかるため、導入作業の人件費も大きくなる傾向があります。

クラウドの場合は、サーバー環境を自社で用意する必要はありません。システムやアプリを利用するための設定費用などはかかりますが、通常、数十万円単位で収まる範囲内です。

### 導入期間

オンプレミスの場合、システムを新しく構築する必要があります。システムの要件定義、設計、テスト、リリースというプロセスを経て使用可能になります。また初期費用が高額なため、導入には慎重な決断が必要となり、承認プロセスも時間がかかるケースが多くなります。一般的には、数か月から半年程度の期間を見込むことになります。

クラウドの場合は、申し込み後即時にサービス利用可能なことも多く、設定や部分的なカスタム要件を除けば、即利用が可能です。

### ランニング費用

オンプレミスの場合、サーバーの固定資産税、ソフトウェアのライセンス費用、ハードウェア・ソフトウェアそれぞれの運用担当者の人件費などがランニング費用として挙げられます。固定資産税や人件費などによって、クラウドと比較すると、ランニングコストが高くなる要因になります。

クラウドの場合は、サーバーなどの運用初期費用はすべてサービス費用に含まれています。ライセンス数やその期間についても、使うときに、使う分だけ、の選択が可能なため、余剰が生まれる余地が少なく、コストは低く抑えることができます。運用はサービス提供者と分担する形になるので、運用担当者の人件費も比較的低く抑えられます。

### 物理的なスペース

オンプレミスの場合は、自社内にサーバー、ネットワーク機器を置くスペース、電力、空調が必要です。

クラウドの場合は、すべてクラウド事業者に任せられるので、物理的なスペースは不要です。

### サーバーの拡張性

オンプレミスでは、ハードウェアの増設が必要なため、機器の調達から、設計など、相応費用と時間が必要です。

クラウドでは、サービスプランによるところはありますが、その範囲内であれば、自由に、迅速に拡張が可能です。またクラウドの場合は、縮小も容易なため、利用状況に応じて、拡張したり、縮小したりが簡単に行えるというメリットにつながります。

### サーバー、OS、アプリケーションの更新

オンプレミスの場合は、自社の責任の下で、定期的にサーバー、OS、アプリケーションの更新を行う必要があります。場合によってはハードウェア更新のために、予算の確保や、停止調整など長期的な計画を立てなければならず、相応の負荷があります。

クラウドでは、クラウドベンダーが常に最新のOS、アプリケーションに更新するため、ユーザー側での更新は必要ありません。

### カスタマイズの自由度、社内システムとの連携

オンプレミスでは、自社の要望に対して、サーバーを自由にカスタマイズを行うことができます。自社の同じネットワーク内にシステム構築できるため、既存の社内システムとの連携も容易に行うことができます。

クラウドでは、クラウドベンダーの提供する範囲によって制約が生まれます。クラウドの場合は、インターネットを経由するため、既存の社内システムとの連携が難しく、場合によっては、連携ができない場合もあります。近年はクラウドサービスの浸透に伴い、API（**A**pplication **P**rogramming **I**nterface）が提供されているケースが増えてきているため、クラウドとの連携はしやすくなってきています。

### 障害対応

オンプレミスの場合は、導入ベンダーと契約することで、リスク分散をすることは可能ですが、あくまで自社環境なので、基本的には自社で障害対応も行うことになります。

クラウドでは、クラウドベンダー側で保守や復旧作業をおこないます。逆に言えば、障害が起きてもユーザー側で手を出すことができないので、復旧を待つしかない、ということも起こります。

### 災害時のリスク

オンプレミスでは、自社敷地内に環境を用意するため、地震などの自然災害に自社環境が巻き込まれた場合には、サービスが停止する場合があります。

クラウドは堅牢なデータセンター内にサーバーが設置されており、データセンターも各地に点在し、システムを分散して配置することが可能なため、災害時のリスクを低下することが可能です。

## どちらを選ぶべきか

利用するケースに応じて、クラウド、オンプレミスを選択することが大切です。以下に一例を紹介します。

オンプレミスを利用するケース

- 自社内の機密情報を扱い、社外に一切データを出したくない
- 自社独自のシステムとデータ連携するため、自社内に構築したい
- クラウドでは用意しきれない、高性能なサーバが必要

クラウドを利用するケース

- 新規事業の立ち上げやスタートアップのため、初期費用を抑え、素早く導入がしたい
- システム構築、運用のリソースが足りない
- テレワークなどでの外部アクセスを想定している

## まとめ

昨今のクラウドサービスの流行に伴い、とにかく「クラウドのほうが良い」という意見になりがちですが、オンプレミスならではの、カスタマイズの自由度や、セキュリティの確保などのメリットにも目を向けて、長期的な視点で検討することが重要です。

オンプレミスとクラウドを組み合わせたハイブリット運用という手段もあります。クラウドだけ、オンプレミスだけではなく、どちらともよく理解をして適切に利用することが、これからのシステム構築において必要なスキルになってくるのだと思います。

クラウドとオンプレミス、それぞれどのようなケースで利用するのかについて解説します。

どちらを選ぶ？クラウドとオンプレミスのメリット・デメリット、違いを比較

# どっちがどっち？マルチクラウド、ハイブリッドクラウドの違いとそれぞれの用途

この記事では、クラウドサービスが理解されている前提としてマルチクラウドとハイブリッドクラウドの基礎知識、混同されがちな両者の違いについて解説します。

## マルチクラウドとは

複数のパブリッククラウドを使い道に応じて併用して利用することです。それぞれの目的に合わせて、最適なクラウドを使い分けることで、それぞれのクラウドの長所を活かして最適な形で運用することが可能です。目的に合った機能を備えており、使いやすさや分析の精度が上がるといったメリットがあります。

- パブリッククラウドとは
    
    専用のハードウェアなどを所有することなく、企業でも個人でも利用したい人が必要な時に必要なだけ自由にサーバーやネットワークリソースを使えるシステムです。
    

### マルチクラウドのメリット

- 複数のサービス提供者からサービス提供を受けるので、独自のカスタマイズが実現しやすくなります。
- ひとつのサービス提供者に依存することがなくなるので、システムの柔軟性を維持できます。
- 複数のクラウドを活用しているため、リスク分散にもなります。またBCP対策にも有効です。

### マルチクラウドのデメリット

- 複数のクラウドをそれぞれ活用しているので運用が煩雑になる可能性があります。
- 複数のクラウドサービス提供者と契約し、それぞれにアカウントを作成することになるので、結果的にコスト高になる可能性があります。
- 複数のクラウドを利用することでセキュリティレベルが低下する可能性があります。

## ハイブリッドクラウドとは

パブリッククラウドとプライベートクラウドや物理サーバーなど、いくつかのサービスを組み合わせて使うクラウドのことです。タイプの異なるサーバーを組み合わせて利用することから、それぞれの持つメリットを活かしつつ、デメリットをカバーしあえるという特徴を持っています。

- プライベートクラウドとは
    
    企業・組織が自社専用のクラウド環境を構築し、社内の各部署やグループ会社に提供する形態をいいます。
    

### ハイブリッドクラウドのメリット

- オンプレミスのサーバーの活用で社外秘データを安全に保管することができ、データのバックアップ強化を図ることができます。
- オンプレミス環境を活かしながら、BCP対策を考えてリスク分散を図ることができます。
- オンプレミス環境でしか使えないシステムを構築している場合、それも活用しながら新たなクラウド環境を併用することができます。つまり、「いいとこどり」の環境を構築することが可能です。
- オンプレミスやプライベートクラウドはカスタマイズが自在である一方で、コスト高になります。カスタマイズが必要でないシステムをパブリッククラウドへ移行することでコスト抑制が期待できます。

### ハイブリッドクラウドのデメリット

- システム構成が複雑になり、システムを運用するにも、状況を理解し、技術力もある担当者が必要になります。
- コスト計算が複雑になります。オンプレミスで運用している部分と、パブリッククラウドを活用している部分など、それぞれのコストが計上されることになるので、適切なコスト配分ができているのかどうかの試算が難しくなります。
- 運用するのに専門性が必要になります。複数の環境を混合して新たなクラウド環境を構築しているので、障害が発生したときに知識と技術を持った担当者でないと対応できません。

## マルチクラウドとハイブリッドクラウドの違い

### クラウドインフラストラクチャの種類

「マルチクラウド」と「ハイブリッドクラウド」の両者とも、複数のクラウドを統合したクラウドデプロイメントを意味しています。異なっているのは、それぞれが使用しているクラウドインフラストラクチャの種類と構築方法です。「マルチクラウド」と「ハイブリッドクラウド」の両者とも、複数のクラウドを統合したクラウドデプロイメントを意味しています。異なっているのは、それぞれが使用しているクラウドインフラストラクチャの種類です。ハイブリッドクラウドインフラストラクチャは、異なる複数タイプのクラウドを組み合わせているのに対し、マルチクラウドは同一タイプのクラウドを組み合わせて使用しています。ハイブリッドクラウドはリンゴとオレンジを組み合わせるようなもので、マルチクラウドは品種の違うリンゴを組み合わせるようなものと考えるとよいでしょう。

- クラウドインフラストラクチャとは

クラウド コンピューティングを提供するハードウェア要素とソフトウェア要素の集合です。これには、コンピュート、ネットワーク、ストレージのほか、仮想化されたリソースにアクセスするためのインターフェイスも含まれます。

![multicloud-1.png](https://storage.googleapis.com/envader-article-images/multicloud-1.png)

### システムの利用方法

ハイブリッドクラウドは、複数のタイプのクラウド環境を混合させ、それらを統合して単一のシステムを構築します。これに対してマルチクラウドは、異なるパブリッククラウドサービスを目的に合わせて併用し、それぞれのクラウドは相互接続することなく、独立して利用します。

### 利用シーン

- マルチクラウド
    - 大規模障害や過負荷によるシステムダウンを想定し、複数社のパブリッククラウド環境を用いてバックアップ・リカバリ体制を構築する。
    - 情報収集、分析、結果開示と閲覧のように、ひとつの業務をフェーズごとに分割し、それぞれのフェーズで最適なクラウドサービスを使う。
- ハイブリッドクラウド
    - 顧客情報の保管・開示を行うシステムにおいて、オンプレミス（もしくはプライベートクラウド）側で機密情報を保管し、パブリッククラウド側で情報公開を行う。
    - モバイルと連携した業務システムにおいて、パブリッククラウド側でモバイルアプリケーション連携を行い、プライベートクラウド側で基幹業務処理を行う。

利用シーンでもわかるようにマルチクラウドは「リスク分散」や「同時利用」が目的といえます。これに対してハイブリッドクラウドは、「業務や情報の性質による分担」に主眼を置いた仕組みと言えるでしょう。

## まとめ

マルチクラウド、ハイブリッドクラウドの基礎知識や両者の違いについて解説しました。似たような意味で使われることが多いですが、実際には大きな違いが存在していました。利用シーンで分かるようにそれぞれの特徴の違いが出ていると思います。両者の運用形態の概要までを理解しすることで、クラウドの理解を少しでも深めていただきたいと思います。

この記事では、クラウドサービスが理解されている前提としてマルチクラウドとハイブリッドクラウドの基礎知識、混同されがちな両者の違いについて解説します。

どっちがどっち？マルチクラウド、ハイブリッドクラウドの違いとそれぞれの用途

# 【初心者向け】GitHubとは？必須知識と使い方について解説！

開発において「**GitHub**（ギットハブ）」は必須スキルとなっています。こちらの記事でGitHubの基礎知識と基本操作、そして実際の開発時の使い方について解説します。

## GitとGitHubについて

**GitHub**とは「**Git**」の仕組みを使用したウェブサービスのことです。まずGitとGitHub違いについて説明します。

「**Git**」とは分散型バージョン管理システムのことです。バージョン管理とは分かりやすく言と、ソフトウェア・アプリケーション開発で作成したソースコードの状態を記録することでバージョンを管理します。機能追加やバグ修正を行う度に変更されるソースコードをその都度記録しておくと変更履歴を管理できることはもちろん、前の状態に戻すことも可能になります。バージョン管理システムには様々な種類がありますが、その中でもGitは「分散型」です。分散型ではないものは「集中型」で、こちらはサーバー上で管理する一つのリポジトリを複数人が接続して使います。リポジトリとは「貯蔵庫」という意味があり、ディレクトリの構造・状態やソースコード、変更履歴を格納しておく場所のことです。「分散型」はサーバー上にあるリポジトリを開発者が各自の環境に複製して作業を行います。

![git01.png](https://storage.googleapis.com/envader-article-images/github/git01.png)

「GitHub」とは、Gitの仕組みを使用して開発のソースコードを保存・共有・公開ができるウェブービスです。開発者が自分の作品のソースコード等を公開したり、チーム開発ではメンバー内でコードを確認（レビュー）したりすることができます。各自の環境で開発を行い、コードを共有・履歴を管理できるため、チーム開発に最適で必須のツールです。

ここからは、GitHubの使い方について以下の順序で説明していきます。

1. 使用前の基礎知識
2. 基本的な操作方法
3. 開発での使用の流れ

## GitHubの基礎知識

GitHubを使うために必要な前提知識となるいくつかの用語について説明します。

- リポジトリ

    前項で説明したリポジトリですが、GitHubには「**リモートリポジトリ**」と「**ローカルリポジトリ**」があります。
    - リモートリポジトリ
        リモートリポジトリとは、GitHub上で保存・管理しているリポジトリのことです。インターネット上にあるため世界中に公開されていると言えます。複数人の開発者がリモートリポジトリを元として自分の環境に複製（clone）して作業を行います。
    - ローカルリポジトリ
        ローカルリポジトリとは、自分の環境（ローカル環境）にあるリポジトリのことです。
- ワークツリー

    ローカル環境でGitの管理下におかれた、実際に作業を行っているディレクトリのことです。
- インデックス（ステージングエリア）

    Gitではワークツリーでの作業内容をローカルリポジトリに記録（コミット）していきますが、直接記録するわけではなく中間にインデックスと呼ばれる準備領域が存在します。インデックスはステージングエリアとも呼ばれ、この領域を間に挟むことでワークツリー内で変更を行ったファイルだけをリポジトリに記録することができます。

![git02.png](https://storage.googleapis.com/envader-article-images/github/git02.png)

- コミット

    ローカル環境内（ワークツリー）で行った作業内容をローカルリポジトリに記録することをコミットと呼びます。任意のタイミングでディレクトリの状態を記録することができるためバージョン管理には欠かせない仕組みです。コミットを行うと、コミットを一意に識別するため40桁のID＝コミットIDが付与されます。コミットIDがあることで履歴を管理することができます。
- プッシュ

    プッシュとはローカルリポジトリの内容をリモートリポジトリに反映させることです。プッシュを行うことで、変更履歴を含む自身のローカルリポジトリの内容がリモートリポジトリにアップロードされます。
- ブランチ

    ブランチとは、一つのプロジェクト（リポジトリ）の中で本筋から分岐させて変更履歴を記録していくためのものです。分岐したブランチの内容は他のブランチに影響しないため、並行して行われる複数の機能追加やバグ修正等の作業を可能にします。
    - マージ
        枝分かれになったあるブランチを他のブランチと合流させることをマージと言います。

![git03.png](https://storage.googleapis.com/envader-article-images/github/git03.png)

- クローン

    既存のリポジトリを**ローカル環境**に複製することをクローンと言います。自分の環境にクローンすることでオフライン状態でもファイルの編集を行うことがでGit管理下で変更を追跡することができます。またクローン元のリモートリポジトリとの接続も切れないため、オンライン状態でローカルの変更をプッシュすることができます。
- フォーク

    フォークとはGitHub上で既存のリポジトリを**自分のアカウント領域**に複製することができるGitHubの機能です。フォークしたリポジトリでは自分の作業内容を更新・反映させることができます。また元の既存リポジトリに対して管理者に更新内容を通知して共同で開発することも可能です。同じ「複製」の機能であるクローンとフォークの違いは下記図のようになります。

![git04.png](https://storage.googleapis.com/envader-article-images/github/git04.png)

- プルリクエスト

    プルリクエストとは、ソースコードの変更をリポジトリの管理者・レビュアーに対して通知して反映（マージ）を依頼する、GitHubが提供する機能のことです。プルリクエストが送られると変更内容や反映先のコードとの差分が通知されます。プルリクエストにより開発メンバー内でコードレビューを行い、一人では気づかなかった記述ミスやバグ等を見つけたりとコードの品質を向上させることができます。

## 必須の基本操作

ここからは実際にgit操作を行ってみましょう。ここではコマンドを用いてgit操作する方法について説明します。

### 事前準備

- GitHubのアカウント作成
- ローカル環境にGitで管理する作業ディレクトリを作成

### 基本操作

GitHubの主な機能はローカルで作業した内容をGitHub上＝リモートリポジトリに反映させることです。ここではその手順・方法について説明します。

- `git clone`

    GitHub上のリポジトリをローカル環境に複製するには`git clone`を実行します。

    ```bash
    $ cd [ディレクトリパス] #作業ディレクトリに移動
    $ git clone [URL]
    ```

    インターネット上にあるリポジトリをローカル環境にコピーするための接続方法にはhttps接続とssh接続の二種類があります。接続の際には、httpsではアクセストークンの生成、sshではsshキーの設定を行っておく必要があります。

    上記コマンドのgit cloneの後ろに記述する[URL]は以下のように取得します。

    - httpsによる接続

    ![git06.png](https://storage.googleapis.com/envader-article-images/github/git06.png)

    - sshによる接続

    ![git07.png](https://storage.googleapis.com/envader-article-images/github/git07.png)

- `git init`

    `git init`はローカルリポジトリを初期化するコマンドで、対象の作業ディレクトリをGitの管理下に置くことができます。ローカルの作業ディレクトリで`git init`を実行することで「.git」というローカルリポジトリが作成されます。
- `git add`

    `git add`は指定したファイルをワークツリーからインデックスに登録するコマンドです。ファイル名はスペースで区切ることで複数指定することができます。

```bash
$ git add [ファイル名]
```

また`git add .`と`.`（ピリオド）を指定するとワークツリーの全てのファイルがインデックスに登録されます。

- `git commit`

    編集したファイルをインデックスに登録したら、git commitを実行してインデックスに登録されたファイルをローカルリポジトリに記録＝コミットを行います。`git commit`を実行する際にはオプション`-m`で必ずコメントを記述する必要があります。コメントは開発チーム内で共有するためレビュアーやメンバーに分かりやすい内容を心がけると良いでしょう。

```bash
$ git commit -m "[コメント]"
```

- `git push`

    続いてコミットしたファイルを`git push`を実行してリモートリポジトリに反映＝プッシュします。初回は「.git」ファイルをリモートリポジトリに紐づけるために`git remote add [リポジトリ名] [リモートリポジトリのURL]`を実行します。この操作によって対象のリモートリポジトリのURLが指定したリポジトリ名で登録されます。リポジトリ名はoriginとすることが多いです。

```bash
$ git remote add origin https://...
```

二回目以降は`git push [リポジトリ名] [プッシュ先のブランチ名]`でリモートリポジトリにファイルをアップロードすることができます。

```bash
$ git push origin [ブランチ名]
```

`add`、`commit`、`push`の一連の流れを繰り返すことで自分の作業内容を一定のまとまりごとにGitHub上のリモートリポジトリに反映させることができます。

![git05.png](https://storage.googleapis.com/envader-article-images/github/git05.png)

- `git status`

    `git status`を実行するとGitの現在の状況を確認できます。例えばファイルの登録をどこまで行ったか（addは行ったがcommitはまだ、など）の確認をする際に便利なコマンドです。ディレクトリやオプションの指定もできるので、実際に試して確認してみると良いでしょう。
- `git log`

    `git log`はコミットの状況・ログを確認できるコマンドです。コミットIDやユーザー情報、日付等のデータが表示されます。こちらも様々なオプションがあります。確認したいことに合わせてオプションを指定しましょう。
- `git pull`

    リモートリポジトリの内容をローカル環境に反映させることをプルと言います。プルを実行するコマンドは`git pull`です。`git pull [リポジトリ名] [ブランチ名]`とリモートリポジトリの名前とリモートリポジトリ上のブランチ名を指定して実行します。

```bash
# 例
$ git pull origin main
```

- `git fetch`と`git merge`

    前項で説明した`git pull`は`git fetch`と`git merge`を一度に行うコマンドです。`git fetch`はリモートリポジトリの内容をローカルリポジトリに取り込むのみで更新（マージ）は行いません。そのため`git fetch`を実行しただけではローカルリポジトリ内のブランチの内容に変更は起きていません。`git merge`を実行することで`git fetch`で取り込んだ内容をローカルリポジトリ内のブランチに結合させることができます。
- `git branch`と`git checkout`

    ブランチを操作するコマンドには`git branch`と`git checkout`があります。`git branch`はブランチの一覧を表示したりブランチの作成・削除を行ったりすることができ、様々なオプションがあります。`git branch`のみ実行するとブランチの一覧が表示されます。現在使用しているブランチには*（アスタリスク）がつきます。`git branch [新規ブランチ名]`で新しくブランチを切ることができます。ブランチを切ると、使用中のブランチの内容がそのまま引き継がれます。ただし作成したブランチには移動していない状態です。`git checkout [ブランチ名]`でブランチを移動することができます。`git checkout -b [新規ブランチ名]`というように`-b`オプションを指定すると、新しいブランチの作成と移動を同時に行うことができます。

## チーム開発でのGitHub使用の流れ

基本的には以下の手順でGitHubを使用して開発を進めていきます。

1. リポジトリ作成・ローカル環境への反映
    まずはチームで使用するリモートリポジトリを作成または用意されているリポジトリを自分の環境にクローンします。
2. 作業用ブランチを切る
    作業用ブランチを切ります。続いてローカル環境で作業を行いますが、ここで作業用ブランチを切ります。作業用ブランチを切ることでクローンしてきた内容に影響を与えずに開発を行うことができます。
3. 開発・リモートリポジトリへの反映
    ディレクトリ・ファイルの追加や編集を行いながらこまめに`git add` 、`git commit` 、 `git push`を実行します。コミットは作業単位で行い、いくつかのコミットをまとめてGitHubにアップロード＝プッシュすることが多いです。プッシュ先はリモートリポジトリ上のメインで使用するブランチではなく、作業用のブランチを指定することが一般的です。
4. プルリクエスト
    リモートリポジトリの作業用ブランチにプッシュした作業内容をメインのブランチに反映させるためにプルリクエストを送ります。チーム内でコードレビューを行い、マージ担当者がGitHub上でマージを実行するとリモートリポジトリのメインのブランチが更新されます。
5. 次の作業に移る時は新しくブランチを切ります。
    その前に、最新のリモートリポジトリをローカル環境に取り込む必要があります。ローカル環境内のメインのブランチは常にリモートリポジトリの内容を反映させて、そこから作業用ブランチを切ることでスムーズに開発を進められます。
6. 2〜5を繰り返します。

![git08.png](https://storage.googleapis.com/envader-article-images/github/git08.png)

### コンフリクト

複数のブランチを結合＝マージする際に、複数人が同じ箇所を編集したことにより起こる競合・衝突を**コンフリクト**と言います。コンフリクトが発生したら双方のブランチの編集内容を確認して修正した後に再度マージを実行します。

こちらで紹介した手順はチーム開発でGitHubを使用する際の大まかな流れです。実際の開発ではチーム内でGitHubの使用手順について認識を揃えておくことが大切です。

## まとめ

GitHubにはバージョン管理・チーム開発のため多くの機能があります。当記事で解説したのは基礎的な部分で、GitHubを使用するために必ず押さえておくべき内容です。様々なコマンドやオプションを利用することでより高度な処理を実行できます。GitHubの知識や使用経験は採用時にもアピールになります。GitHubはほとんどの機能が無料で個人利用もできるため、まずは実際に手を動かしてみましょう。

こちらの記事でGitHubの基礎知識と基本操作、そして実際の開発時の使い方について解説します。

【初心者向け】GitHubとは？必須知識と使い方について解説！

# 未経験でも可能？インフラエンジニア・クラウドエンジニアへの転職

IT技術の進歩に伴って、需要が高まっているのがインフラエンジニアです。クラウドサービスの普及によって業務が減ると言われていましたが、実際はそうでもありません。

インフラエンジニアの需要はまだまだ高いと言えます。むしろ、クラウドサービスに対応できる人材こそ求められつつあるほどです。

今回はそんなインフラエンジニアへ転職を考えている方に向けて、未経験でも転職しやすい理由と必要なスキルについて解説します。ぜひ参考にしてください。

## インフラエンジニアはITで欠かせない人材

![https://storage.googleapis.com/envader-article-images/infra-engineer/image14.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer/image14.jpg)

インフラエンジニアとは、IT基盤の設計から運用、メンテナンス・保守まで幅広く行う人材のことです。業務によって大きく2種類に分けられ、以下のように呼ばれています。

- サーバーエンジニア
- ネットワークエンジニア

サーバーエンジニアは、企業にあるサーバーの設計や構築、テスト、運用までを行います。近年はクラウド化が進んでいるため、クラウドに関する知識が必要になることも。またサーバー関連の業務として、配線周りの知識も必要です。

一方のネットワークエンジニアは、端末やサーバー同士を接続するネットワークを構築し、データを送受信できる環境を作ります。クライアントの要望を聞いて構築をしていかなければいけません。また、障害が起こった場合は24時間体制での対応になることもあります。

最近ではクラウド領域専門で従事するクラウドエンジニアもインフラエンジニアとして内包されています。働き方やスキルが前者二つとは大きく異なってきます。

## インフラエンジニアは未経験でも転職できる

![https://storage.googleapis.com/envader-article-images/infra-engineer/image2.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer/image2.jpg)

インフラエンジニアは、未経験でも転職することができる職種です。もちろん相応の知識・スキルは必要ですが、職種・年齢を関係なく学べます。転職を考えている方は、以下の理由から需要が高いことをまず知っておきましょう。

- 需要が高い
- 即戦力になれる
- リスキリングがしやすい
- キャリアチェンジしやすい
- 年齢が関係ない
- 経験を活かす働き方がしやすい

### 需要が高い

![https://storage.googleapis.com/envader-article-images/infra-engineer/image10.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer/image10.jpg)

インフラエンジニアが担っているITインフラは、24時間365日フル稼働していなければいけません。IT技術が当たり前となった昨今、その需要はますます高まっています。

特にインフラエンジニアの業務は、ITインフラを支える上で必要不可欠です。ですが、IT業界は常に人材不足。未経験であろうとインフラエンジニアは喉から手が出るほど欲しいのが実状です。

### 即戦力になれる

![https://storage.googleapis.com/envader-article-images/infra-engineer/image9.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer/image9.jpg)

近年、多くの企業がクラウドサービスを利用しています。そのためインフラエンジニアにクラウド技術のスキルを求めていますが、まだそれほど多くのインフラエンジニアが対応しているわけではありません。

インフラエンジニアとしてクラウド技術を身につけていれば、即戦力として活躍できるチャンスがある状況なのです。

先述したように需要も高いことから、求められるスキルを身につけることで未経験でも即戦力として働ける環境となっています。

### リスキリングがしやすい

![https://storage.googleapis.com/envader-article-images/infra-engineer/image7.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer/image7.jpg)

インフラエンジニアはリスキリングがしやすい点も特徴です。需要が非常に高いことから、教材や学習サービスが豊富にあります。独学でスキルを習得できる環境が整っているのです。

独学が不安な場合は、スクールや研修サービスを利用しても良いでしょう。学ぶ機会・場所が多くあるため、リスキリングには格好の仕事です。

### キャリアチェンジしやすい

![https://storage.googleapis.com/envader-article-images/infra-engineer/image13.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer/image13.jpg)

キャリアチェンジしやすい点もインフラエンジニアの特徴と言えます。独学でスキルを習得できる環境が整っているため、仕事をしながらでも学べます。

またインフラエンジニアは、経験・実績が評価される業界です。学歴や職歴はあまり重視されないため、キャリアチェンジしやすい環境だとも言えます。勉強して身につけたスキルを十全に発揮できる実力を身につけてしまえば、キャリアチェンジも容易になるでしょう。

### 年齢が関係ない

![https://storage.googleapis.com/envader-article-images/infra-engineer/image6.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer/image6.jpg)

インフラエンジニアへの転職に年齢は関係ありません。重要なのは、スキルと実績です。未経験の場合、実績は難しいので資格を取得する方法があります。

ただ、24時間365日体制が求められることがあるため、年齢によっては体力的な問題で難しい可能性があります。転職をする際は、今後のキャリアアップを見据えてすると良いでしょう。

### 経験を活かす働き方がしやすい

![https://storage.googleapis.com/envader-article-images/infra-engineer/image5.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer/image5.jpg)

インフラエンジニアは、業務内容からコミュニケーション能力を求められます。メンバーや他部門と力を合わせて取り組まないといけないからです。

未経験の方の場合、それまで培ってきたコミュニケーション能力を活用できる可能性が高くなります。IT業界からの転職であっても、培った経験によってチーム内の業務を把握できるため、スムーズに業務を進められます。

## インフラエンジニアへの転職で必要なスキル

![https://storage.googleapis.com/envader-article-images/infra-engineer/image8.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer/image8.jpg)

インフラエンジニアへ転職する際、身につけておきたいスキルがあります。特に未経験の方の場合、以下の3つを意識して身につけるだけで大きく変わるので、要チェックです。

- 技術トレンドに合ったスキル
- コミュニケーション能力
- OSに関する知識・資格

### 技術トレンドに合ったスキル

![https://storage.googleapis.com/envader-article-images/infra-engineer/image11.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer/image11.jpg)

技術トレンドに合ったスキルは、インフラエンジニアでも特に必要なものです。クラウドや仮想化など、時代によって求めるインフラは変化しています。

インフラエンジニアは、そうした技術を常に吸収していかなければいけません。新しい技術だからこそ、今後の需要を見据えて取り入れていく必要があります。

例えば、クラウドサービスが増えることでインフラエンジニアの需要は減ると言われていました。ですが現在、クラウドサービスに対応できるインフラエンジニアが求められ、数は減るどころか増えています。

このように、インフラエンジニアとして活躍するのであれば、技術トレンドに合ったスキルを身につけることを心がけてください。

### コミュニケーション能力

![https://storage.googleapis.com/envader-article-images/infra-engineer/image4.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer/image4.jpg)

インフラエンジニアにとって、コミュニケーション能力は必須です。主に以下の場面で必要とされます。

- クライアントの要望をヒアリング
- クライアントの要望に添った提案
- クライアントへ運用・保守・通信障害の報告
- チームマネジメント

こうした業務で有利に働きます。特にクライアントの要望をヒアリングし、ニーズを満たした提案をしなければいけません。コミュニケーションが苦手な方は、専門の書籍で身につけると良いでしょう。

人と関わる業務が多いため、コミュニケーション能力は高いほど評価されます。

### OSに関する知識・資格

![https://storage.googleapis.com/envader-article-images/infra-engineer/image1.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer/image1.jpg)

インフラエンジニアはエンジニアなので、当然ながらOSに関する知識・資格が求められます。中でも代表的なスキルは以下です。

- サーバーの知識・スキル：Windows、Linux、UNIXなど
- システムの設計スキル
- ネットワークの知識とスキル
- プログラミングスキル
- セキュリティの知識
- クラウドサーバーの知識とスキル
- インフラ設計スキル
- ソフトウェアに関するスキル
- 仮想化の知識とスキル

こうした総合的な知識・スキルが必要です。資格を取得することで学べるため、総合的に学べる資格を取るのも良いでしょう。

客観的な指標にもなるので、転職時の評価にも期待できます。

## インフラエンジニアは24時間の対応が求められることも

![https://storage.googleapis.com/envader-article-images/infra-engineer/image3.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer/image3.jpg)

インフラエンジニアは、24時間対応のケースが多くあります。企業にもよりますが、どうしてもITインフラを止められないケースがあるためです。そのため、状況によっては夜勤となる可能性が大いにあります。

またシステム開発では土日休みではなく、シフト制になることも。転勤があることも多いため、安定した生活をしたい方にはあまり向いていません。

一方でそのような状況を改善すべく夜間対応をオフショア（海外）で実施している企業もあります。

## インフラエンジニアへの転職は未経験でもできる

![https://storage.googleapis.com/envader-article-images/infra-engineer/image12.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer/image12.jpg)

インフラエンジニアは、ITのインフラを支える欠かせない人材です。近年ますます需要が増えていることから、未経験でも転職できるチャンスが大いにあります。リスキリングもしやすい環境にあるため、自分のやりやすい形でスキルを習得できます。

転職の際は、クラウドや仮想化といった技術トレンドに合ったスキルを身につけることを心がけてください。クライアントと話すことも多いため、コミュニケーション能力も必須です。

専門的な知識・スキルに加え、常に学び成長し続ける気持ちがあればインフラエンジニアへの転職は未経験でもできます。IT業界への転職を考えている方は、ぜひ1度検討してみてください。

インフラエンジニアの需要はまだまだ高いと言えます。むしろ、クラウドサービスに対応できる人材こそ求められつつあるほどです。

未経験でも可能？インフラエンジニア・クラウドエンジニアへの転職

# きつい・やめとけ本当に？インフラエンジニアに向いているのはどんな人？

インフラエンジニアの仕事は、ブラック・きつい・やめとけなどと言われています。果たしてそれは本当なのでしょうか。

結論から言えば、インフラエンジニアには向いている人と向いていない人がいます。ほとんどの仕事でそうであるように、向いている人でなければ過酷に感じてしまうのは仕方がありません。

今回はインフラエンジニアがきついと言われる理由について解説しています。逆に仕事としての魅力も紹介するので、インフラエンジニアについて興味のあるかたはぜひ参考にしてください。

## インフラエンジニアの仕事はITインフラ

![https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image12.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image12.jpg)

インフラエンジニアは、企業のオフィス環境やサービス提供に必要なサーバー・ネットワークといったITインフラを専門的に取り扱う仕事です。我々が日々生活していく上で、なくてはならない人材と言っても過言ではありません。

そんなインフラエンジニアは、以下の2種類に分類されます。

- サーバーエンジニア：ソフトウェアのインストールなどを行う
- ネットワークエンジニア：データの送受信などをする機能を構築する

両方を担当することは少なく、どちらかをメインに担当するケースが多いことも特徴です。

また、最近はクラウド領域に特化したクラウドエンジニアという職種もインフラエンジニアとみなされています。

## インフラエンジニアがきつい・やめとけと言われる理由7選

![https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image1.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image1.jpg)

インフラエンジニアは、良く「きつい」「やめとけ」などと言われます。そんな風評を聞いていると、不安を覚える方も多いでしょう。

ここからは、主にそう言われる理由について解説します。大きな理由として、以下が筆頭格です。

- 急な対応が必要
- 夜勤がある
- 勉強し続けなければいけない
- 達成感を覚えにくい
- 問題が解決するまで退社できない
- 世間が休みでも仕事がある
- サーバールームが寒い

### 急な対応が必要

![https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image6.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image6.jpg)

予想外の問題が発生した場合、迅速な対応を求められます。設計の段階でトラブル無く進められたとしても、何かしらのアクシデントによって休日出勤となることも。

障害やトラブルが発生しないように監視や保守を徹底していたとしても、起こる時は起こります。そうした場合は対応に追われることになるため、どうしてもきついと感じてしまうのです。

### 夜勤がある

![https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image16.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image16.jpg)

夜勤があることも、インフラエンジニアの仕事がきついとされる理由です。人間は基本的に昼行性であるため、夜勤をすると体力・精神的に摩耗してしまいます。

急なトラブルだと夜遅くに対応することもあります。睡眠時間が少なくなり生活リズムが崩れる可能性は、常に考慮しておきましょう。

ただ、近年は夜間対応をオフショア（海外など）が担当することが増えています。時差を利用して対応できるため、効率的な方法です。

夜勤中心であったとしても、日中に用事をこなせるので効率的に動けるのも良いポイントと言えます。

### 勉強し続けなければいけない

![https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image9.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image9.jpg)

インフラエンジニアは現場主体の仕事ですが、勉強するべきことが多くあります。

- ネットワーク
- サーバー
- データベース
- クラウド

このような知識を常にアップデートし続けていかなければいけません。技術の進歩についていけないからです。

普段の業務をこなしながら、空き時間に勉強をする。仕事が好きで勉強も苦にならないという方でもないと、きついと感じてしまいます。

### 達成感を覚えにくい

![https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image2.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image2.jpg)

インフラエンジニアは、インフラを整える仕事です。目に見える達成感がないため、成果が見えにくい面があります。そのため達成感を覚えづらく、モチベーションを保ちにくいと感じてしまいます。

インフラ環境は、異常がないことが当たり前です。整備しても感謝されることが少ないため、報われないと感じる場面が多々あります。

### 問題が解決するまで退社できない

![https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image3.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image3.jpg)

インフラ環境に何か障害やトラブルが発生した場合、インフラエンジニアが対応します。ITインフラは社会基盤にもなっているため、放置して退社しては多くの人の生活に影響が出てしまいます。

そのため、障害やトラブルを解決するまで退社できません。問題が解決しないと拘束時間も長くなってしまうため、結果的にきつい仕事だと感じてしまいます。

### 世間が休みでも仕事がある

![https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image17.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image17.jpg)

インフラエンジニアは、世間が休みであってもインフラ環境を保守・監視しなければいけません。カレンダー通りの休みではなくシフト制となることも多く、家族や友人と休みを合わせにくい面があります。

- 週末に家族や友達と遊びたい
- 連休が欲しい

こうした希望のある方は、インフラエンジニアには少々不向きと言わざるを得ません。逆にシフト制でも全く問題ない方は、休みできついと感じることはほぼ無いでしょう。

### サーバールームが寒い

![https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image4.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image4.jpg)

インフラエンジニアが作業をするサーバールームは、基本的に冷房でしっかり冷やされています。サーバー自体が熱を帯びるため、熱暴走を起こさないよう冷やす必要があるからです。

- 寒さに弱い
- 冷え性

このように寒さが苦手な方にとっては、きついと感じる部分となっています。寒さに強い方でも、多少の防寒対策は必要です。

作業環境が快適でない点も、インフラエンジニアの仕事がきついと言われる所以となっています。

## インフラエンジニアはきついだけではない魅力がある

![https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image10.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image10.jpg)

インフラエンジニアは、ただきついだけではありません。きつい・やめとけと言われてもなお続けるだけの魅力があります。特に以下の点は、インフラエンジニアならではです。

- 学歴が関係ない
- スキルが身につきやすい
- 仕事に需要が高い
- 社会に貢献できる
- 1人で作業に集中できる

### 学歴が関係ない

![https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image14.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image14.jpg)

インフラエンジニアは、学歴が関係ありません。実力主義の世界なので、以下の点が主に評価されるからです。

- 実績
- 知識
- スキル
- 成果

中卒・高卒・大卒が同じ土俵で働けます。自分の実力でしっかり稼いでいきたい方にとって、魅力的な仕事であることは言うまでもないでしょう。

学歴で不安を感じている方でも、インフラエンジニアは挑戦できる仕事です。

### スキルが身につきやすい

![https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image8.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image8.jpg)

インフラエンジニアで求められる知識やスキルは、ITエンジニア全般で求められるものが多くあります。そのため、仕事をこなしていく中で自然と様々なスキルが身についていきます。

- 転職
- スキルアップ
- キャリアアップ

これらを目指す方にとって、最適な場所と言えるでしょう。常に勉強をし続ける必要はありますが、学んだ分だけ成長できる仕事です。

### 仕事の需要が高い

![https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image13.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image13.jpg)

インフラエンジニアは、ITインフラを支える仕事です。そのためIT社会の現在において社会的な需要が高く、安定した雇用・収入に期待できます。

仕事がなくなることがない安定した職業と言われるほどです。ITは生活に密着している技術なので、収入と安定を求めるのなら、インフラエンジニアは良い選択肢となります。

### 社会に貢献できる

![https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image7.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image7.jpg)

インフラエンジニアは社会貢献を実感できる仕事です。一般企業のみならず、医療機関や航空管制といった環境でも求められます。ITインフラを整備するインフラエンジニアは、多くの事業に必要とされているのです。

仕事を通じて社会貢献を実現したい方には、ピッタリの仕事と言えます。

### 1人で作業に集中できる

![https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image18.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image18.jpg)

インフラエンジニアの仕事は、基本的に1人で行います。もちろんチームで行う場合もありますが、作業時間のほとんどは1人です。

- 1人で作業したい
- 人間関係が苦手
- コミュニケーションをあまり取りたくない

このような方には快適な働き方になります。ただし、クライアントとの打ち合わせはあるため、全くコミュニケーションを取らない訳ではありません。

1人で作業することが多い仕事だと認識しておいてください。

## インフラエンジニアは将来性もある

![https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image5.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image5.jpg)

インフラエンジニアは、今後ますます需要が高まるITインフラを専門とする仕事です。オンプレミスの仕事がクラウドや仮想化によって減ったとしても、新しい技術にもインフラが求められます。

常に知識やスキルをアップデートしていくことで、最新の技術にも対応できるインフラエンジニアになれます。

決して楽な仕事ではありませんが、知識と経験を蓄えることで、SRE（サイトリライヤビリティエンジニア）など様々なキャリアへ進むことも可能です。

安定と将来性の両方に期待できる仕事と言えます。

## インフラエンジニアに向いている人

![https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image15.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image15.jpg)

インフラエンジニアには向いている人と向いていない人がいます。向いていない人がインフラエンジニアになった場合、きつい・つまらないと感じてしまいがちです。そのため、まずは自分が向いているかどうかを判断すると良いでしょう。

一般的に、インフラエンジニアに向いている人の特徴は、以下の3点が挙げられます。

- ITの勉強が好き
- 新しいことを学び続けられる
- 機械の作業が好き

これらを満たしている方は、インフラエンジニアに向いています。1人で黙々と機械に無糅て作業をし、新しい技術があればすぐに学ぶ意欲も必要です。

インフラエンジニアを目指している方は、自分が当てはまっているかどうかをまず考えてみてくださいね。

## インフラエンジニアはきついが社会を支える仕事

![https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image11.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-not-good/image11.jpg)

インフラエンジニアの仕事は「きつい」「つまらない」と言われ、人によってはブラックと呼ぶこともあります。その理由は、ITインフラを保守・整備するために発生するものばかりです。

ITインフラが障害を起こせば解決するまで対応をし、正常な状態が基本なので感謝もされず達成感もなかなか得られません。サーバールームも寒いことから、体調の面でもきついと感じる部分があります。

ですが、学歴が関係なく、仕事の需要も高いことから誰でも安定した収入を目指せます。社会貢献を実感できるのもインフラエンジニアならではです。

今やITサービスは拡大し続けており、それを支えるITインフラの仕事領域も拡大を続けています。きつい仕事という面がありますが、世の中のさまざまなITサービスを支える魅力的な仕事としてインフラエンジニアを検討してみてはいかがでしょうか。

インフラエンジニアの仕事は、ブラック・きつい・やめとけなどと言われています。果たしてそれは本当なのでしょうか。

きつい・やめとけ本当に？インフラエンジニアに向いているのはどんな人？

# インフラエンジニアはフリーランスで稼げる？需要は？どのような企業が求めているかを解説

昨今のIT技術発展により、ますます需要が高まっている仕事がインフラエンジニアです。多くの企業のインフラを支え、社会基盤を作っている仕事でもあります。

そんなインフラエンジニアの方の中には、フリーランスになりたいと考えている方がいます。フリーランスは、企業に所属していた時とは違い、全てを自分でしなければいけません。

今回は、フリーランスになりたいと考えているインフラエンジニアの方に向けて、需要や年収、案件について解説していきます。向いている人/向いていない人も紹介しているので、ぜひ参考にしてください。

## フリーランスのインフラエンジニアの需要は高い

![https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image1.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image1.jpg)

フリーランスとして独立するにあたって、最も不安を覚えるのが収入です。独立したとしても需要があるのかどうかは、その後の働き方が大きく変わる重要なポイントでもあります。

ですが結論から言えば、フリーランスのインフラエンジニアの需要は高い傾向にあります。特に以下の4つの理由は重要です。

- 新しい技術を欲しい企業が必ずある
- 自社開発のWebサービスを運用したい企業がある
- Web業界のベンチャー企業が求めている
- クラウド移行したい企業が増えている

### 新しい技術を欲しい企業が必ずある

![https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image12.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image12.jpg)

企業の中には、新しい技術を積極的に導入したい企業が必ずあります。例えば、昨今多くの企業が導入し始めているリモートワークなどです。元の出社へと戻った企業もあれば、リモートワークの採用を決めた企業もあります。

そうした時流に乗って新しい技術を欲する企業は、必ず出てきます。フリーランスのインフラエンジニアは、技術導入ができる存在として求められる可能性が高いでしょう。

### 自社開発のWebサービスを運用したい企業がある

![https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image14.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image14.jpg)

自社開発したWebサービスを運用している企業も一定数あります。クライアントからソフトウェア開発を請け負っている企業ではなく、提供している側の企業です。

そうした企業の場合、リモートワークが定着していることが多く、結果としてフリーランスのインフラエンジニアが参入しやすい土壌ができています。インフラエンジニアが担う領域をカバーできるエンジニアが少ないこともあり、フリーランスとして力を求められることも多いでしょう。

### Web業界のベンチャー企業が求めている

![https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image9.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image9.jpg)

Web業界のベンチャー企業の多くが、フリーランスのインフラエンジニアを求めています。リモートワーク環境の整備が進んだことで、案件を発注しやすくなったことが背景にあります。

またベンチャー企業やスタートアップ企業の多くは、少数精鋭です。人員が常に不足しているため、フリーランスのインフラエンジニアとリモートワークで仕事をすることも多くあります。

### クラウドへ移行したい企業がある

![https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image16.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image16.jpg)

クラウドへ移行したい企業からの需要も高まりつつあります。クラウドサービスが主流になりつつある昨今、クラウド対応可能なインフラエンジニアは常に求められています。

自社の情報システムをクラウド上に構築して運用するためには、インフラエンジニアは必須です。リモートワーク環境がより広がれば、更に案件が増えていくでしょう。

## フリーランスのインフラエンジニアの年収相場

![https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image3.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image3.jpg)

フリーランスのインフラエンジニアの年収相場は、約770万円ほどです。月単価にすると約60～70万円ほどとなります。上流工程から入ることもできるため、単価が高いことが理由に挙げられます。

最高年収は1,600万円ほどと幅広く、年収を上げたいのならスキル・実績を積み上げていきましょう。

インフラエンジニアは需要も高いため、独力で成長していける方なら、ステップアップは大いに可能です。

## フリーランスのインフラエンジニア向けの案件は少ない傾向

![https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image13.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image13.jpg)

フリーランスのインフラエンジニア向けの案件は、他のエンジニア職と比べて少ない傾向にあります。ただ、案件が少ないからといって悲嘆することはありません。人材不足であるため、多くの企業がインフラエンジニアを求めているからです。

そのため、案件は少ないが受注しやすいといった現象が起こっています。一方で案件を受注するには営業スキルも必要です。ポートフォリオを作成し、案件獲得に向けて活用していきましょう。

## フリーランスのインフラエンジニアには実務経験が必要

![https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image8.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image8.jpg)

フリーランスのインフラエンジニアとして独立するためには、実務経験が必要です。案件の中には「○○の経験が○年以上」といったように条件のあるものが多くあります。経験がないフリーランスには圧倒的に不利です。

未経験の方が受注できる案件は、ほとんどありません。もし受けられても3年程度ならば足切りされるなんてことも。

そのため、未経験の方はまずインフラエンジニアとしての経験を積むために就職してください。先輩社員から様々なスキルや知識を吸収でき、人脈も作れるため独立後の不安を解消できます。

## インラフエンジニアがフリーランスになるメリット

![https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image6.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image6.jpg)

インフラエンジニアの方がフリーランスになると、どのようなメリットがあるのでしょうか。フリーランスは企業に縛られない働き方であり、憧れを抱く方も多くいます。

フリーランスのインフラエンジニアとなった場合、以下のメリットがあります。

- やりたい仕事を選べる
- 働き方が自由
- 高単価の案件が多い

### やりたい仕事を選べる

![https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image10.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image10.jpg)

フリーランスのインフラエンジニアとなったことで最も大きい点が、自分のやりたい仕事を自由に選べる点です。自分のスキルや希望に合った仕事だけをできます。会社員の場合、担当する業務が決まっていることもあって、自由はほとんどありません。

ですがフリーランスになると、誰からも文句を言われることもなく好きな仕事ができます。エンジニアとして新しいことにチャレンジすることはもちろん、全く違う仕事を掛け持ちすることも自由です。

自由になった分の責任は生じますが、やりたい仕事を選べる点は大きなメリットと言えます。

### 働き方が自由

![https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image15.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image15.jpg)

リモートワークが可能な案件であれば、好きな働き方ができます。気分転換にカフェで仕事をしたり、遅い時間に起きて仕事したりしても問題ありません。その日の予定や気分に合わせて自由自在です。

期日までに成果物を納品すればいいだけなら、好きな時間に働けます。昼夜逆転しても、しっかり納品していれば何も言われません。

このように会社員よりも遙かに自由な働き方ができるのが、フリーランスです。

### 高単位の案件が多い

![https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image7.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image7.jpg)

フリーランスのインフラエンジニア向けの案件は、高単価のものが比較的多くあります。年収アップをするなら、期待しても良いでしょう。

- 案件の受注数を増やす
- 高単価な案件にチャレンジする

こういった手法を使って年収をアップできます。

会社員の場合、年収をアップさせるためには企業の業績や上司からの評価といった第三者が介在しています。自分ではコントロールできない部分です。

しかしフリーランスのエンジニアは、自分の能力・仕事量がそのまま収入へと直結するため、やりがいの面でも一線を画しています。

## インフラエンジニアがフリーランスになるデメリット

![https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image11.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image11.jpg)

インフラエンジニアがフリーランスになると、メリットが大きいように感じられます。ですが同時にデメリットも存在します。

フリーランスは企業に属さないため、常に不安との戦いです。中でも以下の2つは、必ず直面します。独立前に覚悟しておきましょう。

- 収入が安定しない
- 事務作業を自分しなければならない

### 収入が安定しない

![https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image2.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image2.jpg)

インフラエンジニアを問わず、フリーランスは収入が全く安定しません。仕事量も月によって変動するため、収入が少ない月は不安に苛まれます。

- 思うようおに案件を受注できない
- 低単価の案件にしか採用されない
- 怪我や病気になった

これまで会社員として安定した収入があると、余計に不安を覚えることも。そのためフリーランスには、ある程度の楽観視が必要です。何とかなるさで乗り越えるしかありません。

自分の体が資本であるため、怪我や病気にならないように健康にも気をつける必要があります。不安な場合は、フリーランス向けの保険に加入するなど安心を得られる方法をとりましょう。

### 事務作業を自分でしなければならない

![https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image4.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image4.jpg)

フリーランスは事務作業も全て自分でしなければいけません。代表格は確定申告です。他にも以下の事務作業が必要になります。

- 契約書
- 誓約書
- 税金関係の手続き
- 年末調整

会計ソフトを使うことである程度の簡略化はできますが、雑務としてのしかかる点は変わりません。

特に確定申告の関係は、いい加減にすると税務署に指摘されることも。隙間時間を使ってこまめに事務作業を片付けていきましょう。

## フリーランスのインフラエンジニアは高単価に期待できる働き方

![https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image5.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-freelancer/image5.jpg)

フリーランスのインフラエンジニアは需要が高く、多くの現場で重宝されます。案件は少ないものの高単価なものが多く、年収1,000万円超えのプレイヤーもいるほどです。ただし実務経験が必要なため、未経験の方はまずインフラエンジニアを募集している企業に就職し、経験を積みましょう。

またフリーランスには向き不向きがあります。自由である一方、収入が安定せず雑務が増えるため、心身共に負担が増えます。

インフラエンジニアとして独立したい方は、自分がフリーランスに向いているかどうかを考えた上で、実行してくださいね。

フリーランスになりたいと考えているインフラエンジニアの方に向けて、需要や年収、案件について解説していきます。向いている人/向いていない人も紹介しているので、ぜひ参考にしてください。

インフラエンジニアはフリーランスで稼げる？需要は？どのような企業が求めているかを解説

# インフラエンジニア将来のキャリアパス SREや上流工程

インフラエンジニアの方で、将来のキャリアパスで悩んでいる方は多くいます。

インフラエンジニアは、ネットワークやサーバーといったITインフラを支える大切な存在です。今やなくてはならない人材とも言えます。活躍の場が広がっているからこそ、キャリアパスは重要です。

今回はそんなインフラエンジニアのキャリアパスについて解説します。将来設計で悩んでいる方は必見ですよ。

## インフラエンジニアのキャリアパスはまず3年の実務経験から

![https://storage.googleapis.com/envader-article-images/infra-engineer-career/image7.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-career/image7.jpg)

インフラエンジニアのキャリアパスを考えるには、まず3年の実務経験が必要です。未経験では受けられる案件が少ないため、実績と経験を積むことを第一に考えてください。

基本的な流れとしては、3年ほど実務経験を積んでから上流工程を目指す形です。そうすることで、フリーランスとなったとしても案件を受注できるだけの信頼が得られるでしょう。

インフラエンジニアの仕事の中には、運用など一般的につまらないと言われる業務があります。ですが近年はセキュリティ需要の高まりもあって、刺激のある仕事として変容を遂げています。3年間、全く刺激のない仕事にはなりません。

## インフラエンジニアのキャリアパスは3種類

![https://storage.googleapis.com/envader-article-images/infra-engineer-career/image12.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-career/image12.jpg)

インフラエンジニアのキャリアパスは、大きく分けて3種類あります。それぞれ進む道が違うため、まずはどのキャリアになりたいかを考えましょう。

- スペシャリスト
- マネジメント
- ゼネラリスト

### スペシャリスト

![https://storage.googleapis.com/envader-article-images/infra-engineer-career/image2.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-career/image2.jpg)

スペシャリストは、その名の通り技術に特化したインフラエンジニアです。以下の3種類に分けられます。

- インフラスペシャリスト
- クラウドエンジニア
- セキュリティエンジニア

### インフラスペシャリスト

インフラスペシャリストは、ネットワークとサーバーのスキルを極めることでなれるキャリアです。

- 設計
- 構築

以上がメインの業務となります。最新の技術を駆使して、他では実現できない提案やサービスを行います。情報収集とスキル習得が常に求められるキャリアです。

### クラウドエンジニア

クラウドエンジニアは、近年注目されているクラウド上にインフラ環境を設計・構築するエンジニアです。

- 新規でクラウド環境を構築
- 既にあるシステムをクラウドに移行

オンプレミスでクラウドに移行する方法が主流でしたが、最近では既にサービスとして提供されているものを使うのが一般的です。クラウドの知識は今後ますます求められるため、将来性の高いキャリアパスと言えます。

### セキュリティエンジニア

セキュリティエンジニアは、サイバー攻撃に対して攻撃・対策を行うエンジニアです。情報資産の価値が見直され、流出事故も鑑みてニーズが高まっています。

サイバー攻撃は年々巧妙化しているため、兼任のエンジニアではなく専門的な知識・スキルを持ったエンジニアが求められ始めています。責任が非常に重たい一方、ニーズが高まっているため受注しやすいキャリアです。

### マネジメント

![https://storage.googleapis.com/envader-article-images/infra-engineer-career/image1.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-career/image1.jpg)

マネジメントは、プロジェクトやチームを管理する役割を担っていくキャリアパスとなります。インフラエンジニアとしてのスキルはもちろん、コミュニケーション能力や調整力が必要です。

キャリアは以下の3つがあります。

- プロジェクトマネージャー
- ITアーキテクト
- ITコンサルタント

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

プロジェクトマネージャーは、マネジメントの代表的なキャリアパスです。顧客の要望をヒアリングし、予算やスケジュールを調整しながらプロジェクト達成まで進めていきます。

- スケジュール管理
- プロジェクトの進捗管理
- 顧客との調整
- プロジェクトの修正案の立案
- 全体の業務の取りまとめ
- リスク管理
- トラブル対応

チームを取りまとめるキャリアであるため、業務は多岐に渡ります。

### ITアーキテクト

ITアーキテクトは、最適なITシステムの企画・立案を行い、企業経営やビジネス戦略を決定する役割を担うキャリアです。ITインフラに止まらず、企業の経営方針まで考えなくてはいけないため、担当する業務が非常に広範囲となります。

IT戦略は今後ますます重要な要素となることもあって、多くの企業に求められるでしょう。ただし専門性の高い知識・スキルが必要です。

### ITコンサルタント

ITコンサルタントは、顧客が抱えている悩みをITインフラによって解決する役割を担うキャリアです。顧客と二人三脚で課題解決に取り組んでいきます。そのため、以下の能力が重要です。

- コミュニケーション能力
- 形成戦略の視点
- 提案力

企業の課題を解決する方法がどこに転がっているのかわかりません。常に市場の動向や最新技術にアンテナを張り巡らせ、インプットしていく貪欲さが求められます。

### ゼネラリスト

![https://storage.googleapis.com/envader-article-images/infra-engineer-career/image3.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-career/image3.jpg)

ゼネラリストは、何でもできるインフラエンジニアを指します。自分1人で運用から保守までこなせる万能選手です。以下の2つに分けられます。

- フルスタックエンジニア
- フリーランスエンジニア

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

フルスタックエンジニアは、ITインフラにおける工程を全て1人で対応できるオールラウンダーです。

- 設計
- 構築
- 運用
- 保守

フルスタックエンジニアは1人で全て行えるため、企業としては人件費を削減してインフラ構築ができます。特に我が国で99.7%の数を占める中小企業では、重宝される存在と言えます。

### フリーランスエンジニア

フリーランスエンジニアは、独立して業務をこなすインフラエンジニアです。インフラエンジニアの人材は常に不足しているため、重宝される存在となってます。

自由な働き方ができる一方で、収入は安定しません。トラブル時の対応も自分でしなければいけないため、ストレスや不安と常に戦うこととなります。

自分の能力だけで収入を増やしていきたい方にオススメのキャリアです。

https://envader.plus/article/110

## インフラエンジニアのキャリアパスで必要なスキル

![https://storage.googleapis.com/envader-article-images/infra-engineer-career/image10.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-career/image10.jpg)

インフラエンジニアのキャリアパスでは、スキルが重要になってきます。活躍できるためにはスキルを習得し、実績を積み重ねていくしかありません。特にインフラだけにこだわらず、以下のスキルも身につけていきましょう。

- プログラミングの知識・スキル
- クラウドの知識・スキル
- 資格

### プログラミングの知識・スキル

![https://storage.googleapis.com/envader-article-images/infra-engineer-career/image11.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-career/image11.jpg)

プログラミングの知識・スキルは重要です。近年多くの企業が導入を検討しているクラウドは、ハードウェアをプログラミングで動かします。サーバーの起動すら、プログラムによって行っているのです。

- Shell
- Python
- Ruby

これらの言語を習得しておくことで、ツールの選択肢を増やせます。結果的により幅広い工程に関われるため、キャリアパスでも有利になります。

### クラウドの知識・スキル

![https://storage.googleapis.com/envader-article-images/infra-engineer-career/image8.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-career/image8.jpg)

先述したように、クラウド上でシステムを動かすことが増えています。クラウド技術はこれからの技術でもあるため、進化していくにつれて利便性の向上にも期待できます。そうした際にも対応できるクラウドの知識・スキルは、インフラエンジニアとして重要です。

既存のインフラが全てクラウドへ置き換わることは考えにくいのですが、キャリアパスのために学んでおくことで次へと繋げられます。

### 資格

![https://storage.googleapis.com/envader-article-images/infra-engineer-career/image5.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-career/image5.jpg)

インフラエンジニアで必須とされる資格はありません。ですが、資格は知識・スキルを客観的に証明するものとして重要な役割を持っています。キャリアパスを考える際に、取っておいて損はありません。

様々な資格がありますが、中でもインフラエンジニアとして挑戦していきたいのは以下です。

- CCNP（Cisco Certified Network Professional）
- LinuC
- AWS認定ソリューションアーキテクト
- プロジェクトマネージャ試験
- ITストラテジスト
- GCC認定資格
- ネットワークスペシャリスト
- データスペシャリスト
- 応用情報処理技術者

他にも様々な資格があるので、最終的なキャリアパスを見据えて挑戦してください。

## インフラエンジニアのキャリアパスは計画性が大事

![https://storage.googleapis.com/envader-article-images/infra-engineer-career/image4.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-career/image4.jpg)

インフラエンジニアのキャリアパスは、計画性が大切です。最終的にどのようなエンジニアになりたいのかを決めた上で、逆算して考えるようにしましょう。

未経験の方は、実務をこなしながら少しずつ将来のキャリアを見据えていってください。幅広いキャリアパスがある一方で、最終地点までたどり着くには難易度が高いからです。

しっかり計画を立てて、真っ直ぐ進んでいきましょう。

## インフラエンジニアからSREを目指すキャリアパス

![https://storage.googleapis.com/envader-article-images/infra-engineer-career/image9.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-career/image9.jpg)

インフラエンジニアのキャリアパスを考える上で注目したいのが、SREです。インフラエンジニアがインフラのみを業務対象としていることに比べ、SREは信頼性を高める活動全てが業務範囲となります。いわば、1社に1人は欲しい何でもできるエンジニアです。

インフラエンジニアからのキャリアパスを考えると、以下の流れになります。

1. アプリケーション安定稼働させるITインフラの構築や運用を習得
2. アプリケーション開発や運用のスキルを習得
3. SREに関する方法論を理解する

これらのことからもわかるように、インフラエンジニアに別のスキルを身につけるキャリアパスです。インフラ・アプリケーションともに高い技術を持っていることが求められるため、希少な人材として重宝されます。

## インフラエンジニアのキャリアパスは目標から逆算して考えること

![https://storage.googleapis.com/envader-article-images/infra-engineer-career/image6.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-career/image6.jpg)

インフラエンジニアは将来性のある仕事です。ITインフラを運用・保守するため、今後ますます需要が見込まれます。そのため、インフラエンジニアとしてのキャリアパスは幅広くなっています。

スペシャリストになるかマネジメントになるか、もしくはオールラウンダーになるかは、その人次第です。ですが、どれも並大抵の努力でなれるものではありません。実績はもちろん、経験と学習に裏打ちされたスキルが必要です。時には客観的な証明として資格も求められるでしょう。

今後のキャリアを考えている方は、まず自分の将来像を描いてから、計画立ててキャリアを練ってくださいね。

インフラエンジニアは、ネットワークやサーバーといったITインフラを支える大切な存在です。今やなくてはならない人材とも言えます。活躍の場が広がっているからこそ、キャリアパスは重要です。

インフラエンジニア将来のキャリアパス SREや上流工程

# インフラエンジニアは高収入？年収についての分析

インフラエンジニアは、高収入に期待できる仕事として注目を集めています。未経験でも転職しやすいことから、次のキャリアとして考えている方も多いでしょう。

そんな中で気になるのが、インフラエンジニアの年収です。結論から言えば、インフラエンジニアは稼げます。ですが、誰でも稼げるわけではありません。

今回は、そんなインフラエンジニアの年収について詳しく解説していきます。年収をアップさせる方法も紹介しているので、ぜひ参考にしてください。

## インフラエンジニアはITインフラを担う仕事

![https://storage.googleapis.com/envader-article-images/infra-engineer-income/image1.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-income/image1.jpg)

インフラエンジニアは、ITインフラを担う仕事です。IT社会である現代において欠かせない仕事であり、我々の生活に密着している技術を守っています。

その仕事内容は、大きく分けて以下の3つです。

- 設計
- 構築
- 運用

近年はクラウド化に伴い、クラウド対応ができる人材の需要が高まっています。知識・スキルを身につけることで将来性にも期待できます。

## インフラエンジニアの平均年収は約539万円

![https://storage.googleapis.com/envader-article-images/infra-engineer-income/image13.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-income/image13.jpg)

出典：[求人ボックス](https://xn--pckua2a7gp15o89zb.com/%E3%82%A4%E3%83%B3%E3%83%95%E3%83%A9%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E5%B9%B4%E5%8F%8E%E3%83%BB%E6%99%82%E7%B5%A6)

インフラエンジニアの平均年収は、約539万円です。中には1,000万円を超えるプレイヤーもおり、稼げる職種だと言えます。日本の平均年収と比べても高い傾向にあります。

- 正社員：平均年収539万円
- 派遣社員：平均時給2,236円
- アルバイト・パート：平均時給1,102円

地域別の年収においても、やはり最も高いのは関東です。次いで関西となるため、首都近郊もしくは都市圏に近くなるにつれて年収が上がりやすいと言えます。

## インフラエンジニアは1,000万円以上の年収も余裕で可能

![https://storage.googleapis.com/envader-article-images/infra-engineer-income/image2.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-income/image2.jpg)

インフラエンジニアの平均年収は約539万円ほどですが、それ以上を稼いでいる方も多くいます。中には1,000万円以上稼いでいる方もいるほどです。

1,000万円と聞くと難しいように感じてしまいますが、知識・スキルを身につけていけば誰もが狙えるゾーンとなっています。特に以下の方法はオススメです。

- 大企業に勤める
- 外資系企業に勤める
- マネジメント能力を身につける
- フリーランスエンジニアとして独立する
- スキル・技術を磨き続ける

### 大企業に勤める

![https://storage.googleapis.com/envader-article-images/infra-engineer-income/image18.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-income/image18.jpg)

王道ですが、大企業に勤める方法はオススメです。中小企業とは企業の力が全く違うため、収入面で大きな差が開きます。

以下は、厚生労働省のデータを元に求人ボックスが出した年収の差です。

![https://storage.googleapis.com/envader-article-images/infra-engineer-income/image7.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-income/image7.jpg)

出典：[求人ボックス](https://xn--pckua2a7gp15o89zb.com/%E3%82%A4%E3%83%B3%E3%83%95%E3%83%A9%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E5%B9%B4%E5%8F%8E%E3%83%BB%E6%99%82%E7%B5%A6)

これらを見るとわかるように、企業規模によって年収に大きな差があります。最大で118万円もの差が生じています。

大企業では大規模な案件を取り扱っていることも多いため、必然的に経験を積める環境が整っている点も強みです。
将来的に多くの選択肢を得たいのなら、大企業は外せない選択肢となります。

### 外資系企業に勤める

![https://storage.googleapis.com/envader-article-images/infra-engineer-income/image12.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-income/image12.jpg)

外資系企業に勤めるのもオススメです。実力主義の世界であるため環境は過酷ですが、成果を出し続けることで収入アップを見込めます。特に世界的な外資系企業であれば、いち早く年収1,000万円を達成できるでしょう。

マネージャーのような管理職を目指せば、更に近道となります。ただし自分から努力し成長する人材でなければ、振り落とされる可能性が高い世界です。

### マネジメント能力を身につける

![https://storage.googleapis.com/envader-article-images/infra-engineer-income/image4.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-income/image4.jpg)

会社員として年収1,000万円を目指す場合、インフラエンジニアとしてのスキルだけではなかなかたどり着けません。マネジメント能力を身につけ、チームリーダーとして引っ張って行く力が必要になります。

- プロジェクトを期限内に完遂する
- 予算内で納める
- メンバーを引率して成功に導く

こうした実績が求められます。特に近年はマネジメント能力のある人材の需要が高まっていることから、収入アップを狙うなら意識しましょう。

### フリーランスエンジニアとして独立する

![https://storage.googleapis.com/envader-article-images/infra-engineer-income/image8.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-income/image8.jpg)

経験・実績のある方向けの方法ですが、フリーランスエンジニアとして独立する方法もオススメです。企業に属さず個人で高単価の案件を獲得していくことで、年収1,000万円を目指せます。

インフラエンジニアとして実務経験をどれだけ積んでいるかによって変わってくるため、未経験者はどこか企業に所属していく方が無難です。

一方で、エンジニアに限らずフリーランスは月の収入が安定しない側面を持ちます。安定した収入を求める方には向いていません。

### スキル・技術を磨き続ける

![https://storage.googleapis.com/envader-article-images/infra-engineer-income/image17.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-income/image17.jpg)

スキル・技術を磨き続けることも大切です。IT技術は常に進歩しているため、勉強しなければ時流に追いつけなくなります。

近年はクラウドへ対応できるインフラエンジニアが求められています。そのため、クラウドへ対応できないインフラエンジニアは、必然的に仕事が無くなっていくでしょう。

スキルの他、資格もオススメです。知識・技術を持っている客観的な証明となるため、年収アップに期待できます。企業の中には資格取得に向けて補助をしてくれるところもあります。ぜひ活用してください。

## インフラエンジニアは未経験からでも年収アップが可能

![https://storage.googleapis.com/envader-article-images/infra-engineer-income/image15.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-income/image15.jpg)

インフラエンジニアは未経験からでも年収アップは可能です。ただし未経験の場合、最初の年収は約250～380万円が平均値となります。

未経験であることがネックなため、年収をアップさせるには様々な案件を通して実績を積み上げていくしかありません。他には資格の取得もオススメです。

先述したように、未経験でいきなりフリーランスになると案件獲得で苦労する場面が多くなります。一旦は企業に所属し、実務経験を積んでからの方が無難です。3年ほど実務経験があれば、案件獲得もしやすくなるでしょう。

## インフラエンジニアはSESでもちゃんと稼げる

![https://storage.googleapis.com/envader-article-images/infra-engineer-income/image3.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-income/image3.jpg)

インフラエンジニアとセットで聞かれるのが、SESです。SESとは、所属しているインフラエンジニアをクライアント先の企業に派遣する仕組みのこと。正社員や派遣社員とはまた違った働き方になる点が特徴です。

そんなSESですが、以下のメリットがあります。これらを活かすことで、ちゃんと稼げる世界になっています。

- 様々な現場を経験できる
- 人脈を作れる
- 高単価な案件が増えている

### 様々な現場を経験できる

![https://storage.googleapis.com/envader-article-images/infra-engineer-income/image10.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-income/image10.jpg)

SESはプロジェクトごとに仕事内容が変わります。サーバーと一口に言っても、プロジェクトごとに使っているサーバーが違うからです。中には複数のサーバーを使っているところも。

そのため、様々な現場を経験できます。実績において、経験している現場の数は強みになります。キャリアのスタートラインとして、後々活きてくる要素です。

### 人脈を作れる

![https://storage.googleapis.com/envader-article-images/infra-engineer-income/image14.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-income/image14.jpg)

SESはプロジェクトごとに働き先の企業が変わります。働き先の企業が変わるということは、その分多くの人と一緒に仕事ができます。

- 上場企業のプロジェクトマネージャー
- 現場でも活躍するベンチャー企業の社長
- フリーランスのエンジニア

普段は一緒に働けないような人たちと出会えるチャンスがあるのです。一緒に働くことでのスキルアップはもちろん、人脈も作れます。

将来的にフリーランスを考えている方にとって、人脈は大切です。SESとして働くことで人脈を作り続けられる点は、大きなメリットと言えます。

### 高単価な案件が増えている

![https://storage.googleapis.com/envader-article-images/infra-engineer-income/image11.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-income/image11.jpg)

SESは一般的に低収入だと言われています。事実、日本の多重下請け構造によって、年収の企業は多くあります。そうした背景があるため、低収入の面は否定できません。

ですが一方で、高単価の案件が増えています。基本的に総売上の高い企業ほど社員に還元してくれる傾向にあるため、数字から判断すると良いでしょう。

優良な企業ともなれば、年収600万円を超えるところもあります。SESは会社選びが大切です。

## インフラエンジニア向けのホワイト企業が増えている

![https://storage.googleapis.com/envader-article-images/infra-engineer-income/image16.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-income/image16.jpg)

インフラエンジニアは「きつい」「ブラック」などと良く言われます。ですが、実際は大きく異なります。近年はホワイト企業も増えており、ライフワークバランスを取れる働き方が可能です。

その要因としては、以下の2つがあります。

- クラウド事業が増えた
- そもそも誤解が蔓延している

### クラウド事業が増えた

![https://storage.googleapis.com/envader-article-images/infra-engineer-income/image5.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-income/image5.jpg)

IT技術の発達により、クラウド事業が増えてきています。インフラ環境がクラウド化されたことによって、物理的なインフラ調達・管理をする必要がなくなったのです。

クラウド事業が登場する前は、自社が管理する施設内でインフラを設置する方法が主流でした。物理的な機器のため、故障や異常が発生した際は残業や休日出勤が求められたのです。

ですがクラウド化によって物理的なインフラを調達・管理する必要がなくなり、インターネットを介してインフラの構築・運用ができるようになっています。

クラウドへの知識・スキルは必要ですが、きついと言われる働き方は解消されつつあります。

### そもそも誤解が蔓延している

![https://storage.googleapis.com/envader-article-images/infra-engineer-income/image9.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-income/image9.jpg)

インフラエンジニアはネガティブな印象が蔓延している仕事です。

- 緊急時のトラブル対応
- 夜勤や休日出勤がある
- 常に勉強しなければいけない
- 裏方の仕事である
- スキルアップが難しい
- 単純作業が多い
- 年収が低い

こうした意見が良く見られます。ですが、これらの意見は少し古いものばかりです。クラウドによって働き方が変わり、オンショアによって夜勤が無い企業すらあります。

年収が低いとされていますが、しっかり学んでスキルアップしていけば、誰でも1,000万円以上稼げることが可能です。

巷に溢れるインフラエンジニアの印象は、そのほとんどが的を射ていません。自分で努力し成長していける人ならば、問題なく稼いでいけます。

## インフラエンジニアは年収アップしやすい職業

![https://storage.googleapis.com/envader-article-images/infra-engineer-income/image6.jpg](https://storage.googleapis.com/envader-article-images/infra-engineer-income/image6.jpg)

インフラエンジニアは、年収をアップさせやすい職業です。平均年収は539万円ですが、知識・スキルを身につけていき、1,000万円以上を稼いでいる方も多くいます。

年収を上げるには、大企業や外資系企業に就職し経験を積んでいくことが近道です。近年はマネジメント能力を求められる場面が増えていることから、挑戦してみるのも良いでしょう。

かつてと違い、インフラエンジニアでもホワイト企業が増えてきています。クラウド化によって働きやすくなったため、参入するには絶好のタイミングです。常に技術を学び成長し続けられる方は、ぜひ1度挑戦してみてくださいね。

今回は、そんなインフラエンジニアの年収について詳しく解説していきます。年収をアップさせる方法も紹介しているので、ぜひ参考にしてください。

インフラエンジニアは高収入？年収についての分析

# クラウドエンジニアってどんな職業？年収や将来性は

IT技術の進歩により、近年注目を集めているクラウドエンジニア。

ですが、クラウドエンジニアと調べると「きつい」「やめとけ」と検索候補に出てきます。

なぜ、マイナスのイメージを持たれているのか。そもそも目指すべき職種なのか。

今回は、クラウドエンジニアが「きつい」「やめとけ」と言われる理由の他、年収や将来性について解説します。

クラウドエンジニアを目指している方は、ぜひ参考にしてください。

## クラウドエンジニアがきつい・やめとけと言われる理由

![https://storage.googleapis.com/envader-article-images/cloud-engineer/image1.jpg](https://storage.googleapis.com/envader-article-images/cloud-engineer/image1.jpg)

クラウドエンジニアの需要は、日々高まっています。多くの企業が求める人材です。なのにマイナスのイメージを持たれてしまうのには、理由があります。

特に以下の6つの理由が関係しています。

- 責任が重い
- 緊急時の対応が必要
- 資格の取得が難しい
- 幅広いスキルが必要
- 最新情報を常に収集しなければならない
- コミュニケーション能力・ビジネススキルが必要

### 責任が重い

![https://storage.googleapis.com/envader-article-images/cloud-engineer/image11.jpg](https://storage.googleapis.com/envader-article-images/cloud-engineer/image11.jpg)

クラウドエンジニアは、サーバーやネットワークを管理・保守する仕事です。ITインフラは企業の経営に直結します。通常運転していることが当たり前なので、問題発生は起こってはいけないと考えられています。

クラウドITインフラで障害が発生すると、ベンダー側の問題が解決されないとシステムを復旧できません。一方で、少しでも障害が起こると、クライアントからの風当たりが強くなることも。

ベンダー側で問題を解決してくれなければ責められ続けるため、「きつい」と感じる場合があります。責任が重いことから、体力的・精神的にも厳しい仕事です。

### 緊急時の対応が必要

![https://storage.googleapis.com/envader-article-images/cloud-engineer/image3.jpg](https://storage.googleapis.com/envader-article-images/cloud-engineer/image3.jpg)

クラウドエンジニアは、ITインフラの根幹を担う仕事です。システムの保守・運用を守備範囲としている場合、サーバーやネットワークに障害が発生すると緊急で対応しなければいけません。

- サーバーダウン
- システムエラー
- 社内ネットワークに接続できない
- インターネットに接続できない

このような状態になると、企業は業務に支障を来します。対応によっては、多額の損失を出すことにもなりかねません。

トラブルは夜間・休日関係なく起こります。そのため、クラウドエンジニアは日時に関係なく障害対応を求められることがあります。

### 資格の取得が難しい

![https://storage.googleapis.com/envader-article-images/cloud-engineer/image7.jpg](https://storage.googleapis.com/envader-article-images/cloud-engineer/image7.jpg)

クラウドエンジニアが取得するべき資格は、全体的に難易度の高いものが多くあります。エンジニアとして最新の技術を身につけ続けなければいけませんが、そのハードルが高いのです。

例えば、以下の資格が代表格でしょう。

- AWS認定資格
- Google Cloud認定資格
- Microsoft Azure認定資格

いずれも一朝一夕の勉強で取得できる資格ではありません。IT技術は加速度的に進んでいきますから、数年おきの再認定が必要になることも。

資格については、以下の記事で解説しています。ぜひ参考にしてください。

https://envader.plus/article/5
https://envader.plus/article/106
https://envader.plus/article/105

### 幅広いスキルが必要

![https://storage.googleapis.com/envader-article-images/cloud-engineer/image2.jpg](https://storage.googleapis.com/envader-article-images/cloud-engineer/image2.jpg)

クラウドエンジニアは、業務内容上、幅広いスキルを求められます。クラウドサービスを利用してITインフラを構築するため、最低でも以下のスキルを身につけておかなければなりません。

- パブリッククラウドの知識・経験
- Linux

これらに加え、データベースやオンプレミスの知識・経験が必要になることもあります。幅広くスキルを身につけなければいけないため、きついと認識されているのです。

### 最新情報を常に収集しなければいけない

![https://storage.googleapis.com/envader-article-images/cloud-engineer/image4.jpg](https://storage.googleapis.com/envader-article-images/cloud-engineer/image4.jpg)

クラウドエンジニアが常に触れているのが、クラウド技術です。クラウド技術は常に進歩し続けているため、最新情報を収集し続けなければいけません。

AWSのように既存のクラウドサービスであっても、細部のサービスが常に増え続けている状態です。AWSならば2023年3月時点で200種類以上もの数に上ります。

クラウドエンジニアは、新しいサービスの提供もしなければいけません。時代に即した提案ができるように、常にアンテナを貼り続けていく必要があります。

### コミュニケーション能力・ビジネススキルが必要

![https://storage.googleapis.com/envader-article-images/cloud-engineer/image6.jpg](https://storage.googleapis.com/envader-article-images/cloud-engineer/image6.jpg)

クラウドエンジニアは、コミュニケーション能力とビジネススキルも求められます。様々な分野のエンジニアと連携を取りながら業務を進めるからです。

エンジニアの中でも、多数の人とコミュニケーションを取るエンジニアとも言えます。クライアントとの打ち合わせも行うため、ビジネススキルも必要です。

スムーズに業務を進められないと、不安を抱かれてしまうため嫌でも身につけるしかありません。対人スキルに自信の無い方にとってみれば、きついと感じることがあるでしょう。

## クラウドエンジニアの年収

![https://storage.googleapis.com/envader-article-images/cloud-engineer/image13.jpg](https://storage.googleapis.com/envader-article-images/cloud-engineer/image13.jpg)

クラウドエンジニアの年収は、カカクコムが運営する「[求人ボックス給料ナビ](https://xn--pckua2a7gp15o89zb.com/%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%89%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E5%B9%B4%E5%8F%8E%E3%83%BB%E6%99%82%E7%B5%A6)」によると、2023年3月10日時点で、以下の水準です。

- 正社員：約597万円
- 派遣社員：平均時給2,548円

月収で換算すると約50万円になります。

インフラエンジニアの平均年収が約540万円なことを考えると、1割ほど年収が上がります。

ただし傾向として正社員の給料ボリュームは619万円～699万円の間が最も大きいため、働き方によって多少の違いが出てくるでしょう。

## クラウドエンジニアになるメリット

![https://storage.googleapis.com/envader-article-images/cloud-engineer/image12.jpg](https://storage.googleapis.com/envader-article-images/cloud-engineer/image12.jpg)

クラウドエンジニアは、きつい・しんどいと言われる理由がわかりました。ですが、一方では魅力的だとも言われています。

その理由としては、以下の2つがあります。

- 幅広いスキルを取得できる
- 需要が増えていて将来性がある

### 幅広いスキルを習得できる

![https://storage.googleapis.com/envader-article-images/cloud-engineer/image5.jpg](https://storage.googleapis.com/envader-article-images/cloud-engineer/image5.jpg)

クラウドエンジニアには、様々なスキルが求められます。

- パブリッククラウド
- ミドルウェア
- オンプレミス

ITエンジニアの中でも、守備範囲の広さは随一です。更に、クラウドエンジニアに関する資格の難易度も高く、簡単には取得できません。

いつまでも努力をし続けなければなりませんが、裏を返せば常に技術を磨いていける環境です。クラウドエンジニアとして幅広いスキルを身につければ、将来のキャリアパスとして活かせます。

幅広いスキルを習得しなければいけないのは、決してマイナスだけではないのです。

### 需要が増えていて将来性がある

![https://storage.googleapis.com/envader-article-images/cloud-engineer/image9.jpg](https://storage.googleapis.com/envader-article-images/cloud-engineer/image9.jpg)

クラウドエンジニアは、IT技術のクラウド化によって需要が増え続けています。ITインフラをクラウドへ移行したいと考えている企業も多く、活躍できる場所には困らないでしょう。

コロナ禍のリモートワーク導入によって、その存在価値はますます強くなっています。政府も方針として[クラウドシフト](https://cio.go.jp/sites/default/files/uploads/documents/cloud_policy_20210330.pdf)を掲げています。

クラウドエンジニア自体の総数は供給に比例して増えているわけではないため、需要が増えていくことは間違いないでしょう。

## 未経験からクラウドエンジニアになるのは難しい

![https://storage.googleapis.com/envader-article-images/cloud-engineer/image10.jpg](https://storage.googleapis.com/envader-article-images/cloud-engineer/image10.jpg)

クラウドエンジニアは、エンジニア経験者からなら比較的なりやすい仕事です。

一方で、未経験からなるのは非常に難しいとも言えます。求められる知識・スキルが非常に幅広いためです。

インフラエンジニアからクラウドエンジニアになるのは、共通している部分があるため比較的簡単ではあります。

未経験だとそうした知識がないため、全て学んでいかなければなりません。強い意志があれば可能ですが、とてつもない労力を必要とするでしょう。

もし未経験でクラウドエンジニアを目指すなら、スクールに通ったり資格を取ったりすることが最も近道です。

ただし即戦力が求められる世界でもあるため、最終的には実績が必要となることも。回れ道でも少しずつキャリアを積み重ねていきましょう。

## クラウドエンジニアは将来性のある仕事

![https://storage.googleapis.com/envader-article-images/cloud-engineer/image8.jpg](https://storage.googleapis.com/envader-article-images/cloud-engineer/image8.jpg)

クラウドエンジニアは、ITインフラのクラウド化によって今後ますます需要が高くなる仕事です。給与面も高いことから、将来性もあると考えて良いでしょう。

一方で、ITインフラを支えていることから責任が重く、緊急時の対応を求められます。最新の技術を常に身につけていく向上心も必要です。「きつい」「しんどい」と感じる方が多くいます。

常に学び続け成長できる方にとっては、クラウドエンジニアは魅力的な仕事です。自身の性質ではどうなのかを考え、キャリアとして目指してみてくださいね。

今回は、クラウドエンジニアが「きつい」「やめとけ」と言われる理由の他、年収や将来性について解説します。

クラウドエンジニアってどんな職業？年収や将来性は

# 未経験からのインフラエンジニアのロードマップ

IT人材の需要が高まる中、インフラエンジニアを目指す方が増えてきています。

かつては「きつい」「やめとけ」と言われていましたが、今は技術の進歩によって働き方が大きく改善されています。

そんなインフラエンジニアは、どうロードマップを描けばいいのでしょうか。今回は未経験の方に向けて、インフラエンジニアのロードマップについて解説します。ぜひ参考にしてください。

## 未経験からのインフラエンジニアのロードマップ

![https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image16.jpg](https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image16.jpg)

未経験からインフラエンジニアになる場合、以下のロードマップを描くと良いでしょう。

1. 勉強してスキルを身につける
2. 資格を取得する
3. ポートフォリオを作る
4. インフラエンジニアの仕事を探す
5. 中級・上級のインフラエンジニアを目指す
6. スペシャリストの道を選ぶ

### Step1.勉強してスキルを身につける

![https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image12.jpg](https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image12.jpg)

何はともあれ、まずは勉強してスキルを身につけなければいけません。

勉強は座学だけでなく、実践学習も欠かせません。まずは本を読んで基礎を固めてから、トレーニングサイトを使って実践していくと良いでしょう。

独学が不安であれば、通信教育や学校に通う方法もあります。他者がいることで刺激を受けられ、独学よりも継続しやすい環境です。

自分に合った環境でスキルを身につけていきましょう。

スキルに関しては以下の記事で詳しく解説しているので、ぜひ確認してください。

### Step2.資格を取得する

![https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image14.jpg](https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image14.jpg)

知識やスキルが身についたら、次は資格を取得します。資格は客観的に能力・スキルを保証してくれるものであるため、取得して損はありません。

未経験の場合、資格の有無が仕事の受注に直結します。就職・転職の際にも役立ってくれます。

中でも基本情報技術者試験は、必ず取っておきましょう。最低限の能力を担保してくれます。

基本情報技術者試験については、以下の記事で詳しく解説しています。ぜひ確認してください。

### Step3.ポートフォリオを作る

![https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image13.jpg](https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image13.jpg)

資格を取得したら、次はポートフォリオを作ります。ポートフォリオと聞くと主にデザイナーの方が活用しているイメージを浮かべてしまいますが、エンジニアでも使います。

ポートフォリオは、自分のスキル・実績を詰め込んだ営業ツールです。他の応募者との差別化もできるので、活用の幅は非常に広いと言えます。

見やすく・わかりやすいとイメージして作ると良いでしょう。

エンジニアのポートフォリオについては、以下の記事で詳しく解説しています。ぜひ確認してください。

### Step4.インフラエンジニアの仕事を探す

![https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image2.jpg](https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image2.jpg)

ポートフォリオができたら、次はインフラエンジニアの仕事を探します。インフラエンジニアとして働く際、以下のどれかを選ぶこととなります。

- 就職・転職する
- SES
- フリーランス

いきなりフリーランスは難しいため、就職・転職かSESがオススメです。まずは実績を重ね、多くの案件に関わるようにしましょう。

経験を積むことで、更なるステップアップが可能です。

### Step5.中級・上級のインフラエンジニアを目指す

![https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image7.jpg](https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image7.jpg)

実践を重ね、中級・上級のインフラエンジニアを目指すと良いでしょう。インフラエンジニアは年収も高く、上級ともなると年収1,000万円プレイヤーも夢ではありません。

また、他にも企業から独立しフリーランスとしての道を進む道もあります。

- 実績
- スキル
- 能力
- 人脈

これらが兼ね備わっている状態で独立すると、安心感が違います。インフラエンジニアとして高みを目指してください。

### Step6.スペシャリストの道を選ぶ

![https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image1.jpg](https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image1.jpg)

中級・上級のインフラエンジニアとしての道以外に、スペシャリストとしての道を進む方法もあります。インフラエンジニアはITインフラに関係する全ての業務をこなしますが、より細分化して特化する働き方です。

中でも以下の2つを目指すのが代表的なロードマップです。

- サーバーエンジニア
- ネットワークエンジニア

### サーバーエンジニア

サーバーエンジニアは、インフラエンジニアの中でもサーバー部分を担当するエンジニアです。

- データベースサーバー
- アプリケーションサーバー
- Webサーバー
- ファイルサーバー

これらのITシステムを構成するサーバー群の構築業務と保守運用業務を担います。サーバー領域のスペシャリストと呼んで良いでしょう。

クラウド化が進んでいる昨今、クラウドエンジニアも視野に入れて目指す方法もオススメです。

### ネットワークエンジニア

ネットワークエンジニアは、インフラエンジニアの中でもネットワークに特化したエンジニアです。

- ルータ
- Switch
- ファイアーウォール
- ロードバランサ
- VPN

このように、ネットワークエンジニアは最適なネットワーク環境を作り上げる仕事を担っています。ルーティングやスイッチングの技術が求められます。

インフラエンジニアとは似ていますが、ネットワークエンジニアの方がよりスペシャリストとしての能力が必要です。

## インフラエンジニアで身につけたいスキル6選

![https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image11.jpg](https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image11.jpg)

インフラエンジニアには、身につけておきたいスキルがあります。中でも以下の6つは、業務遂行において求められることの多いスキルです。

- 機器とネットワークのスキル
- セキュリティスキル
- クラウド関連のスキル
- 仮想化のスキル
- コミュニケーション能力
- 企画力
- マネジメントスキル

### 機器とネットワークのスキル

![https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image4.jpg](https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image4.jpg)

インフラエンジニアは、インフラの企画設計から運用・監視までこなします。そのため、サーバー機器全般とネットワークに関するスキルは必須です。

クライアントの要求に沿ったインフラを構築するためには、様々な知識を組み合わせて最適解を導くこととなります。

そうした面からも、機器とネットワークのスキルは必要不可欠です。

### セキュリティスキル

![https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image15.jpg](https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image15.jpg)

インフラエンジニアには、セキュリティスキルも必要です。サーバーやネットワークを設計する際は、強固なセキュリティを施さなければいけません。セキュリティを専門とするエンジニアがいる場合も多いですが、ケースによってはインフラエンジニアが担当する可能性があるからです。

- 暗号化
- マルウェア対策
- リスク評価
- ファイアーウォールの設計
- セキュリティシステムの運用方法

こうした知識を身につけておきましょう。

### クラウド関連のスキル

![https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image6.jpg](https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image6.jpg)

近年はクラウド化を選択する企業が増えてきています。インフラエンジニアとしても、時流に乗れるようクラウド関連のスキルも身につけておきましょう。

- AWS
- Google Cloud
- Microsoft Azure

以上3つが定番のクラウドサービスです。クラウド関連のスキルを身につけることで、クラウドエンジニアへの道も拓けます。

### 仮想化のスキル

![https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image10.jpg](https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image10.jpg)

仮想化のスキルも大切です。限られたコンピュータリソースを有効活用するために、仮想化するケースがあります。

仮想化とは、普段使用していない部分を使用できる部分に変える技術です。仮想化することで、IT資源を効率良く使えます。

- サーバー
- ストレージ
- デスクトップ
- ネットワーク

これらを仮想化して用いることが一般的です。VMwareといったソフトウェアを使うことが多いため、事前に学習しておくと良いでしょう。

### コミュニケーション能力

![https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image9.jpg](https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image9.jpg)

インフラエンジニアには、コミュニケーション能力が必須です。構築や運用は、多くの場合チームで行うからです。チーム内でのコミュニケーションが上手くいかなければ業務遂行に支障が出てしまうでしょう。

また、チーム内だけでなくクライアントとのやり取りでもコミュニケーション能力が必要です。クライアントのニーズをしっかり把握し、適切な環境を作り上げなければいけません。

インフラエンジニアにとって、コミュニケーション能力は真っ先に身につけたいスキルです。

### 企画力

![https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image5.jpg](https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image5.jpg)

インフラエンジニアには、企画力も大切です。設計から行うインフラエンジニアにとって、クライアントのニーズを的確に提案に落とし込む作業が求められます。

クライアントの中には自身のニーズを把握していないケースもあります。隠れたニーズを把握し、企画にすることも重要です。

インフラを構築するインフラエンジニアにとって、クライアントのニーズを拾い上げて落とし込む企画力は、無くてはならないものと言って良いでしょう。

### マネジメントスキル

![https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image3.jpg](https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image3.jpg)

マネジメントスキルもインフラエンジニアにとって大切です。プロジェクトは、複数人で進めます。マネジメントスキルを身につけることによって、滞りなくプロジェクトを完遂することも可能でしょう。

- リソースの管理・運用
- 工数の見積もり
- 人員配置
- 目標設定
- 進捗管理

これらにもマネジメントスキルは必須です。納期を守る上でも、大切な能力と言えます。インフラエンジニアとしてスキルアップをするなら、必ず身につけておきたいスキルです。

## 未経験からのインフラエンジニアのロードマップは将来像から逆算して考えること

![https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image8.jpg](https://storage.googleapis.com/envader-article-images/roadmap-infra-engineer/image8.jpg)

未経験からインフラエンジニアになるには、まずスキルを身につけるところから始めなければいけません。客観的な指標となる資格も取得しておくことで更に説得力が増すため、なるべく取っておきましょう。

インフラエンジニアは、そのままインフラエンジニアとしての道を進むか、スペシャリストの道を選ぶかで分かれます。どちらも険しい道に違いはありませんが、日々の業務をこなして成長すれば、誰でもたどり着ける道です。

自分がなりたい姿を想像しながら、自分だけのロードマップを描いてくださいね。

今回は未経験の方に向けて、インフラエンジニアのロードマップについて解説します。ぜひ参考にしてください。

未経験からのインフラエンジニアのロードマップ

# 未経験からのクラウドエンジニアのロードマップ

クラウドエンジニアは、近年人気が集まっているエンジニアの1つです。IT技術の発達によって事業のクラウド化が進む中、ますます需要が高まると予測できます。

そんなクラウドエンジニアを目指す際、未経験者はどのようなロードマップを描けばいいのかわからないという方も多いでしょう。

この記事では、未経験からのクラウドエンジニアのロードマップについて解説しています。就職する際に必要なスキルや知識も紹介しているので、ぜひ参考にしてくださいね。

## 未経験からのクラウドエンジニアのロードマップ

![https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image14.jpg](https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image14.jpg)

未経験からクラウドエンジニアを目指す場合、以下のロードマップを描くことをオススメします。

1. インフラの基本を習得する
2. クラウド技術を習得する
3. 資格を習得する
4. ポートフォリオを作る
5. SEやプログラマーとして実績を傘萎える
6. インフラエンジニアとして3年以上の実績を重ねる

### Step1.ITインフラの基本を習得する

![https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image7.jpg](https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image7.jpg)

まずはITインフラの基本を習得します。ネットワークやサーバーといったITインフラの基礎知識は、クラウドエンジニアにとって大切な知識です。

勉強する方法は様々なものがありますが、以下の3つから自分に合ったものを選ぶと良いでしょう。

- 独学
- オンラインスクール
- 専門学校

社会人の方であれば、隙間時間を活用できる方法を選択してください。無理なく勉強できる環境を作れるかどうかで、学習の効率が大きく変わりますよ。

### Step2.クラウド技術を習得する

![https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image4.jpg](https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image4.jpg)

ITインフラの基本が身についたら、次にクラウド技術を習得します。クラウドエンジニアにとって必須の知識です。

国内のクラウドインフラでは、主に以下の3つが活用されています。これらの理解を真っ先に深めましょう。

- AWS
- Google Cloud
- Microsoft Azure

プラットフォームや提供されるサービスについて知ることで、業務思考で大いに役立ってくれます。

クラウドエンジニアにとってクラウド技術は根幹に関わる知識です。必ず身につけてください。

### Step3.資格を取得する

![https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image1.jpg](https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image1.jpg)

クラウド知識と合わせて取得したいのが、資格です。特に先述した3つのクラウド知識には、それぞれ資格が提供されています。知識・スキルの担保としても役立ってくれるので、取得しておきたいところです。

- AWS認定
- Google Cloud認定資格
- Microsoft Azure認定資格

それぞれレベル別・専門分野別に分かれています。難易度も変わるため、挑戦しやすいレベルからチャレンジしましょう。

資格を取得することで、就職・転職活動時に有利になります。企業によっては資格手当が出ることもあるので、取得して損はありませんよ。

### Step4.ポートフォリオを作る

![https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image5.jpg](https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image5.jpg)

次にポートフォリオを作ります。資格を取得するだけでもそれなりの効果を発揮しますが、ポートフォリオがあることで、説得力を持たせられます。

ポートフォリオは、営業ツールです。デザイナーの方も多く利用し、自身の実績やスキルをわかりやすく提示する役割を持っています。

必須の場面はほとんどありませんが、作っている人が少ないため、あるだけでも差別化に繋がります。就職・転職など様々な場面で使えるツールです。

ポートフォリオについては、以下の記事で詳しく解説しています。ぜひ確認してください。

### Step5.SEやプログラマーとして実績を重ねる

![https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image11.jpg](https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image11.jpg)

クラウドエンジニアは、すぐになれるものではありません。様々な知識・スキルも必要となるため、まずは実務経験を積む必要があります。

SEやプログラマーもその1つです。クラウドエンジニアを目標として経験を重ねていきましょう。特に以下の知識があると望ましいとされています。

- 開発言語の知識：Python、PHP、Java Script、HTML5
- フレームワーク：cakephp、Ruby on Rails、vue.js
- 開発支援ツール：Jenkins、chef、redmine

IT業界は何よりも実績が大切です。まずはクラウドエンジニアに関係する実務に携わっていきましょう。

### Step6.インフラエンジニアとして3年以上の実績を重ねる

![https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image13.jpg](https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image13.jpg)

インフラエンジニアからクラウドエンジニアになる方法もあります。未経験の方がクラウドエンジニアを目指す場合、最もメジャーな方法です。

ただしすぐなれるわけではなく、最低でも3年程度の実務経験は必要でしょう。オンプレミス型情報システムのサーバーやOSを使って、ネットワークやストレージなどインフラ部分の開発や運用を経験するのがオススメです。

インフラエンジニアの経験は、クラウドエンジニアになるにあたって非常に有利に働いてくれます。まずはインフラエンジニアとして実績を重ねてください。

## クラウドエンジニアで必要な資格

![https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image10.jpg](https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image10.jpg)

クラウドエンジニアになるなら、取っておきたい資格があります。資格は、客観的にその人の能力を証明・担保してくれるものです。普段の仕事はもちろん、フリーランスとして独立する際にも役立ってくれます。ぜひチャレンジしましょう。

ここでは、以下の2つのパターンに分けて紹介します。

- IT未経験者向け
- クラウド未経験者向け

### IT未経験者向け

![https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image15.jpg](https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image15.jpg)

IT未経験者の方がクラウドエンジニアになる場合、基礎的な資格を取得すると良いでしょう。

- 情報処理技術者試験
- Linux技術者認定 LPIC
- Linux技術者認定 LinuC
- シスコ技術者認定 CCNA

情報処理技術者試験は、ITに必要な知識を持っている証明にもなる資格です。基礎固めをしたい方は、ぜひ取っておきたい資格と言えます。

同様にLinuxの認定資格も抑えておきましょう。Linuxは仮想サーバーの構築で良く用いられるため、クラウドエンジニアにとって相性の良い資格です。段階別にレベルが設定されているので、まずは簡単なものから挑戦してくださいね。

### クラウド未経験者向け

![https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image6.jpg](https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image6.jpg)

IT経験者かつクラウド未経験者の場合、基礎的な資格は必要ありません。むしろクラウドに関係する資格を積極的に取得しましょう。

中でも以下の3つは、国内で多く使われているクラウドサービスなので、ぜひ取っておきたい資格です。

- AWS認定資格
- Google Cloud認定資格
- Microsoft Azure認定資格

全てを取得する必要はありませんが、少なくとも1つは使えるようにしておきましょう。実践的な勉強があれば、更に役立ってくれます。

クラウド未経験者の方は、クラウドの資格を取得することをまず目標にしてくださいね。

## クラウドエンジニアで就職するなら欲しいスキル・知識

![https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image12.jpg](https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image12.jpg)

クラウドエンジニアとして就職する場合、身につけておきたいスキル・知識があります。ロードマップを描く上でも重要なポイントです。中でも以下の4つは重要なので、必ず身につけておきましょう。

- インフラに関する知識
- クラウドに関する知識
- オンプレミスの知識
- プログラミングスキル

### インフラに関する知識

![https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image16.jpg](https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image16.jpg)

インフラに関する知識は、クラウドエンジニアでは必須の知識です。インフラエンジニアで実務経験を積むのも、インフラの知識が身につくからに他なりません。

特に重要なのが以下の2つです。

- サーバーの知識
- ネットワークの知識

これらはクラウドエンジニアの業務に密接に関わってきます。適切なサービスを提供するためにも、インフラに関する知識は必ず身につけておきましょう。

### クラウドに関する知識

![https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image2.jpg](https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image2.jpg)

クラウドに関する知識も、クラウドエンジニアにとって必須。クラウドエンジニアは、クラウドサービスを円滑に利用できるようにする仕事です。クラウドを扱っている以上、その知識は必ず求められます。

- AWS
- Google Cloud
- Microsoft Azure

最低でもこれらの知識は身につけておきましょう。各種サービスの違いや特徴を把握しておけば、クライアントに適切な提案も可能です。

クラウド技術は日々進歩しているので、毎日アップデートしていきましょう。

### オンプレミスの知識

![https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image8.jpg](https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image8.jpg)

オンプレミスの知識もクラウドエンジニアにとって必要な知識です。オンプレミスからクラウドへと移行が進んでいるため、専門知識がなければスムーズなシステム移行ができません。トラブル発生時の復旧も難しいでしょう。

様々な状況に対応できるよう、以下のオンプレミスの知識は不可欠です。

- ネットワーク
- サーバー
- OS
- ミドルウェア

単にクラウドの知識だけを身につけるのではなく、クラウドへ移行する際の業務も見据えて知識・スキルを身につけましょう。

### プログラミングスキル

![https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image9.jpg](https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image9.jpg)

プログラミングのスキルも必要です。クラウド系の情報システムの開発・運用をするなら、プログラミングの専門知識が求められます。

また、場合によっては自分で直接コードを打ち込むことがあります。ロードマップにおいてSEやプログラマーを経由しておくと良いのは、そうした理由からです。

中でもオススメなのは、以下の3つのプログラミング言語になります。

- Python
- Ruby
- Java

初心者でも習得しやすいものばかりです。自身の作業環境に合わせて、習得しやすい言語から身につけてくださいね。

## クラウドエンジニアのロードマップは実務経験から

![https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image3.jpg](https://storage.googleapis.com/envader-article-images/roadmap-cloud-engneer/image3.jpg)

クラウドエンジニアは、未経験ですぐになることが非常に難しい職種です。まずはSEやプログラマー、インフラエンジニアの実務経験を積みましょう。

ロードマップを描く際は、自身がどのレベルにいるのかを把握してください。IT未経験者かどうかで取得するべき資格が変わってくるからです。身につける知識・スキルも異なります。

まずは実務経験を積むことを目標に、ロードマップを描いてくださいね。

この記事では、未経験からのクラウドエンジニアのロードマップについて解説しています。就職する際に必要なスキルや知識も紹介しているので、ぜひ参考にしてくださいね。

未経験からのクラウドエンジニアのロードマップ

# IaCとは？IaCのメリットやデメリット、Terraformなどの構成管理ツールの特徴を紹介

**IaC**（**I**nfrastructure as **C**ode）とは、サーバーやネットワーク、ストレージなどをはじめとしたインフラの構成をコード化し、その構成や管理を自動化する手法のことです。こちらの記事では、IaCを使う目的と、IaCを実現するにはどのような構成管理ツールがあるのかを解説します。

## IaCとは

![IaC-1.png](https://storage.googleapis.com/envader-article-images/iac/IaC-1.png)

IaCとは、インフラをコード化し、構成や管理を自動化することです。インフラをコード化することで、開発者は時間と手間を大幅に節約することができます。また、同じコードを使用して複数のインフラを構築することが可能なため、一貫性があるインフラを簡単に作成することができます。

例えば、あるアプリケーションを開発するために必要なサーバー、データベース、ネットワーク構成などを手動で設定するのは大変な作業です。多くの手間と時間を消費しなければなりません。

IaCを実現すると、開発者は**コードを書くだけで開発に必要なリソースを自動的に作成する**ことが可能です。また、IaCではこれらのリソースの変更や修正も簡単に行うことができるため、**現在のインフラの現場では必須な技術、知識**と言えるでしょう。

## IaCのメリット

![IaC-2.jpg](https://storage.googleapis.com/envader-article-images/iac/IaC-2.jpg)

IaCを実現することで得られるメリットとして、次が挙げられます。

- ヒューマンエラーの防止
- 正確で一貫性のある環境構築が可能
- 保守性の向上
- 環境構築の手間や時間の削減

以下にそれぞれを詳しく説明していきます。

### ヒューマンエラーの防止

IaCでは、インフラの構成や設定をコードで管理することができます。そのため、**開発者の手作業での設定ミスや誤った手順の実行などを防止する**ことができ、ヒューマンエラーによる問題の発生を防止することができます。

### 正確で一貫性のある環境構築が可能

コードでインフラの構成や設定を管理することで、そのコードを使って同じ環境をいくつも再現することが可能です。これにより、開発環境やステージング環境、本番環境などで同じ環境を構築することが容易になり、正確で一貫性のある環境構築が可能になります。

開発環境やステージング環境については別記事にて解説しています。

[https://envader.plus/article/134](https://envader.plus/article/134)

### 保守性の向上

インフラの構成をコードで管理できるため、変更履歴をGitなどのバージョン管理システムで管理することができます。バージョン管理システムでは変更履歴が残るため、**いつ、誰が、どの部分を変更したのかが明確になります**。これにより保守性が向上し、さらにはその変更によってどのような影響を及ぼすのかを予測することも可能になります。

### 環境構築の手間や時間の削減

手動で行なっていた作業を自動化できるため、環境構築にかかる手間や時間を削減することができます。具体的には、サーバーのセットアップやパッケージのインストール、各パラメータの設定などもコード化することができます。また、AWSなどのクラウドプロバイダーでは、マネジメントコンソールを使用することなく、EC2やセキュリティグループなどの設定をすることが可能です。

このように、IaCを実現することで多くのメリットを受けることができます。

## IaCのデメリット

![IaC-3.jpg](https://storage.googleapis.com/envader-article-images/iac/IaC-3.jpg)

ヒューマンエラーの防止、環境構築の手間や時間の削減など、IaCにはメリットがあることが分かりました。反対に、以下のようなデメリットがあります。

### 学習コストが高い

IaCを実現するためには、後述する**Terraform**や**CloudFormation**などの構成管理ツールを使用する必要があります。それぞれ使用するツールによって**宣言型**や**手続型**などの特徴や、コードの記述方法が異なります。これらの特徴を理解し、新しいスキルを習得する必要があるため、そのための時間やコストがかかることになります。

### 構成管理ツールの導入や構築に時間がかかる

Terraformなどの構成管理ツールを導入する場合、ツールのインストールや設定をする必要があります。ツールのインストールや設定には、使用する構成管理ツールによって特徴や違いがあるため、これらを理解して環境を構築するには時間とコストがかかってしまいます。

### コード化に時間がかかる場合がある

IaCには一度コード化してしまえば同じ環境を複数構築することが容易になるというメリットがありますが、0から環境をコード化する場合には時間がかかってしまいます。コード化する内容が初めての場合、設計や構築の過程でトライアンドエラーを繰り返すことが多くなり、時間がかかる傾向があります。

このようにIaCにはデメリットもあることが分かりました。しかし、IaCを用いることで一度定義すれば反復して使用できること、複数の環境で同じ設定を簡単に再現できることなど、得られるメリットは非常に大きいものになることは間違いありません。

## IaCの構成管理ツール

![IaC-4.jpg](https://storage.googleapis.com/envader-article-images/iac/IaC-4.jpg)

IaCを実現するためには、構成管理ツールを使用します。その種類は複数あり、代表的なものには**Terraform**、**AWS CloudFormation**、**Ansible**などがあります。以下に、構成管理ツールの種類とこれらの特徴はどのようなものがあるのかを解説します。

### Terraform

[Terraform公式](https://www.terraform.io/)

Terraformはアメリカのソフトウェア企業であるHashiCorp社が開発した、オープンソースツールです。HCL(**H**ashiCorp **C**onfiguration **L**anguage）と呼ばれる独自の言語を使用しており、JSONやYAMLと同じような形式で記述をすることができ、読みやすく保守しやすいといった特徴があります。

学習コストの低さもTerraformの特徴の一つです。Terraformでは主に、準備、計画、実行、削除の4つを管理するだけというシンプルさを持っており、最低限この4つのコマンドさえ覚えていればTerraformを扱えます。

また、AWS、GCP、Azureなど主要なクラウドサービスに対応しているため、Terraformを使用するだけで多くのサービスに対応できるのも特徴の一つです。

### AWS CloudFormation

[AWS CloudFormation公式](https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/Welcome.html)

AWS CloudFormationは、JSONやYAML形式で記述されたテンプレートファイルから、EC2やS3をはじめとしたAWSリソースの環境を構築するサービスです。AWSのインフラ環境を構築する作業をコード化し、環境構築作業の迅速化、作業ミスの防止、再利用を実現します。

Terraformは複数のクラウドサービスに対応していますが、AWS CloudFormationはAWSのみに対応しています。

AWS CloudFormationは、定められた形式に従ってテンプレートファイルを記述します。そのファイルをAWSマネジメントコンソール上、またはAWS CLIから実行するのが基本的な使い方になります。記述内容に従ってEC2などのAWSリソースが自動構築され、この構築されたリソースの集合のことを**スタック**(**Stack**)と呼びます。AWS CloudFormationでは、このスタック単位でリソースの作成、変更、削除を行なっていきます。

### Ansible

[Ansible公式](https://docs.ansible.com/ansible/2.9_ja/index.html)

Ansibleは、Pythonで実装されたオープンソースの構成管理ツールです。アメリカのAnsible社によって開発され、現在はAnsible社を買収したRedHat社が開発・提供しています。

AnsibleはPlaybookと呼ばれるファイルに、環境構築に関する設定情報をYAML形式で記述します。作成したPlaybookを元にAnsibleを実行することで、インフラ環境構築の自動化、継続的インテグレーション(CI)、サーバーインフラ全体の制御をすることが可能です。

管理対象のサーバーなどにインストールしないといけないツールやシステムが必要ない、**エージェントレス**と呼ばれる仕組みも特徴の一つとされています。仮に管理対象のサーバーが100台あれば、100台全てにエージェントをインストールする必要がありますが、Ansibleならこの作業が必要ないということです。

また、SSHプロトコルを利用してコマンドを実行するため安全性も高いとされています。

### Chef

[Chef公式](https://www.chef.io/downloads)

ChefはアメリカのChef社(旧Opscode社)が開発しているオープンソースのソフトウェアで、Rubyで実装されています。Chefはフランス語の「料理人」という言葉が由来で、構成要素を記述するファイルは料理をモチーフにした名前が使用されています。

Rubyの**DSL**(**D**omain **S**pecific **L**anguage: ドメイン固有言語)と呼ばれる言語で各設定内容を記述し、そのファイル単体のことをRecipe(レシピ)、Recipeの集合体をCookbook(クックブック)と呼びます。コミュニティによって開発された多くのCookbookが公開されており、Chefの利用者はそれらを自由に再利用することができるメリットがあります。

また、Chefを使用するにはRubyの知識が必要とされますが、テスト機能の充実やDevOpsツールの一部として、自動化されたCI/CDを構築することができるなど様々なメリットがあります。

CI/CDについては以下の記事で解説しています。

[https://envader.plus/article/44](https://envader.plus/article/44)

### Puppet

[Puppet公式](https://www.puppet.com/)

PuppetはChefと同様、Rubyで実装されたオープンソースソフトウェアです。2005年に開発され、Puppet Labs社により現在も開発が行われています。無償で使えるオープンソース版のPuppetと、GUIなどを備えた有償版のPuppet Enterpriseがあり、オープンソース版のPuppetは小規模向け、有償版Puppet Enterpriseは中〜大規模向け用途に適しているとされています。

Puppetでは各設定を記述したマニフェストと呼ばれる定義ファイルに基づいて、インフラの設定作業を自動化します。このマニフェストはPuppet言語と呼ばれる独自の言語を使用して記述しますが、自然言語やconfigファイルに近いため学習コストが低く、習得にはそこまで時間がかからないとされています。

Puppetの大きな特徴として、抽象化レイヤーと呼ばれるOS、ディストリビューション、パッケージシステム等の違いを吸収してくれるレイヤーがあります。このレイヤーがあることで、OSやディストリビューションによるコマンドの違いを開発者が意識する必要がなくなります。

例として、使用するディストリビューションによってはユーザー追加用のコマンドでは**adduser**を使用するか、**useradd**を使用するかといった違いがありますが、マニフェストでは以下のように記述することでその違いを意識する必要がなくなります。

```bash
user { 'foo':
	name       => 'foo',
	password   => 'password',
	managehome => true,
	groups     => 'bar',
}
```

## まとめ

IaC（**I**nfrastructure as **C**ode）は、インフラストラクチャの構成をコード化し、構築、変更、削除などを自動化する手法の一つです。

IaCを導入することで、ヒューマンエラーや運用コストの削減などのメリットがあると同時に、構成管理ツールを理解するための学習コストがかかるなどのデメリットも存在します。IaCを導入する際には、それぞれの構成管理ツールの長所や短所、どのようなことを実現したいのかを理解した上で導入する必要があります。

IaC（Infrastructure as Code）とは、サーバーやネットワーク、ストレージなどをはじめとしたインフラの構成をコード化し、その構成や管理を自動化する手法のことです。

IaCとは？IaCのメリットやデメリット、Terraformなどの構成管理ツールの特徴を紹介

# DevOpsエンジニアってどんな仕事？必要なスキルや資格など

ソフトウェア開発プロジェクトで重要な鍵を握っている職種に、DevOpsエンジニアがいます。

開発から運用まで幅広い領域で活躍するDevOpsエンジニアは、プロジェクトにとって欠かせない存在です。初学者の方の中には、将来的にDevOpsエンジニアを目指している方もいるでしょう。

そこで今回は、DevOpsエンジニアに焦点を当てて、「業務内容」や「必要なスキル」「オススメの資格」を解説します。

DevOpsエンジニアになりたいと考えている方は、ぜひ参考にしてください。

## DevOpsエンジニアとはIT界のジェネラリストのこと

![https://storage.googleapis.com/envader-article-images/dev-ops-engineer/image1.jpg](https://storage.googleapis.com/envader-article-images/dev-ops-engineer/image1.jpg)

DevOpsエンジニアとは、一言で言えばIT界のジェネラリストです。ジェネラリストとは、幅広い知識や技能、経験などを備えた人を指す言葉。ざっくり言えば、万能家です。

ジェネラリストと呼ばれる理由は、担当する業務内容にあります。DevOpsの取り組みを通じて開発と運用の連携を実現し、開発プロセスの迅速化はもちろん、高速化や全体最適化まで目指します。

チームにおける縁の下の力持ちといったポジションであり、いる/いないで大きく変わる存在です。

そんなDevOpsエンジニアを知るために、以下の点を深掘りしてみましょう。

- DevOpsの意味
- DevOpsエンジニアの業務内容
- インフラエンジニアとの違い

### DevOpsの意味

![https://storage.googleapis.com/envader-article-images/dev-ops-engineer/image3.jpg](https://storage.googleapis.com/envader-article-images/dev-ops-engineer/image3.jpg)

DevOpsとは、「Development（開発」と「Operations（運用）」を組み合わせた造語です。従来は分断されていた開発と運用を連携し、同一のプロセスとして扱おうという考え方から生まれました。

現在では更に発展し、以下を表す言葉として使用されています。

- サービスを稼働させながら、システムやソフトウェアを継続的に改善する考え方
- リアルタイムに改善・修正を反映させるための方法論

これらの考え方からもわかるように、DevOpsは「開発と運用の連携に重点を置く」意味を持っているのです。

### DevOpsエンジニアの業務内容

![https://storage.googleapis.com/envader-article-images/dev-ops-engineer/image9.jpg](https://storage.googleapis.com/envader-article-images/dev-ops-engineer/image9.jpg)

DevOpsエンジニアを目指す初学者の方にとって、知っておきたいのが業務内容です。開発者と運用者の中間にいる立場として、多くの業務を担当しなくてはいけません。

企業やチームのニーズによって業務内容に変化はありますが、多くで共通する業務として以下の3つは知っておきましょう。

- CI/CD環境の構築・運用
- バージョンやライブラリの管理
- 構成管理

### CI/CD環境の構築・運用

![https://storage.googleapis.com/envader-article-images/dev-ops-engineer/image5.jpg](https://storage.googleapis.com/envader-article-images/dev-ops-engineer/image5.jpg)

DevOpsに欠かせない概念である、CI/CD環境の構築・運用はDevOpsエンジニアの業務の1つです。

- CI（継続的インテグレーション：アプリケーションコードを変更し、ビルドからテストまで自動的に行う手法
- CD（継続的デリバリー）：テストに通過したソフトウェアを自動で本番環境にアップする手法

どちらも開発環境には欠かせません。

ミスなく効率的に開発者の変更内容を適用するために、マージやビルド、単体・結合テストなどが適切に実行できているかを管理します。

この際、必要なステップを自動化するパイプラインを構築するのも業務です。CI/CD環境の構築・運用にとって、欠かせない存在なのがわかります。

### バージョンやライブラリの管理

![https://storage.googleapis.com/envader-article-images/dev-ops-engineer/image10.jpg](https://storage.googleapis.com/envader-article-images/dev-ops-engineer/image10.jpg)

バージョンやライブラリの管理もDevOpsエンジニアの業務です。特にチームで開発していると、より重要性が増します。

複数のエンジニアで開発を進めていると、各々のタイミングで変更を加えるため、以下のトラブルが生じます。

- 誰がいつ変更を加えたのかわらかない
- 変更点が重複している

適切に管理されていないために起こる人的ミスです。

DevOpsエンジニアはこうしたミスから生じるトラブルを防ぐために、管理ツールの導入や管理方法の構築・運用を担います。

### 構成管理

![https://storage.googleapis.com/envader-article-images/dev-ops-engineer/image12.jpg](https://storage.googleapis.com/envader-article-images/dev-ops-engineer/image12.jpg)

ITシステムの構成管理もDevOpsエンジニアの業務です。システムの構成管理ツールを導入し、あるべき状態で管理していきます。

例えば、現場作業で良くある以下のケースへの対応も可能です。

- サーバーやネットワークが旧バージョンのままだった
- サーバーの設定内容が間違っている
- ネットワークの状態が良くない

こうした状態を防ぐ役割を担っています。スムーズに開発環境を整え、維持するためにもDevOpsエンジニアが担っている業務は大きいのです。

### インフラエンジニアとの違い

![https://storage.googleapis.com/envader-article-images/dev-ops-engineer/image7.jpg](https://storage.googleapis.com/envader-article-images/dev-ops-engineer/image7.jpg)

DevOpsエンジニアと似ているものにインフラエンジニアがあります。エンジニア初学者の方にとって、どう違うのかは気になるポイントですよね。

両者の違いは、運用の自動化や開発の高速化を担当するかどうかに集約します。

システムの運用や保守といった部分では、同じ役割を担っています。ですが、開発プロセスの円滑化など全体を通しての業務は、DevOpsエンジニアならではです。

インフラエンジニアより広範囲の業務を担当するのがDevOpsエンジニアと覚えておきましょう。

## DevOpsエンジニアで必要なスキル

![https://storage.googleapis.com/envader-article-images/dev-ops-engineer/image6.jpg](https://storage.googleapis.com/envader-article-images/dev-ops-engineer/image6.jpg)

DevOpsエンジニアは幅広い業務に関する知識を求められる職種です。ツールや最新テクノロジーへの知識はもちろん、コミュニケーション能力も必要となります。

中でも必須なのが以下の7つのスキルです。

- テクノロジーやツールの理解と知識
- サーバー負荷に対してのスケーラビリティ確保の知識・経験
- ネットワークとインフラへの理解力
- スクリプト言語でのプログラミング
- テストスキルやセキュリティの対策と対処
- クラウドサービスへの知識
- コミュニケーション能力

チーム全体のディレクションも担っていることから、対人スキルは必要不可欠となります。チームの連携が重要になるからこそ、多くのスキルが必要なのです。

## DevOpsエンジニアにオススメの資格4選

![https://storage.googleapis.com/envader-article-images/dev-ops-engineer/image8.jpg](https://storage.googleapis.com/envader-article-images/dev-ops-engineer/image8.jpg)

初学者の方がDevOpsエンジニアを目指すにあたって、身につけておいた方が良い資格があります。必須の資格ではありませんが、幅広い知識や専門性が要求される職種なので、ぜひ挑戦してみてください。

特にオススメなのは、以下の3つの資格です。

- AWS認定DevOps Engineer Professional（DOP）
- Microsoft資格 Azure DevOps Engineer Expert
- Google Cloud認定資格 Professional Cloud DevOps Engineer

### AWS認定DevOps Engineer Professional（DOP）

![https://storage.googleapis.com/envader-article-images/dev-ops-engineer/image13.jpg](https://storage.googleapis.com/envader-article-images/dev-ops-engineer/image13.jpg)

画像引用：[AWS認定DevOps Engineer Professional（DOP）](https://aws.amazon.com/jp/certification/certified-devops-engineer-professional/)

「AWS認定DevOps Engineer Professional（DOP）」は、クラウドサービスの中でも世界最大のシェアを持つAWSに関する資格です。

取得することで、AWSインフラとアプリケーションのテストとデプロイを自動化する能力があると認定されます。AWSのDevOpsエンジニアとして知識を証明できます。

ただ、AWS認定DevOps Engineer Professional（DOP）はAWSでのシステム開発・管理・運用について2年以上の実務経験が必要です。

AWS環境を目指すのであれば、取得しましょう。

### Microsoft資格 Azure DevOps Engineer Expert

![https://storage.googleapis.com/envader-article-images/dev-ops-engineer/image2.jpg](https://storage.googleapis.com/envader-article-images/dev-ops-engineer/image2.jpg)

画像引用：[Microsoft資格 Azure DevOps Engineer Expert](https://learn.microsoft.com/ja-jp/certifications/devops-engineer/)

「Microsoft資格 Azure DevOps Engineer Expert」は、Microsoftが提供するA\zureについての開発と管理の知識・スキルを証明できる資格です。

取得することで、Azure、AzureDevOpsを利用してDevOpsの仕組みを高地策するスキルがあると認定されます。

問題の中には一般的なDevOpsに関する問題も多いため、DevOpsに関する基礎的な知識まで身につけられます。

ただし、挑戦するには「Azure Administrator Associate」「Azure Developer Associate」のどちらかの資格を所有している必要があります。

### Google Cloud認定資格 Professional Cloud DevOps Engineer

![https://storage.googleapis.com/envader-article-images/dev-ops-engineer/image4.jpg](https://storage.googleapis.com/envader-article-images/dev-ops-engineer/image4.jpg)

「Professional Cloud DevOps Engineer」は、Google Cloudを使用したCI/CDパイプラインの構築やインシデントの管理などに関する知識を証明する資格です。複数あるGoogle Cloudの資格の中でも、上位に位置する資格となっています。

出題内容も特殊で、AWSやAzureとは違い「Googleが提唱するサイト・リライアビリティ・エンジニアリング」という考え方を軸にしています。

試験問題が全て英語であり、実務経験も3年以上必要と難易度の高い資格です。

## DevOpsエンジニアは連携によってプロセスの効率化を目指すエンジニア

![https://storage.googleapis.com/envader-article-images/dev-ops-engineer/image11.jpg](https://storage.googleapis.com/envader-article-images/dev-ops-engineer/image11.jpg)

DevOpsエンジニアは、IT業界のジェネラリストのような職種です。多くのメンバーと連携し、開発プロセスの効率化を目指します。そのため、様々な知識や技術、スキルが問われます。一朝一夕に務まる仕事ではありません。

初学者の方が目指すのであれば、まずは資格から挑戦すると良いでしょう。一定以上の実務経験が必要なものばかりなので、経験を積みながら学べます。

DevOpsエンジニアはこれから先、ますます需要が高まると予測できる職種です。ぜひ挑戦してみてくださいね。

DevOpsとは、「Development（開発」と「Operations（運用）」を組み合わせた造語です。従来は分断されていた開発と運用を連携し、同一のプロセスとして扱おうという考え方から生まれました。

DevOpsエンジニアってどんな仕事？必要なスキルや資格など

# Terraformのinput変数の基本的な定義方法 Variableとは

![出典: **HashiCorp Brand** [https://www.hashicorp.com/brand](https://www.hashicorp.com/brand)](https://storage.googleapis.com/envader-article-images/terraform-input-variable/Terraform_PrimaryLogo_ColorWhite_RGB.png)

出典: **HashiCorp Brand** [https://www.hashicorp.com/brand](https://www.hashicorp.com/brand)

こちらの記事では、Terraformにおけるinput変数、Variableについて解説します。Terraformとは、IaC(Infrastructure as Code)を実現するための構成管理ツールの一つです。

Terraformの変数にはinput、local、outputの3つの種類があります。今回はこの3つの変数のうちの一つ、input変数の基本的な定義方法を解説していきます。

IaCについては以下の記事で解説しています。

[https://envader.plus/article/136](https://envader.plus/article/136)

Terraformを実際に触ってみたい方は、以下の記事でハンズオンを解説しています。

[https://envader.plus/article/162](https://envader.plus/article/162)

## input変数とは？

Terraformのinput変数とは、外部ファイル(異なる.tfファイルなど)から値を入力するために使用する変数です。この変数を定義することで、各リソースなどに設定する値を直接書くことを防ぐことができ、再利用性を高めた運用ができるというメリットがあります。

[公式ドキュメント](https://developer.hashicorp.com/terraform/language/values/variables)でも表現されているように、input変数は関数定義の引数のようなものと言えます。

input変数はプロジェクトのルートディレクトリ(親モジュール)で定義すると、CLI、環境変数、.tfvarsファイルやデフォルト値を使って値を設定することができます。ルートディレクトリの下の階層(子モジュール)でinput変数を定義する場合には、呼び出し元(子モジュールを使う側)のモジュールブロックで値を渡す必要があります。

### input変数の定義

Terraformでinput変数を定義するには、variableブロックを使用して変数を定義します。

```bash
variable "region" {
  description = "The region where resources should be created"
  type        = string
  default     = "ap-northeast-1"
}

variable "subnet_ids" {
  description = "List of subnet IDs to deploy resources into"
  type        = list(string)
  default     = []
}
```

variableの後のダブルクウォートで囲まれている部分が変数名になり、input変数を参照する場合にはこの変数名を使用します。この変数名は同じモジュール内の変数の中で一意(一つだけ)にする必要があります。

また、変数名には予約されているsource、version、providers、count、for_each、lifecycle、depends_on、locals以外を使用するようにしなければならないため注意が必要です。

## input変数の引数(設定値)

![001.jpg](https://storage.googleapis.com/envader-article-images/terraform-input-variable/001.jpg)

input変数を定義する際、引数として変数名の後のカッコの中に設定値を記述することができます。以下に公式を元に解説します。

### defaut

変数宣言にデフォルト値を設定することで、ユーザーがその変数を明示的に記述しなかった場合には設定したデフォルト値が使用されます。input変数で定義した変数にはCLIや環境変数、.tfvarsファイルなどで値を渡す必要がありますが、この値を渡す作業が省略された場合にはデフォルト値が適用されるということです。

また、仕様としてデフォルト値には変数を設定することはできません。

```bash
variable "region" {
  default     = "ap-northeast-1"
}

# 変数はデフォルト値に設定できない
variable "region" {
  default     = var.region_name
}
```

### type

変数の値の型を指定することができます。こちらはオプションのため省略することが可能で、省略した場合はどんな型の値でも渡すことが可能です。ただし、型を指定することで開発者にとっての注意喚起や、想定していた型とは違う値を渡した場合にはエラーを返してくれるため、公式では指定することが推奨されています。

どのような型が存在するのかは後述します。

```bash
# 文字列型の例
variable "region" {
   type        = string
 }
```

### description

input変数の説明を記述することができます。説明を簡潔に記述しておくことで、共同で開発していく場合にも変数がどのような役割を持っているのかなどを共有することができます。

```bash
variable "region" {
  description = "The region where resources should be created"
 }
```

### validation

validationを設定することで、変数の値が設定した条件に合っているかどうか検証することが可能になります。

conditionでは真偽値を返す必要があり、falseになった場合にはerror_messageで設定したメッセージを返します。

```bash
variable "environment" {
  description = "Deployment environment"
  type        = string

  validation {
    condition     = contains(["prod", "staging", "dev"], var.environment)
    error_message = "The environment must be 'prod', 'staging', or 'dev'."
  }
}
```

以下にエラー表示の例を示します。

```bash
# environment変数へstgという値を設定した例
# error_messageで設定した値が出力されている

Error: Invalid value for variable
│
│   on variables.tf line 5:
│    5: variable "environment" {
│     ├────────────────
│     │ var.environment is "stg"
│
│ The environment must be 'prod', 'staging', or 'dev'.
│
│ This was checked by the validation rule at variables.tf:8,3-13.
```

### sensitive

sensitiveをtrueに設定することで、terraform planやapplyを実行した際に設定した値を画面に出力されるのを防ぐことができます。この設定は、主に機密情報を含む可能性がある場合に使用されます。

DBのパスワードを想定した変数があった場合、sensitiveをtrueにしておくことで、planやapply実行時に値が出力されることを防ぎます。

```bash
variable "db_password" {
  description = "The password for the database"
  type        = string
  sensitive   = true
}
```

ただし、公式にもあるとおり画面には出力されないものの、.tfstateファイル(Terraformによって管理されているインフラストラクチャの現在の状態を保存し、追跡するためのファイル)には平文で保存されるため、必ずしも安全とは限りません。

参照リンク: [Sensitive Data in State](https://developer.hashicorp.com/terraform/language/state/sensitive-data)

### nullable

nullableは変数にnull値を許可するかどうかを制御するものです。nullable = falseを設定すると、その変数がnullになることを防ぐことができます。デフォルトではtrueに設定されているため、変数の値としてnullを渡しても有効な値として扱われます。

```bash
variable "password" {
  type     = string
  nullable = false
}
```

参照リンク: [Terraform Arguments](https://developer.hashicorp.com/terraform/language/values/variables#arguments)

## input変数の型(Primitive Types)

![002.jpg](https://storage.googleapis.com/envader-article-images/terraform-input-variable/002.jpg)

ここからは、Terraformを利用する上で一番の基本となる型を見ていきます。プリミティブ型と呼ばれる型が基本となり、文字列型、数値型、真偽値型の3つに分類されます。

### string

string型は最も基本的なもので、変数の値には文字列を渡すことができます。表現を変えると、この変数には文字列の値を受け取ることをTerraformに伝えているとも言えます。

値を渡す際にはダブルクウォートで文字列を囲む必要があります。

```bash
# デフォルト値としてt3.microを渡す場合
variable "instance_type" {
  description = "The type of instance to start."
  type        = string
  default     = "t3.micro"
}
```

### number

number型では15のような整数値、1.234などの少数も受け取ることができます。

```bash
variable "max_instances" {
  description = "The maximum number of instances to launch."
  type        = number
  default     = 5
}
```

### bool

bool型では、trueまたはfalseの値を受け取ることができます。

```bash
variable "enable_logging" {
  description = "Enable or disable logging."
  type        = bool
  default     = true
}
```

公式ではプリミティブ型の場合、受け取った値が自動的に適切な型へ変換される可能性があることを説明しています。bool型で指定した場合にも、場合によって文字列型へ変換される場合などです。

参照リンク: [Terraform Conversion of Primitive Types](https://developer.hashicorp.com/terraform/language/expressions/type-constraints#conversion-of-primitive-types)

少しわかりにくいため、以下に例を示します。例では数値型と真偽値型の変数を定義しています。

```bash
variable "example_number" {
  description = "An example number."
  type        = number
  default     = 15
}

variable "example_bool" {
  description = "An example boolean."
  type        = bool
  default     = true
}
```

次に、S3バケットのタグを指定する場面を例に示します。

```bash
resource "aws_s3_bucket" "example" {
  bucket = "my-bucket"
  acl    = "private"

  tags = {
    number_as_string = var.example_number → 15が"15"へ変換される
    bool_as_string   = var.example_bool   → trueが"true"へ変換される
  }
}
```

この例では、S3バケットのタグに数値型とbool型の変数を指定しています。しかし、S3のタグの値は文字列型でなければならないため、ここで自動的に変数のデフォルトで指定した15やtrueの値が文字列型へ変換されます。

また、自動的に変換される条件として値が有効な文字列や数値を含んでいる必要があります。

```bash
# 文字列が数値を表さない場合は変換されない
"abc"
"123abc"

# 文字列が真偽値を表さない場合も変換されない
"yes"
"no"
"1"
```

参照リンク: [Terraform Primitive Types](https://developer.hashicorp.com/terraform/language/expressions/type-constraints#primitive-types)

## ****Collection Types(コレクション型)****

![003.jpg](https://storage.googleapis.com/envader-article-images/terraform-input-variable/003.jpg)

コレクション型は、複合型という複数の値を一つの変数に格納することができる型の種類の一つになります。複合型にはコレクション型の他に、Structural Types(構造型)が存在します。

以下にコレクション型のlist、map、setについて解説します。

### list

listでは、格納される値が同じ型の配列を受け取ることができます。list(受け取りたい型)とすることで、受け取りたい型の配列を指定できます。

```bash
# 文字列の配列を受け取りたい場合
variable "example_list" {
  type    = list(string)
  default = ["apple", "banana", "cherry"]
}

# 数値の配列を受け取りたい場合
variable "example_list" {
  type    = list(number)
  default = [1, 2, 3]
}

# 以下は数値と文字列が混同しているためエラーになる
variable "example_list" {
  type    = list(number)
  default = [1, "two", 3]
}
```

### map

mapはキーと値で構成された配列です。map(受け取りたい型)とすることで作成することができます。

キーはユニークな値(他と重複しない)である必要があり、通常キーと値はダブルクウォートで囲む必要があります。

```bash
variable "example_map" {
  type = map(string)
  default = {
    "key1" = "value1"
    "key2" = "value2"
  }
}
```

ただし、キーが数字で始まらない場合には、ダブルクウォートを省略することも可能です。

```bash
variable "example_map" {
  type = map(string)
  default = {
    key1 = "value1"  # OK: キーが数字で始まっていない
    key2 = "value2"  # OK: キーが数字で始まっていない
  }
}
```

### set

listと似ていますが、setは値にアクセスする際にindexで参照することができません。また、値が重複していてはいけないということ、要素の型は同じでなければならないという条件があります。

```bash
# setの正しい例
variable "example_set" {
  type    = set(string)
  default = ["apple", "banana", "cherry"]
}

# 値が重複しているためエラーになる
variable "example_set" {
  type    = set(string)
  default = ["apple", "apple", "cherry"]
}

# エラー：文字列と数値が混在
variable "example_set" {
  type    = set(string)
  default = ["apple", 123, "cherry"]
}
```

setはTerraformでループ処理を行う際のfor_eachで使用する場面が出てきます。

参照リンク: [The for_each Meta-Argument](https://developer.hashicorp.com/terraform/language/meta-arguments/for_each)

コレクション型(list、map、set)に関しては、**要素の型はすべて同じでなければならない**という点に注意が必要です。

参照リンク: [Terraform Collection Types](https://developer.hashicorp.com/terraform/language/expressions/type-constraints#collection-types)

## ****Structural Types(構造型)****

![004.jpg](https://storage.googleapis.com/envader-article-images/terraform-input-variable/004.jpg)

構造型（structural types）はコレクション型とは違い、異なる型を持つ複数の要素を1つの値としてまとめることができます。構造型には、object型とtuple型の2つがあります。

### object

object型では、一つ一つの要素に対して<キー = 型>と記述し、型を指定することができます。これにより、stringとnumberなど異なる型を一つの変数内で扱うことができるようになります

```bash
variable "employee" {
  type = object({
    name   = string
    age    = number
    active = bool
  })
  default = {
    name   = "John Doe"
    age    = 32
    active = true
  }
}
```

### tuple

tupleは、異なる型の値を一定の順序で格納するためのデータ型です。

```bash
variable "person_info" {
  type = tuple([string, number, bool])
  default = ["Alice", 30, true]
}
```

tupleの値は順序が重要とされており、型と要素の順番が異なる場合にはエラーが発生するため注意が必要になります。

```bash
variable "sample_tuple" {
  type = tuple([string, number, bool])
  default = [30, "Alice", true] // 順序が変わったため、型の定義と合わなくなってしまいエラーになります
}
```

参照リンク: [Terraform Structural Types](https://developer.hashicorp.com/terraform/language/expressions/type-constraints#structural-types)

## まとめ

この記事では、Terraformにおけるinput変数(Variable)の定義方法について解説しました。

コレクション型では要素の型は同じでなければいけないこと、構造型では異なる要素の型を定義すすることができることなど、それぞれの型に応じて違いがあることを理解して変数を定義する必要があります。

今回の記事がTerraformを学ぶ方の一助になれば幸いです。

こちらの記事では、Terraformにおけるinput変数、Variableについて解説します。Terraformとは、IaC(Infrastructure as Code)を実現するための構成管理ツールの一つです。

Terraformのinput変数の基本的な定義方法 Variableとは

# 【IaC】Terraformで定義したinput変数への値の渡し方について解説

こちらの記事では、Terraformで定義したinput変数への値の渡し方について解説します。Terraformとは、IaC(Infrastructure as Code)を実現するための構成管理ツールの一つです。Terraformの変数にはinput、local、outputの3つの種類があります。今回はこの3つの変数のうちの一つ、input変数への値の渡し方について解説していきます。

Terraformのinput変数の定義方法については以下の記事をご覧ください。

[https://envader.plus/article/190](https://envader.plus/article/190)

また、IaCについては以下の記事で解説しています。

[https://envader.plus/article/136](https://envader.plus/article/136)

## input変数を使うメリットとは？

Terraformにおいて、input変数は設定ファイルを再利用して異なる環境や条件でインフラストラクチャを管理する際に非常に便利です。input変数を使用すると、設定ファイルの中で変数を定義しそれらの値を後で変更できるため、コードの柔軟性と再利用性が向上します。

## コードの柔軟性と再利用性とは？

input変数を使用することでコードの柔軟性と再利用性が向上すると述べました。これを具体的にコマンドラインで値を渡す例を用いて解説します。

企業やプロジェクトでは通常、開発環境、ステージング環境、本番環境など、異なる環境で同じインフラストラクチャが必要になります。しかし、コスト面やその他の観点からこれらの環境間で全く同じ環境を必要とするわけではなく、少しだけ変更したい場合があります。例えば、開発環境ではインスタンスを小さいサイズ、本番環境ではインスタンスサイズを大きくしたい、といった場合です。

ここで、Terraformのinput変数を使うと、同じコードを異なる環境で利用することが非常に簡単になります。以下の変数を定義していた場合を例に説明します。

```bash
# プロジェクトの環境を定義
variable "environment" {
  description = "Deployment environment"
}

# インスタンスサイズを定義
variable "instance_size" {
  description = "EC2 instance size"
}
```

先述した変数定義をもとに開発環境を構築する場合、コマンドラインから値を渡す際には以下のようになります。

```bash
terraform plan -var 'environment=dev' -var 'instance_size=t2.micro'
```

一方、本番環境ではインスタンスサイズを大きくしたいため、以下のように値を渡します。

```bash
terraform plan -var 'environment=prod' -var 'instance_size=m5.large'
```

このように開発環境と本番環境で渡す値を変更するだけで、インスタンスサイズを変更することができるため再利用性を高めることができます。また、ソースコードを直接編集することなく変更を行うことができるため、柔軟性があるとも言えるでしょう。

開発環境や本番環境については、以下の記事にて解説しています。

[https://envader.plus/article/134](https://envader.plus/article/134)

## input変数へ値を渡す方法

![001.jpg](https://storage.googleapis.com/envader-article-images/terraform-input-value/001.jpg)

input変数へ値を渡すには、コマンドライン、.tfvarsファイル、環境変数の3つから渡すことができます。

Terraformのinput変数は、variableブロックを使用しその変数の型や説明を記述することができます。ただ、この段階では変数を定義しているだけのため、変数の値は別途渡してあげる必要があります。(デフォルト値を設定している場合を除く)

### 変数の定義

今回は以下の変数を定義し、その変数に対して値を渡していきます。

```bash
variable "vpc_cidr" {
  description = "The CIDR block for the VPC"
  type        = string
}

variable "subnet_cidrs" {
  description = "The CIDR block for the subnet"
  type        = list(string)
}
```

## コマンドラインから値を渡す

コマンドラインで変数の値を渡すには、terraform planコマンドやterraform applyコマンドを実行する際に-varオプションを使用します。

```bash
terraform plan -var="変数名=渡したい値"

terraform plan -var="vpc_cidr=10.0.0.0/16"
```

vpc_cidrとsubnet_cidrs変数に同時に値を渡したい場合には、-varオプションを複数指定します。

```bash
terraform plan -var="vpc_cidr=10.0.0.0/16" -var='subnet_cidrs=["10.0.1.0/24","10.0.2.0/24"]'
```

Windowsのコマンドプロンプトでは扱いが若干違うため注意が必要です。

[Input Variables on the Command Line](https://developer.hashicorp.com/terraform/cli/commands/plan#input-variables-on-the-command-line).

また、-var-fileオプションを使用することで、terraform.tfvarsなど別のファイルに変数を定義し、そのファイルを指定することができます。

```bash
terraform plan -var-file="terraform.tfvars"
```

## 変数定義ファイルから値を渡す

![002.jpg](https://storage.googleapis.com/envader-article-images/terraform-input-value/002.jpg)

.tfvarsファイル、.tfvars.jsonファイルを作成することで、変数の値を渡すことができます。

Terraformでは、.tfvars、.tfvars.jsonファイルが存在している場合、自動的にそのファイルを読み込む設定になっています。作成したファイルの中に変数名と値を記述することで、その値を渡すことができます。

```bash
# .terraform.tfvars
vpc_cidr = "10.0.0.0/16"

subnet_cidrs = [ "10.0.1.0/24", "10.0.2.0/24" ]
```

tfvars.jsonファイルを作成する場合、記述方法はjson形式にする必要があるため注意が必要です。

```bash
# terraform.tfvars.json
{
  "vpc_cidr": "10.0.0.0/16",
  "subnet_cidrs": ["10.0.1.0/24","10.0.2.0/24"]
}
```

## 環境変数を設定する

環境変数を設定して値を渡すこともできます。

```bash
export TF_VAR_変数名='渡したい値'

export TF_VAR_vpc_cidr='10.0.0.0/16'

# listで値を渡す場合
export TF_VAR_subnet_cidrs='["10.0.1.0/24","10.0.2.0/24"]'
```

環境変数へ値を設定すると、.tfvarsファイルや-varオプションを使用せずに値を渡すことができます。環境変数の値を文字列として渡す場合には、シングルクウォートで囲むことで値を渡すことが可能です。

ただ、リストやマップ、オブジェクト型などの値を渡すには記述方法が複雑になり、エスケープ処理などを考慮する必要が出てきます。そのため公式では変数の型が複雑な場合、コマンドラインや環境変数ではなく、.tfvarsファイルなどの変数定義ファイルから値を渡すことが推奨されています。

[Complex-typed Values](https://developer.hashicorp.com/terraform/language/values/variables#complex-typed-values)

実際に環境変数を設定する場面としては、認証情報やデータベースのパスワードなどの機密情報を扱う場面が挙げられます。

```bash
export AWS_ACCESS_KEY_ID='XXXXXXXXXXXXX'
export AWS_SECRET_ACCESS_KEY='XXXXXXXXXXXXXX'
```

## 変数が読み込まれる順番

![003.jpg](https://storage.googleapis.com/envader-article-images/terraform-input-value/003.jpg)

Terraformでは、変数が読み込まれる際には順番があります。これは、変数定義ファイルの.tfvarsファイルとコマンドラインや環境変数で同じ変数に値を渡した時に適用される順番があるということです。

![input-variable-1.png](https://storage.googleapis.com/envader-article-images/terraform-input-value/input-variable-1.png)

図のように初めに環境変数が読み込まれ、その後に.tfvarsファイル、.tfvars.jsonファイルと進みます。コマンドラインから値を渡す場合には、その値が環境変数や.tfvarsファイルの値を上書きし、優先的に使用されます。

## input変数の参照方法

それぞれinput変数へ値を渡す方法を紹介しました。最後にinput変数への参照方法を解説します。渡した値を参照するには、var.vpc_cidrのように記述し値を参照します。

```bash
# VPCのCIDRブロックを設定する例
resource "aws_vpc" "main" {
  cidr_block = var.vpc_cidr
}
```

このように記述することで、input変数へvpc_cidrとして10.0.0.0/16の値を渡していた場合、VPCには10.0.0.0/16のCIDRブロックが適用されます。

## まとめ

今回はinput変数への値の渡し方について解説しました。

input変数へ値を渡す方法としては以下の3つの方法があります。

- コマンドラインから値を渡す
- .tfvarsファイル、.tfvars.jsonファイルなどの変数定義ファイルから値を渡す
- 環境変数を設定する

それぞれの方法についても理解しておくことはもちろん、変数の読み込まれる順番についてもしっかりと理解し運用を行っていきましょう。

Terraformの変数にはinput、local、outputの3つの種類があります。今回はこの3つの変数のうちの一つ、input変数への値の渡し方について解説していきます。

【IaC】Terraformで定義したinput変数への値の渡し方について解説

# インフラエンジニア初学者のためのログ管理入門

![001.jpg](https://storage.googleapis.com/envader-article-images/about-log/001.jpg)

## 1. この記事の目的

この記事の目的はログとその管理の基本的な概念を初学者に解りやすく伝えることです。システムやアプリケーションの健全な運用をサポートするためのログの役割やその管理方法についても詳しく紹介します。インフラエンジニア初学者がログ管理の重要性を深く理解し実際の業務に生かすための第一歩とすることを目指しています。

## 2. ログとは

システムやアプリケーションが日々動作する中でその内部で何が起きているのかを知るための最も基本的な手段が「ログ」です。ログにはシステムの健全性や問題点を示す非常に価値ある情報が含まれています。

### ログの定義

ログはコンピューターシステムやアプリケーションが特定の動作を行うたびに生成される情報の記録です。これはユーザーのアクション・システムの状態変化・エラーメッセージなど、様々な出来事の詳細を時系列でキャプチャしたものです。ログはテキスト形式で保存され特定のフォーマットや構造を持つことが多いです。

### ログの重要性

ログがシステム運用においてなぜ重要を次のとおり説明します。

#### 問題の早期発見

エラーや異常が発生した際にその原因を突き止める手がかりとなるのがログです。ログに記録された情報を解析することで問題の原因や発生箇所を迅速に特定することが可能となります。

#### システムの最適化

ログはシステムの動作やパフォーマンスに関する情報も提供します。この情報を利用してシステムの運用状態を評価し最適化の方針を立てることができます。

#### セキュリティ監視

不正アクセスやセキュリティ侵害の試みが行われた際にその証拠や手がかりがログに記録されていることが多いです。ログの監視によってセキュリティ上の脅威を早期に検知し対策を講じることが可能となります。

## 3. ログの種類

コンピューターシステムやアプリケーションは多様なログを生成します。主要なログの種類とサンプル及びその解説を次のとおりに示します。

### アクセスログ

ユーザーのサービスへのアクセス情報を記録します。

アクセスログの例
```log
127.0.0.1 - - [28/Aug/2023:10:45:32 +0900] "GET /index.html HTTP/1.1" 200 512 "http://example.com" "Mozilla/5.0"
```
IPアドレス`127.0.0.1`から`/index.html`にアクセスがあり、HTTPステータス200(成功)を返し、レスポンスのサイズが512バイトであることを示しています。

### エラーログ

システムやアプリケーションのエラー情報を記録します。

エラーログの例
```log
[2023-08-28 10:46:12] ERROR: File not found: /path/to/file
```
`2023-08-28 10:46:12`に`/path/to/file`というファイルが見つからないというエラーが発生したことを示しています。

### アプリケーションログ

アプリケーションの動作や状態の情報を記録します。

アプリケーションログの例

```log
[INFO][2023-08-28 10:47:00] User login successful. User_id: 12345
```
`2023-08-28 10:47:00`にユーザーID`12345`がログインに成功したことを示しています。

### システムログ

OSやハードウェアの動作情報を記録します。

システムログの例
```log
Aug 28 10:47:45 servername kernel: [12345.678910] CPU0: Core temperature above threshold, cpu clock throttled
```
`Aug 28 10:47:45`にサーバ`servername`のCPU0のコア温度が閾値を超えたためCPUのクロックが制限されたことを示しています。

これらのログはシステムの状態を理解し問題の特定や対策を行う上で非常に重要となります。

## 4. ログのライフサイクル
![003.png](https://storage.googleapis.com/envader-article-images/about-log/003.png)
ログの管理には生成から削除までの一連のライフサイクルが存在します。このライフサイクルを通じてシステムの健全性を維持し、障害対応やセキュリティ分析を効果的に行うことができます。

### 生成
システムやアプリケーションの動作中に様々なイベントや状態がログとして生成されます。どのような情報をどのレベルでログとして記録するかの設定が重要となります。

### 収集
特に大規模なシステムでは複数のサーバーやデバイスからログが発生します。これらのログを一元的に収集することで分析や管理が容易になります。ログ収集ツールやアグリゲーターを使用しログを中央のログサーバーに送信するのが一般的です。

### 保管
ログは法的要件や業界の基準に従って一定期間保管する必要があります。データの完全性や可用性や機密性を確保しながらAWSのS3などコスト効率的なストレージソリューションを選定することが求められます。

### 分析
ログの真価はその内容を分析することで発揮されます。ログ分析ツールを使用しパターンの識別・異常の検出・問題の原因特定などを行います。定期的なレポート作成やアラート設定もこのステップで行われることが多いです。

### アーカイブと削除
ログデータは時間とともに蓄積されその量は膨大となります。コンプライアンスやコスト的観点などから一定期間が経過したログはアーカイブストレージに移動されるか必要なければ安全に削除するべきです。

## 5. ログのアグリゲーションとは

ログのアグリゲーションは複数の異なるソースからのログを収集・整形・一元的に管理するプロセスを指します。大規模な環境や複数のサービス・アプリケーションが動作しているシステムではログ情報が散在するため、その情報を効果的に活用するためのアグリゲーションが不可欠です。

### アグリゲーターの定義

アグリゲーターとは複数のログソースからログ情報を収集し整形や加工を行い一元的に管理・保存するシステムやサービスのことを指します。アグリゲーターによりログの分析や管理が一箇所で行えるようになります。

### アグリゲーターの利点

#### 集中管理

一元的にログを管理することでログの確認や分析が簡単になります。

#### 高速な検索

大量のログデータでも特定の情報を迅速に検索することが可能です。

#### 統一された分析

異なるソースからのログも統一されたフォーマットで分析することができ効率的な情報収集や解析が行えます。

#### アラート機能

特定の条件に合致するログが生成された際に即時に通知を受けることができます。

### 代表的なアグリゲーターツール

#### ELKスタック (Elasticsearch, Logstash, Kibana)
![002.png](https://storage.googleapis.com/envader-article-images/about-log/002.png)
- Elasticsearch:分散型の検索・分析エンジン。大量のデータをリアルタイムで迅速に検索・分析
- Logstash:ログの収集・加工を行うツール。様々なソースからのログをElasticsearchに送信
- Kibana:Elasticsearchのデータを可視化するツール。ダッシュボードの作成やログの詳細な分析が可能

#### Fluentd

高い拡張性を持つオープンソースのログコレクター。様々な入出力プラグインが存在し多岐にわたるログソースからの収集・加工・転送が行えます。

#### Splunk

ログを収集・保存しリアルタイムの検索・分析・可視化を行うソフトウェア。大量のログデータでも迅速な検索・分析が可能で、多くの企業で利
用されています。

アグリゲーターの利用でログ管理の効率性と有効性が大きく向上します。適切なツールを選定しシステムの要件や環境に合わせて設定・運用しましょう。

## 6. まとめ

ログはシステムやアプリケーションの動作を記録した情報で、問題の診断や性能分析に不可欠です。ログにはアクセス・エラー・アプリケーション・システムなど多様な種類が存在し、それぞれの特性や用途に応じて利用されます。

ログのライフサイクルは生成から収集・保管・分析・アーカイブ・削除という流れを持ちます。大規模なシステムや複数のアプリケーションが存在する環境ではログのアグリゲーションが必要となり、このためのツールやサービス（アグリゲーター）が提供されています。

アグリゲーターは、ログの一元管理・高速検索・統一分析などの利点を持ち、効率的なログ管理を実現します。適切なログの取り扱いと管理はシステム運用の品質向上に寄与します。

この記事の目的はログとその管理の基本的な概念を初学者に解りやすく伝えることです。システムやアプリケーションの健全な運用をサポートするためのログの役割やその管理方法についても詳しく紹介します。

インフラエンジニア初学者のためのログ管理入門

こちらの記事では、Terraformの組み込み関数についての基本的な構文と使用例について解説します。

Terraformの組み込み関数とは？elementやlookupなどの基本構文と使用例を学ぶ

BINDは、DNSサーバーのためのソフトウェアです。DNSの情報を管理することができ、クライアントからの名前解決のリクエストに応じて対応するIPアドレスを返すことができます。

【BIND入門】BINDの基礎概念を理解しよう

こちらの記事では、AWSのEC2（ubuntu）にBINDをインストールし、実際にDNSサーバーを構築する方法を解説します。

【BIND入門実践】BINDでDNSサーバーを構築してみよう

# Terraformの基礎 countとfor_eachの基礎を学び繰り返し処理を効率化しよう

![Terraform_count-1.png](https://storage.googleapis.com/envader-article-images/terraform-count-foreach/Terraform_count-1.png)

こちらの記事では、Terraformの繰り返し処理の基本であるcount、for_eachの構文の基礎と使い方について解説します。この構文を使うことによって、Terraformで複数のリソースを作成する際のソースコードの冗長化を防ぐことができます。

## 繰り返し処理の重要性

Terraformで複数のリソースを作成する際、繰り返しの構文を使用しないと以下のようになります。

**前提条件**として、VPCは作成済みです。

```jsx
resource "aws_subnet" "subnet_1" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
  tags = {
    Name = "subnet-1"
  }
}

resource "aws_subnet" "subnet_2" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.2.0/24"
  tags = {
    Name = "subnet-2"
  }
}

resource "aws_subnet" "subnet_3" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.3.0/24"
  tags = {
    Name = "subnet-3"
  }
}
```

3つのサブネットを作成しようとした場合、リソースの数だけコードを記述することになります。これを10個、20個と記述していくことを想像すると、ものすごく冗長なコードになることが分かります。

Terraformの繰り返し処理の構文であるcountやfor_eachを使うことで、この状況を避けることができます。結果として、コードの冗長化を防ぐとともに、可読性の向上にもつながります。

## Terraformとは

そもそもTerraformとは？という方へ概要を説明します。

Terraformは、HashiCorp社によって開発されたオープンソースのIaCツールです。Terraformを使うことで、従来の手動でのインフラ管理や設定作業を自動化し、コードベースでの管理が可能になります。Terraformを使用することで、インフラの設定変更やデプロイを迅速かつ確実に行うことができます。

クラウド環境でのリソース管理において、Terraformは多くのクラウドプロバイダとの互換性を持っています。具体的にはAWS、GCP、Azureなど主要なクラウドサービスに対応しており、インフラ構築を一元的にコードで管理することができます。

IaCのメリットなどについては以下のリンクで解説しています。

[https://envader.plus/article/136](https://envader.plus/article/136#76)

Terraformを実際に触ってみたい！という方へ向けて、環境構築、EC2インスタンスの作成方法について以下の記事で解説しています。

[https://envader.plus/article/162](https://envader.plus/article/162)

## countによる繰り返し処理

countはモジュールや全てのリソースブロックで使用することができる、Meta-Argumentと呼ばれる特別な引数のうちの一つです。

countを使用することで、一つのリソースブロックで複数のリソースを管理することができます。

### countの基本的な使い方

基本的な使い方は以下です。

```bash
resource "aws_instance" "server" {
  count = 4 # 作成したいリソースの数

  ami           = "ami-a1b2c3d4"
  instance_type = "t2.micro"

  tags = {
    Name = "Server ${count.index}" # 0から始まるindexを取得することができる
  }
}
```

Terraform公式ドキュメントより引用: [Basic Syntax](https://developer.hashicorp.com/terraform/language/meta-arguments/count#basic-syntax)

`count`で**作成したいリソースの数値**を入力し、`count.index`で**作成したリソースの**index番号を取得できます。

### countの注意点

countで指定できるのは、整数のみです。リソース作成後に生成されるIDなどを直接参照することはできません。

```bash
# これはエラーになります
resource "aws_instance" "server" {
  count = aws_other_resource.example.id
...
}
```

IDを指定する場合には、length関数などを使って指定する必要がありました。

```bash
variable "subnet_ids" {
  type = list(string)
}

resource "aws_instance" "server" {
  # length関数を使用してサブネットのIDを参照している
  count = length(var.subnet_ids)

  ami           = "ami-xxxxxxxxx"
  instance_type = "t2.micro"
  subnet_id     = var.subnet_ids[count.index]

  tags = {
    Name = "Server ${count.index}"
  }
}
```

Terraform公式ドキュメントより引用: [When to Use for_each Instead of count](https://developer.hashicorp.com/terraform/language/meta-arguments/count#when-to-use-for_each-instead-of-count)

また、countではリソースの削除などによりindexが変わってしまうと、参照するIDなどが変わる可能性があります。

```bash
# subnet-002が削除された場合、subnet-003のインスタンスIDも変わってしまう。
variable "subnets" {
  description = "List of subnets"
  default = ["subnet-001", "subnet-002", "subnet-003"]
}

resource "aws_instance" "example" {
  count      = length(var.subnets)
  subnet_id  = var.subnets[count.index]
  // ... other configuration ...
}
```

リソースの削除などによって参照先が変わってしまう可能性があるリソースに対しては、後述するfor_eachを使用することを検討しましょう。

### countを使ったリソースの作成

countを使用して、3つのサブネットを作成する例を紹介します。

```bash
resource "aws_subnet" "subnet" {
  count = 3 # 作成したいリソースの数

  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.${count.index + 1}.0/24" # indexは0から始まるため、1を足す
  tags = {
    Name = "subnet-${count.index + 1}"
  }
}
```

冒頭で紹介したソースコードを再度掲載します。

```bash
resource "aws_subnet" "subnet_1" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
  tags = {
    Name = "subnet-1"
  }
}

resource "aws_subnet" "subnet_2" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.2.0/24"
  tags = {
    Name = "subnet-2"
  }
}

resource "aws_subnet" "subnet_3" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.3.0/24"
  tags = {
    Name = "subnet-3"
  }
}
```

今回の例は簡単な例ですが、21行あったコードが8行まで削減できているのが分かります。countを使用することで、ソースコードの冗長化と可読性を向上させることができます。

## for_eachによる繰り返し処理

for_eachはTerraformのバージョン0.13で追加された機能です。count同様、Meta-Argumentと呼ばれる特別な引数のうちの一つです。for_eachもモジュールや全てのリソースタイプで使用することができます。

[The for_each Meta-Argument](https://developer.hashicorp.com/terraform/language/meta-arguments/for_each)

### for_eachの基本的な使い方

for_eachへ渡す値で使用できるのは、Terraform がサポートするコレクション型（mapまたはset）です。以下にmapを使用した簡単な例を示します。

```bash
# 3人のユーザーを変数で定義
variable "user_map" {
  default = {
    alice = "admin"
    bob   = "guest"
    carol = "editor"
  }
}

resource "aws_iam_user" "example" {
  for_each = var.user_map

  name = each.key
  tags = {
    Role = each.value
  }
}
```

この例では、`aws_iam_user`リソースを作成する際に`for_each`を使用しています。`var.user_map`変数は3つのユーザー（alice、bob、carol）とそれぞれのロール（admin、guest、editor）を定義しています。

`each.key`では、`var.user_map`の各キー（alice、bob、carol）を指定しています。

`each.value`では、`var.user_map`の各値（admin、guest、editor）を指定しています。

このように`each.key`と`each.value`を使用することで、動的に値を設定できます。

### for_eachを使ったリソースの作成

countと同じように、サブネットを3つ作成する例です。

```bash
resource "aws_subnet" "subnet" {
  for_each = {
# mapの値を渡している
# each.key = subnet_1、subnet_2、subnet_3
# each.valueでmapの値を取得している
    subnet_1 = {
      cidr_block        = "10.0.1.0/24"
      availability_zone = "ap-northeast-1a"
    },
    subnet_2 = {
      cidr_block        = "10.0.2.0/24"
      availability_zone = "ap-northeast-1c"
    },
    subnet_3 = {
      cidr_block        = "10.0.3.0/24"
      availability_zone = "ap-northeast-1a"
    }
  }

  cidr_block        = each.value.cidr_block
  availability_zone = each.value.availability_zone
  vpc_id            = aws_vpc.main.id

  tags = {
    Name = each.key
  }
}
```

mapの値を変数化すると、for_eachの部分をもう少しスッキリ書くこともできます。

```bash
variable "subnets" {
  default = {
    subnet_1 = {
      cidr_block        = "10.0.1.0/24"
      availability_zone = "ap-northeast-1a"
    },
    subnet_2 = {
      cidr_block        = "10.0.2.0/24"
      availability_zone = "ap-northeast-1c"
    },
    subnet_3 = {
      cidr_block        = "10.0.3.0/24"
      availability_zone = "ap-northeast-1a"
    }
  }
}

resource "aws_subnet" "subnet" {
# for_eachで変数を参照し、一つのkeyごとにループしながら値を設定していくことができる。
  for_each = var.subnets

  cidr_block        = each.value.cidr_block
  availability_zone = each.value.availability_zone
  vpc_id            = aws_vpc.main.id

  tags = {
    Name = each.key
  }
}
```

このコードでは、for_eachに変数subnetsを指定しています。`each.value` で変数内で定義した内部マップを指定し、`each.value.~` でその内部マップの値を参照しています

`for_each = var.subnets` の部分で `var.subnets` の各エントリ（`subnet_1`, `subnet_2subnet_3` など）が順番に処理されます。それぞれの繰り返し処理で、`each.key` は外側のマップのキー（ など）を、`each.value` はそのキーに対応する値（各サブネットの設定マップ）を参照します。

そして、`each.value.cidr_block` や `each.value.availability_zone` のようにして、その内部マップの「値」を取得しています。

## for_eachの注意点

for_eachを使う際に理解しておくべきポイントを公式ドキュメントを元にまとめました。

### for_eachに渡す値はmapかsetである必要がある。

for_eachで使用する値はmapかsetでなければいけません。この値を使用することによって、for_eachでリソースを作成する際にそれぞれのリソースが重複して作成されることを防ぐことができます。

mapやsetなどTerraformの型については、以下の記事で解説しています。

[https://envader.plus/article/190](https://envader.plus/article/190)

### setの値を渡す場合は、each.keyもeach.valueも同じ値になる。

setの値はmapのように`key=value`形式ではないため、`each.key`、`each.value`どちらを指定しても同じ値を参照します。

```bash
locals {
  subnet_ids = toset([
    "subnet-abcdef",
    "subnet-012345",
  ])
}

resource "aws_instance" "server" {
  for_each = local.subnet_ids

  ami           = "ami-a1b2c3d4"
  instance_type = "t2.micro"
  subnet_id     = each.key # each.valueを指定しても同じ値を参照する

  tags = {
    Name = "Server ${each.key}"
  }
}
```

Terraform公式ドキュメントより引用: [Using Sets](https://developer.hashicorp.com/terraform/language/meta-arguments/for_each#using-sets)

### plan実行時に判断できない値は使用できない

random_petなど動的に生成されるリソースタイプをfor_eachで使用することはできません。このリソースはランダムな「ペットネーム」（通常は人間が読みやすい形式の文字列）を生成しますが、planを実行する時点では値が確定していません。

```bash
# 悪い例
locals {
  users = tomap({
    name = random_pet.name.id
    role = "admin"
  })
}

# randomな値を生成。
resource "random_pet" "name" {
  length = 2
}

resource "aws_iam_user" "example" {
	# local.usersにはランダムな値が含まれるため、エラーになる。
  for_each = local.users

  name = each.key
  tags = {
    Role = each.value
  }
}
```

このように、plan実行時には値がわからないものを参照している場合、for_eachではエラーになります。

### uuidやtimestampなど毎回異なる結果を返す関数は使用できない

uuid、timestamp、bcryptなど同じ引数に対して毎回異なる結果を返す関数を使用した場合もエラーになります。これは、関数を実行するタイミングで生成される値が毎回異なる可能性があるためです。

```bash
# 悪い例
locals {
  resources = {
		# timestamp関数を使ってローカル変数のmapにキーを生成している
    "${timestamp()}" = "value1"
  }
}

resource "aws_s3_bucket" "my_buckets" {
	# timestamp関数はplanやapply実行時に結果が変わる可能性があるため、エラーになる
  for_each = local.resources
	
  bucket = "${each.key}-bucket"
 }
```

### パスワードなどの機密性の高い値は使用できない

for_eachでは`sensitive=true`としている値を使用することができません。

Terraformでは機密性の高い情報を使用する場合、sensitive属性を`true`にする場面があります。こうすることにより、`plan`や`apply`を実行する際に値が表示されるのを防ぐことができます。

この値をfor_eachで指定するとエラーが発生します。

```bash
# 悪い例
variable "sensitive_values" {
  type = map(string)
	# sensitiveの値をtrueにしている
  sensitive = true
  default = {
    password1 = "supersecret"
    password2 = "evenmoresecret"
  }
}

resource "aws_s3_bucket" "my_buckets" {
	# sensitive=trueの値を指定しているためエラーになる
  for_each = var.sensitive_values

  bucket = "${each.key}-bucket"
 
  tags = {
    SensitiveValue = each.value
  }
}
```

## まとめ

こちらの記事では、Terraformのループ処理であるcount、for_eachについて解説しました。

count、for_eachを使用することでソースコードの冗長化を防ぐことができ、可読性も向上させることができます。

シンプルなリストや数値に基づいてリソースを生成する場合にはcountが適しています。注意点として、countでは作成したリソースのIDなどを参照するには向いていないため、使用する場面は検討する必要があります。

for_eachはmapやsetを使用し、繰り返しリソースを作成する場面に適しています。

countとfor_eachを同時には使用できないため、ループ処理を行いたい場合には両者の適切な使い分けが必要になってくるでしょう。

こちらの記事では、Terraformの繰り返し処理の基本であるcount、for_eachの構文の基礎と使い方について解説します。この構文を使うことによって、Terraformで複数のリソースを作成する際のソースコードの冗長化を防ぐことができます。

Terraformの基礎 countとfor_eachの基礎を学び繰り返し処理を効率化しよう

# インフラ基盤を支える運用保守エンジニアとは

私たちの生活に欠かせないサーバーやネットワークは、日々稼働しています。そんなサーバーやネットワークといったシステム面を運用保守するのが「運用保守エンジニア」です。

安定稼働を支えている縁の下の力持ちのような存在であり、IT技術が当たり前となった現代において、その存在は欠かせません。

初学者の方の中には、運用保守エンジニアに興味を持っている方もいるでしょう。

そこで今回は、運用保守エンジニアについて解説します。未経験でも目指しやすいため、ぜひ参考にしてください。

## 運用保守エンジニアとはインフラ維持に欠かせない人材

![https://storage.googleapis.com/envader-article-images/operation-maintenance-engineer/image5.jpg](https://storage.googleapis.com/envader-article-images/operation-maintenance-engineer/image5.jpg)

運用保守エンジニアは、IT社会のインフラ維持に欠かせない人材です。サーバーやネットワークが障害などで停止しないように、運用管理とメンテナンスを行います。

一般的に保守と運用は別個で考えられていますが、企業によっては両方の業務を兼用することがあります。そうした場合に、運用保守エンジニアは活躍できるでしょう。

そんな運用保守エンジニアを知るために、まず以下について知っておくことをオススメします。

- システムの保守
- システムの運用

### システムの保守

![https://storage.googleapis.com/envader-article-images/operation-maintenance-engineer/image6.jpg](https://storage.googleapis.com/envader-article-images/operation-maintenance-engineer/image6.jpg)

運用保守エンジニアは、システムの保守を担っています。中でも重要なのが、「障害対応」です。トラブルが発生した際に、どの部分に障害があるのか原因を究明し、すぐに復旧を試みます。

トラブルは想定外のケースが多々あります。マニュアルに載っていないトラブルと直面することもあるでしょう。

そうした中で適切に対応しなければいけないため、ソフトからハードまで幅広い知識を求められます。

### システムの運用

![https://storage.googleapis.com/envader-article-images/operation-maintenance-engineer/image4.jpg](https://storage.googleapis.com/envader-article-images/operation-maintenance-engineer/image4.jpg)

運用保守エンジニアは、システムの運用も担っています。ITにおいて運用とは、「トラブルを未然に防ぐこと」です。トラブル無く正常に動き続けなければいけません。

そのために、システム運用では以下のような様々な管理を行っています。

- ネットワーク機器やPCなどの管理
- Webアプリケーションなどの性能管理
- ユーザーアカウントの管理
- セキュリティ管理
- 運用マニュアルの作成
- 不正アクセスや負荷の監視

どれもシステム運用において重要なものばかりです。システムは正常に動いてこそなので、運用面はなかなか評価されません。

ですが、従業員の仕事を支える縁の下の力持ちのようなポジションなので、必要な存在です。

## 運用保守エンジニアの仕事内容

![https://storage.googleapis.com/envader-article-images/operation-maintenance-engineer/image8.jpg](https://storage.googleapis.com/envader-article-images/operation-maintenance-engineer/image8.jpg)

運用保守エンジニアの仕事内容は、大きく分けて以下の2種類に分けられます。それぞれどのような仕事内容なのか、詳しく見ていきましょう。

- ネットワーク運用管理
- システム保守業務

### ネットワーク運用管理

![https://storage.googleapis.com/envader-article-images/operation-maintenance-engineer/image13.jpg](https://storage.googleapis.com/envader-article-images/operation-maintenance-engineer/image13.jpg)

ネットワーク運用管理は、ネットワークが安定して繋がるように管理する業務です。ITが前提の業務が増える中、欠かせない仕事となっています。

主な仕事内容は、以下の5つです。

- アクティブ監視
- パッシブ監視
- リソース監視
- 切り分け作業
- セキュリティ管理
- ネットワークインフラストラクチャーの運用と管理

ネットワークを監視し適切な運用を促すとともに、PCやLANケーブルといったIT機器のリソースも監視します。どちらもネットワークを安定して繋げるために必要なものです。

更にネットワークインフラストラクチャーの運用と管理も行います。企業ネットワークのネットワーク接続・通信・運用・管理を可能にするハードウェア・ソフトウェア・システム・デバイスのことです。

多くの企業がクラウドに乗り換えている中、適切なネットワークインフラストラクチャーを運用・管理する意義は大きくなっています。

### システム保守業務

![https://storage.googleapis.com/envader-article-images/operation-maintenance-engineer/image10.jpg](https://storage.googleapis.com/envader-article-images/operation-maintenance-engineer/image10.jpg)

システム保守業務は、サーバーやシステムに何らかの異常が起こった際に適切な対応をし、「正常な状態を保ち、問題無く続けられる状態にする」仕事です。メンテナンスとも呼ばれています。

以下の業務をこなします。

- システムのアップデート作業
- 不具合の原因究明
- 不具合の修正・復旧
- 緊急対応時の故障機器のリプレース
- 不正アクセスの原因究明
- 新しいシステムの導入
- セキュリティパッチの検証と適用

突発的で明確な答えの無い課題に取り組むことが多い点が、特徴です。そのため、ソフト・ハードともに専門的な知識を求められるケースが多々あります。

システム保守業務では、イレギュラーな対応で、不定期かつ突発的な業務が多いということを覚えておきましょう。

なお、システム保守についてはNTT東日本「[システム保守とは？業務内容・運用との違いを徹底解説](https://business.ntt-east.co.jp/content/cloudsolution/column-235.html#section-01-02)」がわかりやすく解説してくれています。気になる方は、こちらもチェックしてみてください。

## 運用保守エンジニアに必要なスキル

![https://storage.googleapis.com/envader-article-images/operation-maintenance-engineer/image1.jpg](https://storage.googleapis.com/envader-article-images/operation-maintenance-engineer/image1.jpg)

初学者の方が運用保守エンジニアを目指すにあたって知っておきたいのが、必要なスキルです。どのようなスキルがあれば活躍できるのかは、気になるポイントですよね。

運用保守エンジニアになるには、まず以下の4つのスキルを身につけましょう。

- IT知識
- 作業の正確さ
- 責任感
- トラブルシューティング技術

### IT知識

![https://storage.googleapis.com/envader-article-images/operation-maintenance-engineer/image3.jpg](https://storage.googleapis.com/envader-article-images/operation-maintenance-engineer/image3.jpg)

運用保守エンジニアでもIT知識は必要です。技術者として働く以上、最低限のIT知識は身につけておきましょう。例えば以下の知識です。

- サーバーについて
- ネットワークについて
- PCについて
- PCの周辺機器について

これらの知識が無ければ、業務をこなせません。ただ、開発者ではないためプログラミングに関する知識は不要です。

それよりも、[情報処理技術者試験](https://www.ipa.go.jp/shiken/index.html)で学ぶような、幅広い知識が求められます。資格を取得しながら身につけると良いでしょう。

### 作業の正確さ

![https://storage.googleapis.com/envader-article-images/operation-maintenance-engineer/image14.jpg](https://storage.googleapis.com/envader-article-images/operation-maintenance-engineer/image14.jpg)

運用保守エンジニアには、正確な作業も求められます。例えば、システムに軽微な修正やメンテナンスが必要になった場合。影響が少ないのであれば、稼働しながら実施するケースがあります。

この際、ミスが発生するとシステム障害にまで発展する可能性があります。軽微だった修正が、大きなトラブルになるケースです。

こうした状況にならないためにも、正確に作業するスキルが求められます。

### 責任感

![https://storage.googleapis.com/envader-article-images/operation-maintenance-engineer/image11.jpg](https://storage.googleapis.com/envader-article-images/operation-maintenance-engineer/image11.jpg)

運用保守エンジニアには責任感も重要です。リリースされたシステムの安定稼働を保守しなければいけません。

異常を放置したり見逃したりすれば、故障などの原因となってシステムの停止を引き起こします。最悪の場合、企業の命運を左右するなんてことも。

システムの運用保守はルーティンワークになりがちです。だからといって手を抜かずに、責任感を持ってやり遂げられるかどうかが、運用保守エンジニアには求められます。

### トラブルシューティング技術

![https://storage.googleapis.com/envader-article-images/operation-maintenance-engineer/image12.jpg](https://storage.googleapis.com/envader-article-images/operation-maintenance-engineer/image12.jpg)

運用保守エンジニアには、システムやネットワークの問題を解決するためのトラブルシューティング技術も求められます。

システムやネットワークが止まると、業務が全て止まってしまう企業も多くあります。対応力が問われるトラブルシューティング技術は、重要です。

また、運用保守エンジニアだけでなく、他のエンジニア職でも求められる能力でもあります。キャリアパスとして別のエンジニアを目指している方にとっても、身につけておいて損はないスキルと言えるでしょう。

## 運用保守エンジニアを目指すならインシデント対応ガイドが大切

![https://storage.googleapis.com/envader-article-images/operation-maintenance-engineer/image9.jpg](https://storage.googleapis.com/envader-article-images/operation-maintenance-engineer/image9.jpg)

運用保守エンジニアを目指すのなら、[インシデント対応ガイド](https://www.ipa.go.jp/security/reports/oversea/nist/ug65p90000019cp4-att/000025341.pdf)には必ず目を通してきましょう。米国立標準技術研究所によるコンピューターセキュリティの勧告で、国内ではIPAが翻訳監修しています。

インシデントとは、出来事・事件・事例・事案・事象といった意味を持つ英単語です。それらが転じて、近年ではアクシデントになる一歩手前の状況を指します。

そのため、対応ガイドには以下の2つが記載されています。

- システムインシデントに対処する方法
- システムインシデントの対応ガイド

システム運用・保守において気をつけなければいけない点が、ソフトやハード、人的資本にいたるまで網羅されている内容です。

運用保守エンジニアにとって非常に大切なガイドと言えます。

## 運用保守エンジニアのキャリアパス

![https://storage.googleapis.com/envader-article-images/operation-maintenance-engineer/image7.jpg](https://storage.googleapis.com/envader-article-images/operation-maintenance-engineer/image7.jpg)

運用保守エンジニアの一般的なキャリアパスは、以下の2つに分かれます。

- リーダー・マネージャーを目指す
- 他のエンジニアを目指す

経験と実力をつけて立場を上げるか、他のエンジニアを目指すかのどちらかです。

運用保守エンジニアは、ネットワークやサーバーに多く触れます。身につけた知識・技術を活かせば、ネットワークエンジニアやサーバーエンジニアも目指せます。プログラミングを習得すれば、開発エンジニアにもなれるでしょう。

運用保守のスキルは、エンジニアならどこでも通じます。身につけたスキルを活かせるキャリアを目指してくださいね。

## 運用保守エンジニアは初学者でも目指しやすいエンジニア

![https://storage.googleapis.com/envader-article-images/operation-maintenance-engineer/image2.jpg](https://storage.googleapis.com/envader-article-images/operation-maintenance-engineer/image2.jpg)

運用保守エンジニアは、開発エンジニアと違って深いIT知識が必要のないエンジニアです。ITに関する幅広い知識を駆使するため、初学者や未経験の方でも目指しやすいと言えます。

業務をこなしながら学んでいけば、様々なキャリアアップも可能です。運用保守のための正確さを求められるので、得意な方は挑戦してみることをオススメします。

私たちの生活に欠かせないサーバーやネットワークは、日々稼働しています。そんなサーバーやネットワークといったシステム面を運用保守するのが「運用保守エンジニア」です。

インフラ基盤を支える運用保守エンジニアとは

# IaaS, PaaS, SaaS３つの違いを理解する

![001.png](https://storage.googleapis.com/envader-article-images/iaas-paas-saas/001.png)

## クラウドコンピューティングの重要性と普及の背景

クラウドコンピューティングはビジネスの世界だけでなく、私たちの日常生活の中でも急速に普及してきました。この技術がなぜこれほどまでに人々の注目を集め重要性を増したのでしょうか。

### 1. コスト削減
従来のITインフラストラクチャは大きな初期投資が必要で、ハードウェアの購入・設置・保守に多額の費用がかかりました。クラウドコンピューティングの登場により、オンデマンドでリソースを利用することができるようになり、大きな初期コストや保守コストの負担を大きく軽減することができました。

### 2. 柔軟性とスケーラビリティ
クラウドはトラフィックの増減に応じてリソースを瞬時にスケーリングすることができます。これによりビジネスのニーズに応じて簡単に拡張や縮小が可能となりました。

### 3. アクセスの簡易性
クラウドコンピューティングはインターネット経由でどこからでもアクセス可能なため、リモートワークや分散型チームの協力が格段に簡単になりました。

### 4. イノベーションと速度
クラウドプロバイダーは最新の技術とアップデートを常に提供しています。企業は新しい技術のベネフィットを享受しながら、自身での大規模な設備投資や研究に時間を割く必要がなくなりました。

これらの利点によりスタートアップから大企業まで、さまざまな業種や規模の組織がクラウドコンピューティングを採用しています。

## IaaS (Infrastructure as a Service)とは

### IaaSの定義

IaaSはクラウドサービスの一つで、仮想化されたコンピューティングリソースをインターネット経由で提供するサービスです。IaaSを利用することでユーザーは物理的なハードウェアを設置や保守することなく、必要なインフラストラクチャを必要なときにすぐに使用することができます

### IaaSの主な特徴

- オンデマンドのリソース
    ユーザーは必要に応じてリソースを追加・削減することができます。
- ネットワーク接続の仮想環境
    仮想マシン、ストレージ、ネットワークなどの基本的なITリソースへのアクセスが可能。
- コスト効率
    使用したリソースのみを課金されるため、コストを効率的に管理できます。
- フル管理
    ユーザーは提供されたリソース上でOSやアプリケーションなどを自由に管理・設定できます。

### IaaSの例

| サービス名 | 提供 | 説明 |
| ---- | ---- | ---- |
| Amazon EC2 (Elastic Compute Cloud) | Amazon Web Services (AWS) | スケーラビリティや負荷分散機能をを持つ |
| Google Compute Engine | Google Cloud Platform | 高性能な仮想マシンやカスタマイズ可能な環境を提供 |
| Azure Virtual Machines | Microsoft Azure | WindowsとLinuxの仮想マシンを短時間でデプロイし、Microsoftの豊富なエコシステムと統合された環境での運用が可能 |

### IaaSの利用シナリオやメリット・デメリット

#### IaaSの利用シナリオ

- 高負荷のWebアプリケーション
    トラフィックの変動に対応できるスケーラビリティが必要な場合。
- テスト環境の構築
    一時的にリソースが必要な場合や、さまざまな環境でのテストを行いたい場合。
- バックアップや災害復旧
    データのバックアップや緊急時のリソース確保が求められる場合。

#### IaaSのメリット

- 柔軟性
    必要に応じてリソースを増減させることができる。
- コスト削減
    物理的なインフラの導入・保守コストが不要。
- 速度
    新しいリソースを迅速にデプロイできる。

#### IaaSのデメリット

- 管理の難しさ
    クラウドインフラの管理やセキュリティ設定には専門知識が求められることがある。
- 費用の予測
    使用に応じた課金モデルのため、予想以上の費用がかかるリスクがある。

## PaaS (Platform as a Service)とは

### PaaSの定義

PaaSはクラウドサービスのカテゴリの一つで、アプリケーションを開発、運用、実行するためのプラットフォームやツールをインターネット経由で提供するサービスです。開発者はアプリケーションの開発に集中でき、インフラストラクチャの管理や設定の手間を省けます。

### PaaSの主な特徴

- 開発ツールの提供
    データベース、開発フレームワーク、開発・テスト・デプロイツールなどを組み込んで提供。
- スケーラビリティ
    トラフィックの増減に応じて、自動的にリソースがスケーリングされる。
- 統合開発環境
    一貫した環境でのアプリケーションの開発、テスト、デプロイが可能。
- 中間ソフトウェアの管理
    OSやサーバー、ネットワークの管理の必要がなく、アプリケーションレイヤにのみ焦点を当てることができる。

### PaaSの例

| サービス名 | 提供 | 説明 |
| ---- | ---- | ---- |
| Heroku | Salesforce | シンプルなデプロイメントとスケーラビリティを持つクラウドベースのPaaS。様々なプログラミング言語をサポート |
| Google App Engine | Google Cloud Platform | 複数の言語やフレームワークに対応し、自動スケーリング機能を持つ |
| Microsoft Azure App Service | Microsoft Azure | Webアプリ、モバイルアプリ、APIの開発とホスティングをサポートしており、.NET, Node.js, Java, PHP, Pythonなど多数の言語やフレームワークをサポートしている。統合されたCI/CD機能や自動スケーリングを提供 |

### PaaSの利用シナリオやメリット・デメリット

#### PaaSの利用シナリオ

- Rapid Application Development
    短期間でのアプリケーション開発やプロトタイプ作成。
- マイクロサービスの開発
    小さなサービスを独立して開発・デプロイしたい場合。
- Webアプリケーションやモバイルバックエンド
    インフラの管理を少なくしたい場合。

#### PaaSのメリット

- 高速な開発
    インフラのセットアップや管理の手間を省略できるため、開発スピードが上がる。
- コスト効率
    必要なリソースのみを使用し課金されるため、コストを効率的に管理できる。
- 柔軟性
    さまざまな言語やフレームワークに対応している。

#### PaaSのデメリット

- 柔軟性の制限
    一方で制限もあり、提供されているプラットフォームやツールに制約がある場合がある。
- ロングタームのコスト
    長期間使用する場合、費用が高くなる可能性がある。
- 移行の難しさ
    他のプラットフォームへの移行が難しくなる場合がある。

## SaaS (Software as a Service)とは

### SaaSの定義

SaaSはクラウドサービスのカテゴリの一つで、インターネット経由でソフトウェアアプリケーションを提供するサービスです。ユーザーはブラウザ経由でアクセスし、オンプレミスのソフトウェアインストールやメンテナンスの必要がありません。

### SaaSの主な特徴

- ブラウザ経由のアクセス
    ソフトウェアをローカルにインストールすることなく、インターネットとブラウザがあればどこからでもアクセス可能。
- サブスクリプションベース
    通常、月額や年額での課金が行われ、ライセンス購入の必要がない。
- 自動アップデート
    ソフトウェアの更新やパッチが自動的に適用される。
- マルチテナント環境
    一つのアプリケーションインスタンスが複数の顧客にサービスを提供。

### SaaSの例

| サービス名 | 説明 |
| ---- | ---- |
| Google Workspace | クラウドベースのオフィススイート。ドキュメント作成、スプレッドシート、プレゼンテーション、メールなどのツールを提供 |
| Salesforce | クラウドベースのCRMソフトウェア。顧客関係管理を中心に、マーケティング、セールス、サービスなどの機能を統合して提供 |
| Slack	| クラウドベースのチームコミュニケーションツール。チャット、ファイル共有、ビデオ会議などの機能を提供し、チームのコラボレーションを強化 |

### SaaSの利用シナリオやメリット・デメリット

#### SaaSの利用シナリオ

- ビジネスアプリケーション
    CRM、ERP、HR管理などのビジネスプロセスをサポート。
- コラボレーションツール
    ドキュメント共有、ビデオ会議、チャットなどのコミュニケーションツール。
- 特定の業界向けソリューション
    教育、医療、不動産など特定の業界向けのアプリケーション。

#### SaaSのメリット

- 手軽さ
    インストールやメンテナンスの手間がなく、すぐに利用開始できる。
- コスト効率
    アップフロントのコストが少なく、継続的な費用も予測しやすい。
- アクセスの柔軟性
    どのデバイスからでもアクセス可能。

#### SaaSのデメリット

- データのプライバシー
    サードパーティがデータを管理しているため、プライバシーやセキュリティの懸念が生じることがある。
- カスタマイズの制限
    既存のソリューションに合わせる形になるため、特定のビジネスニーズに応じたカスタマイズが難しいことがある。
- 長期のコスト
    長期間利用すると、総コストが高くなる可能性がある。

## IaaS, PaaS, SaaSの比較

### サービスモデルの違いの概要

| サービスモデル | ユーザーが管理するもの | 例 |
| ---- | ---- | ---- |
| IaaS | OS、ミドルウェア、ランタイム、アプリケーション、データ | Amazon EC2, Google Compute Engine, Azure Virtual Machines |
| PaaS | アプリケーションとデータ | Heroku, Google App Engine, Azure App Service |
| SaaS | 主に自分のデータのみ | Google Workspace, Salesforce, Slack |

### どのサービスモデルを選択すべきか

#### IaaSの選択を検討する場面

- 既存のオンプレミスインフラをクラウドに移行したい場合
- フルコントロールしたいとき、特定のOSや設定を使用する必要がある場合
- 独自のネットワークトポロジーやIPアドレスを持ちたい場合

#### PaaSの選択を検討する場面

- アプリケーションの開発に焦点を当て、インフラの管理を最小限にしたい場合
- 複数のデバイスやプラットフォームでアプリケーションを展開する予定の場合
- 一貫した環境でのアプリケーションのデプロイやスケーリングを容易にしたい場合

#### SaaSの選択を検討する場面

- クイックスタートが必要で、カスタマイズやインフラ管理を最小限にしたい場合
- ソフトウェアのアップデートやメンテナンスを自動化したい場合
- コストを初期投資やメンテナンスからサブスクリプション料にシフトしたい場合

最終的に組織のニーズ・技術的な要件・予算・スキルセットなどの要因を考慮し、最適なサービスモデルを選択することが重要です。

## まとめ

IaaS, PaaS, SaaS３つの違いとその選び方を学びました。

選択するクラウドサービスのモデルは、組織のニーズ・技術的な能力・管理したい範囲に基づいて決定すべきです。IaaSは最も柔軟性がありますが、管理の範囲も広いです。一方でSaaSは手間が最も少ないですが、カスタマイズの自由度は最も低いです。PaaSはこの2つの間のバランスを取るサービスと言えるでしょう。


この記事ではIaaS, PaaS, SaaS３つの違いとその選び方を学びます。

IaaS, PaaS, SaaS３つの違いを理解する

# Terraform Workspaceの基礎知識。workspaceの操作と仕組み

## はじめに

近年、インフラストラクチャのコード化、通称**IaC** (**I**nfrastructure **a**s **C**ode) が注目を浴びています。その中でも中心的なツールの1つが「Terraform」です。本記事では、このTerraformの機能の一つである「workspace」に焦点を当て、その基本から使い方に至るまでをご紹介します。

## Terraformとは？

Terraformは、HashiCorp社によって開発されたオープンソースのIaCツールです。Terraformを使うことで、従来の手動でのインフラ管理や設定作業を自動化し、コードベースでの管理が可能になります。その結果、インフラの設定変更やデプロイを迅速かつ確実に行うことができます。

クラウド環境でのリソース管理において、Terraformは多くのクラウドプロバイダとの互換性を持ち、AWS、GCP、Azureなど主要なクラウドサービスでのインフラ構築を一元的にコードで管理することができます。

IaCについては以下の記事にて解説しています。

[https://envader.plus/article/136](https://envader.plus/article/136)

Terraformを用いることで、複数の環境や複数のリージョンでのリソースの状態を一貫して維持することが容易になります。エンジニアの作業効率の向上だけでなく、エラーの発生リスクも低減します。

## Terraformにおけるworkspaceとは？

![workspace-1.png](https://storage.googleapis.com/envader-article-images/terraform-workspace/workspace-1.png)

Terraformのworkspaceは、異なる環境を分けて管理するための「仮想の作業部屋」のようなものです。「開発」「ステージング」「本番」といった異なる環境を分けて管理することができます。workspaceを使わずに環境を分ける場合、それぞれの環境ごとにディレクトリを分けるなどの必要がありました。workspaceはコマンド一つで環境を切り替えることができるため、開発環境やステージング環境にすぐに移行して作業することが可能です。
開発環境やステージング環境については次の記事で解説しています。

[https://envader.plus/article/134](https://envader.plus/article/134)

### workspaceではStateファイルを分割できる

Terraformでインフラをコード化すると、その構成や状態を表す「tfstateファイル（通常、`terraform.tfstate`として保存される）」が生成されます。デフォルトでは1つのtfstateファイル（以降Stateファイル）で全てのリソースを管理することになります。これは大きなプロジェクトや複数の開発者が関わる状況での問題（Stateファイルのコンフリクト、同期の問題など）を引き起こす可能性がありました。

![workspace-2.png](https://storage.googleapis.com/envader-article-images/terraform-workspace/workspace-2.png)

workspaceという機能を導入することで、「開発」「ステージング」といった環境ごとにStateファイルが作成されます。これにより、環境ごとのStateファイルを管理することが可能になりました。環境ごとにStateファイルを分けることで、前述したコンフリクトや同期の問題を効果的に回避できるようになったのです。

![workspace-3.png](https://storage.googleapis.com/envader-article-images/terraform-workspace/workspace-3.png)

tfstateファイルについては、以下の記事で解説しています。

[https://envader.plus/article/199](https://envader.plus/article/199)
[https://envader.plus/article/199](https://envader.plus/article/199)

## どんな時にworkspaceを使うべきか？

Terraformの公式ドキュメントでは、以下のようにユースケースとして解説されています。

> You can create multiple working directories to maintain multiple instances of a configuration with completely separate state data. However, Terraform installs a separate cache of plugins and modules for each working directory, so maintaining multiple directories can waste bandwidth and disk space. This approach also requires extra tasks like updating configuration from version control for each directory separately and reinitializing each directory when you change the configuration. Workspaces are convenient because they let you create different sets of infrastructure with the same working copy of your configuration and the same plugin and module caches.
> 
> 
> A common use for multiple workspaces is to create a parallel, distinct copy of a set of infrastructure to test a set of changes before modifying production infrastructure.
> 
> Non-default workspaces are often related to feature branches in version control. The default workspace might correspond to the main or trunk branch, which describes the intended state of production infrastructure. When a developer creates a feature branch for a change, they might also create a corresponding workspace and deploy into it a temporary copy of the main infrastructure. They can then test changes on the copy without affecting the production infrastructure. Once the change is merged and deployed to the default workspace, they destroy the test infrastructure and delete the temporary workspace.
> 

[Managing Workspaces](https://developer.hashicorp.com/terraform/cli/workspaces#use-cases)**より引用**

実際の現場ではさまざまなユースケースが考えられます。以下では、公式ドキュメントからどういった使い方が適しているのかを考察しました。

### ディスクスペースなどのリソースを節約したい時

workspaceを使うと、1つのディレクトリ内で複数の環境や設定を切り替えて管理することができるようになります。何度もプラグインやモジュールをダウンロード・保存する手間が省けるため、ディスクスペースを節約できます。

つまり、リソースの使用状況を節約したいといった場面に効果を発揮するということです。

異なる環境ごとにディレクトリを作成する場合、それぞれのディレクトリにはプラグインやモジュールの情報がダウンロード・保存されます。多くのディレクトリを持つということは、それだけ多くのディスクスペースを消費することに繋がります。

### テストを行う場合

本番環境と似たテスト環境を作ることで、安全に変更を試すことができます。このテスト環境は、新しい変更を試す場所として役立ち、万が一の問題があった場合でも本番環境には影響を及ぼしません。変更が正しく動作することをテスト環境で確認した後、本番環境にその変更を適用することができ、これにより本番での問題を最小限に抑えることができます。

## **workspaceの基本的な操作**

workspaceの操作方法は非常にシンプルで分かりやすいです。基本的な使い方は以下になります。

```jsx
$ terraform [オプション」 workspace [サブコマンド]
```

`terraform -h workspace`でヘルプがひけます。

```jsx
$ terraform -h workspace
Usage: terraform [global options] workspace

  new, list, show, select and delete Terraform workspaces.

Subcommands:
    delete    Delete a workspace
    list      List Workspaces
    new       Create a new workspace
    select    Select a workspace
    show      Show the name of the current workspace
```

### workspaceの確認と作成

現在洗濯中のworkspaceを確認するには、`show`コマンドを使用します。

```jsx
$ terraform workspace show
default
```

Terraformを初期化した際には、defaultのworkspaceが自動で作成されています。workspaceを新しく作成するには`new`コマンドを使用します。

```jsx
# workspaceを作成する
$ terraform workspace new dev
Created and switched to workspace "dev"!

You're now on a new, empty workspace. Workspaces isolate their state,
so if you run "terraform plan" Terraform will not see any existing state
for this configuration.
```

`terraform new 作成したいworkspace名`とすることで、新しくworkspaceが作成されていることが分かります。注意する点は、workspaceを作成すると自動で作成したworkspaceへ切り替えられることです。間違いに注意しましょう。

### workspaceのリスト表示

`list`コマンドで、存在しているworkspaceを確認できます。

```jsx
$ terraform workspace list
  default
* dev
```

*が表示されている方が、現在のworkspaceになります。このコマンドでは、存在している全てのworkspaceを確認することができます。

### workspaceの切り替え

`select`コマンドでworkspaceを切り替えます。

```jsx
$ terraform workspace select default
Switched to workspace "default".
```

### workspaceの削除

`delete`コマンドでworkspaceを削除できます。

```jsx
$ terraform workspace delete dev
Deleted workspace "dev"!
```

削除する際にも、確認のメッセージは表示されません。間違って残しておくべきworkspaceを削除してしまわないように注意が必要です。

### **workspaceでの文字列補完**

workspace機能で便利なのが、`${terraform.workspace}`とすることでworkspaceの文字列を使用できる点です。コードの中に記述することで文字列として補完できるため、workspaceごとにタグの内容を変更したいときなどに活用できます。

```jsx
# workspaceがdevの場合
resource "aws_vpc" "test" {
  cidr_block = "10.0.0.0/16"

  tags = {
    Name = "${terraform.workspace}-VPC"
  }
}

# terraform planの結果
~~~~~~~~~中略~~~~~~~~~~~
+ owner_id                             = (known after apply)
      + tags                                 = {
          + "Name" = "dev-VPC"
        }
      + tags_all                             = {
          + "Name" = "dev-VPC"
        }
    }
```

## workspaceの機能を使って環境別のVPCを作成する

シンプルな例として、workspaceをdev、stg、prdに分けて作成し、VPCを環境ごとに作成します。VPCのソースコードは先ほどの例をそのまま使用します。

はじめに`terraform new`コマンドで3つの環境を作成します。

```jsx
$ terraform workspace new dev
Created and switched to workspace "dev"!

You're now on a new, empty workspace. Workspaces isolate their state,
so if you run "terraform plan" Terraform will not see any existing state
for this configuration.

# 一度に作成できないため、stg、prdを順番に作成する。
```

3つのworkspaceを作成後、devへworkspaceを切り替えます。

```jsx
$ terraform workspace select dev
Switched to workspace "dev".
```

この状態で`terraform apply`を実行します。devのworkspaceで実行して良いか質問されるため、yesと入力し実行します。

```jsx
$ terraform apply
~~~~~~中略~~~~~
+ owner_id                             = (known after apply)
      + tags                                 = {
          + "Name" = "dev-VPC"
        }
      + tags_all                             = {
          + "Name" = "dev-VPC"
        }
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions in workspace "dev"?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes
```

次にstgのworkspaceへ切り替えます。

```jsx
$ terraform workspace select stg
Switched to workspace "stg".
```

VPCのソースコードはそのまま、stgのworkspaceで`terraform apply`を実行します。

```jsx
$ terraform apply
~~~~~~中略~~~~~
+ tags                                 = {
          + "Name" = "stg-VPC"
        }
      + tags_all                             = {
          + "Name" = "stg-VPC"
        }
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions in workspace "stg"?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes
```

prdのworkspaceも同様に、切り替えと`terraform apply`を実行します。完了後、マネジメントコンソールで3つのVPCが作成されているか確認します。

![workspace-4.png](https://storage.googleapis.com/envader-article-images/terraform-workspace/workspace-4.png)

ソースコードを変更せずに、タグを環境ごとに変更しVPCを作成することができました。このように、一つのソースコードでリソースを管理することができるのがworkspaceの機能です。

## workspaceで生成されるディレクトリ

新しくworkspaceを作成すると、`.terraform.tfstate.d`というディレクトリが生成され、その中に`workspace名`のディレクトリが生成されます。その後、実際にVPCなどのリソースを作成すると`workspace名`のディレクトリ内に環境ごとのStateファイルが作成されるようになります。

main.tfと同じディレクトリに存在しているStateファイルは、defaultのworkspaceを管理しているものです。

```jsx
# 例
$ tree .
.
├── main.tf
├── terraform.tfstate
└── terraform.tfstate.d # 以下、workspaceで管理されるディレクトリ
    └── dev
        └── terraform.tfstate
```

このような仕組みで、workspaceごとにStateファイルを分けて管理しています。

## まとめ

Terraformのworkspaceの基礎知識と使い方について、本記事を通して学びました。

workspaceはTerraformでのインフラ管理を効率的に行うための機能の一つです。特に、複数の環境を持つプロジェクトにおいては、環境の切り替えや設定の管理をスムーズに行うための必須のツールと言えるでしょう。この機能を使うことで、「開発」「ステージング」「本番」といった異なる環境間での移動や操作が、コマンドひとつで可能になります。

workspaceを活用することで、それぞれの環境ごとに専用のStateファイルを持つことができます。これにより、環境ごとのインフラの状態を明確に把握し、管理することが簡単になります。

注意点として、どのworkspaceが現在アクティブなのかを常に意識することです。誤って別の環境で操作を実行してしまうと、予期しない問題や変更が生じる可能性があります。

workspaceを上手く活用するためには、その機能と仕組みをしっかり理解し、適切な環境管理の習慣を身につけることが必要です。

Terraformの機能の一つである「workspace」に焦点を当て、その基本から使い方に至るまでをご紹介します。

Terraform Workspaceの基礎知識。workspaceの操作と仕組み

# 【BIND高度】chroot環境を構築する際の必要知識について解説

こちらの記事では、BINDを使用したDNSサーバーにchroot環境を構築する方法について解説します。BINDの基礎的な概念については、以下の記事で紹介していますので必要に応じてご参照ください。

[https://envader.plus/article/212](https://envader.plus/article/212)

また、実際に手を動かしながら学びたいという方は、以下の記事でBINDを使用したDNSサーバーにchroot環境を構築する方法をハンズオン形式で紹介していますのでご参照ください。

[https://envader.plus/article/229](https://envader.plus/article/229)

## 本記事の解説事項

本記事では以下の項目について解説します。

1. chroot環境の構築とは
2. なぜchroot環境を構築するのか
3. chroot環境の隔離
4. BINDをchroot環境内で設定する際の明示的なファイルパス指定
5. デバイスファイルの作成
6. BINDが読み込むnamed.confの変更
7. セキュリティ制限の定義の追加

## 1. chroot環境の構築とは

chroot（**ch**ange **root**）環境の構築とは、特定のプログラムやプロセスが動作する際に、そのプログラムやプロセスが利用できる「**ファイルシステムのルートディレクトリを変更する操作**」のことを指します。この技術はUNIX系のオペレーティングシステムにおいて長い間利用されてきました。

chroot自体はBINDや特定のアプリケーションに限ったものではありません。多くのUNIXベースのプログラムやデーモンで使用され、一時的な作業環境の作成やパッケージのビルド、リカバリ作業などの多岐にわたる用途で利用されています。

## 2. なぜchroot環境を構築するのか

chroot環境の構築は、**システム全体のセキュリティと信頼性を向上させる**のに役立ちます。特に、サーバー上で動作するデーモンやサービスを隔離することで、セキュリティのリスクを低減できます。もし特定のサービスが攻撃を受けた場合でも、chroot環境の壁が攻撃者の動きを制限し、システム全体へのアクセスを難しくすることができます。

また、chroot環境はセキュリティの向上やプロセスの隔離、開発・テスト環境の分離、依存関係の管理などの様々な目的で使用されます。

しかし、chroot環境の構築は難易度が高いです。設定やセキュリティポリシーの管理が正しく行われていない場合、脆弱性を産む結果になりかねません。そのためにも正しい知識を身につける必要があります。

## 3. chroot環境の隔離

chroot環境を設定する際、単に領域を構築するだけでは十分ではありません。chroot環境は外部とのアクセスを制限し、環境を隔離することを目的としています。そのため、chroot環境の領域を構築後、**chrootと外部を繋ぐディレクトリには正しい所有者・権限の設定が非常に重要**です。

以下はchroot環境のイメージ図です。

![chroot_01.png](https://storage.googleapis.com/envader-article-images/bind-chroot/chroot_01.png)

chroot環境は、指定されたディレクトリ（図でいうと`named`ディレクトリ）を新しいルートとして設定し、そのディレクトリをルートディレクトリとして扱う隔離された環境を作成します。この環境では、指定されたディレクトリがルートディレクトリであるように見えます。

また、上記図のPOINTで記載したように「chroot環境を現行のシステム環境と同じように構築する」ことでchroot環境が現実のシステム環境に近くなり、より多くのアプリケーションやサービスが正常動作するようになります。

## 4. BINDをchroot環境内で設定する際の明示的なファイルパス指定

上記の図で説明すると、通常のシステムのルートは`/`ですが、chroot環境内のBINDのルートは`/named`になります。例えば、`/etc/bind`というファイルパスがあった場合、BINDにとっては`/named/etc/bind`というファイルパスで認識します。

そのため、chroot環境内のプログラムはchroot環境内のファイルパスを正しく認識するためにも、**ファイルパスを明示的に指定することは非常に重要**です。また、**ファイルパスを指定する際のルートは指定したディレクトリであることを意識する**ことも大切です。

以下に、明示的にファイルパスを指定する必要のあるファイルの一例を紹介します。

### 4-1. `bind.keys`

`bind.keys`には、一般的にはルートゾーンの公開鍵（トラステッドキーまたは信頼アンカー）が格納されています。**DNSSECの検証プロセスにおいて、署名されたDNS情報を検証する際の信頼の起点として使用されます**。このため、`bind.keys`は非常に重要なファイルです。

指定方法は以下の2通りです。

- `named.conf`で`bind.keys`をincludeする
    
    ```bash
    include "/etc/keys/bind.keys";
    ```
    
- `named.conf.options`などで`key-directory`ディレクティブを使用する
    
    ```bash
    options {
    	# BINDが管理する信頼アンカーを格納するディレクトリを指定
    	# 指定ディレクトリには、`bind.keys`を含む、BINDによって管理される信頼アンカーが格納される
    	key-directory "/etc/keys";
    }
    ```
    

### 4-2. `named.pid`

`named.pid`は、BINDのプロセスIDが記録されるファイルです。`.pid`は**PID**（**P**rocess **ID**）のことで、実行中のプロセスを一意に識別するための番号のことを指します。PIDは通常、システムがサーバーのプロセスを管理する際に使用されます。

`named.pid`はBINDが自動で生成するファイルです。そのため、生成するディレクトリを用意し、ファイルパスを指定する必要があります。

### 4-3. `session.key`

`session.key`は、ダイナミックDNSの認証キーを保存するファイルです。ダイナミックDNSは、DNSの変更を許可する際にセキュリティキーが必要であり、そのキーがダイナミックDNSの認証キーとなります。

`session.key`もBINDが自動で生成するファイルです。そのため、生成するディレクトリを用意し、ファイルパスを指定する必要があります。

## 5. デバイスファイルの作成

![chroot_02.png](https://storage.googleapis.com/envader-article-images/bind-chroot/chroot_02.png)

**`/dev/null`**, **`/dev/random`**, および **`/dev/urandom`** のデバイスファイルの作成は必ずしも必須ではありませんが、BINDの正常な動作のために推奨されます。

各種デバイスファイルがBINDの動作に関与する部分を以下に説明します。

### `/dev/null`

BINDは多くのログやエラーメッセージを出力する可能性があります。特定のメッセージを無視するために、これらのメッセージを`/dev/null`にリダイレクトするのが一般的です。この処理を行うことにより、**不要なメッセージがシステムのログファイルに記録されるのを防ぐ**ことができます。

### `/dev/random`および`/dev/urandom`

DNSの処理では。クエリや応答などの特定の操作において、安全で予測できないIDや署名が必要です。これらのランダムな値を作るために、`/dev/random`や`/dev/urandom`という特別な場所からデータを取得します。

`/dev/random`はランダムなデータを生成するのに時間がかかることがあります。一方、`/dev/urandom`はすぐにランダムなデータを提供してくれます。

## 6. BINDの読み込み元のnamed.confの変更

chroot環境を構築するためには、chroot環境下に定義した`named.conf`（BIND設定ファイル）を読み込む必要があります。Ubuntuのnamedに関する設定は、`/lib/systemd/system/named.service`に定義されています。この、`named.service`を変更することで読み込み元の`named.conf`を変更することができます。

`/lib/systemd/system/named.service`の中身が以下になります。

```bash
$ cat /lib/systemd/system/named.service

[Unit]
Description=BIND Domain Name Server
Documentation=man:named(8)
After=network.target
Wants=nss-lookup.target
Before=nss-lookup.target

[Service]
EnvironmentFile=-/etc/default/named
ExecStart=/usr/sbin/named -f $OPTIONS
ExecReload=/usr/sbin/rndc reload
ExecStop=/usr/sbin/rndc stop
Restart=on-failure

[Install]
WantedBy=multi-user.target
Alias=bind9.service
```

`ExecStart`はnamedの起動時の設定オプションで、`$OPTIONS`と記述されています。この`OPTIONS`は、`EnvironmentFile`で記述されている`/etc/default/named`に定義された`OPTIONS`を参照しています。

`/etc/default/named`の中身が以下になります。

```bash
$ cat /etc/default/named

#
# run resolvconf?
RESOLVCONF=no

# startup options for the server
OPTIONS="-u bind"
```

このように、Ubuntuでは`/etc/default/named`に`OPTIONS`を定義し、`named.service`でそれを読み込むアプローチが採用されています。

ここまでを踏まえ、BINDの読み込み元の`named.conf`の変更方法は、以下の2通りの方法があります。

- `/etc/default/named`の`OPTIONS`を変更する（Ubuntuのアプローチに則る）
    
    ```bash
    # chroot環境下のnamed.confを使用
    OPTIONS="-u bind -t /chroot/named -c /etc/named.conf"
    ```
    
- `/lib/systemd/system/named.service`を直接変更する
    
    ```bash
    ExecStart=/usr/sbin/named -f -u bind -t /chroot/named -c /etc/named.conf
    ```
    

named.serviceを変更した際には、新しい設定をsystemdに反映させる必要があります。反映させるためには、以下のコマンドを実行します。

```bash
$ sudo systemctl daemon-reload
```

## 7. セキュリティ制限の定義の追加

**AppArmor**（**App**lication **Armor**）は、アプリケーションごとのアクセス制御を提供するセキュリティツールです。

BINDに関するセキュリティ制限の定義は、AppArmorのポリシー設定ファイルの一部として`/etc/apparmor.d/usr.sbin.named`というプロファイルが存在します。このプロファイルに、BINDに対するアクセス制限を定義することで、BINDのセキュリティを強化することができます。

AppArmorの権限指定方法に関しては、以下の表にまとめました。

| 権限 | 説明 | 例 |
| --- | --- | --- |
| r | 読み込み許可 | /etc/named.conf r, |
| w | 書き込み許可 | /var/cache/** w, |
| rw | 読み書き両方の許可 | /var/cache/** rw, |
| m | メモリマップファイルの許可 | /usr/sbin/named m, |
| k | ファイルのロックの許可 | /var/lock/bind.lock k, |
| ix | 実行許可（継承）。子プロセスが親のプロファイルを継承する | /usr/sbin/named ix, |
| Px | プロファイルの変更を許可せずに実行。子プロセスは指定されたプロファイルで実行される | /usr/bin/some-binary Px, |
| Ux | 実行時にunconfinedになる。子プロセスは制限なしで実行される | /usr/bin/unconfined-binary Ux, |
| C | capabilityの許可。特定のカーネル機能へのアクセスを許可する | capability net_bind_service, |

具体的なアクセス制限の定義の手順は以下の通りです。

### 7-1. プロファイルの内容の編集

以下の内容をプロファイルに追加します。（`/chroot/named`以下がchroot環境下とした場合）

```bash
$ sudo vim /etc/apparmor.d/usr.sbin.named

/usr/sbin/named {
    # ... 既存の内容 ...

    # chroot環境へのアクセス許可
    /chroot/named/** r,
}
```

### 7-2. AppArmorの再起動

設定を反映させるために、AppArmorを再起動します。

```bash
$ sudo systemctl restart apparmor
```

## まとめ

こちらの記事では、BINDにおけるchroot環境を構築する際の必要知識について解説しました。BINDの設定や運用を適切に行うためには、今回紹介した中で登場したデバイスファイルの理解やセキュリティツールなどの知識が必要になります。

chroot環境は要件や用途に合わせて柔軟に設定が行えるため、必要な環境を柔軟にカスタマイズできるようになるためにも幅広い知識を身につけていきましょう。

 こちらの記事では、BINDを使用したDNSサーバーにchroot環境を構築する方法について解説します。

【BIND高度】chroot環境を構築する際の必要知識について解説

# 【BIND高度実践】chroot環境を構築してみよう【前編】

![chroot_handson_01.png](https://storage.googleapis.com/envader-article-images/bind-chroot-first-half/chroot_handson_01.png)

こちらの記事では、BINDを利用したDNSサーバーにchroot環境を構築する手順をハンズオン形式でご紹介します。対象となるDNSサーバーの環境は、以下の記事で作成した環境を使用します。

[https://envader.plus/article/213](https://envader.plus/article/213)

また、chroot環境の構築に関する解説は以下の記事で紹介しています。不明点がある場合は、その記事を参照しながら本ハンズオンを進めてください。

[https://envader.plus/article/228](https://envader.plus/article/228)

## 本記事で行うchroot環境の構築手順

本記事では以下の手順でchroot環境の構築を行います。

1. chroot環境の領域の作成
2. `/etc/bind`から必要なファイルのコピー
3. confファイルの読み込み先の変更
4. デバイスファイルの作成
5. chroot環境の隔離

## 1. chroot環境の領域の作成

以下のコマンドで、chroot環境の領域を作成します。ここでは、通常のシステムのルートに存在するディレクトリと同様のディレクトリを作成します。

```bash
$ sudo mkdir -p /chroot/named/{etc,dev,run,usr,var}
```

作成されたchroot環境の領域の構造は以下になります。

```bash
/
└──	chroot
			└── named
			    ├── dev
			    ├── etc
			    ├── run
			    ├── usr
			    └── var
```

## 2. `/etc/bind`から必要なファイルのコピー

`/etc/bind`にあるファイルをchroot環境にコピーします。コピー先は`/chroot/named/etc/`です。

### 2-1. `/chroot/named/etc/`にディレクトリの作成

`/chroot/named/etc/`以下にコピー元のファイルを格納するためのディレクトリを作成します。（管理や可読性のためにディレクトリを分割しますが、必須ではありません）

```bash
$ sudo mkdir -p /chroot/named/etc/{conf,default-zones,external-zones,internal-zones,keys}
```

### 2-2. `/etc/bind/`からファイルをコピーする

デフォルトで作成された`/etc/bind`内のファイルをchroot環境内に用意します。※今回は`/etc/bind/`からファイルをコピーしますが、ファイルをコピーするか、移動させるかなどは要件や目的によって異なります。

```bash
$ sudo cp /etc/bind/named.conf /chroot/named/etc/ && \
sudo cp /etc/bind/zones.rfc1918 /chroot/named/etc/ && \
sudo cp /etc/bind/246.255.10.db /chroot/named/etc/external-zones/ && \
sudo cp /etc/bind/bind.keys /chroot/named/etc/keys/ && \
sudo cp /etc/bind/db.{0,127,255,empty,local} /chroot/named/etc/default-zones/ && \
sudo cp /etc/bind/dns.com /chroot/named/etc/internal-zones/ && \
sudo cp /etc/bind/named.conf.default-zones /chroot/named/etc/default-zones/ && \
sudo cp /etc/bind/named.conf.external-zones /chroot/named/etc/external-zones/ && \
sudo cp /etc/bind/named.conf.internal-zones /chroot/named/etc/internal-zones/ && \
sudo cp /etc/bind/named.conf.{local,options} /chroot/named/etc/conf/ && \
sudo cp /etc/bind/rndc.key /chroot/named/etc/keys/
```

### 2-3. `root.hints`をコピーする

`root.hints`は、DNSにおいて**ルートDNSサーバーの情報を格納**するファイルです。今回のような内部ネットワーク内での名前解決では不要ですが、インターネット上で名前解決が必要な場合に必要になります。

今回は`root.hints`を参照する形で設定します。`root.hints`ファイルは、通常のシステムのファイルパスと同様にchroot環境内にディレクトリを用意し、そのディレクトリに`root.hints`をコピーします。

```bash
# 1. ディレクトリの作成
$ sudo mkdir -p /chroot/named/usr/share/dns/

# 2. root.hintsをコピーする
$ sudo cp /usr/share/dns/root.hints /chroot/named/usr/share/dns/root.hints
```

### 2-4. ファイルコピー後の構造の確認

ファイルコピー後のchroot環境内の構造は以下になります。

```bash
chroot
└── named
		├── dev
		├── etc
		│   ├── conf
		│   │   ├── named.conf.local
		│   │   └── named.conf.options
		│   ├── default-zones
		│   │   ├── db.0
		│   │   ├── db.127
		│   │   ├── db.255
		│   │   ├── db.empty
		│   │   ├── db.local
		│   │   └── named.conf.default-zones
		│   ├── external-zones
		│   │   ├── 246.255.10.db
		│   │   └── named.conf.external-zones
		│   ├── internal-zones
		│   │   ├── dns.com
		│   │   └── named.conf.internal-zones
		│   ├── keys
		│   │   ├── bind.keys
		│   │   └── rndc.key
		│   ├── named.conf
		│   └── zones.rfc1918
		├── run
		├── usr
		│   └── share
		│       └── dns
		│           └── root.hints
		└── var
```

## 3. confファイルの読み込み先の変更

コピーしてきたファイルはchroot環境外の`/etc/bind`内のファイルを参照しているため、chroot環境内のファイルを参照するように読み込み先を変更する必要があります。

なお、今回作成したchroot環境のルートは`/chroot/named`になります。includeディレクティブで指定する読み込み先のファイルパスは`/chroot/named`をルートとした絶対パスで指定します。

### 3-1. `named.conf`

`named.conf`は前回同様includeのみを定義します。

```bash
$ sudo vim /chroot/named/etc/named.conf

// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local

// BIND設定オプションファイル
include "/etc/conf/named.conf.options";
// BINDゾーン情報ファイル
include "/etc/internal-zones/named.conf.internal-zones";
include "/etc/external-zones/named.conf.external-zones";
```

### 3-2. `named.conf.options`

chroot環境は隔離されたシステムとなるため、デフォルトでは指定不要だった部分を明示的に指定する必要があります。

```bash
$ sudo vim /chroot/named/etc/conf/named.conf.options

acl public-subnet {
        10.255.240.0/21;
};

options {
        // 1. 以下を変更
        directory "/var/cache/";

        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.

        forwarders {
                8.8.8.8;   // Google Public DNS
                8.8.4.4;   // Google Public DNSの別のアドレス
        };

				allow-query {
			                localhost;
			                public-subnet;
			        };

        recursion no;

        //========================================================================
        // If BIND logs error messages about the root key being expired,
        // you will need to update your keys.  See https://www.isc.org/bind-keys
        //========================================================================
        dnssec-validation auto;
	
				// 2.
				key-directory "/etc/keys";
				// 3.
				pid-file "/run/named/named.pid";
				// 4.
				session-keyfile "/run/named/session.key";

        listen-on-v6 { none; };

				version "I won't tell you my version.";
};
```

今回`named.conf.options`に追記した内容は4つです。

| 記載した内容 | 説明 |
| --- | --- |
| directory "/var/cache/"; | BINDが一時的なデータやキャッシュデータを格納するディレクトリを指定する |
| key-directory "/etc/keys"; | bind.keysが格納されているディレクトリを指定する |
| pid-file "/run/named/named.pid"; | namedサービスのプロセスIDを保存するファイルを指定する |
| session-keyfile "/run/named/session.key"; | ダイナミック（動的）DNSの認証キーを保存するファイルを指定する |

キャッシュデータや`named.pid`, `session.key`に関してはBINDが自動でファイルを生成します。これらを生成するためにはディレクトリを用意しておく必要があります。

以下のコマンドで必要なディレクトリを作成します。

```bash
$ sudo mkdir /chroot/named/var/cache /chroot/named/run/named
```

### 3-3. `named.conf.default-zones`

`root.hints`に関してはchroot環境内にデフォルトと同様のファイルパスで作成しているので変更は不要です。他`db.*`のファイル4つに関しては以下のように変更してください。

```bash
$ sudo vim /chroot/named/etc/default-zones/named.conf.default-zones

// prime the server with knowledge of the root servers
zone "." {
        type hint;
        file "/usr/share/dns/root.hints";
};

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912

// 以下を変更
zone "localhost" {
        type master;
        file "/etc/default-zones/db.local";
};

// 以下を変更
zone "127.in-addr.arpa" {
        type master;
        file "/etc/default-zones/db.127";
};

// 以下を変更
zone "0.in-addr.arpa" {
        type master;
        file "/etc/default-zones/db.0";
};

// 以下を変更
zone "255.in-addr.arpa" {
        type master;
        file "/etc/default-zones/db.255";
};
```

### 3-4. `named.conf.internal-zones`

デフォルトゾーンファイルまでのファイルパスを変更します。

```bash
$ sudo vim /chroot/named/etc/internal-zones/named.conf.internal-zones

// 以下を変更
include "/etc/default-zones/named.conf.default-zones";
```

### 3-5. `named.conf.external-zones`

正引き、逆引きゾーンファイルまでのファイルパスを変更します。

```bash
$ sudo vim /chroot/named/etc/external-zones/named.conf.external-zones

# 正引きゾーンファイル
# 以下を変更
zone "dns.com" {
    type master;
    file "/etc/internal-zones/dns.com";
    allow-update { none; };
};

# 逆引きゾーンファイル
# 以下を変更
zone "246.255.10.in-addr.arpa" {
    type master;
    file "/etc/external-zones/246.255.10.db";
    allow-update { none; };
};
```

## 4. デバイスファイルの作成

デバイスファイルを作成する際には、デバイスタイプ、メジャーナンバー、マイナーナンバーを指定します。それぞれの属性について以下の表にまとめました。

| 属性 | 説明 |
| --- | --- |
| デバイスタイプ | データの取り扱い方を示す。キャラクタデバイスはデータを1バイトずつ順番に処理し、ブロックデバイスは大きなデータブロックを一度に処理する。 |
| メジャーナンバー | デバイスの「大まかな」種類を示す番号。例: ハードディスクやCD-ROMなどのストレージデバイスは同じメジャーナンバーを共有することが多い。 |
| マイナーナンバー | 同じ種類のデバイスの中で、具体的なデバイスや機能を区別する番号。例: ハードディスクが複数ある場合、それぞれ異なるマイナーナンバーを持つ。 |

以下のコマンドで、デバイスファイルを作成します。

```bash
$ sudo mknod /chroot/named/dev/null c 1 3
$ sudo mknod /chroot/named/dev/random c 1 8
$ sudo mknod /chroot/named/dev/urandom c 1 9
```

これらのデバイスファイルはセキュリティや通信プロトコルの実装など、さまざまな目的で使用されます。特に、`/dev/null`はデータの捨て場としてよく使われ、`/dev/random`および`/dev/urandom`はセキュアなランダムデータの生成に利用されます。

## 5. chroot環境を隔離する

chroot環境の隔離が一番重要です。所有者や権限を適切に設定する必要があります。chroot環境の隔離は以下の図のように行います。

![chroot_handson_02.png](https://storage.googleapis.com/envader-article-images/bind-chroot-first-half/chroot_handson_02.png)

### 5-1. `/chroot`ディレクトリの設定

まず初めに、**chroot環境から外部へのアクセスを制限**します。以下のコマンドを実行します。

```bash
# /chrootはユーザとグループをrootに設定する
$ sudo chown root:root /chroot
$ sudo chmod 700 /chroot
```

### 5-2. `/chroot/named`ディレクトリの設定

次に、**外部からchroot環境へのアクセスを制限**します。以下のコマンドを実行します。

```bash
# /chroot/namedはユーザとグループをbindに設定する
$ sudo chown -R bind:bind /chroot/named/
$ sudo chmod 700 /chroot/named
```

ここまでの設定で、chroot環境を隔離することができました。chroot環境の隔離を行うと、デフォルトのユーザ（ubuntu）でのchroot環境内へのアクセスやファイル参照などが行えなくなりますので、`sudo`または`sudo su`で実行する必要があります。

## まとめ

今回はchroot環境の構築手順の前編を紹介しました。前編の中でのchroot環境の構築における大事な部分は「**chroot環境の隔離**」です。chroot環境の構築後にBINDがchroot環境内のファイルを適切に参照するために明示的に各種ファイルパスを指定する必要があります。

続きは後編で紹介します。後編に関しては以下の記事をご参照ください。

https://envader.plus/article/230

こちらの記事では、BINDを利用したDNSサーバーにchroot環境を構築する手順をハンズオン形式でご紹介します。

【BIND高度実践】chroot環境を構築してみよう【前編】

# 【BIND高度実践】chroot環境を構築してみよう【後編】

![chroot_handson_01.png](https://storage.googleapis.com/envader-article-images/bind-chroot-second-half/chroot_handson_01.png)

こちらの記事は、chroot環境の構築（ハンズオン）の後編です。前編は以下の記事で紹介しています。

https://envader.plus/article/229

また、chroot環境の構築に関する解説は以下の記事で紹介しています。不明点がある場合は、その記事を参照しながら本ハンズオンを進めてください。

https://envader.plus/article/228

## 本記事で行うchroot環境の構築手順

本記事では以下の手順でchroot環境の構築を行います。

1. chroot環境内に適切な権限を設定する
2. named.serviceの変更
3. AppArmorのポリシーの変更
4. 変更の反映
5. named（BIND）の稼働状態の確認
6. DNSリクエストのテスト

## 1. chroot環境内に適切な権限を設定する

chroot環境内の各ディレクトリ・ファイルには、その役割や機能に応じて適切な権限を設定する必要があります。また、前回の権限変更によって**ubuntuユーザーの各種実行権限が足りなくなります**。もし実行権限が不足した場合は`sudo`、または`sudo su`で実行してください。

### 1-1. `/chroot/named`以下のディレクトリの設定

以下のコマンドを実行します。

```bash
# /chroot/named 以下のすべてのディレクトリの権限を 755 に設定
$ sudo find /chroot/named -type d -exec chmod 755 {} \;
```

上記の権限設定の詳細は以下の通りです。

- 所有者
    
    ディレクトリ内のファイルやサブディレクトリを管理するために、chroot環境内のプロセスがディレクトリにフルアクセスを持つことが必要です。所有者に読み取り、書き込み、実行権限を与えることで、ディレクトリ内での作業が可能になります。
    
- グループ
    
    グループに読み取りと実行権限を与えることで、特定のプロセスグループ内のユーザーがディレクトリ内のファイルやサブディレクトリにアクセスできるようになります。書き込み権限は不要なため、セキュリティを維持しながらアクセスを許可できます。
    
- その他ユーザー
    
    その他のユーザーに読み取りと実行権限を与えることで、chroot環境内の他のプロセスがディレクトリ内のファイルやサブディレクトリにアクセスできるようになります。書き込み権限は不要ですが、読み取りと実行権限は必要です。
    

755の権限は、セキュリティとアクセス制御のバランスをとった設定であり、chroot環境内で必要な操作を実行できるようにする一方で、不必要な書き込み権限を制限して安全性を確保します。

### 1-2. `/chroot/named`以下のファイルの設定

以下のコマンドを実行します。

```bash
# /chroot/named 以下のすべてのファイルの権限を 644 に設定
$ sudo find /chroot/named -type f -exec chmod 644 {} \;
```

上記の権限設定の詳細は以下の通りです。

- 所有者
    
    ファイルを読み取り、必要に応じて変更できるため、chroot環境内のプロセスがファイルを操作するのに必要です。
    
- グループ
    
    ファイルを所属グループ内のプロセスが読み取れるようにするため、他のプロセスにも一部のアクセス権を付与しますが、書き込みは制限されています。
    
- その他ユーザー
    
    chroot環境内の他のユーザーがファイルを読み取れるようにするため、一般的な読み取りアクセス権が与えられています。
    

644の権限は、ファイルのセキュリティを維持しつつ、必要なプロセスがファイルを読み取り、必要な情報を取得できるようにする効果的な方法です。同時に、不必要な書き込みアクセスを制限し、データの完全性を保護します。

### 1-3. デバイスファイルの設定

以下のコマンドを実行します。

```bash
# 全てのユーザーの読み書きを許可
$ sudo chmod 666 /chroot/named/dev/{null,random,urandom}
```

これらのデバイスファイルは全てのユーザーに対して読み取りと書き込みの権限を許可します。

- `/dev/null`
    
    `/dev/null`は、書き込み操作を行なっても何も記録されず、読み取り操作は常に空のデータを返します。つまり、このデバイスにデータを書き込むことは、データを破棄することと同義です。`/dev/null`の主な利用目的である、データの破棄と空のデータの返却のために読み取りと書き込みを許可します。
    
- `/dev/random`および`/dev/urandom`
    
    `/dev/random`および`/dev/urandom`は、ランダムなデータを生成するために使用されます。読み取り操作によってランダムなデータの取得を行い、書き込み操作によって特定のランダムデータをデバイスに供給することができます。
    

デバイスファイルに読み取りと書き込みの権限を設定することで、chroot環境内のプロセスがこれらのデバイスにアクセスでき、必要なデータの読み取り、書き込みができるようになります。特にセキュリティ関連の操作やランダムなデータの生成など、さまざまな用途でこれらのデバイスファイルへのアクセスが必要とされる場合があるため、666の権限を設定します。

### 1-4. `/chroot/named/var/cache`の設定

以下のコマンドを実行します。

```bash
# ユーザー・グループのみ読み書き実行を許可
$ sudo chmod 770 /chroot/named/var/cache
```

上記の権限設定の詳細は以下の通りです。

- 所有者
    
    BINDの実行プロセスは、一般的に非特権ユーザー、ubuntuであればbindとして動作します。ディレクトリにキャッシュデータや一時的なデータを生成、更新、削除するため、読み書きおよび実行の権限が必要です。
    
- グループ
    
    特定の環境や設定では同じグループのメンバーがBINDのプロセスと協力して操作を行うことがあります。また、BINDを運用をサポートするためのツールやスクリプトが存在する場合、それらを実行するユーザーもグループの権限を使ってキャッシュデータにアクセスできるようにすることが考えられます。そのため、所有者同様に全ての権限を付与します。
    
- その他のユーザ
    
    一切のアクセスの権限を与えません。
    

**770**の権限は、指定されたユーザーとグループのみにフルアクセスを許可し、それ以外のユーザーからのアクセスを完全に制限することで、セキュリティを強化します。

### 1-5. `/chroot/named/run/named`の設定

以下のコマンドを実行します。

```bash
# ユーザー・グループのみ読み書き実行を許可
$ sudo chmod 770 /chroot/named/run/named
```

こちらもキャッシュディレクトリと同様の理由から770の権限に設定します。

### 1-6. `keys`ディレクトリ内のファイルの設定

以下のコマンドを実行します。

```bash
# ユーザのみ読み書きを許可
$ sudo chmod 600 /chroot/named/etc/keys/*
```

`keys`ディレクトリ内のファイルには600の権限を付与し、BINDのプロセスによってのみ読み書きを行うことを許可します。

`keys`ディレクトリはBINDのキーファイルを保存するディレクトリです。ここに格納するキーファイルは、DNSのゾーン転送や更新などのセキュアな操作を行うために使用される暗号鍵を含む可能性があります。これらのキーが第三者に漏洩すると、DNSサービスが不正に操作されるリスクがあるため、ファイルへのアクセスは厳格に制限される必要があります。

## 2. named.serviceの変更

`/etc/default/named`を変更し、namedがchroot環境のファイルを読み込むように設定します。

```bash
$ sudo vim /etc/default/named

#
# run resolvconf?
RESOLVCONF=no

# startup options for the server
# 以下を変更 -4は任意（IPv4を使用）
OPTIONS="-4 -u bind -t /chroot/named -c /etc/named.conf"
```

上記の設定した内容を以下にまとめました。

| 引数 | 意味 |
| --- | --- |
| -4 | IPv4モードで動作（IPv6は無効化） |
| -u bind | bindユーザーとして実行 |
| -t /chroot/named | bindが動作するルートディレクトリを変更 |
| -c /etc/named.conf | chroot環境内のnamed.confの場所を指定 |

## 3. AppArmorのポリシーの変更

`/chroot/named`以下の全てのファイルは読み取り専用、`/chroot/named/var/cache`、`/chroot/named/run/named/`以下の全てのファイルは読み書き可能と定義します。

`File Access Permissions`ポリシー内に、以下の内容を追加します。

```bash
$ sudo vim /etc/apparmor.d/usr.sbin.named

# vim:syntax=apparmor
# Last Modified: Fri Jun  1 16:43:22 2007
#include <tunables/global>

/usr/sbin/named flags=(attach_disconnected) {
  #include <abstractions/base>
  #include <abstractions/nameservice>

  capability net_bind_service,
  capability setgid,
  capability setuid,
  capability sys_chroot,
  capability sys_resource,

  # /etc/bind should be read-only for bind
  # /var/lib/bind is for dynamically updated zone (and journal) files.
  # /var/cache/bind is for slave/stub data, since we're not the origin of it.
  # See /usr/share/doc/bind9/README.Debian.gz
  /etc/bind/** r,
  /var/lib/bind/** rw,
  /var/lib/bind/ rw,
  /var/cache/bind/** lrw,
  /var/cache/bind/ rw,

  # 以下を追加
  /chroot/named/** r,
  /chroot/named/var/cache/** rw,
	/chroot/named/run/named/** rw,

  ...
}
```

## 4. 変更の反映

1. AppArmorの設定の反映
    
    ```bash
    $ sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.named
    ```
    
2. `named.service`の設定の反映
    
    ユニットファイルであるnamed.serviceを変更したため、最初に以下のコマンドで新しい設定をsystemdに反映させます。
    
    ```bash
    $ sudo systemctl daemon-reload
    ```
    
3. `named`の設定の反映
    
    ```bash
    $ sudo systemctl restart named
    ```
    

## 5. namedの稼働状態の確認

### `named`の稼働状態を確認します。
    
```bash
$ sudo systemctl status named

● named.service - BIND Domain Name Server
        Loaded: loaded (/lib/systemd/system/named.service; enabled; vendor preset: enabled)
        Active: active (running) since Thu 2023-09-14 04:00:58 UTC; 16s ago
        Docs: man:named(8)
    Main PID: 17812 (named)
        Tasks: 5 (limit: 1126)
        Memory: 10.8M
        CGroup: /system.slice/named.service
                └─17812 /usr/sbin/named -f -4 -u bind -t /chroot/named -c /etc/named.conf

Sep 14 04:00:58 ip-10-255-242-121 named[17812]: zone 0.in-addr.arpa/IN: loaded serial 1
Sep 14 04:00:58 ip-10-255-242-121 named[17812]: zone 242.255.10.in-addr.arpa/IN: loaded serial 2023070301
Sep 14 04:00:58 ip-10-255-242-121 named[17812]: zone 127.in-addr.arpa/IN: loaded serial 1
Sep 14 04:00:58 ip-10-255-242-121 named[17812]: zone 255.in-addr.arpa/IN: loaded serial 1
Sep 14 04:00:58 ip-10-255-242-121 named[17812]: zone dns.com/IN: loaded serial 2023070301
Sep 14 04:00:58 ip-10-255-242-121 named[17812]: zone localhost/IN: loaded serial 2
Sep 14 04:00:58 ip-10-255-242-121 named[17812]: all zones loaded
Sep 14 04:00:58 ip-10-255-242-121 named[17812]: running
Sep 14 04:00:58 ip-10-255-242-121 named[17812]: managed-keys-zone: Key 20326 for zone . is now trusted (acceptance timer complete)
Sep 14 04:00:59 ip-10-255-242-121 named[17812]: resolver priming query complete
```

稼働状態（Active）が`active（running）`であることを確認します。また、**CGroup**（**C**ontrol **Group**）セクションで`/usr/sbin/named -f -4 -u bind -t /chroot/named -c /etc/named.conf`となっていることから、`named`がchroot環境で稼働していることが分かります。
    

## 6. DNSリクエストのテスト

正引きテスト・逆引きテストを行い、名前解決が行えるか確認します。

### 正引きテスト

```bash
$ sudo dig bind.dns.com A

; <<>> DiG 9.16.1-Ubuntu <<>> bind.dns.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31816
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;bind.dns.com.			IN	A

;; ANSWER SECTION:
bind.dns.com.		6538	IN	A	10.255.246.216

;; Query time: 4 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Sep 14 04:54:13 UTC 2023
;; MSG SIZE  rcvd: 57
```

`ANSWER SECTION:`で、`bind.dns.com`のIPv4アドレスは`10.255.246.216`と返っていることから、正しく解決されていることが分かります。
    
### 逆引きテスト

```bash
$ sudo dig @bind.dns.com -x 10.255.246.216

; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48565
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 34fe5ab55a8b186c010000006502928e8c1bc11735412193 (good)
;; QUESTION SECTION:
;10.255.246.216.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
216.246.255.10.in-addr.arpa. 86400 IN	PTR	bind.dns.com.

;; Query time: 0 msec
;; SERVER: 10.255.246.216#53(10.255.246.216)
;; WHEN: Thu Sep 14 04:56:46 UTC 2023
;; MSG SIZE  rcvd: 110
```

`ANSWER SECTION:`で、`10.255.246.216`のドメインは`bind.dns.com`と返っていることから、正しく解決されていることが分かります。
    
## まとめ

この後編では、BINDにおけるchroot環境の続きを実践し、DNSリクエストのテストまで行い、chroot環境で問題なくBINDが動作しているかの確認まで行いました。後編の中でのchroot環境の構築における大事な部分は「**chroot環境内に適切な権限を設定すること**」です。これは、セキュリティの強化、データの保護、システムの安定性を確保するために不可欠です。

chroot環境を適切に構築することで、DNSサーバーのセキュリティを向上させることができます。また、各手順や設定の背後にある理由を理解することで、より効果的な運用が可能となります。不明点や詳細な情報が必要な場合は、関連する解説記事もご参照ください。

こちらの記事は、chroot環境の構築（ハンズオン）の後編です。

【BIND高度実践】chroot環境を構築してみよう【後編】

# Git初心者必見！「git reset」と「git revert」の使い分け方

![https://storage.googleapis.com/envader-article-images/git-reset-git-revert/001.png](https://storage.googleapis.com/envader-article-images/git-reset-git-revert/001.png)

## この記事の目的

この記事の主な目的は「git reset （ギット リセット）」と「git revert（ギット リバート）」の基本的な使い方と、それぞれの適切な使用シチュエーションを理解してもらうことです。エンジニア初心者や、これからGitを学び始める方を主なターゲットとしていますので、専門的な用語はできるだけ避け、わかりやすい言葉で説明していきます。

## Gitの基本概念のおさらい

ここでは、Gitの中心的な概念である「コミット」や「リポジトリ」と「ワークツリー」の関係について、簡単におさらいします。

### コミットとは

コミットは、Gitにおける変更履歴の一つの単位として考えることができます。ファイルやディレクトリのある時点でのスナップショットを指し、コミットを行うことでその時点での変更内容や変更した人、変更日時などの情報が記録されます。

#### コミットID

それぞれのコミットには一意のIDが割り当てられており、これを用いて特定のコミットを参照することができます。

#### 親コミット

前のコミットを指し、変更履歴を辿ることができます。

### リポジトリとワークツリーの関係

「リポジトリ」と「ワークツリー」は、Gitの操作を行う上で非常に重要な概念です。

#### リポジトリ

Gitによって管理されているプロジェクトのデータや変更履歴が保存されている場所を指します。リポジトリには、コミットされたデータやブランチ情報、タグなどが含まれています。

#### ワークツリー

リポジトリの最新のコミットの内容が展開されているディレクトリを指します。実際にファイルの編集や追加、削除を行う場所です。

リポジトリとワークツリーの間でのデータの移動や同期を行うために、`git add`や`git commit`などのコマンドを使用します。ワークツリーでの変更をリポジトリに保存することで、変更履歴を確実に記録することができます。

## 「git reset」の解説

git resetは、Gitで非常に強力なコマンドの一つとして知られています。このコマンドを使うことで、特定のコミットに戻ったり、ステージングエリアの変更を取り消すことができます。しかし、その強力さゆえに、誤った使い方をすると大きなトラブルを引き起こす可能性もあります。そこで、このセクションではgit resetの正しい使い方と、それぞれのオプションの違いについて解説します。

### 「git reset」コマンドの基本的な説明

git resetは、主に以下の3つの目的で使用されます。

- ステージングエリアの変更を取り消す
- あるコミットに戻る
- 過去のコミットを完全に削除する

### 「git reset」主なオプションの解説

git resetにはいくつかのオプションがありますが、ここでは最も一般的に使用される`--soft`、`--mixed`、`--hard`の3つのオプションに焦点を当てて解説します。

| オプション  | 説明                                                                                              |
|------------|---------------------------------------------------------------------------------------------------|
| `--soft`   | 指定したコミットにHEADを移動させる。ワークツリーとステージングエリアの変更はそのまま保持 |
| `--mixed`  | (デフォルトのオプション) 指定したコミットにHEADを移動させ、ステージングエリアの変更を取り消す。ワークツリーの変更はそのまま保持 |
| `--hard`   | 指定したコミットにHEADを移動させ、ステージングエリアとワークツリーの両方の変更を取り消す     |

### 「git reset」使用シチュエーションとメリット・デメリット

| オプション  | 使用シチュエーション                                                                                                        | メリット                                               | デメリット                                                                 |
|------------|-----------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------|----------------------------------------------------------------------------|
| `--soft`   | 過去のコミットに戻りつつ、その後の変更を新しいコミットとしてまとめ直したい場合に使用                                     | 変更履歴を綺麗にまとめることができる                 | 誤操作のリスクがある。                                                    |
| `--mixed`  | 過去のコミットに戻りつつ、ワークツリーの変更はそのままにして、再度ステージングしたい場合に使用                             | ステージングのミスを修正するのに便利                | 初心者にはやや複雑に感じるかもしれない                                  |
| `--hard`   | 過去のコミットに完全に戻りたい場合、または最近のコミットを完全に取り消したい場合に使用                                  | コミットのミスを完全に修正するのに有効              | 使用する際は慎重に。一度取り消した変更は元に戻せない場合がある          |

## 「git revert」の解説

`git revert`は、Gitで行った変更を取り消すためのコマンドですが、`git reset`とは異なり、変更を取り消すための新しいコミットを生成する点が特徴です。このセクションでは、`git revert`の基本的な使い方やその特性、使用シチュエーションについて詳しく解説します。

### 「git revert」コマンドの基本的な説明

`git revert`コマンドは、特定のコミットの変更を取り消す新しいコミットを作成します。これにより、過去のコミットを取り消すことができる一方で、その取り消し自体の履歴も残るため、変更履歴を維持することができます。

### revertが生成する新しいコミットについて

`git revert`を実行すると、指定したコミットの変更を取り消す内容を持つ新しいコミットが生成されます。この新しいコミットには、取り消された変更に関する情報や、`revert`コマンドを実行したユーザーの情報、日時などが記録されます。

### 「git revert」使用シチュエーションとメリット・デメリット

| 項目           | 説明                                                                                           |
|----------------|------------------------------------------------------------------------------------------------|
| 使用シチュエーション | 過去の特定のコミットの変更を取り消したいが、その取り消し自体の履歴も残したい場合に使用    |
| メリット       | 1. 過去の変更を取り消しつつ、変更履歴を維持できる。<br>2. 誤ったコミットを公開した後でも、そのコミットを取り消すことが可能 |
| デメリット     | 1. 新しいコミットが生成されるため、コミット履歴が増える。<br>2. 大きな変更を取り消す場合、コンフリクトが発生する可能性がある |

コミット内容やコメントを整理する際にも使用されます。squashについてはこちらの記事で詳しく解説しています。

https://envader.plus/article/268

## 「git reset」と「git revert」の主な使い分け

![https://storage.googleapis.com/envader-article-images/git-reset-git-revert/002.png](https://storage.googleapis.com/envader-article-images/git-reset-git-revert/002.png)

`git reset`と`git revert`はGitで行った変更を取り消すためのコマンドですが、それぞれ異なるシチュエーションでの使用が推奨されています。ここではそれぞれのコマンドが適しているシチュエーションの例と、実務でのベストプラクティスについて解説します。

### それぞれのコマンドが適しているシチュエーション

#### git reset

- ローカルの履歴を修正したい場合: 例えば、コミットメッセージのミスを修正する、または特定の変更を含めたり除外したりする場合等
- リモートにプッシュしていないコミットを取り消したい場合: プッシュする前に間違ったコミットをしてしまった場合等

#### git revert

- リモートにプッシュしたコミットを安全に取り消したい場合: 他の人と共同で作業しているときや、公開リポジトリでの作業時等
- 取り消し自体の履歴も残したい場合: 何が変更されたのか、どの変更が取り消されたのかの履歴を残しておきたい場合

### 実務でのベストプラクティス

#### リモートにプッシュしたコミットはgit resetで取り消さない

他の開発者との履歴の不整合を避けることができます。リモートのコミットを取り消す場合は、`git revert`を使用してください。

#### 変更の取り消しは早めに行う

長い時間が経過してから変更を取り消すと、コンフリクトが発生する可能性が高まります。

#### コマンドの使用前には必ず現在のブランチやステータスを確認する

誤ったブランチやコミットで操作を行わないように注意してください。

## 実践編: よくあるシチュエーションでの対処法

日常の開発作業中、Gitを使用していると様々なシチュエーションに直面することがあります。ここでは、よくあるシチュエーションとその対処法を具体的に解説します。

### 間違ったコミットをした場合

#### 対処法

1. まだリモートにプッシュしていない場合は、`git reset`を使用して直前のコミットを取り消すことができます。
   ```bash
   git reset HEAD~1
   ```
2. リモートにプッシュしてしまった場合は、`git revert`を使用して新しいコミットを生成し、間違ったコミットを取り消します。
   ```bash
   git revert [コミットのハッシュ]
   ```

### 過去のコミットに戻りたい場合

#### 対処法

1. 一時的に過去のコミットを確認したいだけの場合は、以下のコマンドで過去のコミットにチェックアウトできます。
   ```bash
   git checkout [コミットのハッシュ]
   ```
2. 完全に過去のコミットに戻り、それ以降のコミットを取り消したい場合は、`git reset`を使用します。
   ```bash
   git reset --hard [コミットのハッシュ]
   ```

### 公開リポジトリでの誤操作の修正方法

#### 対処法

1. 公開リポジトリで誤ったコミットをプッシュしてしまった場合、`git revert`を使用してそのコミットを取り消すのがベストプラクティスです。
   ```bash
   git revert [コミットのハッシュ]
   ```
2. 取り消したいコミットが連続している場合は、範囲を指定して`git revert`を実行することができます。
   ```bash
   git revert [古いコミットのハッシュ]..[新しいコミットのハッシュ]
   ```

これらの方法でGitでの作業中に発生する様々な問題を効果的に解決することができます。適切なコマンドを選択し、安全な操作を心がけましょう。

## まとめと次のステップ

本記事ではGitの基本的な操作である`git reset`と`git revert`の使い方と使い分けについて詳しく解説しました。これらのコマンドは日常の開発作業で発生する様々な問題を解決するための強力なツールです。

Gitはソフトウェア開発における変更履歴の管理やチームでの協力を効率的に行うためのツールです。適切なコマンドの選択と使用方法を理解することで、開発の効率化やチームワークの向上に大きく貢献します。特にエラーや誤操作から迅速に回復する能力は、開発者としての信頼性や生産性を向上させる重要な要素となるため確実にマスターしたい所です。

### さらなる学習のためのリソースや参考文献の紹介

Gitの学習は基本的なコマンドの理解から始まりますが、深く探求することでさらなる知識やスキルを獲得できます。以下はGitに関する学習のためのおすすめのリソースや参考文献です。

- [Pro Git](https://git-scm.com/book/en/v2): Gitの公式ドキュメントで、初心者から上級者までの内容が詳しく解説されています。
- [サル先生のGit入門](https://backlog.com/ja/git-tutorial/): タスク管理ツールBacklogによるGitの日本語解説です。
- [GitHub Learning Lab](https://lab.github.com/): 実践的なハンズオン形式でGitやGitHubの操作を学ぶことができるリソースです。
- [Git Magic](http://www-cs-students.stanford.edu/~blynn/gitmagic/): Gitの内部構造や高度な操作に関する詳細なガイドブックです。

Gitを活用して、効率的かつ安全な開発を行いましょう。「慣れ」も大事ですので自信がつくまでコマンドを練習するといいかもしれません。


この記事の主な目的は「git reset （ギット リセット）」と「git revert（ギット リバート）」の基本的な使い方と、それぞれの適切な使用シチュエーションを理解してもらうことです。

Git初心者必見！「git reset」と「git revert」の使い分け方

# Gitの作業効率化！git stash と git diff の使い方を解説

![https://storage.googleapis.com/envader-article-images/git-stash-git-diff/001.png](https://storage.googleapis.com/envader-article-images/git-stash-git-diff/001.png)

## まずはGitのおさらい

Gitは、ソフトウェア開発におけるバージョン管理システムです。ソースコードの変更履歴を記録し、簡単に過去の状態に戻したり、複数の開発者で同じコードを共有したりすることができます。

Gitは、ソフトウェア開発の効率化や品質向上に欠かせないツールです。エンジニアとしてGitを使いこなすことで、より生産的で質の高いソフトウェアを開発することができます。

具体的には、以下のようなメリットがあります。

- 変更の追跡: いつ、誰が、どのような変更を行ったのかを一目で確認できます。
- バージョンの管理: プロジェクトの特定の時点の状態を保存し、必要に応じてそこに戻ることができます。
- チームでの共同作業: 複数人での同時作業でも、それぞれの変更を統合し、コンフリクトを解消する手助けをしてくれます。

GitについてはエンベーダーのLinux応用コースで詳しく学ぶことができます。

https://envader.plus/course/5/scenario/1055

## git stashとgit diff　コマンドの紹介

Gitを効果的に使用するためには、いくつかの基本的なコマンドを理解することが不可欠です。ここでは表題の`git diff`, `git stash` に加え、`git status`という3つの重要なコマンドをそれぞれの使い方や役割、利点について解説します。

### 「git status」変更の現状を確認する

#### 使い方

```bash
git status
```

`git status` コマンドは現在のリポジトリの状態を確認するためのコマンドです。変更されたファイル、ステージされていない変更、ステージされた変更などの情報を一覧できます。

#### 役割と利点

* ワークツリーとインデックスの状態を表示することで、次の操作を明確にする助けとなります。
* どのファイルが変更され、どのファイルがまだコミットされていないのかを素早く確認することができます。

#### 出力内容の詳細

`git status` コマンドの出力には、以下の情報が含まれます。

* 変更されたファイル: ワークツリーで変更されたファイルの一覧
* ステージされていない変更: ワークツリーで変更されたファイルのうち、まだステージされていない変更
* ステージされた変更: ワークツリーで変更されたファイルのうち、ステージされた変更
* ワークツリーとインデックスの差分: ワークツリーとインデックスの差分を表示

#### コマンド使用例

```bash
$ git status
# On branch main
# Changes to be committed:
# (use "git add <file>..." to update what will be committed)
#
# new file:   README.md
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# .gitignore

```

この例では、`README.md` ファイルが新しく作成されており、`.gitignore` ファイルは追跡されていない状態です。

### 「git diff」変更内容を詳しく見る

#### 使い方

```bash
git diff
```

`git diff` コマンドは、変更された内容の差分を表示するコマンドです。これにより、具体的にどの行がどのように変更されたのかを確認することができます。

#### 「git diff」オプション

* `--staged`: ステージされた変更の差分を表示
* `--unstaged`: ワークツリー上の変更の差分を表示
* `--cached`: コミット済みの内容とステージされた変更の差分を表示
* `--color`: 差分を色分けして表示

他にも多くのオプションがあります。

https://git-scm.com/docs/git-diff

#### コマンド使用例

```bash
$ git diff
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/README.md
@@ -0,0 +1 @@
+This is a README file.
```

この例では、`README.md` ファイルが新しく作成されたため、差分は以下のようになります。

```bash
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/README.md
@@ -0,0 +1 @@
+This is a README file.
```

### 「git stash」作業を一時保存する

#### 使い方

```bash
git stash save "保存メッセージ"
```

`git stash` コマンドは現在の作業を一時的に保存し、クリーンな状態に戻すためのコマンドです。保存した作業を再度取り出して続けることができます。

#### オプション

* `--save`: 保存する作業にメッセージを指定
* `--keep-index`: ステージされた変更を保存
* `--include-untracked`: 追跡されていないファイルを保存

#### コマンド使用例

```
$ git stash save "WIP: ファイルの追加"
Saved working directory and index state "WIP: ファイルの追加"
```

この例では、WIP: ファイルの追加 というメッセージで作業を保存しています。

※WIPは、Work in Progressの略で、日本語では「作業中」という意味です。Gitでは作業中の変更を一時的に保存する際に、WIPというメッセージをよく使用します。

## 作業中の変更を確認する

![https://storage.googleapis.com/envader-article-images/git-stash-git-diff/002.png](https://storage.googleapis.com/envader-article-images/git-stash-git-diff/002.png)

プログラミングやドキュメントの編集中にどの部分を変更したのか、それがどのように現在のリポジトリに影響するのかを確認することは非常に重要です。これらの変更を確認するために、`git status` と `git diff` コマンドを用いて、作業中の変更内容を確認する方法を実例とともに解説します。

### 「git status」変更状態の確認

#### 使い方

`git status`コマンドを実行すると現在のリポジトリの状態が表示されます。

- 変更されたファイル
- ステージされていない変更
- ステージされた変更など

これらの情報が一覧されます。

#### 実際のコマンド使用例

例えば、`example.txt` というファイルを変更した後、`git status` を実行したとします。

```bash
$ git status

On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   example.txt
```

この出力から、`example.txt` が変更されているが、まだステージされていないことが分かります。

#### 出力内容の詳細

`git status` コマンドの出力には、以下の情報が含まれます。

| 項目 | 説明 |
|---|---|
| 変更されたファイル | ワークツリーで変更されたファイルの一覧 |
| ステージされていない変更 | 変更されたファイルのうち、まだステージされていない変更 |
| ステージされた変更 | 変更されたファイルのうち、ステージされた変更 |
| ワークツリーとインデックスの差分 | ワークツリーとインデックスの差分を表示します。この差分には、追加、削除、変更された行が含まれる |

これらの情報を理解することで、現在のリポジトリの状態をより正確に把握することができます。

### 「git diff」詳細な変更内容の確認

#### 使い方

`git diff`コマンドを使用すると変更された内容の差分が表示されます。変更前と変更後の行が色分けされて表示されるため、どの部分がどのように変更されたのかが一目瞭然となります。

#### 実際のコマンド使用例

先ほどの`example.txt`の変更内容を`git diff`で確認してみましょう。

```bash
$ git diff

diff --git a/example.txt b/example.txt
index e012d44..a987f3c 100644
--- a/example.txt
+++ b/example.txt
@@ -1,2 +1,2 @@
-This is an example file.
+This is a modified example file.
```

この出力から、`example.txt` の "This is an example file." という行が "This is a modified example file." に変更されたことが確認できます。

## 作業の中断と再開「git stash」の活用

![https://storage.googleapis.com/envader-article-images/git-stash-git-diff/003.png](https://storage.googleapis.com/envader-article-images/git-stash-git-diff/003.png)

開発中に別のタスクに取り組む必要が出てきたり、現在の作業を一時的に中断したい場面はよくあります。`git stash` はそうした場面での作業の一時保存と再開時に使用するコマンドです。

### なぜ変更を一時的に保存するのか

Git では変更をコミットするまで、ワークツリーとインデックスの状態は不安定な状態になります。別のタスクに取り組む場合や現在の作業を一時的に中断する場合は、変更を一時的に保存しておくことで、ワークツリーとインデックスを「変更されていない状態」に保つことができます。

### スタッシュの説明

スタッシュはワークツリーとインデックスの状態を保存する機能です。ワークツリーとは、ローカルにダウンロードされたファイルのことです。インデックスとは、コミットする前に保管されるファイルの状態のことです。

スタッシュを保存すると、ワークツリーとインデックスの変更が記録されます。スタッシュされた状態を適用すると、ワークツリーとインデックスの状態が適用したスタッシュから復元されます。

### スタッシュの基本的な使い方

スタッシュの基本的な使い方は、以下のとおりです。

#### 1. 保存 (`save`)

```bash
git stash save "任意のメッセージ"
```
このコマンドで、現在の変更を一時的に保存します。

#### 2. 一覧表示 (`list`)

```bash
git stash list
```
保存されたスタッシュの一覧を表示します。

#### 3. 適用 (`apply`)

```bash
git stash apply stash@{0}
```
最新のスタッシュを適用しますが、スタッシュからは削除されません。

#### 4. 適用と削除 (`pop`)

```bash
git stash pop
```
最新のスタッシュを適用し、同時にスタッシュからその変更を削除します。

#### 5. スタッシュの削除 (`drop`)
```bash
git stash drop stash@{0}
```
最新のスタッシュを削除します。

### 作業の確認

開発している最中に動作確認をしたい場合もあります。スタッシュにより現在の変更を一時的に退避させ、クリーンな状態（変更されていない状態）で動作確認を行うことができます。

1. 現在の作業をスタッシュに保存します。
   ```bash
   git stash save "新機能の開発中"
   ```

2. 動作確認を行います。

3. 動作確認が完了したら、スタッシュを適用します。
   ```bash
   git stash apply stash@{0}
   ```

### 実際の作業フロー中でのスタッシュの活用例

例えば新しい機能の開発を行っている最中に、バグ修正が必要になったとします。

1. まず、現在の作業をスタッシュに保存します。
   ```bash
   git stash save "新機能の開発中"
   ```

2. バグ修正のための新しいブランチを作成し、そのブランチに移動します。
   ```bash
   git checkout -b bugfix-branch
   ```

3. バグを修正し、コミットします。

4. メインブランチに戻り、先ほどの作業を再開します。
   ```bash
   git checkout main
   git stash pop
   ```

以上で緊急のタスクと通常の開発を効率的に行うことができます。

## 他のブランチやコミットへの移動

ここではブランチの基本的な概念、ブランチやコミット間での移動方法、そしてブランチ間の変更内容の比較方法について学習します。

### ブランチとは

ブランチとはプロジェクトの異なるバージョンや機能を同時に開発するための独立した作業スペースです。ブランチを使用することで、メインの開発ラインから独立して新しい機能の開発やバグの修正を行い、作業が完了したらメインの開発ラインにマージすることができます。

### 「git checkout」ブランチやコミットへの移動

### 基本的な使い方

```bash
git checkout [ブランチ名 or コミットハッシュ]
```

`git checkout` コマンドは指定したブランチやコミットへ移動するためのコマンドです。異なる開発ラインや過去のプロジェクトの状態を簡単に確認することができます。

#### 新しいブランチの作成と移動

```bash
git checkout -b [新しいブランチ名]
```
このコマンドで新しいブランチを作成し、そのブランチに移動します。

### ブランチ間での変更内容の比較

ブランチ間の変更内容を比較するには、`git diff` コマンドを使用します。

#### 基本的な使い方

```bash
git diff [ブランチ名1]..[ブランチ名2]
# シンプルな表示
git diff [ブランチ名1] [ブランチ名2]
```

このコマンドにより2つのブランチ間の差分を確認することができます。各ファイルでの変更点や追加・削除された行などが表示されます。

## コンフリクトの解消

Gitを使用してチームでの開発を行う際、コンフリクトは避けて通れない問題の一つです。ここではコンフリクトがなぜ起こるのか、どのように確認しどのように解消するのかについて解説します。

### コンフリクトが起こる原因

コンフリクトは、以下のようなシチュエーションで発生します。

#### 1. 同じファイルの同じ場所を複数の人が変更

二人以上の開発者が同じファイルの同じ部分を異なる方法で変更し、その後マージまたはリベースを試みた場合、Gitはどちらの変更を優先すべきか判断できません。

#### 2. ファイルの削除と変更

一方のブランチでファイルが削除され、もう一方のブランチでそのファイルが変更された場合もコンフリクトが発生します。

### git status でのコンフリクト確認方法

コンフリクトが発生した場合 `git status` コマンドを使用してその情報を確認することができます。

```bash
$ git status

On branch feature-branch
You have unmerged paths.
  (fix conflicts and run "git commit")

Unmerged paths:
  (use "git add <file>..." to mark resolution)

    both modified:   example.txt
```

上記の出力から、`example.txt` ファイルにコンフリクトが発生していることが確認できます。

### 実際のコンフリクト解消の手順

#### 1. コンフリクトの箇所を確認

コンフリクトが発生しているファイルをエディタで開きます。コンフリクトの箇所は以下のようなマークで示されます。

```bash
<<<<<<< HEAD
[変更された内容A]
=======
[変更された内容B]
>>>>>>> branch-name
```

変更されたAを採用する場合には次のように上記から不要な部分を削除します。

```bash
[変更された内容A]
```

#### 2. コンフリクトの解消

上記のマークを参考にどちらの変更を採用するか、または独自の変更を加えるかを決定します。そして不要なマークを削除します。

#### 3. 変更のステージング

コンフリクトを解消したファイルをステージングします。

```bash
git add example.txt
```

#### 4. コミットの完了

コンフリクトの解消が完了したら、コミットを行います。

```bash
git commit
```

学んだ内容のまとめ

- Gitの基本的な概念とその重要性
- 基本的なコマンド (git status, git diff, git stash) の使い方と役割
- 作業中の変更の確認と一時保存の方法
- ブランチとコミットへの移動方法
- コンフリクトの原因とその解消方法

Gitの学びはここで終わりではありません。実際のプロジェクトでの使用や、さらなる高度なコマンドの探求が待っています。
エンベーダーで実際のGitコマンドを試すことができるのでぜひ学習に役立ててください。

https://envader.plus/course/5/scenario/1055


ここでは表題の`git diff`, `git stash` に加え、`git status`という3つの重要なコマンドをそれぞれの使い方や役割、利点について解説します。

Gitの作業効率化！git stash と git diff の使い方を解説

# IAMエンティティを理解する ユーザー・グループ・ロールの基本

![https://storage.googleapis.com/envader-article-images/iam-entity-intro/001.png](https://storage.googleapis.com/envader-article-images/iam-entity-intro/001.png)

## この記事の目的

この記事は、AWSのIAMサービスの基本的な概念と使用方法を初心者の方に分かりやすく解説し、安全かつ効果的なAWSリソースの管理の第一歩としてIAMの重要性を理解してもらうことを目的としています。

### IAMとは何か？

IAM (Identity and Access Management) は、AWSのサービスの中で、ユーザーやアプリケーションがAWSリソースにどのようなアクセスを持つかを管理・制御するサービスです。

### なぜIAMが重要なのか？

AWSを使用する上で、誰がどのリソースにどのようなアクセスを持つかを明確に管理することは、セキュリティの観点から非常に重要です。IAMを適切に設定することで、不要なアクセスを制限し、リソースのセキュリティを向上させることができます。

### IAMエンティティを理解することの意義

IAMエンティティ、つまりユーザー、グループ、ロールなどの概念を理解することは、AWSのセキュリティ設定の基盤となります。これらのエンティティがどのように連携し、アクセス制御を実現するのかを把握することで、より適切なアクセス権限の設定や管理が可能となります。本記事を通じてIAMエンティティの基本的な知識を習得し、AWS環境でのセキュリティ対策を理解していきましょう。

## IAMエンティティの基本

エンティティとは実体を意味し、データベースやシステムにおいて、個別に識別可能な要素やオブジェクトを表す概念です。IAMエンティティは、AWSリソースへのアクセスを許可するAWSのIDとアクセス許可管理サービスです。IAMエンティティとは、AWSリソースへのアクセスを制御するためのものです。

### ユーザー

IAMユーザーは、AWSリソースにアクセスする個人やサービスです。ユーザーは、コンソールへのログイン認証情報やAPIのアクセスキーを持つことができ、これによってAWSのリソースへのアクセスが許可されます。

### グループの役割

IAMグループは、複数のIAMユーザーをまとめるためのコンテナです。グループ自体には認証情報は存在せず、主にアクセスポリシーの適用という形での役割があります。特定のアクセスポリシーをグループに割り当てることで、そのグループに所属する全ユーザーに同じ権限が一括で適用されるため、ユーザー管理が効率的に行えます。

### ロールの利点

IAMロールは、特定の状況やタスクでAWSリソースに一時的にアクセスする必要がある場合に使用される特別なエンティティです。例えば、EC2インスタンスがS3バケットにデータを保存する場合や、別のAWSアカウントのリソースにアクセスする場合など、ロールを使用して一時的なアクセス権限を付与することができます。ロールの主な利点は、永続的な認証情報を持たない点であり、必要な期間やタスクのみ権限を持つことができるため、セキュリティリスクを最小限に抑えることができます。

ロールとポリシーについて詳しくは次の記事で解説しています。

https://envader.plus/article/247

## IAMユーザーの作成と管理

![https://storage.googleapis.com/envader-article-images/iam-entity-intro/003.png](https://storage.googleapis.com/envader-article-images/iam-entity-intro/003.png)

### ユーザーの作成方法

AWSのIAMユーザーは、いくつかの方法で作成することができます。

#### AWSマネジメントコンソール

ブラウザベースのインターフェースを使用して、手動でユーザーを作成。簡単なステップに従って情報を入力し、ユーザーの作成と設定が可能です。

#### CLI (Command Line Interface)

コマンドラインを使用して、スクリプトや一連のコマンドでユーザーを迅速に作成。特に大量のユーザーを一度に作成する際などに便利です。

#### SDK

AWSの提供するソフトウェア開発キットを使用して、プログラム的にユーザーを作成。アプリケーションやシステムとの統合時に役立ちます。

### IaC(Infrastracture as Code)

CroudFomationやTerraformといったIaCツールのコードで作成します。一貫性と保守性が向上します。以下はサンプルコードです。
sample-iam-userというユーザーをsysytemパスに作成しPurpose（目的）タグを付与しています。

```bash
resource "aws_iam_user" "sample_user" {
  name = "sample-iam-user"
  path = "/system/"
  
  tags = {
    "Purpose" = "Sample IAM User Creation using Terraform"
  }
}
```

### アクセスキーの取り扱い

IAMユーザーがAWSサービスにプログラム的にアクセスする際には、アクセスキー (Access Key ID) とシークレットキー (Secret Access Key) が必要です。
重要性: アクセスキーとシークレットキーは、ユーザーの認証情報の一部として機能します。これらのキーを持っている者は、そのユーザーとしてAWSリソースにアクセスすることができるため、非常に慎重な取り扱いが求められます。

### 安全な管理・保管方法

#### キーは絶対に公開しない

公開場所やソースコードにキーを直接記載しないこと。

#### 定期的にキーのローテーションを行う

古いキーを無効にし、新しいキーを発行することで、セキュリティリスクを低減します。

#### 不要なキーは削除

使用していないキーは削除し、必要最低限のキーのみを保持することを心がける。

#### キーのアクセスを制限

キーの情報を必要とする者のみに共有し、それ以外の者からはアクセスできないようにする。

## IAMグループとアクセス制御

![https://storage.googleapis.com/envader-article-images/iam-entity-intro/002.png](https://storage.googleapis.com/envader-article-images/iam-entity-intro/002.png)

IAMのベストプラクティスとして、ポリシーはグループにアタッチし、ユーザーを該当するグループに所属させることが推奨されます。これにより一貫したアクセス権限の提供と効率的な権限管理が可能となり、セキュリティの向上も期待できます。

### グループの作成手順

1. AWSマネジメントコンソールにログイン後、IAMダッシュボードを開きます。
2. 左側のナビゲーションペインで「グループ」を選択し、「新しいグループの作成」をクリックします。
3. 必要な情報を入力し、ユーザーをグループに追加することができます。

### グループを利用したアクセス権限の設定

- グループの詳細ページから「ポリシーのアタッチ」をクリックします。
- 必要なポリシーを選択し、グループに割り当てることで、そのグループに所属するユーザーに指定のアクセス権限が適用されます。

### Terraformのサンプルコード（IAMユーザーをグループに追加）

以下は、Terraformを使用してIAMユーザーをIAMグループに追加するサンプルコードです。

```bash
# IAMユーザーを作成
resource "aws_iam_user" "sample_user" {
  name = "sample-iam-user"
}

# IAMグループを作成
resource "aws_iam_group" "sample_group" {
  name = "sample-iam-group"
}

# IAMグループにユーザーを追加
resource "aws_iam_group_membership" "sample_membership" {
  name = "sample-membership"

  # IAMユーザーの名前
  users = [
    aws_iam_user.sample_user.name
  ]

  # IAMグループの名前
  group = aws_iam_group.sample_group.name
}
```

このコードでは、まずIAMユーザー`sample-iam-user`とIAMグループ`sample-iam-group`が作成されます。次に、`aws_iam_group_membership`リソースを使用して、該当のユーザーをグループに追加します。

## まとめ

### IAMの基本を押さえる重要性

AWSを利用する際のセキュリティは非常に重要な要素です。IAMはその中心となるサービスであり、適切なアクセス制御を行うための基本的な知識は必須です。正確なユーザー管理やアクセス権限の設定を通じて、AWSリソースの安全性を確保することができます。

### 今後の学習のためのステップ
  
IAMの基本知識を習得した後は、更に応用的な知識や他のAWSサービスとの連携についての学習を進めることをおすすめします。以下の日本語のリソースを参考にしてください。

#### AWS公式ドキュメント

AWSの公式サイトには、IAMをはじめとする各サービスの詳細なドキュメントが提供されています。基本から応用まで幅広く学べるリソースです。

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/introduction.html

#### AWSブログ

AWSの公式ブログには、技術的なチュートリアルやユースケース、最新のアップデート情報などが掲載されています。IAMに関する記事も多数あり、実際の運用例などを学ぶことができます。

https://aws.amazon.com/jp/blogs/news/


本記事を通じてIAMエンティティの基本的な知識を習得し、AWS環境でのセキュリティ対策を理解していきましょう。

IAMエンティティを理解する ユーザー・グループ・ロールの基本

# IAMエンティティ応用　IAMロール・ポリシーについて解説

![https://storage.googleapis.com/envader-article-images/iam-entity-applied/001.png](https://storage.googleapis.com/envader-article-images/iam-entity-applied/001.png)

## 本記事の目的

AWSのセキュリティを強化するための主要なサービスであるIAM（Identity and Access Management）には、多くのエンティティと概念が存在します。これらのエンティティの中でも、特に重要な「ロール」と「ポリシー」について、詳細に解説していくことが本記事の目的です。

前回、IAMエンティティの基本についての記事を公開しました。その中でユーザーやグループなどIAMの基本的なエンティティや、それらがどのように連携して機能するのかについて触れました。IAMの奥深い部分をより良く理解するためには、ロールとポリシーの知識がとても役立ちます。今回はこの2つのトピックを詳しく解説していきたいと思います。

### 前回の記事の振り返り

前回の記事では、IAMの基本的なエンティティ、すなわちユーザー、グループ、ロールについて概要を紹介しました。ユーザーはAWSリソースへのアクセスを持つエンティティ、グループは複数のユーザーをまとめるためのエンティティ、ロールは一時的なアクセス権を付与するためのエンティティとして紹介しました。

前回の内容を未読の方や、再度確認したい方は、こちらのリンクから詳細な記事をご覧いただけます。

https://envader.plus/article/246

## IAMロールの深掘り

![https://storage.googleapis.com/envader-article-images/iam-entity-applied/003.png](https://storage.googleapis.com/envader-article-images/iam-entity-applied/003.png)

### IAMロールとは？

IAMロールは、特定のAWSサービスやユーザーが一時的にAWSリソースにアクセスするための中継的な役割を果たします。IAMロールはアクセス許可を持ち、それを一時的に他のエンティティに"貸し出す"ことができます。直接アクセスキーを持たないエンティティでも、ロールを介して特定のリソースにアクセスすることが可能となります。

### 代表的な使用例

#### EC2インスタンス

EC2インスタンスがS3バケットや他のAWSリソースにアクセスする際、直接アクセスキーを持つことなく、IAMロールをアタッチすることで必要な権限を得ることができます。

#### Lambda

Lambda関数がRDSやDynamoDBテーブルなどのデータベースにアクセスする必要がある場合、関数にIAMロールを関連付けることで安全にアクセスすることが可能となります。

### ロールのメリットとデメリット

![https://storage.googleapis.com/envader-article-images/iam-entity-applied/002.png](https://storage.googleapis.com/envader-article-images/iam-entity-applied/002.png)

#### メリット

- セキュリティの向上
    アクセスキーを直接持たないため、キーの漏洩リスクが低減します。
- 柔軟なアクセス管理
    ロールを介して一時的にアクセス権限を付与・変更することができるため、状況に応じた細やかなアクセス制御が可能です。

#### デメリット

- 設定の複雑さ
    IAMロールの設定や関連付け、ポリシーの適用など、初めての方には少々複雑に感じられるかもしれません。
- 適切なポリシーの選択が必要
    ロールに適切なアクセス権限を持つポリシーを関連付ける必要があり、誤った設定はセキュリティリスクとなる可能性があります。

## IAMポリシーの詳細

IAMポリシーは、AWSリソースへのアクセスを制御するためのドキュメントです。このセクションでは、IAMポリシーの種類やその構成、ベストプラクティスについて詳しく解説します。

### マネージドポリシーとインラインポリシーの違い

#### マネージドポリシー

AWSが提供する既存のポリシーであり、複数のIAMエンティティ（ユーザー、グループ、ロール）に再利用可能です。公開されているものや、ユーザーがカスタムで作成したものが含まれます。

#### インラインポリシー

ユーザーが特定のIAMエンティティに直接関連付けるためのカスタムポリシーです。このポリシーは、関連付けられたエンティティにのみ適用され、再利用はできません。

### JSON形式のポリシーの読み方と作成方法
IAMポリシーはJSON形式で記述されます。主要なキーには以下のようなものがあります。

- Effect：ポリシーが許可するか（"Allow"）、拒否するか（"Deny"）を指定します。
- Action：許可または拒否するアクションを指定します。例：s3:ListBucketやdynamodb:PutItemなど。
- Resource：アクションが適用されるリソースを指定します。例：特定のS3バケットやDynamoDBテーブルなど。

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket"
      ],
      "Resource": "arn:aws:s3:::example-bucket"
    },
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:PutItem"
      ],
      "Resource": "arn:aws:dynamodb:us-west-1:123456789012:table/example-table"
    }
  ]
}
```

上記のサンプルポリシーでは、example-bucketというS3バケットのリストを表示する権限と、example-tableというDynamoDBテーブルにアイテムを追加する権限が許可されています。

## ポリシーの書き方のベストプラクティス

### 最小権限の原則

必要最低限の権限のみを付与すること。これにより、不正なアクセスや誤操作のリスクを最小限に抑えることができます。

### 明確なリソースの指定

ポリシーでリソースを指定する際は、可能な限り具体的に指定すること。ワイルドカード（*）を使用する場合は注意が必要です。

## IAMロールとポリシーのTerraformによるサンプルコード

Terraformは、AWSなどのクラウドプロバイダのリソースをコード化し、安定した環境を効率的にデプロイするためのツールです。以下は、Terraformを使用してIAMロールとポリシーを作成するサンプルコードです。

### 1. IAMポリシーの作成

```bash
resource "aws_iam_policy" "example" {
  name        = "ExamplePolicy"
  description = "My example policy description"
  
  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Action   = ["s3:ListBucket"],
        Effect   = "Allow",
        Resource = "arn:aws:s3:::example-bucket"
      }
    ]
  })
}
```

上記のコードは、S3のexample-bucketバケットの内容をリストする権限を持つIAMポリシーを作成します。

### 2. IAMロールの作成

```bash
resource "aws_iam_role" "example" {
  name = "ExampleRole"
  
  assume_role_policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Action = "sts:AssumeRole",
        Principal = {
          Service = "ec2.amazonaws.com"
        },
        Effect = "Allow",
        Sid    = ""
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "example-attach" {
  role       = aws_iam_role.example.name
  policy_arn = aws_iam_policy.example.arn
}
```

上記のコードは、EC2インスタンスがこのロールを引き受けることができるIAMロールを作成し、先に作成したIAMポリシーをそのロールにアタッチします。

これらのコードを適切な.tfファイル（例えばiam.tfなど）に配置し、`terraform init`および`terraform apply`を実行することで、IAMロールとポリシーをAWS上にデプロイできます。

## IAMのベストプラクティス

AWSのIAMを効果的に使用するためのベストプラクティスを以下にまとめます。

### 最小権限の原則

セキュリティの基本的な考え方として、ユーザーやサービスに必要最低限の権限のみを付与する「最小権限の原則」があります。これにより、誤操作や不正アクセスによる損失を最小限に抑えることができます。

### 実践方法

#### ポリシーの作成方法

- AWSが提供するマネージドポリシーを活用する
- 必要な権限を個別に定義してカスタムポリシーを作成する

#### ポリシーの管理方法

- ポリシーのレビューを行う
- ポリシーを定期的に更新する

### ルートユーザーの使用を避ける

AWSアカウントのルートユーザーは、AWSリソースに対する全ての権限を持っています。そのため、このユーザーの認証情報が漏洩すると、AWS環境に甚大なダメージが及ぶ可能性があります。

#### 理由

- セキュリティ上のリスク
    - ルートユーザーは制限なく全ての操作ができるため、不正アクセス時のリスクが極大
    - 誤操作の可能性
    - 意図しない変更や削除が容易

- ルートユーザーの認証情報を複数人で共有するリスク
    - 共有しているうちの1人の認証情報が漏洩すると、AWSアカウントに甚大なダメージが及ぶ可能性

### 定期的なアクセス権限の見直し

組織の変更やプロジェクトの進行に伴い、IAMユーザーやロールの必要な権限は変わる可能性があります。そのため、定期的にアクセス権限の見直しを行うことが重要です。

#### 重要性

- 不要な権限の削除によるセキュリティリスクの低減
    - 過去のプロジェクトや役割で付与された権限が現在も継続している場合、それを削除することでセキュリティリスクを低減
- 新しい権限の追加による作業効率の向上
    - 新しいプロジェクトやタスクのために新しい権限が必要になる場合があります。必要な権限を適切に追加することで、作業の効率を向上させることが可能

## まとめ

AWSのIAMは、クラウドリソースの管理とセキュリティの強化に不可欠です。この記事では、IAMロール、ポリシー、そしてTerraformを使った適切な設定方法について学びました。IAMの設定は複雑であり、継続的な更新が求められますが、正しく適用することで、AWSの使用経験が向上します。これらの知識を活用し、より安全で効率的なAWS環境を追求しましょう。


AWSのセキュリティを強化するための主要なサービスであるIAM（Identity and Access Management）には、多くのエンティティと概念が存在します。これらのエンティティの中でも、特に重要な「ロール」と「ポリシー」について、詳細に解説していくことが本記事の目的です。

IAMエンティティ応用　IAMロール・ポリシーについて解説

# gitのコミット履歴を整理するためにsquashを使いこなそう

![https://storage.googleapis.com/envader-article-images/git-squash/001.png](https://storage.googleapis.com/envader-article-images/git-squash/001.png)

## Squashを使用する目的とメリット

Squashは、複数のコミットを1つのコミットにまとめる操作です。Squashを使用すると、コミットの履歴を整理したり、コミットのメッセージや変更内容を変更したりすることができます。

### 使用シナリオの例

Squashは、以下のシナリオでよく使用されます。

#### 開発中の頻繁な微調整

開発中、特に新機能の開発やバグ修正時には、多くの小さなコミットが発生することがあります。これらのコミットは、最終的な成果物には重要ではなく、履歴を乱雑にする可能性があります。例えば、タイプミスの修正や小さなコードのリファクタリングなどです。

例えば、新機能の「ボタンのデザインを変更する」というコミットと「ボタンの挙動を変更する」というコミットを1つにまとめることができます。これにより、Git履歴が整理され、変更内容が一目でわかるようになります。

### コードレビューの準備

プルリクエストやコードレビューを行う前に、関連する変更を1つのコミットにまとめることで、レビュアーの理解を助け、レビュープロセスをスムーズにします。

例えば、新機能の「ユーザー登録機能を追加する」というコミットを、複数の小さなコミットに分けて実装し、コードレビュー前に1つにまとめることができます。これにより、コードレビュアーが変更内容をより簡単に理解し、効率的にレビューを行うことができるようになります。

#### ワークフローの整理

複数の開発者が関与する大きな機能開発では、個別のコミットが多くなりがちです。これらを意味のある単位にまとめることで、プロジェクトの歴史を追いやすくします。

例えば、複数の開発者が関与する「Webサイトのデザインを変更する」という大規模な機能開発において、各開発者の変更を1つにまとめることができます。これにより、将来的に変更内容を理解したり、必要に応じて変更を取り消したりすることが容易になります。

### Squashを使う主なメリット

Squashを使用する主なメリットは、以下の3つです。

#### 履歴の簡潔化

Squashを使用すると、複数のコミットを一つのコミットにまとめることができます。これにより、Git履歴が整理され、変更内容が一目でわかるようになります。

#### コードレビューの効率化

一連の小さなコミットを一つにまとめることで、コードレビュアーが変更内容をより簡単に理解し、効率的にレビューを行うことができます。

#### メンテナンス性の向上

関連する変更が1つのコミットに集約されていると、将来的にその変更を理解したり、必要に応じて変更を取り消したりすることが容易になります。

#### コラム：squashの語源

![https://storage.googleapis.com/envader-article-images/git-squash/002.png](https://storage.googleapis.com/envader-article-images/git-squash/002.png)

squashの語源は、英語の動詞「squash(スカッシュ)」です。squashは、野菜の「かぼちゃ」や「ズッキーニ」を潰すという意味の動詞です。squashの操作は、複数のコミットを1つのコミットに「潰す」ことに似ていることから、この名前が付けられたと考えられています。

また、squashは、複数のものを1つにまとめるという意味の「圧縮」や「統合」という意味でも使用されます。この意味でのsquashも、squashの操作と関連しています。

なお、GitのSquashは、英語では「squash merge」または「squash commit」とも呼ばれます。

## Gitにおけるsquashとは何か？

squashは、Gitの強力な機能の一つで、複数のコミットを一つのコミットに統合する操作を指します。このプロセスでは、複数の変更を含むコミットが、一つの新しいコミットに「潰され」、一連の変更が単一のコミットとして履歴に残ります。結果として、Gitのコミット履歴がより整理され、見通しが良くなります。

### いつ、なぜsquashするのか

squashの使用は以下のようなシナリオで特に有用です。

#### コミットの簡潔化

開発中に発生する小さな修正や、一時的な変更を一つにまとめて、履歴を整理したい場合。

#### コードレビューのための準備

プルリクエストを作成する際に、関連する一連のコミットを一つにまとめて、レビューを容易にしたい場合。

#### 機能の完全な実装の表示

特定の機能やバグ修正が完了したときに、その全体像を示すために、関連する全てのコミットを一つに統合したい場合。

### squashがコミット履歴に与える影響

squashを使用すると、Git履歴が以下のような点で改善されます。

#### 履歴のクリーンさ

squashを使用すると、Git履歴がスッキリとして、特定の変更点を追跡しやすくなります。これにより、履歴の可読性が向上し、プロジェクトの進行状況をより簡単に理解できます。

#### 情報の集約

関連する変更が一つのコミットにまとめられることで、変更の内容が明確になり、将来のレビューやメンテナンスが容易になります。

#### コミットメッセージの明確化

複数のコミットを統合することで、コミットメッセージをより意味のあるものにすることができ、プロジェクトの歴史をより明確に記録できます。

## squashの実践方法

### ステップバイステップガイド

squashの操作は、Gitのリベース機能を使用して行われます。以下は、基本的な手順を踏んだ説明です。

#### 1. リベースの開始

まず、リベースしたいコミットの範囲を決定します。コマンドは`git rebase -i HEAD~[N]`を使用します。ここで、`[N]`は統合したいコミットの数です。

```bash
git rebase -i HEAD~3
```

このコマンドを実行すると、テキストエディタが開き、リベースするコミットのリストが表示されます。

```bash
pick commit_hash_1
squash commit_hash_2
squash commit_hash_3
```

`git rebase`についてはこちらの記事で詳しく解説しています。

https://envader.plus/article/244

#### 2. Squashの選択

コミットの前に`pick`と書かれているものを`squash`または`s`に書き換えます。最初のコミットは`pick`のままにし、続くコミットを`squash`にします。これにより、`pick`されたコミットに`squash`されたコミットが取り込まれます。

```bash
pick commit_hash_1
squash commit_hash_2
squash commit_hash_3
```

#### 3. コミットメッセージの編集

全てのコミットを`squash`に書き換えた後、新しいコミットメッセージを入力します。不要なメッセージは削除またはコメントアウトします。

```bash
pick commit_hash_1
squash commit_hash_2
squash commit_hash_3

# 新機能の完全な実装
```

#### 4. 変更の確定

新しいコミットメッセージを保存し、リベースを完了します。

```bash
git rebase --continue
```

### 具体的な例

例として、以下のようなコミットがあったとします。

```bash
コミットA: 新機能の初期実装
コミットB: 新機能のバグ修正
コミットC: 新機能の改善
```

これらを1つのコミットにまとめる場合、次のように操作します。

```bash
git rebase -i HEAD~3

# 編集
pick commit_hash_1
squash commit_hash_2
squash commit_hash_3

# 新機能の完全な実装
```

```bash
git rebase --continue
```

### 注意点

* 安全な環境での実行

    Squash操作は履歴を改変するため、誤って重要な情報を失わないように注意が必要です。実験的な変更は、新しいブランチで試すことをお勧めします。

* 共有されたブランチでの使用の注意

    他の開発者と共有しているブランチでSquashを行うと、他の開発者の作業に影響を与える可能性があるため、事前にチーム内で確認することが重要です。

## Squash後のリモートへの反映

![https://storage.googleapis.com/envader-article-images/git-squash/003.png](https://storage.googleapis.com/envader-article-images/git-squash/003.png)

Squash操作後、ローカルのコミット履歴がリモートの最新の履歴と異なるため、通常の`git push`では拒否されることがあります。このような場合、強制プッシュ（`git push -f`）を使用して変更をリモートに反映させる必要があります。

### 強制プッシュの例

```bash
# ローカルリポジトリで変更を確認
git log

# 強制プッシュの実行
git push -f origin [ブランチ名]
```

### 注意点

#### 強制プッシュによるリモートリポジトリの履歴上書きのリスク

強制プッシュは、リモートリポジトリの履歴を上書きします。他の開発者の作業が含まれる場合、それらの変更を失うリスクがあります。共有されているブランチに強制プッシュを行う前には、チーム内での十分なコミュニケーションと、リモートリポジトリのバックアップの取得が必要です。

### コンフリクトの解決

強制プッシュを行った後に、他の開発者がリモートの最新の状態に基づいて作業をしていた場合、コンフリクトが発生する可能性があります。このような場合は、以下のステップで解決します。

```bash
# 最新のリモート状態の取得
git pull origin [ブランチ名]

# コンフリクトの手動解決
`git status` でコンフリクトが発生したファイルを確認
`vim [ファイル名]` などでファイルを開き、コンフリクトを解決

# 再度のコミットとプッシュ
git add [ファイル名]
git commit -m "[コミットメッセージ]"
git push origin [ブランチ名]
```

## まとめ
GitのSquash機能は、複数のコミットを1つのコミットにまとめる操作です。この機能は、コミット履歴の整理や、コードレビューの準備、機能の完全な実装の表示など、さまざまな場面で役立ちます。

Squashを行う際には、以下の点に注意が必要です。

強制プッシュ（`git push -f`）は、他の開発者の作業を上書きする可能性があるため、共有ブランチでは慎重に行うべきです。Squash操作や強制プッシュによってコンフリクトが発生する可能性があるため、その場合は適切に手動で解決する必要があります。

Squashを理解し、適切に使用することで、Gitを用いたソフトウェア開発の効率性と整理性を向上させることができます。


Squashは、複数のコミットを1つのコミットにまとめる操作です。Squashを使用すると、コミットの履歴を整理したり、コミットのメッセージや変更内容を変更したりすることができます。

インフラエンジニア

すべての記事