msawady’s tech-note

フルスタックエンジニアの学んだことや考えていること

【ポエム】自動化でチームの学習を促進する

自動化について思っていることをつらつらと

  • 自分のチームでは「自動化されていないものは(極力)本番に乗せない」というポリシーのもと、インフラの構築/エンハンス/運用 を行っています。
  • インフラチーム = 「手順書とパラメータシートによる辛いマニュアル作業」というイメージが有りましたが、 今のチームでは自動化することへの辛さは感じながらも楽しく仕事をすることが出来ています。

今回は「自動化されたインフラを作る流れ」と「それによるチームのKnowledgeの蓄積」について書きます。

「自動化されたインフラ」を作る流れ

基本的には以下のような流れで「自動化されたインフラ」を作っていきます。

  1. まずは手で構築する
  2. 作業メモを書く
  3. コード/設定ファイルから再構築する
  4. 作業メモをアップデートする

まずは手で構築する

よほど簡単なタスクでない限り、いきなり自動化して構築することは難しいです。 まずは検証環境を利用して手で構築することで作りたいものの全体感や、他の部分との依存関係を掴みます。 このフェーズでのゴールは「動くものを作る」です。

作業メモを書く

これがめちゃめちゃ大事です。 動くものができた段階で、以下のような内容を書いた作業メモを作ります。

  • 何をしたのか
  • 他のインフラとの依存関係
  • ハマりどころはどこか

これをすることにより、

  • 自動化に向けた設計
  • 他のメンバーへのKnowledgeシェア

を行うことができます。

最初のマニュアル構築は無駄のない手順でできないことのほうが多いので、復習の意味を込めてメモを作り、「本当にやる必要があった作業はなにか」「作業順序はどのようにすべきだったのか」を明らかにします。そして、これはそのまま自動化に向けたインプット(= 設計) になります。

また作業メモをチームに展開することで、レビューを受けて設計をブラッシュアップすることが出来ると同時に、タスクの内容をチームに展開することができます。他のメンバーへタスクを引き継ぎやすくすると同時に、本番適用後の運用タスクも引き継ぎやすくなります。

自動化のインプットを整備し、タスクの属人化を避けるためにも、作業メモを作ることは非常に重要です。

コード/設定ファイルから再構築する

作業メモに基づいてコード/設定ファイルから再構築します。このときに大事なことは最初に手で作ったものはすべて消すことです。自動化されたインフラを作るチームにおいて、手で作ったものはすべてゴミです。メンテナンスやコストの観点から、手で作ったものはすべて消してからコードや設定ファイルによる構築を行います。

作業メモをアップデートする

コード/設定ファイルからの再構築が完了したら、最初に作った作業メモをアップデートします。

  • 事前に作った作業メモの間違っているところの修正
  • 自動化の際のハマりどころ
  • 自動化できなかった部分のメモ
  • コードや設定ファイルのREADME、パラメータのサンプル

実際に構築すると事前のメモとの食い違いが出てくるはずなので、その修正を行う必要があります。

また、コードや設定ファイルから構築しようとすると、一発で出来ることは少なく、何かしらの「ハマり」が出てくるので、そこについてもメモを残してチームに共有します。

そして全てを自動化できない or 自動化しようとするほうがナンセンス なことはままあります。具体的には「cloudformationが対応していないからCLIでやった」「認証情報は手動で取得して貼り付けた」など。こういった部分についてもメモを残します。

最後に、作業やメンテナンスを不定期に行う必要がある際には、コードの使い方やパラメータのサンプルを残します。

ここまでやると、「自動化のためのコード/設定ファイル」と「その部分についてのドキュメント」が残り、「運用しやすい自動化されたインフラ」が残ります。

チームの Knowledge の蓄積

以上のような流れで自動化されたインフラを作っていくと、タスクをやった当人は「手で作り」「ドキュメントを作り」「自動化する」という3つの側面でタスクに当たることになるため、否が応でもKnowledgeが貯まります。

一方で、「個人のKnowledge」を「チームのKnowledge」にするためにはいくつか気を使う必要があります。

作業メモ(=ドキュメント)をみんなでレビューする

ドキュメントは有ることが大事なのではなく、メンバーに読まれていることが大事です。

× チームのKnowledge = ドキュメントの量 × 質
○ チームのKnowledge = ドキュメントの量 × 質 × 読んだメンバー数

最初にドキュメントを作成したあとはみんなで読み、レビューするというフローを作ると良いです。チーム全体で内容を確認し、分からないことを質問するようにします。なので、このレビューは「seniorメンバー/リーダーが確認すること」と「juniorメンバーも納得すること」という2つのゴールを持ちます。

全員が対面でレビューすることはコストが高いので、基本的にはチャットやGithub/Gitlabでのトークで行います。そこで「juniorメンバーからコメントする」など、質問が出やすくなるような工夫をすると、ドキュメントの質が上がるだけでなく、チームへのKnowledgeシェアも進みやすくなります。

急ぎのタスクはペアプロ

「手で作り」「ドキュメントを作り」「自動化する」するには一人でやると、普通に手で構築するよりも時間がかかります。ただ、スケジュールがタイトだからといってドキュメンテーションをおざなりにしたり、レビューを省略したり、まして手動で構築することは避けるべきです。

解決策としては、ペアプロ(作業)が有効です。一人でやるよりも集中できるので単純に効率が上がるだけでなく、2人で作業することで「ハマり」時間を短くすることが出来るので、1人でやるよりも格段に作業効率が上がります。また、各メンバーの暗黙知(エディタの使い方、コマンドのオプション...) を伝えることにもつながるので、Knowledgeの蓄積という面から見ても効果が高いです。

終わりに

自動化はエンジニア心をくすぐる非常に楽しい作業です。一方で、ドキュメンテーションやKnowledgeシェアを怠ると、誰にもメンテできないブラックボックスにもなりがちです。

自動化と並行してドキュメンテーションやKnowledgeシェアを進めることで、面倒くさい定形作業を省力化できるとともに、juniorメンバーの成長も進みます。