
CCNAの合格点は? 試験改定後の傾向や勉強方法を解説
2022.04.27
INTERVIEW 特別インタビュー
特別インタビュー
Masao Takeda・大学卒業後、コベルコシステムに入社。開発業務に従事する。その後、創業メンバーとしてフューチャースピリッツの起業に参画し、レンタルサーバ事業や電子決済事業、SaaS(サーズ)事業を推進。12年を経て、ラクスに入社。ITインフラ、運用・保守、SRE(サイト・リライアビリティ・エンジニアリング/サイト信頼性工学)の分野で、責任者としてプロダクトグロースを推進する。2022年にマーケティングツール「MicoCloud(ミコクラウド)」の企画・開発・販売を手がけるMicoworksに入社。以降、現職
PCに初めて触れたのは、ガンダムなどのロボットに憧れていた小学生の頃。父親にファミコンをねだったところ、「こっちのほうがいいんじゃない?」とPCを買い与えてくれたのがきっかけです。
当時はプログラミングという言葉すら知りませんでしたが、自分でマニュアルを読みながら独学でPCに慣れ親しんでいきました。高校時代になると10万円単位の装備も購入し、我流で性能アップを楽しんでいましたね。そのまま迷いなく情報系の学部に進学し、「PC関係の仕事に携わりたい」と思うようになりました。
最初の就職活動では、エンジニアとして働けるところを探しました。地元が京都なので関西で働きたい思いが強く、「関西に本社がある」「人事の人がおもしろい」という基準で1社目を選びました。
それが、神戸製鋼系列のSIer(システムインテグレーター)であるコベルコシステムです。2年半ほど開発業務を経験し、開発の流れや技術は身に付きましたが、次第に「上司が指定する技術で、クライアントがつくりたいものをつくるのは、自分のやりたいことと違う」という思いが募っていきました。
その頃、登場したのが、OSS(オーエスエス)やLinux(リナックス)などのオープンソフトの技術です。若い人は想像ができないかもしれませんが、当時、多くの会社では何百万円というお金をかけてファクトリーオートメーションのソフトウェアを作っていました。そうしたなかで、ほぼ無料で使える優れた技術が出てきたことに感銘を受けたのです。「品質が上がれば、絶対にこちらの技術が使われるようになるに違いない。自分もこの新しい技術に振り切ったほうがいいのではないか」そう予見し、新しい場所に身を置いて技術を身につけたいと思い、転職を決めました。
とはいえ当時はまだITベンチャーも少ない時代。この技術に携わることができる転職先は見つけられず、一旦は京都の自宅に帰りました。ネット掲示板で「OSSやLINUXをやりたい」という仲間を探し、同じ志を持った大阪大学の学生起業家と出会えたことで、3名でレンタルサーバの事業をスタートさせました。
その3名の中で私が技術責任者を一手に担うことに。サーバー管理を担当するなかで、必要に駆られてインフラエンジニアとしてのキャリアがスタートしました。ここが最初のターニングポイントです。
サーバやネットワークの知識は、英文資料を読み漁りながら独学で勉強しました。大学の授業で基本的な知識は学んでいましたが、実践的なスキルはまったくなかったからです。
レンタルサーバー事業事態は幸いにも時流を捉えることができ、すぐに代理店を通じて毎月50〜100件ほどの依頼を獲得できる状況に。会社もどんどん大きくなっていきました。
とはいえすぐに高額の設備投資ができるわけではなく、システムダウンする回数もかなり多かったので、24時間365日体制で障害対応に奔走していましたね。1〜2年間はほぼひとりで対応していたのでかなり大変でしたが、おかげでトラブル時の原因究明や問題解決の力は飛躍的に上がりました。
大きい会社を辞めてベンチャーを立ち上げる以上、高い目標を持っていたほうが頑張れるだろうと考え、「20代で1,000万円稼げるエンジニアになる!」と決めていたこともモチベーションになったように思います。28歳でその目標を達成できました。
次なる転機が訪れたのは、起業して12年目のことです。数年前にクラウドが登場し、レンタルサーバ事業が頭打ちの状況になってきていたので、電子決済事業やSaaS事業なども新たに立ち上げ、3つの事業柱を確立していました。そのなかで「これからの時代、SaaSは絶対に伸びる」と手応えを感じ、SaaSをメイン事業とする企業で挑戦してみたいという思いが次第に募り、自分は違う道を進もうと決めました。
「SaaSをやれる関西の会社」という条件で探したところ、最初にヒットしたのが3社目となるラクスです。取締役の2人に会って話したとき、「なんて優秀な人たちだ、この人たちと一緒に仕事がしたい」と直感的に感じたので、他社は見ずに決めました。収入は半分になるものの、これから伸びる分野だと確信を持っていましたし、過去の経験から「自分が頑張れば、お金はどうにでもなる」と思っていたので、ためらいはありませんでした。
ラクスは自己資金で経営している会社だったので、インフラ領域でも利益や費用対効果の最大化を図ることがもとめられました。それまであまり意識していなかった「目的に対して、技術的なコストをどうかけるか」という目線を養えたことは、同社で得られた財産ですね。起業時に「いずれ必要になるかも」と考えて簿記3級を取得していたのですが、その知識も初めて役に立ちました。
コスト意識を持てるインフラエンジニアはクライアントに喜ばれるので、どんな会社でも評価されると思います。今主流となっているクラウドサービス「AWS(アマゾン ウェブ サービス)」もサービスを消費した分だけ換算される従量課金制。無駄な使い方をしていると、あっという間にコストは膨らんでしまいます。
また同社では、「大きなビジョンを掲げて、高品質なインフラを作り上げる」というチャレンジも経験できました。
入社時点ではネットワークに問題が多かったので、全面的に入れ替えることを決め、1〜2年をかけて一から作り直していきました。やりたかった仮想化技術も取り入れたのですが、「将来こういうことをやっていくので、これくらいコストをかける。まずはこれをやらせてくれ」と事前に経営層との合意形成もしっかり図りました。計画通りにいかないフェーズも何度かありましたが、最初に大きな風呂敷を広げておくと着地点をつくりやすいです。
入社時の予想通り、事業は順調に成長し、上層部は東京拠点に移っていきました。私も呼ばれたのですが、地元から長く離れる考えはなかったので、「そのうち関西に帰ります」と宣言しての上京でした(笑)。
4年間ほど東京で働きましたが、インフラ領域を任せられる後輩が育ち、ちょうど良い頃合いだと考え、次の道に進むことに。「自分も外に出て最後のベンチャーに入って再び挑戦しよう」と決めました。
キャリア4社目では、3つの条件が揃っている会社を探しました。当社Micoworksを知ったときには、「ここだ、見つかった!」と興奮しましたね。自分を必要としてくれていると感じられたこともあり、入社を決意。
その3つの条件とは、「これから伸びるビジネスをやっていること」「ロジカルに考える風土があり、PDCAを粘り強く回していること」「トップの熱量があること」です。インフラエンジニアとしてベンチャー企業に入るならば、この3点を重視することをおすすめします。
伸びるビジネスをやっているかが重要な理由は、ビジネスが伸びない状況では、技術的なチャレンジに制限がかかるからです。私自身は幸い経験がないですが、同業者から「ビジネスの先行きが怪しくなり、技術領域への投資が止まった」「保守しかやらせてもらえなくなった」といった話は比較的よく耳にします。
ビジネスが伸びている会社であれば、その成長過程においてインフラ領域でもいろいろなチャレンジができます。待ちの姿勢ではなく、自分から「これをやると、これだけ効果出せるんで!」とアピールして技術投資を引き出していく姿勢があると、よりベターです。それを繰り返していれば、優秀なインフラエンジニアになれると思います。
ただし、どんなに事業の目の付け所が良くても、会社の風土としてロジカルに考えながらPDCAを回し続ける胆力がなければ、ビジネスを成長させていくことはできません。
加えてベンチャーの場合、トップの熱量と事業の成功は、ある程度の相関関係があると感じます。トップに熱量がなければ人は付いてこないので、社長の本気度なども入社前に確かめておくのがおすすめです。仮に社長が直感型の人物でも、ロジカルな経営層が脇をしっかり固めていれば、良いバランスの会社だと私は判断します。
私が思うインフラエンジニアの魅力は、システムの上位から下位まですべての層を知っている存在になれること。開発側からはブラックボックスに見えているけれど、自分の目にはホワイトボックスでちゃんと見えている、という場面をたくさん経験してきました。不具合時に「どこで何が起こっているか」のアタリを迅速につけられたときに、この仕事のおもしろみを実感します。
このおもしろさを感じられるようになるには、システム全体の仕組みについて知らなければなりません。理解を深めるほど、問題が発生したときの原因特定の精度やスピードが上がってくるのを体感できると思います。
100か所を調査しなければ解決できないような状況でも、サーバー関連やネットワークを真に理解しているインフラエンジニアが1人いれば、5〜6か所の確認で済む、なんてことも決して大げさな表現ではありません。チームの生産性を何十倍も向上させることができるので、どの会社に行っても重宝される希少性の高い存在になることができます。
「グレーな領域を巻き取り、どんどん支配下に置いていく」という意識を持つのもおすすめです。
開発とインフラの領域は、明確に棲み分けがされているわけではありません。実案件では、両者ともがわかっておいたほうがいいグレーな領域が存在します。どっちが責任を持つの? という状況になったときに、「ここは自分がやります!」とどんどん巻き取っていっていけば、知識が身に付き、そのシステムに対する影響力も大きくしていくことができます。陣取り合戦のようなイメージを持ち、率先してわかる範囲を広げていきましょう。
併せて、「問題が発生する前に要因をつぶしておく」という意識も高めていくと良いと思います。クライアントがそのシステムをどのような使い方をしているのか、いつどの程度サーバー に負荷がかかるのかを詳細に把握し、土日・深夜の動きを含めて負荷のコントロールや分析・予測をおこない、あらかじめ不具合を潰しておく。「あの人が入ってくれると安定する、トラブルが少ない」という評価は、そのままインフラエンジニアとしての市場価値につながります。
これからのキャリアで成し遂げたいビジョンは、「インフラエンジニアが一番ラクだよね」と言われるような世界観を創り出すこと。以前、開発の人たちをチームに誘ったところ、「しんどいからイヤだ」と複数人から断られたことがあり悔しかったので(笑)、絶対にこの状況を変えようと思っています。
クラウドが隆盛になり、ネットワーク・サーバなどの下位層の作業がほぼなくなったことで、昔に比べれば業務内容が変化してきていますが今後いっそうの半自動化や高度化を図り、「どれだけ手作業をなくせるか」ということを追求していきたいです。
一方で、育成においては「下位層のこともわかっているエンジニアに育ててあげたい」という思いも強く持っています。クラウドの時代になったことで、 インフラやネットワークがわかるエンジニアはどんどん減っています。だからこそ「インフラ・サーバを理解しつつ、アプリケーションが動く環境も整えられる」という両方の問題解決ができる人材は、希少性が高くなっているためです。
情報セキュリティのリスクマネジメントという観点からも、「インフラ基盤をきっちり整備し、運用体制を構築できる」というスキルは重要度が高まっています。クライアントの大事な個人情報を守れる存在になれば、どこへ行っても重宝されることでしょう。
また、先々開発エンジニアを目指すにしても、「どういう基盤でサービスが動くのか」を理解していることは強みになります。開発は「いかに品質高いものを早く作れるか」が重視されるポジションですが、基盤にも限界があることを頭に入れながら作っていないと、リリース後にトラブルの多いシステムになりやすいです。
そういった意味では、どんなエンジニアもインフラ領域を学んでおいて絶対に損はないと思いますね。個人的には「まずはインフラ領域を3年やって、そこからアプリケーション開発やセキュリティなどに広げていく」というキャリアを推奨します。
若い人にとって「まずは3年」というのが簡単ではないことも理解しているつもりです。私も最初の会社を2年半で辞めた人間ですので(笑)。
それでも「3年かけて慎重に育てよう」と考えている理由は、インフラ領域は責任が大きいので、経験の浅い段階で大事故を起こしてトラウマを抱えて欲しくない、という思いからです。とはいえトラブルを経験しないと大きく成長はできないので、私のチームでは、テスト環境でトラブルをシミュレーションして解決する経験を積む、という育成をしています。
インフラは広くて深い領域なので、勉強は計画的に進めていきましょう。環境は作ってあげられますが、最終的にモチベーションを上げて頑張っていくのは自分自身。「3年後こうなっていよう」というイメージを持ちながら、着実に知識を積み上げていくのがおすすめです。
取材・執筆:外山ゆひら
2022.04.27
2022.01.24
2022.01.12
2020.09.09
2020.07.03
2020.06.19
2020.06.11
2020.06.04