フロントエンド開発はプロトタイプとスキーマがすべて
と言っても過言ではないと最近思っています。
ここでいうプロトタイプとスキーマというのは以下のとおりです。
プロトタイプとは
UI/UX デザイナーがプロトタイピングツールを使用して作成される生成物のことです。
有名なプロトタイピングツールとしては Sketch Figma AdobeXD などが挙がります。
Web プロトタイピングツールとしての最近のトレンドは Figma で、少しずつ Figma 一強になりつつあります。
実際 Web プロトタイピングツールとしては Figma が頭 1 つ 2 つ抜けている印象があります。
スキーマとは
API の型定義が書かれた仕様書のことです。
一般的に拡張子は json か yaml ですが、yaml のほうがよく目にするかも。
スキーマの話となると Swagger という単語をやたら耳にしますが、結構ふわっと言われている印象があります。
API の仕様として Swagger という単語を使用しているのであれば、Swagger 3.0 から OpenAPI 3.0 という名前に変わったため、そこの現場は仕様が古いということに鳴ります。
最近であれば OpenAPI 3.0 以上の仕様でスキーマを作成すると思うので、Swagger はどちらかといえばツールの呼び名のほうがメジャーなのかな？（Swagger Editor とか Swagger UI とか）
スキーマの作成ツールとしては、Swagger Editor や Stoplight Studio などが挙がります、個人的には Stoplight Studio がオススメ。
フロントエンド開発であれば、スキーマファイルから API の型を生成している現場はたまに目にしますが、実際には API Client 周りも全て生成できます。
で、フロントエンドエンジニアとしてはプロトタイプとスキーマがきちんと開発されていれば、フロントエンド開発で困ることってあんまり多くないです。
一般的にはプロトタイプやスキーマが存在しない現場のほうが多いですが、あれなんでなんですかね？
UI/UX デザイナーが在籍しない現場は論外として、在籍するのに効果的にプロトタイプが開発できていない現場もめちゃくちゃ多いです。
日本ではまともにプロトタイプを開発している現場がほぼ存在しないため、どうしても情報が海外頼りになってしまうのが確かに厳しいところではあるのですが…。
スキーマにしてもそうですが、スキーマを切らない現場は論外として、スキーマを切るにも関わらずクライアントやスタブを生成しないというのは、ちょっと理解できない…。
こっちについてはネット上に山ほど情報があるので言い訳のしようもないような気がします。
そういう意味だと GraphQL って本当に革新的ですよね、スキーマがないとなーんもできないですから。
と、少し愚痴っぽくなりましたが。
とかく Web サービスの開発においてプロトタイプとスキーマは必須だと思っています。
とはいえ、プロトタイプとスキーマを導入しているにも関わらず Web サービスの開発がうまく回っていない現場も山ほど存在しています。
フロントエンドエンジニアの目線から見てきた印象としては、単純にフロントエンドエンジニアの知識・技術不足で開発速度が上がっていない現場もかなり多かったですが。
上にも書いたとおり、プロトタイプとスキーマに問題があるケースも少なくなかったので、過去目にしてきた問題をざくざくっと書いていこうと思います。
プロトタイプが画面単位で切られている
プロトタイプで一番よく目にする問題がこれです。
最近の Sketch や XD の仕様は把握しきれていないですが、Figma であればむしろ画面単位、つまり Page 単位でプロトタイプを切るメリットって存在しません。
Figma にはコンポーネントという概念が存在しているため、きちっと Atomic Design に沿って Atoms からコンポーネントを切ることが大切かなーと。
chot.design というサイトに Figma の使い方 が日本語で書かれているため、これに沿って操作方法を学ぶことをオススメします。
特に 3-4. コンポーネント化 はしっっっっっっかりと理解しましょう。
コンポーネントの概念がわからなければ、フロントエンドエンジニアに聞くなり、自分で調べるなり、Atomic Design を理解するところから始めましょう。
プロトタイプがレスポンシブの考慮がされていない
PC 及びスマートフォン向けの Web サービスを作っているはずなのに、なぜか PC 向けのプロトタイプしか切っていない現場もありました。
スマートフォン向けのプロトタイプが切ってあるものの、最小幅の考慮がされていないプロトタイプも見てきました。
プロトタイプはしょせんプロトタイプなのでどうしても表現に限界が出てきます。
そのため、最大文字数や最小幅など、一番表現が厳しいケースを常に意識するようにしましょう。
プロトタイプが CSS フレームワークの仕様が無視されている
CSS で手を抜きたいから Material-UI や Bootstrap などの CSS フレームワークを導入する現場って多いですが。
UI/UX デザイナーが CSS フレームワークの仕様を理解していなければ、結局 CSS フレームワークを CSS で上書きしまくるという、本末転倒なことをしている現場も少なくないです。
そもそも CSS フレームワークって Atomic Design の考慮などは行われていない（当たり前ですが）ため、うまくコンポーネント設計に沿えないところがかなり多いです。
CSS フレームワークを導入するときは、フロントエンドエンジニアは言わずもがな、UI/UX デザイナーもしっかりと仕様を把握していなければいけません。
その上で PM やディレクターが CSS フレームワークの仕様から外れた要件をあげてきた場合は、反映が厳しいことをしっかりと伝えられるボトムアップな雰囲気も必要かなーと。
なので、個人的にはそもそも CSS フレームワークが好きじゃないです、素の CSS で十分でしょってケースは決して少なくないよなーと。
プロトタイプと Storybook で差異が発生している
これはフロントエンドエンジニア側の話ですが。
Storybook を導入していない現場は論外として、本来論であればプロトタイプと Storybook で 1px たりとも差異が発生してはダメです。
全て同じ色、全て同じフォント、全て同じサイズ、全て同じ挙動でコンポーネントを作成するのがフロントエンドエンジニアの仕事です。
とはいえ、実際にはブラウザの仕様や HTML、CSS の仕様によって多少の差異が発生します。
その差異に対しどこまで許容できる範囲なのか、きちんと見極めて story を切ってやることが大切です。
プロトタイプと Storybook で差異が発生していることが当たり前になっている現場もあまりに多いです。
Wiki やエクセルに API の仕様を書いている
昭和か！って突っ込みたくなりますが、実際に存在するのでゾッとします。
そんなことするなら書かないほうがまだマシです、無駄な作業で無駄な時間使うな！
スキーマに書かれている仕様が間違っている
普通スキーマから型定義を生成して、そこに対して繋ぎこみの実装を行うと思うのですが。
たまーになぜか実装を先に進めて、それからスキーマを書きだすという本末転倒な開発フローを取っている現場があります。
このフローだとあとから実装を直した場合スキーマが連動していないため、実装と型定義で差異が発生し想定外のバグにつながることが少なくないです。
ある程度実装を書いて動作確認を取ってからスキーマを作成するのは大切なことですが、差異が発生してはスキーマの意味がないです。
当たり前のことですが、スキーマファーストで開発を行うようにしましょう。
スキーマから API クライアントを生成していない
これも不思議なんですが、なーぜか API クライアントを生成しない現場が多いです。
API クライアントって生成し得だと思っているので、有無を言わず生成しちゃいましょう。
OpenAPI Generator の公式サイト にはテンプレートのカスタマイズ方法なども書かれています。
他にも大小様々な問題を目にしてきましたが、ぱっと思い出せるのはこんな感じかなーと。
過去何度も書いてきましたが、プロトタイプにコンポーネント志向が伴っていないのは最も大きな問題だと思います、ついでレスポンシブ対応かなーと。
Web サービス開発って、当たり前ですがきちんとした知識と技術を持って行えばある程度うまくいきます。
もし現場で Web サービスの開発がうまくいっていなければ、まずはプロトタイプとスキーマの導入を提案してみるのはいかがでしょうか。
ちなみに自分は過去何度か提案させてもらいましたが、反映してくれたのは 1 社だけで、他は全て却下されたのでもう二度と言うことはないです。
また既に作成されているプロトタイプについて、もっとこうしたほうが良いのになーと思うことも多いですが。
UI/UX デザイナーの領域にフロントエンドエンジニアが口出しするのってすごく嫌がられるので、これももう二度と言うことはないです。