Rettyでデザイナーをしています、adattuです。
今年、RettyはAdvent Calenderが2つ存在するのですが、 ここではPart2のAdvent Calenderの1日目として「デザイナー×エンジニアで開発プロセスとUIの改善に取り組んでいるお話」をお届けしたいと思います。
※前提として、この記事の「エンジニア」とは「フロントエンドエンジニア」を指し、対象範囲はWebとなっています。
はじまり
遡ること1年前2020年秋。デザイナーとエンジニアは、それぞれ以下の課題を抱えていました。
デザイナー側
エンジニア側
- アイコンやカラーコードがきちんと管理されておらず、実装時に調整コストがかかる
- デザイナーのブラウザ仕様による制約への理解が浅く、実現しにくいデザインが上がってくる
- デザイン作成ツール（Sketch）から仕様共有ツール（Zeplin）への最新デザイン反映漏れが多い。そもそもZeplinが使いづらい
ご覧の通り、実はデザイナーもエンジニアも同じような悩みを抱えていました。
しかし、当時LeSS体制への移行や、コロナ禍によるフルリモート化で、職種間でのコミュニケーション機会が減っており、お互いの課題共有すら難しい状態でした。
それでも、お互いになんとかしたいという気持ちはあり「コミュニケーション機会が減ったということは、まずは、なにか協業できる機会があればそれぞれ抱えている課題を解消できるのでは？」というところから、デザイナーとエンジニアのタッグによる改善計画がスタートしました。
やったこと
よもやま会の設定
まずは、「デザイナー×フロントよもやま会」を週1で設定しました。元々弊社では「よもやま文化」という、チームや職種の垣根を超えてざっくばらんに話す機会を設ける文化があり、それをデザイナーとエンジニアでもやってみよう、という試みです。
こちらでは
- 開発プロセスの課題
- サービス自体のUIまわりの課題
を中心に、まずはお互い感じていたモヤモヤをざっくばらんに洗い出すことを目的にしました。
そして、開発プロセスの課題についてはよもやまの時間を使って話し合いを続け、 UIまわりの課題については別に時間を設け対応する、という方針で改善を進めていきました。
UI改善MTGの設定
次に、よもやま会で出たUI周りの課題を解決する会議体を設定しました。
こちらでは「何をやるか決める回(30分)」と「実際に手を動かす回（1時間）」を隔週で設け、実際に手を動かす日は、エンジニアが画面共有して実装する様子をデザイナーも見ながら修正をすすめました。
こうすることで、
- エンジニアが実装時に必要なデータをすぐにデザイナーにお願いできる
- デザイナーもUIの細かい調整を画面をみながらお願いできる
というメリットがありました。
こうして、開発プロセスの課題についてはよもやま会、UI改善についてはUI改善MTG、という形で現在まで取り組みを続けてきました。
取り組みによる成果
上記の取り組みを1年以上続け、徐々に成果が出てきました。
主要デザインツールの移行
エンジニアとデザイナーが当時抱えていた大きな課題に「実装用データへの最新デザイン反映漏れや、デザインデータのメンテナンスコストがかかる」がありました。
これは、デザイナーがデザイン作成にSketch、他職種への仕様共有にPrott、Zeplin、Invisionと、用途に応じて複数のサービスを使っていたことが原因でした。
それを今回、figmaに全ての役割を集約させたことで、デザイナーのデータ管理と他職種への共有コストが大幅に軽減。上記の課題も解決し、結果開発効率のアップにつながりました。
使用ツールの移行は、移行先が最適かどうかの調査や他部門との調整が必要で、デザイナーの一存だけで進めるには難しく、後回しになっていました。
しかし、エンジニアと課題感が同じだったことや、よもやま会で一緒に合意を取りながら進められたことで、ようやく移行の実現にこぎつけました。
主要アイコンとカラーコードの整理
こちらも、アイコンデータの読み込み元やカラーコードが整理されていないことで、コードの見通しが悪くなったり、エンジニアとデザイナーの調整コストが発生したりと、地味に開発のボトルネックになっていました。
今回、使用しているアイコンの元データを統一し、似たようなカラーコードを排除できたことでかなり裏側がスッキリできました。カラーコードはスマホとPCの使用色を統一し、figmaのカラーパレットに登録して、今後似たような色が発生しないような仕組みも作れました。
その他
その他、リファイメントの運用や画像圧縮プロセスの見直しをしたり、細かいUI改善も随時行っていました。 また、画像のアイコンフォント化や、デザイナーもターミナルを使いstorybookを学んでみるなど、実験的な試みにもチャレンジしていました。
また、目に見える成果以外にも
- 画面共有しながらの作業や会話で、職種間のナレッジや考え方を共有し、それによって普段の業務コミュニケーションも円滑になった
- エンジニアとデザイナーがお互いの考え方を共有・理解したことで、自分自身の職責に対しての理解も深めることができた
- 単純に接触機会が増えたことで、デザイナーとフロントの心理的な距離も縮まった
などさまざまな副次的効果もありました。
継続と成果のコツ
ここまでやったこととその成果について書いてきましたが、 そもそも、なぜこの取り組みが1年間続き、成果にも繋がったのか？というのを自分なりに振り返ってみました。
がんばりすぎない
まず、参加メンバーが完璧にやろうという意識を持たずに進んでいたことが大きかったと思います。1個1個の課題を完璧に潰してから次にいくのではなく、分解してMTGの時間内で進められるところからやってみたということ。
あとは心構えとして、あくまで本来のミッションに支障をきたさない範囲でやったこと。よもやまとUI改善MTGは、どちらも出席強制ではなくその週に時間が取れる人たちが出席していました。議事録も作り込むわけではなく、ファシリテートも誰か同じ人が毎週やるというよりは、その時出席してる人の中でできそうな人がなんとなくやる、くらいのゆるさでやっていました。
途切れさせない
よもやまMTGで議題がないときは、スキップせず雑談タイムにしていました。 自然消滅を防ぐ目的もあるんですが、業務以外の人となりを知ることで心理的距離も縮まったり、MTGがはじまったときに議題がなかったとしても、話してるうちに議題が生まれることもあったりしたためです。
まとめると、無理のない範囲で、コツコツと続けたことが継続と成果に繋がったのかなと思います。
こうやって書くとめちゃくちゃ当たり前のことですが、やっぱり当たり前のことって大事なんだなと改めて再確認しました笑
ここで挙げた他にも、メンバーの課題感が一致していたことで主体的に動こうというマインドが働いたことや、人数の規模感がちょうどよかった（最大エンジニア5人・デザイナー3人）のもあるのかなと個人的には思ってます。
さいごに
今後は、プロダクト側だけでなくお店管理画面の開発プロセス改善や、デザインルールの整備を行いながらUI改善リストの消化を行っていく予定です。 デザインデータのFigma移行も完全に終わっておらず、一部のデザインはまだSketchで作成している状態なので、こちらも随時デザイナーの方で対応していきます。
デザイナーとフロントエンドエンジニアで連携しながら進めている改善プロジェクトですが、課題ややりたいことの内容に応じて、他職種の方々もどんどん巻き込んでいき、裏側からもUser Happyを実現していきたいと思います。
これを読んだみなさまにも何かの参考になれば幸いです:)
ありがとうございました!
