エンジニアから考える デザインチーム ビルディング Takanori Oki ( @takanorip ) @デザイナーミーツエンジニア （以下略）

自己紹介 - 大木尊紀（オオキタカノリ）/@takanorip - 株式会社スマートドライブ
 フロントエンドエンジニア - React、Vue、Polymer、Web制作全般 - 「イヌでもわかるWeb Components」

職歴 1. デザイン会社
 ディレクター兼マークアップエンジニア 2. Web制作会社
 フロントエンドエンジニア 3. 自社サービス
 フロントエンドエンジニア

注意 - 今日話すことは、僕が所属している組織の話なので、 全てのパターンに当てはまるわけじゃないです - 正解みたいなものを提示する話ではないので「そういう こともあるのかー」くらいの感じで聞いてください

フロントエンドとデザイン デザイン マークアップ JavaScript バックエンド UIデザイン デザイナー エンジニア デザイナー エンジニア

フロントエンドが複雑になり、 マークアップをエンジニアが 担当することが増えてきた

フロントエンドエンジニアが デザインの一部を担うように 変化してきた （フロントエンドデザイナー、フロントエンドエンジニアみたいな話ありましたよね）

フロントエンドとデザイン - フロントエンドとデザインは密に関わり合っている - デザインチームがうまく機能することで、
 フロントエンドエンジニアも気持ちよく仕事できる - エンジニアがデザインチームビルディングに関わることで、 お互いの理解を深めたい

弊社の構成 - デザイナー - CDO - UIデザイナー - エンジニア - フロントエンドエンジニア - サーバーサイドエンジニア

弊社の使用ツール - Figma (デザインツール) - GitHub - JIRA、Confluence - Google Docs

課題 - デザインチームがうまく回ってない感じがあった - エンジニアとうまく連携できるようにしたい - タスクが滞らないようにしたい

やったこと① - タスクやドキュメントの管理ツールを整備 - デザイナーにエンジニアのフローに乗ってもらった - PRD(Product Requirements Document)、
 デザインDoc(Why, What, Howを示すもの)などで
 仕様を共有 - JIRAでタスク管理

PRD、デザインDoc 実装 レビュー

PRD、デザインDoc デザイン レビュー

PRDの項目

項目 説明 概要 背景 どんな背景があるから実現する必要性があるのか？ 目的 何を実現するか？ 検討 機能や要件に対して検討した内容を記載する 調査・検証 R&D要素の強い場合のみ記載する 市場調査 機能要求 主な機能的要件や仕様を記載する スコープ やること、やららないことを定義する 主要な結果 製品化の成功をどうやって評価するのか？ 対象ユーザー だれのためにこの問題を解決しようとしているのか？ UX要求 ユースケースやUIモックアップ ユースケース ユーザーの視点でシステムの利用例の全てのパターンを表現する UIモックアップ (Optional) イメージが伝われば、軽めのメモ書き程度のものでもOK

やったこと② - デザインフローの整備 - 担当する部分を明確にする - デザイン決定フローも明確にしようとしている - エンジニアがデザインにレビューできる環境をつくる - エンジニアがデザインを理解するため

成果 - デザイナーの進捗が可視化され作業しやすくなった - 仕様をお互いに議論することで、エンジニアとデザイナー の認識の齟齬がなくなってきた - 今のところ、うまくエンジニアのフローにのれている

デザイナー、エンジニアそれぞれが やりやすくなる方法を一緒に考える

課題 - デザイナー同士のコミュニケーションが不足している… - 言語の壁が乗り越えられない - デザイナー同士のこだわりがぶつかる - 人が足りない - 足りない中でうまくまわす体制は整ったけど、
 スケールできる体制じゃない…

コミュニケーションで 気をつけていること

気をつけていること - 気になることがあったら、すぐに言う - 特に実装に関わる部分 - 細かく議論することが大事 - 早めに確認することが何よりも大事 - デザインに関してきちんと意見する - 「エンジニアだから…」とか遠慮しない - デザイン勉強する

おわり！ （フォント：コーポレートロゴ）