エンジニアと一緒に進めるデザインレビューにおすすめの「GitHub Issues」

この記事は、2019年9月17日にクラウドワークスデザイナーブログに投稿した記事です。

こんにちは。デザイナーの小林です。

先日、DXELという勉強会のLT、パネルディスカッションに登壇させていただきました。そのLTでは、エンジニアとデザイナーが協業するために行っているチーム運営や開発プロセスの工夫を紹介してきました。

【増枠】DXEL.4 エンジニアとデザイナーの「協働力」を最大化するには (2019/08/23 19:30〜)

今回はLT・パネルディスカッションで詳しくお話していない「デザインレビュー」に焦点を当てて、ブログで紹介していきます！

デザインレビューは何のために行うのか？

私が所属するフロントエンドチームのデザインレビューは、デザイナーが制作したデザインやプロトタイプを、エンジニアやデザイナー、プロダクトオーナーなどチーム全員でレビューしています。デザインレビューをチーム全員で行う目的は、主に以下の2つです。

・デザイナーの持つ観点以外からのフィードバックでプロダクトを多面的に評価できること。
・エンジニア・デザイナーで、自分たちが作っているものへの共通理解を持つこと。

私たちのチームでは、いろんなレビュー方法を試しましたが、最終的にGitHub Issues + zeplinという組み合わせに落ち着きました。GitHub Issues と Zeplin は、以下のように役割を明確にわけてレビューに使用しています。

Zeplin は、デザインやスタイルの指示書

Zeplinは、デザインデータをアップロードすることで詳細なスタイルを共有しやすくすることができるツールです。コメント機能やスタイルガイド、Slack連携など、デザインレビューに便利な機能もあります。

私たちのチームでは、詳細なスタイルの確認で使用しており、エンジニアは実装に入るタイミングでZeplinのデータを確認しながら実装していきます。デザインレビューや実装のタイミングでZeplinの内容に不明点などがあったときには、後述のGitHub Issuesで相談してもらうようにしています。

GitHub Issues は、レビューコメント・コミュニケーション専用

GitHub Issuesに書く内容は統一していませんが、個人的には以下の内容を書くように心がけています。

・このIssues（レビュー）は何のために書いているのか？
・デザイン（Zeplinのリンク + キャプチャ）
・デザインの意図の説明
・デザインしているときに悩んだこと・相談したいこと

デザインをチェックしてもらうというよりは、このデザインをベースにチームでコミュニケーションしてよりよいものにしていくのが目的なので、意図や相談したいことも積極的に書くようにしています。

ZeplinだけじゃなくGitHub Issuesを導入した理由

Zeplinにはない画像添付で、よりお互いの意図を伝えやすくなる
百聞は一見にしかず。言葉で説明されるよりも、見たほうが早く理解できることってたくさんあります。エンジニアとデザイナーで必ずしも共通言語で話せるとは限らない環境であったり、ざっくりとしたイメージのすり合わせや実装可能か検討する段階では、無理に言葉にするより画像や事例のデモを添付できるほうが、お互いの共通認識をもちやすくなります。

チームのデザイン・実装に関する相談をGitHubに集約できる
チームで相談した内容が、GitHubやSlack、Zeplin、各種ドキュメントツールなどに散乱してしまうことがよくあります。しかし、散乱してしまうと、後からどうしてこのデザインになったのかドキュメントを発掘できないということがありました。

成果物に対する相談をGitHubに集約することで、なぜこのデザインに決まったのかGitHubに相談履歴を残すことができます。実装レビューや相談もGitHubを使うことが多いので、エンジニア・デザイナーの職種に関わらず、同じツール内で履歴がいつでも確認できる状況であることは大切にしているポイントです。（※ 時折、Slackで相談してしまうこともありますが、そういう時はslackのリンクを貼ったりしています。）

ステータス変更やメンバーのアサインができてレビューが管理がしやすい
MTGだけではなくドキュメントベースでレビューするとき、複数のレビューが同時並行で進むとレビューの管理が難しくなります。また、チーム全員が見るべき時と、各職種から最低1名ずつ見ればよい時、特定の誰かに必ずみてほしい時など、誰がレビュアーになっているかもレビューする時の大事なポイントです。

GitHub Issuesでは、解決していないIssues（レビュー）は「OPEN」、すでに解決したIssues（レビュー）は「CLOSED」などステータスを管理できるため、完了しているレビューとそうでないものの管理が簡単にできます。

また、人のアサインやレビューの種類のタグ付けなども行うことができるため、チームの状況にあわせてカスタマイズしながらレビューを管理できるところも魅力的だと思います。

さいごに 

GitHub Issuesを使ったデザインレビュー、いかがでしたでしょうか？

エンジニアとデザイナーがよりよく協働するための1つの工夫として参考にしていただけると嬉しいです。その他にもチーム運営の工夫などもLTでお話していましたので、もし興味があれば以下の資料も見てみてください。