Chatwork Tech Talk Chatwork株式会社 プロダクトマネジメント室　マネージャー 石田 隼 Chatworkの継続的な改善を支える プロダクトマネジメント

2 Chatwork株式会社 プロダクトマネジメント室 マネージャー 来歴 2012年 米国でユーザーテスト会社を学生起業 2015年 Chatworkの米国支社に入社 2017年 東京支社に転籍しプロダクトマネージャーに就任 2019年 プロダクトマネジメント室 マネージャーに 石田 隼 Hayato Ishida 自己紹介

改めて、今日のテーマ Chatworkの継続的な改善を支えるプロダクトマネジメント 3

開発プロジェクトの種類

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

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

Chatwork、変わってないように見えるけど？ 7 2020年11月までで、ロードマップPJとバグfixなどを覗いた機能改善の数 ファイル送信時の表示UI改善 ToALLの通知人数表示改善 ファイルのソート機能 Toと絵文字選択UX改善 引用内To/ToALLの通知改善 タスクがない場合の概要欄の自動拡張　etc ６ ３ リリース

なぜ継続的な小規模改善が必要なのか？

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

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

Chatworkにおける小規模改善の歴史

小さな改善の歴史 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開始 フィードバック管理の見直し

小さな改善の歴史 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開始 フィードバック管理の見直し 仕組みは作った けど、体制がな くて進まない

小さな改善の歴史 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開始 フィードバック管理の見直し

小さな改善の歴史 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開始 フィードバック管理の見直し 適切な優先度で改 善ができない

小さな改善の歴史 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開始 フィードバック管理の見直し

継続するための3つの要素

小さな改善を継続するための３つの要素 18 どれか1つでもかけたら、小さな改善の”継続”が難しくなる 体制 プロセス ゴール 兼務ではなく、小さな改善をお こなうことを責務とするチーム 改善の種を企画にし、意思決定 し、開発を推進するプロセス 小さな改善をすることで、会 社として達成したいゴール 多能的なチーム 高い自主性 明確な役割の定義 フィードバック収集 データ分析 起案・企画 開発優先度 KPI策定 状態目標 必要な要素 必要な要素 必要な要素

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

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

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

小さな改善を継続するための３つの要素 22 どれか1つでもかけたら、小さな改善の”継続”が難しくなる 体制 プロセス ゴール 兼務ではなく、小さな改善をお こなうことを責務とするチーム 改善の種を企画にし、意思決定 し、開発を推進するプロセス 小さな改善をすることで、会 社として達成したいゴール 多能的なチーム 高い自主性 明確な役割の定義 フィードバック収集 データ分析 起案・企画 開発優先度 KPI策定 状態目標 必要な要素 必要な要素 必要な要素

Chatworkでの取り組み

3つの要素におけるChatworkでの取り組み 24 体制 開発本部から切り離したPM付けの小さな改善の専任チームを設立 プロセス ユーザーフィードバックの管理環境のアップデート ゴール 戦略に基づく優先順位付けとKPIへのブレイクダウン

体制 - グロースエンジニアリング室の設置 25 背景 ● 開発本部内にチームを設置すると、本部経由の目標とPM経由の目標でバッティングする ● ロードマップや差し込み案件が優先され、小さな改善へのリソースが確保できない 役割 ● ユーザーグロースに関わる改善施策の開発 ● ロードマップに乗らない小規模な改善の開発 ルール ● 何があってもロードマップや、差し込み案件 にチームリソースを割り当てない CEO CTO W e b モ バ イ ル デ ザ イ ン サ | バ | G E 室 P M 室 開発本部

プロセス - Airtableによるフィードバックの一元管理 26 昔 今 PM 収集に時間がか かる リスト化＆スコアリング 施策をピックアップし、 PRDを作る スコアリングに時 間がかかる フィードバックを収集 施策検討までに時 間がかかる Airtableに集約し、定期的にPMとデザ イナーでスコアリングをおこなうこと で、少ない手間で改善リストを作る

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

まとめ

まとめ Chatworkでは、安定した品質でプロダクト価値を提供するために、 小さな改善を通して、継続してUX負債を返済することに取り組んでいます。 継続して改善を行うためには、適切な、体制・プロセス・ゴールが必要で、 改善に特化した専任チームを作り、PRDの徹底とユーザーフィードバックの管理 方法を改善することで、企画プロセスを最適化しました。また、事業戦略に基づ き、UX価値と事業価値のどちらを優先するかの判断を行った上で、改善サイクル を回しています。 29

働くをもっと楽しく、創造的に