デザインレビュー
はじめに
- この手引きはレビュー依頼時の必要事項を網羅的にまとめ、指針として共有するものです。
- レビュー時の迷いを減らし、レビュー相手への負荷の軽減する目的で定義しています。
- この手引きはレビューの手段を強制するものではありません。迷ったらお手本とし、必要があればカスタムしてください。
- 項目に更新・改修・削除が必要な場合、どんどん編集していきましょう。
本手引きの使い方
- 「推奨事項」として書かれていることは、できるだけその方法に沿ってレビュー依頼をすると望ましい事項です。
- 「任意事項」は、状況に応じて対応する、または不要な事項です。
- レビュー時は、レビューテンプレートをコピーして文書を作成して使ってください。
- その後のやり取り方法は各ツールに準拠します。
レビューとは
- レビューはクオリティを高め、レビュー依頼者が気づかないことへの気づきを与えるものです。
- レビューは意見の押し付けではなく、ディスカッションです。
- レビューはあなたの考えを否定するものではありません。
心得
- 相手の時間を使うことを意識して依頼する。
- レビューの完了はレビューを出した人が判断する。
- レビュー中に合意形成ができない場合、第三者に意見を求める。
- レビュー後の積み上げは基本OK
- 優先タスクがあればそちらを優先する。
- 重大な問題がある場合は例外とする。
- レビューを安易に進めては行けない、議論して揉んでから進む。
- 互いに納得してから先に進む。
- 後出しで負荷がかかる可能性が高い。
- 休暇取得中の人へのレビュー依頼は原則しない。
- 依頼されても別に返事はしなくてよい。
レビューの目的・目標
- レビューは、レビュー依頼側がレビューで達成したい目的・目標を設定し、レビュアーに明示する。
- レビュアーはその目的・目標に沿った成果物・コードを軸に判断し、コメント、アドバイス・助言する。
- チームの知見や気づきを糧に品質を向上し、深遠なるインターフェースの極地にたどり着くための儀式である。
レビューの種類
| 種類 | 目的 | 強制力 ※1 | 対象 | 対象チャンネル |
|---|---|---|---|---|
| 開発プロジェクトレビュー | 開発プロジェクト内のレビュー | 強強 | PdM, エンジニア, ドメインマスター等 | 各プロジェクトのチャンネル |
| プロダクトデザイングループレビュー | プロダクトデザイナー観点で品質を上げるためのレビュー | 柔 | プロダクトデザイナー | #design_products |
| コンポーネントレビュー ※2 | Figmaライブラリとしての利便性・再利用性、実装のことを考えたレビュー | 剛 | プロダクトデザイナー, エンジニア | #pj_smarthr_ui |
- ※1 フィードバックに対しての対応がどの程度求められるか。
- ※2 現状はSmartHR UIを指す。いずれデザインシステムレビューになる想定
レビュールール
プロジェクト後に性質が違うため、それぞれ定義します。
- 開発プロジェクトレビュー
- プロダクトデザイングループレビュー
- コンポーネント（SmartHR UI）デザインレビュー
1. 開発プロジェクトレビュー
関わる人数が多く、職種も多様なので、目的・背景・概要・レビューして欲しい点を明確にして行なうことが求められる。ただし、人数が少ない場合などはこの限りではない。
推奨事項
- 前提としてデザイナー以外のメンバーが見ることを想定する。
- 仕様やどういったレビューをするか、事前に明示しておくことが望ましい。
- レビューテンプレートを元に先行して送っておく。
- レビューの数日前に送り、前日に再度確認のプッシュをしておく。
レビュー手段
- ツールは限定しない。
- レビューを依頼したいユーザーの環境次第とする。
- Slackスレッド、Jiraのチケット詳細に記述されることが多いことを前提とする。
2. プロダクトデザイングループレビュー
相談しやすいよう、雑談ベースのふんわりなレビューでも可。具体的にレビューをしてもらうことを前提とした場合としてのガイドを紹介する。
推奨事項
- 基本的に、デザイナーの文脈でレビューをしてもらう。
- 関わっていないプロジェクトへのレビューを求められることが多い。
- 背景とどういうものかの説明を用意したうえでレビュー依頼する。
- レビューポイントを絞り、要点を噛み砕いて説明する。
依頼方法
- プロデザレビュー会に持ち寄る。
- CodiMDに相談事項を書き、その場でレビューしてもらう。
- 内容が詳細にわかっている場合、テンプレートを元に書き、事前に共有しておく。
- Slackのスレッド上でレビューしてもらう。
3. コンポーネント（SmartHR UI）デザインレビュー
レビュー対象が小さく具体的なレビューとなるので、仕様やレイヤー構造まで書き、レビューを依頼する。
推奨事項
- テンプレートに従い、具体的な情報を書いて、レビューを依頼する。
依頼方法
- レビュアーは最低2人を指定し、レビュー依頼する。
- レビュアー2人からLGTMを貰えれば完了とし、masterにマージする。
レビュー手段
- Figma上でのレビューを軸とする。
- 即応性が欲しい場合等は、Slack等でも可能
- 画像が添付できないなどの制約があるので、不便と感じた場合はSlackを使う。
レビュー中のポイント
- レビュー観点から逸れそうな意見も拾うために、例えばSlackのスレッドやMiroの付箋置き場など、書き留める場所を用意しておく
- 確認を求めたい点、不安な点を明確にする。
- 完了後のアクションを明確にする。
- 意見をもらい、答えは求め過ぎない。
- 受け身でなく、能動的にレビューをもらうようにする。