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