複雑な現場に入り込み、技術だけでは届かない領域を前に進める

これまでのキャリアについて教えてください。

2017年に新卒でエムスリーに入社し、Androidエンジニアとしてキャリアをスタートしました。m3.comのアプリや派生サービス、一般向け医師相談サービスであるAskDoctorsのアプリ版の立ち上げなど、複数のモバイルプロダクトの開発に関わってきました。

特にAskDoctorsは新規立ち上げのプロジェクトだったため、一から形にしていく難しさと面白さの両方を感じていました。入社後は、多くのユーザーに使われるプロダクトを開発する経験を積むことができたと思います。

2020年からはグループ会社の支援チームに加わり、既存サービスの改修や保守運用の内製化、新規開発、システムの刷新といったテーマに取り組んでいます。最初の支援先では、長年運用されてきたシステムの刷新に関わりました。既存の仕様や挙動を理解しながら進める必要があり、コードを読み解きながら一つひとつ整理していく場面が多かったです。こうした経験を通じて、整った環境で新しく作ることよりも、複雑な状態にあるものを整理しながら前に進めていくことに、自分の強みがあると感じるようになりました。

なぜエムスリーテクノロジーズを選んだのですか？

エムスリー本体も優秀なエンジニアが多く在籍しています。また、Android以外の技術領域への挑戦も出来ており、日々スキルが向上していくのを感じていました。社内での移動も考えたのですが、より事業のコアな部分で自分という個人の価値を直接的に発揮できる環境について山崎と相談していたところ、テクノロジーズはどうかと提案され入社しました。

自分の強みは、既存のコードを理解して改善していくことや、バグの原因を特定し、パフォーマンスを改善していくような領域にあると感じています。きれいに整った環境で新しく作るよりも、複雑な状態にあるものを整理しながら、少しずつ良くしていくやり方が自分には合っていました。

エムスリーテクノロジーズで、自分の強みを活かせる場面がより広がり、深くなったなと感じています。グループ会社には開発体制がこれから整っていくフェーズにある組織や、体制は整っているものの技術負債が蓄積している組織があります。そうした環境であれば、自分が関わることで現場を前に進められる余地がある。そう感じ、この環境に身を置くことを選びました。

入社前後で感じたギャップを教えてください。

一番大きかったのは、エンジニアの役割が開発に閉じないことでした。支援先の組織のフェーズによっては、開発組織自体が十分に整っていない場合もあり、単に実装を進めるだけでなく、何を作るべきかというところから関わる必要があります。優先順位の整理や進め方の設計まで含めて考える場面も多くありました。

実際に、エンジニアとして入ったつもりが、気づけばプロダクトマネージャーに近い立ち位置で考えることもありました。開発だけに集中するというよりも、より広い領域に関わる必要があり、最初は戸惑いもありました。ただ、自分自身としては開発に閉じない関わり方を求めていたこともあり、その変化は前向きに受け止めていきました。

一方で、支援先によってはテストカバレッジが高く、QA体制も整っているなど、技術的に成熟している組織もあります。そうした環境では、品質と開発スピードのバランスをどう取るかという別の難しさがありました。組織ごとに状況が大きく異なるため、その都度、自分の関わり方を変えていく必要がある。この点は、参画前に想像していた以上のギャップだったと感じています。

この仕事の難しさと面白さについて教えてください。

難しさでいうと、技術的にどうするのが良いかだけでは決められない場面が多い点だと思います。たとえばフレームワークの更新一つとっても、必要性があってもすぐに着手すべきかどうかは別の問題です。ビジネスとして優先すべき開発がある中で、どこにどれだけ時間を使うのかを判断する必要があります。

実際に、以前所属していたチームではリファクタリングの時間を意識的に確保できていましたが、ビジネス側の要望や新機能開発の優先度が高く、技術的負債の解消に時間を割きづらい環境では、課題として認識されていても後回しになってしまうことがあります。そのような状況の中で、どこまで対応するのか、どの順番で進めるのかを見極める必要があります。

そうした判断が、開発の進み方やプロダクトの状態に大きく影響していきます。

一方で、自分が関わることで止まっていた取り組みが動き出したり、改善が進んでいくのが見えると、この仕事の面白さを感じます。技術的な対応にとどまらず、進め方や優先順位まで含めて関わることで、状況そのものを前に進めていける。その変化に関われる点が、この仕事の特徴だと思います。

達成感を感じた経験はありますか？

大規模フレームワークのリプレースは、大きな経験でした。臨床研究のシステムということもあり、当初はドメイン知識もほとんどない状態で関わることになりました。必要最低限の知識をキャッチアップしながら進めていく形でした。

その中で、自分はビジネス側の機能開発ではなく、フレームワークの更新やシステム全体の刷新といった基盤部分に集中して取り組んでいました。他のエンジニアが業務に直結する開発を進める中で、自分は当時一人で基盤のリプレースに取り組む立ち位置でした。

最初に取り組んだプロダクトではまとめて置き換える進め方で負荷が大きくなってしまいましたが、その経験を踏まえて、2つ目のプロダクトでは業務を止めずに移行するために段階的な進め方へと切り替えました。結果としてどちらもリリースまで到達し、問題なく動いたときには、やり切ったという感覚がありました。

また、自分が関わることで、それまで優先順位の都合で着手しきれていなかった改善が動き出した実感もありました。役割分担として自分が基盤改善に専念できたからこそ前に進められる領域があるという点は、この環境ならではだと感じています。

ここでの成長についてどう感じていますか。

一番大きいのは、コミュニケーションの部分だと思っています。これまでの経験を通じて、組織との向き合い方や関係者との認識の揃え方を、実践の中で学んできました。

以前は、目の前のシステムの課題をどう解決するかという点に意識が向きがちでしたが、それだけでは物事は前に進まないと感じるようになりました。同じ課題であっても関係者ごとに前提や認識が異なることが多く、そのまま進めてしまうと後々大きな手戻りに繋がります。そのため、最初の段階で背景や目的を共有し、前提を揃えることを意識するようになりました。

技術的な面でも、レガシーシステムの理解やリプレースの進め方などを実務の中で身につけてきましたが、それ以上に、どう進めるかを考える力が伸びたと感じています。単に実装するのではなく、その対応がどのような影響を持つのか、今やるべきかどうかを判断する視点は、この環境で得られた大きな変化です。

どんな人がこの環境に向いていますか。

技術力は前提としてありますが、それ以上にコミュニケーション力が重要だと思います。ビジネス側の方と一緒に進める場面も多く、いかにしてビジネス側の言葉に翻訳して共通認識を作るかが求められます。また、課題自体が整理されていない状態から関わることも多いため、話を聞きながら状況を整理し、方向性を見出していく力も必要になります。

そのため、チームリーダーの経験がある方や、開発にとどまらず組織やプロダクトにも関わってきた方は、比較的入りやすいと思います。全体を見ながら動いてきた経験が、そのまま活きる場面が多いからです。

一方で、役割や進め方があらかじめ決まっている環境に慣れている場合は、最初は戸惑うこともあるかもしれません。何をやるかから考える場面が多いため、そのプロセス自体に面白さを感じられるかどうかが、この環境にフィットするかの分かれ目になると思います。

最後にメッセージをお願いします。

この環境では、さまざまな組織に入り込みながら、それぞれの課題に向き合い続けることになります。一つの課題を解決して終わりではなく、次の課題が見えてきて、それにどう向き合うかを考え続けていく仕事です。

決まった正解が用意されているわけではありませんが、自分の関わり方次第で状況が変わっていく実感は持ちやすい環境だと思います。技術的な対応にとどまらず、進め方や関係者との向き合い方まで含めて考えながら取り組んでいく点に、この仕事の特徴があります。

課題を見つけ、どうすれば前に進められるかを考えることに面白さを感じられる方と、ぜひ一緒に取り組めたら嬉しいです。