More Related Content
Similar to Product managershouldask mvp (20)
More from Tanaka Yuichi (13)
Product managershouldask mvp
- 2. Confidential
2
自己紹介
• 金融系 -> 組み込み系 -> Web(Ad, SNS, Game)
-> BigData, ML -> Vendor -> FinTech
• フロントからインフラまでが得意、Hadoop/Spark
系, あとMLあたり。デザインは無理ぽ。
• Apache Spark周りでいくつか著書あります。お小
遣いください。
• Web記事もいくつかあります。お小遣い(ry
- 8. Confidential
8
チームカラーの意識 2
得意な言語/やりたい言語/やったことある言語がバラバラ
レイヤの違いによるスキル差異(インフラ寄り、ミドル寄り、サー
バー寄り、フロント寄り)
オンプレ / クラウド
Ansible / Chef
Jenkins / CircleCI
SQL(MySQL / Postgre) / NoSQL (Mongo / Couch)
MVC / UCDD / (Clean Architecture)
jQuery / Vue.js / React + Redux
背景職の違いによる「良いシステム開発」の違い
Ad, Game, Webはスケーラビリティ・速度重視
OSS系は構造や安定性を重視
金融系はDocumentや安全性を重視
- 12. Confidential
12
重要視したこと諦めたこと(合意の方向性)
プロモーション / 広告流入時期 ~
それでもリリースを最優先
Unitは諦める、結合・機能テスト側でカバー
基本的にUnitは書く、個々の粒度で。無くてもOK
お金に絡む部分は書く。
ただしSkipリリースをすることもある
MVCを一旦意識する。
個々Approveした上で、commentは残していく。
リファクタは個々の時間の範疇で行う。
インフラのスケーラビリティ
Web/APIなどはスケール可能にする。
アジャイル(スプリントMTG)を諦める
認識合わせの為のチーム内勉強会を週1で取るようにする
- 13. Confidential
13
チームで成長のためにやっていること、今のフェーズ
~ 今
まだリリースを最優先
新規部分についてUnit, MVCを意識する
明らかにおかしいものはどう直して欲しいかを記述
マイクロサービス化進めて部分的な再構築を始める
勉強会の中で質についての会を増やす
週1日リモートワークの日を作る
Wikiにdocument化を一部進める
課題
仕様のサイロ化進んで知らない機能が増えてる
初期と違う仕様が多く、モンキーパッチが目立ってきた
エンジニアの稼働が高い
チケット着る側・仕様を詰める側がボトルネックになってきた
- 16. Confidential
16
The Wizard of Oz
の前にMVP(検証可能な必要最低限のプロダクト)とは
実際にユーザーにサービスを提供し、それがユーザーに利用さ
れるまではただの仮説で、提供者の都合の良い思い込みである。
であるから、ユーザーに必要最低限の機能をまず提供し、その
フィードバックを得て仮説検証を行いサービスを適宜方向調整
することで、余計な開発コストの削減やプロダクトマーケト
フィットを目指す手法。Wizard of Oz(オズの魔法使い)もそ
の手法の一つ。タイムバンクでは一部意図してWizard of Ozと
スモークテストを行ってます。
Wizard of Ozとは
本来システム化されている(ように見える)フロントプロダクトを、
実際は生身の人間が手動で操作することで初期開発費用(期間)を
大幅に削減し、システム化のリスクを回避する手法。
要は、人が頑張ってる状態
- 19. Confidential
19
具体例) イベントの施策と開発例 ※あくまで架空の例です
要件:
ユーザーの売り注文に対し、買い注文の絶対数が少なく(事実)ユーザーの買い
控えにつながっているのではないか?(仮説1)また、市場全体の価格が上昇す
ることで、セカンドバイの心理的障壁が薄れるのではないか?(仮説2)
検証:
買い注文に対してランキングを作成し、上位者にインセンティブを付与することによって、
ユーザーの買い注文が増え(検証1)、市場全体の価格が上昇し(検証2)、心理的な障壁
が薄れるか?(検証3)
開発に必要なもの:
ランキングを表示するページ
ランキングに参加するページ
ランキングを計算するbatch
イベント期間を管理するテーブル
ランキングを格納するテーブル
ランキング参加者を格納するテーブル
インセンティブを付与する機能
イベントの作成・変更管理機能
ランキング参加者の管理機能
不正検知機能
だいたい二週間〜三週
間後に開催可能なイベ
ント
- 20. Confidential
20
具体例) イベントの施策と開発例2 ※あくまで架空の例です
検証可能かどうか?:
測定可能か?
その検証項目は定量的か?
定量的に判断するデータは取得しているか?
比較対象のデータはあるか?
短期か長期か?
短期的に検証可能な項目か?
検証:
買い注文に対してランキングを作成し、上位者にインセンティブを付与することによって、ユーザーの買い
注文が増え(検証1)、市場全体の価格が上昇し(検証2)、心理的な障壁が薄れるか?(検証3)
検証3は定性的であり、定性->定量化が必要
心理的な障壁が定量的に表される数値ってなに?
どのように計測するの?
どのようにデータ取得するの?
判断:
検証可能なようにディスカッションし、定量化を行う
聞かなかったことにする
ディスカッションは最も工数が重たい作業
特にデータ分析において新たな軸(心理的表現)を探るパターンは意味消失するか、
限定的な解釈が可能になる程度なので工数に対して効果が見込めないので避けるのも
あり!
- 21. Confidential
21
具体例) イベントの施策と開発例3 ※あくまで架空の例です
ランキングを表示するページ
ユーザーが見るページなので必要
ランキングに参加するページ
そもそも入り口の動線なので必須
ランキングを計算するbatch
ぼくが2じかんおきくらいにSQLたたく
イベントを管理するテーブル
直接Controllerにでもかいとけばおけ
ランキングを格納するテーブル
表示するデータなんで必要
ランキング参加者を格納するテーブル
流石に参加管理は必要
インセンティブを付与する機能
イベント終了後、まとめて付与
イベントの作成・変更管理機能
継続的にやるなら作る
ランキング参加者の管理機能
継続的にやるなら作る
不正検知機能
悩むけどMVPなら外してもOK
だいたい一週間弱で開
催が可能
開催中に並行で実装
可能
検証を待ってから実装
この部分とこの部分は手で頑張る!!!
(オズの魔法使いにぼくはなる!)
- 22. Confidential
22
失敗したと思っている例 ※あくまで架空の例です
イベントを定常化後、インセンティブを変更して再度検証を繰り返したケース
ランキングを表示するページ
ユーザーが見るページなので必要、アレンジでいける
ランキングに参加するページ
そもそも入り口の動線なので必須、これもアレンジでいける
ランキングを計算するbatch
バッチもアレンジでいける!
イベントを管理するテーブル
すでに定常イベント済みなのでflg追加でウハウハ
ランキングを格納するテーブル
表示するデータなんで必要、すでにある
ランキング参加者を格納するテーブル
流石に参加管理は必要、これもある
インセンティブを付与する機能
インセンティブが変更になったので、大幅に回収必要!
自動的に付与していたものを、イベント終了後、手動でまとめて付与する対応
イベントの作成・変更管理機能
すでにある
ランキング参加者の管理機能
これもある
不正検知機能
そうそうに対応したのである!
Editor's Notes
- 現在:
Ruby, Node.js, Python
AWS
常時のメンバ:
サーバー3
アプリ 2
外部 2
Temp 3
実験的な機能リリースと
- Yesのあなたは20分ゆっくり寝てましょう。多分今日のお話で学ぶことはないです。
Android 諦めました。
- Yesのあなたは20分ゆっくり寝てましょう。多分今日のお話で学ぶことはないです。
Android 諦め
エンジニア論の違い
なんの言語を得意とするのか?
バックエンドにどういう経験があるのか?
Game/Web/Adはスケーラビリティを重視
OSS系は構造や安定性を重視
金融系はDocumentと構造、安全性を重視
- Yesのあなたは20分ゆっくり寝てましょう。多分今日のお話で学ぶことはないです。
Android 諦め
エンジニア論の違い
なんの言語を得意とするのか?
バックエンドにどういう経験があるのか?
Game/Web/Adはスケーラビリティを重視
OSS系は構造や安定性を重視
金融系はDocumentと構造、安全性を重視
- MVP(Minimum Viable Product)
- MVP(Minimum Viable Product)
- MVP(Minimum Viable Product)
- ユーザー体験を損ねるものは