デザイナーの困りごとを解いたら、自分にも見えるものが増えた

こんにちは、Gaji-Labo の谷本です。

Figma のコメントを毎日集め、前日からの差分だけを Slack に流す仕組みを作りました。きっかけは、デザイナーから共有された「コメントの影響範囲や、全体の状況を把握しづらい」という困りごとです。

デザイナーとフロントエンドの2職種で解決方法を考えた結果、コメントを書く側の運用を変えず、受け取る側の環境だけを変える方法にたどり着きました。すると、デザイナーのために作った仕組みが、フロントエンドである私にとっても、デザイン作業の状況を知る手がかりになりました。

この記事では、困りごとの原因をどう整理したか、なぜ運用ルールを増やさなかったのか、そして他職種の課題に取り組んだことでチームに何が見えるようになったのかを紹介します。

デザイナーから共有された困りごと

Gaji-Labo では、参画しているプロジェクトによりよい価値を提供するため、社内でデザイナーと状況を共有する場を持っています。私が関わっているプロジェクトでは、週に一度その場を設けています。

そこで、デザイナーから次の困りごとが共有されました。

• コメントが他のデザインデータにどう影響するのか把握しづらい
• コメント全体の状況を把握しづらい

原因を整理すると、コメントが付く場所と、指摘が影響する範囲のずれに行き着きました。

Figma のコメントは「この画面のこのボタン」というように、デザインファイル上の決まった場所に付きます。一方で、その内容がコメントの付いた場所だけに関係するとは限りません。

たとえば、「このボタンのラベル」という指摘は、同じボタンを使っている別の画面にも関係します。「この余白の取り方」という指摘なら、共通の部品を使っているすべての箇所に影響する可能性があります。

コメントが付いている場所を見ても、影響がどこまで及ぶのかは分かりません。また、コメントがそれぞれの場所に紐づいているため、すべてをまとめて確認することも困難です。

別々に見えた二つの困りごとは、同じ原因から生まれていました。

運用を増やさず、受け取り方を変える

最初に考えられるのは、コメントの書き方や運用ルールを整える方法です。

• コメントに影響範囲を書いてもらう
• 分類用のタグを付けてもらう
• コメントを共有する頻度を上げる

今回は、どれも採用しませんでした。

ひとつ目の理由は、書く人の負担が増えるからです。把握しづらいという問題を解決するために、コメントを書く手間を増やしてしまうと、困りごとの形が変わるだけです。新しい運用を定着させるための労力も必要になります。

もうひとつの理由は、コメントを書く時点では影響範囲が分からない場合もあるからです。書き手に影響範囲の記載を求めても、その時点では答えを持っていない可能性があります。

必要なのは、コメントの書き方を変えることではなく、書かれたコメントを把握しやすい形に並べ直すことだと考えました。

この判断は、今回の取り組みで重要だった点のひとつです。困りごとの解決に必要な負担を、困っている人へそのまま返さない方法を選びました。

Figma のコメントを一覧にして、差分だけを Slack に流す

そこで、Figma の外にコメントの一覧を作りました。仕組みが行っているのは、次の三つです。

• Figma からコメントを毎日取得する
• デザインファイル上の位置から切り離し、1件ずつ並べ直す
• 各コメントの対応状況を持たせ、前日からの差分だけを Slack に流す

デザインファイルの中に散らばっていたコメントを、外部でひとつのリストにまとめた形です。コメントを並べ替えられるようになると、どこに指摘が集まっているのかを確認しやすくなります。

ただし、全件を毎日 Slack に送っても読まれません。そこで、新しく追加されたコメントや、対応状況が変わったコメントだけを通知し、数十秒で目を通せる量に収めました。

コメントを書く側の運用は変えていません。これまでどおり Figma にコメントを書くだけで、新しいツールやルールを覚える必要もありません。変えたのは、コメントを受け取る側の環境だけです。

何をどのような形で見たいのかは、デザイナーと一緒に整理しました。デザイナーが困りごとと必要な情報を伝え、フロントエンドがそれを仕組みにする。どちらか片方だけでは作れないものでした。

この仕組みによって、コメント全体の状況は把握しやすくなりました。同じ箇所への指摘をまとめて見られるため、影響範囲も以前より追いやすくなっています。

一方で、影響範囲を完全に把握できるようになったわけではありません。コメントを書く時点で、どこまで波及するか分からない問題については、別の方法を検討しています。

デザイナーのための仕組みが、自分の状況把握にも役立った

この仕組みは、デザイナーの困りごとを解決するために作りました。しかし、作った私自身も Slack に届く通知を毎日見るようになりました。

通知を見続けていると、どこに指摘が集まっているのか、クライアントからの返答を待っているのかといった、デザイン作業の輪郭が見えてきます。

もちろん、デザインの内容や、指摘に至った検討の過程まで分かるわけではありません。見えるのは、どこが動いていて、どこで止まっているのかという外形だけです。それでも、何も見えていなかった状態とは違います。

デザイナーのために作った一覧が、フロントエンドである私の状況把握にも役立つようになっていました。
今回の取り組みで得た、想定していなかった変化でした。

話し合いを増やさず、同じものが見える状態を作る

チーム内のコミュニケーションを改善しようとすると、話し合う場を増やす方法を考えがちです。しかし、話し合いには参加者全員の時間を同時に確保する必要があります。

今回作ったのは、話し合いの場ではなく、同じ情報をそれぞれのタイミングで見られる環境です。Slack に届く差分へ毎日目を通すだけなら、互いの作業を止める必要がありません。

現時点では、この仕組みによってチームのコミュニケーションが大きく変わったとまでは言えません。それでも、相手がどこに手をかけているのかを知る機会が増えれば、認識のずれに早く気づける可能性があります。

今回の方法を別の場面で試すなら、押さえる点は二つです。

書く側の運用を変えないところから始める

相手に新しい作業を依頼すると、合意形成と定着のコストが発生します。受け取り方だけを変える方法なら、小さく始められます。合わなければ元に戻すことも容易です。

全体ではなく差分を見る

全体の状況を毎日確認しようとすると、情報量が多くなり、次第に見なくなります。変わった部分だけに絞ることで、短時間でも継続して確認できます。

個人の困りごとを、チームで引き取る

この取り組みは、デザイナーが困りごとを共有できる場があったことから始まりました。

担当範囲だけで線を引けば、Figma ファイルのコメント管理はフロントエンドの仕事ではありません。それでも二つの職種で取り組んだのは、個人が抱えている困りごとを、個人だけの問題として残さなかったからです。

困っている人が、自分では解決方法まで分からないことがあります。一方で、別の職種が持つ技術を使えば、その困りごとを解決できる場合があります。そのためには、困りごとを持つ側と、それを形にできる側が一緒に状況を整理する必要があります。

今回は、デザイナーの困りごとを解決するために、コメントの受け取り方を変えました。その結果、フロントエンドである私にも、これまで見えていなかったデザイン作業の状況が見えるようになりました。

個人の困りごとをチームで引き取り、元の状態よりも高い成果を目指す。今回の仕組みは、Gaji-Labo が大切にしている仕事の進め方から生まれたものです。

Gaji-Labo フロントエンドエンジニア向けご案内資料