[株式会社hokan　後藤氏]小さいチームでもコードのアップデートと新規開発を止めない！ #Webフロントエンドリプレイス

hokanフロントエンドの歩み

hokanのフロントエンドチームは、過去1年間でいくつかの大きな変更を経験しました。4人から成る私たちのチームは、本来の機能開発を行いつつ、フロントエンドの改善にも同時に取り組んできました。

今回は、このフロントエンドの歴史の中で比較的大きなことを短期間で行っていく「短期集中型リプレース」、細かい変更を長い時間をかけてじわじわ行っていく「長期じわじわ型リプレース」についてお話させていただきます。

ビルドツールをcreate-react-appからViteへ移行

「短期集中型リプレース」のアプローチの一環として、私たちはビルドツールをcreate-react-appからViteへと移行しました。

この変更の主な動機は、開発体験の向上です。以前のビルドツールは起動に時間がかかり、ホットリロードが遅いという問題がありました。そのため、よりスムーズな開発環境を求めてViteへの移行を決定し、実際に開発体験が改善されました。

ただ、弊社はある程度歴史のあるプロダクトのため、Viteを導入する過程でいくつかの障壁に直面しました。とりわけ、500以上のメンテナンスされていないJavaScriptファイルを全てTypeScriptに変換する作業は、非常に困難でした。そのため、各ファイルを個別に確認し処理する代わりに、ts-migrateを活用して一括での置き換えを敢行しました。

Viteと互換性のないライブラリも存在したため、手動でパッチを適用する作業も必要でした。

このプロジェクトには、中心となる担当者を1名アサインし、通常業務と並行して進めました。コードのレビューと動作確認は、チーム全員が分担して担当しました。

顧客一覧を含むhokanにあるページをNotionに洗い出し、細かい機能ごとに担当者を割り振り、動作確認を実施しました。問題が発生した際は、Notionにリストとして記載し、チーム内で共有しました。

プロジェクトは段階を踏んでリリースされ、開始から3ヶ月後には開発環境に適用されました。その後、他のプロジェクトと並行しつつ、本番環境への反映作業を進め、最終的に1月に全ての作業が完了しました。

フロントエンドのバージョン管理を「ServiceWorker」から「Firestore」へ移行

次に、ServiceWorkerの移行についてです。

現在、フロントエンドのバージョン管理にはServiceWorkerが主流ですが、特定の問題点がありました。たとえば、緊急のバグ修正リリースをリアルタイムでユーザーに反映させたい場合、ServiceWorkerのバージョン管理が更新されないことがしばしばありました。多くのユーザーが古いバージョンに留まってしまう事態が散見されたのです。これを受けて、私たちはServiceWorkerの使用を廃止するという決定をしました。

フロントエンドのバージョン管理を「ServiceWorker」から「Firestore」へ移行スライド1

私たちは、最新のフロントエンドバージョンの更新を確認するために、Firestoreを利用する方法を採用しました。

ビルド時に環境変数にバージョン番号を埋め込みます。そして、リリース時にはFirestoreにも手動でバージョン番号を入力して更新するのです。

Firestoreに記載されている「currentVersion」というデータは、信頼できる最新バージョン番号として機能します。サービスがロードされる際に、コードに埋め込まれたバージョン番号とFirestoreから取得した最新バージョン番号を比較します。もし差異がある場合は、更新を促すダイアログを表示することで、ユーザーに確実に更新させる手法を採っています。

このリプレースプロジェクトでは、中心となる担当者1名をアサインし、通常の機能開発と平行して進めました。これが私たちの短期集中型リプレースのプロセスです。

このアプローチのメリットは、専任の担当者がいるため、チームメンバー全員が自分の担当する機能開発とリプレース作業に集中できる点です。

同じ期間で比較した際に、チーム全体の機能開発のアウトプットが減少してしまう可能性はあると思います。しかし、リプレースによって得られるメリットも大きいため、全体として失うものはないと考えています。また、リリースタイミングの調整など、ビジネスサイドとのコミュニケーションも、専門の窓口を設けることでスムーズに行えるようになるという利点があります。

一方で、デメリットとしては、集中しすぎることで担当者が限定されがちになり、知識の共有が進まない点が挙げられます。これに対する対処法としては、二つのアプローチが考えられます。一つ目は、全員がレビューや動作チェックを行い、変更内容を共有することで理解を深めるという方法です。ただし、変更点が複雑である場合、レビューだけでは理解が追いつかないことも想定されます。その場合の二つ目の方法は、担当者による共有会の開催や、ドキュメントの作成を通じて情報を共有することです。

最後に、現在も一部が進行中である長期的なリプレース作業についてお話ししたいと思います。

moment.jsからdate-fnsへの移行

私たちがmoment.jsからdate-fnsへの移行を検討し始めた主な動機は、moment.jsの開発チームが新しいプロジェクトでの使用を推奨しないと公式にアナウンスしたことにあります。これを受けて、他のライブラリに切り替えるべきだという流れが生まれました。

この移行プロセスを進めるために行った主な活動は二つあります。一つは計画と進捗状況を可視化すること、もう一つはチーム全体でフレキシブルに取り組むことです。

計画と進捗の可視化のために、まずmoment.jsを使用しているファイルをすべて特定し、それらをNotionのプロジェクト管理ツールを用いてタスクリストとして整理しました。これにより、どのファイルが移行の対象となっているのかを明確にしました。そして、これらのタスクに対しては特定の担当者を割り当てず、スプリントの期間中に時間があるエンジニアが自由にタスクを選んで取り組む方式を採用しています。

現在、上図のような2週間のスプリントを採用しており、ステージング期間の後半には、手が空くメンバーが出ることがあります。

そのため、空いたメンバーは自分の興味のあるタスクを選んで取り組むようにしています。この方法は集中型ではなく、スプリントによっては対応できないこともありますが、タスクの進捗を可視化しているため、できなかったタスクについてはすぐに振り返りを行うことができます。

また、チーム全員がタスクに取り組むことで、特定の人だけがライブラリーに詳しくなることを避け、知識をチーム全体で共有しています。これが良い効果をもたらしていると感じています。

さらに、私たちは現在、Material-UIからMUIへの移行も進めています。この移行の主な動機は、ライブラリーのバージョンを更新したいということです。

このリプレース作業では、ファイルごとにタスクを割り当てるのではなく、開発の流れの中で少しずつ対応しており、声かけ運動を行うスタイルで進めています。

私たちは、コンポーネントに個別のスタイルを適用しているため、一気に置き換えるとデザインが崩れるリスクがあります。

そのため、全体を一度に置き換えるのではなく、新しい機能開発や既存機能の改修を行う際に、それを担当するエンジニアがMaterial-UIのコンポーネントを使用しているファイルに遭遇した場合に、都度MUIに置き換えるという運用をしています。

もし、Material-UIを使用しているファイルを手がけていても変更が見過ごされていた場合には、コードレビュー時に指摘し、その場で修正を促すようにしています。これが、私たちが取り組んでいる長期的で徐々に進めるタイプのリプレース戦略です。

このアプローチの利点としては、まず、タスクを細分化して独立させることで、開発作業と平行して進めることが可能になる点が挙げられます。

タスクを小さく区切ることで、15分程度の空き時間にも取り組むことができ、ビジネスサイドとのやり取りで待ち時間が発生した際には、取り組むのにちょうど良いサイズです。

二つ目のメリットは、全員が取り組むことで知識が共有しやすくなるという点です。

プロジェクトの概要を共有する初期段階の説明会を開催し、その後はメンバーが各自のペースで作業を進めながら、自発的に知識共有を行うので、知識をチーム全体で共有するハードルが大きく下がります。

反対に、デメリットとしてはプロジェクトが長期化するため、終わりをどう定義するかが不明瞭になりがちです。これに対する対策としては、プロジェクト開始時にゴールラインを明確にし、必要なタスクを洗い出し、チーム全員がそれを理解することが重要だと考えています。さらに、長期的にじわじわと進めるリプレースは、通常の機能開発と平行して行われるため、スプリントによっては進捗がない時期もあります。そうした際は機能開発を優先し、進捗がないことを割り切るようにしています。

hokanでは、短期集中型と長期じわじわ型のリプレースの2種類があり、それぞれに適した対処法が存在します。メリットとデメリットはありますが、どのリプレースを行いたいかによって最も適した方法を選ぶことが重要です。そして、新たなリプレースを進める過程で、より良いパターンや方法を発見する可能性もあります。

＼株式会社hokanでは、積極的に採用中📣／

株式会社hokanの中途採用・転職・求人情報｜Offers Jobs

福利厚生も充実しており、リモートワークやフレックスタイム制度はもちろん、技術向上や開発効率を支援するために年間12万円を受け取れるテックブースト制度など、魅力的な福利厚生があります。ご興味をお持ちでしたら、カジュアル面談も大歓迎ですので、ぜひお話ししましょう。ご清聴ありがとうございました。