急拡大が難しいからこそ地道な育成が鍵――X-Tech5 CTO 馬場氏が語るインフラエンジニアの組織づくり

エンジニア職の中でも、とりわけ経験者採用が難しいと言われるインフラエンジニア。そのため自社で育成することを前提に採用を進める必要も出てきます。

しかし現実には、「インフラエンジニアもしくはその候補の採用がうまくいかない」「育成目的で未経験者を採用したが教育がうまくいかない」といった悩みを抱えている企業も多いのではないでしょうか。

加えて、ITシステムはクラウドへの移行が急激に進み、インフラ構築だけでなくセキュリティ面の考慮や保守・運用までトータルで考えられる人材が求められるようになりました。そういった変化の中、ITインフラ・システムの構築および運用を支援する、株式会社X-Tech 5で取締役CTOを務める馬場俊彰さんは、前職からインフラエンジニアの育成やチームビルディングに注力されてきました。

特効薬はないに等しい。根気よく育てる。そのための仕組みづくりが大切――。そう語る馬場さんが前職時代からインフラエンジニアの育成・教育、さらには評価において、どういったところにこだわりを持っているのか、詳しく伺いました。

インフラ未経験者の採用・育成を前提にした組織づくり

――はじめに馬場さんのこれまでのご経歴を簡単にお伺いできますか。

馬場俊彰氏（以下、「馬場」）：前職もインフラ関連の請負事業を展開している企業に所属していて、取締役兼CTOを務めていました。

インフラレイヤーのSIで、24/365のチームもいて、構築から運用支援までおこなっていました。わたしが入社した当時は、まだSREがない時代だったものの、かといって「インフラだけやっていればよい」という時代でもなくなってきた頃だったので、インフラレイヤーをコアスキルとして、お客様の運用フェーズを支援していました。

今日お話しするインフラエンジニアの育成については、前職での経験がメインになります。

――まずは、インフラエンジニアの採用についてお聞きします。流動性が少ない職種だと思いますが、特に即戦力となる経験者の採用はかなり苦労されているのではないでしょうか。

馬場：そうですね。前職では最初から、経験者採用はほとんど期待できないだろうと考えていましたので、早くから新卒や未経験者を採用して育成に力を入れていました。

――新卒や未経験者の方が入社された後は、どれくらいのレベルまでトレーニングされますか。

馬場：前職には24/365のチームがいて、業務でもある程度は手順化できるものを取り扱う前提だったので、まずは通常業務でトラブルを起こさないレベルの知識を身につけてもらっていました。たとえば、お客様とお話しするときに、問題なく会話が通じる程度というのも一つの基準です。

教育にはかなりコストをかけていて、時間制ではなくカリキュラムベースで、卒業できて初めて実務に入れるという仕組みで実施していました。だから早い人は早いけど、人によっては一年以上かかる場合もありましたね。

――やはり、入社してすぐに現場に入ってもらうのは難しいですか。

馬場：難しいというよりも、未経験者がすぐには対応できないレベルを企業のサービスレベルとして置いていました。会社としてのブランディングもありますからね。お客様からすると、素人っぽい人から電話がかかってきたら嫌ですよね。そうならないように、クオリティコントロールをしていました。

――カリキュラムを通じて、どのように見極めや育成をしていくのか、もう少し詳しく教えてください。

馬場：前提として、非常にハードなカリキュラムで、そもそも採用した人全員が通過できる想定ではないんです。通過できない人は、トレーニングの期間が伸びますし、いつまでも現場に入れません。厳しいと思われるかもしれませんが、たとえばすでに現場に出ているエンジニアたちが2年で学べた内容を3年かけても学べない人が、その先もこの仕事で活躍できるかというと、おそらくは無理ですよね。

カリキュラムには、お互いが「この仕事が合っているかどうか」を見極める側面もあります。

インフラエンジニアに見られる特性

――途中で脱落してしまう人が、つまずきやすいポイントなどはあるのでしょうか。

馬場：分野を問わずIT系エンジニアとしてのレベル感になってしまいますが、いわゆるエンジニア的な考え方や働き方に向いていない人や、「こんなに勉強しなければいけないのか、ちょっと無理だな」となってしまう人はどうしてもいますね。あとは障害対応の仕事がメインですから、障害の発生に対して必要以上にプレッシャーを感じてしまう人は合わないでしょう。

たとえば、お客様のサーバでトラブルが発生したときの一次対応、契約によっては二次対応までする場合もありますが、トラブルは本当に突然降ってくるんです。そこで慣れる人もいますが、どうしてもつらくて耐えられない人もいます。単純にメンタルが強い・弱いという話でもなく、合う・合わないに尽きると思います。

――トレーニングを終えて、現場に入った新人の方のスキルアップについてもお聞きしたいのですが、基本的には実務を通して引き続き学んでもらうという形でしょうか。それとも会社として、何か働きかけていたことはありましたか。

馬場：定番ですが、社内勉強会などはいろいろと実施していました。

――インフラエンジニアの場合、担当している範囲の特定の技術に偏ってしまいがちな印象があるのですが、勉強会などで交流をしてもらったりするのでしょうか。

馬場：これはわたし個人の好みでもありますが、交流したり他のチームと混ぜたりして見識を広げてもらうといったことは、あまり考えていませんでした。むしろ「とにかく好きなことをたくさんやってください」と言っていました。まずは興味のあるものに深く触れる。広げるにしても、そこから派生して広がっていくことがほとんどだと思います。

ただ、学習に関する雰囲気づくり、企業としての文化づくりには積極的に取り組んでいました。企業としても、早くからコミュニティベースの勉強会を主催していましたし、わたし自身も何冊か本を書いたりしています。

合わせて、折に触れて「エンジニアは、そうやって変化していくのが当たり前なんだよ、ずっと同じではだめなんだよ」といった話はよくしていましたし、そういったマインドや行動を評価するようにもしていましたね。

評価する際の注意点と求められる管理者の力量

――さきほど、評価について少し触れていましたが、インフラエンジニアの評価については、特にこんなところを評価するといった、他の職種とは異なるポイントがあったりするのでしょうか。

馬場：開発職とは異なり、新たな機能を作ったといった目立つ仕事ばかりではないので、細かいところにも目を配っていました。たとえば、お客様と信頼関係が結べているかどうかを重視していたり。前職はあまり規模の大きな会社ではなかったからできていたことかもしれませんが。

――そこは評価する側、マネジメントする側の力量が問われる部分でもありますよね。

馬場：そうですね。完璧で誰からも不満のない評価制度など存在しませんから、常に模索していくしかありませんし、評価する側の人徳が崩れたら終わりだと思っています。

そういう意味では、マインド面における「自分たちがどんなエンジニアの姿をよしとするか」をドキュメントにまとめて共有していました。

――「この基準に即して評価を決める」と明確にして、共有するのが大切なんですね。

馬場：そうだと思います。社員が20～40人くらいの段階までは、みんなわたしの背中を見て育ってくれていました。その場その場で、正しいと思われる姿を自分自身で見せてきましたから。ただ、組織が大きくなってくるとそれだけでは限界が出てきて、そうすると組織も少しずつ変質していってしまう。だからみんなに改めて共有するために、ドキュメント化をしました。

――評価でグレードをつけるときには、「これができているのにここは足りない」などと悩みませんでしたか。

馬場：それはありますよね。評価制度にも紆余曲折がありました。やはりみんなスキルやマインドには凹凸がありますから、足りない項目を許容する運用をしていた時期もありますし、逆に凹凸の一番下を評価基準としていた時期もあります。そこはもう模索していくしかありません。

あとは、やはり評価するマネジャーの力量にもよりますよね。マネジャーの力量、あるいは人徳が高ければ、凹凸が大きくても運用上の問題にはなりませんでした。ただ、人が増えたりマネジャーが変わったりすると、下限をその人の評価として適用しようという話になってきますよね。そのほうが運用としてはスムーズになりますから。ただ、そうするとどうしても尖った人は減ってしまいます。前職では、尖った人についてはスペシャリスト的な別の職位を作って、そちらを適用することもありました。

――生産性については、どのように測るのでしょうか。またチームとして、全体的な生産性の向上はマネジャーとして常に課題だと思うのですが、何か別の指標はあったりするのでしょうか。

馬場：個別の生産性を計るのはかなり難しいと思います。みんな指標が欲しくて、SLAやSLIなどに手を出してみたりするのですが、手段と目的が逆転してしまいやすいんですよね。SLAが上がったから良いとか、変わらないから悪いといった話になってしまいますから、評価の指標にしてしまうのは、あまりよいやり方ではないのだろうなと考えています。もちろん、評価の参考にするのはよいとは思いますが。

SREに関する本でも、「最初に、案件コードや稼働に対するプロジェクトコードのひもづけをやめるところから始めないとうまくいかない」といった話がよく出てきます。やり方やターゲット自体を変えないとうまく回っていかないでしょうね。

チームビルディングと組織拡大の難しさ

――次に、チームビルディングについてもお伺いします。前職ではどれくらいの規模のチームが多かったのでしょうか。

馬場：最大でも7人程度だったと思います。

継続的に携わる持ち案件みたいなものを、チームでいくつか担当してもらっていました。1人だけで案件を担当するとボトルネックになりやすいので、担当は必ず2人以上にしていましたね。

現職では、プロダクトオーナーやデベロッパーがチケットを切ってスタートするケースが多いです。ただ、たとえばモニタリング結果の定点観測などで、データトピックをチケットにしたりもします。あとは会話の流れで「これはやらなきゃいけなかったね」といったことも出てきますから、それらをまずはチケット化してから「アサインはどうしようか」と考えるケースもあります。スクラムのようなバックログを作ったり洗い出したりするタイミングを厳格においているわけではないですが、週次で優先順位を決めてやっています。

――前職での育成のお話からすると、組織を大きくするにはかなり時間がかかったと思いますが、やはり急拡大は難しいのでしょうか。

馬場：前職でのやり方では無理でしたね。だから「急拡大はできない」と判断していました。

急速に増やすのは無理だという前提で、毎年5～10人は増やせるようコツコツやっていました。それこそ育成に1、2年は必要としていましたので、そんなにたくさんの人を同時にトレーニングもできないですし、カリキュラムを卒業していくペースを様子見しながら採用をしていました。

――育成のコストを考えると失敗できないというか、たとえば育成に1年要して、結果うまくいかなかったりすると大変ですよね。

馬場：大変ですが、それが事業上の制約ですから、ある程度織り込み済みでもありました。リソースが不足している時期は、新規受注や営業をやめて、既存顧客の引き合いだけに絞って対応をするといった決断もしていました。

インフラエンジニアに多い特性と気をつけたいポイント

――ほかにチームの運営などで、これまでにぶつかった壁や大変だったポイントはありますか。

馬場：インフラエンジニアの特性として、ロールプレイングゲームで言えば支援職っぽい性格の人が多いと思うんです。誰かを助けたり、何かを支えたりといった仕事にやりがいを感じるタイプですね。

こういった人は献身的かつ協力的で非常によいのですが、逆に言うと自己犠牲的になりやすい。「あとは大丈夫です、やっておきます」が積み重なってしまいやすいんです。ギリギリまでアラートを上げずに耐えられてしまう人も多いので、個人に負荷がいきすぎないよう目を利かせていたつもりです。

もちろん人の役に立っている実感があれば、そんなにつらくはないという側面もあると思います。だから本当にマネジメントする側の手腕が問われますよ。業務内容的にメンバーたちは常にプレッシャーが高い状態にありますから、できる限り不満がない、よいコンディションでいてほしいんです。

あとは、さきほどから話している通り採用がとにかく大変なので、離職してほしくないというのもありました。なるべく長く、気持ちよく働き続けてもらいたいと思っていましたね。

――性格というか、その人の特性によるところもありそうです。個々に合わせたマネジメントが求められますね。

馬場：どうしても提供したいサービスの質を維持しようと思うと、それに従事する人材の育成コストも手間も非常にかかります。ただ、労働集約型の業務で、インフラエンジニアの数だけスケールをして売り上げを増やすこともできますが、そうしたいとは思いません。だからよいエンジニアがいてくれることには、それだけの価値があって、コストをかけてでもやる必要性を感じています。もし退職する人が出たとしてもよい関係でいたいですし、そこまで含めたケアをしていましたね。

――最後に、これからリーダーやマネジメントをしようという方に対して、メッセージをお願いします。

馬場：わたし自身は、とにかくメンバーをよく観察するようにしてます。リモートでオンラインのコミュニケーションになっても、やはり声のトーンや顔色には出ますから、よく見てよく聞くのが重要だと思っています。あとは、個々の状況や特性は異なりますから、ステレオタイプにあてはめたりはしない。「あなたはこんな属性で、こんな状況だからこうでしょう」といった話はしないようにしています。

また、わたしは役職でいえばCTOですが、今日はあまり技術の話はしませんでした。普段はもちろん技術的な業務もありますが、取締役でもあるので、事業全体のボトルネックやスケールファクターに注目しています。

みんなをリードしたり上から引っ張り上げるというよりは、誰かを支えたり、こぼれたところを拾ったりといった役割を意識しています。メンバーの業務からあふれた、その他全部を担当してメンバーが気持ちよく働ける環境を整えるのが、CTOとしての自分の仕事だと思っています。

――ありがとうございました。