MNTSQ社内勉強会 #1 スタートアップの開発サイクルを調べてみた

Transcript

1. スタートアップの開 発サイクルを調べ てみた MNTSQ Product Management 社内勉強会 2022.03.11 #1
2. MNTSQ 2 今日話してみたいこと
 • プラクティスが公開されていたスタートアップ三社の開発サイクルを元 に学びを得たい
 ◦ SmartHR、Hey、Dely
 ◦ ざっくり眺めてみるだけでも学びがあるのではないか
 
 • それを踏まえた上で、MNTSQの開発サイクルの改善ポイントをカジュ アルにディスカッションしたい

3. MNTSQ 3 SmartHR社
 https://tech.smarthr.jp/entry/2021/06/16/115550 Key Finding
 • Issue管理にはProductboardというSaaSを活用している
 • 要望は同じものを何回も起票できる（どの機能にどれくらい要望がきているか把握可能）
 • 要望を解説する会でドメインエキスパートがPMやPMMに要望をひとつひとつレクチャー
 ◦ PMから「なぜ優先度をあげられないか」を説明していたりもする
 • ロードマップモム会では各部門代表が揃い、閲覧は自由（１２０人くらい参加するらしい）
 • PRDはProduct Requirements Documentの略で、機能要件のためのDocument
 ◦ うちだと仕様SSoTに相当しそう
 • バザールは不定期に開催される社内フィードバック会：MNTSQのロープレ会に相当

4. MNTSQ 4 SmartHR社（プラスアプリ）
 https://tech.smarthr.jp/entry/2021/06/16/115550 Key Finding
 • SmartHRの一部アプリの開発はもう少しシンプル
 
 気になる
 • Productboardからバックログへの起票が二度手間にならないか

5. MNTSQ 5 参考：productboard
 https://www.productboard.com/ Key Finding
 • 組織サイズが大きくなると、Integrationのbenefitが大きい気がする
 ◦ 例えばCSがZendeskで来たような質問をGitHubに起票する手間がなくなるとか
 ◦ GitHubの使い方をSales, CSに教えなくとも、ツールによって上手く変換できるということか
 ◦ 今のMNTSQの組織サイズ（４０名弱）でどこまで有効かはわからない

6. MNTSQ 6 https://note.com/miyahirok/n/n57218102a63a Key Finding
 • お急ぎ便なるコースがある
 • 仮説リスト、ロードマップ、プロダクトバックログを分けて管理している
 • リリース結果の検証・効果測定の振り返りから仮説リストにフィードバックする
 ◦ MNTSQにの使われ方分析的な仕組みだろうか
 • bugbashをやっている（bug発掘に特化したMNTSQのロープレ会）
 • VOC定例というBizサイドでカジュアルにアイデアをためていく会をやっている
 Hey社　(STORES 予約)

7. MNTSQ 7 https://tech.dely.jp/entry/2018/12/24/170000 Dely社
 Key Finding
 • 要件定義のフェーズ（デザインフェーズ）と実装を分離
 ◦ 要件定義フェーズにおいて機能価値検証、ユーザビリティーテストを行っている
 • アイディア出しはPO/PM、デザイナー、エンジニアががっつり時間を使って会議
 • プロトタイプはペーパープロトタイプ、Sketchのワイヤーフレーム、ときどきXcodeで動くプロトタイプまで 作っている（しかもUI設計は更にまた後のフェーズにある）
 • 実装フェーズにいったらデザインフェーズには戻らない（デザインにコミットしている）
 気になる
 • 機能に大小あると思うけど、細かいところまでこのやり方でやりきっているわけではなさそう

8. MNTSQ 8 三社を見比べて思ったこと
 • （当然ながら）作るもの、チームサイズ、顧客数、達成したいスピード感によって 最適なやり方は違いそう
 ◦ SmartHR（ドメイン特化 toB)とDely（toC)では作り方が異なる
 ▪ Delyはデザインの完成度に注力："デザインは1px単位で詰める"
 ▪ SmartHRは各ファンクション間の意思疎通に注力
 • データ的にMNTSQがやっていないのは「仮説リスト」くらいであり、他はだいた い同じ
 ◦ バックログ（GitHub Issue）
 ◦ ロードマップ（短期＆長期のスケジュールSSoT)
 ◦ PRDは一部重要なものだけ (開発仕様SSoT)
 ◦ 事業戦略（Master Plan＆ありたい姿md）
 • 会議体として、SmartHRの「要望を解説する会」のようなものはあってもよいの かもしれない
 ◦ 現状はIssueに文字で書き下しているが、微妙なニュアンスや前提知識の ずれなどは同期的にやったほうが擦り合う可能性ありそう
 • 開発に関わらない質問的なやりとりをどうさばいているのかも知りたい

9. MNTSQ 9 MNTSQ社は今こんな感じ、改善の余地はいろいろありそう？
 MasterPlan
 ドメイン別
 ありたい姿
 スケジュール
 SSoT（長期）
 開発仕様SSoT
 開発Issues
 Biz<->Product
 Product
 Team Dev
 Members
 Portal Issues
 具体化
 issue
 raise
 PR
 PR
 参照
 スケジュールSSoT（短 期）
 参照
 具体化
 詳細化
 issue
 raise
 開発決定
 pdm sync
 振り分け
 一部を
 詳細化
 Milestone
 手動sync
 一部
 抽出
 リリースノート
 手動
 まとめ
 #product-feedback
 ロープレ会 プロダクトコード
 開発&
 デプロイ
 Lean Canvas
 具体化
 product
 discussion
 参照して開発
 利用ログ
 ユーザが
 活用
 使われ方 分析で
 new issue へ
 new issue へ
 : 具体的なデータ
 : 定例会議体

10. MNTSQ 10 思い出したこと: 安定なシステムもプロセスはめちゃ複雑だったりする