デザインシステム構築チームに関わりはじめ、いろいろ考えることが増えてきた。

最初は右も左も分からず、「たぶん……こうすればよさそう」とつぶやきながらへっぴり腰で取り組んでいた。
しかし、業界の先人たちの知見と大先輩方々の助言を賜る機会が増え、どっしり？腰を据えて「ここまでやれば、いったんは良さそう」という姿勢で構えられるようになってきた（と思う、自分は）。

デザインシステム構築の具体的なアプローチについては、先人や業界の天才な方々が多く知見を共有していらっしゃるので、ここでは個人的に意識していることを書き綴っていこうと思う。

正解が見つからなければ未来に託す #

• ある程度の見込みは立てておく必要があるが、未来のことは誰にもわからない
• 決められないことで推進が停滞しては本末転倒、「今はこれで」というところで落とし所をつける（落とし所をつけられるようになる特殊な訓練をする）
  • すぐに白黒つけない。人間が使うものなので白黒つけられないことのほうが多い
  • 個人的には、「ひと晩、風呂に入りながら考えても出てこなかったら、それを決めるのは今じゃない」って考えるようにしている
• 未来のステークホルダーが「なぜ今はこの状態になっているのか」がわかるように、ドキュメントを残しておく
  • これも完璧に残すよりは「まったくわからない」より「少しでもわかるように」くらいのものでも構わない

捨てやすい状態にする #

• ユースケースが少なくても「こういうコンポーネントはこれから必要になってきそう」みたいな物があれば追加しちゃう。
  使わなくなることも十分に考えられるので、いつでも捨てられるようにしておく
• 過去にユースケースがあったとしても絶対的に使いづらいもの、使ってほしくないものは、いったん作る。
  あとで断捨離しやすいように作る

うちはうち。他所は他所 #

• 他所で作られているデザインシステムが自分たち（プロダクトチーム）にとって使いやすいとは限らない。あくまで対象のプロダクトチームが使いやすいモノを意識する
• とはいえ、他所には自分たちが持ち得ないたくさんの知見があるので、遠慮なく参考にさせてもらう
• 「他所でやってるからうちでもやる」を採用理由にしない。「うちではこういうユースケースがあるから、コレが参考になるので採用する」という説明ができる否かで採用を決める
• Figma のデザインデータと Storybook のコンポーネントは別物として考える
  • Figma では必要ないけど、実装的には必要（あったほうがいい）コンポーネントというのは存在す（弊社の場合は）
    • 絶対どっちかに揃えなくちゃいけないなんていう法律はないので、それぞれで使いやすい状態にすることを優先する
  • チームによってはこれに限らない。弊社の場合は別物として考えたほうが、都合良いケースが多いのでこういう意識を持っている

超長期戦、そして「完成」はない #

• 過渡期を乗り越える覚悟をする（年単位で続くことを想定して）
  • 「過渡期なので…」という言い訳を積極的に使っていく
  • デザインシステムをプロダクトに反映する過程で、画面（デザイン）の不整合は絶対に起こる（避けようがない）
  • 不整合を理由にコンポーネントライブラリの利用を渋ったら、本末転倒。使われないデザインシステム（コンポーネントライブラリ）の始まりはじまり
• デザインに正解はないように、デザインシステムも時間の流れともに変わっていくモノ
• 一種の社内プロダクト（製品）になるので、常に使ってもらっている人からのフィードバックに対しては真摯に受け止める

🍙 #

デザインシステムを取り組むのに必要なことは、知識や経験もだが、一定の不真面目さも必要なのかなと思った。
万事をまじめに考えていると延々と議論が長引いて終わりが見えなくなり、気持ちが疲弊する。
そうなるとモチベーション維持が難しくなるし、デザインに正解はない、あるいは時代や社会変容とともに変化していくものなので、 1 + 1 = 2 にならないことのほうが圧倒的に多い。
「100 点満点を目指すよりも、50 点取れたらハイパー偉業」くらいの気持ちでいたほうが、気楽に仕事を進められるなぁと思った。