リプレース実施の目的は、開発者体験の向上
本日は、弊社の開発者体験改善策について、特に「リファクタ」と「リプレース」の定義に焦点を当てて解説いたします。
弊社における「リファクタ」は、同一リポジトリ内で同じ技術を用いて変更を加えるプロセスを指します。これに対し、「リプレース」は、二つのシナリオに分けて定義されています。第一に、同じ技術を選択しながらも、リポジトリやプロジェクトを変更する大規模な変更を行う場合です。第二に、同一リポジトリ内で、技術選定を大幅に変更する場合もリプレースに含まれます。例えば、部分的にReactを導入するなどの変更がこれに該当します。
弊社のポリシーとして、大掛かりな一括リリース、いわゆる「ビッグバンリリース」は極力避けるべきと考えています。その代わりに、漸進的なリプレースを推奨しており、継続的なリファクタリングと漸進的なリプレースを平行して進めることで、開発者体験の向上を目指しています。
ディレクトリ構成と漸進的にリプレースの進め方
このような構成にすることで、共通化された部品を独立したライブラリとして持っていることです。これにより、プロダクトの開発が容易になります。
ビッグバンリリースは時間がかかるもので、その間にビジネス要請などが介入し、結果としてリプレースが中止されるか、あるいは事実上無かったことになるリスクがあります。このような問題を避けるためには、漸進的なアプローチが有効であり、良いプラクティスだと考えています。
リプレースは時間がかかるもので、場合によっては完了しないこともありますが、リプレースで重要なのは継続的に取り組んでいくことだと思っているので、それができるプラクティスは重要だと思っています。
また、モチベーションが高い時には、その熱意を大切にして、より良い環境を作りたいと思います。リンターやテスト、ストーリーブックなどを積極的に作り、それらを使って新しい世界を構築し、徐々に古いシステムに統合していく方法は、非常に良いアプローチだと感じています。
ライブラリの依存関係に沿ってビルドしなければならない手間が発生
通常のプロセスでは、新しいリポジトリでライブラリを作成し、その後ライブラリをビルドします。Moshプロジェクトには、約3つのライブラリがあり、それぞれのライブラリを依存関係に従って順にビルドする必要がありました。そして、それらのライブラリをリポジトリが取り込んで、最終的なビルドを行うという、非常に複雑な手順を踏むことになります。
この手順を毎回繰り返す必要があるかという問いには、数え切れないほど何度も「毎回必要です」というコミュニケーションを取ってきました。
加えて、このような経験をした人はほとんどおらず、新たにこのプロセスに取り組む人にとっては、キャッチアップコストが非常に高くなります。
自分のビルドが一体どこにあるのかという状況になり、これには困っていました。しかし、これらの問題をすべて解決してくれたのが「NX」というビルド管理ツールです。
NXのおかげで作業が非常に楽になりました。このツールは依存関係を自動的に解決してくれるため、新旧リポジトリの関係について気にすることなく、シームレスに開発を進めることができるようになりました。
これは、私がこれまで取り組んできたリプレース戦略の一例です。漸進的なリプレースとして、技術スタックを大きく変更することなく、部分的に新しい設計や技術を導入し、それを取り入れていく方法を採用してきました。
今後も、このような漸進的なリプレースを社内で積極的に進めていく予定です。
ユニット分割の根幹をなすサービス分割とMFE
Moshは、個々のクリエイターのニーズに応えるサービスです。特に決済や予約など、取引に関連するニーズに対応しています。ここで重要なのは「個々」という点です。例えば、非常に大きなエンタープライズ企業がたくさんのニーズを持っている場合、それらに対応するためには小規模なMVP（Minimum Viable Product）を次々と試していく必要があります。
ニーズに応えるためには、いきなり完璧な製品を作ろうとしても成功しないため、小さなトライアンドエラーを繰り返す体制が必要です。そのためには、サポートする技術基盤が不可欠です。現在、私たちの会社では「やりたいことのドメインモデル」を作成しており、そのモデルにおいて重要な「繋がり」を持つ部分でチームを編成しています。各チームは自分たちのドメインモデルを管理し、必要なMVPやプロダクトプロトタイプの開発を行っています。
これを実現するためには、技術的な基盤だけでなく、インフラやアーキテクチャーのサポートが絶対に必要になってきます。
今後、我々はこのような形式のアーキテクチャーを目指していく予定です。これは厳密にはマイクロサービスとは言えないかもしれませんが、ドメインごとに独立したモデルを採用し、各主役ごとに分割されたバックエンドサービス群と、それに適応する形のマイクロフロントエンド化をしていく方針です。
マイクロフロントエンド化は、基本的に漸進的なリプレースを考えており、Angularをホストとして使用しつつ、その上にAngularアプリケーションやReactアプリケーションを配置することを計画しています。
私がお話ししたのは、サービスの分割とマイクロフロントエンドの導入、それに伴う技術要素の更新についてですが、それ以外にもサーバーサイドレンダリング、ネイティブアプリケーションの開発、カスタムデザイン、お客様個別のGoogle Analyticsの組み込みやタグの埋め込みなど、様々な取り組みを進めていく予定です。
もし興味を持たれた方がいらっしゃれば、これが宣伝のように聞こえるかもしれませんが、表示しているリンクから是非コーポレートサイトをご覧いただきたいと思います。
＼株式会社moshでは、積極的に採用中／Mosh株式会社の企業情報 | ITエンジニアの副業・転職採用・求人案件サイトOffers Jobs（オファーズ ジョブズ）