音声書き起こし
1. オープニング
@potato4d
こんにちは。UITのポテトコーデです。ユーザーインターフェイスとテクノロジーを愛する開発者のためのポッドキャストUITインサイド、今回もやっていきたいと思います。今回はですね、PayPayカードとその他のサービスにまたがるUIコンポーネントのVue 3マイグレーションを題材としていきたいと思います。
@potato4d
今回は実際のマイグレーションを担当されたため、もとさんにゲストとして来ていただいております。もとさん、よろしくお願いいたします。
@ytamemot
はい、よろしくお願いします。
@ytamemot
種本祐介と申します。2022年にですね、WebデザイナーとしてYahoo株式会社の方に新卒入社いたしました。配属は金融統括本部の方になりまして、PayPayカードに関する主にフロントエンド周りを中心とした業務に従事しております。2023年にですね、1月にPayPayカード株式会社の方に出向いたしまして、対外的に役割としてはデザインエンジニアのような形として引き続き周りのフロントエンドの業務をしております。
@potato4d
なるほど。フロントエンドエンジニアよりは少しデザイン寄りに、こう、近いような立ち位置で業務してるっていう風なところですね。フロントエンドではあるかっていう風な。
@ytamemot
そうですね、よりデザイナーの方とこう密にコミュニケーションをとるようなところになってます。
@potato4d
本日はUI関連の話もかなり深くなれたと思うんで、よろしくお願いいたします。お願いします。では早速ですが、オープニングで少し複数のサービスにまたがるUIコンポーネントのマイグレーションって話をしたかなと思いますけど、具体的にどういうことをやったかっていう概要を話してもらってもいいでしょうか。
2. プロジェクト概要
@ytamemot
はい、ご存じの通り、2023年にですね、Vue 2系がEOLになりました。で、あとPayPayカードの方でもですね、セキュリティの観点から、マイグレーションの必要がありました。で、カード側ではですね、Web版とミニアプリ版、2つのサービスを提供してまして、両方ともVueで動いてます。なので、この2つのサービスをマイグレーションしないといけないんですけれども、その中で、カード側で共通利用しているUIコンポーネントのマイグレーションも同時に必要となりました。で、このUIコンポーネントはですね、npmのパッケージ化されたものになってますので、別リポジトリで管理されている、そういうパッケージ部分のコンポーネントに関してもマイグレーションが必要ということで、自分が筆頭にそういったマイグレーション作業をしたっていう風なことになってます。
@potato4d
うんうん、なるほどなるほど。ちょうどVue 3に変えるっていうタイミングで、結構こう、広範囲の更新が必要になったので、PayPayカードの開発が結構メインで使っているというか、使っている箇所も多いんで、一緒にサービス内の移行とともに、共通のコンポーネントの方も一緒に対応していったっていう風な形ですかね。
@ytamemot
おっしゃる通りです。
@potato4d
この作業って結構マイグレーションって時間がかかるような。コードベースの量とか、結構古い機能どれぐらい使ってるかとかにもよるかなと思うんですけど、期間とかでまちまちかなと思うんですけど、今回の事例だとどれぐらいの期間でやった形になりますかね。
@ytamemot
こちらは対応期間としては約1か月半かかりましたね。はい。後から見返すとそのぐらいかかってたのかなっていう風に思ってます。はい。
@potato4d
これ、あれですか、機能開発と並行してやっていったみたいな形なんですかね。
@ytamemot
そうですね。機能開発と並行でやってたってことですね。
@potato4d
機能開発止めて一気にやっちゃうみたいなケースもあるかなと思うんですけど、止めずに、かつ共通コンポーネントもっていうところで考えると、結構早い期間でスムーズに終わった感じがありそうですね。
@ytamemot
そうでもなかったですね。
@potato4d
いや、そうでもないですか。なるほどなるほど。じゃあせっかくなんで苦労したところとかあったらこっから聞いていければなと思います。なんか初めに聞きたいのが、1か月半かけて今回マイグレーションっていうのを終わらせたみたいなのがあるかなと思うんですけど、これはもうあれですかね、今の状態としては、共通コンポーネントだけじゃなくて、PayPayカードの本体とか他のサービスも全部に置き換わってるような状態になるんですかね。
3. ビルドツール関連の課題
@ytamemot
PayPayカードのサービス。カード側はVue 2系からNuxt 3に変えましたね。はい。なんかちょっと内部で色々意見があって、開発規模とか、あと体制とかを鑑みてそういった判断になりましたね。で、一方で保険、このデザインコンポーネントは保険側も利用してるっていう風な背景がありまして、保険側のVueのところ、Vue 2系からVue 3にマイグレーションするっていう風な判断になったっていう風な背景があります。はい。
@potato4d
VueからVueのメジャーバージョンアップと、VueからNuxtで一緒にメジャーバージョンアップついでにフレームワークに載せていくっていう風なのが行われたっていう形ですね。ちなみにちょっと本題から逸れますけど、Vue 2からVue 3って自然な移行になるかなと思うんですけど、今回Nuxtにカード側をしたっていうのはなんか理由があるんですか。
@ytamemot
カードの開発規模っていうのがやっぱり大きいので、そのフルスタックなフレームワークに載せた方がなんでしょうね。開発のある程度厳格なディレクトリ構成になってた方が意思疎通とりやすいのかなっていうところと。あとは、カード側はWeb版も提供してるので、SEO周りとかもちょっと考慮したいっていう風なビジネス側からの意見もありまして、じゃあこのタイミングでコストかけてやっちゃおうっていうところでやったっていう風なところで。
@potato4d
なるほどなるほど。シンプルにサービス自体も大きくなるんで、ボトムラインをフレームワークで担保しておくことによって品質安定化させたいっていうところに加えて、SEOだったりサーバーサイドレンダリングとかがやりやすい基盤の方が今後を考えてもプラスなんじゃないかっていうところで移行したって形ですね。
@ytamemot
そうですね。
@potato4d
じゃあ今日はそんなNuxtの話とかもちょっと聞きたいところではあるんですけど、ちょっと共通UIコンポーネントのところで色々聞いていければなと思っております。じゃあ、さっき、意外とスムーズにいかない部分もあったっていうところかなと思うんですけど、なんか実際やっていく中で、このVue 2からNuxt 3にするところ、そしてVue 3にするところに加えて、PayPayカード、Web版、ミニアプリ版で、あとPayPay保険っていう3つが最初にあるUIコンポーネントを触っていくっていう風になったかなと思うんですけど、やって出てきた課題感っていうのはなんかどういったものがあったりしました。苦労したところとか。
@ytamemot
そうですね、カード側の移行スケジュールと、あと保険側の移行スケジュールってのが、後々見ると合わなかったってのが発生して、そこのその合わない部分をどう解決するかっていうところの課題感がありましたね。
@potato4d
なるほど。それは先に、あれですかね、移行してる方向けに提供すると、後方互換性が壊れちゃうみたいな。
@ytamemot
そうですね、具体的に言うと、例えばカード側の方では、Vue 2系からNuxt 3に変えるってところなんで、全く新しく作り変えるみたいなイメージになります。なので、新しいリポジトリを立てて、Vue 2系、ウェブパックで動いているVue 2系から、Nuxt 3で、Viteで動いてるNuxt 3に変えようみたいな話になったんですけど、保険側はVue 2系から、Vue 3系にマイグレーションするんで、Vue 2系のウェブパックからVite化をまずはやって、その最後にVue 3系にする手順になってます。なので、Vue 2系のデザインコンポーネントと、Vue 2系のViteで動くデザインコンポーネントの2つで動かさないといけないような環境を整えないといけない、検証環境を整えないといけないっていう風なところが課題としてあります。
@potato4d
なるほど。最終的にVue 3の世界に行ってしまえば、どのプロダクトもViteになってるんで、ウェブパックのことは考えなくていい。が、Vue 2のプロダクトがあるっていう前提になると、Vue側の方はViteのバージョンとウェブパックのバージョン両方を提供しないといけないっていうのが出てきたわけですね。
@ytamemot
そうです。
@potato4d
はい。なかなかこれってこうなんでしょう。ビルドツールチェーンごとに色々機能差もあって、提供とかややこしい部分も多いかなと思うんですけど、これはどういう風に解決していったんですか。
@ytamemot
お伝えするとあれですかね、機能としては内部で隠蔽するような形を取るっていうなところになってまして、コンポーネント側からしてみれば、そのVite、ウェブパック両方とも共通して動くような構成をとりました。なので、ここに依存しないように関数でラップさせて、外部からVite用、ウェブパック用みたいなところの注入を行うような構成を取ることで、利用側からしてみれば同名関数を使ってるような形を取りました。
@potato4d
なるほどなるほど。それはなんか共通でのものを呼び出してるっていう風な形になって、その呼び出した先の処理が異なるって形になるかなと思うんですけど、呼び出すインターフェースとしてはどういう形を取ったんですかね。
@ytamemot
そうっすね。結局開発環境さえを提供できればいいので、結構シンプルな形を取りました。具体的にはVueのプロトタイプ機能ですかね。例えば使って同名のグローバルな変数に対して同じ関数名を用いて、内部の具体的な処理ってのはVite、ウェブパック違うっていう風なことをすることで、同時にはそれぞれ別の世界で動かせるよねっていう風なところをやりましたね。
@potato4d
じゃあ、プロトタイプのところの処理っていうのを、そのViteの場合とウェブパックの場合で処理が違うように区別しておいて、ランタイムで使っているツールチェーンによって最適化された処理が行われるみたいな形に集約することによって、こうなんでしょう。デザインコンポーネントを本体の方では何も書かなくていいっていう風な形にしたっていう風な。
@ytamemot
そうですね、おっしゃる通りです。はい。まず、
@potato4d
Viteの状態であったら、そのプロトタイプって結構Viteの時代だと気軽に使えるというか、気軽に使う文化圏なんで、扱いやすい場所として使えますし、一時的なものであれば、なんかこう、ずっとプロトタイプでメンテナンスするってなると大変かもしれないですけど、なんか気軽に生やせて扱いやすいっていうところでは、かなりなんか良さそうな感じがしますね。このプロトタイプへの注入みたいなのは、なんかそれぞれのあれなんですかね、ツールチェインの方で注入するコードみたいなのを軽く書いておいて、ウェブパックの場合はこうでこうっていう風な形でやったってところですね。
@potato4d
はい、そうですね。じゃあ、結果的には、もうランタイムのところに行くまでには全部そういったツールチェーンの差っていうのは吸収されていて、ランタイムでどっちかっていうのが確定してるっていう風なところですね。
@ytamemot
はい、おっしゃる通りですね。
@potato4d
これ、なんか、プロトタイプにするにあたって、結構その既存のコード自体も多少は触らないといけない部分があったかなと思うんですけど、大体あれですかね、ほぼ一括置換というか、シンプルに機械的に置き換えていくだけで済んだって感じですか。
@ytamemot
そうですね。幸いそこまで依存するような、その各Viteウェブパックで依存するような処理ってのが広範囲になかったっていうのもありまして、このぐらいの範囲だったら1個1個手書きで変えていってもまかなえるような量だったので、結構こうシンプルに愚直に変えていったっていう風なところですね。
@potato4d
なるほど。そんなに多くないって話でしたけど、具体的にはなんか置き換えたやつはどういった処理を置き換えていきましたか。今回は
@ytamemot
例えばなんですけど、動的インポート回りですかね、のがありまして、で、例えば、ウェブパックの場合は、インポートを、ほにゃららで、チルダーを使って、こう、ファイルとかを動的にインポートするような、なんか使い方みたいなのがあったりするんですけど、Viteだと、その動的なそういうインポート、かつ、こう、変数名も入れたいケースですね、そういうケースの時に、うまくViteが動かないっていう風な時なので、動的インポート、かつ、そのインポートする先が、こう、どこの変数名を使うみたいなケースですね、そういうケースとかはいくつか箇所があったんで、それをどう、うまい具合に差分なくして、エラーを出さないようにしようかなっていうので。はい、ところですね。
@potato4d
確かになんかそもそもあれですもんね、チルダーを使ったりみたいなエイリアス機能って、ウェブパックとかだと結構みんなたくさん設定してますけど、Viteとかだと、なんかそういう文化圏からちょっと離れたりしますし。あとこう、あれですもんね、ダイナミックで処理するにしても、ダイナミックの処理の仕方が、なんかウェブパックは割と柔軟っていうか、なんでもできるみたいな形になってますけど、なんかViteはちゃんと最適化するために、こう、ある程度綺麗に書かないといけないみたいな部分もあるんで、ちょっと吸収しないといけない部分があったっていう風な形ですよね。
@ytamemot
そうなんですよね。はい。なので、その辺も踏まえてですね、対応したっていうところですね。
@potato4d
なんかあれですね、共通コンポーネントなんで、やっぱりチャンクとかでの単位の最適化みたいなのも重要ですし、このあたりはなかなか、確かに頭を悩ませる部分ではありそうですね。
@ytamemot
そう、そうなんすよね。こっち触ると他のところで落ちるし、ではViteを最適化するとウェブパックで落ちるみたいなんで、どうしようこれみたいなのが、あれ、やっぱ対応する時はありましたね、思い返すと。
@potato4d
だけど、こう、あれですね、地道に潰していって、なんとか終えることが今回はできたかなっていう風なところですね。
@ytamemot
そうですね。
@potato4d
これ、最終的にはもう今の状態としてはあれなんですが、このVite版のコンポーネントってのはもう役目を終えているような。このViteとウェブパックのやつは役目を終えてて、基本的にVue 3の世界に来ることはできてるみたいな感じなんですかね。
@ytamemot
はい、もうすべてVue 3の世界にできて、はい、一応パッケージとしてはVue 2のやつは残してるんですけど、一応。はい、一応。はい、そうですね。ただ、もう全部Vue 3に変えましたね。
@potato4d
でもあれですね、あとは落とすだけというか、そのライブラリーをデプリケートにする、それをどっかでやればひとまず終わりって感じですね。ありがとうございます。なんか、他になんかビルドツールチェイン周りが結構やっぱり今の話聞いてると課題だったのかなと思うんですけど、その他で困った部分であったりしましたか。
4. その他の課題と対応
@ytamemot
UIコンポーネントをやる中で、
@potato4d
そうですね、UIコンポーネントのところでと、
@ytamemot
やっぱりVeeValidate v4対応がきつかったですね。多分これほほ、いろんな箇所でも多分語られてるとは思うんですけど、VeeValidate、そういうサードパーティー周りのライブラリーのアップデート対応ってのが、そういうツールチェーン以外だと結構しんどかったですね。
@potato4d
やっぱりあれですよね、こう、Vueみたいなの移行していくってなったら、周辺ライブラリのアップデート、特にメジャーバージョンアップデートの水準って大変になりがちですし、なかなか苦労する部分はありますよね。
@ytamemot
そうですね、
@potato4d
はい。UIコンポーネントとしてはVeeValidateの他にはなんか使ってるライブラリー結構あったんですか。
@ytamemot
Vite依存に関しては、VeeValidateと、あとはsvg-loaderとか、なんかそういう、SVGを、さっきのその動的にファイル引っ張ってくるみたいな、まさにそこなんですけど、svg-loaderで動的にSVGファイルをコンポーネントとして提供するみたいな、このVite用のsvg-loaderみたいなところの差分とかでもそんなぐらいですかね。
@potato4d
じゃあ、結構ランタイムレベルで困ることはVeeValidateもくらいだったって感じですかね。
@ytamemot
そうですね。もうこれが1番重かったと言っても過言ではないですね。
@potato4d
実際あれですか、1か月半のうち結構な時間をVeeValidateにやっぱ取られた感じですか。
@ytamemot
結構。そう、結構な時間取られましたね。長期的にわりとその工数が削られた上の、その両対応のやつは1個型ができれば、その適応してるだけっていう、なんで。そこに行き着くまでがしんどかったんですけど、VeeValidate v4はこう、1歩進んで、立ち止まって1歩進んでっていうのがいっぱいあったイメージがあり、これが1番しんどかったですね。はい、実は。
@potato4d
確かになんかやるたびにあれですもんね、その、ここ触ってたら、ここVeeValidateのこのAPI依存してるじゃんみたいなのになって、予想より手戻りが発生するみたいなんが頻発するって感じですもんね。
@ytamemot
そうなんですよ、
@potato4d
はい。これもあれですかね、もうこっちに関してはもうほんとに地道に1つずつ片付けていくしかないって感じですよね。
@ytamemot
そうですね。1番最初にどんなぐらい破壊的な差分があるかっていうのを調べてやったんですけど、結局ちょっと後戻りしましたね。
@potato4d
やっぱそうですよね。わかります。なるほど、ありがとうございます。大きくはこの2つで時間をかけて1か月半ぐらいで終わったかなっていう風なところですね。
@ytamemot
はい、ありがとうございます。
@potato4d
かなりなんかあれですね、イレギュラーなケースというか、やっぱりこう、古いものは古いもの、新しいもの新しいものっていう風に分けて、例えば今回のケースとかだと、Vue 2はもうウェブパックだけとか、Vue 3はViteだけみたいなのが多いかなと思うんですけど、なんかそこを複数対応していくってのが、やっぱり今絶賛稼働中のサービス、複数が利用してるからこそだなと思いますし、その中で妥協しないってなると、やっぱりこう、古いバージョンでも最新の技術に対応していくみたいなのが必要になるかなと思うんですけど、なんかうまくそこを両立してやったっていう風な感じなので、すごい面白かったです。ありがとうございます。
@ytamemot
ありがとうございます。
5. 次回への改善点と学び
@potato4d
せっかくなんで、なんかもう1点聞いてみたいなって思ったのが、今回このいろんなアプローチをそれぞれの課題に対してやっていったかなと思うんですけど、なんか今回のマイグレーションを得て、例えばうちの会社とかだと、例えばLINE、Yahooだと、結構いろんなプロダクトで同じような課題感を持ってたりとか、いろんなプロジェクトで、それぞれ最近のマイグレーションをやっているプロジェクトもあるかなと思うんですけど、なんか今回、自分たちの知見をベースにして、なんか他のプロジェクトが同じような、こうシチュエーションであった場合、なんか次はこういう風にやると良さそうとか、なんか自分が同じことを例えばやることになったら、次はこういう感じでやりたいっていう風に思ったこととかあったら聞いてもいいですか。
@ytamemot
そうですね。やっぱり今回の話で言うと、そのカードだけが使ってるようなそのパッケージじゃないっていう風な前提があるので、そこのそもそも両立が増えた背景としては、保険側とのスケジュールのコミュニケーション、ミスコミュニケーション取ったとしても無理だったかもしんないんですけど、そこのコミュニケーションもっと取ってれば、もう少し工数減らせたのかなっていう。あんまりそこ、まとってたつもりではあったんですけど、もう少し密にしたことで、じゃあもっと最適な方法を早期に考えられたのかなっていうのがあるので、いろんな関係者がいるようなマイグレーション対応の場合は、関係者集めて一旦合意とって、そういう風に進めていった方が良かったのかなって。ちょっとなんか進め方みたいな話になっちゃうんですけど、ちょっと技術的な話ではないんですけど。はい、そういうところかなっていうふうに思いましたね。
@potato4d
なんで、あれですよね、こう影響範囲が大きいコンポーネントっていうのは、やっぱり足並み揃えていかないと、なかなか差分の吸収っていうところにいろんなコストをかけることになるんで、スケジュール感っていうのが、こう、足並み揃ってるといいよねっていうのが1番って感じですかね。
@ytamemot
そう、そうですね、はい。
@potato4d
なんか、インクリメンタルにすればするほど影響範囲は小さくできますけど、その分対応量ってのは増えちゃいますもんね、やっぱり。
@ytamemot
はい、そうですね。
@potato4d
なんで、今回のあれですね、技術的なアプローチとしては、このViteとウェブパックの両対応っていうのは、結構やり方としてはうまくいったかなっていうのはありつつも、両対応しなくていいような形とかにできるとベストかもっていう風な感じですかね。
@ytamemot
はい、そうですね。あとは、部内でもっとその他のカードだけじゃなくて、LINEの方のその知見のある方にもいろんなお話を聞いときゃよかったっていう風に思いますね。
@potato4d
結構多い系の話はあるんで、事前に最近やった人に聞いてみるみたいなのがあったらもっと円滑だったかもな、みたいな。
@ytamemot
そう、そうなんですよね。
@potato4d
いや、でも、なんかあれですよね、ちゃんと技術的なテクノロジーでの解決をやりつつ、なんかそれをしないで済むのが1番楽っていうのは、なんかある意味1番良い。いいって言ったら変ですけど、なんか技術的に解決やるすべを持ちながら、それをやらないっていう、やらないで済むようにやるってのがなんか1番な選択肢でもある気がする。んで、
@potato4d
なんか次以降似たようなケースとかあったりとか、今ちょうどこれからマイグレーションを考えてる人とかがいるのであれば、なんかできるだけあれですね、その事前の段階ってところで解決できるといいかなってとこですね。
@ytamemot
はいですね。
@potato4d
ありがとうございます。最後に、クロージングに入る前にもう1つ話そうかなと思います。で、今ここまでですね。色々お話聞いていきましたが、少し技術的な具体としで、こういうことやってましたみたいな、コードベースを交えた解説みたいなところはですね、実は4月に谷本さんがLINE株式会社名義でMDN Webというイベントで登壇しておりましてですね、その資料の方に載っておりますので、紹介欄に掲載しておきますので、ぜひぜひ、興味ある方はですね、実際のコードベースなどなど見ていただいて、参考にしていただければと思います。
@ytamemot
ありがとうございます。宣伝
@potato4d
じゃあこのままクロージングの方に移ろうかなと思います。というわけで、今回は、PayPayカード、PayPay保険の2つのサービスにまたがるUIコンポーネントをVue 3にマイグレーションしていくまでにやったことっていうところについて本さんにお話いただきました。LINE Yahoo株式会社では、このようにフロントエンドに関する議論や意見交換といったものを日々行っております。社内の勉強会から生まれたポッドキャストのエピソードみたいなものをこれまでたくさんありますので、今後とも外部に発信していける情報はどんどん発信していこうかなと思います。というところで、本日はたもとさんにお越しいただき、PayPayカード、PayPay保険のサービスにまたがるUIコンポーネントのマイグレーションについて話してもらいました。ありがとうございました。
6. クロージング
@ytamemot
ありがとうございました。
