こんにちは。自称ソフトウェアエンジニアの橋本 (@hassaku_63)です。最近は斉藤和義と Original Love の楽曲をよく聴いています。歌って弾けるようになりたい。
この記事では、2024/07から始めた社内向けのイネーブリング活動である "CDK Office Hour" の活動内容を紹介します。
Office Hour って？
Office Hour とは、いわば「なんでも相談会」です。AWSJ の SA (Solution Architect) さんが不定期で開催している*1同名の活動から名前と基本スタイルを拝借しました。
SA さんが所属しているセクションごとに得意分野があるので、その得意分野ごとで「この時間帯、これこれの場所 (Zoom とか、AWS Loft とか）に常駐しているので、お客様は何でも聞きに来てね！！！」とオープンに相談相手になってくれるものです。私がやっている "Office Hour" は、この企画のスタイルを真似て、とりあえず社内向けでやってみよう、というものです。
狙いと開催概要
対象参加者は社内のエンジニアであれば特に限定していません。もともとインフラ寄りなクラウド SIer から始まった当社でも、近年では IaC 実装も含めればコードを書く案件はごく普通にあります。こうした事情もありつつ、普段の仕事では絡みが薄い横との交流・情報交換も目的としています。
幸い、複数の部門からちょいちょい参加者が集まっていて、リピーター的に来てくださる方もあります。私自身は社内システムの運用保守込みで IaC やアプリケーションコードの面倒を見ていることが多いので、そうした分野の質問や雑談も受け付けていたりいます（どうせ中の人は私ひとりですので）。例えば TypeScript/Python/Go の話とか、ソフトウェアテストの話とかです。
当社はリモートワークのメンバーが多いので、基本的にオンラインで開催しています。気軽に立ち寄れるよう、バーチャルオフィス(ovice)で開催しています。
開催実績
当社の会計年度では昨年度の下期は 2024/09/01 〜 2025/02/28 になります。
この期間中は 11月下旬ごろまで実施していました。それ以降は私個人の事情でお休みしていました。
ざっくりカウントすると、CDK 回と銘打って開催していたのは計12回実施で、そこそこ会話に混じっていた or 開催場所に滞在してくれたであろう人が延べ30名弱ほどです。
上記の12回にプラスして、モダンな IaC の取り扱いが多めな特定の部署向けで出張開催したこともありました。それ含めると約半年で13回実施していたことになります。また、CDK 回以外にもソフトウェア開発一般で銘打って開催していたものもあるので、実際には20回以上 "Office Hour" 企画はやっているはずです。たぶん。
もらった質問や会話ネタの紹介
CDK 以外の話もちょいちょいありますが、実際にいただいたネタの一例を紹介します。なお、私の方から勝手に広げた話題もあるので以下全部が参加者からの質問・話題提供ということではないです。あしからず。
- ディレクトリのレイアウトはどうする？
- 今XXX案件でモノレポを検討しているが、レポジトリ構成についてどう思う？
- Serverless Framework から SAM or CDK に移植をすることになった
- cdk migrate や import の話
- リソースに一括タグ付けしたい
- Aspects は超絶に便利
- Aspects は GoF デザインパターンの Visitor の実装例である、という話
- Snapshot Testing は使った方がいいの？
- 社外のベンダー（開発者）にもコードを触ってもらう想定があるが、その際にガードレール的な仕組みを入れておきたい。どうすれば？
- おすすめな情報源、参考資料、書籍など。書籍の選書傾向など
- CDK は CloudFormation を知らなくても、TypeScript 未経験でも、案外書けるという話を、実例交えて
- モジュール分割はどう考えている？Stack や Construct の分割はどうする？
- CDK では「平易な書き方」が推奨されるイメージがあるが、それについてどう思う？
- L3 的な抽象度の高い Construct は使っている？
- fromXXX 系のメソッドと、IXxxx の命名規則を持つ（Construct と基本 1:1 対応することが多い）インタフェース型についての有用性
- デプロイ前のデグレ防止のチェックはどうやっている？
- 一部の L2 Construct で内部的に Custom Resource を使っているものがあって、なんとなく気持ち悪さがある。これについてどう思う？
- terraform plan 相当のものは CDK にある？
- あるパラメータの命名について迷っているのでいい案あれば聞きたい
- 同じ仕事をする2つの実装パターンがあるんだけど、どっちが好みか？もしくは良し悪しの判断などあれば聞きたい
- 昔の Asset って削除してる？
- 外部から注入する設定値は、何を使ってどのように CDK コードの中で扱うか（環境変数や Parameter Store, Context などの扱い）
- CI/CD どうやって組む？
- 対応言語の中では Python しか経験がない。CDK でも Python の採用を検討しているが、TypeScript の方がいいの？
一部の回答を紹介
ここでは、実際にいただいた質問とそれに対する私の回答をいくつか紹介します。説明しきれない文脈もあり、説明不足に見える点があるかもしれませんがご了承ください。
ディレクトリのレイアウト
（質問内容の補足）アプリケーションのソース（フロント＆バックエンド）が同一レポジトリに混じっているので、cdk init で作成されるディレクトリレイアウトと一緒にすると少し違和感があった。
（以下、私の回答）
基本的には cdk init で作成された構造をベースにするのでよいと思う。後からサブディレクトリを切って引っ越すことは（CI/CD を含めたコードベース全体が大きく膨らまない限り）そこまで難しくないはずで、クリティカルな問題ではないように見える。
ただ、IaC とアプリ実装で完全にレポジトリルートからディレクトリ分割してしまう構成は大いにアリだし、なんなら私としてはそちらの方がレイアウトとしては綺麗だと思う（これは個人的な好みの範疇もある）。npm workspace を使うことを想定したときに cdk 関係の依存関係が他の（フロントエンドなどの）ソースと自然な形で分割できるので、そういう意味でも cdk (IaC) 用にサブディレクトリを切ってしまうレイアウトはアリ。aws-samples などを見ていても、そのようなディレクトリ構成になっている例は観測できる。
Aspects は便利
Aspects の設計思想のバックグラウンドである「Visitor パターン」のことも覚えておくと、今後も何かしら役にたつかも？という話をしました。
なお、Aspects を含めた実用的な初心者向けの記事を過去に書いていますので、よかったら以下もご参照ください。
ちなみに、2024/03/27 時点で上記記事の例は少々古いです。特定の RemovalPolicy を適用する方法について解説しましたが、これは本記事の執筆時点で RemovalPolicies.of(scope) が使えますので、今後はこちらを使うとよいです。
該当機能を実装した RemovalPolicies クラスのリファレンスは以下。
class RemovalPolicies · AWS CDK
この機能が取り込まれた Pull Request は以下です。
ちなみに、この機能の中身には Aspects が使われているので、基本原理的な部分は上述の私の記事で紹介している実装例とだいたい同じです。私の実装例より、もっときっちり、ちゃんと作ったバージョンが公式から出たと思っていただければ。
※さらに余談ですが、この PR は日本人の watany さんという方が実装されています。ここ1年ほど日本人の CDK コントリビュート勢が大変アツいことになっていて、いち CDK 推しとしては大変胸熱な思いです。
スナップショットと差分管理
スナップショットは基本入れ得なので、使い捨て確実な実装でもない限りはコードベースの規模によらず入れた方が良い、というのが私の意見。
デプロイ前にスタックリソースのデグレがないかチェックしたいのであれば、例えば cdk diff を使うという選択肢もある。
しかし、スナップショットなら CI に乗せて回すのも簡単だし、スナップショット差分の有無*2がそのままレビューに役立つため、diff コマンドを使うよりも普段遣いの運用には便利だと考えている。
もちろん、ChangeSet 込みでできるだけ厳密な差分が見たい・・・！なシーンもあろうかと思うので、cdk diff が不要という話ではない。
（余談）CDK における「差分」の検知、という文脈で私が過去に書いた記事があるので、宣伝しておきます。
なお上記の記事はスナップショットよりは cdk diff の方に主眼を置いた内容になっていますので、あしからず。
記述言語は TypeScript を使った方がいい？
（質問内容の補足）質問者は CDK の対応言語の中で経験があるのは Python のみ。言語のキャッチアップに不安があった。しかし、巷の様子を見る限りは TypeScript が優勢な様子なので、実際どうなのかを聞いてみたい・・・という質問。
（以下、私の回答）
私個人としては TypeScript を強く推したい。ただ、とはいえ周囲のチームメイトのスキル状況や、習得をサポートできる経験者が全くいない状況である場合は少々しんどいかもしれない*3。こうした周囲状況を鑑みて好ましい材料がほとんど見つからないなら、TypeScript 以外を採用するのもアリ。とはいえ、あくまでも既定路線は TypeScript である方がよい。
TypeScript を推したい理由は主に型定義の恩恵とネイティブ実装の言語であることの2点。
型定義については今さら説明するほどのことはないと思うが、IDE で補完が効くことによる開発者体験の向上、実行しなくても型のエラーはわかるので開発者としては試行錯誤を早い段階で回しやすい、Python よりも型に関するサポート自体が厚いので扱いやすい（例えばネスト構造を持つオブジェクトの扱い、型パラメータ、型ガードの存在など）*4、などが挙げられる。
ネイティブ実装言語であることの利点は、少しだけ説明がいると思うので前段の話からしていく。
CDK が多言語対応している原理だが、これは jsii という FFI (Foreign Function Interface) 的な仕組みによるもの。jsii が TypeScript の生実装を別言語に翻訳したり、翻訳された別言語と node を橋渡しする機能を提供している。詳しい仕組みは jsii の Runtime Architecture を参照いただくとして、だいたいこのような原理で複数言語のサポートを可能にしている。しかし、言語が変われば当然言語仕様にも差異があるわけで、ts 版では使えた機能が XX 言語では使えない、ということも出てくる。そして、すぐ下でも述べるように、CDK で要求される TypeScript レベルはそこまで高くない、ということも踏まえると、jsii（を噛ませた非ネイティブ実装な言語の）使用に起因する制約でハマるくらいなら、最初からネイティブ実装言語であり、かつ言語自体も大変メジャーな TypeScript を採用するのはむしろ堅実な選択だと、個人的には考えている。
・・・ただ、とはいえ ts 未経験者からすると、CDK のために新しい言語を覚えるということ自体が採用の心理的障壁と感じられるケースもかなり多いように思う。なので、それを払拭する方向の私なりの体感値を以下で述べてみることにする。
まず、私自身が TypeScript をまともに仕事で使ったのが CDK デビューきっかけであり、それでもなんとかなったことが大きい。ちなみに CDK デビュー前でまともに実務経験があった言語は Python のみ。
CDK で使う TypeScript とアプリケーションロジックの開発で使う TypeScript とでは要求される水準が全く異なり、基本的に CDK の方が要求水準が低い。ソフトウェア開発の文脈で一般的な話（主にモジュール分割の一般原則）も、CDK ではアプリケーションほどきっちりしたモノは要求されない。というより、むしろ実装で凝りすぎると後から苦労するので変にテクい実装はせず、慣れていないなら尚のことできる限り「ベタ書き」スタイルに近い書き方をしたほうがよい。共通の部品や機能を切り出すなどのアイデアは、気持ち消極寄りで判断するくらいがちょうどよい。
当社の中でも、新卒上がりの数年目で、入社前にプログラミング経験がなかったメンバー（AWS も未経験）がいきなり CDK にデビューし、それほど大きな壁もなく使えたという事例も 2,3 件観測している。こうした観測事例からも、TypeScript の経験値が薄いこと自体は、デビュー前で不安に思われている方が想像するよりも実際のハンデにはならないと考えている。
他の言語が書けるのであれば、そして（少なくとも）私が在籍して会話可能な関係値である限りは、孤立無援な状況にはならないと思う。なので、どうか当社のメンバーは信じて TypeScript を採用してほしい。
余談。観測事例のご本人いわく、「TypeScript という言語というよりは、"CDK" を書いてる、っていう感覚」らしい。ニュアンスとしてはあくまで IaC の実装を作っている感覚であって、TypeScript という言語を使っている感覚は薄いとのこと。なお、本人の体験談は AWS CDK Conference Japan 2023 にて実際に登壇発表されたものがあるので、その際の資料も併せてご紹介しておく。
AWS3年目、TypeScript初心者がCDK を使いこなせるのか？第一歩で感じたハードルとメリット - Speaker Deck
振り返り
まず感じたのは、自分が当初予想していたよりも多くの部門から参加があったことです。いい意味でびっくりしました。案外いろいろな部署が CDK を（もっと言えば IaC を）採用しているんだなと。他の参加者にとっても、意外に隣人っていたんだ・・・と刺激になったのではないかと思います。
次に、バーチャルオフィスの利用は正解だったなと思いました。予定の都合で途中参加・退出になるケースはちょいちょいあったので、もし Google Meet だったらもっと出入りが億劫だっただろうなと思いました。対象者を限定しないゆるっとした会なら、バーチャルオフィスの利用は適しているように思います。
最後に、企画当初の思惑について振り返ります。
CDK は汎用言語で書ける分記述の自由度が高いのですが、これは裏返しの欠点でもあります。私はこの特徴をポジティブにとらえていますが、とはいえ初学者にとっては悩みどころにもなりえます。インフラ出身のメンバーが多い当社では特に、記述言語に起因する要因...例えば習得コストや、記述の柔軟性の高さをハードルに感じる方も多いのだろうと、そう考えていました。
このような状況仮説を踏まえ、ある程度勘所をわかっている人間が在籍していて、いつでもサポートすると表明している状況が見えていれば CDK 入門以前〜直後のメンバーにとっては安心材料になるはずで、ひいてはそれが社内での CDK の普及にも寄与するのではなかろうかと考えました。Office Hour の企画を実行した理由のうち、組織視点のメリットはそんな感じです。体感値としては、当初の私の感覚は間違っていなかったように思います。
課題
この活動が組織にどう貢献しているのか、定量的に示すことが今後の課題です。
組織全体の生産性向上のためにも、評価指標の策定や効果測定の方法を検討し、活動の意義を明確にしていきたいと考えています。特にこの手の活動は各々の「本業」の外側にあり、また直接的に事業の売上に貢献するものでもありませんから、他者にその意義と成果が説明できることは大事になると考えています*5。
社内外を問わず、横断的な取り組みをされている方々の知見も参考にしたいと考えています。情報交換やディスカッションにご協力いただける方がいらっしゃいましたら、お声がけいただけると幸いです。
今後の展望
当分は、自分の余力があるかぎりこの活動を続けようと思っています。こうして半期の節目で報告ブログをアウトプットすることも、おそらくは大事なアピールだろうと思います。もらった質問を抽象化して公開記事として出す、みたいな話もやっていけるといいなぁと思っています。
CDK 以外のジャンル、例えば TypeScript やソフトウェア開発、CI/CD などでも同様なことができたらいいなとも考えています。
*1:Japan に限らず、各国でやってるようです
*2:これは、CI 結果として検出されるスナップショット差分によるCI失敗と、コミッターが明示的に更新したことによって発生するコミット上のスナップショットの差分、この2つの文脈があります
*3:今は生成AIがアシスタントしてくれるので、ts ライクな書き方や初見だとわかりづらい型定義の記述方法など含めて解決できそうな気はしています
*4:加えて言うと、Python がサポートするのは型ヒントであってそもそも静的型付けと別物
*5:しかしながら、現時点ではまだ具体的な改善案はありません。本音を言うと、私個人は技術の話でキャッキャできればそれで幸せな人間なので、もしかすると無意識で避けてしまっていたのかもしれませんね
