エンジニアから考える デザインチーム ビルディング

Transcript

1. エンジニアから考える デザインチーム ビルディング Takanori Oki ( @takanorip ) @デザイナーミーツエンジニア （以下略）
2. 自己紹介 - 大木尊紀（オオキタカノリ）/@takanorip - 株式会社スマートドライブ
 フロントエンドエンジニア - React、Vue、Polymer、Web制作全般 - 「イヌでもわかるWeb Components」
3. 職歴 1. デザイン会社
 ディレクター兼マークアップエンジニア 2. Web制作会社
 フロントエンドエンジニア 3. 自社サービス
 フロントエンドエンジニア
4. 注意 - 今日話すことは、僕が所属している組織の話なので、 全てのパターンに当てはまるわけじゃないです - 正解みたいなものを提示する話ではないので「そういう こともあるのかー」くらいの感じで聞いてください
5. フロントエンドとデザイン デザイン マークアップ JavaScript バックエンド UIデザイン デザイナー エンジニア デザイナー エンジニア
6. フロントエンドが複雑になり、 マークアップをエンジニアが 担当することが増えてきた
7. フロントエンドエンジニアが デザインの一部を担うように 変化してきた （フロントエンドデザイナー、フロントエンドエンジニアみたいな話ありましたよね）
8. フロントエンドとデザイン - フロントエンドとデザインは密に関わり合っている - デザインチームがうまく機能することで、
 フロントエンドエンジニアも気持ちよく仕事できる - エンジニアがデザインチームビルディングに関わることで、 お互いの理解を深めたい
9. 弊社の構成 - デザイナー - CDO - UIデザイナー - エンジニア - フロントエンドエンジニア - サーバーサイドエンジニア
10. 弊社の使用ツール - Figma (デザインツール) - GitHub - JIRA、Confluence - Google Docs
11. 課題 - デザインチームがうまく回ってない感じがあった - エンジニアとうまく連携できるようにしたい - タスクが滞らないようにしたい
12. やったこと① - タスクやドキュメントの管理ツールを整備 - デザイナーにエンジニアのフローに乗ってもらった - PRD(Product Requirements Document)、
 デザインDoc(Why, What, Howを示すもの)などで
 仕様を共有 - JIRAでタスク管理
13. PRD、デザインDoc 実装 レビュー
14. PRD、デザインDoc デザイン レビュー
15. PRDの項目
16. 項目 説明 概要 背景 どんな背景があるから実現する必要性があるのか？ 目的 何を実現するか？ 検討 機能や要件に対して検討した内容を記載する 調査・検証 R&D要素の強い場合のみ記載する 市場調査 機能要求 主な機能的要件や仕様を記載する スコープ やること、やららないことを定義する 主要な結果 製品化の成功をどうやって評価するのか？ 対象ユーザー だれのためにこの問題を解決しようとしているのか？ UX要求 ユースケースやUIモックアップ ユースケース ユーザーの視点でシステムの利用例の全てのパターンを表現する UIモックアップ (Optional) イメージが伝われば、軽めのメモ書き程度のものでもOK
17. やったこと② - デザインフローの整備 - 担当する部分を明確にする - デザイン決定フローも明確にしようとしている - エンジニアがデザインにレビューできる環境をつくる - エンジニアがデザインを理解するため
18. 成果 - デザイナーの進捗が可視化され作業しやすくなった - 仕様をお互いに議論することで、エンジニアとデザイナー の認識の齟齬がなくなってきた - 今のところ、うまくエンジニアのフローにのれている
19. デザイナー、エンジニアそれぞれが やりやすくなる方法を一緒に考える
20. 課題 - デザイナー同士のコミュニケーションが不足している… - 言語の壁が乗り越えられない - デザイナー同士のこだわりがぶつかる - 人が足りない - 足りない中でうまくまわす体制は整ったけど、
 スケールできる体制じゃない…
21. コミュニケーションで 気をつけていること
22. 気をつけていること - 気になることがあったら、すぐに言う - 特に実装に関わる部分 - 細かく議論することが大事 - 早めに確認することが何よりも大事 - デザインに関してきちんと意見する - 「エンジニアだから…」とか遠慮しない - デザイン勉強する
23. おわり！ （フォント：コーポレートロゴ）