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
240
グロースするプロダクトの開発プロセスと関わり方
shige0501
December 02, 2020
Tweet
Share
More Decks by shige0501
See All by shige0501
モバイルアプリを効率的に開発するクロスプラットフォーム開発という選択肢
shige0501
1
320
2017/03/25 RxJava2 + OkHttp + Retrofit入門
shige0501
0
1.7k
Other Decks in Technology
See All in Technology
長文から長文を生成するLLMツールをオープンソースで作ってみた。
tomohisa
2
150
Tohoku.Tech #1 「EC-CUBE/AWSの構築をChatGPTに相談してみました」by テンダ
jun2882
0
140
サービス成長と共に肥大化するモノレポ、長くなるCI時間 / As services grow, monorepos get bigger and CI time gets longer
kohbis
5
2.1k
家族アルバム みてねで直面してきた技術的負債 / MIXI KAG 2024
isaoshimizu
17
7.7k
MongoDB Atlas Vectorsearchではじめる生成AIアプリ開発
chie8842
3
510
現実世界の事象から学ぶSOLID原則
h0r15h0
24
10k
KTC_DBRE.pdf
_awache
1
290
単回帰分析について数式を追いながら実装してみた
kentaitakura
0
500
Why do you get AWS certificates
hirosys
0
110
Tohoku.Tech #1 「Cursorを使ったRaspberry Piの開発」by ねこまた
jun2882
0
250
Azureコストは水道代/The_47th_Tokyo_Jazug
aeonpeople
3
380
戦略的DDDを実践するための跳躍力 / OOC 2024
pictiny
6
4.1k
Featured
See All Featured
The Invisible Side of Design
smashingmag
293
49k
Pencils Down: Stop Designing & Start Developing
hursman
115
11k
The Cult of Friendly URLs
andyhume
73
5.6k
Fantastic passwords and where to find them - at NoRuKo
philnash
35
2.4k
Teambox: Starting and Learning
jrom
126
8.4k
What’s in a name? Adding method to the madness
productmarketing
PRO
14
2.6k
Build your cross-platform service in a week with App Engine
jlugia
223
17k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
39
4.3k
For a Future-Friendly Web
brad_frost
170
8.9k
Adopting Sorbet at Scale
ufuk
66
8.5k
Clear Off the Table
cherdarchuk
82
310k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
219
21k
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
働くをもっと楽しく、創造的に