モノタロウのフロントエンド刷新の取り組み⑤～6年強のあゆみと学び（技術選定と本番運用のギャップをどう乗り越えるか）

こんにちは。モノタロウでECサイトの開発・運用を担当している辰巳です。

モノタロウではECサイトのフロントエンド刷新に取り組んでおり、その内容をブログで共有したいと思います。

モノタロウのECサイトは1,000万を超えるユーザに利用される事業者向け間接資材ECで、当社のビジネスの中核を担っています。一方でフロントエンドは、長年の機能追加の中でレガシーな技術や独自フレームワークへの依存が進み、設計の異なる複数のシステムを各チームが横断して担当するという、認知負荷の高い構成になっていました。このシステムを刷新するというのが今回お話しする取り組みです。

ここまでのシリーズでは、モノタロウのフロントエンド刷新の取り組みの概要、開発生産性の効果、UIコンポーネントやBFFの整備の状況と苦労、工夫などについてお話ししてきました。

実はこの取り組み、2019年11月に始まっており、6年強続く（まだ終わっていませんが）超長期のプロジェクトになっています。現在は、トップページ、商品検索ページ、商品一覧ページ、商品詳細ページといった主要ページへの展開が進み、ユーザ体験（Core Web Vitals）やビジネスKPI（売り上げのリフト）の面でも大きな成果が得られつつあります。

振り返ってみると、我ながらよく心折れずに進めてこられたと思います。今回の記事では、私たちがこの巨大プロジェクトをどのように進めてきたのかを「フロントエンド刷新のあゆみ」として振り返り、途中で挫折することなく進めてこられたポイントを「フロントエンド刷新の学び」としてまとめたいと思います。

フロントエンド刷新のあゆみ
フロントエンド刷新の学び
おわりに

関連記事のリンクを参考までに載せておきますので、よかったらあわせてチェックしてみてください。

フロントエンド刷新のあゆみ

立ち上げ前

プロジェクトを立ち上げる前から、私たちエンジニアは、モノタロウのECサイトを構成するフロントエンドのシステムに課題があることを認識していました。フロントエンドのアプリが異なる言語やアーキテクチャをベースとする複数のレガシーなシステムで構成されていたことで、主に以下の2つの課題がありました。

開発の認知負荷が高く開発生産性が上がらず、価値提供に時間がかかる
高度なUI/UXを実現するハードルが高い

課題は認識している一方で、課題が壮大過ぎることもあり、目の前の事業貢献に直結するタスクを優先する「今」のニーズと、将来の持続的な成長に必要な刷新に取り組む「未来」のニーズとのジレンマを抱え、なかなか具体的な一歩が踏み出せない状況が続いていました。

立ち上げ期（2019年11月～2020年3月）

取り組み
ECサイトのフロントエンドのあるべき姿（ToBe）と現状（AsIs）とのFit & Gap分析（2019年11～12月） ECサイトのフロントエンドの要求・要件・評価基準の整理（2020年1～3月）

この状況を打破するために有志3名が業務外で自発的にはじめたのがこのプロジェクトです。課題はいつまでも有志だけで扱えるものではないため、決定権者を巻き込んで組織目標の一部に組み込むことを当面の目標としました。そのために最初に取り組んだのが「ECサイトのフロントエンドのあるべき姿（ToBe）と現状（AsIs）とのFit & Gap分析」です。非常に大まかではありますが、ECサイトに求められる要求に対し、私たちのシステムは応えられているのか、応えられていないとすると課題は何なのかを言語化しました。

これを基に有識者や決定権者と議論を重ね、「ECサイトのフロントエンドの要求・要件・評価基準の整理」で、内容をより具体化・精緻化していきました。ここで得られた成果が、その後のフロントエンド刷新の取り組みの骨格となる全体マップになりました。すなわちこのマップにより、フロントエンド刷新で何を実現すべきか、それをどう評価するかについて、関係者の認識を揃えることができました。

この結果、組織目標としてプロトタイプによるPoCを進めていくことが決まり、プロジェクトの第一歩を踏み出しました。

PoC期（2020年4月～2021年9月）

時期	取り組み
2020年4～9月	プロトタイプの企画システムのアーキテクチャ設計と技術選定
2020年10月～2021年3月	プロトタイプのUIデザインシステムの基本開発
2021年4～9月	プロトタイプの開発

PoCでは、将来モノタロウのECサイトでどんなユーザ体験を提供すべきかという未来志向で検証を進めました。事業貢献に直結するタスクと並行してPoCに取り組み、およそ25%の工数を掛けていました。

最初に（2020年4～9月）、「プロトタイプの企画」と「システムのアーキテクチャ設計と技術選定」に取り組みました。「プロトタイプの企画」では、ECサイトの主要導線のひとつである、ユーザが商品を探索・選定するシチュエーションにフォーカスし、そこでのユーザのメンタルモデルと行動パターンを分析しながら、提供すべきユーザ体験のコンセプトを整理しました。並行して「システムのアーキテクチャ設計と技術選定」では、新しいフロントエンドのシステム構成や処理方式といった大きな設計方針を体系的に整理しつつ、開発で採用する技術選定を行い、React/Next.jsを採用することを決めました。技術選定の詳細は Vue.js？React？フレームワーク選びの７つの選定基準、大規模ECサイトのフロント刷新プロジェクトに書かれているので、よかったらご覧ください。

次に（2020年10月～2021年3月）、「プロトタイプのUIデザイン」と「システムの基本開発」に取り組みました。「プロトタイプのUIデザイン」では、前のフェーズで決めたユーザ体験のコンセプトを具体的なUIデザインに落とし込み、モックを作成していきました。並行して「システムの基本開発」で、プロトタイプのベースとなる基本的なWebアプリを開発しました。React/Next.jsを採用することは決めていましたが、コーディング規約、リントやテストなどのツール、ログやエラー通知などのライブラリ、Storybookを用いたUI開発、GraphQLのライブラリと開発方式（スキーマファーストかコードファーストかなど）など、将来を見据えて開発基盤として必要なものを詳細に決めていきました。また、ReactやNext.jsの使い方やSEO対策としてのSSR（サーバサイドレンダリング）の実現方法など、アプリ開発の知見も深めていきました。

最後に（2021年4～9月）、「プロトタイプの開発」で、前期の成果をもとに、ユーザ体験のコンセプトに基づく商品検索・閲覧ページのプロトタイプを開発しました。具体的には、商品の検索、絞り込みと商品情報の閲覧とをソフトナビゲーションで行き来しながらスムーズに商品を探索・選定するUIをフロントエンドの新しいシステムで開発し、より高度なUI/UXの実現可能性を確認しました。

限定的な本番導入期（2021年10月～2023年3月）

PoCを経て無事本番導入を進めることになったのですが、現行システムは巨大かつ複雑で一朝一夕に置き換えられるものではありません。現行システムの仕様の透明性の低さや、私たちの技術運用のケイパビリティの未熟さもあり、主要なページを置き換えるのは非常にリスクが高い状況でした。そこで私たちは、フロントエンド刷新を、現行システムを段階的に新システムに置き換えていくストラングラーパターンで進めることとしました。この際、取り組みを大きく「新システムの導入」、「現行システムの負債解消」、「組織の再設計・対応」の3つのアプローチで考えました。

新システムの導入：新しい技術を本番で実運用し、ビジネスインパクトの拡大と私たちのケイパビリティの強化を図る取り組み
現行システムの負債解消：現行システムの複雑さを部分的に解消し、移行しやすくする取り組み
組織の再設計・対応：刷新を促進したり効果を最大化するための組織面の取り組み

新システムの導入

取り組み
買ったものリストページ検索機能簡易版（2021年10月～2022年3月）商品詳細ページ属性選択UI（2022年4～9月）用途ページ（2022年4月～2023年3月）買ったものリストページ検索機能強化版（2022年10月～2023年3月）

全ての技術スタックを一気に導入するのはリスクが高いため、限定的かつ段階的に進めていきました。

最初に取り組んだのがReactの導入です。クライアントサイドのUIにReactを導入し、バックエンドAPIは既存のものを利用する形で、Reactの導入を進めていきました。具体的には、「買ったものリストページ検索機能簡易版」、「商品詳細ページ属性選択UI」がこの取り組みに当たります。

次に取り組んだのがNext.jsの導入です。サイト内で、ビジネスインパクトが限定され、計測やSEOを含む基本的な動作を検証できるページを選び、ここにNext.jsを導入し、影響を評価しました。具体的には、「用途ページ」がこの取り組みに当たります。

最後に取り組んだのがGraphQLの導入です。BFFとしてGraphQL APIを構築し、既存のAPIに代えて利用する取り組みです。具体的には、「買ったものリストページ検索機能強化版」がこの取り組みに当たります。この時に開発した初期のBFFの失敗と学びがモノタロウのフロントエンド刷新の取り組み④～BFF×GraphQL導入の狙いとスキーマ設計の試行錯誤に書かれているので、ぜひ参照ください。

現行システムの負債解消

取り組み（本格的な本番導入期も継続）
ABテストの仕組みの刷新（2022年4月～2024年9月）計測の仕組みの刷新（2022年12月～）

ここでは大きくABテストと計測の2つの課題に取り組みました。

まず、ABテストについて、現行システムでは内製の仕組みを使っていましたが、サブシステムごとに仕様や使い勝手が微妙に異なり、開発面で負担となっていました。また、ABテストの結果を全ユーザに反映するためにコード変更を伴うリリースが必要で、運用面でも負担になっていました。そこで、ABテストに加えてリリーストグルやキルスイッチなどにも包括的に対応できるFeature Flagの外部サービスを導入し、内製の仕組みを置き換えました。Feature Flagの外部サービスを新システムにも導入することで、ABテスト移行を外部サービスの導入という単純な問題に置き換えることができました。

次に、計測について、現行システムでは計測の大部分が手続き的に実装されており、新システムに移行する際はコードを愚直に書きなおす必要がありました。そこで、計測をHTML属性を用いて宣言的に実装できるようにし、宣言された内容をもとに計測ライブラリが処理を行う構成に変更しました。計測ライブラリを新システムでも動作できるようにすることで、計測移行を宣言の移植という単純な問題に置き換えることができました。

組織の再設計・対応

取り組み（本格的な本番導入期も継続）
ドメインチームの組成（2022年4月～）

冒頭で挙げた課題の解消やサービスのスケールを実現するには、システムの刷新だけでなく組織の刷新も欠かせません。そこで私たちは「チームトポロジー価値あるソフトウェアをすばやく届ける適応型組織設計」を参考に逆コンウェイ戦略（理想のシステム構造に合わせて組織を設計する戦略）を取り、ドメイン境界に沿ったストリームアラインドチーム（≒ドメインチーム）を組成しました。そして、ドメインチームを単位にプロダクトをフルサイクル開発（開発から運用まで自律的に担う形）できる状態を目指し、この組織構造に合わせてシステム構造も設計しました。この取り組みが、モノタロウのフロントエンド刷新の取り組み①～大規模ECサイトのフロントエンドをドメイン単位で再設計した話にあるシステム設計につながりました。

本格的な本番導入期（2023年4月～）

私たちの経験と実力が成熟してきたところで、いよいよ本格的な本番導入に進みました。

新システムの導入

取り組み
共通基盤の整備（2023年4月～）用途ページへの共通基盤の適用（2024年2月～9月）主要ページへの展開（2024年10月～）

主要ページに展開する前に共通基盤の整備を進めました。具体的には、ボタンやラベル、ヘッダーやフッターなど多くのページで使われるUIコンポーネント、認証やカート、ミドルウェア、ロガーなど横断的に使われる機能を整備しました。そして、用途ページにこれらを取り込み本番運用に乗せ、展開に備えました。共通UIコンポーネントの整備の取り組みはモノタロウのフロントエンド刷新の取り組み③～「小さく早く試す」UIコンポーネントの整備に書かれているので、よかったらご覧ください。

これらの準備を経て、2024年10月からECサイトの主要ページへの展開を開始しました。現在、トップページ、商品検索ページ、商品一覧ページ、商品詳細ページの移行が完了しつつあります。

現行システムの負債解消

取り組み
CDNの設定の対称化（2024年4月～9月）

ECサイトの運用にCDNを利用していますが、環境毎の設定の対称性が不十分で、CDNやリバースプロキシの認知や運用の負荷が高い状態でした。そこでこの時期にCDNの設定の対称化にも取り組みました。

組織の再設計・対応

取り組み
OKRへのフロントエンド刷新の組み込み（2023年10月）フロントエンドモダナイゼーションチームの組成（2023年10月）フロントエンド刷新に向けたオンボーディングの実施（2024年4～9月）

本格的な本番導入に向けて、組織のOKRにフロントエンド刷新を組み込み、目的と重要度の認識を揃えました。また、フロントエンドモダナイゼーションチームと呼んでいるイネイブリングチーム（他チームの能力向上を支援する役割のチーム）を組成し、複数ドメインへの展開に備えた組織づくりをしました。

2024年4～9月にはフロントエンドエンジニアを対象としたオンボーディングを大規模に開催しました。ここでは、React/Next.js/GraphQLといった要素技術に関する基礎研修と、それを活用したアプリ開発のハンズオンの応用研修からなる講座を企画・実施し、開発スキルやノウハウの組織への普及を図りました。

フロントエンド刷新の学び

これまでのあゆみを振り返って、大規模なフロントエンド刷新を進める上で特に有効だったポイントをまとめます。

要求、要件、アーキテクチャ設計の全体像を初期段階でできるだけ網羅的に整理する

私たちは、立ち上げ期に要求・要件を、PoC期にアーキテクチャ設計をそれぞれ整理しました。この際、強く意識していたのが網羅性です。どんな要求や要件が求められているのか、アーキテクチャ設計で考えるべきポイントは何か、といった項目をできるだけ抜けや漏れのないように整理することを心掛けていました。この結果、整理した内容がその後の活動において課題領域の全体マップや評価軸として機能し、私たちの視野を広く保ち、客観的な判断を支援してくれる、非常に有用な存在となりました。例えば、技術選定でReact/Next.js、Vue.js/Nuxt、Angularを比較検討しましたが、事前に整理した要件が評価軸となり、最終的にReact/Next.jsを採用する意思決定につながりました。

ひとつ注意したいのは、網羅性にこだわり過ぎてはいけないということです。課題領域を完全に網羅しようとすると時間がかかりますし、そもそも様々なステークホルダーが存在するため現実的に難しいと思います。大切なのは、時間をかけすぎずにできるだけ網羅しようとする意識です。実際に進めていく中で抜けや漏れに気付くことがあるかもしれませんが、それはその時に同様の抜け漏れがないかを確認しながら追加していけばよいのです。

技術運用のケイパビリティを獲得する期間を設ける

PoC期のプロトタイプ開発を通じて、React/Next.js/GraphQLを使ってECサイトを開発・運用するための学びを深めていきました。例えば、現行のURL体系を維持しつつ刷新後のシステムで扱いやすいURL体系とのギャップをどこでどう埋めるかや、状態管理の設計ポリシーとライブラリ選定、Storybookを活用したスキーマ駆動開発のトライアル、GraphQLサーバやクライアントの設計とライブラリ選定、テストの構成と書き方、インフラやブランチ戦略など、挙げればきりがありません。実運用を想定し、どんな選択肢がありどれが要件にフィットするかをひとつひとつ丁寧に検討する中で、私たちの技術運用の実力は飛躍的に向上しました。そして、ここでの知見と経験が、その後の本番導入で大いに役立っていると感じます。仮にこの期間がなく本番導入に進んでいたら、都度課題に直面してスピードが出なかったと思いますし、納期を優先した場当たり的な選択がその後の技術負債となった可能性も高かったと思います。本番導入前に技術運用の土台を築く助走期間を設けることが、その後の成果を大きく左右すると感じています。

ケイパビリティのレベルと局面に応じ、システムの煩雑さを低減する最善手を打ち続ける

実際に本番導入を進めると、組織の技術力が課題のサイズに追いつかない状況が起こりえます。私たちもそのような状況に直面しました。この時、自分たちの実力を正しく見定め、それに見合うサイズの課題に取り組むことが重要です。決して背伸びをしすぎてはいけません。また、取り組む課題についても、それ単体でシステムの煩雑さを低減し、かつ相対的に技術負債になりにくいものを慎重に選んでいく必要があると思います。私たちも、いきなり全体を置き換えようとはせず、ストラングラーパターンで、まず一部のページの一部のUIにReactを導入して、次に一部のビジネスインパクトの小さいページにReact/Next.jsを導入して、というように、自分たちの実力に応じて、少しずつ課題の難易度を上げ、範囲を拡大してきました。このように、ケイパビリティのレベルと局面に応じた最善手を愚直に打ち続けることが、長期的な刷新を成功に導く鍵だと考えています。

アプローチの視野を拡げる

限定的な本番導入期のパートで書きましたが、取り組む課題を決める際、私たちは大きく「新システムの導入」、「現行システムの負債解消」、「組織の再設計・対応」の3つのアプローチから最善の一手を考えました。刷新だからといって、新システムの導入ばかりにとらわれず、現行システムを整理して移行しやすい状態に整えたり、理想とするシステム構成を実現するために先行して組織設計を見直す働きかけを行ったりすることも大切です。視野を広く持ち、取り組みが成果につながるまでの時間軸も意識しながら、その時々の最善の選択をすることが重要だと考えます。

組織目標として合意形成して継続的に取り組む

システムの刷新は基本的に時間がかかるものです。そして、直接的にはエンドユーザへの価値提供につながらず、刷新後になってはじめて間接的に価値を生むことが一般的です。このため、システム刷新に取り組む人は、冒頭で触れた、目の前の事業貢献に直結するタスクを優先する「今」のニーズと、将来の持続的な成長に必要な刷新に取り組む「未来」のニーズとのジレンマに長期間折り合いを付けていく必要があります。この時、システム刷新の目的と重要度が組織全体で認識され、その状態が維持されないと、プロジェクトの存続を巡る社内調整に都度翻弄され、本来注力すべき刷新そのものが前に進まないという本末転倒な状況を招いてしまいます。このような事態に陥らないために、システムの刷新を組織目標として正式に合意し、継続的に取り組める環境を整えることが不可欠だと考えています。

おわりに

今回の記事では、6年強にわたるフロントエンド刷新のあゆみとそこからの学びについてお話ししました。私は、システム刷新の要諦はシステムの煩雑さ（≒エントロピー）を低減することだと考えています。レガシーシステムの煩雑さはあちこちに遍在しているので、最終的なゴールを見失わず、自分たちの実力で扱える最善の課題を切り出して着実に解いていく地道な積み上げがとても重要だと思います。新システムへの移行にこだわり過ぎず、現行システムの改善や組織の見直しなど、できることは多くあります。視野を広く持って取り組んでいくことが大切だと思います。

私たちのフロントエンドのシステムの煩雑さは、開始当初に比べるとかなり改善してきたと感じますが、まだ道半ばです。引き続き煩雑さの解消に取り組みつつ、ECサイトのサービス改善を進めていきたいと思います。私たちの取り組みに興味をお持ちいただけましたら、カジュアル面談などぜひお気軽にお声がけください。