「絵を描く」「実装する」の二面から、プロジェクトを支えるエンジニア

氏名:岩山さん
入社日:2021年4月1日
インタビュー:2022年3月17日
サーバーサイドエンジニア

システム全体を見渡すエンジニアとしてのキャリアを目指して

新卒で入社したのは都内のモバイルゲーム企業。その後地元の札幌に戻り、パッケージソフトの開発やフルリモートでスタートアップでの開発に携わることで、事業や規模の異なる企業を経験しました。そして2021年にLINE Growth Technology(以下、GT)に入社しました。
これまでの経歴はサーバーサイドエンジニアとしての経験が長いですが、過去の職場ではチームのリソース状況に合わせてフロントエンド開発やクラウドを利用したインフラの構築運用などにも関わってきました。

GTへの転職のきっかけは前職で感じた「個別機能の開発よりも、もう少し広い視点でシステム全体の設計や開発がしたい」という思い。例えば新規事業を行うときにどのようなアーキテクチャでシステムを作れば安定性が上がるか、利用者が増えても耐えられるか...といった検討をするような仕事をしたいと思っていたのですが、当時所属していた会社では事業方針変更で新規事業がストップしたことから実現が難しくなってしまいました。そこでモヤモヤを抱えていたところに、GTから声をかけてもらったことがきっかけでした。

GTなら多彩な事業やサービス開発に関われますし、関わっているプロジェクトも多いので、いろいろな事業のフェーズを経験できそうだと感じて入社を決めました。

長く使われてきた『出前館』のシステム改修プロジェクト

担当している業務のなかで現在大きなウェイトを占めているのは、出前館のシステム改修プロジェクトです。LINEグループは2020年から出前館と提携し、LINEサービスとの連携も進められていて、注文や配達に使うシステムの改修を行っています。

僕は出前館のサポート担当の方が利用するシステムの改修プロジェクトに参画しています。例えば、注文の処理がうまくいかずにエラーになってしまったり、配達の方が見つからず処理を完了できなかったりといったトラブルに、サポート担当の方が対応する時に利用されるシステムです。

出前館そのものは歴史の長いサービスなので、稼働しているシステムがレガシーであることが課題でした。インフラもオンプレミスからAWSへの移行を進めています。

そもそもずっと使われていたシステムなので、UIがわかりにくい部分や、改修を繰り返してきたことによって保守が難しかったり、システム間での連携部分に課題があったりと精査が必要な状態。ドキュメントも少ない中で修正がしにくく、なかなか手を出せなかったんだろうなという状況を当初感じました。「現行の仕様はどうなっているのか?」「この既存仕様は不要では?」など、1ヶ月ほどかけて具体的な修正の洗い出しを行い、関連システムを担当する他のチームともコミュニケーションをとりながら新システムの要件の洗い出し・設計要件の改善をしていきました。

既存のシステムの課題を解消しながら、意識していたのはメンテナンス性です。今回改修をしたシステムを今後5年、10年と使っていくにあたり、より管理しやすい設計を心がけました。

実際に使用するサポートチームの方からいただくフィードバックはとても大事ですね。使いづらいと感じた部分を具体的に指摘してもらえたり、ポジティブなフィードバックもいただけたりするので開発のモチベーションにもなりやすいです。

テックリード的な立ち位置で、判断力を求められる場面で悩んだことも

僕がプロジェクトのなかで担っている役割は大きく分けると二つあります。一つはシステムの全体像をイメージして“絵”を描いていく、アーキテクト的な部分。もう一つは、実際に手を動かして、PoC(概念実証)的にモノを作ってみる役割。作りたいモノに対してどんな技術を使えば効果的かを検討して、それが本当に有用かどうかを見極め、実際の開発へ展開していくような役割です。テックリードと言い換えてもいいかもしれません。コードレビューなどを通してシステムが一定のルールに沿っているか、今後もメンテナンスしていけるような設計になっているかをチェックし、メンバーに助言をすることもあります。

入社して最初に入ったプロジェクトがこの出前館プロジェクトだったので、自分に求められている力が発揮できるかというプレッシャーはありました。最初は自信がなく、10:0の強い意思決定ができずに反省が残ったことも。「自分はAの方法がいいと思ったけど、他の人はB案だと言っているし、Aが絶対にいいと言い切ることもできない...」と、気弱な判断をしてしまったことで後から「やっぱりAにすればよかった」と感じることもあるんです。マネージャー陣もある程度任せてくれるので、責任は自分で取るから、もっと自分を信じて強気な判断ができたら...というのは、僕自身が感じている今後の課題ですね。

LINEグループならではの情報集積量とプロジェクト数

アーキテクトとしての面白みは、「勝ちパターン」のようなものがないところです。いつでも通用するパターンは存在しなくて、その部署やシステムによって異なる事情を汲み取りながら最適なアーキテクチャを考えていく試行錯誤が楽しいです。アーキテクトにはサーバーサイドだけでなくフロントエンド、セキュリティなど多くの分野の知識が求められますが、新しく何かを学びながら仕事に取り組めるのは今の職場のいい部分ですね。

ちなみに、これはプロジェクトチーム内でも同じことがいえて、同じプロジェクトにアサインされていても、メンバーはバックグラウンドや経歴が違うので、それぞれが思うベストは違うということもよくあります。そこをぶつけ合いながらチームとしてのベストを探していくのは、大変でもありますが面白みの強い部分だと思いますよ。

GTやLINE全体の魅力は、やはり企業規模が大きいことによる情報の集積です。GTの社員もLINEグループの各社と共通のSlackやwikiを利用していますし、情報もオープンになっていて。気になるチャンネルを覗いて新しい知識をインプットできるのも刺激になります。いろいろなチャンネルに参加して情報をキャッチしています。

GTにはいろいろな案件が集まるので、求められる技術の領域もそれぞれ異なります。開発に使用する言語やフレームワークも社内ルールや統一されているものはなく、案件に対して最適なものを選んでいくのが多いです。いろいろな言語が使えることに越したことはないのですが、得手不得手もあるでしょうし、いろいろなプロジェクトが動いているGTなら合うところが見つかると思います。

システム全体を俯瞰してサービスを考えられるエンジニアへ

エンジニアとしてのキャリアは9年目。個別システムの全体設計も経験してこられたし、より広い範囲でシステム全体を考えるような業務にも関われたらと考えています。例えばサービス開発にしても、サービスの運用業務のようなある種裏側の部分を長く経験してきたので、表側の部分も意識した全体からサービスを検討していくようなキャリアを描いています。

僕の思う「よいエンジニア」は、いろんな知識がある人。加えて、知識へのアクセス方法を知っている人です。目の前におりてきた問題に対して自分なりの回答を提示できるのがベストですが、回答がなくても「ここを調べたらいいかも」「ここでのやり方が応用できるかも」と瞬時に浮かぶ“勘所”って大切だと思っているんです。

それから、GTの案件はチームで動かすものなので、もくもくと作業を進めるタイプの人よりも関係者とコミュニケーションを取りながら案件を進めていける人でしょうか。個人的には技術的なスキルももちろんですが、対人的なスキルも大事にして、合わせて磨いていきたいと考えています。