インフラエンジニアへの挑戦は今からでも遅くない｜果敢にトライしてスピーディーな成長をつかめ

エンジニアを目指すのに「早い・遅い」の意識は必要ない

ITエンジニアの世界に興味を持つようになったそもそものきっかけは、3歳のときにアップル製品好きの父親が買ってきた「AppleⅡ」というコンピューターとの出会いでした。古いモデルでマウスもないようなコンピューターでしたが、それでインベーダーゲームをよくしていたのを覚えています。

当時はかなり高価だったコンピューターを子どもに自由に触れさせてくれた。そんな家庭環境がITの世界に興味を持つきっかけを与えてくれました。小学校入学前からプログラミングなどという意識はないけれど、マニュアルに書いてあったコマンドを意味もわからず試したりして遊んでいましたね。

中学校、高校でも友人と一緒にゲームを作ってばかりいました。高校2年の夏には、中学時代の同級生たちと4人で、シミュレーションゲームを作るソフトウェアハウスの会社を作りました。もちろん高校生の思いつきですから、すぐに会社はたたむことになりましたが。

そんな高校時代でしたから、大学進学も何かを勉強するためというよりも、当時コンピューター好きの猛者たちが集まる大学サークルとして有名だった京大マイコンクラブ（KMC）に入りたくて、京都大学を目指しました。KMCに入るのが目的で、学部は何でも良かったので一番入試のハードルが低いと思われた農学部を受験し、無事入学することができました。

在学中にはアルバイト先のゲーム開発会社で手掛けたネットワークゲームがヒットして、日本初の大規模多人数による同時対戦型のRPGとしても注目されました。

学生時代からそんな実績が残せたのは、私が小さな頃からゲームを自作したりプログラミングができたり、コンピューターに早くからなじんできたことがまったく関係ないとは言いません。しかしエンジニアとしての能力や優劣に関しては、始めた時期が早いとか遅いとかはあまり関係ないというのが実感です。実際のところ大学時代にKMCに入部して初めてプログラミングを覚えたという同級生がいましたが、周りも驚かされるようなすごい勢いで知識を吸収していき、いまでは大企業のAI研究のエースとして活躍しています。

エンジニアとして活躍できるかはいつ始めるかではなく適性が大きく影響するので、エンジニアの力を磨くのに大人になってからでは遅すぎるといった意識は必要ないと思います。

「二兎を追うものは一兎をも得ず」の失敗を糧に技術に徹することを決意

私にとってのターニングポイントは、ネットワークゲーム開発のためのソフトウェアなどを手掛けるコミュニティーエンジンという会社を立ち上げて経営に携わっていた時代です。2000年に起業し、エンジニアとしてプログラムを書いたりする一方で社長業もこなしていましたが、そのうちに社長業に専念してほしいと周りからも言われるようになりました。 

それでプログラミングから手を引き社長業に徹するようにしました。それが2006年のことです。ところがプログラムのコードを書かなくなって4年、気付けば現場の状況も製品のことも詳細が把握ができなくなっていました。その結果プロジェクトが回らなくなり、人の心も離れ、2011年には会社をたたむことになりました。

技術の会社なのに、技術の詳細な中身がわからないのでは社長は務まりません。少なくとも私には1人2役は無理だと悟りました。それ以降は、自分は技術に徹して、技術でビジネスを支えるような立場で仕事をしていこうと決めたわけです。これが大きなターニングポイントでしたね。

ですからmonoAI technologyからCTOに誘われた際も、マネジメントにかかわることになるため、初めのうちはずっと断っていました。しかし最終的には安田京人取締役がCTOのマネジメント面を肩代わりしてくれることになり、CTOを引き受けることになりました。

フルスタック的な万能性がより求められる。領域の幅の広さが活躍につながる

エンジニアとしてのキャリアを振り返ると、最初はゲームの実装にかかわるフロントエンドの開発から入って、プログラミングや設計といったバックエンドの開発やアプリ開発、通信のためのサーバー設計・運用やネットワーク構築といったインフラ領域まで、幅広く手掛けてきました。

軽々しくフルスタックという言葉は使えませんが、1人で何役もこなせる万能性を持ったエンジニアとしての能力を磨いてこられたのは私の強みになっています。考えれば当たり前なのですが、コンテンツを配信するサーバーに不具合が生じた場合には、ウェブブラウザーについて理解していなければ問題解決には至りません。つまりサーバーもブラウザーも両方ともわかるインフラエンジニアが必要とされるわけです。

もちろん複数のレイヤーをものにするのは、すぐには無理です。私もゲーム開発ツール「Unity」を使いこなすのに10年、ネットワークに精通するのに10年、ウェブブラウザに10年といった時間をかけて一つひとつ積み重ねてきました。

フルスタックエンジニアとしてすべての領域について対応できることに越したことはありませんが、全部自分一人でやる必要はないとも思います。ただ、フルスタックとは言わないまでも、それぞれの領域について何がわからないのかわかるなど複数のレイヤーで目が効くようになれば、エンジニアとしての活躍の場は広がります。

社内でも複数のレイヤーに通じたエンジニアを育てるためにレクチャーを準備しています。たとえば「Unity」に通じたエンジニアには、ネットワークやウェブブラウザの動きや働き、ほかのツールの使い方などを理解してもらうのが狙いです。

思いついたら「とにかくやってみよう」がエンジニアへの第一歩

エンジニアの仕事で最も重要な点は、とにかくやってみること。作ったらすぐに世に出し、評価にさらされることを避けない姿勢です。世に出す前に社内で評価を受けるのでも良いのですが、とにかく自分以外の目で見て触れてもらってフィードバックを受ける。そのフィードバックが学びのきっかけであり成長の原動力になるからです。

新しいものをリリースすれば、バグの存在や使い勝手の悪さを指摘されるのは当たり前。自分の知識が及ばない専門的観点からの指摘もあります。それがあるからこそ学べるし成長できるのです。

抜きん出て優秀なエンジニアの性格や才能はさまざまですが、一つはっきりとした共通点があります。それは、早く学び早く成長するために必要なことは、とにかく成果物をすぐさま世に問う姿勢だと承知している点です。恥ずかしいとか、間違えたくないなどと考えている暇はない。すぐにフィードバックをもらい改善し解決し前へ進む。その覚悟があるエンジニアはみな極めて優秀です。

それをやればやるほど入ってくる情報量は多くなりますし、これが10年、20年と続けば、やらないエンジニアとの差はとんでもなく大きなものになるでしょう。

私が作った成果物も、「バグがある」「使いづらい」とクレームを言われることもあります。でも言われれば言われるほどアドレナリンが出てやる気が湧き、脳が活性化します。文字通り仕事の原動力になっています。

国民的な人気シリーズとなっているRPGの開発に携わったことがありますが、完成して世に出すまでは絶対秘密のプロジェクトになるので、家族にも話せないし一言も口にできない精神的な重圧がありタフでなくては仕事になりません。そのタフネスを発揮できるのは、それが貴重なフィードバックにつながることを身に沁みてわかっているからです。

エンジニアに求められるのは、「何も起きないように」することではなく「エンジニアは何かを起こすのが仕事」であると自覚することなのではないでしょうか。

人に頼ることをためらわずに。「わからない」と言える勇気が成長を加速させる

行き詰ったときは、人に頼る。頼る勇気は、企業で働くエンジニアには必要です。企業の中には優秀な人材が、同僚であれ先輩や上司であれ必ずいるのですから頼らない手はないですし、力を合わせるべきだと思います。それが企業という組織の存在価値でもあります。

その出発点となるのが「わからないこと」を認める姿勢です。若い人ほど、わからないことをわからないと言い出せない。それが後々に大問題につながることもあります。会議の場ではなおさら言い出しづらいでしょうね。

私はCTOという肩書であっても「技術的にわからないこと」を「わからない」と言います。なぜならインフラについてであろうとネットワークでもアプリでもプログラム言語でも、全部を完璧に理解することなど誰にも不可能だし、わからないことが存在して当たり前だからです。

しかしわからないことの存在に気付ければ、そこから新たな知識を得られます。どこかに自分のわかっていない穴があると自覚するのが最も重要なこと。必ずどこかに自分の知らない事柄が眠っています。

たとえば最もポピュラーなプログラミング言語であるJavaにだって、何十年もプログラムを書いてきた私が知らない、私にとっての穴が存在するはず。だから「そんなことも知らないのか」と思われたとしても気になりません。私はわからないことは最速で「わからない」といえるように常に心掛けてきました。若い人たちにも、これからインフラエンジニアを目指す人にも、「わからない」といえる姿勢を強く意識してもらいたいと願っています。

全部わかったと考えてしまった時点で成長は終わりです。エンジニアの知識やスキルの習得には一定の学習曲線があります。何も知らないゼロからスタートし、初めのうちは学習曲線が急カーブで上昇します。何でもできるような気もしてくるでしょう。

ところが中級者になると今度は、それまで見えていなかった難しさに気付き自信を喪失し成長も止まる。学習曲線も上向きません。そこからまた地道に勉強を重ねていくと、再び自信が芽生え「自分はちょっとできるぞ」となる。そうやってカーブの角度を変えながらエンジニアとして成長していくのです。

インフラもソフトウェア化する流れは間違いない

現在30～50代のインフラエンジニアは、自分でPCを組み立てたり、自分でパーツを買ってきてカスタマイズしたり、ケーブルを自分でハンダ付けしたりが当たり前だった人も多いです。キーボードやマウス、モニターとPC本体の連携を通じて、ネットワークとかインフラの概念を感覚的に把握する前提もありました。しかしスマホが一般化して以降に育った世代はインフラ経験がまったくない世代です。

その意味ではインフラエンジニアについてピンとこない面があるかもしれません。一方でインフラエンジニアのあり方も変化しています。クラウド化が進み、インフラも純粋なソフトウェアに近づき仮想化されたリソースによって働く形になりつつあります。

つまりインフラエンジニアもソフトウェアを動かすコードを書けなくては務まらない面が増えているわけです。そういう時代のインフラエンジニアだからこそ、フルスタックとは言わないまでも、複数領域に目がきく幅広い能力が余計に求められていくようになると感じています。

医者とインフラエンジニアのやりがいに共通点

インフラエンジニアのやりがいは、医者のそれに近いものだと思います。うまく動かなかったシステムが、インフラエンジニアがひとひねりするだけでスムーズに動き出す。あるいはサーバーを立てれば、そこに新たな子どもが生まれたようなもので、目に見える形で結果が現れます。

だからこそ、「病気が治りました」や「無事に子どもが産まれました」と医者が感謝されるのと同じように、インフラエンジニアも具体的な感謝をされて喜ばれる。だからインフラエンジニアのやりがいは医者に近いものだという気がします。

そしてダイナミックな仕事に携われるのもインフラエンジニアの魅力です。たとえばサーバーの移設は大変ですが、本当にダイナミックですし、やり遂げた実感と大きな満足感を得られる仕事だといえます。