デザイナーの帽子をかぶりながら、チームとの関わり方を考えつづけている話/How does a designer fit in a Scrum Team?

by Hiromi Morikawa

Slide 1

Slide 1 text

　 Scrum Fest Osaka 2023 デザイナーの帽子をかぶりながら、チームとの関わり方を考えつづけている話 2023.7.1

Slide 2

Slide 2 text

　 2 freee株式会社プロダクトデザイナーとある大きな製造業（2009年〜）　フロントエンド開発 / UXデザイン / アジャイル推進 freee株式会社（2021年10月〜） HCD-Net認定人間中心設計専門家 CSPO/A-CSPO/CAL1 最近の趣味森川裕美（ひろみつ） Product Designer Hiromi Morikawa プロフィール画像のトリミング⽅法

Slide 3

Slide 3 text

3 いまはプロダクトデザイナーのぼうしをかぶっています

Slide 4

Slide 4 text

4 昨日の基調講演聞きました？

Slide 5

Slide 5 text

5 本日お話しすること話すこと ● なぜアジャイルとデザインにこだわるのか、理由となる原体験 ● 関わるうえでどんな悩みがあるか ● 新しいチームのなかにどのようにデザイナーが関わっていったか ● ひとつの事例としてのわたしの経験話さないこと ● デザインプロセスの全体像 ● 具体的なデザインとスクラムのプロセスのあわせかた、⼿法、フレームワーク

Slide 6

Slide 6 text

6 01 わたしとデザインとチームの出会い 02 「プロダクトデザイナー」のわたしと、「スクラムチーム」 03 守破離からやり直し貢献を増やす 04 まとめ⽬次

Slide 7

Slide 7 text

　わたしとデザインとチームの出会い

Slide 8

Slide 8 text

8 大学にいくために香川県から福岡へわいはデザインやるんじゃ！

Slide 9

Slide 9 text

9 「チームでものづくり」の原体験 http://www.design.kyushu-u.ac.jp/~festival/tamayura/ 学園祭

Slide 10

Slide 10 text

10 「チームでものづくり」の原体験 ● 各学科の学⽣で構成 ○ 環境設計、⼯業設計、⾳響設計、画像設計、芸術情報設計 ○ 各専⾨分野の学⽣が横断的に集まる ● 共通⾔語は「デザイン（芸術⼯学）」 ○ 個々のスキルを活かしてコンセプトが形になってゆく ● 「1たす1が2」ではなくて、掛け合わせて2以上のものができる…！ ● 熱狂！熱狂！

Slide 11

Slide 11 text

11 「チームでものづくり」の組織頭副頭舞台美術班⾳響班映像班広報班⾐装班

Slide 12

Slide 12 text

12 「こんなチームで仕事がしたい」の原点 ● 今思えばはじめての職能横断チーム ● デザインという考え⽅、向かうべきゴールは共通していて、各⾃の得意な能⼒を使っている状態 ● 相⼿の能⼒、考えをリスペクト、⾃分を侵害される恐れもない⼤学という環境なので利害関係も少なく、違いはあれど、強烈な原体験

Slide 13

Slide 13 text

13 芸術工学＝ design https://design-academia.net/1046/

Slide 14

Slide 14 text

14 技術の人間化 - 技術を人間のために活かす技術の人間化を目指すデザイン（平成 17年度第52 回研究発表大会基調講演） https://www.jstage.jst.go.jp/article/jssds/13/3/13_KJ00004289367/_pdf

Slide 15

Slide 15 text

15 人の役にたつものを作りたい…でもエンジニアであるわたしがデザインを知り乗りこなすまで

Slide 16

Slide 16 text

16 社会⼈になってこんなことをやってきました Front-end Development UI Design UX Now! + + Agile + 社内啓蒙プロダクトデザイン 2009〜 2021〜 Java

Slide 17

Slide 17 text

17 プレイヤーからアジャイルの推進者となって学んだこと ● 場の観察やファシリテーションなど、デザイナーの経験を活かせる ● UXの知⾒も無関係ではない ● アジャイルでやろうとしていることは、プロダクト開発そのものでは？ ● アジャイルは「チーム」で探索的に「プロダクト」を作っていく活動「チームでものづくり」のヒントがありそう！ UX + Agile + 社内啓蒙プロダクトデザイン

Slide 18

Slide 18 text

18 情報アーキテクチャ「情報アーキテクチャ設計のプロセスにはその下に横たわる企業内の政治的な力関係がはっきりと現れてきます。（中略）設計者は、組織構造の政治的環境に敏感でなければなりません。（中略）しかし、政治的なことも理解しておけば、それがアーキテクチャに及ぼす影響をコントロールすることもできます。」（情報アーキテクチャ p.109-110） https://amzn.asia/d/asfG3RC

Slide 19

Slide 19 text

19 "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." Conway's law - Wikipedia コンウェイの法則「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」

Slide 20

Slide 20 text

20 分業が、UI設計でのペインとも繋がっている！ https://twitter.com/HikaruTayama/status/1111814066845040640

Slide 21

Slide 21 text

21 顧客からはじめ、早期にコラボレーションする・顧客から始めるのがアジャイル・早期から頻繁にコラボレーションするのがアジャイル・不確実性を計画するのがアジャイルプロセスやツールの「正しい」実践の先を見据え、それぞれの人たちの違いや複雑さを受け入れ、より良い方向に向かって一緒に働く方法を見つけることを求める。 https://amzn.asia/d/e26ZnAh

Slide 22

Slide 22 text

22 チームの外から中に戻る決意 ● 「開発」はアジャイルになった、では事業は？ ● 新規事業⽴ち上げ & クローズの繰り返ししか経験のない⾃分がプロダクトづくりの⽀援をしていいのか？後ろめたさがあった ● ユーザーに使われるプロダクトを成⻑させる経験を積もう ● 再度チームの中に⼊り「プロダクトデザイナー」として経験を積むことを決意 HCD,UX + Agile + 社内啓蒙プロダクトデザイン

Slide 23

Slide 23 text

23 プロダクトデザイナー？ ● ”デザイナー”種類が多すぎ問題 ○ UIデザイナー、UXデザイナー、サービスデザイナー etc… ● freeeには「エクスペリエンスデザイナー（XD）」「プロダクトデザイナー（PD）」がいる ○ XD：ユーザーリサーチによる課題の発⾒、調査結果に基づくコンセプト検討、およびプロジェクトの計画⽴案サポートを実施する ○ PD：共通仕様の⽅針やプロダクトデザインの⽅針を決定する。継続して改善し、プロダクトをより良い⽅向へ導いていく

Slide 24

Slide 24 text

24 個人的に推しているプロダクトデザインの定義 What the heck are the differences between product, UX, and UI designers?

Slide 25

Slide 25 text

　「プロダクトデザイナー」のわたしと「スクラムチーム」

Slide 26

Slide 26 text

26 　自動化・可視化を実現するこれまでにない統合型クラウド会計ソフト

Slide 27

Slide 27 text

27 私が担当している領域・対象ユーザー：会計士さん/税理士さん向け・法人や個人事業主から通帳や領収書などを預かり、記録を代行することがある・この「記帳」の業務が主に担当範囲

Slide 28

Slide 28 text

28 開発しているもの

Slide 29

Slide 29 text

29 不確実性の高いプロダクトづくり ● 新しいセグメントのユーザーに受け⼊れられるか？ ○ インストール型の既存ソフトに近い使い⼼地が必須 ○ 情報構造が違う＝既存ソフトを完全には真似られない ○ ⼊り⼝のレベルを下げ、⾃分達の世界に導く設計が必要 ● 社歴の浅いメンバーで古いコードに向き合う ○ 屋台⾻のプロダクトコードに⼿を⼊れるには、深い理解が必要アジャイルなプロダクトづくりが向いていそう🤔

Slide 30

Slide 30 text

30 わたしが働いているチームエンジニア＠名古屋プロダクトマネージャー QA デザイナー＠東京

Slide 31

Slide 31 text

31 デザイナーも「開発者」の一員スクラムガイド2020日本語版 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

Slide 32

Slide 32 text

32 デザイナーも「開発者」の一員スクラムガイド2020日本語版 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

Slide 33

Slide 33 text

33 デザイナーも「開発者」の一員 p.48 私は開発者という呼び名を⾮常に広い意味で使っている。この⾔葉が指すのは、ソフトウェアを開発する全ての⼈のことだ。プログラマ、テスター、アナリスト、データベースエンジニア、ユーザビリティエキスパート、テクニカルライター、アーキテクト、デザイナーなどである。 p.79 ここで開発者というとき、そこにはプログラマ、テスター、データベースエンジニア、アナリスト、ユーザーインターフェイス‧デザイナなど、すべての担当者が含まれることを忘れないでほしい。 https://amzn.asia/d/1iCT05w

Slide 34

Slide 34 text

34 わたしが働いているチームエンジニア＠名古屋プロダクトマネージャー QA デザイナー＠東京

Slide 35

Slide 35 text

35 わたしが働いているチームエンジニア＠名古屋プロダクトマネージャー QA デザイナー＠東京

Slide 36

Slide 36 text

と、息巻いてチームに⼊ったものの…

Slide 37

Slide 37 text

37 繰り返す形成期と混乱期形成期 Forming チームが形成される混乱期 Stoming ぶつかり合う統一期 Noming 共通の規範が形成される機能期 Performing チームとして成果を出す散会期 Adjourming チームの終結タックマンモデル

Slide 38

Slide 38 text

38 繰り返す形成期と混乱期 ● 頻繁に⼊れ替わる⼈員･･･ ● ふりかえりで⾔いだせない危機感… ● 価値をユーザーに届けたい気持ちはあるのに…リリースできない期間が続く

Slide 39

Slide 39 text

なぜこんなにうまくいかないんだろう？

Slide 40

Slide 40 text

40 ①チームのエンジニアからの思いがけない反応 ● ひろみつの動き⽅はfreeeのデザイナーとして異質なのでは？ ○ デザイナーが少しづつ作っていくやりかたをあまり⾒ない ○ 社内の他のデザイナーの標準と合ってる？ ○ ロードマップはプロダクトマネージャーが作るものでは？ ● デザイン作業の時間取れてる？ ○ PRD（製品要求仕様書）を書くからデザイン作業ができないのでは？

Slide 41

Slide 41 text

41 ● 過去に仕事をしたデザイナーはどんな動き⽅をしていた？ ○ どんなプロダクトで？ ○ どんなコミュニケーションがあった？ ● ⾃分とのギャップ ○ ⾼速にルック&フィールを決めることを求められているのでは ● これまでのデザイナーの印象が理解や期待値になっているのでは？ ○ 「デザイナー」という帽⼦は被り⼼地が悪いかもしれない… あとで思い直して本人に背景を聞いてみた

Slide 42

Slide 42 text

42 こういう距離があったのでは？私 ● プロダクトづくりの話だと思っている ● 実験しながらプロダクトデザインする ● 複雑なUIは技術⾯とトレードオフ ● なぜデザイナーが外に？開発からはじまるスクラム ● 最初はつくることから ● 決まったものをプロダクトバックログにしたい ● クオリティの⾼いUI設計がほしい期待値のすれ違い

Slide 43

Slide 43 text

43 ● 「スクラム」と「デザイン」のプロセスは相性がわるい ● スクラムのなかにはデザイナーが⼊っていないので疎外感があるアジャイルとデザインの関係でたびたび耳にしていたこともしかしてこれか…！という実感

Slide 44

Slide 44 text

44 ②こういうプロセスでやりたいという理想があった ● これまでの経験と思い込みからくる慢⼼、⼈と状況を⾒れていない ● デザインプロセスの共有も⾜りていなかった共通の課題感と知識がないのに焦っていた

Slide 45

Slide 45 text

45 エンジニアからの指摘 ● デザイナーのほうが壁をつくっているのでは？ ● エンジニアと⼀緒に考えられる部分もあるのでは？ ● 全部やろうとしていない？ ● デザイナーであるということを意識しすぎて、結果的に壁を作っているように⾒えたらしいそうか、壁をつくっているのはわたしなのかも…

Slide 46

Slide 46 text

46 かぶる帽子がかわると振る舞いが変わってしまう気づき ● チームのなかにいると完全なる当事者 ● 引いて場を冷静に⾒れない ● 出来事に感情で反応してしまう推進者メンバー推進者の距離当事者の距離

Slide 47

Slide 47 text

47 当時を知っているコーチ曰く「ひろみつさん何してんねん」

Slide 48

Slide 48 text

動きを変えよう、仕切り直しだ！

Slide 49

Slide 49 text

　守破離からやり直し貢献を増やす

Slide 50

Slide 50 text

50 守破離の守からやり直す ● ⼀旦求められる動き（Figma作成）をやりつつ、機会を伺うモードに ● 新しいエンジニアが増えるのを機に、コーチに⼊ってもらい「守」からやる決意をチームでする ● 個⼈的にもコーチに助けを求めた ○ はじめはプロセスへ積極的に介⼊せずにUI設計に注⼒すること ○ 私の⽬から⾒える課題感を伝えること

Slide 51

Slide 51 text

51 観察モードから再出発 ● UI設計難易度の低い開発エピックのタイミングで⼼に余裕が出てくる ● 先にUI設計を全て終えて開発に渡す形式に ○ スプリントには参加するが、エラー表⽰や気になる点があれば対応 ○ UI実装ができた段階で、デザイン⾯をレビュー

Slide 52

Slide 52 text

52 「もやみ」 ● UI設計観点で修正したいものがPBIに残り続ける ● 完成の定義にしてデザイナーもPRを確認すればいいのでは ● デザイナーが中に⼊っていたほうがいいのでは？ ● ふりかえりで少しずつ主張してみる

Slide 53

Slide 53 text

　 53 Figma作業もくもく配信スプリントレビューをリードしてみる同じ本を読んでみるリリース後の様⼦を⾒にいこう目の前のできることから 01 02 03 04

Slide 54

Slide 54 text

54 デザイナーっていつなにしてるの？ある⽇のふりかえりでの、コーチのひとこと… コーチ「みんな、ひろみつさんがどんな仕事してるか知ってるん？」チーム「知らないかも」わたし「そっかー(´‧ω‧`) 」 Figma作業をしているところのありのままを⾒せるTryをしてみることに

Slide 55

Slide 55 text

55 モブ部屋を作って作業を配信してみた

Slide 56

Slide 56 text

56 ● 作業が遅いなって更に思われないだろうか… ● 簡単そうだという印象にならないだろうか… ● UI設計にダメ出しされたらどうしよう… 作業をオープンにする怖さ https://twitter.com/morozov_dev/status/1563590470504042497

Slide 57

Slide 57 text

57 やってみて起こったこと ● 気軽にUI要件の相談ができるように ○ UI設計に困っているポイントも共有できる ○ 逆に実装の相談も

Slide 58

Slide 58 text

58 次に生まれた「もやみ」 ● デザイナーの他の思考をどう知ってもらえばいいのだろう？ ○ Figma上で⾒えている部分以外の活動 ○ プログラミングが開発の数割でしかないように、Figmaもその⼀部

Slide 59

Slide 59 text

　 59 Figma作業もくもく配信スプリントレビューでユーザーテスト同じ本を読んでみるリリース後の様⼦を⾒にいこう目の前のできることから 01 02 03 04

Slide 60

Slide 60 text

60 それまでのスプリントレビュー ● 開発した機能をエンジニアが操作して説明 ● プロダクトマネージャー（スクラムのPO）やデザイナーが確認する

Slide 61

Slide 61 text

61 「合っているか確認してもらう」「承認してもらう」ものではないスプリントレビューってなんだっけ

Slide 62

Slide 62 text

62 もっと効果的にレビューをするにはどうしたらいいのか？関係者の⽅々をレビューに呼び、説明した結果のフィードバックを受ける

Slide 63

Slide 63 text

63 想定シナリオに沿って動くものを触ってもらう Tryをやってみることにもっと効果的にレビューをするにはどうしたらいいのか？

Slide 64

Slide 64 text

64 「ユーザビリティテストが活かせるのでは！？」 ● 設計したUIが妥当な設計になっているか、ユーザビリティ問題の発⾒を⾏う ● ストーリーに対して、使えるものになっているか確認するのと同じでは ● 簡易的なユーザビリティテストを組み込んでみることをリードすることに

Slide 65

Slide 65 text

65 freeeのプロダクトデザイナーが関わるリサーチユーザビリティテスト　設計したUIを利用が想定される人に試しに使ってもらい、UIの操作性上の問題を発見すること　Figmaでの設計段階やプロトタイプ段階など、スプリント外で行うことが多い業務観察　「人々の実践（していること）のありのまま」を、おもに観察とインタビューを組合せて体感・　　理解しようとすること　※エスノグラフィを応用したリサーチをfreeeではこう呼んでいますプロダクトデザインユーザビリティテスト業務観察設計を検証する得たヒントを活かす設計を修正する

Slide 66

Slide 66 text

66 スプリントレビューでやった流れ ● プロダクトチーム＋関係者を呼ぶ（ユーザーを良く知っている⼈ or ユーザーに近い⼈） ○ カスタマーサクセス ○ マーケ ● 事前の機能説明などは⾏わず、仮の状況を伝え、実際に使ってもらう ● 操作画⾯をシェアしてもらい「考えていること」を声に出してもらう ● メンバーはカメラとマイクをオフにして操作を観察 ● ⼀通り操作が終わったら、操作中に気になった⾏動を深掘りしたり、率直な感想を聞く

Slide 67

Slide 67 text

67 提示したシナリオ

Slide 68

Slide 68 text

Slide 69

Slide 69 text

69 やってみてメンバーからどんな反応があった？ ● 現場で使うために何が必要かがわかった ○ 運⽤を含めた全体の流れのなかで、改善したい箇所が明らかになった ○ 連携されたデータを受け取るビジネス部⾨の観点で⾒ることもまたテスト ● 開発していると⾒えにくい課題点が⾒えた ● モチベーションが上がった ○ 直接的に利益を享受する⼈たちが喜んでくれた ○ ユーザーが使える、役に⽴ちそうだという⾃信が持てた

Slide 70

Slide 70 text

70 チームのテンションが爆上がりした

Slide 71

Slide 71 text

Slide 72

Slide 72 text

72 やってみたことで得たもの ● 動くものをもとに、早い段階でフィードバックを受ける重要さを体感 ● エンジニア、QA、デザイナーそれぞれの視点でユーザーの理解度が上がる ● スクラムのリズムのなかでデザイナーの専⾨性を発揮して協働できる ● 同じものをみることでチームを強化する学習のループを回すことができるかも

Slide 73

Slide 73 text

73 ”ヒアリング”だけではわからない ● UI設計の際に、関係者に「どんな課題があるか」事前にヒアリングしていた ● 動くものを元にシミュレーションしてみると、出てこなかった課題が出てきた ○ なぜ現場で困っているのか ○ さらに運⽤を楽にするには何を解決すべきか ■ 例：

Slide 74

Slide 74 text

74 やってみたことで起こった変化 ● スプリントごとに簡易ユーザビリティテストをするように ○ 成功体験から、1パターンに定型化してしまう ○ 結果「コストかかりすぎでは？毎回やるの？」という声が上がりだす ● シナリオはもっと前段階、計画時、PBI作成時に決められるのでは？ ● 設計に仮説があり確かめたいものだけに絞るという決断をする

Slide 75

Slide 75 text

75 やってみたことで起こった変化 ● 「レビューの⽅法はこれでいいのか？」あるエンジニアから疑問が上がる ○ 実現したいことに近づいているか分かるか？ ○ ユーザビリティテストではその時点での設計（仮説）検証が主 ● レビューではなくプロダクトゴールとスプリントゴールが原因では ○ チームでゴールとチームの状態、検査するものを計画するように ○ 進捗としてレビューで定量のデータも⾒よう

Slide 76

Slide 76 text

76 また生まれる個人的な「もやみ」 ● ユーザビリティテストでは、その時点で設計/開発したものの設計の妥当性は確認できるけれど、ゴールに近づけているかは検証できない ● ユーザー候補からのあらゆる要望を、チームが真に受けないためには？ ○ 「ユーザーは嘘をつくことがある」という知識の共有が必要そう ○ ユーザー像が共有されていないと、要望を受け⽌めてしまう⼼配もある ○ 「ぴったり」なユーザー像を共有するには？ ○ それは今実装すべきものか？

Slide 77

Slide 77 text

　 77 Figma作業もくもく配信スプリントレビューをリードしてみる同じ本を読んでみるリリース後の様⼦を⾒にいこう目の前のできることから 01 02 03 04

Slide 78

Slide 78 text

78 とある日のラーニングセッションで ● チームが担当している機能の不具合対応をどう扱えばいいか？ ● 主としているプロダクトの開発を圧迫せず予測可能性を⾼めるには？ ● プロダクトバックログとポイントの考えかた、バーンアップチャートについてふかぼりして学んだ ● チーム内ではアジャイルについての経験差もある

Slide 79

Slide 79 text

79 機運おばさんと化すわたし https://amzn.asia/d/1iCT05w

Slide 80

Slide 80 text

80 読書会、はじまる ● 毎週1章ずつ ● チーム全員参加 ○ プロダクトマネージャー、エンジニア、QA、プロダクトデザイナー ● 事前に読んできて感想を書いておく ● 当⽇コメントが盛り上がっていたり疑問に感じることを話し合うスタイル

Slide 81

Slide 81 text

81 実際の読書会メモ

Slide 82

Slide 82 text

82 やってみて起こったこと ● チームで同じ話題について議論する場ができた ○ 感想以外にも、考えていることや意⾒も表明できる ● 「これあの本で読んだやつだ」とチームで共通の語彙ができる ○ アジャイルに関する知識の差が埋まる ○ ユーザーストーリーやリースプランニング、ゴールについての共通認識 ● 「これやってみたい」とTryが⽣まれ出す

Slide 83

Slide 83 text

”計画づくりとは価値の探求なのだ。”

Slide 84

Slide 84 text

　 84 Figma作業もくもく配信スプリントレビューをリードしてみる同じ本を読んでみるリリース後の様⼦を⾒にいこう目の前のできることから 01 02 03 04

Slide 85

Slide 85 text

85 freeeのプロダクトデザイナーが関わるリサーチの種類ユーザビリティテスト　設計したUIを利用が想定される人に試しに使ってもらい、UIの操作性上の問題を発見すること　Figmaでの設計段階やプロトタイプ段階など、スプリント外で行うことが多い業務観察　「人々の実践（していること）のありのまま」を、おもに観察とインタビューを組合せて体感・　　理解しようとすること　※エスノグラフィを応用したリサーチをfreeeではこう呼んでいますプロダクトデザインユーザビリティテスト業務観察設計を検証する得たヒントを活かす設計を修正する

Slide 86

Slide 86 text

86 リリース後に行ったリサーチの目的 ● 使い続けている会計事務所と使わなくなった会計事務所の差分は何か？ ○ 定量データの裏には何が隠れている？ ○ なぜ使われている？継続利⽤を阻害する⽋点はない？ ○ 利⽤ユーザーに時系列にヒアリング ● あとからチームに参加したエンジニアのユーザー理解向上

Slide 87

Slide 87 text

87 画面外の業務環境を知る意味 ● デスクの上には何がある？どのような配置で？何のために？ ○ ディスプレイ、資料、電卓、文房具 etc… ● どんなキーボードを使っている？それはなぜ？ ● 入力している際のキータッチは？右手と左手はどこにある？ ● 画面外と画面内、どのように見ていそう？ ● 紙と画面をどのように行き来する？ ● 画面を操作する前に物理的に準備していることは？ ● どれくらいの速さで仕事が進んでいる？設計のWHYがたくさん隠れている ※イメージ

Slide 88

Slide 88 text

88 業務を観察する ● 普段業務を行っているデスクの近くにお邪魔する ● 見せていただきたい業務を再確認する ● 普段通り業務を進めてもらう ○ 黙って見る ○ 普段の作業を解説するデモにならないように注意する ● ひとかたまりの業務を見せていただいた後に、気になる行動などをインタビューする

Slide 89

Slide 89 text

89 師匠と弟子のように https://www.amazon.co.jp/dp/4274214834 インタビュアーを弟子、ユーザーを師匠と見立てて、師匠の体験を弟子に継承するイメージ

Slide 90

Slide 90 text

90 Human Centered Design（HCD）人間中心設計の計画利用状況の把握と明示ユーザの要求を満たす解決策の作成ユーザの要求事項の明示要求事項に対する設計の評価解決策がユーザーの要求事項を満たす「ISO 9241-210」で国際規格化されているインタラクティブシステムの⼈間中⼼設計に関する規格

Slide 91

Slide 91 text

91 HCDサイクル ● デザイナーはHCDに沿ってデザインしたといっても… ● ⼯程が縦割りだとアジャイルと組み合わさってなくない？ ● 要求事項に対する設計の評価は本当にできているのか…？

Slide 92

Slide 92 text

92 やってみてどうだった？

Slide 93

Slide 93 text

93 やってみてどうだった？ ● 使われているんだという実感 ● 同じ語彙（ユーザーや業務フロー、速度感、雰囲気、発⾔）で議論できるようになった ○ 操作の速度感など⽂字にしにくい感覚の共有 ○ あの機能や対応はやっぱり必要だ、という肌感 ○ 提供順や設計への納得感 ● プロダクトゴールへの距離をチームで実感できた

Slide 94

Slide 94 text

94 続く個人的な「もやみ」 ● 「課題」は聞いても出てこない、⾒るべきはユーザーのAs-Is ● 開発するのはたった1画⾯だが… ○ 複数パターンの業務プロセス上で使われる ○ 複数の役割のユーザーが利⽤する ○ モデル化していないとチームで同じものを⾒れないのでは？ ● 設計上のトレードオフが複数発⽣するということ ○ ⽬先の要望をフラットに扱っているとゴールを⾒失う ○ 設計の優先度に影響する ○ ゴールに向かうために検証すべき問いか？

Slide 95

Slide 95 text

95 巻き戻していっている感覚プロダクトゴールスプリントゴール設計としての仮説

Slide 96

Slide 96 text

　まとめ

Slide 97

Slide 97 text

97 やってみて思ったこと ● 何かをリードすることは、⾃分の仕事を知ってもらうということでもあった ○ 「デザイナーの◯◯さん」ではなく、「デザインが得意な◯◯さん」になる ● ちょっとずつやっているところを⾒せて、巻き込むということかも ○ 最初からきれいなプロセスでやるのは難しい ○ ⽬の前のことから ○ チームのその時その時に必要そうな情報を取り⼊れることで前進した

Slide 98

Slide 98 text

98 開発者の⼀員として「チームでものづくり」の旅はつづく ● デザイナーと協働するときに出てくるフレームワークの話もあるけれど… ● デザイナーの守備範囲もチームの理解もその現場次第 ● プロセスを取り⼊れることに意識がいくと⽬の前の課題がみえなくなる学び ● ⽬の前のチームと課題に⽬を向けるのが先かも ● デザインのプロセスを巻き戻してさかのぼらせていく ● 最終的に融合した状態を⽬指すのはあり ● 「みんなで」っていうのはどういうことだろう？ ○ 合議ではない ○ 全員が同じことを同じレベルでできる必要はない、では協働って？

Slide 99

Slide 99 text

Fin わたしの蒼い⿃さがしは続きそうです٩( 'ω' )و