社員インタビュー 2024.6.12

ALHには技術特化のエンジニアが沢山いることを知ってほしい

KOHEI

平均年齢28.6歳、若手社員が多い印象のALHですが、要職に就かず、20年近く技術を磨き続けているベテランエンジニアが何人もいることをご存じでしょうか？

今回はそのうちの1人であるYUSUKEさんに、これまでの経験やALHに居続ける理由など、たっぷりとお話を伺いました。

※エンジニア視点の質問をしてもらうために、助っ人としてインフラエンジニア歴5年目のKOTAさんにもご参加いただきました。KOTAさんの発言のみ青文字にしています。

「何を経験しなかったのかを把握しておく」
「古い技術が選ばれる理由を考えよう」
「今後の方向性は5年目くらいから見えてくる」
「ALHの案件を一覧で出せたら、かなりの惹きになるのに」

-本日はよろしくお願いいたします！まず最初にALH入社以前からお聞きします。

中高生の頃からPCに触るのが好きで、HPを自作して公開したり、ネットゲームに熱中したり……中華料理屋でアルバイトしながらPCばかりいじる生活が続き、気付いたら20歳が目前に迫っていました。

このままではまずいと思い、PCを使う仕事であるエンジニア職の求人を探したのです。フリーターでしたし、就職氷河期（2005年）ということもあって、就職活動は結構苦戦しました。

そんな中私を拾ってくれたのがALHの前身であるバリストライドでした。

KOTA：当時のエンジニアってどのようなイメージだったんですか？

ホリエモンが台頭してきて、IT系はうまくいけば稼げるという印象はあったよ。

ただ、まだ偏見も強くて、世間的にはPCをパチパチいじってお金をもらっている人というイメージもあったようです。私自身も言われたことがあるし。

-なるほど。労働時間も今よりかなり多かったとか？

そこは人や案件によると思います。ちなみに最初の案件は労働時間としてはとてもホワイトだったよ。

「何を経験しなかったのかを把握しておく」

-初めて参画した案件についてお聞きします。

案件の話の前に、今では考えられないことですが……。
当時私はスーツを持っていなかったので、内定後に初めての案件に行くことが決まったタイミングで、なんとスーツをいただきました。

KOTA：そんなことがあるんですね！ドラマのワンシーンみたい。

ありがたいことです。
いただいたスーツに身を包んで乗り込んだ初めての案件は、オペレーター業務でした。

「マシン室の温度管理」「映画のフィルムのような大きい電磁気テープの設置と取り外し＆受け渡し」「障害が起きたときに決まったところに連絡」などの業務からスタートしました。

慣れると余裕が出てくるので、記録作業の中で可能なところはVBAを学んで自動化してたけど、それでもちょっと暇でしたね……。

KOTA：自分だったら焦ってしまいそうです。

今のALHの社員たちなら皆そうだと思うよ。私の場合はまだ19歳だったし、他を知らなかったのでそこまで焦りはありませんでした。
ちなみにオペレーターを経験出来たことは、貴重な財産になったと思っています。

-それはなぜでしょうか？

システムは構築する期間より、運用していく期間の方が圧倒的に長いので、運用シーンをリアルに想像できると設計・構築をする上で武器になります。

でも、これから入社してくる子たちにオペレーター経験を勧めるかと言うと、そこは何年スパンで自分のキャリアを見るかによりますね。

30歳までに一人前になりたいという22歳の新人ならアリかも知れません。

でも3～5年スパンで考えているなら、構築から入ったほうがいいかも。

KOTA：すごく納得感があります。私も早く一人前になりたいと思ってスタートしたし、実際に構築案件から入ったのですが、オペ経験があれば視野が広がるなと思います。

そうだね。

オペレーター業務に限らず、何かを経験せずにキャリアを積んでいく場合は「何を経験していないか」を把握しておくことが大切だと思っています。

私も所々飛ばしているけど、何を飛ばしているかは分かっているので後からキャッチアップできるようにしています。

経験していない範囲や知らない範囲を把握しておきましょう。

KOTA：はい！

-続いて2案件目についてお聞きします。

ここで自動化の面白さを知りました。

Webサービスを設計構築する案件で最初はWin系の設計を担当していたのですが、一段落したタイミングでUNIX系も担当することになりました。
当時割と忙しかったので、色々なことを自動化してみたんですよ。
最初の案件でもVBAを使って自動化に挑戦していましたが、UNIXは何でも自動化できました。スクリプトを書くのが楽しくて。

KOTA：どんな作業を自動化したんですか？

一例を挙げると……認証基盤をつくったあとにデータ移行が控えていたんだけど、リリース直前まで移行チームが立ち上がっておらず、ある日いきなり担当に任命されてしまいました。

データベースAからデータベースBに変換するツールがないし、正しく移動しているかチェックする手段も決まっていない。このままだと目でチェックすることになりそうでした。

「これはスクリプトを書いて自動化しないと自分が困るな」と思って必死に書きましたね。

周りは皆経験豊富な方たちだったけど、実力のある人ほど忙しいので、自動化の対応ができずに漏れ溢れたタスクが散見されました。

自動化するにも一定の時間を割く必要があるけど、その時間を割く余裕がないという。

そういう漏れ溢れたタスクこそ自分が何とかしないとと思って、積極的に拾いに行ってました。

KOTA：さすがですね！ちなみに当時はシェルはあったんですか？

そりゃあったよ（笑）。
今と違ってネット検索ではなく本で学ぶ時代だったけどね。

シェル系のコマンド本だけで3～4冊買ってデスクに置きっぱなしにしていました。付箋だらけでしたよ。

KOTA：本いいですよね。最近は生成AIに作らせて微調整するだけでも使えちゃうから、便利な一方、そこまでお手軽でいいのかなと思ったり。

いいと思うよ！使えるものはどんどん使っていく。

ただ、AIに作らせてみると、違う方法のほうが効率が良いのに……と思うこともあるので、自分でチェックできる程度に学んだうえで生成AIを活用するのがベストじゃないかな。

「古い技術が選ばれる理由を考えよう」

-次の案件についてお聞きします。

約7年にわたり大手金融機関の案件に参画しました。

ここではかなり大規模なシステムを触ったこと、金融機関という独特な業界を担当したことで色々と気付きがありました。

最初は統合基盤とバックアップシステムの運用保守から入り、商用のUNIX系OSであるSolaris（Oracle）、AIX（IBM）を担当しました。

当時すでにLinuxが台頭していたのですが、信頼性や安定性を求められる所ではSolarisやAIXなどの商用UNIXが依然として多かったのです。

新しい技術でやればいいのにと考えたこともありましたが、金融機関なので仕方がありません。不具合があると国全体に影響を及ぼしてしまうサービスですから。

KOTA：モダンな開発環境で働きたいと思う方が古い環境の案件に配属になったら、どういう心持ちで業務に臨むべきだと思いますか？

まず、なぜ古い技術を評価するクライアントがいるのかを考えましょう。

インフラの代表的な例でいえば、AWSやAzureなどクラウドが流行っている今、なぜオンプレミスやVMを選ぶのか？ AWSだと困る部分は？嫌がられる部分は？損することは？などなど。

それこそ聞いたことがないかも知れないけど1950年代からある「COBOL」という言語は、そろそろなくなると言われ続けてきたけど、未だに何年かに一度はCOBOLエンジニアが必要になっている場面に遭遇します

COBOLが使えるエンジニアなんて滅多にいないから、案外扱えたら単価は高いかも知れません。だからと言ってCOBOL習得を勧めはしないけど、古い技術にもニーズはあります。

参画先は見つかるし、無駄にはならないってことを伝えたい。

クラウドとオンプレミスに話を戻すと、両方に詳しければ設計段階でどちらを採択するか、細かく検討できるようになります。
モダンな開発環境を追い求めるのもいいけど、それ以外も知っておくと、後々上流工程を担当する時に役に立ちますよ。

KOTA：わかります！私もVM案件を経験したことで検討の幅が拡がりました。
1つお聞きしたいのですが、YUSUKEさんみたいに実体験を通じて色々知っていくのが重要なことは理解する一方、短期間である程度視野を拡げるにはどうしたらいいですか？

私も自分でしっかりと触っていない技術なんて山ほどあるよ。

例えば、ブロックチェーンや生成AIなど色んな技術が出てくる中で、それらの概要だけでもおさえておけば、検討材料に入れることはできます。

クライアントとの打ち合わせで話題に上がった時に多少は議論できるし、意見も述べられる。

「おそらくこうだと思いますが、念のため確認しますね」って言えると信頼獲得につながりやすい。

KOTA：なるほど、参考になります。浅く広くでも知っておくことが大事ですね。

エンジニアになったばかりの子たちにはよく、「AWSの認定資格などだけじゃなくて、基本情報技術者試験・応用情報技術者試験もとったほうが良いよ」と伝えています。

OSやネットワーク、データベースに限らず幅広い知識を体系的に学べますから。

KOTAさんはとりましたか？

KOTA：基本情報は持ってます！応用は試験中に腹痛で抜け出してしまって不合格になってしまってそれっきりです……。でも勉強はしたので知識としては持っています（汗）。

勿体ないけど、知識として入っているなら良いと思います（笑）。

まとめると、若い子たちには資格試験等で体系的に学びつつ、案件先では目の前のタスクで扱う技術をしっかりと身に着けながら、その周辺知識も浅く広く拾って行ってほしいですね。

この先中堅～ベテランになっていく中で「自分はインフラエンジニアだからOSのことだけ知っていればいい」では通用しないときが来るんですよ。

例えば、「アプリケーションがどう動くか」や、「ネットワークやデータベースに関する基礎知識」などを知っている必要があるケースに遭遇することもあるでしょう。

設定レベルで細かく知っておく必要はないけど、浅く広く拾っていく習慣は早くからつけておきましょう。

KOTA：意識して拾っていきたいと思います！他にも若手の方に向けたアドバイスはありますか？

新しい案件に参画する若手には、以下2つのアドバイスを贈っています。
「分からない言葉をなくす」「質問できるパスを確保する」

1つ目は分からない言葉を目や耳にしたら、その都度調べて潰していきましょうということです。
2つ目は、自社他社を問わず、気軽に質問できる相手を見つけておきましょうということです。

そういう相手がいないと辛くて続かなくなってしまうので、意識して見つけに行ったほうが良いと思います。

「今後の方向性は5年目くらいから見えてくる」

-経験を積んだ方のキャリアとしてPL、PMと管理する立場を歩んでいく方と、マネジメントはせず技術を追求していく方がいますよね。それぞれの違いをどう捉えていますか？

PMは管理能力が求められるポジションです。進捗が遅れているときに原因を見極めて対処する力、人員管理をする力、あるいはクライアントと折衝して話をまとめる力など、技術とは違う能力が必要です。

規模次第では私もやってできないことはないと思いますが、あまりやりたいとは思わないですね。自分は技術屋だと思っているので。

逆にPMの立場に専念するようになって長い方だと、もう長いことコードは書いていないという方もいます。

向き不向きややりたいことの違いで分かれていくと思います。

-ちなみに、純粋に年収を追い求めるならどちらのほうが？

確実にPMでしょう。数億、数十億のプロジェクトを率いるPMとなれば相当な年収のポジションになると思います。

ただ、大規模なプロジェクトのPMは正社員でないと任命されないので、あくまでもサラリーマンとしての年収のレンジ内になります。

フリーランスの方が大規模なプロジェクトのPMになることはまずありません。個人では責任を負えませんから。

とはいえ、どちらも突き詰めればかなりの高年収が見込めるので、「どっちのほうがより稼げるか」で選ばずとも、収入に困ることはないと思いますよ。

-自分がどちらの道を歩んでいくかの見極めは、いつどんなきっかけでするものですか？

KOTA：最近そこについて考える機会があったので先に私の意見からいいですか。
おかえり人事制度※で人材開発部に期間限定で移動した際に研修コーチを担当させてもらい、育成や管理が好きだし得意そうだなと感じたので、私はマネジメント路線で行こうと思っています。案件先でもPLを務めさせてもらってます。
ただ、ALH全体でみると、技術を磨いていきたいと言っている人のほうが今のところ多い印象です。

※おかえり人事制度：今いる部署に戻れる前提で一定期間違う部署での勤務経験が積める制度

なるほどね。KOTAさんに関しては、そうなのかも知れない。

ただ2～3年目の若手が今時点で言っている内容はまだまだ変動的なモノだと思います。

先ほどから視野を広げようと言ってきましたが、自分が参画している案件以外に目を向けるのはかなり難しいので、どうしたって視野は狭くなってしまうものです。

自分が参画している案件に関しても、まだシステム全体を管理している立場の人と話す機会は少ないだろうから、自分に降りてくる限られた範囲の情報だけで想像を膨らませるのは難しい。

3年目くらいで、案件先では何かしらのリーダーポジション、社内では部下や後輩を持って、他部署や他チームともやりとりをするようになって、プロジェクトの方向性を決める人たちとも接点を持ち始めて……技術者としては運用、構築、設計など複数のフェーズを経験して、5年目くらいから今後の方向性を考え始めたらいいと思います。

多分最初の数年は、そのときの経験によって頻繁に考えが変わる段階だと思いますよ。