Chatwork Tech Talk #2 Chatwork株式会社 開発本部 グロースエンジニアリング部 エンジニア 重村 浩二(SHIGEMURA Koji) グロースする プロダクトの開発プロセスと関わり方

自己紹介 重村 浩二（しげむら こうじ） Chatwork株式会社 開発本部 グロースエンジニアリング部 エンジニア Twitter: shige0501 山口県からフルリモートで働いてます（至５年） 最近の楽しみは今月届く M1 Mac mini の到着です！ 2

01 我々はどこに注力するのか？ Chatworkの場合

グロースさせるには何が必要か？

グロースさせるには何が必要か サービス初期： 自分たちが最もChatworkを活用する利用者であるため、自分たちの欲しい機能がユー ザーの欲しい機能だった 5 サービスを作るわたしたち ユーザー =

グロースさせるには何が必要か 6 サービスを作るわたしたち ユーザー ≠ 現在： ユーザーの多様化

ユーザーの多様化で起きたこと ペルソナが複数存在するようになった ● Chatworkのシェア拡大とユーザー像の多様化 ○ 士業、介護・福祉、建設など、多種多様な利用シーンで使われるようになった ● 私たちの変化 ○ メインターゲットは中小企業（社員数は数名〜数十名）のお客様 ○ 私たちはマザーズに上場し、上場企業となった（社員数も 100名超え） 7 ユーザーが必要としているものは、 自分たちをベースに考えるだけでは答えが導き出せない

ではどうするか？

02 ユーザーの声を活かす フィードバックを活かした開発へ

ユーザーの声を活かす 10 ユーザーのフィードバック とアイデア 効果測定 テスト プロトタイプで フィードバック リリース 実装 データ収集 施策立案 P R D

ユーザーの声を活かす 11 ユーザーのフィードバックと アイデア 効果測定 テスト プロトタイプで フィードバック リリース 実装 データ収集 施策立案 エンジニア 主担当領域 P R D デザイナー 主担当領域 PM: プロダクトマネージャー PM 主担当領域

施策の立案は主にPMから 12 ユーザーのフィードバックと アイデア 効果測定 テスト プロトタイプで フィードバック リリース 実装 データ収集 施策立案 P R D ● ご意見・ご要望フォームからの送信 ● セールスが受けた意見 ● 社内のアイデア … etc これらを蓄積したデータベースをもとに、 PMが施策としてPRD (Product Requirement Document) を作成

プロトタイプで実装の方向性を早期に確認 13 ユーザーのフィードバックと アイデア 効果測定 テスト プロトタイプで フィードバック リリース 実装 データ収集 施策立案 P R D 以下の確認を目的に、まずはプロトタイプを作成してか ら本実装・レビューすることが多い ● 立案された施策が技術的に可能なものかどうかの 検証 ● UIの案がいくつか出てきたとき、実際に触れる状 態にしてみる エンジニアはクライアントサイド (Web / iOS / Android) も サーバーサイドも領域を決めずに対応を実施する

プロトタイプ〜実装の全体の流れ 14 実装 プロトタイプ 作成 チーム内で 施策に合う改善か 確認 本実装 エラーケースなど の考慮 コードレビュー テスト

PMとのコミュニケーションが発生するところ 15 実装 プロトタイプ 作成 チーム内で 施策に合う改善か 確認 本実装 エラーケースなど の考慮 コードレビュー テスト プロトタイプをもとに、施策の方向性にあった UI / 機能の深堀りを実施 特にUIはデザイナーから複数の案が提案される ため、実際に実装が可能かどうか、組んでみた 時のさわり心地が期待したものになりそうかどう かをプロトタイプでPM含めて確認してループさ せる

プラットフォームごとに違うリリース戦略 16 ユーザーのフィードバックと アイデア 効果測定 テスト プロトタイプで フィードバック リリース 実装 データ収集 施策立案 P R D リリースの仕方とタイミングがプラットフォームによって異なる （各プラットフォームを保守・運用しているチームのリリーススケ ジュールを考慮） ● WebであればA/Bテストがおこないやすいため、事前に A/Bテストを行うことが多い。 ● モバイルの場合はA/Bテストがやりにくい（リリースされた ら元にもどせない）ため、社内での検証メイン 上記を考慮の上、リリーススケジュールを PMと調整

リリースが終わってからが本番 17 ユーザーのフィードバックと アイデア 効果測定 テスト プロトタイプで フィードバック リリース 実装 データ収集 施策立案 P R D Treasure Dataにユーザーの操作に関するイベント を記録し、実施した施策の効果測定をおこなう Webの場合であれば得られた結果によって A/Bテス トの100%反映を実施するかの判断に利用する。 また、改善の必要があれば施策の見直しをおこなう エンジニアはイベント設計・実装やクエリによる抽出 部分で対応 PMが定義したKPIをもとに、適切なタイミングで イベントが取れるように実装

フィードバックループを回していく良い点と気をつけているところ ● 良い点 ○ 意思決定者（PM）、デザイナー、エンジニアが一つのチームにまとまってい るため、施策が進めやすい ● 気をつけているところ ○ 特にコミュニケーション部分 ■ PM、チームメンバーとのコミュニケーションももちろん重要 ■ 加えて、弊社は職能型チームと機能型チームが入り混じっている状態 ● グロースエンジニアリング部は機能型チーム ■ グロース施策を動かしていく上で、保守・運用をしている職能型チームに 与える影響を施策実施前に共有していくことで、職能型チーム側が進めて いる対応との間でコンフリクトなどが発生しないように注意している 18

まとめ ● Chatworkの小さな改善はユーザーの声から ○ どれを選ぶことがユーザーの価値につながるかは、PMが判断 ● エンジニアは、施策の実現可能性の高い方法を提案 ○ プロトタイプで早めに触れるようにして方針決定の手助け ● そして施策の効果を検証していく仕組みの構築を実施 ○ KPIを追うために必要な情報を収集していく仕組みの箇所の仕込み 19

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