#48「ミツエーリンクスのコーポレートサイトリニューアル」

加藤: 皆さん、こんにちは！ ミツエーリンクスの加藤です！

佐竹: 佐竹です！

加藤: はい、では今回もミツエーテックラジオやっていきたいと思います。ミツエーテックラジオは、株式会社ミツエーリンクスのスタッフが、Webデザイン、 Webフロントエンドなどの、Web技術に関するニュースやツールをシェアするポッドキャストです。前回のエピソードからちょっと期間が空いてしまいましたが、皆さまいかがお過ごしだったでしょうか？

佐竹: この期間に、色んなことがありましたね。

加藤: そうですね。いつの間にか年も明けてますよ！

佐竹: ですね。でも一番のトピックスはミツエーリンクスのコーポレートサイトをリニューアルしたことじゃないですか？

加藤: そうですね。採用サイトとか英語ページとかブログなどは除いて、日本語の静的ページを中心にリニューアルを行いました！なので、今回はそのリニューアルについての振り返りトークといってみましょう。

佐竹: はい。まず私の話からになるんですけど、私は制作者で入社してから初めて自社サイトのリニューアルを担当したんですね。で、自社サイトの場合、ある程度、自分たちで方向性だったり、進め方を決めたりする必要があるんですよね。

加藤: あー、まぁ確かにそうですね。自社サイトの場合は、受発注の関係が存在しないので、プロジェクトの全てのプロセスにおいて自分たちが主体的に動いて完結させる必要があるっていうのは、普段のプロジェクトとは大きな違いかもしれないですね。

佐竹: はい。私は開発者として技術的な要件を決めたり、技術選定をしたりすることはあるんですけど、そこまで上流工程に関わることは多くなかったので、プロジェクトに依って役割が違ってくることもあるんだなぁということに気がつきました。

加藤: うん。なるほど。私はあの立場上なのか分かりませんけども、通常のプロジェクトでもテクニカルディレクション的な役割が多くなってきてて、まぁ普段とあまり変わらない感じだったんですけど、制作者目線だとそんな風に見えてたんですね！

佐竹: そうなんですよ。でも、普段、自分からは見えないところで色々な役割、役職の人たちがどういうことを考えながらサイトを作っているのかを知るいい機会になりましたし、今回のリニューアルは情報設計は変えずに、見た目を刷新するプロジェクトだったので、最初はまぁ戸惑いましたけど比較的やりやすかったかなと思いました。

加藤: そうですね。あと自社のサイトでは、あのー、チャレンジングなことにも取り組みやすいので、リニューアルでは毎回チャレンジテーマみたいなものを決めていて、たとえば前回2019年のリニューアルではダークテーマを取り入れてみたり、今回はデザインシステムの構築を目指しながら進めてみましょう、という話をしました。

佐竹: はい。チャレンジテーマが決まったことで、取り入れてみたいこととかの意見も色々出しましたよね。えっと、開発に限った話だとデザインシステムのコンポーネントライブラリを作成するというところから、フレームワークを検討して、今回使用することにもなったAstroの話なんかもでてきたりしたんですよね。

加藤: そうですね。これまではテンプレートエンジンとかも使ってなかったので、内部のソースコードは実はかなり変わってますね。今回のエピソードではそのあたりも少し深堀りして話せたらいいなぁと思います。

佐竹: では、まずデザインシステムですね。

加藤: はい。デザインシステムは、あの、業界で統一的に用いられている定義はないんですけど、簡単に説明するとしたら、一貫したユーザーエクスペリエンスを提供するための仕組みのようなものです。で、聞いて分かる通り、結局どこがゴールなのか明確にするのが難しいので、まずはデザインガイドラインを作ることと、デザイントークンを定義することを目指して始めた感じですね。

佐竹: はい。デザイントークンを取り入れると、既存のコンポーネントと似たコンポーネントを作成する場合に、色やサイズに揺れがでてしまうということを防げたりするんですよね。

加藤: ですね。あるあるですけど、デザイントークンが定義されていない状態で構築すると、こう人の目には区別できないほど微妙に違うカラーコードがたくさん増えちゃったり、サイズ違いのボタンコンポーネントが何個もできちゃったりとかしますよね。

佐竹: ですね。そのために今回のリニューアルではデザイナーと相談して色とかサイズとか動きなどのスタイルガイドを作成してもらいました。そしてそれを基にデザイントークンをJSON形式で作成して、出力したCSSカスタムプロパティをコンポーネントに反映するというところまで対応しました。

加藤: はい。対応するにあたってのポイントって何かありますか？

佐竹: うん。そうですね。一番のポイントはコミュニケーションを恐れないということですかね。

加藤: おぉ～、なんか本質的な感じですね。

佐竹: はい。これまでせっかく考えて作っていただいたデザインに自分が何か言ってもいいのかという遠慮のような抵抗があったんですね。でもスタイルガイドをまとめて、実装に落とし込むにはデザイナーの意図だったりデザインルールを理解していないままではちょっと難しかったので、分からないところや認識に齟齬があれば遠慮せずに確認したり、提案するっていうようにしていました。

加藤: うん。良いものを作るにはやっぱりフラットに意見を出し合える環境というのが大事だと思うので、デザインシステムがその一端を担う役割にもなったっていうことですね。

佐竹: そうですね。これがもしフラットに意見を言える環境でなかったら、ルールが曖昧なデザイントークンをただ増やし続けるだけになってしまったと思うので、デザインシステムではコミュニケーションがポイントだなぁとやっぱり対応してみて実感したわけですね。

加藤: なるほど。いい気づきですね！ちなみに開発においては何か効果のようなものは感じましたか？

佐竹: そうですね。えっと、デザイントークンはまずサイトで使用する色やサイズなどを集めたプリミティブトークンというものを作成して、それをそのまま使うのではなくって、ルールに合わせてセマンティックトークンというものにしてから使用するというようにしていました。で、そうすることで、例えばライトモードの色のトークンと対になるダークモードの色のトークンというのをルールで決めていたので、デザインが２つ揃っていなくても作業を進められて、作業の効率化が図れたかなと思います。

加藤: うん。私もところどころ、こうコンポーネントを作ったりとか、手伝わさせてもらったりしたんですけど、デザイントークンがあるだけで、いい意味で制限されている感じというか。いつもだったらあまり考えずにカラーコードを追加するような時も、ちょっと立ち止まって考えるきっかけになっていたような気がします。

佐竹: そうですね。あと、デザイントークンを定義した時に色のコントラスト比なども考慮していたので、セマンティックトークンさえ使っていれば自然とアクセシビリティも担保できる状態となっていたので、作業の標準化にもなったかなと思います。

加藤: うん。なんか、結構いいこと尽くめなので、デザインシステムに取り組む始めの一歩としては良かったのかなぁと思いました。

加藤: はい。では次にAstroの話に移りましょうか。

佐竹: はい。まずAstroが何か少し説明させていただきます。Astroは、アプリケーションというよりはブログやECサイトのようなドキュメントよりのWebサイト構築にフォーカスしているWebフレームワークです。

加藤: 今回Astroを選んだのは何か理由とかありますか？

佐竹: そうですね。Astroはビルド時に可能なかぎりJavaScriptを排除して、HTMLとCSSを生成してくれたり、うーん、今回は使用しなかったんですけどAstroが画像用のコンポーネントを標準で用意してくれていて、そのコンポーネントを使うと画像自体の最適化までやってくれたりするので、表示パフォーマンスを最適化するのに便利だと思ったんです。

加藤: うん。なるほど。ページの表示が遅いとユーザーがサイトから離脱する要因にもなってしまうので、あの、ビルドにかかる時間みたいな開発におけるパフォーマンスだけでなくて、Webサイト自体のパフォーマンスにどれだけ貢献するかというところもフレームワークを決める時の選定基準の一つにしたいですよね。

佐竹: そうですね。あ、あとスコープつきのスタイルがデフォルトで設定されているっていうのも選んだ理由の一つです。

加藤: あー、スコープいいですね。スコープが別だと、例えば複数のコンポーネントでクラス名が被っていても互いに干渉しなくなって、より堅牢なスタイルの設計ができますね。

佐竹: はい。ただコンポーネントの組み合わせによってスタイルを変えたい場合だったり、CMSでも使用するようなコンポーネントの場合はスコープの設定をなしにすることがあったので、セレクターの命名は基本的に重複しないようにしておくといいと思います。

加藤: なるほど。スコープは便利だけど、あまりそこに頼りすぎないように、みたいな感じですかね。他に何か気をつけたほうがいいことはありますか？

佐竹: えー、あ、Astroに限らずですけどフレームワークを使用する時は、バージョンアップに気をつけたいですね。特に成熟しきっていないフレームワークを使用する時はバージョンアップが頻繁にあるので、その度に機能の追加だったり変更とか廃止に臨機応変に順応していく必要があります。

加藤: Astro、アップデートのペース早いですよね。Astroのバージョン3がリリースされた時に自分がこう何気なくアップデートしたら、スコープつきスタイルのデフォルトの仕様がwhereを使う方法から属性を使う方法に変わっていて、いくつかのコンポーネントに影響が出ちゃっていたのを佐竹さんが気づいてくれました。

佐竹: そんなこともありましたよね笑。少しだけ別のプロジェクトに参加して戻ったら、その間にバージョンが上がっていて、コンポーネントの見た目が変わっているので、あの時はちょっとびっくりしました。

加藤: そうですよね。しっかり影響範囲を確認してなくてすみません…。バージョンアップには脆弱性の対応が含まれていることもあるので、極力アップデートには追従するのが望ましいとは思うんですけど、アップデートの際にはちゃんと移行ガイドとか破壊的変更があるかっていうのを確認しないとダメだなぁと当たり前ですけど思いました。で、個人的に辛かったのは、プロジェクトが始まった当初はバージョン2系で開発していて、サイト全体で3000ページくらいあるんですけど、ビルドするのに約40分くらいかかってたんですよね。

佐竹: プロジェクトが進むにつれて、ページ数がどんどん増えてビルドにかかる時間も比例して増えていくのは結構辛かったですね。

加藤: そうなんですよね。まぁでもバージョン3がリリースされた時にフレームワーク内部の処理も最適化されたみたいで、あのレンダリングのパフォーマンスもかなり改善されて、結果的にビルド時間が5分くらいまで短縮されました。

佐竹: まぁ5分も長いといえば長いですけど、前に比べたらよくなりましたよね。

加藤: そうですね。Astroが出力するコードは基本的に全部静的なHTMLになるので、本当に超急ぎで更新したい時はHTMLを直接編集することもまぁできるといえばできるのですけど、通常はCI/CDのプロセスにのせてビルドから公開までを自動化できたらいいなぁと思っています。この辺りは今後取り組んでいきたいと思っているところですね。

加藤: はい。話したいことはまだたくさんあるんですけど、今日はここで終わりにします。

佐竹: リニューアルは段階的に対応を進めているところなので、ブラッシュアップした内容も今後機会があればご紹介していきたいです。

加藤: そうですね！直近だとView TransitionsがAstroでも使えるようになったので、その辺りを導入してみたいなぁと思ったりしてます。今後フロントエンドBlogなどで発信していければと思います！

加藤: 最後に、ミツエーリンクスではスマートなコミュニケーションをデザインしたいUIデザイナー、UI開発者を募集しています。採用サイトではオンライン説明会やオンライン面接なども行っていますのでチェックしてみてください。

また、このPodcastはApple Podcast、Google Podcast、Amazon Music、Spotify、YouTubeで配信していますので、お好みのプラットフォームでフォローいただけると、最新のエピソードをすぐ視聴できます！こちらもぜひご活用ください。 「#ミツエーテックラジオ」でご意見、ご感想、こんなこと話してほしいというリクエストなどお待ちしております。 それでは今日はこの辺で！ありがとうございましたー！

佐竹: ありがとうございました！