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
330
グロースするプロダクトの開発プロセスと関わり方
shige0501
December 02, 2020
Tweet
Share
More Decks by shige0501
See All by shige0501
モバイルアプリを効率的に開発するクロスプラットフォーム開発という選択肢
shige0501
1
410
2017/03/25 RxJava2 + OkHttp + Retrofit入門
shige0501
0
1.8k
Other Decks in Technology
See All in Technology
CDK CLIで使ってたあの機能、CDK Toolkit Libraryではどうやるの?
smt7174
4
190
2025/09/16 仕様駆動開発とAI-DLCが導くAI駆動開発の新フェーズ
masahiro_okamura
0
120
roppongirb_20250911
igaiga
1
240
react-callを使ってダイヤログをいろんなとこで再利用しよう!
shinaps
2
260
まずはマネコンでちゃちゃっと作ってから、それをCDKにしてみよか。
yamada_r
2
120
AIエージェントで90秒の広告動画を制作!台本・音声・映像・編集をつなぐAWS最新アーキテクチャの実践
nasuvitz
3
340
RSCの時代にReactとフレームワークの境界を探る
uhyo
10
3.5k
Create Ruby native extension gem with Go
sue445
0
120
AWSで始める実践Dagster入門
kitagawaz
1
730
20250912_RPALT_データを集める→とっ散らかる問題_Obsidian紹介
ratsbane666
0
100
これでもう迷わない!Jetpack Composeの書き方実践ガイド
zozotech
PRO
0
1.1k
テストを軸にした生き残り術
kworkdev
PRO
0
210
Featured
See All Featured
Testing 201, or: Great Expectations
jmmastey
45
7.7k
RailsConf 2023
tenderlove
30
1.2k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
A Modern Web Designer's Workflow
chriscoyier
696
190k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
The Straight Up "How To Draw Better" Workshop
denniskardys
236
140k
BBQ
matthewcrist
89
9.8k
How to Ace a Technical Interview
jacobian
279
23k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
30
9.7k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
jQuery: Nuts, Bolts and Bling
dougneiner
64
7.9k
Balancing Empowerment & Direction
lara
3
620
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
働くをもっと楽しく、創造的に