なぜ今日本企業は今、「Infrastructure as Code」（IaC）に舵を切るべきか？ ガートナーが明かすインフラ自動化戦略

エンジニアの“労苦”を半減し、価値ある活動に時間を使え

　旧態依然とした組織にはチャレンジが多いが、それ以上にIaCのメリットは多い（図3）。特に、日本企業に共感されそうなものに、「Reduce Toil（労苦の低減）」がある。Site Reliability Engineering（SRE）では、トイル（toil）を「手作業、繰り返される、自動化が可能、戦術的、長期的な価値がない、サービスの成長に比例して増加する、といった特徴を持つ作業」と定義しており、Googleではこの無駄な時間を50％未満に減らすことに取り組んできた。その狙いは、貴重なエンジニアの時間を無駄にすることなく、サイトの信頼性向上に集中できるようにすることだ。

　そして、その先のSREの最終目標は、サービスを改善し、ユーザー体験を向上させることにある。その実現には、開発者の体験向上が前提になる。国内では、障害が発生したときに備え、オペレーターが夜間監視対応を求められる現場が未だにあるが、エンジニアがもっと価値ある活動に関われるようになるためにも、プラットフォームエンジニアリングやSRE以前に、ガートナーではIaCをすぐにでもやるべきことと捉えている。

　そのためには、インフラエンジニアの意識改革から始めなければならない。青山氏は、「プラットフォームエンジニアリングの実現に向けて、サーバーからストレージ、ネットワークまで、インフラを構成要素ごとに見る代わりに、インフラ全体をプロダクトとみなす考え方への転換が求められる」と説明した。それができると、開発側がインフラを気にしなくてもすむよう、アプリケーション開発者体験をサポートする仕組みを作ることも視野に入る。

　具体的には、セルフサービスポータルを構築し、軽微な変更要求には、開発側で対応できるようにするようなことだ。また、機能の追加開発にも迅速に追随する。これはマイクロサービスアーキテクチャーでコンテナ化しておいた方が対応しやすい。つまり、IaCを個別のテーマと捉えるのではなく、インフラのクラウド移行と最適化に継続的に取り組むことがインフラエンジニアの変革ジャーニーになる。