こんにちは、freeeのUXチームの 
id:ymrl です。
今日はアウトプット→思考デーということで、デザイナー向けにReactでUIを組むワークショップをいきなりやってみた話を書こうと思います。
私は昨年、エンジニアからデザイナーになりました 。そしてデザイナーの側に立ってみると、いろいろと効率が悪いなと思うところが多く、そこをどうにか打開できないかと思ってやってみたのがこのワークショップです。
しかしまだその状況は打開できていません。この記事はそんな中途半端な状態の話です。
freee のUI開発の現場、私の問題意識
前提として、freeeのUI開発について説明しなければいけません。
私がメインでやっているのはVibesというデザインシステムの開発です。VibesはfreeeのWebアプリケーションのUIを爆速でハイクオリティに開発できる状態を目指しています。それ以外にも、社内のアクセシビリティ関連の活動をやっていたり、一部の画面デザインをやったりもしています。Vibesに関しての詳細はフロントエンドカンファレンス福岡で発表した資料で紹介しています。
私の業務内容が実装物のコーディングに近いところにいる一方で、ほかのデザイナーはこれまでコーディングとの距離が遠くなりがちでした。プロダクトデザインをしているデザイナーがSketchでUIのデザインをして、それをバックエンドも兼任するエンジニアがコーディングするというフローで開発していました。Vibesも、そういうフローのなかでデザイナー側もエンジニア側もアウトプットの品質にばらつきが出てしまう問題意識から始まったプロジェクトでした。
Vibesによってデザイナー向けのSketchファイルと本番で使われるReactコンポーネントの見た目が一致した状態で提供されるようになって、品質のばらつきは抑えられるようになってきました。しかし一方で、生産性のうえではまだ改善の余地があるなと思っていました。
Sketchファイルに含まれる情報はコンポーネントの見た目だけです。見た目からある程度はそのコンポーネントはどういうデータを受け取れて、どういう表示ができるという仕様を読み取ることはできますが、すべての仕様を読み取ることはできません。たとえば「ここに入るテキストは改行できるのか」とか「このコンポーネントはこういうときに横幅はどうなるんだろうか」みたいな情報は、現物を見なければわかりません。
そこで Storybook で実際に触れる状態のコンポーネントを提供したり、addon-knobs でコンポーネントに渡すpropsを操作したりできるようにしているのですが、それでも細かいところはソースコードを見ていかなければなりません（これには私がドキュメントを書くのをサボりがちになっている問題もあるんですが……）。実戦でHTML/CSS/JavaScriptをある程度書いていたことがある人なら、ある程度の勘が働くところも多いのですが、デザイナー全員がそういうわけでもありません。
デザイナーもコードに触りたい
一方で、現状でコードに触れていないデザイナー側も問題意識を持っていました。話を聞いてみると、みん本番で動いているフロントエンドのコードで、自分で書けそうなところは自分で書きたい、修正できそうなところは修正してみたいと思っているものの、なかなか踏み出せていないようでした。
- HTMLやCSS、簡単なJavaScriptならやったことあるが、Reactのような本格的フレームワークは触ったことがない、もちろんFlowやTypeScriptを使ったことはない
- エンジニアとしての知識がない状態でローカルでサービスを動かす環境構築をするのが大変で、動作確認が難しい
- 黒い画面がよくわからない、失敗したらどうなるかわからなくて怖い
両方ともに課題感があるんだからやるしかない！ということで、デザイナーがコードを書くワークショップを開催しました。
ワークショップの準備
ワークショップのゴールとしては以下のような内容を考えました。
- デザイナーがVibesのコンポーネントの仕様を理解する手助けになるような勘所を身につけられる
- デザイナーがVibesのコンポーネントを組み合わせて実際のUIをコーディングできるようになる
- デザイナーがあわよくばプロダクトのコーディングに参加できるようにする
ということで、内容としてはこうなりました。
- 絶対に躓かない開発環境構築の事前準備資料を用意して、その通りに事前準備をする
create-react-appコマンドを打ってアプリケーションを作り、npm install --save-devでVibesを追加する- あわよくば現場のコードにコミットできるよう、TypeScriptを使用する
- エディタは標準でTypeScriptをサポートしていて、社内にもユーザーが多いことからVisual Studio Codeを推奨
- Vibesのコンポーネントを並べてUIを作る
ここでのキモは「絶対に失敗しない事前準備資料」だと思っていて、CLIでの操作をほとんどしたことがなくても絶対に間違うことのないよう、コマンドの打ち方から説明したり、自分のマシンの状態を確認しながら場合分けして必要な設定ができるように工夫してスライドを作りました。 （実は過去に近い内容を新卒研修用に作ったものがあったのでそれを流用しつつ、TypeScriptを使うようにしたり準備部分を丁寧にするなどの手を加えました）
事前準備は非常に丁寧に作った一方、「Reactとは何か」「TypeScriptとは何か」「Redux」「ステート」…… といった内容についてはほとんど説明しないことにしました。そこをわかってなくても今回の課題をやるには十分だし、とにかくまずはできる範囲で「UIが作れた！動いた！楽しい！」と思ってもらえれば十分と思っていたからです。
やってみた
ワークショップは会議室を3時間ほど押さえ、基本的にはスライドを見ながらもくもく作業し、上手くいかない場所やわからないことがあったら講師である私や、参加者どうしで助けあうという形式にしました。また、さらに上級編としてただコンポーネントを並べるだけでなく、freeeが実際に使用しているAPIを保存したJSONを読み込んで、UIに表示してみるという課題のワークショップも追加で行いました。
事前準備の書き方を丁寧にしたおかげか、ほぼ全員がワークショップまでに環境構築をスムーズに終えることができていました。おかげで「ワークショップの大半が環境構築になる」という最悪なケースにはならずに済み、ワークショップは満足度の高いものになりました。
もともとはお手本を用意してそれを作ってもらうという感じで始めましたが、なかにはいろいろなコンポーネントを並べるのに挑戦した人もいました。
ワークショップをやってみて
こういったワークショップをやってみて良かったことやわかったことがいろいろとありました。
デザイナーが動くプロトタイプを作ってみる流れが生まれた
このときに作った資料やサンプルコードのおかげで、Sketchのようなデザインツールだけでなく、実際にブラウザで動作するかたちでプロトタイプを作ってみるデザイナーが現れたのはいちばん嬉しい効果でした。
簡単なものであればSketchで作るのも良いですが、より細かい精度でユーザーの使い心地をテストするには、実際にブラウザ動作するプロトタイプという選択肢があるのは良さそうです。
TypeScriptはやっぱり難しい
現場のエンジニアとコラボレーションできるためには静的型付けなコーディング環境があるべきだろう、と思ってTypeScriptをやってもらいましたが、こちらが用意した課題の範囲でやるならまだしも、自由にプロトタイプをやるには難しいという状況のようです。プロトタイピングの選択肢を増やすことを目的に据えるなら、ここは考えなおす必要がありそうです。
デザイナーがReactに入門する良い資料は何だろう
ワークショップの課題は私がお手本を作ったうえでなぞってもらえばいいのですが、その先の道標を用意できていないのが現状です。React公式のチュートリアルに挑んだ人もいたのですが、欲しいものがちょっと違うという感じだったようです。たしかに、デザイナーにはtic-tac-toeを作りながらpropsやstateについて知ることは求めていないような気がします。
もうちょっと実戦に近いものがあると良い気がするんですが、なかなか良さそうなものが見つけられていません。思いあたるものがある人は Twitter (@ymrl) なんかでこっそり教えてもらえると嬉しいです。
おわりに（1日のおわりに）
今日はアウトプット→思考デーとして、続々と記事を公開してみました。いかがでしたでしょうか？
「アウトプット→思考デーって何？？」と思った方はぜひ、今日の1本目の記事である aniki の記事をお読みください
そしてアウトプット→思考デーのアウトプット→思考な記事たちは、カテゴリーページから一覧できます。
私は2017年にこのfreee Developers Blogを立ち上げ、そして今日の @noblejasper の記事にあったように、freeeという会社のやっていること、楽しさや面白さを社外の皆さんに知ってもらえたり、社内の開発者のワクワク感を盛り上げることに繋ったりするといいなと思いながら自称編集長をやりつづけてきました。
今日のこのアウトプット→思考デーの企画も、本当に行きあたりばったりでやってみたものですが（まさにアウトプット→思考）、freeeの開発チームにすこしでも興味を持っていただければ幸いです。
