ウェブサイト「みんなのBaaS」をリニューアルした話
みんなの銀行のマーケティンググループ オウンドチームでは、ウェブサイト「みんなのBaaS」のリニューアルを行いました。
🏦ウェブサイト「みんなのBaaS」（2024.8.7 リニューアル）
https://baas.minna-no-ginko.com/
みんなの銀行では、個人向け金融サービスを提供する一方で、パートナー企業の皆さまにAPI（※）を通じてみんなの銀行の金融機能やサービスを提供するBaaS（Banking as a Service）事業では、「金融」と「非金融」がシームレスに結びついた新たな価値の共創を目指しています。
BaaS本格スタートとなる2024年度、金融サービスの導入を検討中もしくはこれから検討する事業者の皆さまに「BaaSの活用イメージ」をより分かりやすくお伝えしていくために、マーケティンググループ オウンドチームでは、ウェブサイト「みんなのBaaS」のコンテンツを拡充しました。
今回のマーケティングマガジンでは、サイトリニューアルにあたっての課題や技術選定、実際に導入してどうだったかについて、フロントエンドエンジニア目線でお話しできればと思います。
※Application Programming Interfaceの略で、銀行と外部の事業者との間の安全なデータ連携を可能にする仕組みのこと。
リニューアル前：ウェブサイト「みんなのBaaS」の課題
リニューアル前のウェブサイト「みんなのBaaS」は慣性スクロール（※1）とGSAP（※2）を使ったワンページのウェブサイトでした。
※1 慣性スクロールとは、主にマルチタッチインターフェースで採用されている機能で、画面を素早くスクロールさせた際、指を画面から離しても急には止まらず、慣性が作用しているようにスクロールがある程度維持される機能のことである。
※２ JavaScriptライブラリの「GSAP（ジーサップ）」はウェブサイトのモーション制作に役立ちます。GSAPは高機能であり、実行性能が良好で、互換性も高い利点があります。
開設当時からいくつかの経緯を経て、全体的に表示速度が遅いことが悩みでした。体感だと2秒くらい待ってしまいます。そこがボトルネックとなって離脱による機会損失が生じていたのは自明の理です。
少し古いものとなりますが以下の『Think with Google』の記事では、ページの表示速度が1〜3秒の場合は離脱率が32%。1〜5秒の場合は90%、1〜6秒の場合は106%、1〜10秒の場合は123%上昇することが書かれています。
モットーは「より早く、より見やすく、よりストレスフリーに」
マーケティンググループ オウンドチームでは、「より早く、より見やすく、よりストレスフリーに」をモットーにウェブサイトづくりに取り組んでいます。このモットーを貫くべく、技術選定を行いました。
技術選定とSvelteKitを採用したその理由
プレーンなHTML・CSS・JS（JavaScript）
これらは原始的で直観的ではあるものの、目指す方向とは異なり簡易的となるため、除外しました。
MPAフレームワーク
コンテンツを拡充する今回のサイトリニューアルでは、SPA（※1）フレームワークではなく、有名どころのMPA（※1）フレームワークAstroが有効ではあるものの、Astroはコンテンツ量に対しての機能量がマッチする印象を受けなかったため、除外しました。
※1 現在、ウェブ開発には、SPA（Single-Page Application）とMPA（Multi-Page Application）の2つの主要なアーキテクチャ パターンがあります。
SPAとは、アプリが取得または提供するデータに基づいて、ページのHTMLレンダリングのほとんどまたはすべてをクライアント側のJavaScriptに制御させることで定義されます。アプリはブラウザの組み込みナビゲーションをオーバーライドして、ルーティングとビューの処理機能に置き換えます。
MPAは通常、プリレンダリングされたHTMLをブラウザに直接送信します。多くの場合、ブラウザがHTMLの読み込みを完了した後にクライアント側のJavaScriptで拡張し、ブラウザの組み込みのナビゲーション メカニズムを使用して後続のビューを表示します。
JSフレームワーク
JSフレームワークには、Nuxt、Next、qwick等の複数の選択肢がありますが、今回は今後のことも鑑みて、癖が少なくまた知見のあるSvelteKit（※2）を採用しました。
※2 SvelteとViteを使った Webフレームワークで、高速で楽しく柔軟な開発を可能にします。
ちなみに2024年6月にオープンしたみんなの銀行 採用サイトも、Svelte + esbuildを採用しています。
🏦みんなの銀行 採用サイト（2024.6.28 オープン）
https://corporate.minna-no-ginko.com/careers/
JSフレームワークは、非フロントエンドエンジニアから見ても、分かりやすいコンポーネントを作ることができます。
またルーティング（※3）も、ディレクトリ構成で定義されるため、非常に分かりやすいです。
※3 SvelteKitの中心は、ファイルシステムベースのルーターです。アプリのルート（routes）、例えばユーザーがアクセスできるURLパスは、コードベースのディレクトリによって定義されます。
実際にSvelteKitを導入してみて
大きな点として、アクセシビリティにおいてA11y（※5）という指標に達成していないと開発時に警告を出してくれるため、Lighthouse（※6）上で容易に高いスコアが出せました。
※5 ウェブアクセシビリティ（略語：A11Y、AccessibilityのAからYまでの間に11文字が挟まれているため、このように略す）は、身体的および技術的な制約によらず、ウェブサイトを使いやすく保つためのベストプラクティスです。ウェブアクセシビリティは、W3CのWeb Accessibility Initiative（略称：WAI）によって、標準化と議論がされています。
※6 Lighthouse は、ウェブページの品質向上に役立つよう開発されたオープンソースの自動化ツールです。任意のウェブページ、公開ページ、認証要求ページに対して実行できます。パフォーマンス、ユーザー補助、プログレッシブ ウェブアプリ、SEO などの監査を実施しています。
他のスコアも、サードパーティスクリプト（外部のプロバイダや開発者によって提供されるJavaScriptコード）の影響はあれど、悪くはない数字を出すことができました。いわずもがな表示速度の遅さ・遷移時のわずらわしさは、当初の狙い通り解消されました。
また、副次的な効果もありました。
あらかたコンテンツの実装が終わった時に、表示速度を遅くするLCP（Largest Contentful Paint）改善のために、画像の出し分けをRetina（高解像度でハイコントラストな色彩表現を可能としたディスプレイ） / 非Retinaで行う必要が出てきました。
手動で画像を管理するには、デザイナーの工数や手戻り、Retinaは対応したのに非Retina画像の差し替えが漏れていたなどのリスクが発生します。
Svelteの公式ライブラリとしてリリースされているものに、「@sveltejs/enhanced-img」という画像最適化ライブラリがありますが、これを採用した結果、次世代画像フォーマットであるAVIF、webP等の拡張子に対応しているブラウザに見合った画像でローディングしてくれるようになりました。
それにより社内のデザイナーに拡張子画像の生成を依頼する必要がなくなり、HTML側でsrcsetを書く必要もなくなり、シンプルになりました。
また画像の置き場をsource(src)配下にすることで、どの画像が加工されているかも明白になりました。 これによって運用時にも画像を1つ連携するだけで済みます。
おわりに
SvelteKitを採用したことで、結果として「開発体験もよく、ユーザーにとってもストレスフリーで閲覧できる」“いいとこどり”になったので良かったと思います。今後も顧客体験ファーストでより良いウェブサイトを開発していけたらと思います。
筆者紹介
池田 祐輔
みんなの銀行 マーケティンググループ フロントエンドエンジニア。色々を経てクリエイティブエージェンシー、モビリティ企業にてフロントエンドエンジニアを担当。その後、2023年8月にみんなの銀行に参画。主にみんなの銀行が手掛けるサービスサイト、コーポレートサイト等々を担当。
👇マーケティングマガジンの記事一覧はコチラ！
👇みんなの銀行 採用サイト｜現在募集中の職種はコチラ！
https://corporate.minna-no-ginko.com/careers/job-descriptions/marketing/digital-marketer/
👇デジタルバンクのプロジェクトは、なぜ生まれ、どのように開発が進められてきたのか。こちらの本も合わせてお楽しみください！