現場では、IaC や CI/CD が「やったほうがよい」と勧められることが増えています。方針としてはそのとおりです。ただ、正しく実行してもらうには、言葉の捉え方にどれだけ幅があるかを知ったうえで伝える必要があります。

同じ言葉を使っていても、頭の中の具体がずれていると、合意したつもりが噛み合いません。こちらが想定した運用と、相手が想像した運用が別物のまま進む、ということがあります。

IaCという言葉の幅

Infrastructure as Code と聞いたとき、ある人は CloudFormation を画面や手作業に近い形で直接操作することを思い浮かべます。別の人は、Terraform などのツールでコードとして宣言し、再現可能な状態を保つことを思い浮かべます。どちらも「IaC」と呼ばれることがあります。幅がある、ということです。

CI/CDという言葉の幅

CI/CD も同様です。検査を挟んで品質を確かめながら進める流れを指す人もいれば、検査なしでデプロイまでつなぐ流れを指す人もいます。同じ略語でも、中身の厳しさは大きく違います。

幅を共有してから伝える

流行語をそのまま渡すだけでは、思い描いていたことが実現できないこともあります。相手がどの具体を思い浮かべているかをそろえ、こちらの意味の幅も開示する。先に言葉を揃えてから進める必要があります。

伝え方の具体

一つは、開発統制のドキュメントに、技術用語で正しく書いておくことです。略語の定義だけでなく、どのツール・どの検査を含むかを書いておくと、後からの解釈のぶれが減ります。

もう一つは、設計会議で、まず具体を決める契約にすることです。IaC や CI/CD という言葉で合意する前に、どの幅で進めるかを会議の場で決めてから動く、という進め方です。

IaC も CI/CD も、やった方がいいことであるのは違いません。ただ、言葉の幅を知ったうえで、相手と同じ地図を持ってから伝える。それだけで噛み合い方が変わります。

ご相談ください

課題の整理からでも大丈夫です。お気軽にご連絡ください。

相談する