あったらいいなフロントエンド開発の時に

この記事は...

• フロントエンド開発する時にあったら良いなを言語化してみた
• 所謂デザインシステムを拡張したものに近い感じになった
• あくまで理想なので同期的にすべて揃えることは不可能だけど、共通認識としてあると「開発に何が足りないか」考えるヒントになるかも
• ん、というか自分がWeb作る時に考えていることに近いのか...？

💡 サービス・プロダクトの概念・原則

• プロダクトの性質を定義
  • サービスなどとして稼働する時にユーザーに伝わるもの・期待値（UXともいう）
    • 開発時に一貫して気にしたい
    • KGI・KPI
      • 数値化されていない素朴なものでもいいので、なんのために作って、どうなったら成功なのかを知ってかないと、なにを作っているのかわからなくなりがち
    • MVP
      • なぜこのサービスがほしいのか
      • なぜこの機能、施策がほしいのか
    • SEO 要件
      • Web でやる以上はターゲットをある程度は決めておきたいよね
    • 挙げてたらキリがなくなりそう...
  • 実装自体に直接関係はしないものもあるが大事
    • プロダクトの開発で困った時の灯台の様なもの
      • 個人開発でもこういうコンセプト考えておくとものは作りやすい

🎨 スタイルガイド

• プロダクトのスタイルを定義
  • CSS 設計で効いてくる
    • スタイルガイドがしっかりしていれば設計・実装コストは下がる
      • ここが薄いと実装する人間の裁量で品質に差が出る
        • こういうときにデザインやったことないとしんどいかも
      • あったら嬉しい
        • 色
          • 配色パターンもあると尚よし
        • タイポグラフィ
        • 余白
          • Vertical Rhythm とかあると良いよね
        • アンチパターン
      • 「あったら嬉しい」が定義されていれば大方変数化（AltCSS 使用前提）が可能

📱 コンポーネントライブラリ

• UI を任意の観点で切り出したものの定義
  • UIを持つプロダクトのコミュニケーションツールとして機能したい
  • UI 設計であったほうがよい
    • ただ静的なものの定義だけではなく、ユーザーのアクションに合わせた状態（過程）が定義されていると良い
      • モーションまで定義されていると最高かも
    • 目に見えている所以外の定義（状態の管理）なども定義されていると嬉しい
    • 場合によっては Storybook など実装ベースで定義できると良いよね
    • ここが固まっているとUIライブラリの選定や状態管理の設計のイメージが湧きやすい
    • a11y も含めて考慮できると最近の傾向からすると良いよね

📶 URI

• URI一覧
• 必要なクエリの定義
  • コンポーネントライブラリやページ単位で紐付けたい
    • URI・クエリ <=> 状態管理 は相関関係のケースが多い

🗝 認証・認可

• 必要な場合ね
• 認証
  • JWT とかはどうでもよくて、FEはどちらかというと認証情報を永続化するための方針を決めたい
    • Cooki？ LocalStrage？ ここらへんが議論の的になるのかな
    • 最近は BFF経由でセキュア対応した Cookie 操作が安牌？
  • ページによっては認証情報がいらないケースもあるので、そこも分かってくるといいよね
• 認可
  • URI * 認可*n のパターンでどれだけUIの表出に変化があるか、状態管理に制限がでるか知りたい

🛠 API I/F

• Swagger など OpenAPI の定義があると嬉しい
  • 型情報に基づいた I/O の議論がしたい
  • Mock 書くのが面倒なのでローカルで叩けるものがあると嬉しみ倍増

🗺 インフラ周りの論理構成図

• あったら嬉しいというか早めに方針決めたい
  • 何故？
    • デプロイフローが次に決められる
    • プロキシが入る場合アプリケーション側のURIの定義に色付が必要だったりする
    • 開発環境を整備しやすくなる
      • Docker 周りの定義や Docker-compose 使うのとか

🌝 夜も眠れない問題

• ある程度決まっていたほうが行動に移せるサブセットを纏めてみる
  • UI設計・実装
    • スタイルガイド
    • コンポーネントライブラリ
    • URI・クエリ
    • 認証・認可
  • 状態管理
    • コンポーネントライブラリ
    • URI・クエリ
    • 認証・認可
    • その他メタ的に必要な永続情報（Cookie などで管理するもの）
  • 技術選定
    • アプリケーションとインフラは切り離して非同期で考えられると良いよね
      • アプリケーション
      • インフラ
        • ただ、Next.js/Vercel など一気通貫で考えたほうが良いケースもかなり出てきたのであくまでケースバイケースで

🤔 何を持って仕様なのか

• 今回はデザイン・エンジニア視点の単語で書き出してみた
  • 所謂ビジネスロジック的なものは各所に分散されているという感じになると思う
    • こう「仕様」というものを言語化するのは実は難しいかもしれない