自社サイトをリニューアルしました。
というより、改めて1から作り直しました。
リニューアルしなきゃいけない理由があったわけではないんです。
SEOがどうとか、機能が古いとか、デザインが時代遅れになったとか、そういう「外的要因」ではなくて。完全に内的欲求です。
- 新しい技術を触ってみたかった
- 今後の仕事に役立ちそうな技術の選定を兼ねて
- やっぱり好きなUIにしたかった
- 趣味
このへんが主な動機です。
特に強かったのは、「今後の制作に活かせそうな技術を、ちゃんと自分の手で試してみたい」というところ。
自社サイトって、実験場として最高なんですよね。誰かの意見に合わせなくていいし、多少変でも許されるし、納期もない。
自分のペースで、自分の興味で、自分の好きな方向に作れる。これが最高なんです。
WordPressをやめてAstro + microCMSにしてみた
今回のリニューアルでは、初めてAstro + microCMSの構成にしてみました。
これまではWordPressか、単純な静的コーディングしか選択肢がなかったのですが
そろそろ違う提案もできるようにしておきたいと思ったのがきっかけです。
特にmicroCMSは最近伸びている印象もあって、一度ちゃんと触っておきたかったというのもあります。
今回は、全体はAstroで静的に組みつつ、お知らせをmicroCMSで管理する構成にしました。
ガチガチのフルヘッドレスにしなくても、必要なところだけAPI化するくらいがちょうどよかったです。
使ってみた感触としては、「これは今後、実務にも普通に使えるな」といったところです。
フレームワークはBootstrapを採用
今回の構築は、Bootstrapベースで組みました。
Tailwindももちろん候補には上がりましたが、今回は自分でデザインもUIもすべて構成する必要があったので、Bootstrapのコンポーネント設計に乗っかる形にしました。
Tailwindは、デザインがしっかり決まっている案件にはすごく向いていると思っています。
余計なスタイルが一切入らず、UIの意図をそのまま反映しやすい。
ただ、自分で1からデザインを考えて作っていく場合には、「どんなUIにするか」も毎回考えなければいけないので、Tailwindだとちょっと手が止まることが多いです。
その点、BootstrapはベースとなるUIコンポーネントが用意されていて、そこからカスタムしていけるのが楽。
今回のように自分で全部作るけど、方向性はある程度決め打ちしたいというときには、ちょうどよかったです。
あと納品後の改修でも、Bootstrapはやっぱり楽なんですよね。
「モーダル追加したい」「この箇所アコーディオンにしたい」みたいな要望が来たとき、基本的なUIであればすぐ対応できるのが強い。
（このあたりはTailwind UIを使えば良い話ですが、結局デザインから考える必要がありますし…。）
単純に今回の自社サイトでは、Bootstrapの考え方の方が自分には合っていたというだけの話です。
正直なところ、自分はそこまでデザインが得意ではないので、Bootstrapの枠組みに助けられました。
デザインはニューモーフィズム
UIのスタイルは、ニューモーフィズムに戻しました。
前に一度このスタイルで組んでいた時期があったんですが、その後WordPressテーマ（arkhe）に差し替えて見た目を整えたものの、やっぱり自分にはしっくりこなくて。
視認性の課題とかもあるのはわかってますが、どうしてもこの雰囲気が好きなんですよね。
で、問題は「どう作るか」でした。
BootstrapベースのNeumorphism UIというフレームワークがあり、それを使おうと最初は考えていましたが、
なんとBootstrap 4系で開発が止まっていました。今後のことも考え、そのまま使うのは現実的ではありませんでした。
それならいっそ、Bootstrap 5でベースを整えて、Sassのバリアブル（変数）だけで調整して作り込んでみようと思いました。
結果として、独自CSSはほとんど書いていません。
基本的な角丸、シャドウ、カラー、余白といったパーツはすべてBootstrapのSCSS変数でカスタマイズし、そこにニューモーフィズム的な表現を載せています。
この手法の良さは、独自のデザイン性を持たせつつも、Bootstrapのコンポーネント設計を崩さずに構築できるところ。
実はチーム制作にも向いていて、初期段階でSCSS変数を調整しておけば、誰が組んでも同じトーンでUIが仕上がるのが大きなメリットだと思います。
アニメーション周りについて
スライダーはswiperを使っています。
Bootstrapにもカルーセルはありますが、カスタマイズの自由度が低めで、レイアウトに合わせた調整がしづらい場面も多いです。
その点、swiperは自由度と拡張性が高く、細かいUIにも対応しやすいので、今回の構成にはフィットしました。
アニメーションには gsap を採用しています。
理由はシンプルで、パフォーマンスが安定していて、しかも軽量だからです。
スクロール連動やフェード、要素の出入りなどを加える中で、動作が重くならず、滑らかに再生されることを優先しました。
また、必要以上にファイルサイズを増やさずに済むのも大きなポイント。
最低限の動きでもクオリティが担保できるため、自社サイトのような構成にはちょうどよかったと感じています。
今後について
現時点で実装が完了していないのが、フォームまわりです。
問い合わせフォームをどう組み込むかはまだ検討中で、外部サービスを使うか、軽めのサーバーレス構成にするか、使い勝手やメンテナンス性を見ながら決める予定です。
また、今後の運用を前提に、必要に応じてページやセクションを追加していくつもりです。
あくまで「完成」ではなく、「柔軟に変えられるベースをつくる」ことが目的だったので、仕様を固めすぎず、拡張性を持たせた構成にしています。
このあたりも、自社サイトだからこそできる自由度として活かしていけたらと思っています。
終わりに
以上、自社サイトをリニューアルしたときの記録でした。
実務というより、趣味と検証の中間みたいな作業ではありましたが、実際に手を動かしてみたことで得られた感触はかなり多かったです。
構成、技術選定、スタイル、UIの表現など、普段の案件ではなかなか試せないことも盛り込みつつ、
「このやり方、今後の案件にも使えそうだな」と思える部分もいくつか見つかりました。
自社サイトなので、気が向いたらまた変えると思います。
でも、それくらいの自由さがあるからこそ、実験にもなり、モチベーションにもつながるのかなと。
同業の方が見たときに、何かしら引っかかる部分があればうれしいです。
ここまで読んでいただき、ありがとうございました。
