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
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
9
73k
LLMを搭載したプロダクトの品質保証の模索と学び
qa
0
1.1k
AI時代を生き抜くエンジニアキャリアの築き方 (AI-Native 時代、エンジニアという道は 「最大の挑戦の場」となる) / Building an Engineering Career to Thrive in the Age of AI (In the AI-Native Era, the Path of Engineering Becomes the Ultimate Arena of Challenge)
jeongjaesoon
0
140
Android Audio: Beyond Winning On It
atsushieno
0
850
要件定義・デザインフェーズでもAIを活用して、コミュニケーションの密度を高める
kazukihayase
0
110
Platform開発が先行する Platform Engineeringの違和感
kintotechdev
4
570
react-callを使ってダイヤログをいろんなとこで再利用しよう!
shinaps
1
240
AIエージェント開発用SDKとローカルLLMをLINE Botと組み合わせてみた / LINEを使ったLT大会 #14
you
PRO
0
120
roppongirb_20250911
igaiga
1
240
Webアプリケーションにオブザーバビリティを実装するRust入門ガイド
nwiizo
7
830
企業の生成AIガバナンスにおけるエージェントとセキュリティ
lycorptech_jp
PRO
2
170
DroidKaigi 2025 Androidエンジニアとしてのキャリア
mhidaka
2
270
Featured
See All Featured
Why Our Code Smells
bkeepers
PRO
339
57k
Rails Girls Zürich Keynote
gr2m
95
14k
Designing Experiences People Love
moore
142
24k
Embracing the Ebb and Flow
colly
87
4.8k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
131
19k
Reflections from 52 weeks, 52 projects
jeffersonlam
352
21k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
9
810
4 Signs Your Business is Dying
shpigford
184
22k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
Scaling GitHub
holman
463
140k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
8
520
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.9k
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
働くをもっと楽しく、創造的に