aws-dev-live-show.connpass.com
こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
以下、イベントページから引用です。
多くのエンジニアにとって、コードを書いたり、設定をチューニングしたりするのは楽しい時間です。しかし、ある環境でしか起こらないバグの調査や、単調な繰り返しの作業、人との調整など、クリエイティブな仕事への集中を妨げる「壁」もあります。 Infrastructure as Code (IaC) はアプリケーションの可視性を向上し、自動化を可能にするため、エンジニアがこれらの壁を越えるための有効な手段となります。IaCをあなたの武器にするための方法を一緒に考えてみましょう！
会の様子
エンジニアの職務満足度と楽しさ
LeanとDevOpsの科学を参考にしながら、エンジニアの職務満足度を上げるために何ができるのか？という話を聴いていきました。
本の中では継続的デリバリーやリーンマネジメントが職務満足度を上げるための方法として挙げられていますが、この他にも職務満足度を下げるような作業を減らすという方法もあるよねということで、例えば手動テストやチーム調整、障害対応などを下げるといった例が挙げられるよねという話がありました。
IaC
上述した職務満足度を上げる一つの方法として、手動ではなくコードに基づいたインフラストラクチャの管理やプロビジョニングを行うプロセスである継続的デリバリーの基礎として、IaCの紹介がありました。
IaCを活用することで、作業ミスがなくせるだけでなく、作業時間を拘束されないようにもなるメリットがあるということです。
また、WFのV字モデルで言えばIaCは詳細設計や単体テストの部分を置き換えることができるというお話もありました。
手順書の難しさ
IaCの既存の代替手段である手順書は、作業ミスを誘発するだけではなくレビューが難しいというポイントもあり、自然言語で読みやすいと思いきや詳細度が上がると知識がないと読めないというのは手順書もIaCも同じだということでした。
また、UIがいつの間にか変わってしまい、手順書と異なるオペレーションを実行しないといけなくなるリスクを常に孕んでいるという話も出ていました。
個人の意識変革をするために
IaCの活用に潜む壁として、個人の意識変革があるため、まずは試してみることが重要だということでした。
また、個人の意識変革を具体的にしてみると、
- モダンなプログラミング言語の経験がない
- プログラミングの周辺ツールがわからない
- 構築するサービスの経験がない
- 全部細かく設定しないと気がすまない
- 勝手に環境が壊れてしまいそう
- ユーザーにリクエストされていない
- プロジェクトマネージャーの賛同を得られない
といった部分がハードルになるという話が出ていました。
IaCの立ち位置
IaCはインフラとアプリケーションの中間に位置しており、境界も曖昧になっているため、インフラチーム/アプリケーションチームと分かれている場合はなかなかハードルが高いと捉えられることもあるだろうということでした。
ただし、逆に言えばインフラチーム/アプリケーションチームが一歩別チームに寄り添うきっかけになるとも言えるため、前向きに捉えて欲しいということです。
組織文化のメカニズムを作るIaC
iaCはインフラチーム/アプリケーションチームが共働するための仕掛けになり得るという話を聴いていきました。
コードを通じてチーム間でコラボレーションすることで、文化を変革するメカニズムを作り出すことができるという話で最後は締められました。
会全体を通した感想
IaCがインフラチーム/アプリケーションチームの中間にあるため、チームが共働する手助けになるというのは新しい視点でIaCを捉えていて面白かったです。
セッションも安定のクオリティで、めちゃくちゃ聞きやすかったです。
