「As Code」
私自身はこれまで、「X as Code」における「as code」という接尾辞を、「原則やルールの体系」という意味で捉えてきました1。これは、「as code」を「プログラミングとして」という意味に捉える一般的な解釈とは異なります。
この短いブログ記事を書いて自分の意図を明確にしておく必要を感じたのは、私がTerraform2を始めた経歴があるために、こうした誤解を受けることが多いからです。Terraformは、「X as Code」を掲げる代表的なツールです。
私が「X as Code」3で目指してきたのは、人々の頭の中にある知識を外に取り出し、より明確に記録された仕組みに落とし込むことです。記録されれば、その知識やプロセスを共有し、バージョン管理し、改善を重ねていくことなどが可能になります。
プログラミングとの関係は、体系化された知識はコンピューターでも読み取れる形になりやすく、そのことによる利点をすべて得られるという点にあります（自動化や検証などです）。ただし、「as code」のシステムに、現代のプログラミングに求められる要件をすべて適用すべきだとは考えていません。
歴史的な補足をすると、私は10年以上前に（Terraformより前に）Tao of HashiCorpの共著者になりました。この考え方は、そこにある「体系化」に関する2つの節にも今なお表れており、元の文章からほとんど変わっていません。これは、「as code」に込めた私の意図を理解するうえで、もう一つの手がかりになるはずです。
この投稿を、「プログラミングとして」という考え方への批判や、「as code」が完璧だという主張、あるいは「as code」は常にこのように解釈すべきだという主張4として受け取らないでください。どれも私の意図ではありません。ここで明確にしたいのは、あくまで私自身がこれまでこの言葉に込め、使ってきた意図だけです。
脚注
私はもう何年もTerraformに携わっておらず、2023年にはHashiCorpを退職しています。また、私が自分の功績として挙げているのは、あくまでTerraformを始めたことだけです（私一人で始めたわけでもありません）。その後の何年もの間、Terraformを保守してきたのは別の人々です。 ↩
「X as Code」や「Infrastructure as Code」という言葉を作ったのは私ではありません。誰が作ったのかは知りませんが、Terraformや私のキャリアより前から存在していました。求められていないビジネスアドバイスを一つすると、新しい市場カテゴリーを作るのではなく、既存のカテゴリーに参入しましょう。市場を教育するコストは競合他社に負担してもらえばよいのです。 ↩
結局のところ、物事の定義は社会的なプロセスです。大勢が向かうところへ、私たちも皆ついていくことになります。 ↩