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

スクラムフェス大阪2023登壇資料
プロポーザル：https://confengine.com/conferences/scrum-fest-osaka-2023/proposal/18545

1. 　 Scrum Fest Osaka 2023 デザイナーの帽子をかぶりながら、 チームとの関わり方を考えつづけている話 2023.7.1
2. 　 2 freee株式会社 プロダクトデザイナー とある大きな製造業（2009年〜） 　フロントエンド開発 / UXデザイン / アジャイル推進 freee株式会社（2021年10月〜） HCD-Net認定 人間中心設計専門家 CSPO/A-CSPO/CAL1 最近の趣味 森川 裕美（ひろみつ） Product Designer Hiromi Morikawa プロフィール画像の トリミング⽅法
3. 3 いまはプロダクトデザイナーのぼうしをかぶっています
4. 4 昨日の基調講演聞きました？
5. 5 本日お話しすること 話すこと • なぜアジャイルとデザインにこだわるのか、理由となる原体験 • 関わるうえでどんな悩みがあるか • 新しいチームのなかにどのようにデザイナーが関わっていったか • ひとつの事例としてのわたしの経験 話さないこと • デザインプロセスの全体像 • 具体的なデザインとスクラムのプロセスのあわせかた、⼿法、フレームワーク
6. 6 01 わたしとデザインとチームの出会い 02 「プロダクトデザイナー」の わたしと、 「スクラムチーム」 03 守破離からやり直し貢献を増やす 04 まとめ ⽬次
7. 　 わたしと デザインとチームの出会い
8. 8 大学にいくために香川県から福岡へ わいは デザイン やるんじゃ！
9. 9 「チームでものづくり」の原体験 http://www.design.kyushu-u.ac.jp/~festival/tamayura/ 学園祭
10. 10 「チームでものづくり」の原体験 • 各学科の学⽣で構成 ◦ 環境設計、⼯業設計、⾳響設計、画像設計、芸術情報設計 ◦ 各専⾨分野の学⽣が横断的に集まる • 共通⾔語は「デザイン（芸術⼯学）」 ◦ 個々のスキルを活かしてコンセプトが形になってゆく • 「1たす1が2」ではなくて、掛け合わせて2以上のものができる…！ • 熱狂！熱狂！
11. 11 「チームでものづくり」の組織 頭 副頭 舞台美術班 ⾳響班 映像班 広報班 ⾐装班
12. 12 「こんなチームで仕事がしたい」の原点 • 今思えばはじめての職能横断チーム • デザインという考え⽅、向かうべきゴールは共通していて、各⾃の得意な能⼒ を使っている状態 • 相⼿の能⼒、考えをリスペクト、⾃分を侵害される恐れもない ⼤学という環境なので利害関係も少なく、違いはあれど、強烈な原体験
13. 13 芸術工学 ＝ design https://design-academia.net/1046/
14. 14 技術の人間化 - 技術を人間のために活かす 技術の人間化を目指すデザイン （平成 17年度第52 回研 究発表 大会 基調講演 ） https://www.jstage.jst.go.jp/article/jssds/13/3/13_KJ00004289367/_pdf
15. 15 人の役にたつものを作りたい…でも エンジニアであるわたしがデザインを知り乗りこなすまで
16. 16 社会⼈になってこんなことをやってきました Front-end Development UI Design UX Now! + + Agile + 社内啓蒙 プロダクトデザイン 2009〜 2021〜 Java
17. 17 プレイヤーからアジャイルの推進者となって学んだこと • 場の観察やファシリテーションなど、デザイナーの経験を活かせる • UXの知⾒も無関係ではない • アジャイルでやろうとしていることは、プロダクト開発そのものでは？ • アジャイルは「チーム」で探索的に「プロダクト」を作っていく活動 「チームでものづくり」のヒントがありそう！ UX + Agile + 社内啓蒙 プロダクトデザイン
18. 18 情報アーキテクチャ 「情報アーキテクチャ設計のプロセスにはその下に横たわる企業内 の政治的な力関係がはっきりと現れてきます。（中略）設計者は、組 織構造の政治的環境に敏感でなければなりません。（中略）しかし、 政治的なことも理解しておけば、それがアーキテクチャに及ぼす影 響をコントロールすることもできます。」（情報アーキテクチャ p.109-110） https://amzn.asia/d/asfG3RC
19. 19 "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." Conway's law - Wikipedia コンウェイの法則 「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」
20. 20 分業が、UI設計でのペインとも繋がっている！ https://twitter.com/HikaruTayama/status/1111814066845040640
21. 21 顧客からはじめ、早期にコラボレーションする ・顧客から始めるのがアジャイル ・早期から頻繁にコラボレーションするのがアジャイル ・不確実性を計画するのがアジャイル プロセスやツールの「正しい」実践の先を見据え、 それぞれの人たちの違いや複雑さを受け入れ、 より良い方向に向かって一緒に働く方法を見つけることを求める。 https://amzn.asia/d/e26ZnAh
22. 22 チームの外から中に戻る決意 • 「開発」はアジャイルになった、では事業は？ • 新規事業⽴ち上げ & クローズの繰り返ししか経験のない⾃分が プロダクトづくりの⽀援をしていいのか？後ろめたさがあった • ユーザーに使われるプロダクトを成⻑させる経験を積もう • 再度チームの中に⼊り「プロダクトデザイナー」として経験を積むことを決意 HCD,UX + Agile + 社内啓蒙 プロダクトデザイン
23. 23 プロダクトデザイナー？ • ”デザイナー”種類が多すぎ問題 ◦ UIデザイナー、UXデザイナー、サービスデザイナー etc… • freeeには「エクスペリエンスデザイナー（XD）」「プロダクトデザイナー （PD）」がいる ◦ XD：ユーザーリサーチによる課題の発⾒、調査結果に基づくコンセプト検 討、およびプロジェクトの計画⽴案サポートを実施する ◦ PD：共通仕様の⽅針やプロダクトデザインの⽅針を決定する。継続して改善 し、プロダクトをより良い⽅向へ導いていく
24. 24 個人的に推しているプロダクトデザインの定義 What the heck are the differences between product, UX, and UI designers?
25. 　 「プロダクトデザイナー」 のわたしと「スクラムチーム」
26. 26 　 自動化・可視化を実現する これまでにない統合型クラウド会計ソフト
27. 27 私が担当している領域 ・対象ユーザー：会計士さん/税理士さん向け ・法人や個人事業主から通帳や領収書などを預かり、記録を代行することがある ・この「記帳」の業務が主に担当範囲
28. 28 開発しているもの
29. 29 不確実性の高いプロダクトづくり • 新しいセグメントのユーザーに受け⼊れられるか？ ◦ インストール型の既存ソフトに近い使い⼼地が必須 ◦ 情報構造が違う＝既存ソフトを完全には真似られない ◦ ⼊り⼝のレベルを下げ、⾃分達の世界に導く設計が必要 • 社歴の浅いメンバーで古いコードに向き合う ◦ 屋台⾻のプロダクトコードに⼿を⼊れるには、深い理解が必要 アジャイルなプロダクトづくりが向いていそう🤔
30. 30 わたしが働いているチーム エンジニア ＠名古屋 プロダクトマネージャー QA デザイナー ＠東京
31. 31 デザイナーも「開発者」の一員 スクラムガイド2020日本語版 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
32. 32 デザイナーも「開発者」の一員 スクラムガイド2020日本語版 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
33. 33 デザイナーも「開発者」の一員 p.48 私は開発者という呼び名を⾮常に広い意味で使っている。こ の⾔葉が指すのは、ソフトウェアを開発する全ての⼈のこと だ。プログラマ、テスター、アナリスト、データベースエン ジニア、ユーザビリティエキスパート、テクニカルライ ター、アーキテクト、デザイナーなどである。 p.79 ここで開発者というとき、そこにはプログラマ、テスター、 データベースエンジニア、アナリスト、ユーザーインター フェイス‧デザイナなど、すべての担当者が含まれることを 忘れないでほしい。 https://amzn.asia/d/1iCT05w
34. 34 わたしが働いているチーム エンジニア ＠名古屋 プロダクトマネージャー QA デザイナー ＠東京
35. 35 わたしが働いているチーム エンジニア ＠名古屋 プロダクトマネージャー QA デザイナー ＠東京
36. と、息巻いてチームに⼊ったものの…
37. 37 繰り返す形成期と混乱期 形成期 Forming チームが 形成される 混乱期 Stoming ぶつかり合う 統一期 Noming 共通の規範が 形成される 機能期 Performing チームとして 成果を出す 散会期 Adjourming チームの 終結 タックマンモデル
38. 38 繰り返す形成期と混乱期 • 頻繁に⼊れ替わる⼈員･･･ • ふりかえりで⾔いだせない危機感… • 価値をユーザーに届けたい気持ちはあるのに…リリースできない期間が続く
39. なぜこんなにうまくいかないんだろう？
40. 40 ①チームのエンジニアからの思いがけない反応 • ひろみつの動き⽅はfreeeのデザイナーとして異質なのでは？ ◦ デザイナーが少しづつ作っていくやりかたをあまり⾒ない ◦ 社内の他のデザイナーの標準と合ってる？ ◦ ロードマップはプロダクトマネージャーが作るものでは？ • デザイン作業の時間取れてる？ ◦ PRD（製品要求仕様書）を書くからデザイン作業ができないのでは？
41. 41 • 過去に仕事をしたデザイナーはどんな動き⽅をしていた？ ◦ どんなプロダクトで？ ◦ どんなコミュニケーションがあった？ • ⾃分とのギャップ ◦ ⾼速にルック&フィールを決めることを求められているのでは • これまでのデザイナーの印象が理解や期待値になっているのでは？ ◦ 「デザイナー」という帽⼦は被り⼼地が悪いかもしれない… あとで思い直して本人に背景を聞いてみた
42. 42 こういう距離があったのでは？ 私 • プロダクトづくりの話だと思っている • 実験しながらプロダクトデザインする • 複雑なUIは技術⾯とトレードオフ • なぜデザイナーが外に？ 開発からはじまるスクラム • 最初はつくることから • 決まったものをプロダクトバックロ グにしたい • クオリティの⾼いUI設計がほしい 期待値のすれ違い
43. 43 • 「スクラム」と「デザイン」のプロセスは相性がわるい • スクラムのなかにはデザイナーが⼊っていないので疎外感がある アジャイルとデザインの関係でたびたび耳にしていたこと もしかしてこれか…！という実感
44. 44 ②こういうプロセスでやりたいという理想があった • これまでの経験と思い込みからくる慢⼼、⼈と状況を⾒れていない • デザインプロセスの共有も⾜りていなかった 共通の課題感と知識がないのに焦っていた
45. 45 エンジニアからの指摘 • デザイナーのほうが壁をつくっているのでは？ • エンジニアと⼀緒に考えられる部分もあるのでは？ • 全部やろうとしていない？ • デザイナーであるということを意識しすぎて、結果的に壁を作っているように ⾒えたらしい そうか、壁をつくっているのはわたしなのかも…
46. 46 かぶる帽子がかわると振る舞いが変わってしまう気づき • チームのなかにいると完全なる当事者 • 引いて場を冷静に⾒れない • 出来事に感情で反応してしまう 推進者 メンバー 推進者の距離 当事者の距離
47. 47 当時を知っているコーチ曰く 「ひろみつさん何してんねん」
48. 動きを変えよう、仕切り直しだ！
49. 　 守破離からやり直し 貢献を増やす
50. 50 守破離の守からやり直す • ⼀旦求められる動き（Figma作成）をやりつつ、機会を伺うモードに • 新しいエンジニアが増えるのを機に、コーチに⼊ってもらい「守」からやる決 意をチームでする • 個⼈的にもコーチに助けを求めた ◦ はじめはプロセスへ積極的に介⼊せずにUI設計に注⼒すること ◦ 私の⽬から⾒える課題感を伝えること
51. 51 観察モードから再出発 • UI設計難易度の低い開発エピックのタイミングで⼼に余裕が出てくる • 先にUI設計を全て終えて開発に渡す形式に ◦ スプリントには参加するが、エラー表⽰や気になる点があれば対応 ◦ UI実装ができた段階で、デザイン⾯をレビュー
52. 52 「もやみ」 • UI設計観点で修正したいものがPBIに残り続ける • 完成の定義にしてデザイナーもPRを確認すればいいのでは • デザイナーが中に⼊っていたほうがいいのでは？ • ふりかえりで少しずつ主張してみる
53. 　 53 Figma作業 もくもく配信 スプリントレビュー をリードしてみる 同じ本を 読んでみる リリース後の 様⼦を⾒にいこう 目の前のできることから 01 02 03 04
54. 54 デザイナーっていつなにしてるの？ ある⽇のふりかえりでの、コーチのひとこと… コーチ「みんな、ひろみつさんがどんな仕事してるか知ってるん？」 チーム「知らないかも」 わたし「そっかー(´‧ω‧`) 」 Figma作業をしているところのありのままを⾒せるTryをしてみることに
55. 55 モブ部屋を作って作業を配信してみた
56. 56 • 作業が遅いなって更に思われないだろうか… • 簡単そうだという印象にならないだろうか… • UI設計にダメ出しされたらどうしよう… 作業をオープンにする怖さ https://twitter.com/morozov_dev/status/1563590470504042497
57. 57 やってみて起こったこと • 気軽にUI要件の相談ができるように ◦ UI設計に困っているポイントも共有できる ◦ 逆に実装の相談も
58. 58 次に生まれた「もやみ」 • デザイナーの他の思考をどう知ってもらえばいいのだろう？ ◦ Figma上で⾒えている部分以外の活動 ◦ プログラミングが開発の数割でしかないように、Figmaもその⼀部
59. 　 59 Figma作業 もくもく配信 スプリントレビュー でユーザーテスト 同じ本を 読んでみる リリース後の 様⼦を⾒にいこう 目の前のできることから 01 02 03 04
60. 60 それまでのスプリントレビュー • 開発した機能をエンジニアが操作して説明 • プロダクトマネージャー（スクラムのPO）やデザイナーが確認する
61. 61 「合っているか確認してもらう」「承認してもらう」ものではない スプリントレビューってなんだっけ
62. 62 もっと効果的にレビューをするにはどうしたらいいのか？ 関係者の⽅々をレビューに呼び、 説明した結果のフィードバックを受ける       
63. 63 想定シナリオに沿って動くものを触ってもらう Tryをやってみることに もっと効果的にレビューをするにはどうしたらいいのか？
64. 64 「ユーザビリティテストが活かせるのでは！？」 • 設計したUIが妥当な設計になっているか、ユーザビリティ問題の発⾒を⾏う • ストーリーに対して、使えるものになっているか確認するのと同じでは • 簡易的なユーザビリティテストを組み込んでみることをリードすることに
65. 65 freeeのプロダクトデザイナーが関わるリサーチ ユーザビリティテスト 　設計したUIを利用が想定される人に試しに使ってもらい、UIの操作性上の問題を発見すること 　Figmaでの設計段階やプロトタイプ段階など、スプリント外で行うことが多い 業務観察 　「人々の実践（していること）のありのまま」を、おもに観察とインタビューを組合せて体感・ 　　理解しようとすること 　※エスノグラフィを応用したリサーチをfreeeではこう呼んでいます プロダクトデザイン ユーザビリティ テスト 業務観察 設計を 検証する 得たヒントを 活かす 設計を修正する
66. 66 スプリントレビューでやった流れ • プロダクトチーム＋関係者を呼ぶ （ユーザーを良く知っている⼈ or ユーザーに近い⼈） ◦ カスタマーサクセス ◦ マーケ • 事前の機能説明などは⾏わず、仮の状況を伝え、実際に使ってもらう • 操作画⾯をシェアしてもらい「考えていること」を声に出してもらう • メンバーはカメラとマイクをオフにして操作を観察 • ⼀通り操作が終わったら、操作中に気になった⾏動を深掘りしたり、率直な感 想を聞く
67. 67 提示したシナリオ
69. 69 やってみてメンバーからどんな反応があった？ • 現場で使うために何が必要かがわかった ◦ 運⽤を含めた全体の流れのなかで、改善したい箇所が明らかになった ◦ 連携されたデータを受け取るビジネス部⾨の観点で⾒ることもまたテスト • 開発していると⾒えにくい課題点が⾒えた • モチベーションが上がった ◦ 直接的に利益を享受する⼈たちが喜んでくれた ◦ ユーザーが使える、役に⽴ちそうだという⾃信が持てた
70. 70 チームのテンションが爆上がりした
72. 72 やってみたことで得たもの • 動くものをもとに、早い段階でフィードバックを受ける重要さを体感 • エンジニア、QA、デザイナーそれぞれの視点でユーザーの理解度が上がる • スクラムのリズムのなかでデザイナーの専⾨性を発揮して協働できる • 同じものをみることでチームを強化する学習のループを回すことができるかも
73. 73 ”ヒアリング”だけではわからない • UI設計の際に、関係者に「どんな課題があるか」事前にヒアリングしていた • 動くものを元にシミュレーションしてみると、出てこなかった課題が出てきた ◦ なぜ現場で困っているのか ◦ さらに運⽤を楽にするには何を解決すべきか ▪ 例：
74. 74 やってみたことで起こった変化 • スプリントごとに簡易ユーザビリティテストをするように ◦ 成功体験から、1パターンに定型化してしまう ◦ 結果「コストかかりすぎでは？毎回やるの？」という声が上がりだす • シナリオはもっと前段階、計画時、PBI作成時に決められるのでは？ • 設計に仮説があり確かめたいものだけに絞るという決断をする
75. 75 やってみたことで起こった変化 • 「レビューの⽅法はこれでいいのか？」あるエンジニアから疑問が上がる ◦ 実現したいことに近づいているか分かるか？ ◦ ユーザビリティテストではその時点での設計（仮説）検証が主 • レビューではなくプロダクトゴールとスプリントゴールが原因では ◦ チームでゴールとチームの状態、検査するものを計画するように ◦ 進捗としてレビューで定量のデータも⾒よう
76. 76 また生まれる個人的な「もやみ」 • ユーザビリティテストでは、その時点で設計/開発したものの設計の妥当性は 確認できるけれど、ゴールに近づけているかは検証できない • ユーザー候補からのあらゆる要望を、チームが真に受けないためには？ ◦ 「ユーザーは嘘をつくことがある」という知識の共有が必要そう ◦ ユーザー像が共有されていないと、要望を受け⽌めてしまう⼼配もある ◦ 「ぴったり」なユーザー像を共有するには？ ◦ それは今実装すべきものか？
77. 　 77 Figma作業 もくもく配信 スプリントレビュー をリードしてみる 同じ本を 読んでみる リリース後の 様⼦を⾒にいこう 目の前のできることから 01 02 03 04
78. 78 とある日のラーニングセッションで • チームが担当している機能の不具合対応をどう扱えばいいか？ • 主としているプロダクトの開発を圧迫せず予測可能性を⾼めるには？ • プロダクトバックログとポイントの考えかた、バーンアップチャートについて ふかぼりして学んだ • チーム内ではアジャイルについての経験差もある
79. 79 機運おばさんと化すわたし https://amzn.asia/d/1iCT05w
80. 80 読書会、はじまる • 毎週1章ずつ • チーム全員参加 ◦ プロダクトマネージャー、エンジニア、QA、プロダクトデザイナー • 事前に読んできて感想を書いておく • 当⽇コメントが盛り上がっていたり疑問に感じることを話し合うスタイル
81. 81 実際の読書会メモ
82. 82 やってみて起こったこと • チームで同じ話題について議論する場ができた ◦ 感想以外にも、考えていることや意⾒も表明できる • 「これあの本で読んだやつだ」とチームで共通の語彙ができる ◦ アジャイルに関する知識の差が埋まる ◦ ユーザーストーリーやリースプランニング、ゴールについての共通認識 • 「これやってみたい」とTryが⽣まれ出す
83. ”計画づくりとは価値の探求なのだ。”
84. 　 84 Figma作業 もくもく配信 スプリントレビュー をリードしてみる 同じ本を 読んでみる リリース後の 様⼦を⾒にいこう 目の前のできることから 01 02 03 04
85. 85 freeeのプロダクトデザイナーが関わるリサーチの種類 ユーザビリティテスト 　設計したUIを利用が想定される人に試しに使ってもらい、UIの操作性上の問題を発見すること 　Figmaでの設計段階やプロトタイプ段階など、スプリント外で行うことが多い 業務観察 　「人々の実践（していること）のありのまま」を、おもに観察とインタビューを組合せて体感・ 　　理解しようとすること 　※エスノグラフィを応用したリサーチをfreeeではこう呼んでいます プロダクトデザイン ユーザビリティ テスト 業務観察 設計を 検証する 得たヒントを 活かす 設計を修正する
86. 86 リリース後に行ったリサーチの目的 • 使い続けている会計事務所と使わなくなった会計事務所の差分は何か？ ◦ 定量データの裏には何が隠れている？ ◦ なぜ使われている？継続利⽤を阻害する⽋点はない？ ◦ 利⽤ユーザーに時系列にヒアリング • あとからチームに参加したエンジニアのユーザー理解向上
87. 87 画面外の業務環境を知る意味 • デスクの上には何がある？どのような配置で？何のために？ ◦ ディスプレイ、資料、電卓、文房具 etc… • どんなキーボードを使っている？それはなぜ？ • 入力している際のキータッチは？右手と左手はどこにある？ • 画面外と画面内、どのように見ていそう？ • 紙と画面をどのように行き来する？ • 画面を操作する前に物理的に準備していることは？ • どれくらいの速さで仕事が進んでいる？ 設計のWHYがたくさん隠れている ※イメージ
88. 88 業務を観察する • 普段業務を行っているデスクの近くにお邪魔する • 見せていただきたい業務を再確認する • 普段通り業務を進めてもらう ◦ 黙って見る ◦ 普段の作業を解説するデモにならないように注意する • ひとかたまりの業務を見せていただいた後に、気になる 行動などをインタビューする
89. 89 師匠と弟子のように https://www.amazon.co.jp/dp/4274214834 インタビュアーを弟子、ユーザーを師匠 と見立てて、師匠の体験を弟子に継承 するイメージ
90. 90 Human Centered Design（HCD） 人間中心設計の計画 利用状況の把握と 明示 ユーザの要求を満たす解決策の 作成 ユーザの 要求事項の明示 要求事項に対する 設計の評価 解決策がユーザーの 要求事項を満たす 「ISO 9241-210」で国際規格化されている インタラクティブシステムの⼈間中⼼設計に関する規格
91. 91 HCDサイクル • デザイナーはHCDに沿ってデザインしたといっても… • ⼯程が縦割りだとアジャイルと組み合わさってなくない？ • 要求事項に対する設計の評価は本当にできているのか…？
92. 92 やってみてどうだった？
93. 93 やってみてどうだった？ • 使われているんだという実感 • 同じ語彙（ユーザーや業務フロー、速度感、雰囲気、発⾔）で議論できるよう になった ◦ 操作の速度感など⽂字にしにくい感覚の共有 ◦ あの機能や対応はやっぱり必要だ、という肌感 ◦ 提供順や設計への納得感 • プロダクトゴールへの距離をチームで実感できた
94. 94 続く個人的な「もやみ」 • 「課題」は聞いても出てこない、⾒るべきはユーザーのAs-Is • 開発するのはたった1画⾯だが… ◦ 複数パターンの業務プロセス上で使われる ◦ 複数の役割のユーザーが利⽤する ◦ モデル化していないとチームで同じものを⾒れないのでは？ • 設計上のトレードオフが複数発⽣するということ ◦ ⽬先の要望をフラットに扱っているとゴールを⾒失う ◦ 設計の優先度に影響する ◦ ゴールに向かうために検証すべき問いか？
95. 95 巻き戻していっている感覚 プロダクトゴール スプリントゴール 設計としての仮説
96. 　 まとめ
97. 97 やってみて思ったこと • 何かをリードすることは、⾃分の仕事を知ってもらうということでもあった ◦ 「デザイナーの◯◯さん」ではなく、「デザインが得意な◯◯さん」になる • ちょっとずつやっているところを⾒せて、巻き込むということかも ◦ 最初からきれいなプロセスでやるのは難しい ◦ ⽬の前のことから ◦ チームのその時その時に必要そうな情報を取り⼊れることで前進した
98. 98 開発者の⼀員として「チームでものづくり」の旅はつづく • デザイナーと協働するときに出てくるフレームワークの話もあるけれど… • デザイナーの守備範囲もチームの理解もその現場次第 • プロセスを取り⼊れることに意識がいくと⽬の前の課題がみえなくなる学び • ⽬の前のチームと課題に⽬を向けるのが先かも • デザインのプロセスを巻き戻してさかのぼらせていく • 最終的に融合した状態を⽬指すのはあり • 「みんなで」っていうのはどういうことだろう？ ◦ 合議ではない ◦ 全員が同じことを同じレベルでできる必要はない、では協働って？
99. Fin わたしの蒼い⿃さがしは続きそうです٩( 'ω' )و