こんにちは、DevBrandingのellyです。7月30日に配信した「freee Tech Night 〜全サービス新デザイン！リブランディングの裏側」の様子をご紹介します。
今回からfreee tech nightも心機一転、新デザインに変更しています。
freeeは6月22日にリブランディングを実施しました。それに伴い全サービスを新デザインにアップデートすることとなり、今回はアップデートに対応したエンジニアと UXデザイナーをゲストに迎え、大規模な変更や改善を乗り越えるコツについて詳しく話してもらいました。
ymrl: 写真左上 2014年1月入社 エンジニアとして入社し、現在はUXデザイナーとしてfreeeのデザインシステムを構築。 アクセシビリティ向上にも取り組む。
keik: 写真右上 2017年1月入社 アプリケーションエンジニア。 freee人事労務の開発を担当。 機能開発よりも品質・生産性マネジメントをしていることが多い。
のぶじゃす (@noblejasper): 写真右下 ラジオパーソナリティ、2017年に中途入社 mixi、ソーシャルゲーム企業でソフトウェアエンジニアを経験し freee に。入社後はエンジニア→エンジニア採用担当→エンジニアと DevBranding を担当。 しゃべりたがり。声が大きい。
リブランディングに伴いプロダクトの名前、ロゴ、色を変更
今回のリブランディングで2人は主に何を担当したのですか？
ymrl: 6月22日に新ビジョンのブランドイメージ”誰もが自由に経営できる統合型経営プラットフォーム”を発表していて、それと同時に各プロダクトのロゴが変わり、ネーミングルールも”会計freee”→”freee会計”のように”freee”が前に来るように変わりました。ロゴの色も鮮やかな色に変わっています。
プロダクトの数はどれくらいあったんですか？
keik: 規模の大小はあるものの、全部で50個くらいあってかなり大がかりな動きだったと思います。
ymrl: 当日デプロイしたものでいうと14個でした。
激しいですね。ステークホルダーの数も多いし日程調整とかも大変だったのではないですか？
ymrl: freeeのブランドチームとTakramさんというデザイン会社さんに入っていただいて、freeeとして実現したいことを言語化して作り込んでいました。 そこから「誰もが自由に経営できる統合型経営プラットフォーム」というビジョンが決まり、デザインフィロソフィーも作っってそれをプロダクトに反映していくんですが、各プロダクトにそれぞれプロジェクトマネージャー、エンジニア、デザイナーがいて、私みたいに全部を横断してる人やQAがいて、50人以上は関わっているでしょうね。
その合意を取りながら進めるのはヤバそうですね。 keikさんはどんなことをしていたんですか？
keik: 私はfreee人事労務のロゴ、文言、色の実装を担当していました。
ymrlさんが配ったものを実際に適用していったということですね。
keik: 実装作業は私が行い、その変更のレビューは別のメンバーにしてもらうという感じでしたね。
工数はどのくらいかかりました？
ymrl: リブランディングのプロジェクト自体は去年始まって、去年の年末に社内に発表されました。プロダクトの作業は今年の2月からスタートして、最初にブランドチームとUXチームで発表当日に何をどこまでやるのか、その先どうするのか、何をやって何をやらないみたいなことを決めて、4月からロゴとかのファイルを配る準備をしてました。UIの色変更は2ヶ月くらいかけて5月半ばまでやっていました。
それで6月22日リリースですよね？（笑）
ymrl: はい（笑）freee会計とかfreee人事労務みたいにユーザー数が多いプロダクトは発表当日にやり切りました。
デザインシステム”Vibes”をアップデートしデザインを一括変更
ymrlさんはデザインシステム”Vibes”（社内の標準UIコンポーネントライブラリ）のオーナーですよね。それが今回のような一括変更にどう役立ったのか教えてもらえますか？
keik: そうですね、めちゃくちゃ助かりました。Vibesが適用されている部分はそちらのバージョンアップだけ行えば後は何もしなくても変わるという状況なので。
Vibes 自体をymrlさんが直すときはどうでしたか？
ymrl: はじめは元々のパレットを入れ替えればいいかなと思ったんですけど、ブランドイメージががらっと変わって、これまでは主張の激しくない控え目な青色だったのが今回軽やかな明るい青色になったので、これまでと同じ使い方をすると画面がちょっと眩しいというか、ぎらぎらした感じになってしまいました。
2カ月くらいかかったと言っていたのはそこの調整ですね。 これまでのUIとほとんど変わってないように見えつつも、実は青色だったところを控え目なグレーや黒に変えた場所があったりします。一番分かりやすいのはヘッダーのグローバルナビゲーションが白くなったところで、ここはやっぱり白くないとダメだなぁと思って結構頑張りました。
デザイナー側は開発段階でどんな準備をしていましたか？
ymrl: デザイナー側は細かく変えていくというだけで、Vibes も実装に対してはあんまり頑張った場所はなく、色を置き換えたものを粛々と作ってました。ただ、さっき言ったようにどこに何色を配置するというのを結構変えてるので、なるべくコードが増えないようにしつつ両バージョン存在する状態にするというのはちょっと頑張んなきゃいけなかったなと。
Vibes適用外の部分はカラーコードを定数化、正規表現置換でいつでも再生成可能にすることでメンテンナンスコストを最小に
エンジニア側ではどういう工夫をしましたか？
keik: Vibesを使ってる部分は、全然何もしていないです。ただし、Vibesの適用は進行中でプロダクト全域に対して適用されているわけではないので、適用されていない部分は根気強く grep をするというガッツに満ちたやり方をしていました（笑）
プロジェクト自体は3月から聞いていて、実際に色が決定したのは5月だったんですが、色は追って統一されるということを見越して、ハードコーディングされているカラーコードをgrepしてかつそれを定数に置き換えておけばどんな色がきても対応できるだろうってことでコツコツ定数化していくというのを積み重ねていきました。
それは便利ですね。とはいっても5月までの間途中で入った修正とはどう戦ったんですか？
keik: あんまり早くブランチ作っても、コードの変更でコンフリクトが発生してブランチのメンテナンスにかなりのコストがかかってしまいます。やった工夫は、定数を使うのもそうだし、それをやってもコンフリクトするところはあるんで、正規表現置換で同じ趣旨に沿った変更を機械的にいつでも再生成可能なようにしておくということです。コンフリクトしたらそこを頑張って解消しにいくというよりは、捨ててもう1回作り直すってことを繰り返していましたね。なのでメンテナンスコストはほぼ発生してないです。
実行すればいつでも変更ができるってことですよね。
keik: Gitのコミットメッセージにコマンド書いちゃうというので準備完了ですね。
ymrl: 最初にそういう工夫をしていたからだと思うんですけど、実を言うとfreee人事労務は着手が全プロダクトの中でもかなり遅いほうで、音沙汰が無いなぁと思って連絡したら「あ、来週からやります」と言われて、本当に翌週にはほぼ完成した状態になってて、作業量が減るように準備して後から一気にやるというやり方が本当にうまくいったんだなと思いました。 全体見ている側からすると心配になるやり方なんですけど。
心配だったんですねymrlさんは（笑）
QAと連携することでfreee人事労務ならではの変更点の多さにも対応
freee人事労務は他のプロダクトと違ってロゴがもともと緑色で、色を変えるだけで見栄えが悪くなったり使い勝手が損なわれることもあったのではないかと思いますが、そこはどう工夫していましたか？
keik: Vibesが適用されているところはそこも含めて色設計してくれていたので安心だったんですけど、それ以外の部分に関しては確かに機械的にやると変な感じになるリスクもあるので、QAのチームに依頼するという形をとりました。 今回のようなケースだと仕様がしっかりあるわけではないので、何かおかしいところないか？というあいまいな依頼の仕方だったんですけど、それでも意思疎通できるしやってくれるチームなので助かりました。
リリーススケジュールの整理で障害発生時にも臨機応変に対応
freee会計もfreee人事労務も一気にリリースしたんですか？
ymrl: ブランドチームからするとドンと行きたかったと思うんですけど、プロダクト側に話が来た時点で「一斉には無理なんでその日のうちに出せるぐらいの気持ちでいてください」って言いました。
そうですよね、危ないですよね。
ymrl: 危ないですね、そもそも普段からそんなに同時にデプロイしてないので何が起きるか分からないです、2～3個はあっても14個はないと思うので。
適切なコミュニケーションができていていいですね。リリースの順番もymrlさんが整理したんですか？
ymrl: そうです、気づいたら誰もやってなかったので（笑）リリースの1週間前ぐらいに何時何分にこれをデプロイというスケジュールをまとめたドキュメントを作成しました。インフラについては詳しくなくて「これとこれはインフラを共有しているので同時にやらない方がいい」みたいな指摘をもらったんですけど、そういう会話のためにもタタキを最初に作ったのは良かったなと思います。
実は危ない瞬間もあって、リリース開始のちょっと前に CIがコケたり、オペミス未遂みたいなのが発生して、とっさに順番入れ替えたりしたんですが、そのときもこのドキュメントを見ながら、これを後ろにずらそうみたいな会話ができてよかったです。おかげでなんとかリリース開始時刻までには間に合いました。
keik: いやあ、あれは焦りましたね（笑）デプロイのパイプラインに使っているSaaSに障害が起きてデプロイできなくなったっていうのが真相なんですけど、祈ってましたね。みんなこんな絵文字使って🙏
リブランディングを通してコードの品質やメンテナンス性が向上しUIデザインもしやすくなった
やってみて良かったこと、悪かったことはありますか？
keik: 技術的な観点で言うと、統一したり一貫させて実装することがコードの品質に寄与していて、今回の作業によってハードコードされているところはほぼなくなり、品質やメンテナスの観点でもすごく良くて、式年遷宮みたいな効果があったなと思っています。
これからいつでも色を変えられますね。
keik: 全然すぐいけます、紫色とか。
いや、しばらくはこの色でいきたいです（笑）ymrlさんはどうですか？
ymrl: freeeがブランドとして目指しているものとかビジュアルの方向性が整理されたので、今後UIを作っていくのがやりやすくなったと思います。
全体を俯瞰できる環境を整えること、段取りを整え最適な方法を事前に発見しておくことが大規模変更を成功させるコツ
複数のプロダクトをまたいだ大規模な改善やアップデートに立ち向かう場面での教訓はありますか？
ymrl: 一気に全てを変えるっていう今までやったことがないことをやったので、どう立ち回るとスムーズにいくのか分からないまま飛んできたボールを拾って打ち返すみたいなことをやってて、こういうときには全体を俯瞰して見る人が必要だし、早めにkeikさんみたいに動いてくれる人を巻き込んでいくのが必要だと分かって良い学びでした。
エンジニア向けで言うと、今回最初に自分がある程度エンジニア視点での整理をやったんですけど、自分もエンジニアではない立場になって2～3年経って今の構成とかチームの状態が分からなくなっていると感じました。こういう巨大デプロイをする場合、関係者が多いので特にエンジニア起点でタスクが発生していない場合はエンジニアが早めに拾いに行ける体制があると上手くいくんじゃないかなと思います。
keik: 各プロダクトの事前の仕込みが功を奏した部分もあったので、段取りを整えて適切なやり方を発見しておくということがすごく重要かなと思います。
この二人のおかげもあって今回リブランディングを無事に成功に導くことができました。 リブランディングで生まれ変わったfreeeをこれからもどうぞよろしくお願いいたします。
イベントの本編はここまでです。この後は「アフタートーク」でより深い技術談議が繰り広げられました。
