Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Chatworkの継続的な改善を支えるプロダクトマネジメント

Hayato Ishida
December 02, 2020

 Chatworkの継続的な改善を支えるプロダクトマネジメント

Hayato Ishida

December 02, 2020
Tweet

More Decks by Hayato Ishida

Other Decks in Technology

Transcript

  1. 2 Chatwork株式会社 プロダクトマネジメント室 マネージャー 来歴 2012年 米国でユーザーテスト会社を学生起業 2015年 Chatworkの米国支社に入社 2017年

    東京支社に転籍しプロダクトマネージャーに就任 2019年 プロダクトマネジメント室 マネージャーに 石田 隼 Hayato Ishida 自己紹介
  2. 開発プロジェクトの種類 5 2ヶ月以上の開発 2週間単位の開発 大 小 ロードマップの中-大規模の開発PJと、短期的に価値提供をする小規模開発にわかれる ロードマップ案件 期初に策定した機能 プロジェクト単位でチーム作り

    要件決めに2週間~1ヶ月 開発に2~6ヶ月 ユーザー告知をしっかり グロース施策や小規模開発 都度ユーザーFBやデータから検討 同じチームで取り組む 要件決めに1日~1週間 開発に1週間~3週間 ユーザー告知しないこともある
  3. 開発プロジェクトの種類 6 2ヶ月以上の開発 2週間単位の開発 大 小 ロードマップの中-大規模の開発PJと、短期的に価値提供をする小規模開発にわかれる ロードマップ案件 期初に策定した機能 プロジェクト単位でチーム作り

    要件決めに2週間~1ヶ月 開発に1~3ヶ月 ユーザー告知をしっかり グロース施策や小規模開発 都度ユーザーFBやデータから検討 同じチームで取り組む 要件決めに1日~1週間 開発に1週間~3週間 ユーザー告知しないこともある
  4. なぜ小さな改善は必要なのか? 小さな改善を通してUX Debt(=UX負債)を返済し、プロダクト価値を安定させる 9 Functional Reliable Usable Pleasurable Aaron Walter’s

    Hierarchy of User Needs 今の機能品質 理想とする品質 UX Debt 品質 ①初期の機能スコープによるもの リソースや時間などの制約の上で、スコープ判 断をするため、初期のリリースで完璧な機能を リリースできることはほぼない ②ユーザーニーズの変化によるもの ユーザーの増加や外部環境の変化により、常に ニーズは変化していく ③サービスへの期待値の変化によるもの サービスの認知が広がるにつれて、期待値が高 まり、より高い品質を求められる UX Debtが生まれる理由
  5. なぜ小さな改善は必要なのか? 小さな改善を通してUX Debt(=UX負債)を返済し、プロダクト価値を安定させる 10 Functional Reliable Usable Pleasurable Aaron Walter’s

    Hierarchy of User Needs 今の機能品質 理想とする品質 UX Debt 品質 ①初期の機能スコープによるもの リソースや時間などの制約の上で、スコープ判 断をするため、初期のリリースで完璧な機能を リリースできることはほぼない ②ユーザーニーズの変化によるもの ユーザーの増加や外部環境の変化により、常に ニーズは変化していく ③サービスへの期待値の変化によるもの サービスの認知が広がるにつれて、期待値が高 まり、より高い品質を求められる UX Debtが生まれる理由
  6. 小さな改善の歴史 12 3Q 4Q 1Q 2Q 3Q 4Q 1Q 2Q

    3Q 4Q 2018 2019 2020 グロースエンジニ アリング室設置 ユニット化 (機能別) ユニット化 (KPI別) 組 織 仕 組 み ユニット 解散 定期的な見直しと人の異動 PM&デザイナー ペア企画体制 QPRD開始 QPRD運用 簡易的な起案のフレームとして維持 改善の仕組みづくりにトライ (5%ルール/トマソン etc) PRD継続 職能別 x ロードマップ x GE室 PRD開始 フィードバック管理の見直し
  7. 小さな改善の歴史 13 3Q 4Q 1Q 2Q 3Q 4Q 1Q 2Q

    3Q 4Q 2018 2019 2020 グロースエンジニ アリング室設置 ユニット化 (機能別) ユニット化 (KPI別) 組 織 仕 組 み ユニット 解散 定期的な見直しと人の異動 PM&デザイナー ペア企画体制 QPRD開始 QPRD運用 簡易的な起案のフレームとして維持 改善の仕組みづくりにトライ (5%ルール/トマソン etc) PRD継続 職能別 x ロードマップ x GE室 PRD開始 フィードバック管理の見直し 仕組みは作った けど、体制がな くて進まない
  8. 小さな改善の歴史 14 3Q 4Q 1Q 2Q 3Q 4Q 1Q 2Q

    3Q 4Q 2018 2019 2020 グロースエンジニ アリング室設置 ユニット化 (機能別) ユニット化 (KPI別) 組 織 仕 組 み ユニット 解散 定期的な見直しと人の異動 PM&デザイナー ペア企画体制 QPRD開始 QPRD運用 簡易的な起案のフレームとして維持 改善の仕組みづくりにトライ (5%ルール/トマソン etc) PRD継続 職能別 x ロードマップ x GE室 PRD開始 フィードバック管理の見直し
  9. 小さな改善の歴史 15 3Q 4Q 1Q 2Q 3Q 4Q 1Q 2Q

    3Q 4Q 2018 2019 2020 グロースエンジニ アリング室設置 ユニット化 (機能別) ユニット化 (KPI別) 組 織 仕 組 み ユニット 解散 定期的な見直しと人の異動 PM&デザイナー ペア企画体制 QPRD開始 QPRD運用 簡易的な起案のフレームとして維持 改善の仕組みづくりにトライ (5%ルール/トマソン etc) PRD継続 職能別 x ロードマップ x GE室 PRD開始 フィードバック管理の見直し 適切な優先度で改 善ができない
  10. 小さな改善の歴史 16 3Q 4Q 1Q 2Q 3Q 4Q 1Q 2Q

    3Q 4Q 2018 2019 2020 グロースエンジニ アリング室設置 ユニット化 (機能別) ユニット化 (KPI別) 組 織 仕 組 み ユニット 解散 定期的な見直しと人の異動 PM&デザイナー ペア企画体制 QPRD開始 QPRD運用 簡易的な起案のフレームとして維持 改善の仕組みづくりにトライ (5%ルール/トマソン etc) PRD継続 職能別 x ロードマップ x GE室 PRD開始 フィードバック管理の見直し
  11. 小さな改善を継続するための3つの要素 18 どれか1つでもかけたら、小さな改善の”継続”が難しくなる 体制 プロセス ゴール 兼務ではなく、小さな改善をお こなうことを責務とするチーム 改善の種を企画にし、意思決定 し、開発を推進するプロセス

    小さな改善をすることで、会 社として達成したいゴール 多能的なチーム 高い自主性 明確な役割の定義 フィードバック収集 データ分析 起案・企画 開発優先度 KPI策定 状態目標 必要な要素 必要な要素 必要な要素
  12. よくあるパターン 19 体制はないけど、プロセスとゴールだけある 専任 チーム プロセス ゴール 兼務ではなく、小さな改善を 行うことを責務とするチーム 改善の種を企画にし、意思決定

    し、開発を推進するプロセス 小さな改善をすることで、会 社として達成したいゴール 多能的なチーム 高い自主性 明確な役割の定義 フィードバック収集 データ分析 起案・企画 開発優先度 KPI策定 状態目標 必要な要素 必要な要素 必要な要素 初期のQuick PRD 会社やチームで定めた目標 に対して、なんとか達成す るために現場でプロセスを 設計するパターン 起こりうること Chatworkでの例 明確な体制がないので、誰かが兼 務で担当するが、優先度が上がり きらず推進できなくなる
  13. よくあるパターン 20 体制は作ったが、プロセスの設計を怠ったパターン 体制 プロセス ゴール 兼務ではなく、小さな改善をお こなうことを責務とするチーム 改善の種を企画にし、意思決定 し、開発を推進するプロセス

    小さな改善をすることで、会 社として達成したいゴール 多能的なチーム 高い自主性 明確な役割の定義 フィードバック収集 データ分析 起案・企画 開発優先度 KPI策定 状態目標 必要な要素 必要な要素 必要な要素 過去の〇〇委員会や〇〇チーム ゴールに対して課題を感じ た役員がトップダウンで専 任チームをつくるパターン 起こりうること Chatworkでの例 プロセスがないので、開発スピー ドが上がらなかったり、思うよう にアウトプットが出ない
  14. よくあるパターン 21 体制とプロセスはあるのに、ゴールがあいまい 体制 プロセス ゴール 兼務ではなく、小さな改善をお こなうことを責務とするチーム 改善の種を企画にし、意思決定 し、開発を推進するプロセス

    小さな改善をすることで、会 社として達成したいゴール 多能的なチーム 高い自主性 明確な役割の定義 フィードバック収集 データ分析 起案・企画 開発優先度 KPI策定 状態目標 必要な要素 必要な要素 必要な要素 初期のユニット組織 チームの規模に対して担 うゴール多すぎパターン か、目的が曖昧パターン 起こりうること Chatworkでの例 ゴールや存在意義が不明確なの で、徐々になぜやっているかを見 失い、体制が形骸化する
  15. 小さな改善を継続するための3つの要素 22 どれか1つでもかけたら、小さな改善の”継続”が難しくなる 体制 プロセス ゴール 兼務ではなく、小さな改善をお こなうことを責務とするチーム 改善の種を企画にし、意思決定 し、開発を推進するプロセス

    小さな改善をすることで、会 社として達成したいゴール 多能的なチーム 高い自主性 明確な役割の定義 フィードバック収集 データ分析 起案・企画 開発優先度 KPI策定 状態目標 必要な要素 必要な要素 必要な要素
  16. 体制 - グロースエンジニアリング室の設置 25 背景 • 開発本部内にチームを設置すると、本部経由の目標とPM経由の目標でバッティングする • ロードマップや差し込み案件が優先され、小さな改善へのリソースが確保できない 役割

    • ユーザーグロースに関わる改善施策の開発 • ロードマップに乗らない小規模な改善の開発 ルール • 何があってもロードマップや、差し込み案件 にチームリソースを割り当てない CEO CTO W e b モ バ イ ル デ ザ イ ン サ | バ | G E 室 P M 室 開発本部
  17. プロセス - Airtableによるフィードバックの一元管理 26 昔 今 PM 収集に時間がか かる リスト化&スコアリング

    施策をピックアップし、 PRDを作る スコアリングに時 間がかかる フィードバックを収集 施策検討までに時 間がかかる Airtableに集約し、定期的にPMとデザ イナーでスコアリングをおこなうこと で、少ない手間で改善リストを作る
  18. ゴール - 優先度の決定とKPIへのブレイクダウン 27 UX 低 UX 高 ビジネス 低

    ビジネス 高 2 ビジネスインパクトが大 きく、UXも改善される施 策 1 ビジネスインパクトは大 きいが、UX毀損があ る、またはUX改善には つながらない施策 4 ビジネスインパクトは低 いが、ユーザーニーズ が高く、UXの改善が見 込める施策 3 ビジネスインパクトが低 く、UXの改善にもつなが らない 1と4の優先度を決める ビジネス価値とユーザー価値のどちらを求 められているステージなのか? UX改善の場合の指標 ・NPS ・改善デリバリー数 ・改善対象となる機能の利用率 グロースの場合の指標 ・アクティブ指標 ・有料転換率 ・ARPU