はじめに
こんにちは。レコチョクの河野です。プロダクトデザイナーとして、EggsやGIGGSのプロダクト開発に関わっています。
この記事は、社内で実施したデザインシステム勉強会の内容を記事化したシリーズの第2弾です。第1弾のデザイントークン編ではColor・Typography・Dimensionのトークン設計について紹介しました。今回は命名管理とOOUI（オブジェクト指向UIデザイン）にフォーカスします。
勉強会全体を通して伝え続けたのは、「デザインシステムの究極の目的はチームで使われる単語を統一すること」というメッセージでした。このセクションは、そのメッセージが最も直接的に表れる領域です。
命名は思っている500倍大事
まず前提として声を大にして言いたいのが、命名は全ての職種の人が思っている500倍くらい大事だということです。
UIデザインといえば見た目や操作に目が行きがちですが、実はUIの根幹には「情報設計」が占めます。情報設計には、サービスに出てくる概念の定義や画面構成が含まれます。
エンジニア向けの『リーダブルコード』も最初の30ページを命名に割いていることから、その重要性が理解できます。
企画・制作・実装のどの職種でも命名は本質的な関心事です。設計（デザイン）を担う人が命名をリードすることで、全員の迷いを減らせると個人的に考えています。
画面の命名ルール
EggsとGIGGSでは、アプリ画面名を次の3タイプで統一しています。
| 画面タイプ | 説明 | 例 |
|---|---|---|
| {名詞}一覧 | オブジェクトがリストで並ぶ画面 | アーティスト一覧、ライブハウス一覧 |
| {名詞}詳細 | 特定のオブジェクトの詳細情報を表示する画面 | アーティスト詳細、ライブハウス詳細 |
| モーダル系（動詞） | 特定の操作に特化した画面 | プレイヤー（再生）、QRコード読み取り |
ここでいうモーダルとは、プロダクトが特定のタスクの実行に特化した状態（モード）に入っていることを指します。楽曲を再生する画面や入力フォームなど、特定の操作が完了するまで維持される画面はモーダルなUIとして分類しています。
和英両方でつける
もう1つ意識しているルールとして、画面名は和名と英名の両方を必ずつけています。目的はアルファベットでソートしやすくすることと、英訳のコストを吸収することです。
エンジニアはクラス名や変数名を英語で命名します。ビジネス側もGAのイベントログを定義するときに英語名が必要です。ここをアプリ全体の「設計」を担うUIデザイナーが最初の時点で吸収してしまえば、全員のコストが下がります。
英名のルールはシンプルです。
{名詞}一覧 → {Noun} List
{名詞}詳細 → {Noun} Detailこの構造が決まっていれば、考えるべきは {Noun} の部分だけです。やってみると思ったほど難しくありません。
できれば可算名詞に紐づける
名詞の選び方でもう1つ意識しているのが、できれば可算名詞に紐づけて整理するということです。
例えば「ライブの情報」という表現を使うと、Information は不可算名詞なので「どの単位までを1つの情報とみなすか」が人によって揺れてしまいます。代わりに「ライブの詳細」として Live Detail とすれば、「詳細画面に含まれるのはこの項目とこの項目だ」と定義できるので、解釈の揺れを抑えられます。
この話に対して、勉強会当日に設けたSlackの実況チャンネルでリアルなコメントが飛んできました。
「楽曲だけでもmusic, song, trackがあり、意識しないとこれが全部混ざってカオスになりそう。決まっているとたしかに嬉しい」 「musicは不可算名詞だからtrackの方がtrack, tracksでわかりやすいという話が前あった」
「もし統一しないまま進めたら、画像の英訳がimage, photo, pictureとコード上で混在するような事態も起こりうる」という声もありました。プロダクトの規模が大きくなるほどこの手の揺らぎは蓄積していくので、早い段階で統一しておくメリットは大きいです。
命名で使える英辞書系サイトとしては、次を参考にしていました。最近はAIに任せることも多いですが、手作業で命名を考えることで自分の概念の理解を深めることもできるので、手動で引いてみるのもお勧めです。
実際の命名作業では、Figma上でいきなり始めるのではなくExcelシートで一括管理するのが有効でした。和名を書き出し、対応する英名を横に並べ、Figmaのフレーム名や仕様書のタイトルを文字列結合の関数で自動生成する列を用意します。
CSVで出力してバックログのチケットを一括起票したり、Notionのデータベースに流し込んだりもできます。全画面分の名前をつけるのはかなりの重労働ですが、こうした工夫で揺らぎのない命名管理を実現しています。
コンポーネントの命名ルール
コンポーネントの命名では、コンポーネントの種類＋オブジェクト（名詞）で分類します。
Material Designのコンポーネント分類を参考にする
コンポーネントの種類は、Material Design 3のComponentsで定義されている名前を参考にしています。Card、Cell、Column、BottomSheetなど、標準的な分類を共通言語として採用することで、「同じような役割のコンポーネントが乱立して何が何だかわからない」という事態を防いでいます。
スラッシュ区切りと逆順ルール
Figmaではコンポーネント名にスラッシュ (/) を含めると、スラッシュの前後が階層として解釈されます。Assetsパネルではこの階層に沿ってグループ表示されます。インスタンスの差し替えメニューでも同じ階層内のコンポーネントが関連候補として一覧される仕組みです（Name and organize components – Figma Learn）。この仕組みを活用し、次のような形式で命名しています。
Card/Ranking/Artist
Card/Ranking/Track
Cell/VList/Couponポイントは、このスラッシュ区切りの命名を逆順に辿ると、SwiftやKotlinのカスタムクラス名として自然な命名になるように設計していることです。
Card/Ranking/Artist → ArtistRankingCard
Cell/VList/Coupon → CouponVListCell
Figmaの管理上とコード上の両方で命名が揃うため、制作側と実装側のどちらにも無駄がありません。実況チャンネルでは
「コンポーネントの命名規則が決まっていると、iOSとAndroidのアプリで同じクラス名で実装できるので、双方のコードレビューにも役立つなと思いました」
というコメントもあり、実装の観点からも命名規則を整備するメリットがわかりました。
命名を揃えると、制作・実装以外でもスケールする
画面名やコンポーネント名を統一したことで、デザインと実装以外のところでも恩恵がありました。
GAイベントログとしての命名統一とその波及効果
職種間で名前を統一していなかった時期では、EggsではFigma上のコンポーネント名も実装のクラス名もGAイベントログの定義もバラバラでした。全員が同じことを3回考えているのに、どれも散らかっている。データ分析も非常にやりづらい状態でした。
名前を揃えたことで、ログに埋め込む文字列がほぼ一発で定義できるようになりました。例えば「アーティスト詳細画面にアーティストのカラムセルからタップで遷移した」というイベントも、命名ルールに沿えばほぼ考えることなくカスタムパラメーターとして含める値の文字列が決まります。
さらにこのログ基盤をもとにABテストを実施し知見を得た事例もあります。「チームで使われる単語を統一する」と言う信念を持って命名を意識的に統一することでこうした領域までスケールするポテンシャルがあるということを、伝えておきたいところです。
ここまでで画面名やコンポーネント名の揃え方を説明してきましたが、そもそも名詞の部分（アーティスト、楽曲、プレイリストなど）をどうやって整理するのかという問いが残ります。ここで登場するのがOOUI（Object-Oriented UI Design）です。
OOUI（オブジェクト指向UIデザイン）
OOUIとは、オブジェクト（操作対象のもの・こと）を中心としてUIをデザインしようとする手法です。画面名やコンポーネント名の整理に直結します。加えて、デザインの5段階モデルでいう「要件」や「構造」の階層に関するディスカッションをシステマティックに進めるための強力なツールです。
実況チャンネルでは「オブジェクトモデリングは、データベースの設計を考える時にも必要そう」というコメントがありました。勉強会の場では「バックエンドの人を巻き込むのもありだが、テーブル設計ほどの厳密さは求めていないので、期待値調整をしてからディスカッションに入ると話が弾む」と回答しています。
オブジェクトモデリングのステップ
Eggs/GIGGSのプロダクト開発の中では『オブジェクト指向UIデザイン』で提唱されているモデリングのステップをこれまでのプロセスで多く実践してきました。勉強会の中では、ユーザーストーリーから実際の画面構成を考える例を交えて説明しました。
1. 名詞を抽出する
要件定義のアウトプット（ユーザーストーリーマッピングの付箋など）から名詞を片っ端から抽出します。「アーティスト」「楽曲」「コメント」「ランキング」「プレイリスト」「ライブ」。こうした名詞がまず並びます。
2. 関係性を紐づける
抽出した名詞同士を「楽曲にはコメントが紐づく」「アーティストが楽曲を公開する」のように関係性で結びます。
3. 多重度を特定する
アーティスト1人に対して楽曲は複数（1:N）、楽曲1曲に対してアーティストは1組（N:1）のように、対応する数を特定します。ライブとアーティストの関係なら、1つのライブに複数のアーティストが出演し、1人のアーティストも複数のライブに出るので N:N です。
4. メインオブジェクトとプロパティを分類する
名詞の中にはメインとサブの関係があります。例えば「歌詞」は楽曲に1対1で紐づく説明的な要素なのでプロパティ（サブ）です。「コメント」は楽曲に対して複数紐づく独立した概念なのでメインオブジェクトです。
5. コレクション（一覧）とシングル（詳細）を導き出す
メインオブジェクトが特定できたら、それぞれに対してコレクション画面（一覧）とシングル画面（詳細）が必要かを検討します。まずは一覧→詳細の遷移を機械的に引き、次に多重度の関係を反映して画面間の遷移を追加すると、画面遷移図がほぼ自動的に完成します。
仕様書を書き始める前に全体の画面構成の見通しを持てるので、「似た画面が乱立してしまった」「途中で必要な画面に気づいた」という事態を防げます。
Figma MakeとOOUI
GIGGSの立ち上げ時には、Figma Makeを使ったプロトタイプ作成にもOOUIの成果を活用しました。
自分がGIGGSチームにジョインしたとき、チームがすでに画面遷移図を整理してくれていました。Figma Makeに渡したのはこの遷移図のみです。およそ「モバイルアプリの全体を作ってください。ライブ情報を見られるアプリで、遷移関係はこんな感じです。」たったこれだけの指示で、最初のプロトタイプがほぼ一発で生成されました。
AIにプロトタイプを作らせるために特別なプロンプトを工夫する必要はありません。名詞を基準にドメインモデルと画面遷移図を整理しておくことが、最大のコンテキストになります。これは人間相手でもAI相手でも同様に強力です。
まとめ
命名とOOUIの取り組みを通して実感したのは、名前を揃えることの効果が想像以上に広い範囲へ波及するということです。デザインデータの整理だけでなく、実装のクラス設計やGAログの命名、ABテストの基盤にまで影響します。
実況チャンネルで「実際デザイン進めで合致した際、じゃあ今まで適用されてきた名前をどうやって合わせていくのか……というのはこれから先いそうだなと思った」というコメントがありました。既存の命名を後から統一するのは確かに大変です。しかし、すべての出発点は「名詞を特定して、名前をつけること」です。特別な技術やツールがなくても、ホワイトボードと付箋があれば始められます。自分の思考を再現性のあるプロセスで整理できること、チームを巻き込むことで見解が揃い、コラボレーションの改善を体感できるので、この方法論がとても気に入っています。ぜひトライしてみてください。
参考資料
河野穣
2019年新卒のエンジニアです．iOS修行中．
