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