こんにちは。モノタロウでECサイトの開発・運用を担当している辰巳です。
モノタロウではECサイトのフロントエンド刷新に取り組んでおり、その内容をブログで共有したいと思います。よろしければ、関連記事もあわせてチェックしてみてください。
- Vue.js？React？フレームワーク選びの７つの選定基準、大規模ECサイトのフロント刷新プロジェクト
- モノタロウのフロントエンド刷新の取り組み①～大規模ECサイトのフロントエンドをドメイン単位で再設計した話
- モノタロウのフロントエンド刷新の取り組み③～「小さく早く試す」UIコンポーネントの整備
- モノタロウのフロントエンド刷新の取り組み④～BFF×GraphQL導入の狙いとスキーマ設計の試行錯誤
「モノタロウのフロントエンド刷新の取り組み①～大規模ECサイトのフロントエンドをドメイン単位で再設計した話」では、ECサイトのUI/UX高度化と開発生産性向上に向けたフロントエンド刷新の取り組みの概要を紹介しました。今回の記事では、この取り組みの主目的のひとつである開発生産性向上において、現在確認できている効果を定量的、定性的にお話ししたいと思います。
当初期待していた効果
フロントエンド刷新の取り組みを本格化する前に、社内で活動の合意を得るため（このあたりの取り組みや学びは改めて別の記事で紹介したいと思います）、開発生産性の効果、具体的には開発リードタイム短縮の効果を見積もりました。開発に1ヶ月程度（25人日）を要する案件を対象に、刷新前後で開発工数がどう変化するかを見積もりました。手戻りは仮に工数の20%発生する前提としています。
| （人日） | |||
| 刷新前 | 刷新後 | ||
| （ステップ1）スキーマ駆動開発とStorybookによる開発プロセスのモダン化 | （ステップ2）左記に加えて、UIコンポーネント/BFFスキーマの共通化 | ||
| 開発工数 | 25（手戻り +5） | 22（手戻り 0） | 15.5（手戻り 0） |
| 削減率 | － | ▲12% 手戻りあり ▲27% |
▲38% 手戻りあり ▲48% |
刷新前の案件開発では、Pythonのサーバサイド処理（レンダリングを含む）とTypeScript/jQueryのクライアント処理を複合した開発が必要で、それぞれ依存関係があるため、全体を一気通貫で開発しないと最終成果物を確認しづらい状態となっています。このため、課題が見つかるタイミングが遅く、結果的に手戻りの工数も大きくなりがちです。これに対し刷新後は、表1のステップ1にあるように、スキーマ駆動開発でUIとロジックを独立して開発できるようになったり、Storybookで見た目や動きを確認しながらUIを開発できるようになったりすることで、開発工数を12%（手戻り考慮で27%）削減できると考えました。また、表1のステップ2にあるように、UIコンポーネントやBFFスキーマの共通化を進めることで、開発工数を38%（手戻り考慮で48%）まで削減できると考えました。さらに、並行開発が容易になることで、工期はそれ以上に短縮できると考えました。
実際の効果
開発工数
今回、移行の都合上 刷新前後で同じ案件を開発する機会があり、これを対象に開発工数の変化を実際に計測することができました。案件はECサイトの検索ページでファセット部分のUIを大幅に見直すものでした。
| （人時） | ||
| 刷新前 | 刷新後 | |
| 開発工数 | 91 | 60 |
| 削減率 | － | ▲34% |
現在は、UIコンポーネント/BFFスキーマの共通化（表1のステップ2）の恩恵を十分享受できる状態にまではなっていないのですが、スキーマ駆動開発とStorybookによる開発プロセスのモダン化（表1のステップ1）による予想を大きく上回り、開発工数を34%削減できていることが確認できました。
プルリクエストのリードタイム
モノタロウでは組織横断で開発生産性向上に取り組んでおり（*1）、その中でプルリクエストのリードタイムをシステマティックに計測しています。その代表的な値としてプルリクエストの最初のコミットからマージされるまでの時間（以下、commit2merge）があり、これを刷新前後のリポジトリで比較しました。図1の通り、この時間が大幅に短縮できていることも分かりました。
考察
このように当初の想定を上回る開発生産性の定量的効果が得られていますが、その要因はシステムのモジュール化に負うところが大きいと考えています。もともと、スキーマ駆動開発でUIとロジックをモジュール化できると考えていましたが、UI内部もコンポーネント単位でモジュール化してStorybookで開発できるようになりました。このため、モジュール単位でスコープを限定して小規模にかつ独立して開発することが可能となり、結果的に開発しやすく手戻りも少ない状態を実現できています。また、プルリクエストの変更内容や変更行数も自ずと制限されるため、レビューを含めて作業が効率化され、プルリクエストのリードタイムの短縮につながっています。モジュール化は、問題領域を限定してコンテキストに縛りを与えられる点でAI駆動開発（*2）との親和性が高く、効果のさらなる積み増しも期待できそうです。
一方、この効果を下支えしているのが標準化/共通化された基盤となりますが、その整備や保守が滞ると、効果が薄れたり技術負債が生じやすくなったりします。現在もNext.jsやReactなどのライブラリのバージョンアップ、共通モジュールのnpmパッケージ化など、基盤の様々な課題に取り組んでいますが、効果の維持・向上には基盤への継続的な投資が不可欠と考えています。
おわりに
今回の記事ではフロントエンド刷新による開発生産性の定量的・定性的効果をお話ししました。引き続き、基盤の整備と基盤を活用したECサイトの強化に取り組んでいきますので、私たちの取り組みに興味をお持ちいただけましたらカジュアル面談などお声掛けいただけるとうれしいです！
参考資料
*1 組織横断で取り組む開発生産性：失敗から学んだ本当にやるべきこと
*2 モノタロウのAI駆動開発の全貌をご紹介します
