デザイナーの帽子をかぶったわたしが、プロダクト開発するうえでスクラムチームに提供したいこと / what I want to provide to Scrum teams when developing products

Scrum Fest Fukuoka 2024の登壇資料です。
プロポーザル：https://confengine.com/conferences/scrum-fest-fukuoka-2024/proposal/19575

Transcript

1. 　 Scrum Fest Fukuoka 2024 デザイナーの帽子をかぶったわたしが、 プロダクト開発するうえでスクラムチームに提供したいこと 2024.3.9
2. 　 2 freee株式会社 プロダクトデザイナー とある大きな製造業（2009年〜） 　フロントエンド開発 / UXデザイン / アジャイル推進 freee株式会社（2021年10月〜） HCD-Net認定 人間中心設計専門家 CSPO/A-CSPO/CAL1 最近の趣味 森川 裕美（ひろみつ） Product Designer Hiromi Morikawa
3. 3 福岡に６年間住んでいました わいは 芸術工学 やるんや！ 昨⽇出てきた九⼯⼤と⾚本が⼀緒な、⼤橋にある芸⼯⼤に通っていた
4. 4 なぜ発表することにしたの？ • Regional Scrum Gathering Tokyo 2024で「ユーザーがわからない」「役に⽴つ かどうかわからない」というエピソードを⽿にしたこと • 「アウトカム」や「仮説検証」、デザイナーとの協働に対する関⼼の⾼まり • ⽇々チームでオタクの早⼝をしがち…
5. 5 Youはどんなデザイナー？ RSGT2024のOSTの様⼦
6. 6 Youはどんなデザイナー？
7. 7 Youはどんなデザイナー？ Front-end Development UI Design UX Now! + + Agile + 社内啓蒙 プロダクトデザイン 2009〜 2021〜 Java
8. 8 Youはどんなデザイナー？ • 業務のリサーチから、設計、デリバリー後の検証まで • 新企画のための機会領域の探索やコードは書いてない • １スクラムチーム専任
9. 9 本日お話しすること 話すこと • 検証だ！とユーザーに突撃する前に獲得できるユーザーに関する知識 • 「ユーザーの話を聞く」の解像度を⾼くするためのヒント 話さないこと • デザイナーが開発プロセスに混ざるためのベストプラクティス
10. 10 01 UXとスクラムの融合の勘違い期 02 「ユーザーに聞く」ことは劇薬？ 03 toBアプリの「アウトカム」とは何？ 04 よーし「ユーザー検証」だ！   ちょっと待って、ユーザに突撃する前に 05 「知らないこと」なのか「仮説」なのか 06 まとめ ⽬次
11. 　 UXとスクラムの 融合の勘違い期
12. 12 UXとスクラムチームとの出会い • 業務系中⼼だったため、toC新規事業へ憧れる • アジャイルのパイロットチームにUXデザイナーとしてin☺ • UXのプロセスと開発をうまく繋げたい • デュアルトラックアジャイルだ！ https://jpattonassociates.com/dual-track-development/
13. 13 UXとスクラムチームとの出会い • ユーザの反応があって嬉しい！ • Howはトレードオフできるという発⾒ • なんだかイキイキしてきたような気がする！
14. 14 UXとスクラムチームとの出会い • …プロダクトのお墓を⽴てることになった（何度⽬か • デリバリーとデザインは繋がっていたが… • 仮説検証は真には⾏われていないのだった
15. 15 ⾒えていなかった原価と損益分岐 • 毎⽉経理に向けて報告が必要なことを知る • 売上は？在庫は？棚卸し？…ほえ？ • フロントに気をとられて「事務作業」だと思ってしまっていた • 運⽤するほどお⾦が流れていき投資も少なく… • ユーザー！といってるだけではプロダクトはうまくいかないことを知った
16. 16 toCとtoBの領域の特性の違いを考えはじめる • インターフェースの設計でプロダクトに貢献できないか？ • toB領域のあるSaaSにキャリアの舵を切る（いまココ
17. 今⽇の話の前提
18. 18 　 自動化・可視化を実現する これまでにない統合型クラウド会計ソフト
19. 19 私が担当している領域 ・対象ユーザー：会計士さん/税理士さん向け ・通帳や領収書を預かり、記録する「記帳」の業務 ・これまでの弱みを潰す戦略のポジション
20. 20 今⽇の話の前提 • …という⽂脈を前提に、N1の話として聞いてください ◦ toBとtoCでも異なる ◦ サービス規模や組織規模でも違う ◦ 新規事業開発やグロースなどプロダクトのフェーズでも違う ◦ 「デザイナー」でもカバー領域も違う
21. 　 「ユーザーに聞く」ことは劇薬？
22. 22 わたしが働いているチーム エンジニア ＠名古屋 プロダクトマネージャー エンジニア デザイナー ＠東京 QA ＠⻑野
23. 23 スクラムチームの最近 • 新チーム⽴ち上げから２年 ◦ エンジニアが半分⼊れ替わった ◦ ユーザーや価値に⾼い関⼼ • スクラムを採⽤ ◦ アジャイル、スクラムの知識には濃淡 ◦ プロダクトゴール‧スプリントゴールを⽴てはじめて半年強くらい • 現場の業務の観察経験のないメンバーも
24. 24 スプリントレビューをちゃんとしたい機運の⾼まりAgain • メンバーの⼊れ替わりで⼀時的にベロシティが落ちていた • リズムも整い、難易度の⾼い開発部分がリリースできそう • 「スプリントレビュー」がどんな場かという理解も深まってきた • 今作っているものが有益なのか、⼈を呼んで確かめたいという話に
25. 25 スプリントレビューをちゃんとやる？
26. 「ユーザーに触ってもらおう」となったときに 気をつけると幸せになることを話すよ
27. 27 スプリントのなかで良く聞く⾔葉 「とりあえずユーザーに聞いてみましょう」
28. 28 スプリントのなかで良く聞く⾔葉 • 内⼼構えているわたし… 誰に聞く？ 何が検証できれば 次に進めるんや？ 判断をユーザーに 委ねてない？ 今聞くのが いいん？ チームで 仮説と検証観点 揃ってる…？
29. 29 検証でヒアリング落とし⽳あるある 僕は使えますね。 でも、ちょっとわかりにくかったんで、 ここに説明を出すのがいいと思います。 どうですか？使えましたか？
30. 30 黒い⽫問題 2006年初版
31. 31 黒い⽫問題 ある食器メーカーが「次に買うとしたらどんなお皿がいいか」というテーマで 主婦５人にグループインタビューをした。 参加者はデザイン案・経験談をもとに討議を進め、最終的には「これまでと は違う、オシャレでカッコイイ黒い四角いお皿」という意見でまとまった。 インタビュー協力のお礼に、食器サンプルの中からどれでも好きなモノを１ つだけ持って帰って良いことに。 （引用：ユーザ中心ウェブサイト戦略 p87）
32. 32 黒い⽫問題 参加者全員が持って帰ったのは、結局「白い丸い皿」だった。 白い丸いお皿を持って帰ろうとした理由を尋ねると「４人家族なので、1枚 だけ黒いお皿をもらっても仕方がない」「家にあるお皿の多くは丸いお皿。 四角いお皿だと食器棚に並べることができなさそう」という現実的な理由が 得られた。 （引用：ユーザ中心ウェブサイト戦略 p87）
33. ユーザの意⾒ではなく、⾏動という事実
35. 35 計画こそ命 • いちばん致命的なのは、狙っているユーザーではないこと ◦ 例：リテラシーが⾼すぎる ◦ 例：業務のバックグランドが違う ◦ 例：めちゃくちゃ好意的なロイヤルユーザー • リクルーティング失敗するとなかなか意図した検証ができない（設計８割）
36. 36 ヒアリング落とし⽳あるある • 「使いにくかったですか？」      ⾃分が感じた前提で誘導 • 「実はここをこうするとよくて…」   解決策としての使い⽅を案内 • 「何があればいいですか」       不⾜機能を聞いてしまう • 「ここがこうだったらどうですか？」  機能提案して印象を聞く
37. 37 ヒアリング落とし⽳あるある • ⾃分たちが作ったものなので、使って欲しい、説明したくなる • 使えていないとショック • 困ったことは早く解決してあげたい • 要望をそのまま受け取ろうとしちゃう
38. 38 ユーザーを⾒ることで⽣じる副作⽤ https://www.amazon.co.jp/dp/4297119951
39. 39 ユーザーを⾒ることで⽣じる副作⽤ • ユーザーの情報の鮮やかさに引っ張られる ◦ ⽬の前にしたN＝1のユーザーの声をかなえてあげたくなってしまう ◦ それぞれがいいと思ったものを開発したくなってしまわない？ ◦ 重要なものに投資できなくならない？ ユーザーの声をきき、受け⽌めるにもスキルがある、事前準備しよう
40. ユーザの意⾒ではなく、⾏動という事実
41. 41 ユーザの意⾒ではなく、⾏動という事実を重視する • いつもユーザーが⾏なっている⾏動か？ ◦ こちらを思って⾊々説明してくれた結果、⽇々の⾏動ではなかったり ◦ ⾃らを正当化する⼈間の防衛本能が働いたり • 発⽣頻度は？致命度は？ ◦ N＝3くらいの再現性ができてから優先度をあげる
42. 42 「使いにくい」とはなにか？ ユーザビリティ 特定のユーザが特定の利⽤状況において、システム、製品⼜はサービスを利⽤す る際に、効果、効率及び満⾜を伴って特定の⽬標を達成する度合い。 https://webdesk.jsa.or.jp/books/W11M0090/index/?bunsyo_id=JIS+Z+8521%3A2020
43. 43 「使いにくい」とはなにか？ ユーザビリティ 特定のユーザが特定の利⽤状況において、システム、製品⼜はサービスを利⽤す る際に、効果、効率及び満⾜を伴って特定の⽬標を達成する度合い。 https://webdesk.jsa.or.jp/books/W11M0090/index/?bunsyo_id=JIS+Z+8521%3A2020
44. 44 You Are Not the User. • ユーザビリティは特定の⽂脈におけるタスク の達成しやすさ • ユーザーと業務を知らない限り、 「使いにくい」が妄想になってしまう • ⾃分がユーザーになりにくいプロダクトで は、業務理解が使いやすさの設計のもと https://amzn.asia/d/irPchep
45. 45 You Are Not the User. https://www.redbubble.com/i/sweatshirt/You-are-NOT-the-user-UX-by-theriskworld/51243441.0LCRC
46. 46 You Are Not the User. https://www.amazon.co.jp/dp/B0CLP39RN6
47. 47 You Are Not the User. https://www.amazon.co.jp/dp/B0CLP39RN6
48. 　 toBアプリケーションの 「アウトカム」とは何？
49. 49 出現が増えてきたような⾔葉「アウトカム」 Output vs Outcome vs Impact
50. 50 出現が増えてきたような⾔葉「アウトカム」 • 製品を利⽤した結果もたらされる効果が「アウトカム」 ◦ 課題が解決した ◦ 新たな可能性が⽣まれた ◦ 顧客が適応したOR⾏動が変わった
51. 51 「カスタマージャーニーマップ」を書けばいい？ • ソフトウェアを使ってもらう相⼿は「カスタマー」なのか？ • 業務アプリケーションの場合は、購⼊者と使⽤者が違う場合も http://tech-pic.com/
52. 52 「カスタマージャーニーマップ」を書けばいい？ …CJMを次のように定義していますー「顧客のプロセス、ニーズ、 認識を、対象の企業との関係全般にわたって視覚的に図示したド キュメント」。 CJMでは通常、対象の企業の顧客として個人がもつ関係に焦点を 当てます。その上で、意思決定のプロセスにスポットライトを当てる ケースが多いのです。 …「そうした多数のタッチポイントの関係を正確に把握して調整し、 一貫性のある全体をどう作り出すか」です。…CJMはタッチポイント を可視化して、より効率よく管理するための戦略ツールなのです。 （マッピングエクスペリエンス p.249-252）
53. 53 「業務アプリケーション」なんだから「業務」でしょ https://dictionary.goo.ne.jp/word/%E6%A5%AD%E5%8B%99/
54. 54 「業務アプリケーション」なんだから「業務」でしょ • 達成しなければならない「業務」のためにソフトウェアを作っている ◦ ※契約やプラン周りの話になると、購買シナリオに近くなる場合も • 購買時の期待を知っておくことは必要だが、業務のコアで使うアプリケーショ ンには業務の理解が必要
55. 置かれた環境と、業務プロセスへの理解をすべし
56. 56 なぜ業務を知ることが重要と思っているか • 業務のソフトウェアは、業務の道具 • 業務を知らずして道具は作れない • 道具を作ることは、彼らの業務を作ること • 使い⽅を決める ＝ ユーザーの業務をコントロールできてしまう • インターフェースを決める倫理観‧責任感が伴う
57. 57 なぜ業務を知ることが重要と思っているか 7.1 情報システムは用途、ソフトウェアは道具 …ソフトウェアは、情報処理を支援する「道具」であって、情報処理 システム自体ではありません。 …一方、ソフトウェアのデータモデルはそれより間接的で、想定され る用途向けの帳簿を作るなど、業務を支援するための素材のような ものです。用途は狭く定義されている場合もありますが、広い場合 もあります。住所録ソフトは、住所録管理という用途に狭く特化した 道具です。スプレッドシートは、広い用途をもち、そのひとつとして住 所録管理に用いることもできる道具です。（データモデリングでドメインを駆 動する p.159）
58. 58 なぜ業務を知ることが重要と思っているか どんな「⽤途」の「道具」をつくるのか？
59. 59 ソフトウェアは、業務の道具
60. 60 「ペイン」「ニーズ」そのまえに • まず達成すべきは業務が達成できること • 実現したいこととのギャップがペイン ◦ そのまま解決することがゴールではないかもしれない ◦ 根っこを知れば技術や設計の⼒でもっと⼤きな価値を提供できるかも
61. 61 業務のオタクになれ • 利⽤者は誰？ ◦ 組織の中に複数のユーザーがいることがある • 組織のなかで、どんな関係性で働いているのか？ ◦ 何の情報をやりとりしているのか？ ◦ 情報はどのようにやり取りされているのか？ ◦ どんな⼒が働いているのか？ • 個々のユーザーの仕事のゴールと⽬的、はじまりと終わりは何か？ • 何が評価されるのか？
62. 　 よーし「ユーザー検証」だ！ ちょっと待って、 ユーザに突撃する前に
63. 63 じゃあペルソナつくりましょう！あるある 名前：降井圭利 年齢：42歳 家族構成：同い年の妻、⼦供２⼈（５歳‧２歳） 埼⽟在住 ⚪⚪の会社に勤めている 次の管理職候補のエース
64. 64 『ゴムのユーザー』に向けて作っていないか？ …しかし、これでは設計チームメンバが自分勝手なユーザ像を思 い描くことができてしまうので、何も定義していないのと同じなので す。このようなユーザ定義を 、アラン・クーパーは『ゴムのユーザ（elastic user）』と揶揄していま す。設計者の都合に合わせて伸縮自在のユーザという意味です。 …当然ながら、本来は設計者が”ユーザの都合”に合わせるべき。 （情報アーキテクチャ p.6-7）
65. 65 ビジネス上どのセグメントに注⼒しているか知っている？ ここのユーザーに 使って欲しい 今のプロダクトのファン ※イメージ 将来的には使って欲しい が今じゃない
66. 66 ビジネス上どのセグメントを狙っているか知っているか？ • ビジネス的に注⼒するセグメントごとに使われ⽅が違ったりもする ◦ どんなユーザー層に受け⼊れられている？ ◦ 今開発しているプロダクトはどこを狙っている？ • 何の課題を解くことが施策の使命なのか？ ◦ ターゲットとするユーザーのリテラシーは？ ◦ そのユーザーがどうなることを望んでいる？
67. ユーザのあたりもついた、ヒアリングだ！
68. 68 丸腰で突撃するリスク ユーザーから⾒ればあなたはプロダクトのプロ • 業務⾯ ◦ ⾔葉や⼀般的な流れを理解していないとそもそもを聞いてしまう ◦ 全く業務を知らないと印象悪いかも… • プロダクト⾯ ◦ 担当プロダクト以外の質問が⾶んでくる場合も ◦ 詳しい⼈が⼀⼈いると安⼼
69. 69 どこの情報を⾃分たちは知らないのか？ 業務達成のためのソフトウェアの細かな操作 ユーザーの業務プロセスや⾏動‧⼯夫 会社毎の慣習や独⾃の⼯夫‧ルール 業界‧地⽅の慣習 書籍で知れるような業務の⼀般知識 調べにくさ 難しい やさしい
70. 70 どこの情報を⾃分たちは知らないのか？ 業務達成のためのソフトウェアの細かな操作 ユーザーの業務プロセスや⾏動‧⼯夫 会社毎の慣習や独⾃の⼯夫‧ルール 業界‧地⽅の慣習 業務の⼀般知識 調べにくさ 難しい やさしい ここくらいまでは、 書籍や社内の有識者 から得られる可能性
71. 71 どこの情報を⾃分たちは知らないのか？ 業務達成のためのソフトウェアの細かな操作 ユーザーの業務プロセスや⾏動‧⼯夫 会社毎の慣習や独⾃の⼯夫‧ルール 業界‧地⽅の慣習 業務の⼀般知識 調べにくさ 難しい やさしい 社内関係者が知って いるかも、⾏かない と分からない領域に
72. 72 どこの情報を⾃分たちは知らないのか？ 業務達成のためのソフトウェアの細かな操作 ユーザーの業務プロセスや⾏動‧⼯夫 会社毎の慣習や独⾃の⼯夫‧ルール 業界‧地⽅の慣習 業務の⼀般知識 調べにくさ 難しい やさしい 新しく設計する際はこのあ たりまで知っておきたい。 業務を分析する上での材料
73. 73 どこの情報を⾃分たちは知らないのか？ 業務達成のためのソフトウェアの細かな操作 ユーザーの業務プロセスや⾏動‧⼯夫 会社毎の慣習や独⾃の⼯夫‧ルール 業界‧地⽅の慣習 業務の⼀般知識 調べにくさ 難しい やさしい プロダクトリリース後、 検証や利⽤状況を確認する 場合はここを⾒にいく
74. 74 でも…「操作」だけじゃない 業務達成のためのソフトウェアの細かな操作 ユーザーの業務プロセスや⾏動‧⼯夫 会社毎の慣習や独⾃の⼯夫‧ルール 業界‧地⽅の慣習 業務の⼀般知識 操作の 「⽬的」の⼟台 →達成したい業務
75. 75 業務のオタクを深めるための⽅法（ひろみつの場合） • 業界知識 ◦ 業界の基礎知識本を読む ◦ 簿記ドリルを解く ◦ 社内の業界経験者に話を聞く ◦ 業界の友達と雑談する ◦ 実家に来ている会計⼠さんに話を聞く
76. 76 業務のオタクを深めるための⽅法（ひろみつの場合） • ユーザー ◦ 税理⼠さんや会計⼠さんのブログを読む ◦ カンファレンスやユーザー会に参加する ◦ 業務の観察に⾏く ◦ 会計事務所内の関係者マップをつくる
77. 77 オタクを深める⽅法（チームで） • 業務のシミュレーションをする ◦ freee、他ソフトを触る会 ※実際の勉強会の資料
78. 78 業務を観察する • 普段業務を行っているデスクの近くにお邪魔する • 見せていただきたい業務を再確認する • 普段通り業務を進めてもらって黙って見る • ひとかたまりの業務を見せていただいた後に、気になる 行動などをインタビューする
79. 79 師匠と弟子のように https://www.amazon.co.jp/dp/4274214834 インタビュアーを弟子、ユーザーを師匠 と見立てて、師匠の体験を弟子に継承 するイメージ
80. 　 「知らないこと」なのか 「仮説」なのか
81. 81 「知らないこと」なのか「仮説」なのか • 知らないこと ◦ 知るすべがあるものは学習できる ◦ 調べられないものは現場に⾏って知る • 仮説 ◦ できるだけ早いうちに潰す ◦ 実装だけスプリントで回していると、レビューでは遅い場合も
82. 82 コスト低く早めに検証すべし プロジェクトマネジメント知識体系ガイド（ PMBOKガイド）第7版 • ライフサイクルが進⾏するにつれ、修正作業のコストは⾼くつく
83. 83 コスト低く早めに検証すべし • 実装しなくても検証できるもの • 実装しないと検証できないもの • 実データが⼊らないと検証できないもの • 業務の現場に導⼊され、⼀定期間利⽤しないと検証できないもの ディスカバリーからバックログに載っていないと全体の仮説は⾒えない （これをチームでやるのがデュアルトラック）
84. 84 あなたの「スクラム」はどこから？ https://www.mobiusloop.com/
85. 85 あなたの「スクラム」はどこから？ https://www.mobiusloop.com/ スクラムを取り⼊れよう！ という動きは、 デリバリー側から→ はじまることが多い （主観）
86. 86 検証の⽬的は様々 • 受け⼊れられそうか確認する • UIの使い勝⼿を検証する • 作ったものが⻑期的に仕事で使い物になるか検証する etc
87. 87 たとえば画⾯設計 PR‧製品品質‧ リードタイムを含めた サービス全体の体験 スケッチ 画⾯イメージ プロトタイプ 検証環境 リリース後サービス UI、レスポンスの精度 操作性など アプリ内の体験 表⽰情報‧レイアウト ⾊使いなどの適切さ コンセプトの受容性 表⽰情報の適切さ コンセプトの受容性 低精度 ⾼精度
88. 88 レビュー⼿段のひとつとしての、ユーザビリティテスト ユーザビリティテスト 　設計したUIを利用が想定される人に試しに使ってもらい、UIの操作性上の問題を発見すること プロダクトデザイン ユーザビリティ テスト 業務観察 設計を 検証する 得たヒントを 活かす 設計を修正する • ユーザビリティ上の仮説が⼤きかったり、使いやすさが重要な場合に有効
89. 89 やりかた • プロダクトチーム、関係者、ユーザーに近い⼈を呼ぶ • 事前の機能説明などは⾏わず仮の状況を伝え、利⽤をシミュレーション • メンバーは⾏動を観察 • その後操作中に気になった⾏動を深掘りしたり、発話を深掘りする
90. 90 現実の環境に近いシナリオを提示してシミュレーション
92. 92 チームをリサーチに巻き込む際に気をつけていること • 現場での振る舞いのインプットをしておく • ヒアリングの落とし⽳を共有しておく ◦ できるだけ「⾏動」「発⾔」のFACTを持ち帰られるように • とはいえその通りにはすぐには⾏動できないので、⼀度体験 ◦ 経験者と⼀緒に参加すると、その後の情報の吸収⼒が変わる
93. 93 複数職能が検証に参加すると何がいいのか？ • 複数の⽬で観察できる効率 • 職能が違えばかけているメガネが違う ◦ 違う⾓度からの情報が網羅的に集まる ◦ 同じ感覚を共有していると同じ⽅向を向きやすくなる ユーザーの業務を知ったり、ユーザーの声を受け⽌めるスキルをつけよう
94. 94 複数の関係者が同じユーザーに話を聞いていないか？ • 「あれ？今度⚪⚪さんがいらっしゃいますよ」系ヒヤリハット • そのFeatureが届くまで、様々な⼈々が関わり⽇々信頼を積み上げている ◦ マーケティング ◦ カスタマーサクセス ◦ カスタマーサポート etc… • 影響を受ける「ユーザー」はひとりではない ◦ 相対している⼈がユーザーに詳しい場合もある
95. 95 レビュー⼿段のひとつとしての、社内ヒアリング 社内担当者は、日々顧客に接しながらその特徴など分析を重ね…社内担 当者は顧客を特徴ごとに分類し、体系化して捉えているため、その知恵を 最初に借りることで、高い精度でターゲットユーザを想定できるのである。 まずは社内の人間を通して、ユーザを知る作業をスタートさせると良いだろ う。 社内ヒアリングで獲得したいのは、既存の数値データなどには現れにくい 事実、つまり担当者の人間の感覚としての経験値である。…担当者の過 去の経験、あるいは現在の経験という”事実”を引き出すことが重要であ り...。社内ヒアリングの基本姿勢は、担当者が感じている顧客に関する経 験則を上手に引き出すことなのである。 （引用：ユーザ中心ウェブサイト戦略）
96. 　 まとめ
97. 97 ユーザーに突撃して検証する前にできることがある • スクラムのリズムが安定してくるとアウトカムに⽬がいくようになる • ユーザと業務のオタクになるべし • どこの情報を⾃分たちは知らない？解像度も分けて考えられる • ユーザーの声をきき、受け⽌めるにもスキルがある、事前準備しよう • ステークホルダーへの影響もある、彼らの経験則を引き出そう
98. 98 わたし視点で提供できそうと思っていること • アウトカムに意識がむき始めるタイミングで、リサーチの知識が役⽴ちそう • デザイナーの帽⼦をかぶっている⼈がその知の⾼速道路を引けるかも • 特に開発からスクラムの導⼊が始まっているチームは融合のチャンス！ ユーザーに当てたい！と思ったとき、今⽇の内容が参考になると嬉しいです
99. ご清聴ありがとうごさいました！