これまでこの連載では「いかに成長するか」「⁠いかにスキルを付けるか」というトピックについてふれてきましたが、今回は育つ側ではなく、育てる側の視点からのトピックについて書いてみたいと思います。

筆者の経験から

筆者ももちろん、最初のうちは育つ側で、ある程度スキルがついてからは育てる側にもなるようになりました。筆者が某データセンター（よく出てきますね）のマネージャに就任したときには、エンジニアが5人しかいない状態でした。すでにサービスは始まっており、しかも24時間365日の手厚いサービスを売りにしていたので、このままではサービスの提供に支障をきたすのは明確だったため、エンジニアの確保は急務の課題でした。

とはいえ、いつの時代も「できるエンジニア」はそうそう獲得できないというのは変わらぬものです。そのため、獲得ではなく育成に集中するしかないというのが筆者の出した答えであり、そしてこれはそこから現在まで10年続く筆者の目標にもなりました。

幸い、いまの時点で「できるエンジニア」ではなくても、エンジニアになりたいという希望が強く、また鍛えればいいエンジニアになる（可能性がある）人は結構いるものです。そこで当時、未経験者歓迎！とうたって広く募集を募りはじめました。

育成が目的ですから、その時点でのスキルが高ければそれにこしたことはありませんが、それよりも「教育したらいかに成長できそうか」を見抜くのがメインの採用活動になりました。前職が教師であったり、ファストフードの店長であったり、ユニークな経歴の人たちを多く迎え入れたものでした。

ところで、この連載はインフラエンジニアについてで、また当時の筆者が教育してきた人たちもインフラエンジニアですから、今回の内容はほとんどがインフラエンジニアの教育、育成について、ということになります。

ゴール設定とフローの確立

さて、インフラエンジニアというのはまず「ミスをしない」ということが最重要の課題のひとつとして求められます。以前書いたかもしれませんが、インフラというのは加点評価というよりは減点評価の面があることは否めません。もちろん、設計やパフォーマンスチューニングなど加点評価される面もなくはないのですが、いかにサービスを安定して提供するかということが一番重要です。

この場合、教育において最も重要なのは、教育される側にとっての絶対的な「ゴール」を設定することです。それはつまり「そのことさえ考えていれば間違った行動は取らない」という、信条とも言えるものです。

当時の筆者が掲げた「ゴール」は、「⁠1秒でもサービスを長く提供するにはどうすればいいかを考えること」でした。もちろん、本当はこれが全てではないのです。「⁠いかにクライアントやユーザが幸福かを考えること」のほうがより重要ではあります。ただ、そのゴールでは、運用の現場では最終判断がつかないケースがありうるのです。

「1秒でもサービスを長く提供するにはどうすればいいかを考えること」はかなりの確率で正しい判断であり、また現場でも判断が下しやすいゴールであったため、このような設定をしたのです。未経験者や初心者を教育する場合、ある程度のレベルまでは、ゴールを設定することのプラスの面が強く作用します。レベルがあがってから、そのゴールでは不足している点を補ってあげれば良いのです。

次に行ったのはフローの確立でした。これはとくにインフラエンジニアには強く言えることですが、ミスを減らすには良いフローが欠かせません。筆者は結局そのデータセンターには4年在籍していましたが、最初に定めたフローはほぼそのままの形で4年後にもまだ使われていました。朝令暮改は悪いことではないですが、運用のフローにとってはあまり好ましくありません。

このため「いかに長く使えるか」という視点でフローを作ることは重要です。そのフローの特徴は、とにかくいちいち、上位者の確認が入ることでした。作業計画の作成、確認、実行、確認、報告、確認、といった具合です。これによって、計画の立案、実行、報告の各時点で上位者から、駄目な点があれば「赤が入る」ことになります。これによって作業をしながら学ぶことができ、かつミスを出さないという、教育と実務を両立させることができました。

また、上位者にとっても、人の作業をチェックすることは自身のスキルの向上につながるのは言うまでもありません。「⁠他人に教えられないスキルはスキルではない」のです。当時の筆者にとっては、初心者だけではなく、上位者ももちろん教育の対象だったのです。また、このフローの導入によって自然と、どの程度のレベルであれば上位者になるのかがわかりやすい、という良い点もありました。

査定のポイントは「評価基準が共有できること」

他にも教育をしていく時に重要なものに、正しい査定というものがあると思います。正しい成長が正しく評価をされるというのはとても大事なことです。当時の筆者は以下のような方法で査定を行っていました。

まずレベルを1から10まで設定します。おおまかに言うと、

というものでした。目安としては、8,9が見習い、7で半人前、4,5,6で一人前というイメージです。

そのため未経験や初心者で入ってきた人はまずレベル7になり、そして6以上になるというのが当面の目標となります。またこれらのレベルは、前述した作業フローとも密接に連携していました。フローにおける上位承認者というのは、上記のレベル6以上のことを指していました。ただしレベル4,5,6でも、自身が作業するときは他社の承認は必要です。

レベル1,2,3であれば自身の判断だけで作業することができました。そして、このレベル決定のための査定をレベル6以上のメンバーで毎週開催していました。全メンバーのレベルの上下維持について、レベル6以上の全メンバーで評価していたのです。

この評価方法は、手前味噌ですがかなり上手く機能していたと思います。ほぼ全員の間で「このくらいのスキルならこのレベルだ」という感覚が共有されていたため、スキルアップの目標が常にわかりやすいものだったと思います。スキルアップと評価がうまく連携していないと、教育には支障をきたすのではないでしょうか。

栄光の？「第三小隊」

もうひとつ、当時重視したのがチーミングです。某データセンターでは当初、3つのチーム編成からスタートしました。当時は「小隊」と呼んでいたのでここでもその名称を使用しますが、簡単にいうと朝、昼、晩のシフトがそれぞれ第一小隊、第二小隊、第三小隊と呼ばれていました。そしてメンバーが増えるうちに、SI業務を行う第四小隊、特殊作業を行う第五小隊と増えていきました。

もちろん、各小隊にはそれぞれ隊長がいます。ちなみに、この隊長は、レベル6以上でないと就任できないものでした。そして、教育、育成においては教育する側、される側の相性というものが思いのほか強く作用します。ですから、ある隊長の元で伸び悩んでいた人を他の隊長の下に移すと成長する、というのはままあることでした。このため、「⁠この人は今の段階ではこのチームにいるほうがいい」とか「この人とこの人を同じ小隊に入れて競わせるといい」なども重視していました。

また、レベルによって所属するのにふさわしい小隊、というのもあります。24時間サービスを提供している場合、どうしても夜間作業者というのは必要です。筆者のケースでは第三小隊が夜間作業を行うチームでした。この夜間作業を行う第三小隊は、未経験者や初心者はあまり配属できないのです。

トラブルというのは夜間に起こることが多いですし、また昼と違い夜には基本第三小隊のスタッフしかいないため、他に頼れることができません。このため、第三小隊に配属されるのはある程度のレベル以上になってから、ということになります。

「どう確保するか」から「どう育てるか」へ

ここまでは比較的、未経験者、初心者をどう教育するかについてという視点のトピックでしたが、もちろん上位のマネージャをどう教育するかというのは同じくらい、もしくはより重要なことです。上位のマネージャを育成できれば、初心者の育成はそれらのマネージャに任せることができます。そしてトップはマネージャの教育に専念することができます。トップが全ての人員を教育しているのでは、組織の規模と成長に自から限界があります。

具体的にどういった技術をどう教えるかについては、今回のトピックでは触れていません。今回はあくまでも、教育をしていくうえでの枠組みや仕組みという視点で書いてみました。

まとめると、ゴールを設定する、フローを作る、査定評価の仕組みを作る、チーミングをする、間接教育ができるようにする、と当たり前のことばかりではあります。もちろん、これらに加えて、トップおよび上位者の技術力が高い、というのが重要なことです。

残念ながら、仕組みだけでは人は育ちません。できるエンジニアが正しい枠組みの中で教育をして始めて、できるエンジニアを育成することができるのです。このため、エンジニアの育成においては、まずは自身のレベルを上げること（この連載でも都度書いています）と、それに加えて教育の枠組みを作ることが重要なのだと思います。

今は「いかにできるエンジニアを確保するか」が企業の勝負の分かれ目だ、と言われたりします。もちろん、「⁠エンジニアが企業にとっての重要な要素だ」と声高に言われるようになったことは、とても良いことだと思います。ただ、その先には、確保ではなくて、「⁠いかにできるエンジニアを育成するか」こそが重要だと思われるステージが来ることでしょう。

筆者は今後もその点について、考えてまた行動していこうと思います。