Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
グロースするプロダクトの開発プロセスと関わり方
Search
shige0501
December 02, 2020
Technology
0
320
グロースするプロダクトの開発プロセスと関わり方
shige0501
December 02, 2020
Tweet
Share
More Decks by shige0501
See All by shige0501
モバイルアプリを効率的に開発するクロスプラットフォーム開発という選択肢
shige0501
1
400
2017/03/25 RxJava2 + OkHttp + Retrofit入門
shige0501
0
1.8k
Other Decks in Technology
See All in Technology
LangSmith×Webhook連携で実現するプロンプトドリブンCI/CD
sergicalsix
1
140
無意味な開発生産性の議論から抜け出すための予兆検知とお金とAI
i35_267
0
220
生成AI開発案件におけるClineの業務活用事例とTips
shinya337
0
160
ドメイン特化なCLIPモデルとデータセットの紹介
tattaka
1
290
急成長を支える基盤作り〜地道な改善からコツコツと〜 #cre_meetup
stefafafan
0
150
自律的なスケーリング手法FASTにおけるVPoEとしてのアカウンタビリティ / dev-productivity-con-2025
yoshikiiida
0
210
製造業からパッケージ製品まで、あらゆる領域をカバー!生成AIを利用したテストシナリオ生成 / 20250627 Suguru Ishii
shift_evolve
PRO
1
160
OPENLOGI Company Profile for engineer
hr01
1
33k
ひとり情シスなCTOがLLMと始めるオペレーション最適化 / CTO's LLM-Powered Ops
yamitzky
0
460
Oracle Cloud Infrastructure:2025年6月度サービス・アップデート
oracle4engineer
PRO
2
310
Microsoft Build 2025 技術/製品動向 for Microsoft Startup Tech Community
torumakabe
2
320
5min GuardDuty Extended Threat Detection EKS
takakuni
0
180
Featured
See All Featured
Measuring & Analyzing Core Web Vitals
bluesmoon
7
490
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
Fireside Chat
paigeccino
37
3.5k
Thoughts on Productivity
jonyablonski
69
4.7k
Facilitating Awesome Meetings
lara
54
6.4k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Why Our Code Smells
bkeepers
PRO
337
57k
It's Worth the Effort
3n
185
28k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
Practical Orchestrator
shlominoach
188
11k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.7k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Transcript
Chatwork Tech Talk #2 Chatwork株式会社 開発本部 グロースエンジニアリング部 エンジニア 重村 浩二(SHIGEMURA
Koji) グロースする プロダクトの開発プロセスと関わり方
自己紹介 重村 浩二(しげむら こうじ) Chatwork株式会社 開発本部 グロースエンジニアリング部 エンジニア Twitter: shige0501
山口県からフルリモートで働いてます(至5年) 最近の楽しみは今月届く 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
働くをもっと楽しく、創造的に