多様な環境で作り方をデザインする（freee技術の日2024）

2024年6月1日に開催されたfreee技術の日2024にて登壇した資料です。

当日のライブ配信のアーカイブは以下です。
https://youtu.be/fd_i3l2Bha8?t=16470

Transcript

1. 多様な環境で 作り⽅をデザインする ryotake / 武和椋太 2024年6⽉1⽇
2. 2 ryotake / 武和 椋太
 HR領域のプロダクトデザインを担 当。前職ではUXデザイナーとしてク ライアントワークをしていました。最 近は自作キーボード沼に片足を取 られています。
 プロダクトデザイナー
3. 　 デザインをデザイナーで閉じない 今⽇話したいこと
4. 　 デザインをデザイナーで閉じない 今⽇話したいこと なぜそう思ったか？ 閉じないための試⾏錯誤 を紹介します
5. 　 デザイナーあるある
6. 　 仕様は固まってるので デザイン作ってくれませんか？
7. 　 新規プロダクトの構想があるんだ けどデザイン担当してみない？
8. 　 お客様に提案してみたいので モックを作ってくれませんか？
9. 　 ⾊々な場⾯でデザイン担当 できそう！やるぞ！
10. 　 いつデザインできますか？ あ、、、 逆にいつまでにできないとやばいですか？
11. 　 ⾊々抱え込んで プロジェクトのボトルネックになりがち
12. 　 画⾯数少ないって⾔ってた けど結局量が増えてる そもそもこのスケジュール は無理では？ 仕様決まってるって聞 いたけど全然じゃん 裏側では‧‧‧
13. 　 なんで周りはこうしてくれ ないんだろう？ なんであの⼈はわかって くれないんだろう？
14. 　 Bizはいつも無理なこと ばっかり⾔ってくる このスケジュールでこの デザインは無理だよ、わ かってないな もう決まってるのに、 何でデザイナーはすぐ 作ってくれないんだ
15. 　 なぜこういったことが起こるか？
16. 　 広⽊⼤地『エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング』（技術評論社）
17. 　 コミュニケーションの不確実性 複数⼈で何かを⾏う場合、必ずそこに があるから
18. 　 意図が伝わるとは限らない コミュニケーションの不確実性 ⼈は他⼈を完全には理解できない 理解されても予想通りに⾏動するとは限らない
19. 　 “エンジニアリングは、複数⼈のチームで何かを実現 していく⼯程です。そのため、1⼈の⼈間ではなかな か起こらないはずの不合理な⾏動が、組織では発⽣ してしまうのです” 広木大地『エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング』（技術評論社）
20. 　 “無能で⼗分に説明のつくことを悪意のせいにするな” ロバート‧J‧ハンロン
21. 　 情報の伝達ができていないだけのことでも、 何か害意や悪意を⾒出してしまいがち
22. 　 我々は⽇々、 他⼈のことはどうしてもわかりきれないのに さらに複数のチームに⼊って開発している さらに専⾨性や役割が分かれている他⼈同⼠で というジレンマ
23. 　 “いかにしてコミュニケーションの不確実性を減らして いくのかというのが、エンジニアリングにとって重要な 態度となります。” 悲劇を繰り返さないためにも 広木大地『エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング』（技術評論社）
24. 　 意思決定とそれに関わる情報が 正しく整合性をもって伝達されるよう継続して努⼒すること。 情報公開が情報の透明性を作るわけではありません。 「情報の透明性」
25. 　 これをデザイナー視点で解釈すると
26. 　 デザインを進める中での情報が 正しく整合性をもって伝達されるよう継続して努⼒が必要！ デザインを渡して説明すれば透明性ができるわけではないぞ！ 「デザインの透明性」
27. 　 デザインをデザイナーで閉じない デザイナー PdM Eng デザイン
28. 　 デザインを透明にし チームの成果を最⼤化するための努⼒ デザイナー PdM Eng デザイン
29. 　 デザインを含めた開発プロセスを チームで定義する やってみたこと その1
30. 　 PdM‧Eng デザイナー 依頼 デザインプロセス • 追加調査 • UI設計 • ユーザビリティテスト など デザインデータ納品 デザイン待ち
32. 　 ⼯夫ポイント ⾃分たちの「仕事」を理解し、 アウトプットではなく仕事の連鎖を描く
33. 　 仕事とは 材料 材料 材料 活動 成果 なんらかの成果と、その成果を出すために⾏う活動のまとまり
34. 　 価値 ⾏動 属性 UI設計 デザインデータ UI設計の例
35. 　 デザインデータ xxx xxx 実装 プロダクト 仕事の成果は別の仕事の材料となる
36. 　 成果物や活動だけでプロセスを繋げると、属⼈化しがち PRD デザイン データ 実装
38. 　 職種に関わらず馴染みがある 成果物‧プロセスを選ぶ やってみたこと その2
39. 　 価値 ⾏動 属性 UI設計 デザインデータ UI設計の例
40. 　 これまで この情報を整理したければ 構造化シナリオかな KA法で価値マップ作 ろうかな
41. プレスリリースや提案資料を⼀緒に作ることで材料を揃える
42. 　 ⼯夫ポイント デザインの中で欲しい情報を デザイナー以外も馴染みある形で チームでアウトプットする
43. 　 データ設計と⼀緒に 早めに考えられると 良さそう 情報設計部分も⾃⼰完 結しない⽅がいいな
44. Engにとっても馴染みがある形式で情報設計
45. 　 figmaは必要になるまで使わない やってみたこと その3
46. 　 過去の過ち とりあえずfigmaで作ってみますね！
47. 　 過去の過ち とりあえずfigmaで作ってみますね！ ボタンはこの位置の⽅が クリック数は‧‧‧ これだと⼯数が‧‧‧ こういう機能があっても良くな い？ 既存仕様だとこうはできないで すね
48. 　 出てくる意⾒を全てfigmaに 反映し管理し続ける状況になった
49. 　 その結果、デザイナーしか触れないfigmaが最新の 仕様状態になり、デザイナーがボトルネックに
50. 　 別名：無限デザイン編
51. 　 さらに、 精緻なものが⾒えると気になってしまうのが⼈間 ボタンはこの位置の⽅が クリック数は‧‧‧ ここの⾊はもうちょっと⽬⽴た せた⽅が‧‧‧ もっと最初に⾒えるように ‧‧‧
52. 　 最初から細かいところばかりみてしまうと‧‧‧😱 あれ、そもそも何をどこまで作 るべきなんでしたっけ？
54. 　 ⼯夫ポイント イメージを広げていくときは 誰もが触れて、細部が気にならないレベルで 素早く作る
56. 　 職種に関わらず馴染みがある成果物‧プロセスを選ぶ デザインを含めた開発プロセスをチームで定義する figmaは必要になるまで使わない
57. 　 デザイナーしかわからない、触れないことが減り ボトルネックになることも減った やってみてどうだった？ 各プロセスで何が必要で何が⽣じるのかが認識揃 うと、⼀緒にやることが増えてきた 1 2
58. 　 デザインをデザイナーで閉じない 今⽇話したかったこと