牛歩ですすめるデザインシステム
こんにちは！
デザインシステムアドベントカレンダー18日目の記事です🎄
こちらの記事では、「導入してこんな良いことがあったよ🌟」・「うちではこんな感じでコミュニケーションとってます💪」みたいな感じのキラキラ記事を！！！！ほんまは！！！書きたかった！！！！！！！！！！！！でも！！！！！現実甘くない！！！！！！！
初めて事業会社で、デザイン組織もないところで、でもプロダクトはいっぱいあって、必要ではあるんだけどなかなか進まない、、、なぜだろう、、、これが原因か〜〜？じゃあこうしてみるか〜〜！（改善中）の泥臭い感じのことを書きます。
忘年だし、来年はキラキラ記事を出すぞ！って心意気で書いていきますのでどうぞお付き合いください。
組織概要
私が所属している組織と体制はざっくりこんな感じです。（社名はちょっと伏せますね。）
- 不動産系の事業会社
- 全体で50~60人くらい
- 内エンジニアの人数は15人
- バックエンド・フロントエンド・インフラ・ハードと特に分けてなくて全部いい感じにやるってなっています。（ただバックエンド強め）
- デザイナーの人数は2人（私含める）
- 1人はDTPが強い方です
- webもネイティブも両方プロダクトとしては存在して、8個くらいプロダクトはある。
- デザイン組織は特にない
こちらを「デザイン組織の成熟度に合わせたデザインシステム提案」という記事に記載がある成熟度に当てはめたところ
Level 1 : Producers
ビジュアルを作るのが主な仕事。他部署からのオーダーを受けてデザインする場合が多い組織。実装との連携まで考えるのは困難なので、自分たちの仕事効率化にフォーカスして作ります。
とあるので、おそらくProducersに当てはまります。
さぁ、あとは始めるだけだ。
ここまで調べてさぁ！！！！スピーディーに進めるぞ！！！！！と、息巻いて、他社さんのアウトプットも参考にしつつ
デザイン原則も作った！カラーパレットも整理して定義した！デザインファイルも作った！コンポーネントもデザインデータと実装名前合わせるようにした！フロントエンドのベースの構成も作った！ファイルのテンプレートも作った！お膳立ては完璧！
おっしゃ！使ってもらえるやろ！！！！！
未来からきた私😃「使われないんだなこれが」
使われなかった理由その1: 情報へのアクセスの方法が分からないので、メンバーが存在を知らない・使い方が分からない
作ったはいいけど、作ったものをシレッとプロダクトのファイルに入れて、「入れておいてます〜」と場所だけ伝えてそのままにしてしまっていました。また、デザインデータについてもなぜかその時の私は「デザインデータの見方は誰でも分かるでしょう。」と思っていたのです。（よくない！！）
このままでは「知ろう」とすらならないので、浸透もしなければ使ってももらえません。
その結果、
- デザインデータのコンポーネントの分け方も伝わらなければ余白の数値も伝わっていない
- Storybookに登録しているコンポーネントにたどり着けない（Storybook起動できない）
- 本来欲しかったHTML構成でアウトプットがされない
といったことになりました🙈
💡解決策
プロダクトに関わるメンバーを集めてFigmaを使った勉強会を行いました。
- Figmaの基本的な使い方
- Figmaのデータから実際にコードに落とすために見るべき箇所
- 実際にデザインデータからコードに起こしてみよう
といったハンズオン形式の勉強会をし、まずは情報へのアクセスの方法をお伝えしました。
そうすることで少しずつスタイルガイドを使ってもらえたり、Figmaのデザインデータに対しての関心が高くなったかなと思います。
使われなかった理由その2: 色々揃えた結果属人化してしまった
先述したように、色々用意をしたんです。結果、私が「揃えてくれる人」になってしまって、
デザインデータを作ってフロントエンドまでの実装を1人でしている職人が爆誕しました🫠
属人化をすると、他の人は手を出そうとしても出せません。そうすると閉じたものになってしまうので浸透なんてしません。
これだと「そもそもデザインシステム構築する必要無かったんじゃ......」と頭をよぎることはあったものの、
私がもし今デスノートに名前を書かれて死んでしまっても誰が作ってもある一定の品質を担保しつつ一貫性のあるものをアウトプットできる仕組みは作っておかねばなりません。
なので、こうしてみました。
💡解決策
小さなデザイン改修の実装から他のメンバーに着手してもらう体制をとるようにしました。
メンバーの上長にデザインシステムの話を通し、次回の改修で既存のコンポーネントに手を加えるのでその実装部分を私以外のメンバーにしてもらうこととしました。
こちらに関してはまだ結果は出てないのですが（今チャレンジ中）、しばらく誰でも出入り可能なハドルミーティング等で画面を繋ぎながら一緒にレクチャーをしていく形で進めてみています。
使われなかった理由その3: 技術要件にあってない
弊社のプロダクトはWebだとPHPでフレームワークはCakePHPで作られているものがほとんどです。
そこにStorybookをかませたことで、最初は「コードコピペできるしだいぶ楽ちんでしょう！」と思っていたのですが、実際はそんなことはなくStorybookに記載のあるHTMLをもう一回PHPに書き直さないといけないといった手間が増えただけでした。
結果、実装する人はStorybookを見ずに既存で実装されているコードを探してコピペするといった本末転倒な感じになってしまいました。
このままでは、コピペ元がもし間違っていたとしたら間違っているコードが量産されてしまうといった事態になりかねません。
💡解決策
Storybookをやめて、自前のPHP製でスタイルガイドを作り直します。
ヒアリングしたところコードをコピペできたり、デザインデータと同一のコンポーネント名になっているので探しやすいといったところは良い！とのことだったので、コードスニペットやデザインデータど同一のコンポーネント名で検索できるといったものは残しつつ、自前で作ろうと思います。
......Storybook、便利だったな。。。
使われなかった理由その4: 啓蒙活動してなかった
これが一番ですね😇
理由その1と若干重なるのですが、「伝えられていなかった」これに尽きます。
もちろん、デザイン原則も浸透していないですしせっかく作ったライティングガイドラインもあまり使われませんでした。
💡解決策
入れたら終わり！ではなくて、入れたら宣伝する！宣伝する！宣伝する！導入して使ってもらう！宣伝する！みたいな結構マメに小出ししていかないといけないので、以下のようにチャレンジしてます。
- デザインデータのファイルにでかでかとデザイン原則を貼り付ける（効果微妙）
- レビュー時に「ライティングガイドラインに沿うと〜」と一緒にガイドラインのURLを共有する
- メンバーは固定せず定期的に社内勉強会でハンズオンを開催する
結果としてどうかはまだ分からないのですが、少しだけ「一貫性のあるルールは」といった議論ができるようになったのかな？と思います。
使われなかった理由その5: まだ我々には早い？
いいですか......先述にある
とあるので、おそらく
Producersに当てはまります。
自覚していたのにいろいろ手広く作ってしまったのもちょっと反省してます。
ちなみにProducersでは、
- デザイン原則（部内での約束事で狭義な意味のデザイン）
- 簡易ブランドガイドライン
を用意し、少しずつ理解を進めレベルを上げていくのですが
デザイン原則も作った！カラーパレットも整理して定義した！デザインファイルも作った！コンポーネントもデザインデータと実装名前合わせるようにした！フロントエンドのベースの構成も作った！ファイルのテンプレートも作った！お膳立ては完璧！
最初から手広く作りすぎた😇
💡解決策
地道に牛歩ではありますが進めていきます。腹はくくった。。。（脳筋）
まとめ
作ったらブァーーーーって一気に広がるは大間違い。1人でやって勝手に配布してってのは今考えると完全に独りよがりの自己満だったな〜と大反省しています。
使う人に寄り添って、話を聞いて、一緒にやっていく。そして仲間を増やす。
時間はかかっても、泥臭く小さく細かくやっていくのが大事。
牛歩だけど焦らずゆっくり確実に進めていきます🤘
牛歩の続報を待たれよ！！！！
Discussion