Amebaのデザインシステム「Spindle」の舞台裏(個人的な感想)

先日会社のブログにて、僕が関わっているAmeba事業のデザインシステム「Spindle」の紹介と、SpindleのWebサイト公開をしました。

公開したとは言っても、まだ社外に公開するにあたって整えきれていないコンテンツなどはまだ出せていないですが、公開に足る最低限のところまでは整えられたかなと思います。引き続き、改善やコンテンツの充実を進めていく予定です。

さて、記事の内容は広報的に整えましたが、そこで書ききれなかったことや、その他の裏側っぽいところを残しておこうかと思います。

アメブロとはある種の競合ともいえるnoteで書くのはやや背徳感もありますが、まぁそれはそれで。

この一歩を実現するには恵まれた環境だった

先ほどの記事では偉そうに僕が色々と書いてはいるものの、大元のブランド設計や、その中身の設計や開発のところは強力なメンバーが居たおかげや、事業としてのタイミングの良さのおかげでした。

例えば、デザインリードの本田は、以前に会社のブログにも記事を書いてもらいましたが、カラーパレットの作成やコンポーネントの設計の基盤は彼の力によるものです。論理的に、工学的に、言語化しながら進めてもらいました。テックリードの原は、Ameba事業のテックリードでもありますが、Webやパフォーマンスのエキスパートであり、コンポーネントの実装設計やDevOps周りもサササッとやってくれています。

あと状況として記事に書いた通りですが、ブランディングを動機として始められたことがとても大きかったといえます。あとは設計・開発の効率化や生産性を高めるというのが事業課題として顕在化していたので、投資するには絶好の機会でもありました。ただここに前述のようなメンバーを100%でアサインするというのは厳しいので、現実的には兼業であり、実体として個々人のキャパシティでいえば100%を越えていると言えます。

とはいえ、結局各々のチームやプロジェクトで設計・開発するときに作らないといけないものをちゃんとドキュメントにして、ある程度の再利用性と拡張性を見込んだものをつくる、ということに改めてちゃんと向き合った良い機会だったとも言えます。

答えのないデザイン原則

デザイン原則のライティングを担当したのですが、デザインシステムにおけるデザイン原則というものには大変苦労しました。事業としての筋はブランド定義の流れから方向性は見えていたものの、これだけでも半年以上はかかったんじゃないかと思います。

Amebaのデザイン原則「敬意・軽快・情緒・歓迎」

Amebaのデザイン原則は敬意・軽快・情緒・歓迎です。それぞれ補足説明がありますが、今でも個人的にはこの内容やワーディングで良いのだろうかと悩んでいます。間違ったことは書いていないと思うものの、もっと印象的で、かつ具体的にどうするのかが直感的で...など色々と考えています。

Amebaという事業はブログが主軸であるものの、多様なサービスを抱えています。本当にAmeba全体を視野にいれたもので考え始めると、例えばブログサービスとしての体験のみに言及するのも違うななどと考えます。言い訳みたいなものですが、それを広げていくと、どうしても抽象的になりがちなのかもしれません。

あとは教科書的な「デザイン原則」というものに縛られる必要もないとないとも考えました。もっと「行動指針」ぽいものとか「べからず集」みたいなもののほうがいいか、など色々と在り方そのものとも向き合いました。それなりのバージョンの原稿をつくっては、ブランド戦略チームや他のメンバーにフィードバックもらい、そうして今のバージョンに着地しました。おそらくはどこかでSpotifyのように、デザイン原則の内容やその在り方が変わる時が来ると思っています。

コンテンツに関するガイドラインが足りない

Spindleでは現状コンポーネントライブラリようなもの以外にも、アクセシビリティに関するガイドライン等、デザイナーや開発者ためだけのものではない重要なコンテンツはあります。あるいは営業資料用のスライドテンプレートがあり、これらは営業やセミナーなどを開く人に役立ちます。順当に中心メンバー、デザイナーでやれることから進めていった結果ではありますが、もっと早めに進めたかったことはコンテンツガイドラインでした。

ここで僕がいうコンテンツガイドラインというは、MailchimpのContent Style Guideのようなものです。主にライティングに関するガイドラインではあるのですが、ただ単純に表記ゆれや「です・ます調」のような基準だけではなく、どういうときにどういう語りかけをするのか・そこにどういった「らしさ」を持つかといったところまでのガイドがあるが理想的です。こうしたものであれば、職種問わずに「らしさ」の伝え方や一定の品質などが担保されるはずです。また単純に文章に関するガイドだけでなく、エラーページやデータが0件の時(Empty state)のデザインといったものも含まれてくると考えています。

Spindleでもガイドラインの下地はあるものの、正式なドキュメントや補助するツールなどはまだ十分ではないので、これらにも力をいれていきたいところです。

デザインシステムという表現

ブランドアップデートの手段のひとつとして「デザインシステム」を掲げたわけですが「デザインシステム」という呼称は内部ではほぼ使っていません。記事にある通り「デザイン」と「システム」が第一印象で「すべての人」に届けづらいと考えたためです。ブログの方でも引用した記事でも書かれているのですが、「デザインシステム」という呼称自体に固執する必要はなかった、というのはここまでの実感です。日常的には「それSpindleにあるよ」とか「これはSpindleで定義したいね」などとやりとりされています。

一方で「Spindle」がなんでも解決してくれるもの、のようになっているのが良いのか悪いのか、という気持ちもあります。意図的に広く適応できるものとして考えてはいるものの「Spindleでは解決しないもの」というような定義もあると良いのかもしれません。「何でも解決できるもの」と期待されるものは「何も解決できないもの」に成り果てるのはよくあることです。

あとは「デザインシステム」という表現に関しての話に戻ると、ここ1年くらいで出てきたものの多くは「スタイルガイド」や「コンポーネントライブラリ(パターンライブラリ)」といった従来のものに該当するものが多いと感じています。これについてはかつて(今も?)「UX」がさまざまな使われ方をされているのと同じように感じますが、UXほどは丁寧な定義はないと僕は考えているので、どう呼ぶは基本的に自由だとは思います。とはいえ、組織の中で定義するにあたっては「それが何なのか」を踏まえて、結果「デザインシステム」と呼ぶのかは考えるべきだと思います。

中心メンバーが抜けても継続できるか

これは一番の悩みどころかもしれません。Spindleではデザインシステムに関するチームモデルの考え方でいうと「連合モデル+中央集権モデル」のハイブリッド型といえます。(図は記事より引用)

連合モデルと中央集権モデルのイメージ図

サイバーエージェントはさまざまな事業・組織があり、文化として本人の希望と移動先の組織側の需要とマッチすれば異動できるようになっています(もちろんいろんな事情やタイミングで難しい場合もありますが)。あるいは単純に転職といった理由で中心にいた人が抜けてしまう、というのはよくある話です。

2年前に参加したデザインシステムのカンファレンス・Clarityを振り返ったときに「デザインシステムって、なんだなぁ」などと同僚と話していたのですが、デザインシステムの肝はガイドラインやライブラリといった成果物のデザイン以上に、組織をどうデザインするか・組織でどうデザインするかだと感じています。

幸いにも、Amebaの多くの人がSpindleに対する積極的なフィードバックや貢献姿勢があって助かってはいるのですが、多くの意思決定をする中心メンバーが欠けた場合はどうなるか、と考えることがあります。ただ、この手の話は結局デザインシステムの話というよりは、実際にユーザーに提供しているプロダクト開発においても同じ話で「誰かが抜けても死なない」ようにやっていくしかないでしょう。Spindleに関していえば、それこそプロダクトデザインや開発において、スター的な人の頭の中にしかなかったものが、Spindleの中で資産化することによって受け継がれていくものしたいと考えてます。そうするとますますSpindleは死ねないな、ということに回帰するので、このあたりにも向き合わないといけません。

結論、やってよかったデザインシステム

色々と反省や不安、今後の展望を綴りましたが、振り返ってみて「やってよかった」「よくできてるな」と思っています。それは自画自賛というわけではなくて、Spindleに関する組織内でのサーベイや、先ほど挙げたような協力者の多さなど、まだまだ小さな芽ですが一過性のプロジェクトでは終わらないものになっていると感じているからです。

そうやれたのも「目的」と「手段」を分けて考えられたからでしょう。「デザインシステム」そのものが目的化したり、本当に今必要なものがデザインシステムと呼ばれるものであるのかは見極める必要があります。Spindleはそれなりに大きなデザインシステムになりそうですが、少なくともはじめはデザインシステムというほど大層なものじゃなくて良いでしょう。

このnoteに書いた通りの課題や、細かいことでいえばバージョニングの問題とか色々山積みですが、ひとつのプロダクト作りのように設計と開発を個人的には楽しめています。

今デザインシステムのようなものを検討している人や組織にとって参考になる内容かはわかりませんが、ひとつの体験談ということで。

明日の元気の素になります。