今回はlake.biの開発チーム2名に「最近の仕事はどんなことをしていたか」を聞いた開発者インタビューです！ では、さっそくいってみましょう！
lake.biの概要はこちら
今回の登場人物
- 秋本 昌利（あきもと）: 2020年 株式会社サイバー・コミュニケーションズ（現株式会社CARTA COMMUNICATIONS）に中途入社。ソフトウェアエンジニアとしてlake.biの開発・運用に従事。現在はフロントエンドのリプレイスを担当。
- 大前 直士（おーまえ）: 2023年 CARTA HOLDINGS 新卒入社。株式会社CARTA COMMUNICATIONSにてソフトウェアエンジニアとしてlake.biを開発。現在はフロントエンドのリプレイスを担当。
Springbootバージョンアップ 2.7 → 3.2
-- あきもとさん、今回のプロジェクトについて教えてください。具体的にどんな作業を行ったんですか？
あきもと: 今回はlake.biで利用しているSpringbootのバージョンアップを行いました。 Springboot2.7系が2023年11月24日にEOLを迎えたため、サポート可能な3.2系までアップデートしました。また、Springboot3.0系からJavaの最低バージョンが17になったので、Java11から17へのバージョンアップも同時に行いました。
-- なるほど、2つのバージョンアップを同時に行ったわけですね。対象範囲はどの程度でしたか？
あきもと: 今回の対応範囲は、オンラインでレポートを作成するシステムのサーバーサイドAPI部分が対象でした。 具体的には、Java11から17へのバージョン変更、Springboot2.7系から3.0系への移行に伴う影響範囲調査とコード修正を行いました。
-- 大規模な更新だったんですね。作業を進める中で何か課題はありましたか？
あきもと: はい、やはり課題がありました。 対象のリポジトリに他案件の変更が次々と入るため、こまめにマージすると既存EC2にデプロイされている他案件のコードと混ざってしまい、他メンバーの受け入れ試験にも影響が出てしまう状況 だったんです。
-- それは厄介そうですね。どのように対処したんですか？
あきもと: 新規EC2を用意して、既存EC2に変更影響が出ないようにしました。これにより、必要があれば簡単に切り戻しができるようになりました。また、インフラチームと協力して、EC2環境設定の準備や更新、開発環境へのマージ、評価環境での動作確認まで担当し、最終的にリリースまで無事に完了させることができました。
-- チーム全体で協力して解決したんですね。良かったことはありますか？
あきもと: 今回の作業内容や手順をIssueやドキュメントにしっかり残したことです。実は、以前のSpringboot移行時にはEC2の準備や手順などがドキュメントに残っていなかったんです。今回はそれを踏まえて、詳細な作業内容や試験手順をissue化しました。これは今後同じような作業をする人たちの助けになると思います。あとは本番環境でのリリース後もトラブルが起きなかったことですね。これは、慎重に作業を進めた結果だと考えています。
-- 素晴らしいですね。今後の展望について聞かせてください。何か計画はありますか？
あきもと: そうですね、短期的な課題と長期的な目線で考えています。
- 短期: Springbootバージョンアップの事前スケジューリング
- 長期: ブランチデプロイの整備
まず短期的なSpringbootバージョンアップの事前スケジューリングについて。 今回の改善がギリギリのタイミングだったことを反省していて、チーム内で新しいアプローチを話し合っています。具体的には、まず明確な期限を決めて動き出そうということです。この方法なら、作業の優先順位が明確になって進めやすくなるんじゃないかと。
長期的な展望としては、ブランチデプロイの仕組みの整備を考えています。各ブランチごとにデプロイ環境を用意して、更新内容をサクッと確認できるようにしたい です。
こうすれば、レビューやテストがより効率的に行えるようになるでしょうし、Springbootの更新作業だけでなく、他の開発作業全般でも活用できると思います。長期的にはこの仕組みを整備して、チーム全体の開発プロセスを改善していきたいですね。
-- なるほど、短期的な対策と長期的な展望、両方をしっかり考えているんですね。特にブランチデプロイの仕組みは、チーム全体の効率化にもつながりそうです。あきもとさん、貴重なお話をありがとうございました！
新卒2年目でNuxt2 → React18への移行
-- おーまえさん、今回のプロジェクトについて教えてください。具体的にどんな作業を行ったんですか？
おーまえ: 今回の仕事では、Nuxt2で書かれていたプロダクト画面をReact18で書き直す作業を行いました。フロントエンドの知見がゼロの状態からのスタートだったので、技術選定から始めて、移行体制の構築、そして実際の実装までを担当しました。
-- フロントエンドの経験がない状態からのスタートだったんですね。なぜReactへの移行を選んだのでしょうか？
おーまえ: はい、主に以下の3つの理由からReactへの移行を選びました
- Nuxt3へのアップデートが困難
- Vue3の学習コストがReactを新規に学ぶのと大差がなかった
- Reactの方が将来性として有利
まず、 Nuxt3へのアップデートが困難だと判断した ことです。破壊的変更が多く、周辺ライブラリのサポート状況にも懸念がありました。次に、Vue3の学習コストがReactを新規に学ぶのと大差ないと考えたことです。最後に、Reactの方が将来性や利用人口としても多く有利だと判断しました。組織の選択肢や知見を増やすという観点からもReactが良いと考えました。
-- 実際に作業を進める中でどのような工夫をされましたか？
おーまえ: はい。主に以下の3つの点に注力しました：
- ESLintの設定
- CI/CDの整備
- PR単位でのデプロイ環境の構築
1つ目はESLintの設定です。全員がReact初心者ということもあり、アンチパターンを踏むリスクを減らすためにツールでガードレールを設けました。2つ目はCI/CDの整備です。最初期に整備することで再実装とメンバー参画時の開発スピードを高められると考えました。3つ目はPR単位でのデプロイ環境の構築です。これにより、レビューのしやすさが向上し、バグの共有や実装例の共有にも役立ちました。
-- 素晴らしいですね。その結果、どのような成果が得られましたか？
おーまえ: はい、いくつかの成果がありました。まず、「リファレンス実装」として、これからメンバーが参考にできる実装を用意できました。また、GitHub移行の試金石として、ActionsやProjects、Slack連携、botによるPRなど、一つの運用方法を示すことができました。さらに、 Lintによる指摘とPR単位でのデプロイ環境がもたらした高頻度なデリバリーにより、習熟や開発を加速させる環境を構築できました。
個人的には、大学時代にほんの少し触れただけのフロントエンド開発でしたが、ここまで実装できたことに達成感を感じています。特に実績を管理するテーブルは、Nuxt版でも難航したコンポーネントでしたが、今回はより使いやすい形で実装できました。
-- おーまえさん、詳細な説明をありがとうございました！
以上、lake.biの開発者インタビューでした！ CARTA COMMUNICATIONSではエンジニアを募集しております。興味ある方はぜひこちらよりご応募ください。
