こんにちは、freeeのUXチームというところでデザイナーとエンジニアの狭間の生活をしている 
id:ymrl です。このブログの編集長（自称）でもあります。
はやいもので2020年も終わりが近付いてきました。今年は感染症の流行、オリンピック延期、リモートワークやDXブームなど、振り返ってみれば激動の一年でした。そして年のおわりの12月ということで、今年もfreee Developers Advent Calendarとして、12月25日まで毎日いろいろなメンバーがブログを書いていきます。
あらためまして、ymrlです。昨年は デザインシステムをやるためにエンジニアからUXへ異動した話を書きました。今年はもうちょっと具体的にどんなことをやっているのか、去年からのアップデートを含めて書いてみようと思います。
内容は先日Webアクセシビリティの学校 オンライン特別授業 というイベントで発表したものと被ります。
デザインシステムで解決したかった問題
freeeのエンジニア組織ではサーバーサイド・フロントエンドというエンジニアの区別をせず、まとめて「ソフトウェアエンジニア」という括りになっています。UXチームに移籍する前の私はフロントエンドの比重が大きめではありましたが、しかしサーバーサイドのコードもかなり書いていました。いわゆる「フルスタックエンジニア」というやつですね。また、プロダクトに関わるデザイナーの肩書も「UXデザイナー」であり、UI専門というわけではありません。ユーザー調査や分析の知識やスキルがとても重要視されています。
この、フルスタックエンジニアとUXデザイナーという組み合わせは、少人数で早いサイクルでWebサービスを作っていく上では良い組み合わせだと思います。しかし、Web UIという分野はエンジニアとデザイナーのどちらにも特化した人材がおらず、手薄になってしまいます。UIへの取り組み方も人それぞれになってしまい、結果としてfreeeでは、いろいろな問題が起きていました。
- デザイナーごとに作っているUIがバラつく
- エンジニアがデザイナーの作ったものを再現する精度もバラバラ
- CSSの書き方の指針がなく、適当なコピペを適当に配置したり改変したりしてstylesheetsディレクトリ内がカオス
- 同じような見た目だけど「なんか違う」UIが大量に発生
そして、上記のような問題を抱えていることで、生産性が落ちてしまっている懸念も出てしまっていました。デザイナーが毎回ゼロから画面モックを起こしていたり、エンジニアがカオスなソースコードの内容を把握しないと修正したり新しいものを足したりすることができないのは効率がいい状態とは言えないでしょう。
アクセシビリティの施策をやりやすくしたい
2017年ごろから、アクセシビリティに詳しい社員の入社をきっかけに、アクセシビリティを強く意識していく方針が生まれました。視覚障害の当事者の入社もあり、実際にfreeeのサービスのアクセシビリティがどの程度の位置にあり、どういった問題があるのかもわかっていきました。
しかし、それでも実践していくのは非常に大変なことでした。
以前、Zennに Webアクセシビリティ難しすぎる問題 という文章を書いたのですが、ここに書いた内容はfreeeで感じていた難しさが背景になっています。
Webアクセシビリティについてしっかり考えようとすると、どんな問題があるのかを把握するためには想像力を働かせる必要がありますし、実際に行動に移すにはWebデザインにも実装方法にも詳しくなければなりません。アクセシビリティ「だけ」なら勉強すればいいですが、他の業務をやりながらアクセシビリティ「も」やるのはなかなかハードルが高くなってしまいます。そして、それでもアクションに移すことができた有志のメンバーの活動では限界がありました。
一方、当時すでにReactを全社的に採用していて、UIコンポーネントさえアクセシビリティをしっかり考慮して作りこんでいれば、それを使い回してアクセシビリティをかなり向上できる手応えを感じてもいました。しかし、それをやろうにも先述のWeb UIが手薄になっている問題が邪魔をしてしまいます。実現のためには、デザイナーもエンジニアも「同じコンポーネントを使う」という前提を作る必要がありました。
デザインシステムを作ろう
という経緯から、作ることになったのが “Vibes” というデザインシステム（UIコンポーネント集）です。Vibesではデザイナー用のSketchファイルと、実装用のReactコンポーネントを同じ仕様で作って提供することで、高品質なUIを高速で作れる状態を目指しています。デザイナーはSketchのシンボルとして定義されたコンポーネントを組み合わせることで画面デザインをサクッと作ることができ、エンジニアは実装済みのコンポーネントを組み合わせるだけで、マークアップの仕方を悩んだりスタイルシートを書いたりすることなくUIを構築できます。
Vibesを作りはじめたとき、同時に 「ほむほむ理論」 というのも提唱しました。これは、スタートアップのWebサービスは成長の過程においてリニューアルを繰り返し、リニューアルごとにスクラップ＆ビルドされUIの品質が高まっていくというものです。実際、freeeではVibes登場以前に何度かCSSの共通化や仕組みの変更を試みたものの上手くいかなかった歴史があったり、初期に作られた画面のトーン＆マナーが現行のそれと合わなくなったりしていました。Vibesはそういった歴史や前提を踏まえて、見た目を一新しすべてのUIコンポーネントを作り直し、徹底的にスクラップ＆ビルドをやりきる方針で進めています。
Webサービスは最初は雑なUIが用意され、次にリニューアルされて見た目がキレイになり、次の3週目でようやく正しいUIが実装されるという経験則があって、暁美ほむらも3週目でメガネを外して本気になるので「ほむほむ理論」みたいなことを言っていたんですが、暁美ほむらが眼鏡を外すのは4週目だった。
— ymrl (@ymrl) July 2, 2019
- 発売日: 2016/12/21
- メディア: Prime Video
ちなみに、自分以外の人間が「ほむほむ理論」という言葉を喋っているところを見たことはありません。
使い方を伝え、フィードバックを吸い上げる
こうして登場したVibesは、まずSketchライブラリがあることでデザイナーに受け入れられ、Vibesで構築された画面が登場し始めました。そしてエンジニアにVibesを使ったほうが開発効率が上がる実感をしてもらったことで、エンジニアからも積極的に「Vibesを使いたい」という声が上がるようになりました。
しかし、広く使われるようになったものの、いろいろな問題も見えてきました。コンポーネントが作成時の意図とは違う使われ方をしたり、実装の仕様では不可能な変更を施したデザインが作成されたり、そういったデザインのものを組み込んだりVibesの実装に問題があるときにVibesにIssueやPull Requestを送るのではなく個別最適化された実装が作られてしまったりしていました。
そこで、Vibesの使い方を伝えたり、フィードバックを貰ったりするための施策をいろいろとやりました。
サロンを開く
freee社内では、何らかの話題について語らう「場」を作るとき、「○○サロン」という名前をつける風習があります。その風習にならい、デザインガイドラインであるGrooveとあわせ「Vibes/Grooveサロン」という場を集一回設けて、デザインシステムを活用するデザイナーが相談できるようにしています。
あえて時間を取って集まることで、すごく困っている・迷っていることだけではなく、「これでいいと思っているが、時間に余裕があれば一応聞いてみたい」というような質問もできるようになります。また、「こう使ってほしい」を伝えるにも、具体的にデザイナーが悩んだ場所に対して「デザインシステムの上ではこう」という解を提示するほうがわかりやすくなるはずです。
Slackをエゴサーチする
デザインシステムを使う側がどんな場所で困っているのかを知るために編み出した方法として、「ひたすらにSlackをエゴサーチする」というのもあります。とにかくSlackを「Vibes」で検索して、デザインや実装の上で迷っていることや困っていることを拾いあげるのです。定期的に巡回して、もしVibesで実現できるはずのことであれば「こうやればできます」というやり方を示したり、できないことやバグであれば「Issue立てておいてください」と言うようにしています。
エゴサーチで能動的に拾いにいくことで、現場でデザインシステムを使う側からすれば迷う時間が減るし、作る側からすればどんなことで困っているのかが知れて、デザインシステム自体やドキュメントに反映していくことができます。しかし、あんまりやりすぎると「監視されている」と思われてしまいそうなので、やり方は気をつけていかなきゃな、と思っています。
アクセシビリティ向上の仕組みを作る
アクセシビリティも視野に入れて作りはじめたVibesですが、必ずしもVibesで作っただけで、アクセシビリティの問題がすべて解決するというわけではありません。freeeでは独自のアクセシビリティガイドラインを定義して、これを満たすことを目標としていますが、すべての画面がこれを満たすようになるまでにはまだ長い道のりがあります。
Vibesでは、アクセシビリティの担保が難しくなりそうなところを積極的に取り込むようにしています。コントラストの問題が起こりにくいようにカラーパレットを整備したり、キーボードによる操作に複雑な実装が必要なコンポーネントを提供したりすることで、（実際のガイドラインでどうなのかは抜きにして）私の気持ち的には落第点にはなりにくい状態にはなっています。
しかし、フォームのラベル付けなど、複数のコンポーネントを正しく使わないと上手くいかないものがあったり、Vibesに無いものを独自で作る場合があったりするなどで、必ずしもガイドラインをきちんと達成できるとは限りません。そのため、アクセシビリティチェックの仕組みが必要となります。freeeのガイドラインにはチェックリストも付属しており、どういった目的で整備しているのかは中根さんの記事に解説がありますが、今回はどういうやり方でチェックをしているのかをすこし紹介します。
freeeのチェックリストでは、チェック項目が「デザイン」「コード」「プロダクト」に別れています。これはそれぞれデザイナー・エンジニア・QAそれぞれの立場でチェックできるようになっていることを意図しています。freeeで多い開発プロセスでは、デザイナーの設計に従ってエンジニアが実装を行い、QAがリリース前にその動作を確認するため、それぞれのフェーズでチェックが行われることで問題を早く発見できることを期待しています。
また、アクセシビリティが難しい要因の1つである分野が横断的すぎる問題についても、この場ではそれぞれの関心やスキルに応じたチェック内容にすることで対処しています。チェック開始時には、チェックリストが記載されたGoogleスプレッドシートを生成するGoogleフォームに必要事項を入力してもらうようにしているのですが、このときに所属チームに応じて項目がフィルタリングされたシートを提供することで、関係のないものを気にせずチェックできる仕組みも用意しています。
この中でも「プロダクト」については非常に網羅的で、axeのようなチェックツールやNVDAという実際のスクリーンリーダーを用いてテストを行っています。実はチェックリストはQAチームから導入が始まったのですが、リリース前にQAチームがアクセシビリティチェックを行って問題点を指摘することで、その前段階のエンジニアやデザイナーにもチェックを実施する波が広がりつつあります。
おわりに
今回の記事では、Vibesをはじめたいきさつ、Vibesを育てていくためにやっていること、アクセシビリティチェックの運用について紹介しました。まだまだVibesもアクセシビリティもやらなければならないことが山積みですが、より開発フローにフィットする形で育てていきたいと思っています。
そして、freeeではエンジニアもデザイナーも積極的に募集しています！デザインシステムもアクセシビリティも新しい取り組みをどんどんやっているので、より良い開発フローとプロダクトを一緒に作ってくれる人が来てくれたら嬉しいです。
あしたは新卒でSREで、なぜか彼に関係するSlack emojiが大量に作られてしまっているクマシュンの「インフラ未経験の20卒がSREになった話」です。お楽しみに！
