Slide 1

Slide 1 text

多様な環境で 作り⽅をデザインする ryotake / 武和椋太 2024年6⽉1⽇

Slide 2

Slide 2 text

2 ryotake / 武和 椋太
 HR領域のプロダクトデザインを担 当。前職ではUXデザイナーとしてク ライアントワークをしていました。最 近は自作キーボード沼に片足を取 られています。
 プロダクトデザイナー

Slide 3

Slide 3 text

  デザインをデザイナーで閉じない 今⽇話したいこと

Slide 4

Slide 4 text

  デザインをデザイナーで閉じない 今⽇話したいこと なぜそう思ったか? 閉じないための試⾏錯誤 を紹介します

Slide 5

Slide 5 text

  デザイナーあるある

Slide 6

Slide 6 text

  仕様は固まってるので デザイン作ってくれませんか?

Slide 7

Slide 7 text

  新規プロダクトの構想があるんだ けどデザイン担当してみない?

Slide 8

Slide 8 text

  お客様に提案してみたいので モックを作ってくれませんか?

Slide 9

Slide 9 text

  ⾊々な場⾯でデザイン担当 できそう!やるぞ!

Slide 10

Slide 10 text

  いつデザインできますか? あ、、、 逆にいつまでにできないとやばいですか?

Slide 11

Slide 11 text

  ⾊々抱え込んで プロジェクトのボトルネックになりがち

Slide 12

Slide 12 text

  画⾯数少ないって⾔ってた けど結局量が増えてる そもそもこのスケジュール は無理では? 仕様決まってるって聞 いたけど全然じゃん 裏側では‧‧‧

Slide 13

Slide 13 text

  なんで周りはこうしてくれ ないんだろう? なんであの⼈はわかって くれないんだろう?

Slide 14

Slide 14 text

  Bizはいつも無理なこと ばっかり⾔ってくる このスケジュールでこの デザインは無理だよ、わ かってないな もう決まってるのに、 何でデザイナーはすぐ 作ってくれないんだ

Slide 15

Slide 15 text

  なぜこういったことが起こるか?

Slide 16

Slide 16 text

  広⽊⼤地『エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング』(技術評論社)

Slide 17

Slide 17 text

  コミュニケーションの不確実性 複数⼈で何かを⾏う場合、必ずそこに があるから

Slide 18

Slide 18 text

  意図が伝わるとは限らない コミュニケーションの不確実性 ⼈は他⼈を完全には理解できない 理解されても予想通りに⾏動するとは限らない

Slide 19

Slide 19 text

  “エンジニアリングは、複数⼈のチームで何かを実現 していく⼯程です。そのため、1⼈の⼈間ではなかな か起こらないはずの不合理な⾏動が、組織では発⽣ してしまうのです” 広木大地『エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング』(技術評論社)

Slide 20

Slide 20 text

  “無能で⼗分に説明のつくことを悪意のせいにするな” ロバート‧J‧ハンロン

Slide 21

Slide 21 text

  情報の伝達ができていないだけのことでも、 何か害意や悪意を⾒出してしまいがち

Slide 22

Slide 22 text

  我々は⽇々、 他⼈のことはどうしてもわかりきれないのに さらに複数のチームに⼊って開発している さらに専⾨性や役割が分かれている他⼈同⼠で というジレンマ

Slide 23

Slide 23 text

  “いかにしてコミュニケーションの不確実性を減らして いくのかというのが、エンジニアリングにとって重要な 態度となります。” 悲劇を繰り返さないためにも 広木大地『エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング』(技術評論社)

Slide 24

Slide 24 text

  意思決定とそれに関わる情報が 正しく整合性をもって伝達されるよう継続して努⼒すること。 情報公開が情報の透明性を作るわけではありません。 「情報の透明性」

Slide 25

Slide 25 text

  これをデザイナー視点で解釈すると

Slide 26

Slide 26 text

  デザインを進める中での情報が 正しく整合性をもって伝達されるよう継続して努⼒が必要! デザインを渡して説明すれば透明性ができるわけではないぞ! 「デザインの透明性」

Slide 27

Slide 27 text

  デザインをデザイナーで閉じない デザイナー PdM Eng デザイン

Slide 28

Slide 28 text

  デザインを透明にし チームの成果を最⼤化するための努⼒ デザイナー PdM Eng デザイン

Slide 29

Slide 29 text

  デザインを含めた開発プロセスを チームで定義する やってみたこと その1

Slide 30

Slide 30 text

  PdM‧Eng デザイナー 依頼 デザインプロセス ● 追加調査 ● UI設計 ● ユーザビリティテスト など デザインデータ納品 デザイン待ち

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

  ⼯夫ポイント ⾃分たちの「仕事」を理解し、 アウトプットではなく仕事の連鎖を描く

Slide 33

Slide 33 text

  仕事とは 材料 材料 材料 活動 成果 なんらかの成果と、その成果を出すために⾏う活動のまとまり

Slide 34

Slide 34 text

  価値 ⾏動 属性 UI設計 デザインデータ UI設計の例

Slide 35

Slide 35 text

  デザインデータ xxx xxx 実装 プロダクト 仕事の成果は別の仕事の材料となる

Slide 36

Slide 36 text

  成果物や活動だけでプロセスを繋げると、属⼈化しがち PRD デザイン データ 実装

Slide 37

Slide 37 text

No content

Slide 38

Slide 38 text

  職種に関わらず馴染みがある 成果物‧プロセスを選ぶ やってみたこと その2

Slide 39

Slide 39 text

  価値 ⾏動 属性 UI設計 デザインデータ UI設計の例

Slide 40

Slide 40 text

  これまで この情報を整理したければ 構造化シナリオかな KA法で価値マップ作 ろうかな

Slide 41

Slide 41 text

プレスリリースや提案資料を⼀緒に作ることで材料を揃える

Slide 42

Slide 42 text

  ⼯夫ポイント デザインの中で欲しい情報を デザイナー以外も馴染みある形で チームでアウトプットする

Slide 43

Slide 43 text

  データ設計と⼀緒に 早めに考えられると 良さそう 情報設計部分も⾃⼰完 結しない⽅がいいな

Slide 44

Slide 44 text

Engにとっても馴染みがある形式で情報設計

Slide 45

Slide 45 text

  figmaは必要になるまで使わない やってみたこと その3

Slide 46

Slide 46 text

  過去の過ち とりあえずfigmaで作ってみますね!

Slide 47

Slide 47 text

  過去の過ち とりあえずfigmaで作ってみますね! ボタンはこの位置の⽅が クリック数は‧‧‧ これだと⼯数が‧‧‧ こういう機能があっても良くな い? 既存仕様だとこうはできないで すね

Slide 48

Slide 48 text

  出てくる意⾒を全てfigmaに 反映し管理し続ける状況になった

Slide 49

Slide 49 text

  その結果、デザイナーしか触れないfigmaが最新の 仕様状態になり、デザイナーがボトルネックに

Slide 50

Slide 50 text

  別名:無限デザイン編

Slide 51

Slide 51 text

  さらに、 精緻なものが⾒えると気になってしまうのが⼈間 ボタンはこの位置の⽅が クリック数は‧‧‧ ここの⾊はもうちょっと⽬⽴た せた⽅が‧‧‧ もっと最初に⾒えるように ‧‧‧

Slide 52

Slide 52 text

  最初から細かいところばかりみてしまうと‧‧‧😱 あれ、そもそも何をどこまで作 るべきなんでしたっけ?

Slide 53

Slide 53 text

No content

Slide 54

Slide 54 text

  ⼯夫ポイント イメージを広げていくときは 誰もが触れて、細部が気にならないレベルで 素早く作る

Slide 55

Slide 55 text

No content

Slide 56

Slide 56 text

  職種に関わらず馴染みがある成果物‧プロセスを選ぶ デザインを含めた開発プロセスをチームで定義する figmaは必要になるまで使わない

Slide 57

Slide 57 text

  デザイナーしかわからない、触れないことが減り ボトルネックになることも減った やってみてどうだった? 各プロセスで何が必要で何が⽣じるのかが認識揃 うと、⼀緒にやることが増えてきた 1 2

Slide 58

Slide 58 text

  デザインをデザイナーで閉じない 今⽇話したかったこと

Slide 59

Slide 59 text

No content