Q.なぜ Astro で作ったのか
情報要件自体はシンプルなのでフレームワークは最小構成にし、その軽い土台の上にブランド表現として 3D を乗せる、という組み方が Astro + Cloudflare に一番きれいに収まったから。
「愛着」テーマに切り替わった Phase 2 で、コーポレートサイトを設計から実装まで一人で担当しました。Astro を本格採用したのはこのサイトが最初で、Cloudflare にデプロイしたのもまだ 2〜3 回目という初期です。技術選定を一つずつリサーチしながら組んだ、自分にとっての土台づくりの案件でした。
技術選定より前に、デザインの方向性は固まっていました。ロゴの延長で 卵モチーフ と 余白を持たせたゆったりした雰囲気 はすでに決まっていて、そこに乗せる細部の作法として、ちょうど仕様が公開されたばかりだった Material Design 3 Expressive を読み込んでいます。
Material Design は 2 の頃から追っていて、Expressive で一段化けたと感じていました。Web サイトにそのまま持ち込めるわけではありません(どちらかというとアプリケーション向けの概念)が、学べる部分は多いと思っています。
もう一つ、他のメンバーの希望も加味して グラスモーフィズム を採用しました。ゆったり・余白という方向性と相性が良いという判断です。
実装は Astro + Tailwind。選定理由は、
結果 Astro が一番きれいに収まりました。同じ要件なら今でも第 1 候補は Astro です。唯一変えるとしたら、当時は Cloudflare Pages に置きましたが、今は Astro のアダプタが Pages 非対応になったので Cloudflare Workers にデプロイします。逆に言うと、それ以外の技術選定は 1 年経った今リサーチし直しても、ほぼ同じ構成を選びます。当時そこそこ真面目に調べて組めていた、という手応えがあります。
土台をあえて軽くしたぶん、表現に振れる余白ができました。ここで Blender で 3D モデリングを起こし、Three.js でサイト上に描画する、という挑戦を乗せています。
創業期のスタートアップは、良くも悪くも情報が薄いものです。「具体的に何をやっているか」を言葉で説明しきれない段階でも、抽象度の高い 3D モデルなら雰囲気で「こういうことをやろうとしている」を伝えられる、というのがこの表現を選んだ理由です。ロゴの卵モチーフ(→ロゴ・名刺・ブランド)をはじめとする世界観を、平面のあしらいで終わらせず 3D 表現まで一貫させたかった、という思いもありました。Astro / Cloudflare はこの案件でしっかり自分のものにしましたが、Three.js は今回軽く触れた程度で、本格的に使いこなせるところまでは至っていません。それでも技術的な挑戦として、素直に勉強になった一本です。
問い合わせ種別の選択肢は、一般的にはプルダウンで済ませることが多いところを、あえて ラジオボタン にしています。
もちろんデメリットもあります。プルダウンに比べて 一覧性が低く、下までスクロールしないと自分がどの項目に該当するか分かりにくい。それを理解した上でラジオボタンを選んだのは、当時の自分たちのフェーズに合っていると判断したからです。
創業初期は「来るもの拒まず」で、ユーザーも取材も研究協力も何でもウェルカムに受け止めた方がメリットが大きいと考えていて、この設計もその発想を反映したものです。
お知らせなどの更新用に、当時は MicroCMS を CMS として入れました。ここは今なら変えます。
外部のライターが書くわけではなく、更新するのは内部だけの運用です。それなら外部 CMS を挟むより、MDX でリポジトリ内にマークダウンを持つ方が素直でした。今のコーディングエージェントを前提にすれば、Keystatic を使う / あるいは CMS を使わずマークダウンを更新しやすい仕組みを用意する、といった形にすると思います。
実装前に、Figma 上で全ページのデザインを組んでいます。実装の段階で「このページはなし」「このページを追加」といった変更もあったので、今の実装と完全には一致しませんが、サイト全体の雰囲気を掴むには十分でした。
画面遷移のアニメーションも軽く付けています。最終的に実装するのは自分自身だと分かっていたので、凝ったアニメーションを作り込む必要はなく、「ここはこう動く」という遷移の流れさえ掴めれば十分、という判断でした。
当時 Figma 上のコンポーネント管理は Atomic Design(Atoms → Molecules → Organisms)で組んでいました。この分割自体は、Figma 上でコンポーネントを管理する分にはとても便利で、悪い判断ではありません。
反省しているのは、これをそのまま実装側のコンポーネント分割にまで引きずったこと。デザインと実装の両方をやってみて分かったのですが、Figma 上では便利な Atomic Design も、実装でコンポーネントを管理する段になると混乱しやすい。デザイン(Figma)のコンポーネント管理と、実装のコンポーネント管理は、別々に最適解を考えた方がいい、というのがここでの学びです。それ以降のサイト制作では、Atomic Design を実装まで持ち込まないようにしています。
今のデザインの前に、実は別のデザイン一式を作っていました。ロゴ(卵モチーフ)が決まる前の段階で、ブランドとして依って立つモチーフがまだなく、方向性を決めるのに苦労した記憶があります。
この時は モバイルファースト で組んでいました。ただ、その後 Web 制作会社に入って学んだのは、Web サイトに関しては PC を基本の重心にしつつ、崩し方を頭の片隅に置いておく バランスの方がやりやすい、ということ。PC のデザインをしている最中にも「これはモバイルだとどう見えるか」をうっすら想像しておく。モバイルの見え方をまったく想像できていない PC 一辺倒のデザインもそれはそれでバランスが悪いので、どちらかに寄せすぎないことも大事にしつつ、基本の軸足は PC 側に置く、というのが今の自分のやり方です。
このデザインを作る過程で、情報アーキテクチャやサイトマップ、ユーザーフローも一通り用意しています。
正直、今の規模感からすると ここまで作り込む必要はなかったと今は思っています。実際、その後のデザインでこれらを直接参考にしたわけでもありません。ただ、こういう情報設計を一通り自分の手で作った経験自体は、次に真面目にやるときの引き出しになっていると思います。
ロゴで卵モチーフが決まってからは、そこから逆算してデザインを組めるようになりました。ブランドのアイデンティティが先に立つとここまで作りやすくなるのか、と実感した一件です。今のデザインの方が気に入っています。
細部のデザインは、その後サイト制作の場数が一気に増えたこともあり、今ならもっと詰められると思っています。ただ「余白・ゆったり」というブランドの方向性の置き方自体は、当時から悪くなかったと思っている一本です。
+More_Decisions
