2023.08.31

ベテランエンジニアとのタッグで、若手エンジニアや組織としてのスピード成長を実現【エンジニア:前編】

ベテランエンジニアとのタッグで、若手エンジニアや組織としてのスピード成長を実現【エンジニア:前編】

 

 リンクエッジのエンジニアチームでは、他業種からの転職者や新卒メンバーも含めた若手から経験豊富なベテランまで、さまざまなエンジニアが在籍しています。そんな多様なメンバーの活躍と組織の成長の背景には、外部パートナーとのタッグによる取り組みとその成果がありました。


今回は、パートナーとして伴走いただいている株式会社スタートアップテクノロジー 松井様とエンジニアチームの飯田さんにインタビュー。その内容を前半・後半に分けてご紹介します!


まず前編は、エンジニアチームにおける協業の様子と、両社のタッグによって完遂した「インフラ移行プロジェクト」について話を聞きました。






――お二人の自己紹介をお願いします!

 

松井:株式会社スタートアップテクノロジー(以下、スタテク)開発部の松井です。自動車設備にまつわるエンジニアリングを経験した後、学生時代にプログラミングを学んでいた経験を活かしてキャリアチェンジし、以来ITエンジニアとしてキャリアを歩んできました。


スタテクに入って3年ほどで、現在はテックリードとしてお客様の開発や開発組織づくりを横断的にご支援したり、プログラミングスクール『RUNTEQ』の運営サポートとしてイベントでの登壇やコンテンツ作成のお手伝いを行ったりしています。




飯田:リンクエッジ エンジニアチームの飯田です。金融機関で4年間働いた後にエンジニアにキャリアチェンジし、今年で3年目になります。






パートナーの力を借りながら、若手エンジニアが価値発揮し成長できる環境づくりを

 

――リンクエッジのエンジニアチームと松井さんとの協業は、どのようなきっかけからスタートしたのですか?

 

飯田:リンクエッジには私含め若手エンジニアが多いため、エンジニアリング組織を成長させていく過程を知見の豊富なスタテクさんにご支援いただいてきました。




松井:スタテクとしては、私が入社する以前から長く伴走させていただいています。私は入社して半年ほどのタイミングでアサインされ、ご一緒することになりました。初めはWebアプリケーションのいわゆるプログラミングの部分を、現在は私自身の専門領域であるAWSを中心とするインフラ領域を主に担当しています。


松井 英俊:株式会社スタートアップテクノロジー 開発部 テックリード。大手製造業や創業期のスタートアップにて幅広い職種を経験し、2017年から AWS を活用した Web 開発に従事。2021年より現社に所属し、クライアントに対する開発支援や組織づくりを支援する他、同社が運営するプログラミングスクール「RUNTEQ」のイベント登壇やコンテンツ制作にも関わる。早期からサーバーレスアーキテクチャに着目し、技術記事の公開やコミュニティイベント登壇、シビックテックなどを通じて AWS を活用したサーバーレスアーキテクチャの認知活動を行う。2021年国内2人目のAWS Serverless Hero受賞。




――松井さんとリンクエッジのメンバーは、それぞれどのような役割を担われているのですか?開発体制や協業の様子について教えてください。

 

松井:この先もずっと伴走し続けるのではなく、しっかりとした体制を築いていずれご卒業いただくことをビジョンとしているため、「難易度の高い部分は私が、そうでない部分はリンクエッジさんが担当する」といったサポートの仕方や明確な役割分担はしていません。


リンクエッジのメンバーに開発をお願いしてこちらでレビューを行ったり、反対に私の方で手を動かし、皆さんにレビューしていただきながら技術的なご説明をしたり、柔軟に調整しながら進めています。




飯田:外部の方に支援や指導に入ってもらっているというよりは、一つのチームとして一緒に取り組ませていただいている感覚ですね。






――現在はエンジニアチームとしてどのような取り組みを進めているのですか?

 

飯田:主に取り組んでいるのは、以下3つです。

1. 自社の成果報酬型広告ASPサービス『Link-AG』の開発と運用保守
2. 新規事業のシステム設計・開発
3. 1.2のベースとなるインフラの構築と運用保守

インターネット広告業界では、変化が早く取り巻く状況や広告媒体が次々と変化していくため、それらをいち早くキャッチアップしてスピーディに開発を進めていくことが求められます。


 またそれだけでなく「Link-AGとは別軸でここにもチャンスがあるんじゃないか」といった新たなアイディアについて、ビジネスサイドと一緒に実現に向けて動いたり、土台となるインフラ部分を整えたりと、エンジニアチームで幅広い領域をカバーしています。


飯田 恭子:大手損害保険会社の東京海上日動火災保険株式会社から異業種ジョブチェンジを試み、2020年にリンクエッジへ。入社後はアプリケーションの新規開発を担当し、現在はインフラの構築・運用保守にも携わっている。※前回のインタビューはこちら






可用性や運用コストなどの課題を改善すべく、「インフラ移行プロジェクト」が始動

 

――今回エンジニアチームでインフラ領域におけるサービス移行を完了されたとのことですが、これはどのようなプロジェクトだったのでしょうか?改めてプロジェクト概要や始動背景を教えてください。

 

飯田:元々Link-AGはAWSの『EC2』を中心としたサーバー構成だったのですが、メンテナンスや有事の際の緊急対応を私たちエンジニア自身で行わなければいけなかったり、アクセスの集中によってサーバー負荷が高くなってしまったりと、さまざまな課題が生じていました。


これらを解決するために、AWSの『ECS』というマネージド型のコンテナオーケストレーションサービスを中心とした構成に移行しようと立ち上がったのが今回のプロジェクトです。


 また、新たに『AWS CDK(※)』を用い、TypeScriptなどのプログラミング言語でインフラリソースをプロビジョニングすることにも挑戦しました。


(※)主要なプログラミング言語を使ってAWS上のリソースを定義できるフレームワーク




松井:ECSなら、私たちは設定したい部分のみ設定すればよく、あとはよしなにAWSがサーバーの面倒を見てくれるようになります。これに移行することで管理コストを抑えて開発体験をよりよいものにし、事業貢献につなげていきたいなと。そんな思いで、エンジニアチームとして1年間このプロジェクトに取り組んできました。






――飯田さんはどのような背景でこのプロジェクトにアサインされたのですか?

 

飯田:アサインされたのは、アプリケーション側の開発を1年ほど経験し、Link-AGのシステムの仕様を理解できるようになってきた頃のことでした。プロジェクトとしては比較的難しい内容ではありますが、将来のことを考えて、私のような経験の浅いメンバーも育成していこうという意図でアサインしていただいたのだと認識しています。


エンジニアになって2年目でアプリケーション開発だけでなくインフラの設計・構築にまで領域を広げられるとは思っていなかったので、「若手でも自分次第でここまでやらせてもらえる環境」というのは、当社のエンジニアチームの魅力の一つだと思います。






――移行はどのように進められたのでしょうか?

 

松井:まず従来のアーキテクチャは「オンプレでも再現できるような環境をシンプルにクラウドにリフトした」というイメージのものです。プロジェクトでは、これを『ECS』を使ってクラウドのメリットを活かせるような形にシフトし最適化していきました。


この作業はアプリケーション側にも影響が及び調整が必要になるため、同じAWSのサービス同士の移行とはいえとても難しいものです。


 そのため、タスクを切り出して飯田さんにお渡ししつつ、AWSサービス等の仕様を深く理解していないと難しい部分などは私が直接作業をさせてもらいました。前段でお伝えしたように、お互いにレビューし合う中で「ここはこのような意図でこの設定にしています」などと解説したり、勉強会でコードを展開したりしながら、チーム内で知識の濃淡がなくなるよう意識して進めていきました。







将来を見据えた適切な采配とフォローアップで、短期間での成長を実感

 

――インフラ移行プロジェクトにおいて、特に印象に残っていること、苦労されたことはありますか?

 

飯田:私自身インフラ領域に関わるのは初めてで一般的な知識がなかった上、今回触れた『ECS』や『AWS CDK』は抽象的な部分も多く、初心者にとって分かりづらいものでした。当初はミーティングに参加しても「話されている内容が分からない」「質問したくても何を聞いていいか分からない」というもどかしい状況でしたね。


そうした前提知識や概念を理解するために、オンライン学習サービスなどを使って自分で手を動かし、少しずつキャッチアップしていったことが特に苦労した点として印象に残っています。


 また今回移行したのはすでに稼働してユーザーに使われているシステムのため、移行のタイミングでサーバーを落としたり止めたりすることは許されません。まだ既存のインフラ構成やサービスの全体像の理解も完全ではない中で、絶対に失敗してはいけないというプレッシャーがありました。




松井:「動いているシステムの土台だけを変える、その前後で結果が変わってはいけない」という非常にデリケートな作業で、システム固有の大変さがありましたよね。


 他に技術的な観点としては、親となるサーバー上に軽量な仮想環境を構築して稼働させる『コンテナ技術』を使う必要があり、この技術で運用するという前提でアーキテクチャに手を入れ直す部分が難しかったなと振り返ります。





――共に取り組んだ1年を振り返って、お互いに対する印象や思いとしてはいかがでしたか?

 

飯田:リンクエッジの将来を見据えながら、教育的な観点から「どこまでをリンクエッジのメンバーに任せ、どうフォローすべきか」まで考えて踏み込んでいただけることが、とてもありがたいなと感じています。そういった采配のもと実務で実際に手を動かせたことで、よりスピード感を持って成長できた実感がありました。




松井:スタテクの立場としても、私たちのご支援のあり方をしっかりと理解された上でお任せいただいているため、「ここまで踏み込んでいいのだろうか」といった忌憚なく伴走できるやりやすさを感じます。


 また今回お任せするタスクの難しさに「負荷が高すぎないか」と不安を感じる部分も当初ありましたが、飯田さんはプロジェクトを進める過程で知識をどんどんキャッチアップされていて。その努力や成果があったからこそ、プロジェクトを無事終えられたと思っています。


プロジェクト発足時にご一緒していた弊社のCTOも、終盤に私が飯田さんと技術的に高度で建設的な議論をされている様子を見て、「短期間で大きく成長された」と感激していました。




飯田:嬉しいお言葉をありがとうございます。悩んだ際に適切なタイミングで適切な方法や教材を教えていただき、また「どのような思考でどのように調査を進め、どう課題を解決していくのか」といった思考のプロセスを近くで学ばせていただいたおかげです。


松井さんのような経験豊富な方と一緒に取り組めることの安心感が大きく、とても貴重で恵まれた経験をさせていただいたなと思っています。






――飯田さんはエンジニア3年目となった今、これまでを振り返りどのような成長実感がありますか?

 

飯田:エンジニアを目指した時に自分の中で掲げていた、「3年目にはこれくらいできるようになっていたい」というイメージを大きく越えることができたと思っています。


1年目にはアプリケーション側の機能開発から始まり、入社後半年ほどで新規機能開発のプロジェクトを任せてもらいました。ビジネスサイドと連携しながら、要件定義〜実装〜テスト〜リリースまで自分が主導して行う経験ができたのは大きかったですね。


 2年目からは、今回お話ししたインフラ移行プロジェクトを1から取り組ませてもらったのと同時に、既存で動いているインフラやアプリケーションの運用保守も担当しました。


開発だけしているとあまり意識してこなかった、パフォーマンス面やサーバー監視面、コスト面についても意識するようになり、目線が1つ上がった感覚があります。時には緊急対応をすることもありましたが、その分「可用性の高いサーバー構成」や「運用保守を踏まえた実装」を身をもって考えるようになりました。


 また、チームのコード規約・開発ルールやドキュメントを作成したり、採用にも関わらせてもらったりと、幅を広げられた1年半だったなと思っています。


そういったことを2〜3年目で取り組む経験ができたのは、リンクエッジのどんどん挑戦させてもらえる風土と、スタテクさんや社内メンバーのサポートのおかげだと思っています。





事業貢献に向けた“攻め”の取り組みと、そのための堅牢な土台づくり=“守り”の両面に注力していきたい

 

――前編の最後に、エンジニアチームとしてどのような課題に取り組んでいくのか、今後の展望を教えてください!

 

飯田:エンジニアチームの課題として、“攻め” と “守り” をどちらもしっかりとやっていくことが重要だと考えています。


“攻め” として取り組みたいのは、絶えず変化するユーザーのニーズや他部署の要望をキャッチアップしてスピーディに開発し、また新規事業にも挑戦していくことです。


 そしてそのためには、特にシステムにおける “守り” が必要です。Link-AGはできて5年ほどが経ち、バージョンアップの必要性やデータが蓄積したことによるパフォーマンス面での課題が出てくるフェーズにあります。今回のインフラ移行プロジェクトを皮切りに、そういった課題を解決するための取り組みに今後も着手し、システムを安定稼働させて “攻め” に取り組むための基盤をつくっていきたいと思います。




松井:そうですね。アプリケーションのインフラは一度つくったら “塩漬け” のイメージを持ってしまいがちですが、実は性能やセキュリティなどの観点からさまざまなアップデートが必要ですから。自動化できるものは自動化しつつ、人が介在すべき部分は仕組み化を進めながら、アップデートに対応していきたいところです。


 また内部設計の改善にも積極的に取り組み、そういったブラッシュアップを経ても正しい動作を保証できるよう、テストの範囲も拡充させるなど、よりよいアプリケーションを目指す取り組みも進めていければと思います。


 

後編へ続く! ―

  • この記事をシェア

その挑戦と成長が、
次の時代を創る。

エントリーする(採用情報を見る)