Successfully reported this slideshow.
Your SlideShare is downloading. ×

グロース施策でもUX活動を絶やさないために。UXとアジャイルの交差点と、他職種混合チームの今後

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 39 Ad

グロース施策でもUX活動を絶やさないために。UXとアジャイルの交差点と、他職種混合チームの今後

Download to read offline

Chatwork Product Day 2022

Chatworkのグロースの一端を担うグロースチーム。このチームでは、単に数値の向上を目的とした施策ではなく、数値と密接に結びつくユーザー課題の解決や、シームレスな体験提供をアジャイルに価値検証することを大事にしています。
自分達で意思決定しながら成長するためのチーム体制構築について、試行錯誤をご紹介しました。

Chatwork Product Day 2022

Chatworkのグロースの一端を担うグロースチーム。このチームでは、単に数値の向上を目的とした施策ではなく、数値と密接に結びつくユーザー課題の解決や、シームレスな体験提供をアジャイルに価値検証することを大事にしています。
自分達で意思決定しながら成長するためのチーム体制構築について、試行錯誤をご紹介しました。

Advertisement
Advertisement

More Related Content

Recently uploaded (20)

Advertisement

グロース施策でもUX活動を絶やさないために。UXとアジャイルの交差点と、他職種混合チームの今後

  1. 1. © Chatwork 2022年 10月 7日 北口 / 西口 / 仁科 Chatwork株式会社 グロース施策でも UX活動を絶やさないために UXとアジャイルの交差点と職能横断チームの今後
  2. 2. 本日の登壇メンバー プロダクトオーナー (PO) 北口 ひとみ スクラムマスター / エンジニア (ScM) 西口 誠二 UX デザイナー / UXリサーチャー 仁科 智子
  3. 3. 3 所属チーム 開発 3名 デザイナー 3名 PO 1名 ScM 1名 Chatwork のユーザーグロースを担当している職能横断チームです 社内では Growth Engineering チーム、 略して「GEチーム」と 呼ばれています!
  4. 4. 今日お話しすること グロース施策のアジャイル開発と UX の交差点 1. チームの思いと体制構築の壁 2. デザインプロセスの構築 3. チームの成果事例 4. パネルディスカッション
  5. 5. チームの変遷 発足 今回のお話 2019年 2022年 4月 体制変更後
  6. 6. 私たちのチームミッション プロダクトをグロースさせる施策を すばやく生み出していくこと
  7. 7. がむしゃらに施策を打つのではなく チーム一丸となって ユーザー体験を良くして成果を出したい! チームの思い チーム内を受発注関係には したくない!
  8. 8. チームの思い チーム一丸となるには デザインプロセスを含めた アジャイル開発の体制構築が重要と考えた
  9. 9. 体制構築の壁 スクラムを導入 デザインプロセスと開発プロセスを同じスプリント で回そうとした デザインプロセス 開発のスプリントにとりあえずデザイナーを参加させる、というような形ではうまくいかなかった ● サイクルが違う ● ゴール設計が合わない ● 1つのスプリントで異なる施策 開発プロセス *スプリント:小さな単位で計画と実装を繰り返し、 少しずつ全体の完成度を高めていくというアプローチ *
  10. 10. t デザインプロセスの構築 連携しながらスピーディにバックログ を生み出すには? ScM 開発者 PO デザイナー ? * *バックログ:機能や改善が必要な ものに優先順位をつけてリスト化 したもの
  11. 11. t デザインプロセスの構築 デザインプロセスを開発プロセスから独立 PO、デザイナーが参加するデザインチームを作り、会議体やプロセスを設計 デザインチーム 開発チーム デザインプロセス PO デザイナー PO ScM 開発者
  12. 12. デザインチームの会議体設計 ペアワークや粗い段階でのフィードバックがしやすいように時間を確保 デザインプロセスの構築 UX モブ UX モブ UX モブ 月 火 水 木 金 UI モブ UX Mob ● 施策で解決する課題やターゲットユーザーを一緒に決めていく共同作業の時間 ● 構想や進捗を相談ベースで気軽に共有して受発注関係を避ける ● スピーディな情報共有により、合意・意思決定のスピードアップ Sync 振り返り バックログ リファインメント プランニング
  13. 13. デザインチームの会議体設計 ペアワークや粗い段階でのフィードバックがしやすいように時間を確保 デザインプロセスの構築 月 火 水 木 金 プランニング / バックログリファインメント / 振り返り ● 学びや気づきを活かしやすいよう、スクラムの形を採用 ○スプリントの始めにタスクを決めるプランニング ○スプリントの終わりに次のタスクを明確にするリファインメントや振り返り Sync UX モブ UX モブ UX モブ UI モブ 振り返り バックログ リファインメント プランニング
  14. 14. 開発チームとの合同会議体の設計 ペアワークや粗い段階でのフィードバックがしやすいように時間を確保 デザインプロセスの構築 振り返り 月 火 水 木 金 バックログ リファインメント Sync / UI Mob ● Sync では各チームの進捗や課題、リリース後の数値を共有 ● UI モブ では粗く作ったワイヤフレームを、開発メンバーとフラットに議論 ● デザイン・開発の橋渡しの部分でも受発注関係を避ける Sync UX モブ UX モブ UX モブ UI モブ プランニング
  15. 15. チーム間連携 各チームの会議体 各プロセスが交わる部分を大事にしつつ、それぞれの業務に集中できるように Daily Daily Daily Daily Daily 振り返り プランニング バックログ リファインメント デザイン 開発 UI モブ 月 火 水 木 金 Sync UX モブ UX モブ UX モブ バックログ リファインメント プランニング 振り返り
  16. 16. デザインプロセスの流れ 基本のデザインプロセスに習いつつ、施策の規模によって柔軟にアレンジ 現状理解 コンセプト UX/UI要件定義 ユーザー 要件定義 ワイヤ フレーム UI 1週間 デザインプロセス 1週間 フィード バック デザインプロセスの構築 一人で悩む時間や手戻りを減らし、リ ードタイムを短縮
  17. 17. 実施施策の例 17
  18. 18. 実施施策の例 4日間で課題発見〜リリースまで実施した事例 ユーザープロフィールページからの新規登録への移動率向上 施策概要 ?
  19. 19. 実施施策の例 4日間で課題発見〜リリースまで実施した事例 着手からリリースまでの流れ デザインチーム 開発チーム 1日目 仮説立て & インタビュー準備 効果計測の準備 2日目 インタビュー実施 & 課題の優先度づけ & ワイヤ作成 3日目 UI モブ → UI FIX & 開発 4日目 リリース
  20. 20. 仮説立て & インタビュー準備(デザイン) ● デザイナーがセルフユーザビリティチェックで現状課題の仮説を検討 ● 仮説をもとにインタビューを設計 1日目 どこが わかりにくそう? 実施施策の例 タイトルなどの 文章が わかりづらい? ボタンの色が 警告に見える?
  21. 21. ユーザー課題発見インタビュー(デザイン) ● 対象者:3名 ○ 実際のユーザーさんをリクルーティングする時間が取れないため、 社歴が浅く、かつ開発職ではない社内メンバーに率直な感想をインタビュー 2日目 実施施策の例 わかりにくい点や 不安に思う点は? ページの目的は 理解できる? 登録をためらう 要素はある? 迷うポイントは ある? もっとこうだったらい いな、はある?
  22. 22. 課題の優先度づけ & UI作成(デザイン) 2日目 セルフユーザビリティチェックでは見 えなかった課題が明らかに 実施施策の例 何ができるようになるのかす ぐにかわからない 隠されている部分が あると不信感がある ボタンが複数あると 迷いそう
  23. 23. 効果計測準備(開発) リリース後の効果計測に備えて、ログデータの抽出と可視化 1・2日目 実施施策の例 リリース後にすぐに結果を 計測できるように
  24. 24. UI モブ(ワイヤへのフィードバック)(合同) → 開発 3日目 ユーザー課題が 解決しそう? 開発時の 懸念はない? もっと良い表現は ある? 実施施策の例
  25. 25. UI FIX & 開発完了 3日目 実施施策の例
  26. 26. リリース 4日目 実施施策の例 理解に必要な情報を上 部に表示 情報を隠さず 出すことで 不安を取り除く 情報の優先度を 見直し
  27. 27. 理解に必要な情報を上 部に表示 情報を隠さず 出すことで 不安を取り除く 情報の優先度を 見直し 結果 登録へと進んだユーザーが 約 3 % UP! 実施施策の例
  28. 28. そのほかの成果 体制構築後のチーム成果 デザイン検討時間の短縮⬇︎ 施策リリース数の向上⬆️
  29. 29. そのほかの成果 体制構築後のチーム成果 ● デザインプロセスとが明確になった & 相談の場が増え手戻りが減った ● 「誰が何をいつまでにやる」のプランニング ● 「できていたか・課題はなかったか」の振り返り デザイン検討時間の短縮⬇︎ 施策リリース数の向上⬆️
  30. 30. 振り返り グロースチームの成果 ● チーム一丸となってユーザー主語の課題解決をし、 数値的な成果を上げられた ● 開発・デザインのチーム分割&スクラム導入で 施策リリース数の向上やデザイン検討時間の短縮に成功した
  31. 31. 振り返り この体制が作れた理由 ● 会社としてスクラム開発に取り組める土台があった ○ スクラムマスター・アジャイルコーチのアサインにより 慣れていないメンバーもリードしてもらうことができた ● チームメンバーの強い思いと理解があった ○ ユーザーの課題解決によるプロダクトグロースをしたい ○ 人間中心なデザインプロセスへの理解と実行
  32. 32. 順風満帆に聞こえたかもしれませんが、 試行錯誤やまだまだなところも。 チーム外への レビューどうする? もっと成果を 出したい 検証の効率化 ユーザーを知る方法が 限定的 振り返り 悩む時間も 多い
  33. 33. t UX / UI、チーム作りなど随時発信中です! ちょっと宣伝 note Podcast Coming Soon
  34. 34. パネルディスカッション 34
  35. 35. 従来の課題 パネルディスカッション 社内で実績のなかった アジャイルなデザインプロセスに 現場のデザイナーはスムーズに対応できたか? テーマ 1
  36. 36. 従来の課題 パネルディスカッション 施策に対する ユーザーからのフィードバック テーマ 2
  37. 37. 従来の課題 パネルディスカッション チームメンバーからの プロセスに対してのフィードバック テーマ 3
  38. 38. ありがとうございました 38

Editor's Notes

  • LT 始めます。
  • 仁科:一人ずつ簡単に自己紹介
  • 仁科
  • 仁科
  • 西口さん
    ・導入初期の
  • 西口さん
    ・導入初期の
  • 西口さん
    ・導入初期の
  • 以上、デザイナーと開発者でアジャイル開発しているお話でした。ありがとうございました。

×