この記事は、以下のシリーズの4つ目の記事です。
(前の記事はこちら)
さて、スキルセットの育成について話しましょう。
組織内で早い段階で構築しているスキルセットについて少し話しました。
Microsoftには、本当に数多くのCLI大好きエンジニアがいっぱいいます。
すぐにCLIにログインしたがるし、彼らが何か欲しいなぁと感じる何かの為に本当にたくさんのコマンドをタイプします。
しかし、数十、数百、数千と管理対象のネットワーク端末が増えていき、さらに高度なことにトライをしようと思った時。もはやPythonのような言語を必要としていました。
決定的だったのは２年前の出来事です。
ネットワーク機器の情報を集める必要があった時、誰かが『じゃあ全部のデバイスにログインするか』と言い出したんです。全ての端末にログインをして、インターフェースの統計情報を読んで、何が悪いのかを伝えると。これがターニングポイントでした。
これが、10の端末であれば？
問題無いでしょう。
これが100の端末だったならば？
多分無理だし、さらに17,000のデバイスを与えて同じことをやれと言われたら？
考えなくてもわかります。絶対に無理です。
では現在は？
どうやってやるのか。考えを転換しました。
Pythonか何かを使ってどうやるのか？という方向です。
netmikoのようなライブラリを用いて全ての端末にログインできるようになれば、情報を簡単に取得することができます。取得した情報を用いてその場で決定を下すようなこともできます。
先述の状態を変えるため我々はPythonからスタートしましたが、数年前にAnsibleを知るに至りました。
Ansibleを用いた変革の旅は、とても面白いものでした。
それはエンジニアたちに問題と言うていで、何かクイズを与えているのと同じだからです。
ほとんどのものはProblemフォーム上で起票されます。
エンジニアたちは起票された問題を自ら引き受け、自分が対処するつもりだというでしょう。彼らはPlaybookを作るつもりです。
そして、本当に私が欲しかった、150ものPlayが連なる長いPlaybookがどんどんと出来上がるのです。
Pull Requestが出来上がり、75から150のなにがしかの実行能力をみんなに提供してくれるのです。
ほとんどの場合、完璧なRolesを作り上げてくれます。
慣れてくると、AnsibleではRolesが作れ、それがエンジニアそれぞれの責任範囲になってくるとわかってきます。
我々はほとんどの仕事をplaybookにしてしまいましたが、もっと仕事を楽にしていくためにAnsible自体のUpstreamコミュニティへの技術提供も開始しました。
そしてこれこそが、私たち全員に新しいスキルセットの構築を開始するよう皆を説得し得るものでした。
私自身、実際には2年前、組織内でGitトレーニングを受けていませんでした。
3年前、我々の技術分野ではチームにもGitのエキスパートはいませんでした。
しかし前述の通りで組織をさらに引き上げるつもりがあるなら、Gitに熟練しなければと考えました。
どんな質問にも答えることができる専門家が必要だと思ったのです。
なので、私は恐竜の着ぐるみでトレーニングを受けました。
実際に私は恐竜の着ぐるみを着て仕事をすることができるようになったのは世界で最もすばらしい出来事でしたが、最初のブランチを紙で切り出してテープで貼った時は本当に最高でした。
しかし、これが本当に文化を大きく変えていったのです。
今日、エンジニアは一人で仕事をしている訳ではありません。400人のエンジニアがチーム全員で新たに参加してきます。
それらの新しいエンジニアは、Gitを知らない人たちです。
そういった人たちを、我々の社内コミュニティでは、皆が意欲を共有したいという気持ちを持っていて、そんな人たちがビデオトレーニングを受けて、ドキュメントを読んで、質疑をしあい、そして皆Gitを知るに至っています。
これは、船の行く先を変えたいがための最初の出発時点での話でした。
これは、Zero to Heroと呼ばれる教育プログラムです。
最初はHero To Zeroと勘違いしていました。
どう自動化を育んでいくのか、というのはずっとポイントで、我々はずっと議論を重ねてきました。
エンジニアの一人がこのプログラムを考えついて、我々の中でこのプログラムを作り上げてきました。
Ansibleをどんどん浸透させて色々な人を自動化に参加させたかったので、トレーニングプログラムには色々な人に参加してもらいました。
トレーニングにおいてはAnsibleのPlaybookの書き方、Roles、再利用性、本番環境への適用承認からの実行フローなど自動化のコンセプトとして必要なこと全てを学び、全ての内容について答えることができるくらいの能力を身につけさせます。
なぜか。Playbookの書き方をよく知って欲しいからです。
何故なら、下手なPull Requestを出した後は50-100件程度のコメントがつくこともあるのですから。
コメントが多すぎたり、ツールに慣れていなかったりして、それらの対処方法もわからず、150もの批判的なコメントがついたりしたらせっかく頑張ってPlaybookを作ってPR出したのに、『ああ失敗したな』とメンバーは感じることでしょう。そんなことは見たく無いんです。
ではどうやってそれを回避するのか？正直簡単ではなかったです。
我々はこのトレーニングを実施して、私たちはZero to Heroを開始したのです。
組織全体をどんどんと前進させ、自動化に適合させるためです。
さらに、我々はセッションを行いました。
Zero to Heroの最初の2ヶ月は環境の設定を実施し、どれほど環境が複雑なのかを知り、自分のPCのVisual Studio Codeのことを知り、Gitのことを知り、レポジトリを取得したりPullしたり、GitHub Enterpriseへのログイン方法、GitHub Enterpriseとはなんなのか、最初の数ヶ月でプルリクを実施するためには何をしたら良いのか？などなど。
本当に色々なことを新しく学んでいきました。
そして、結果として非常に快適になっています。
我々は本当に変わったのです。
今はこのプログラムは少し変えています。
実際のエンジニアのレベルに合わせて構成しています。
100, 200, 300, 400というクラスベースで割り当てています。
100のクラスはシンプルな環境設定のセットアップのクラスです。
環境設定、Gitのインストール方法、リポジトリのクローン作成方法、2要素認証とGitHubエンタープライズの設定方法など、とても簡単なものです 。
レベル200のクラスになると、どうやって最初のプレイブックを書くのかについて話し始めます。Rolesとは何か、そしてそれらをどうやって見つけることができるか。これらのRolesをどう扱い、再利用することができるのか。なぜなら、自動化をさっさと利用可能な状態にしたいのと、早く結果を残すことが大事だからです。
そして300, 400のクラスです。
非常に高度なトピック用にこれらを準備しています。テストの書き方など、オートメーションプラットフォーム内に独自のテストスキームを持っています。
400のコースを実施する時には、真剣に受講者と会話をします。
今度、Pull Requestを実施するとどんな複雑なことが起こっているのかを見せます。
そこで何が起きるのを見るのか？
現在、だいたい5〜6人のエンジニアが我々の組織内にいるのですが、彼らはネットワークエンジニアとかネットワーク開発者と呼べるような存在です。
彼らはpull requestされたコードをチェックする準備ができています。彼らが王国への鍵を管理しているので本当に安心できるようになっています。
あなた(受講者)が書いたコードは高品質で優れていることが、周りの皆が書いたコードからも証明されているので、プロダクションに安心してプッシュすることができるんですよ！と言うことを、彼らに認識させることができるのです。
そして、最後にAutomation Communityについてお話しましょう。
(次回へ続く)
