UIデザインとフロントエンド実装のレビュープラクティス集

Transcript

1. © 2024 Wantedly, Inc. Wantedly Tech Night 24/09 Sep. 18 2024 - Shintaro Kawabe UIデザインとフロントエンド 実装のレビュープラクティス集
2. © 2024 Wantedly, Inc. 自己紹介 shintaro kawabe sh1ntaro_dev s-kawabe 所属 ウォンテッドリー株式会社 ・Visit Growth Squad ・Frontend Chapter ・Design System Guild React / TypeScript / Figma / Design System 好きな 技術 ポーカー / カラオケ / クラフト ビール 趣味 s_kawabe ✨#wantedly_tn 最近ハマっ てること オリーブオイルを使って料理する
3. 今日伝えたい話 © 2024 Wantedly, Inc. レビューのスタンスを改めて、チームの良い関係性を築く方法 素早くかつ成果物の質を高めるUIのフィードバック方法 ウォンテッドリーで実践しているフィードバックプロセスについて グロースチームのフロントエンドエンジニアから見た
4. © 2024 Wantedly, Inc. 1. 基礎編：「批評」に対するスタンス 2. 前提編: Wantedlyのグロース開発プロセス 3. 実践編: デザインレビュー 4. 実践編: コードレビュー 目次
5. 基礎編: 「批評」に対するスタンス © 2024 Wantedly, inc.
6. 1. 基礎編: 「批評」に対するスタンス © 2024 Wantedly, Inc. https://www.componentdriven.org/ レビュー/批評とは？ 単なるリアクションや反応を示し、対応する。というだけのものではなく、 フィードバックループを生み出す行い。 ゴールに基づいていて、なぜそれをやる必要があるのか明確で、やらな かった場合どうなるかがわかることが大事。 批判的思考を使ってその意見や成果物が正しいか間違っているかを判 断する能力が真に求められる。
7. 1. 基礎編: 「批評」に対するスタンス © 2024 Wantedly, Inc. https://www.componentdriven.org/ クリティカルシンキング 同定 調査 バイアス制御 推論 欲求の確認 好奇心 向き合っている問題は 何なのかを しっかり定義する 情報のリソースを きちんと探る 思い込みを減らす 様々なことに好奇心を 持ち幅広い知識を身に つける 手段を目的化しない 立ち止まって本当の 目的を確認する 別の視点や他のアイデ アにも目を向ける
8. 前提編: Wantedlyのグロース開発プロセス © 2024 Wantedly, inc.
9. 2. 前提編: Wantedlyのグロース開発プロセス © 2024 Wantedly, Inc. PRD を作る Kick off 実装 Visit Growth Squadというチームでは、開発ごと（施策と呼んでいます）に以下のプロセスで開発し ています。 デザイン 仕様検討 Prototyping QA リリース 効果検証
10. 2. 前提編: Wantedlyのグロース開発プロセス © 2024 Wantedly, Inc. PRD を作る Kick off 実装 デザイン PRD（要求定義書）をPdMが作成し、要求を満たすプロトタイプを デザイナーが素早く作成、PdMと要求、要件の議論を行います。 仕様検討 Prototyping QA リリース 効果検証
11. 2. 前提編: Wantedlyのグロース開発プロセス © 2024 Wantedly, Inc. PRD を作る Kick off 実装 デザイン プロトタイプのフェーズで要求や要件が整理されたら、メンバーを集めてキックオフを行います。その 後は施策メンバー間で細かい仕様検討とデザイン、実装を行います。 仕様検討 Prototyping QA リリース 効果検証
12. 2. 前提編: Wantedlyのグロース開発プロセス © 2024 Wantedly, Inc. PRD を作る Kick off 実装 実装が終わったらQAを実施します。QAには以下の３種類があります。 デザイン QA: 実装したUIをデザイナーがチェックする工程 通常のQA: テスト項目書を準備し仕様を満たしているかチェックする工程 PdMチェック : PdMによる最終チェック、要求をしっかり満たしているかの確認 デザイン 仕様検討 Prototyping QA リリース 効果検証
13. 2. 前提編: Wantedlyのグロース開発プロセス © 2024 Wantedly, Inc. PRD を作る Kick off 実装 QAが完了したらエンジニアがリリースを行います。 その後は必ず、仮説検証が成功したか失敗したか検証を行っています。 デザイン 仕様検討 Prototyping QA リリース 効果検証
14. 実践編: デザインレビュー © 2024 Wantedly, inc.
15. 2. 実践編: デザインレビュー © 2024 Wantedly, Inc. デザインレビューのWHY • 満たしたい要求を本当に満たせるのか • ユーザー体験を毀損するデザインになっていないか • デザインシステムに則ったデザインか • Wantedlyのブランドから逸脱したものになっていないか • 技術的に難しすぎる表現になっていないか
16. 2. 実践編: デザインレビュー © 2024 Wantedly, Inc. デザインレビューのHOW PRD を作る Kick off 実装 デザイン 仕様検討 Prototyping QA リリース 効果検証 PdMによるレビュー、要求を満たせるかや UX上の問題がないかを見る デザイナーによるレビュー、デザインシステムに則り正しい構造でデザインできているか見る エンジニア（施策メンバー）によるレビュー、技術的な問題がないかや仕様と照らし合わせて 懸念がないか意見を出す、少しでも品質を上げるため細部にもこだわる
17. 2. 実践編: デザインレビュー © 2024 Wantedly, Inc. デザインレビューのHOW PRD を作る Kick off 実装 デザイン 仕様検討 Prototyping QA リリース 効果検証 PdMによるレビュー、要求を満たせるかや UX上の問題がないかを見る デザイナーによるレビュー、デザインシステムに則り正しい構造でデザインできているか見る エンジニア（施策メンバー）によるレビュー、技術的な問題がないかや仕様と照らし合わせて 懸念がないか意見を出す、少しでも品質を上げるため細部にもこだわる
18. 2. 実践編: デザインレビュー © 2024 Wantedly, Inc. デザインレビューのWHAT - 構造を見る Figmaのレイヤーの親子関係だったりグルーピング、余白の取り方、 Auto Layoutなどのプロパティの詳細を細部までチェックする。デザイ ナーの意図を正しく理解しないと、実装におけるコンポーネント設計との 整合があいまいになるため。 e.g. • 「このフォームは、こことここが同じグループという認識ですか？」 • 「なぜここの余白は他と違い8px離れているのですか？」 （弊社も最近FigmaのDev Modeが導入されました 🎉）
19. 2. 実践編: デザインレビュー © 2024 Wantedly, Inc. デザインレビューのWHAT - デザインシステムを共通言 語に デザインシステムを整備してデザイントークンやコンポーネントなどの共 通言語をつくる。その上で共通言語を使って議論する。 e.g. • 「ここの色ってBlackAlpha800を使った方がより認知しやすそうじゃないで すか？」 • 「ここはTooltipよりもCoachMarkを使用するほうが適切だと思います、なぜ なら~~」
20. 2. 実践編: デザインレビュー © 2024 Wantedly, Inc. デザインレビューのWHAT - ユビキタス言語をつくる デザイナーと一緒にデザインを見て、ドメイン知識の入った機能やコン ポーネントにも名前をつける。これも共通言語になり後々のプロジェクト進 行や実装作業におけるミスを減らしてくれる e.g. • 「この機能におけるこのコンポーネントは ScoutMessageTipと呼ぶことにし ましょう」 • 「TopPageBannerが◦◦のときどういう挙動が正しいですか？」
21. 実践編: コードレビュー © 2024 Wantedly, inc.
22. • バグを生む危険性のあるコードになっていないか • 要求と要件をしっかりと捉えた実装になっているか • ユーザー体験を毀損する実装になっていないか • デザインシステムや共通コンポーネントを正しく扱えているか • 一貫性があり、後から見た人がスムーズにキャッチアップできるコードになって いるか • 割れ窓になるコードを放置していないか 3. 実践編: コードレビュー © 2024 Wantedly, Inc. コードレビューのWHY
23. 2. 実践編: コードレビュー © 2024 Wantedly, Inc. コードレビューのHOW PRD を作る Kick off 実装 デザイン 仕様検討 Prototyping QA リリース 効果検証 フロントエンドエンジニアによるレビュー、 UI実装やバックエンドの繋ぎ込み、実現する仕様単位 など小さくレビューの粒度を分けて何回かラリーを行う
24. 3. 実践編: コードレビュー © 2024 Wantedly, Inc. コードレビューのWHAT - Pull Request WhyとWhatを分けて書くことを意識する。 特になぜやることになったのかを厚く書くことで、レビュワーはもちろんgit blameしてたどり着いた将来の誰かが幸せになる。 コンテキストをしっかりと共有することで、レビュワーが実装のズレや間違 い、疑問を見つけられる確率が上がる。
25. 3. 実践編: コードレビュー © 2024 Wantedly, Inc.
26. • 重要度や意図を伝えることを意識する。（MUST, Nice to have, IMO …etc みたいなラベルをつけてコメントする） • どう直すとよいか、具体的なアイデアやコードサンプルを提示すると 認識齟齬も少なく教育的にもよい。「直して欲しい」という意図はわか るがその具体がわからないコメントには注意。 • 積極的に質問を行う。レビューは一方的な確認ではなく対話による 議論でもある。 3. 実践編: コードレビュー © 2024 Wantedly, Inc. コードレビューのWHAT - コメント
27. 3. 実践編: コードレビュー © 2024 Wantedly, Inc.
28. パフォーマンスや可読性に影響を及ぼす、複雑な状態管理や副作用、コ ンポーネント設計と言ったポイントはデザイナーやPdMのチェックでは見 えないのでレビューにおける重要度が高い。 デザイナーやPdMのチェックでも見えるようなデザインの修正よりも重要 視してレビューを行うことが大切。 3. 実践編: コードレビュー © 2024 Wantedly, Inc. コードレビューのWHAT - デザイナーに見えないところを重 視
29. • 状態管理、副作用、設計 ◦ 無駄なuseStateやpropsのバケツリレー ◦ 無駄なuseEffectの濫用 ◦ Reactの作法を守っているか ◦ データの流れがシンプルになっているか • 命名や配置 ◦ 命名が適切かどうか、名前を見てどんなものかイメージがつくか ◦ 機能のグルーピングが適切か、ディレクトリ配置が正しいか • 真に適切な共通化が行われているか 3. 実践編: コードレビュー © 2024 Wantedly, Inc. コードレビューのWHAT - よく見るチェックリスト
30. 3. 実践編: コードレビュー © 2024 Wantedly, Inc.
31. 参考 © 2024 Wantedly, Inc. https://docs.wantedly.dev/fields/app s/collaboration-with-designers
32. Thank you © 2024 Wantedly, Inc. ご清聴ありがとうございました！