デザイン組織が社内下請けから脱却するためにやったこと/20230208_kobayashi

by Rakus_Dev

Slide 1

Slide 1 text

デザイン組織が社内下請けから  脱却するためにやったこと  第一開発部プロダクトデザイン課マネージャー小林肇

Slide 2

Slide 2 text

#RAKUSTechCon 自己紹介  小林肇 2003年エンジニアとして入社。配配メールの開発を担当。 2012年よりデザインチームの立ち上げ。現在はプロダクトデザインチームのマネージャー。趣味は音楽と相撲観戦。

Slide 3

Slide 3 text

#RAKUSTechCon ラクスのプロダクト ● BtoB SaaS ● Best Of Breed戦略で仕様もUIも個別に最適化 ● 難解なドメイン知識が必要 ○ 経理業務、帳票発行、勤怠管理、メールサポート、販売管理、メール配信、チャットボット ● リリースからの経過年数はさまざま ● UIはモダンなものからレガシーなものまでさまざま

Slide 4

Slide 4 text

#RAKUSTechCon 2000 2005 2010 2015 2020 2025

Slide 5

Slide 5 text

#RAKUSTechCon

Slide 6

Slide 6 text

#RAKUSTechCon 現在のプロダクトデザインチーム ● デザイナー 9名 + マネージャー1名 ● 20代～40代 ● それぞれ1～2のプロダクトを担当 ● 横断組織

Slide 7

Slide 7 text

#RAKUSTechCon デザイナーのおもな業務 ● UI/UXの設計 ● UIライブラリの整備 ● 文言作成 ● ユーザーヒアリング

Slide 8

Slide 8 text

#RAKUSTechCon Mission プロダクト開発の中心となり、顧客課題を解決する優れたUXを生み出す Vision 日本を代表するBtoB SaaSの優れたUXを生み出すプロフェッショナルチーム

Slide 9

Slide 9 text

#RAKUSTechCon 発足当初から現在に至るまで、チームの成長とともに課題はいろいろ変わりました。

Slide 10

Slide 10 text

#RAKUSTechCon 発足当初（デザイナー 0 → 1名） ● UIルールは無いに等しい ● UIデザイナーをどうやって育成すべきかわからない ● 開発プロセスにどのように関与すればいいか試行錯誤

Slide 11

Slide 11 text

#RAKUSTechCon 手探り期（デザイナー 1 → 3名） ● UIのルールを少しずつ整備 ● プロダクトの数に対してデザイナーはまだまだ不足 ● 細々としたUIの依頼の対応に追われる ● 依頼されるUI設計の規模も少しずつ大きくなる

Slide 12

Slide 12 text

#RAKUSTechCon 拡大期（デザイナー 3 → 7名） ● デザイナーの数は充足 ● 表面的な依頼にとどまり手が余る戦略要件構造骨格表層 ← 表層の依頼が増える  ← 本来やりたいのはココ  

Slide 13

Slide 13 text

#RAKUSTechCon デザイナーの困りごと ● Excelに書かれたUIをキレイにする依頼 ● 機能開発のミーティングに呼ばれない ● UIの作成依頼をただ待つ状態 ● 部分最適のUI設計で全体的な統一感がでない ● 工数がないのであきらめざるをえないUI ● 自分たちでは実装できない ● メンバーのモチベーションが下がる

Slide 14

Slide 14 text

#RAKUSTechCon 特に困ったこと  ● Excelに書かれたUIをキレイにする依頼 ● 機能開発のミーティングに呼ばれない → 依頼された段階では画面遷移や配置はほぼ決まっている → スケジュールは迫っており、あるべき論の改善案は求められていない

Slide 15

Slide 15 text

#RAKUSTechCon 特に困ったこと  ● 自分たちだけでは何もできない ● UIの作成依頼をただ待つ状態 → 社内下請けの状態になっている

Slide 16

Slide 16 text

#RAKUSTechCon 開発チームの中に入れていない

Slide 17

Slide 17 text

#RAKUSTechCon 5. 課題  社内下請けの状態から脱却したい   

Slide 18

Slide 18 text

#RAKUSTechCon 5. 課題  社内下請けの状態から脱却したい  デザイナー主体でUIを設計したい 

Slide 19

Slide 19 text

#RAKUSTechCon できないことには理由がいろいろある

Slide 20

Slide 20 text

#RAKUSTechCon 要因  ①開発プロセス ②スキル不足

Slide 21

Slide 21 text

#RAKUSTechCon 要因①開発プロセス 2000 2005 2010 2015 2020 比較的新しい歴史が長い

Slide 22

Slide 22 text

#RAKUSTechCon 要因①開発プロセス・歴史の長いプロダクトほど、デザイナーが上流工程に参加するタイミングがなかった・急に入ろうとしもハレーションが起きる・デザイナーの役割について説明不足プロセスの変更は、関係者に大きな負担を強いる

Slide 23

Slide 23 text

#RAKUSTechCon 要因②スキル不足・ビジネスサイドの方針の理解不足・顧客の業務の理解不足・顧客の課題の理解不足・仕様の理解不足

Slide 24

Slide 24 text

#RAKUSTechCon 自分たちの実力をつけて、やるべきことを着実に進めていこう

Slide 25

Slide 25 text

#RAKUSTechCon アクション・デザイナーの役割を定義する・機会をみつけて全力でエンジニアに協力・デザイナーがいたほうが楽だと実感してもらう要因①開発プロセス

Slide 26

Slide 26 text

#RAKUSTechCon 要件定義におけるデザイナーとエンジニアの役割を定義 ● 要求仕様を元に、アプリケーションで実現すべき要件を洗い出す人 ● 要件を実現するために必要な内部ロジック、周辺機能との整合性などを設計する人 ● 開発エンジニアとデザイナ双方が設計した成果物を、「要件定義書」としてまとめる人 ● 要件を実現するために必要な項目・ UI（画面遷移など）を設計する人 ● PdMが機能を考えるうえでUI・画面遷移のプロトタイプを作ってサポートエンジニア  デザイナー 

Slide 27

Slide 27 text

#RAKUSTechCon アクション・事業部方針を理解する・顧客の抱える課題を知る（要望一覧、インタビュー）・複雑なプロダクトの仕様を理解する・関連する法律を学習する（電子帳簿保存法、インボイス）・デザイナーのスキルアップ要因②スキル不足

Slide 28

Slide 28 text

#RAKUSTechCon ● チームのスキルアップ勉強会輪読会

Slide 29

Slide 29 text

#RAKUSTechCon UIライブラリの策定

Slide 30

Slide 30 text

#RAKUSTechCon 徐々に出てきた効果・ミーティングにも呼ばれるようになってきた・デザイナー主体でUI/UXをまかされるようになってきた・ユーザーインタビューを依頼されるようになった・エンジニアと定期的な振り返りの実施 → 開発チームの一員になれてきている実感

Slide 31

Slide 31 text

#RAKUSTechCon デザインチームの拡大を振り返ってはじめのころは、デザイナーの役割がどうあるべきか、私自身も手探り。 UIだけの話をしたり、生産性のわるい仕事もしていた。顧客のことも徐々に理解できてきた（まだわかってない）。エンジニアとのコミュニケーションは大きく増えており、社内下請けの状態から徐々に脱却し、デザイナーも上流工程に関われるようになってきた。

Slide 32

Slide 32 text

#RAKUSTechCon 今後のビジョンデザイナーが顧客の課題を本質的に理解し、解決するUI/UXを設計できるようになりたい。そのためには、以下を進めていきたい。・顧客の業務や課題の深い理解・エンジニアやPdMとの連携強化・デザイナーの設計スキルの向上

Slide 33

Slide 33 text

#RAKUSTechCon 5. 課題  デザイナーが中心となってUI/UXを設計し、  顧客課題を解決するチームを目指します 