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

デザイナーが少なく、開発プロセスの中でデザイナーの役割の定義が曖昧で、デザイナーって何をしてくれる人なのか、プロダクト開発においてデザイナーがいるとどんなメリットがあるのかがちゃんと認識されていませんでした。キレイなUIを作ってくれるということは認知されていても、そのためにはどのようにデザイナーがプロダクト開発に関わるべきか不明瞭なために、下請け的な仕事になっていました。
課題解決をミッションとするデザイナーが、プロダクト開発チームの一員になるために、どのようにして役割を認識してもらい、役割を広げていっているのかを説明します。

Transcript

1. デザイン組織が社内下請けから
 脱却するためにやったこと
 第一開発部 プロダクトデザイン課 マネージャー 小林肇
2. #RAKUSTechCon 自己紹介
 小林肇 2003年 エンジニアとして入社。配配メールの開発を担当。 2012年よりデザインチームの立ち上げ。 現在はプロダクトデザインチームのマネージャー。 趣味は音楽と相撲観戦。
3. #RAKUSTechCon ラクスのプロダクト • BtoB SaaS • Best Of Breed戦略で仕様もUIも個別に最適化 • 難解なドメイン知識が必要 ◦ 経理業務、帳票発行、勤怠管理、メールサポート、販売管理、メール配信、チャットボット • リリースからの経過年数はさまざま • UIはモダンなものからレガシーなものまでさまざま
4. #RAKUSTechCon 2000 2005 2010 2015 2020 2025
5. #RAKUSTechCon
6. #RAKUSTechCon 現在のプロダクトデザインチーム • デザイナー 9名 + マネージャー1名 • 20代～40代 • それぞれ1～2のプロダクトを担当 • 横断組織
7. #RAKUSTechCon デザイナーのおもな業務 • UI/UXの設計 • UIライブラリの整備 • 文言作成 • ユーザーヒアリング
8. #RAKUSTechCon Mission プロダクト開発の中心となり、 顧客課題を解決する優れたUXを生み出す Vision 日本を代表するBtoB SaaSの 優れたUXを生み出すプロフェッショナルチーム
9. #RAKUSTechCon 発足当初から現在に至るまで、 チームの成長とともに課題はいろいろ変わりました。
10. #RAKUSTechCon 発足当初 （デザイナー 0 → 1名） • UIルールは無いに等しい • UIデザイナーをどうやって育成すべきかわからない • 開発プロセスにどのように関与すればいいか試行錯誤
11. #RAKUSTechCon 手探り期 （デザイナー 1 → 3名） • UIのルールを少しずつ整備 • プロダクトの数に対してデザイナーはまだまだ不足 • 細々としたUIの依頼の対応に追われる • 依頼されるUI設計の規模も少しずつ大きくなる
12. #RAKUSTechCon 拡大期 （デザイナー 3 → 7名） • デザイナーの数は充足 • 表面的な依頼にとどまり手が余る 戦略 要件 構造 骨格 表層 ← 表層の依頼が増える
 ← 本来やりたいのはココ 

13. #RAKUSTechCon デザイナーの困りごと • Excelに書かれたUIをキレイにする依頼 • 機能開発のミーティングに呼ばれない • UIの作成依頼をただ待つ状態 • 部分最適のUI設計で全体的な統一感がでない • 工数がないのであきらめざるをえないUI • 自分たちでは実装できない • メンバーのモチベーションが下がる
14. #RAKUSTechCon 特に困ったこと
 • Excelに書かれたUIをキレイにする依頼 • 機能開発のミーティングに呼ばれない → 依頼された段階では画面遷移や配置はほぼ決まっている → スケジュールは迫っており、あるべき論の改善案は求められて いない
15. #RAKUSTechCon 特に困ったこと
 • 自分たちだけでは何もできない • UIの作成依頼をただ待つ状態 → 社内下請けの状態になっている
16. #RAKUSTechCon 開発チームの中に入れていない
17. #RAKUSTechCon 5. 課題
 社内下請けの状態から脱却したい
 

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

19. #RAKUSTechCon できないことには理由がいろいろある
20. #RAKUSTechCon 要因
 ①開発プロセス ②スキル不足
21. #RAKUSTechCon 要因①開発プロセス 2000 2005 2010 2015 2020 比較的新しい 歴史が長い
22. #RAKUSTechCon 要因①開発プロセス ・歴史の長いプロダクトほど、デザイナーが上流工程に参加するタ イミングがなかった ・急に入ろうとしもハレーションが起きる ・デザイナーの役割について説明不足 プロセスの変更は、関係者に大きな負担を強いる
23. #RAKUSTechCon 要因②スキル不足 ・ビジネスサイドの方針の理解不足 ・顧客の業務の理解不足 ・顧客の課題の理解不足 ・仕様の理解不足
24. #RAKUSTechCon 自分たちの実力をつけて、やるべきことを着実に進めていこう
25. #RAKUSTechCon アクション ・デザイナーの役割を定義する ・機会をみつけて全力でエンジニアに協力 ・デザイナーがいたほうが楽だと実感してもらう 要因①開発プロセス
26. #RAKUSTechCon 要件定義におけるデザイナーとエンジニアの役割を定義 • 要求仕様を元に、アプリケーションで実現すべき要件を洗い出す人 • 要件を実現するために必要な内部ロジック、周辺機能との整合性などを設計する人 • 開発エンジニアとデザイナ双方が設計した成果物を、「要件定義書」としてまとめる人 • 要件を実現するために必要な項目・ UI（画面遷移など）を設計する人 • PdMが機能を考えるうえでUI・画面遷移のプロトタイプを作ってサポート エンジニア
 デザイナー

27. #RAKUSTechCon アクション ・事業部方針を理解する ・顧客の抱える課題を知る（要望一覧、インタビュー） ・複雑なプロダクトの仕様を理解する ・関連する法律を学習する（電子帳簿保存法、インボイス） ・デザイナーのスキルアップ 要因②スキル不足
28. #RAKUSTechCon • チームのスキルアップ 勉強会 輪読会
29. #RAKUSTechCon UIライブラリの策定
30. #RAKUSTechCon 徐々に出てきた効果 ・ミーティングにも呼ばれるようになってきた ・デザイナー主体でUI/UXをまかされるようになってきた ・ユーザーインタビューを依頼されるようになった ・エンジニアと定期的な振り返りの実施 → 開発チームの一員になれてきている実感
31. #RAKUSTechCon デザインチームの拡大を振り返って はじめのころは、デザイナーの役割がどうあるべきか、私自身も手探り。 UIだけの話をしたり、生産性のわるい仕事もしていた。 顧客のことも徐々に理解できてきた（まだわかってない）。 エンジニアとのコミュニケーションは大きく増えており、 社内下請けの状態から徐々に脱却し、デザイナーも上流工程に関われるようになってき た。
32. #RAKUSTechCon 今後のビジョン デザイナーが顧客の課題を本質的に理解し、解決するUI/UXを設計で きるようになりたい。 そのためには、以下を進めていきたい。 ・顧客の業務や課題の深い理解 ・エンジニアやPdMとの連携強化 ・デザイナーの設計スキルの向上
33. #RAKUSTechCon 5. 課題
 デザイナーが中心となってUI/UXを設計し、
 顧客課題を解決するチームを目指します

34. #RAKUSTechCon https://meety.net/matches/XuZwEPSfXahd
35. #RAKUSTechCon おわり