こんにちは。
Ｓｋｙ株式会社でクラウドソリューションエンジニアを担当しています。
元々はネットワークやサーバーなどのインフラエンジニアとしてPMまで経験してきましたが、2年程前からクラウドソリューションエンジニアとして働いております。
メインはAWSですが、Microsoft Azureもお客様の要望に合わせて提案することがあります。
今日は、そんな私がクラウドソリューションエンジニアとして、便利だなと思った仕組みの「Infrastructure as Code (IaC) 」について投稿させていただきます。
背景
クラウドでインフラを構築する方は、アプリケーション側の人やクラウドやIaCが当たり前になってから構築を始めた方が多いと思います。
その方たちは、当たり前のように「IaC」を扱えますが、反対に、私のようにオンプレミスを軸にインフラを始めてきた人にとっては、「IaC」と聞いて、「え？コード？プログラム無理」とアレルギーのような拒絶反応を示す方も多いのではないでしょうか。
特にネットワークエンジニアの方は、その傾向が強いかもしれません。(個人の感想です)
ですが、「IaC」にはその拒絶反応を乗り越えてでも手に入れられる大きなメリットがあります。
例えば、こんな悩みが消えます。
- 技術継承 → 人出不足の解消
- 品質向上 → 顧客満足度向上
- ドキュメント問題 → 運用コスト、更改コストの削減
1. “技術”をチームの「資産」として継承する
長きにわたって勉強したり身に付けてきた技術力をもって、安定したサーバーやネットワークを構成してシステムを支えてきました。
その中では、新しい技術を追いかけ試行錯誤して様々な障害を乗り越えてようやく積みあがってきた「職人技」のような、膨大なノウハウが詰まっています。
それは、一朝一夕では手に入れることが難しい財産(ノウハウ)だと思います。
しかし、その貴重なノウハウはなかなか人に伝えることが難しく、更新もおろそかになって誰でも安定した品質を提供することが難しくなります。
- システムの構築時には完璧だったものが運用していくにつれて形骸化してしまう。
- システム構築時にはスーパーエンジニアがいたから何とかなったが、後になってその人が退職して何をしたのかわからない人しかいない。
- システム更改時に、既存の設定を踏襲しようとしたがドキュメントが不足していて調査に時間がかかる。
新しいOS、仮想化、クラウド、SaaSなどシステムはどんどん複雑化するのに品質の重要性は上がってきています。
それらを作る手法が古いままだと品質の低下や工数の増加など、近年の物価上昇に加えて重い問題がのしかかってきます。
2. レビュー文化で品質向上！責任もチームで分担する
「コード」という共通言語ができることで、複数人でチェック（レビュー）し合えるようになります。
結果、一人に責任が集中するのではなく、チーム全体で品質を担保する体制が作れます。
手作業でのインフラ変更は、どうしても個人の責任になりがちです。
- 「深夜、たった一人で膨大な量のパラメータを手作業で変更する」
- 「夜にもんもんとしながら寝て解決策を検討する」
そんな孤独な戦いを経験した方も多いのではないでしょうか。
しかし、IaCを導入して GitHub や GitLab などでコードを管理すれば、その戦いは「チーム戦」に変わります。
変更内容は「こういう変更をしたいです」というPull Request（提案）としてチームに共有され、複数のメンバーが「この設定で合ってる？」「こっちのほうが効率的じゃない？」とレビュー（査読）し合えるようになります。
上長も、具体的なコードの差分を見ながら的確な承認ができます。
この仕組みによって、「誰がやったんだ」という個人の責任追及ではなく、「チーム全員で品質を保証した」という、前向きな責任の分担が実現できます。
これは、心理的安全性を高め、チームのパフォーマンスを向上させる上でも、非常に大きな一歩です。
3. さらばExcel手順書！“動く設計書”で形骸化を防ぐ
Excelの手順書は、作成も更新も大変な労力がかかります。
結果、メンテナンスが追いつかず、いつしか誰も信じない「形骸化」したドキュメントになってしまいがちです。
IaCは、この長年の悩みから私たちを解放してくれます。
なぜなら、IaCのコード自体が、そのまま「インフラの最新の設計書」になるからです。
コードを見れば、現在のインフラ構成が100%正確に分かります。
変更履歴もすべてGitに残っています。
もはや、実態と合っているか分からないExcelファイルとにらめっこする必要はありません。
コードという「常に最新の状態を示す信頼できるソース」があります。
お客様への納品物も、形骸化するExcelではなく、「動く設計書」であるコードによって、素早く高い価値を提供できます。
メリットは以上です。
では、ここらからは「IaC」を始めていきましょう。
IaCのツール
IaCにはTerraformやAnsible、AWS CloudFormationなど、様々なツールがあります。
それぞれに特徴がありますが、もし最初のツール選びに迷ったら、まずは Terraform から触ってみるのはいかがでしょうか。
Terraformをおすすめする理由
- AWS、Azure、GCP など主要なクラウドサービスで利用できる汎用性が高く、案件母数の増加、スキルの汎用性からエンジニアの価値向上が見込めます。
- ベンダーロックインを防ぐことができます。
- 宣言的な記述：「サーバが1台、ネットワークがこれ」といった「あるべき姿」を定義する書き方なので、構成が直感的に理解しやすいです。
- 情報が豊富：世界中で使われているため、困ったら生成AIやインターネット検索が助けてくれます。
もちろん、Ansibleのように「サーバにソフトウェアをインストールする」といった構成管理が得意なツールもあります。
まずはTerraformでインフラの土台を作る経験をしてみて、そこから興味の幅を広げていくのが良いと思います。
まとめ
Infrastructure as Code (IaC) は、決して一部のプログラマーのためだけの、難しい技術ではありません。
本記事で紹介してきたように、IaCを導入することは、
- 工数を減らし、お客様に寄り添った価格や納期を実現する。
- 品質の高め、お客様からの揺るぎない信頼を勝ち取る。
…といった、ビジネスの成功に直結する大きな価値をもたらしてくれます。
まさに、品質、コスト、生産性を向上させ、会社とチームの力を底上げする「強力な武器」と言えるのではないでしょうか。
最後に、まだIaCに触れていない方は、検証環境や最小限の環境で試してみてはいかがでしょうか。
