デザイナー向けにReactでUIを組んでみるワークショップをやってみた

こんにちは、freeeのUXチームの id:ymrl です。

今日はアウトプット→思考デーということで、デザイナー向けにReactでUIを組むワークショップをいきなりやってみた話を書こうと思います。

私は昨年、エンジニアからデザイナーになりました 。そしてデザイナーの側に立ってみると、いろいろと効率が悪いなと思うところが多く、そこをどうにか打開できないかと思ってやってみたのがこのワークショップです。

しかしまだその状況は打開できていません。この記事はそんな中途半端な状態の話です。

freee のUI開発の現場、私の問題意識

前提として、freeeのUI開発について説明しなければいけません。

私がメインでやっているのはVibesというデザインシステムの開発です。VibesはfreeeのWebアプリケーションのUIを爆速でハイクオリティに開発できる状態を目指しています。それ以外にも、社内のアクセシビリティ関連の活動をやっていたり、一部の画面デザインをやったりもしています。Vibesに関しての詳細はフロントエンドカンファレンス福岡で発表した資料で紹介しています。

speakerdeck.com

私の業務内容が実装物のコーディングに近いところにいる一方で、ほかのデザイナーはこれまでコーディングとの距離が遠くなりがちでした。プロダクトデザインをしているデザイナーが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を使うようにしたり準備部分を丁寧にするなどの手を加えました)

コマンドの打ち方の説明。「コマンドの前の $ の部分は打ち込まない」という説明をしている。
コマンドの打ち方の説明。「コマンドの前の $ の部分は打ち込まない」という説明をしている。

GitHubに公開鍵が登録されているのかの確認の説明スライド。sshコマンドを試してダメだったら次のページへ行く
GitHubに公開鍵が登録されているのかの確認。sshコマンドを試してダメだったら次のページへ行く

事前準備は非常に丁寧に作った一方、「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 の記事をお読みください

developers.freee.co.jp

そしてアウトプット→思考デーのアウトプット→思考な記事たちは、カテゴリーページから一覧できます。

developers.freee.co.jp

私は2017年にこのfreee Developers Blogを立ち上げ、そして今日の @noblejasper の記事にあったように、freeeという会社のやっていること、楽しさや面白さを社外の皆さんに知ってもらえたり、社内の開発者のワクワク感を盛り上げることに繋ったりするといいなと思いながら自称編集長をやりつづけてきました。

今日のこのアウトプット→思考デーの企画も、本当に行きあたりばったりでやってみたものですが(まさにアウトプット→思考)、freeeの開発チームにすこしでも興味を持っていただければ幸いです。

jobs.freee.co.jp

突撃!隣のリモート環境

こんにちは、エンジニアのスポーンです。 早いもので新卒入社をしてから約1年が経ちました。

本日はアウトプット→思考デーという社内のアウトプットを促進するイベントの日なので、弊社社員のリモートワークについて書いていきます。

freeeでは現在、新型コロナウイル感染症拡大の影響で全従業員が在宅勤務となっています。 以前エンジニアのmassが愛知県の大三島からリモートワークのノウハウについて書いていましたが、今回の記事では他の社員のノウハウも共有していきたいと思います。

バーチャル出社をする人

バーチャル出社をする人
バーチャル出社をする人
UXデザイナーの id:ymrl はバーチャルなアバターを使って出社をしていました。会話するときの表情や手の動きをキャプチャーして、声もボイスチェンジャーを使って可愛い声に変えています(!)

全社集会でもこの姿で登場し、役員とのミーティングもこの姿でやったようです。

車の中で面接対応する人

リモートワークの悩みで 集中できる環境がない というのは多くの人が頭を抱える問題ですね。

ご家庭を持っている方だと家族からの理解を得る難しさや、家庭内の様々な理由で割り込みが発生してしまうこともあります。

特に作業環境として難しいのが面接や商談などの、外部の人とのコミュニケーションの場です。 そこで、車の中ならノイズが無く集中できるのでは無いか?と試している人がいました。

車内面接の様子
車内面接の様子

CISOのtosa

  • ガソリンの減りが気になる
  • やたら暗いところから面接者とつなぐので、なんだか申し訳ない
  • 長く駐車場にいると、猫とか狸とかよく通るのがわかる
  • ご近所さんの目が気になる

と語っていました。

ランチを自炊する人

料理が好きな人にとってはランチの自炊もリモートワークのメリットですよね。 中には非常に凝ったランチを自炊している人もいました。

ブリと青柳のカルパッチョ
ブリと青柳のカルパッチョ

柿の白ワイン蒸し ジュレ添え
柿の白ワイン蒸し ジュレ添え
鯛のポワレ パンプキンソース
鯛のポワレ パンプキンソース

牛タンのステーキ アスパラとともに
牛タンのステーキ アスパラとともに

このメニューで材料費は1000円以下、調理時間は30分以内に収めているそうです。 僕は自炊ランチでジュレを使っている人を初めて見ました...(オシャレなお皿は3coinsで買ったそうです。)

まとめ

いかがでしたでしょうか?

普段と違うリモートワークでも生産性を高めるために色々な工夫をしている人を紹介しました。

spawnのリモート環境
spawnのリモート環境

僕もモニターの上にディスプレイ用の台を設置して、趣味のプラモデルを飾って仕事へのモチベーションを上げています。

DevBranding(技術ブランディング)チームを立ち上げて1年が経ちました。

はじめまして!こんにちは、freee株式会社のDevBrandingを行っています@noblejasper です。

今回「アウトプット→思考デー」というDevBrandingチームにうってつけの機会!チームの紹介も兼ねて、freeeの技術ブランディングはどんな事をやっているのかを書きたいと思います。freeeの技術やプロダクト、エンジニアを知る一つのきっかけになってもらえたら嬉しいです!

DevBrandingチームの目的

DevBrandingというのは、社内の有志のメンバーで2019年3月に発足し、技術広報やブランディング活動をしているチームです。気づいたら1年が経過していました。

チーム発足当時、まずはチームの目的を決めようという所からスタートしました。集まったメンバーと話している中から

  • freeeのエンジニアのやっていること、雰囲気をわかってもらいたい = ブランディングの向上
  • freeeで働くエンジニアたちのワクワク感を向上していきたい = 内部的訴求
  • freeeのエンジニアリングを知って面白いと思ってほしい = 外部的訴求

の3つがコアな想いだという事が見えてきました。そこでブランディング向上、内部訴求、外部訴求を包括した形で、目的を決めました。

『freeeがエンジニアにとってのあこがれの場所になっていること』

が我々DevBrandingチームの目的です。現時点でも同じ目的を目指していますが、活動の形も少しずつ変わってきています。今後目的の変化もあってもいいのかもなと考えていたりもします。

DevBrandingのメンバー

6〜7人のメンバーで主に活動しています。 人数が変動的なのは、本業に集中したい時期などの兼ね合いで流動的に活動していることが多いためです。

毎週金曜日にメンバーで集まり、判断事項の相談や進捗の確認を行っています。

会議室でブログをもくもく書いてた日の集合写真
DevBrandingメンバーでDevelopers Blogをモクモクと書いている日もあったりします

取り組んでいること

技術ブランディングに関係することは幅広くやっており、メンバーそれぞれが自立して動いている部分などもあります。

今回は特に私が取り組んでいる事を書きたいと思います。

  • カンファレンススポンサー関連
  • DevBrandingの効果測定
  • 登壇、イベント開催サポート

などが主だった取り組みです。

カンファレンススポンサー関連

freeeとしてスポンサーする技術カンファレンスや技術イベントの情報収集やスポンサー可否の判断などを行っています。長期的に、freeeの扱っている技術と親和性が高いカンファレンスをつなげていきたいと考えています。大なり小なりDevBrandingチームが関わってスポンサーの協賛をしたり、イベント参加したものは年間30イベント以上ありました。

カンファレンススポンサー関連だと、ブース運営におけるアイデア出しなどもしています。スポンサーブースで配布しているフライヤーを作ったり、スポンサーブースに来た方と話しやすくする工夫などをアイデアを相談しながら実施しています。

話しやすくする工夫の例でいうと、iOSDC2019やCloud Native Days Kansai 2019で、「確定申告をしたことがありますか?」というスケッチブックを持ってブース近くを通りがかった人に話しかけやすく、答えやすくするというのを行ってみました。(よく見るやつではありますが)

developers.freee.co.jp

developers.freee.co.jp

このアンケートは話しやすくする効果としてはとても良かったです。それだけではなく、副次的な効果もありました。

なんと、ブースに来てくれたおおよその人数が後から計測出来るのです。大した事ではないように思えますが、今まではブース運営スタッフの肌感でしか判断出来なかった数値が可視化されました。これが次の効果測定につながってきます。

DevBrandingの効果測定

DevBrandingを立ち上げた当初から、DevBrandingの効果を測定したいという気持ちが私の中にありました。有志で集まっているからこそ、DevBrandingが何の効果を生んでいるのかを可視化したい。と思っていました。

実のところ効果測定に関してはまだまだ出来ていない状況です。

まずはデータを取る所にチャレンジしてみました。接触した人数や興味を持ってくれた人を数える事から始めてみました。

  • 前述のスポンサーブースに来てくれた人数を記録
  • freee Developers Blog のアクセス数やリピーター数を分析
  • イベント参加前後でのTwitterのフォロワー数の増減数を記録
  • 自社主催イベント(freee Tech Night)に参加してくれた人のリピーターの数を取得

などを行っています。

ここはまだまだ試行錯誤が必要な段階だと思っていて、理想としては「あこがれてくださっている人数」を可視化していける仕組みづくりをやっていきたいと思っています。その数字を指標に活動していけるチームになっていきたいなと思っていたりします。

アウトプットの質より量を増やしていきたい

スポンサーや、効果測定などの話をしてきましたが、まず大切なのはアウトプットの量なのではないかと思っています。

アウトプットの量で言うと、もっと多く出していけるのではないかという課題感を持っており、どうやって出していくのかもチームで相談してアクションしていっています。今はまずDevelopers Blogを盛り上げていこうとしています。

  • 社内向けの記事で外部に出せそうなものを書いている人に相談してBlogを書いてもらう
  • 社内で起きた事でBlogに出したいものを書いてもらえないか打診する
  • 自分たちでもBlogを書く

などを行っています。

自分たちでもBlogを書くという項目がありますが、実は私はfreee Developers Blogに記事を書くのは初めてです(笑)

今回の「アウトプット→思考デー」をきっかけに書く事が出来ました。よかった。 本日「アウトプット→思考デー」にBlogを書こうという話もDevBrandingのMTGの中で出た話でした。実現出来てとても嬉しいです!

これからやっていきたいこと

まだまだやれること、やりたいことはたくさんあります。 最後に書いたようにまずはアウトプットの量を増やしていく事にフォーカスしたいと思っています。

freeeから外部へのアウトプット量を増やし、効果測定で可視化することで加速していければいいなと思っています。

freeeがエンジニアにとってあこがれの場所になれるようにこれからも頑張っていきます!

チームのふりかえりフォーマットを色々変えてみた話

こんにちは、ミツバ(id:MitubaEX)です。 19新卒でfreeeに入社して、もうそろそろ1年が経とうとしています。 僕が所属するチームでは、数ヶ月前から毎週ふりかえりのフォーマットを変えてみてゆるーくふりかえりをしています。 今日はアウトプット→思考デーということで、そこらへんの話を書こうと思います。

想定読者

  • ふりかえり自体に何か変化を起こしたい人
  • ふりかえりフォーマットに困っている人

背景

僕が所属するチームは以前からKPT(Keep, Problem, Try)でふりかえりをしていました。 しかしこのKPTをずっとやっていると以下のようなことを思うようになりました。

  • 議題が抽象的で逆に議論する項目が出ずらい感があったり
  • フォーマットが変化しないことによってチームの出てくる課題感の偏りみたいなのも感じる

そんな時にジャーマネ(チームをマネジメントしてくれている人)からrandomretros というものを教えてもらいました。

randomretros.com

その名の通り、ランダムにふりかえりフォーマットが出てきてそれに沿ってふりかえりができるサイトです。 面白そうだなと思ったので、チームで活用していくようになりました。

もちろんKPTも良いフォーマットだとは思っていますが、ふりかえりを楽しくするという観点ではやっぱりフォーマットが変化していく方が司会、参加者のモチベーションも上がると思うのでやっていこうかなと思いました。

前提

  • ふりかえりは一週間ごと (間隔は短め)
  • 司会は持ち回りで行う
  • 司会の人がrandomretrosのフォーマットを元に資料作成

実践したふりかえりフォーマットとそれぞれの所感

実践したふりかえりフォーマットの一部をざっくり紹介します

📊Liked, Learned & Lacked

フォーマット

以下の項目を記入して議論

  • ❤️Liked: 一週間で楽しかったこと、好きだったこと
  • 👩‍🏫Learned: 一週間で学んだこと
  • 👀Lacked: チームメンバーが必要だったもの
所感
  • Liked、Learnedにはポジティブなことが書けるので、ふりかえりの雰囲気は良かった
  • Lackedは、KPTでいうところのProblemに当たる部分だが、良かった部分が目立ってそこまで議論できていない印象だった
  • 良かったことを伸ばしていくことには向いていそう

📈Health Check

フォーマット

以下の項目ごとに今の健康状態を記入して議論

  • Delivering value - 価値の提供 -
  • Collaboration - コラボレーション -
  • Honesty - 正直・誠実 -
  • Fun - 楽しい -
  • Learning - 学習 -
  • Speed - 速度 -
  • Ways of Working - 働き方

健康状態は以下の三つ

  • 🌳完璧ではないかもしれないが満足している
  • 🌕いくつかの問題があるが災害(異変?)ではない
  • 🍅対処しなければならないいくつかの深刻な問題がある
所感
  • 色で問題のある箇所が一目でわかるかつ、資料がカラフルになって心も踊る
  • 文字をあまり記述しないフォーマット(健康状態が主)なので、そこまで詳細な議論はできない印象はあった

🎎守破離

フォーマット

以下の項目を記入して議論

  • 守: どういうことを学び実践しましたか?
  • 破: どんなルールを破る/変えることができましたか?
  • 離: どんな新しいアイディアや実験を試すことができましたか?

参考: 守破離 - Wikipedia

所感
  • 守は書きやすいので皆書いていたが、破、離が凄く難しい
  • 破は、日常やらないことをやったみたいに軽めに考えると書きやすい印象 (業務ベースでは意外と難しい)
  • 離は精進するしかない

🧞Genie in a Bottle

フォーマット

以下の項目を記入して議論

  • 自分自身に望むこと
  • チームに望むこと
  • 他に望むこと

※三つの願いを叶えてくれる的なアレ

参考: Wishing Retrospective - Chris's deck

所感
  • 全体的にP寄りのフォーマットで、個人のProblemなんかも見れて面白い
  • 他に望むことには、自由なことも書けるので世界のこととかも書ける(面白い)
  • 理想ベースで考えているので、来週までに行えるTryが出にくい印象はあった

今後の展望

KPTから色々なフォーマットに変更したのは良かったのですが、 あまりにも業務に関連しないふりかえりをやってもそこまで有益ではないなと思い始めました。 なので最近は今週のタスクのプロセスごとに各自でレビューしてみて、問題や改善できそうなことを書いていくみたいなフォーマットにしてみたりしました。 実際の業務をふりかえることが、議論しやすくて良さそうな印象でした。 もちろんずっとプロセスをふりかえるだけじゃダメだと思うので、都度フォーマットは変えていくのが良さそうです。

まとめ

やってきたフォーマットを4つほど紹介してみました。 どれも面白いものばかりでしたね! 皆さんもふりかえりの議論がマンネリ化した時には、ぜひ他のフォーマットを使ってみてください。