はじめに

2025 年 03 月 27 日 にクラスメソッドの大阪オフィスで開催された Midosuji Tech#5 にて「安易にIaCを選択したら時間をたくさん消費してしまった話」というタイトルで登壇しました。

Midosuji Tech とは？？

Midosuji Tech は、クラスメソッド株式会社の大阪オフィスで開催する IT 技術の勉強会です。気になる技術、流行りの技術など、技術全般について自由に語ったり議論するコミュニティです。

毎回テーマを決めて開催しますので、ご興味のあるテーマの際はぜひご参加ください！
https://classmethod.connpass.com/event/346306/

登壇資料

はじめに

今回はAWS環境を新規構築する際に、IaCを選択したことで、必要以上に時間を使ってしまったという内容で登壇しました。

しくじり、その1

1つめのしくじりは、目的を考慮せずにIaCを使用したことです。
IaCのメリットとして、インフラをコードで管理できる点や、コードの再利用が容易である点が挙げられます。
これらのメリットは、運用時に享受できることが多いでしょう。
この時は、IaCを使った運用は想定しておらず構築段階だけIaCを利用したことで、そのメリットを受けることができませんでした。
ただし、再利用可能なコードが手元にあったり、今後も利用することが想定されるコードであればIaCを利用することも検討できると思います。

しくじり、その2

2つめのしくじりは、普段意識していないリソースの定義に時間がかかってしまったことです。
AWSをマネジメントコンソールから利用していると、気づかないうちに必要なリソースが作成されていることがあります。
例えば、Lambda関数を作成すると、裏側でCloudWatchのロググループや、ログ出力に必要なIAMロール、IAMポリシーが作成されます。

IaCではこれらのリソースも明示的に定義する必要があります。
(ただしCDKなど、自動でリソースを生成してくれるツールもあります)
こうしたリソースの調査や定義にとても多くの時間を取られてしましました。

しくじり、その3

3つめのしくじりは、IaCでリソース定義からデプロイするまでに時間がかかったことです。
マネジメントコンソールだと、ある程度サービスを理解していれば画面を見ながら簡単にリソースを作成できます。
しかし、IaCだとリソースを定義する方法を調べ、実際にコードを書いてデプロイするという作業が必要になります。

こういった初期投資の時間を考慮できていなかったことで、定義から実装までに時間を要してしまいました。

どうしたらよかったのか？

ではどうすればよかったのでしょうか。

振り返ってみると、この時の私はIaCを触り始めてすぐだったこともあり、目的よりツールが先行してしまっていたのだと思います。
まずは目的をベースに、それを達成するために最適な手段を選択するべきだと思います。
その上で、IaCを利用する場合は初期コスト(学習コストも含め)を払うことで運用や再利用という観点で大きなメリットが得られるツールであることを理解しておく必要があるということを学びました。

最後に

皆さんの失敗話を聞いていると、とてもためになる話、あるあると頷ける話、などなど面白い話が盛りだくさんでした。
こうした失敗談を聞ける機会は珍しいので、今回話して下さった皆様には大感謝です！