事業成長を加速させるフロントエンド改善
山下功介 氏：「事業成長を加速させるフロントエンド改善のお話」というタイトルで発表させていただきます。
まずは自己紹介です。ヘイ株式会社STORES.jpでフロントエンジニアをしております、山下功介と申します。前職では、ベトナムのHRTech領域のスタートアップでフロントエンドとして働いておりました。主にVueとReactが好きです。
まず会社の紹介です。heyはSTORES.jpと、クレジットカード決済と電子マネーを提供しているCoineyの経営統合によって生まれた会社です。
STORES.jpは、誰でも簡単にオンラインが作れるサービスで、自分ではなかなか持ちづらい9種類の決済方法でしたり、独自ドメインの取得など多数の機能を提供しております。
STORES.jpのフロントエンド環境
本題に入りまして、昨年までのSTORES.jpのフロントエンド環境についてお話しいたします。
まずストアページとそのストアのオーナーさんが管理するストアオーナー用のページが主な機能になっており、それらが去年まではRailsのモノリシックな環境で構築されていました。その中でERBのテンプレートと、AngularJSもv1.3を使っておりました。
そこでAngularJSからVue.jsへの移行を始めました。
それと同時にフロントエンドチームの発足もされました。フロントエンドチームはもともと1人で発足されたので、約1年で7倍ですね。7人のメンバーが増えました。
まずはコアとなるストアデザイン機能というものがありまして、その機能の開発着手に進みました。約5ヶ月かけてストアデザイン機能をリリースいたしました。
当初の見積もりは2ヶ月だったのですが、それが5ヶ月と2倍以上に膨れ上がってしまいました。これはなぜか？ 大きな理由は開発スタートとチームの誕生、そしてメンバーの急激な増加。これが一気に重なったことにあります。
今まで基盤が一切できていない中で進めていたので、開発スピードを上げるためには一定の基盤の構築やルールのところに時間のリソースを割いていかなければ、長期的な加速は見込めないと判断し、約3ヶ月を基盤の構築に費やすことになりました。
その中で見えてきた課題がだいたいこちらですが、今日は10分しかないのでこの3つに絞ってお話させていただければと思います。
ますコンポーネントルールです。コンポーネントはいろんなメンバーで開発をしているので似たようなコンポーネントが乱立していました。異なる粒度のコンポーネント……大きすぎたり小さすぎたりするコンポーネントがありました。STORES.jpは複数のリポジトリがあるので、他のリポジトリでも使いたいという課題がありました。
それに対してStorybookを使ったUIコンポーネントライブラリを作成しました。作った数は現状で30種類のコンポーネントで、主に複数のリポジトリで使えるようにライブラリ化をしました。あと、デザインが今まであまり揃っていなかったのですが、デザインシステムを構築し、デザイナーを巻き込んでそこから開発をするようにしました。
主に作ったコンポーネントはこのようになっております。ボタンやフォーム、ダイアログなどがあります。その他、ここに出ていないものも作りました。
主に改善とつらみですが、改善できたことは大幅な記述がいらなくなったことです。ロジックや各ドメインにリソースを割けるようになりました。そしてデザイナーともUIの共通認識もできましたので、ちょっとデザインが違うときに「ここどうなっているの？」という確認がし易くなりました。
つらみですが、100件以上の修正issue。これがプロジェクトを進めていく上でここを直さないと次に進めないことがけっこう起こってしまいました。あと長期的に運用するにあたって後方互換の考慮も必要です。このあたりはけっこうつらいですね。仕様もしっかり決めていかないとなかなか厳しいところがあります。
あとはバンドルサイズがものすごく肥大化してしまう問題もありました。今で116キロバイトあります。ElementUIがあると思うんですが、あれのコアファイルで140ぐらいですね。うちはそんなにまだ機能が揃っていないのにこれなので、ここに関してはこれから更に肥大化していくのでちょっと見直しをしていかないといけない部分になります。
レビュー環境の見直し
次にレビュー環境の見直しです。レビュー環境はローカルのチェックアウトがとても面倒で、IEだったりスマートフォンの立ち上げはけっこう面倒くさいですよね。あとデザイナーに「ちょっと見せてよ」みたいなことを言うときにすぐに見せれなかったり、ローカルに立ち上げてもらう必要があります。
それをCircleCIとLambda@Edgeで解決しました。これで生成されるプレビュー環境はステージング環境で実装内容の確認ができます。そして1つのプッシュに対して1個のURLが発行されるような仕組みになっていまして、内容はこんな感じです。
GitHubのプルリクエストが作成されるとnuxt.jsのビルドが走って、その結果をプルリクのナンバーごとにS3に保存していきます。レビュアーはLambda@Edgeの認証を経てCloudfrontを経由しプレビュー環境にアクセスします。なお、サブディレクトリに直接アクセスすると404でエラーになってしまうため、Lambda@Edgeでデフォルトルートのマッピングを行う必要があります。
これによりレビューコストの軽減ができ、IE、SPで気軽なプレビュー環境が作成できました。先ほど申し上げたとおり、サブディレクトリへのアクセスには工夫が必要というところと、APIがデプロイされている必要があるので、そこが注意が必要です。
次に行ったことがテストの効率化です。UI周りのテストの書き直しが非常に面倒だったり進捗が遅れてくると、テストが後回しになりやすかったりします。そしてなるべく楽をしたいというところもあります。
そこで使ったのがREG-SUITを使ったVisual Regression Testingです。
左と右の画像を見比べていただくとこういったかたちで差分を表示してくれます。その内容をプルリクエストにコメントくれます。この赤い丸の数が主に変更になった、修正のファイル数になります。
こういった感じでスタイルの崩れチェックが可能です。
これもGitHubのプルリクエストを作成してStorybookのビルド、zisuiというライブラリでスクリーンショットの撮影をして、リグレッションテストでそのスクリーンショットとS3に保存しているマスターブランチの画像を比較します。その比較結果とスクリーンショットをS3に保存し、プルリクエストに比較結果をコメントしていきます。
これによって見た目関係のテストの簡略化やリファクタリング時の精神的負荷の軽減を得ることができました。導入も比較的容易にできると思います。ただ、イベントだったりのアニメーションのテストはできないというところ、あと差分が多い場合は人力でのチェックになるのでどうしても見落としが出てくるところはあります。
チームとしてのスピード感がアップ
最後にまとめです。チームとしてのスピード感は改善を通してだいぶ上がってきました。ただ、まだまだ未解決の問題もあります。仕様書が揃っていないことでしたり、見積もりの精度が甘いところ。これはどう解決しようかと検討している最中です。あとパフォーマンス改善のところには、まだまったく手が回っていない状態になっています。
なので、どなたか良い知見があれば教えていただけるとすごい助かります。
最後に個人成長ができた点というところで、実は私は4月に入社したばかりで3ヶ月しか経ってません。
このBCUなんですけど入社5日目に社内で募集がありまして、ちょっと手を挙げてみたら意外とすんなり確定しちゃったんですね。
ドメインだったり技術だったり、歴史的背景もわからないことだらけだったので、社内ツールを遡りまくって先輩に聞きまくって手探りでやってきました。そのおかげで歴史を通しての課題感とかもわかりましたし、その乗り越え方も身についてきました。これがけっこう大きな個人成長だと思います。
最後に、まだ募集は常にしているので気になる方がいらっしゃいましたら、「Hello hey」という隔週で木曜日にイベントをやっております。これは誰でも参加できますので、ぜひ気になる方とかエンジニアと話したい方がいらっしゃいましたら、ぜひこちらに参加していただければなと思います。発表は以上になります。ありがとうございました。
(会場拍手）
