FREEEの事例に学ぶ、新規プロダクト開発の進め方

FREEE
の事例に学ぶ、新規プロダクト開発の進め⽅ 1
FREEE
の事例に学ぶ、新規プロ
ダクト開発の進め⽅
2020
年4
⽉にリリースした「Freee
プロジェクト管理」という新規プロダクトの開発
に⾄る話
感想
対象業種や業務に関するヒアリングはめっちゃ⼤事
事業の⽅向性を固める
PJ
の前提知識を揃える
プロトタイプ作成のための前提知識の収集が完了させることを意識してヒ
アリングを⾏う
プロトタイプからユーザーテストまでのサイクルがめちゃくちゃ早い
メンバーが1
⽇2
時間しか取れないのに、1
週間サイクルで回しているのは単
純にすごい
準備でここまで変わるのかっていうイメージ
ユーザーストーリーベースで動くの良い
何のための機能なのかをチーム全員が理解している
ユーザーストーリーマッピングで優先度の⾼い機能も可視化されていて、開
発のロードマップも明確
プロジェクト毎に開発チームルールを定義するの良い
freee
プロジェクト管理チームでは
常にユーザーストーリーを第⼀に考える
動くものをベースに会話する
物理的な場所を意識しない開発
不確実性が⾼い状況でも遊び⼼を忘れずに、開発を楽しむ
⾃分達が試⾏錯誤したことを整理し、他のチームに残す

View Slide

FREEE
スクラムメンバーにQA
がいると品質が⾼くなるんだなぁ
坊村さんが⾔っていた通りQA
⼊れるの良いな（今まで打鍵者くらいにしか
思っていなかった）
テスト設計・QA
テストもスプリントに⼊れる
機能の過不⾜に早く気づき、修正も早い
ユーザーの視点でサービス全体の品質を担保する
理想を追求する
ステークホルダー全員が納得したらリリース
リリースが楽しそう
スプリントレビュー中にリリースしてる
機能フラグで管理しているので、on/off
のみ
楽しそう
読んだメモ
第1
章新規事業スタート前にプロダクトマネージャー
が取り組んだこと
初期メンバーはPdM
、UX
デザイナー、エンジニアの3
名
対象業種や業務に関するヒアリング
3
ヶ⽉で100
本のヒアリングや議論を⾏い、10
万字を超える議事録
テックリードも加わり4
名に
「SPRINT
最速仕事術――
あらゆる仕事がうまくいく最も合理的な⽅法」のデ
ザインスプリントを採⽤
プロトタイプへの落とし込み、ユーザーテストまでを1
週間で⾏う
各メンバーが兼務状態だったため5
⽇間×2
時間
事前にテーマとゴール設定を擦り合わせていたおかげで予定通りに終了
プロトタイプ作成のための前提知識の収集が完了していたこと
PdM
、UX
デザイナー、エンジニア、テックリードと全ファンクション
で経験値の⾼いメンバーが揃っていたこと

View Slide

FREEE
経営陣にプレゼン
想定ユーザーが抱える課題
freee
が提供する価値とソリューション
競合プロダクトとの⽐較
事業計画
海外・国内の競合サービスの調査
ホームページだけでなく実際のプロダクトを利⽤することが重要
ミッション/
ビジョンに整合性と事業性の両⽴担保すること
第2
章漠然とした要件からMVP
を⾒極めるには？プロ
トタイプからペルソナを⾒出し、開発に⾄るまで
UX
デザイナーの主な役割
ユーザーリサーチ
デザインプロセスの整備
UI
作成
誰に何を届けるためのサービスなのか
ざっくりとした⽅向性から、サービスの⽅向性を固めにいく
初期MVP
で残った機能は⼀つだけ
提供すべき価値の認識があいまいで、機能の重みづけや取捨選択が⽢くなっ
ていた
プロトタイプや経営層との議論の中で中⻑期的なビジョンが⾒えてきた
対象ユーザーに再度インタビューを実施し、業務解像度やペインの明確化
全員でユーザーストーリーマッピングを作る
ユーザーストーリー（〇〇として××
がしたい、△△だからだ）を構造化し
たもの
左から右に時系列、上から下に重要度順
MVP
としてカバーすべきストーリーを俯瞰して議論しやすくなる
スクラムでユーザーストーリーベースで取り組む

View Slide

FREEE
何のための機能かを認識して開発しやすくなる
第3
章新規プロダクトの開発プロセスで意識したい5
つ
のポイント
常にユーザーストーリーを第⼀に考える
チームでの意思決定の⽅針を決めることが⼤事
ユーザーストーリーがチームに浸透しないと意味ないため物理的な合宿で
認識を揃えた
これは本当に重要
動くものをベースに会話する
不確実性の⾼い状態から、試⾏錯誤して本質的な価値を⾒つける
初期はあえてHeroku
を採⽤し、開発した機能を動く状態にして議論
「包括的なドキュメントよりも動くソフトウェアを」
物理的な場所を意識しない開発
複数拠点のため物理的に離れているチーム
MTG
やスクラムイベントは常にビデを会議のURL
を共有、誰でも参加
OK
アジェンダは事前にGoogle Docs
に作成し、MTG
中にリアルタイムに書
き込んで作成
抽象的なディスカッションは予めmiro
などを⽤意
動くものをベースに会話するために、常に最新の状態を確認できる環境
を⽤意
不確実性が⾼い状況でも遊び⼼を忘れずに、開発を楽しむ
継続的に⾼いパフォーマンスを発揮するためにはチーム全体が楽しむこと
が⼤事
スプリントが終わったらクラッカーで祝福
関係者を巻き込み、スプリントイベント中にリアルタイムデプロイ
フィーチャートグルを⽤意しておき、その場でフラグを切り替える
その場で新機能が使える体験は⾮常に好評
⾃分達が試⾏錯誤したことを整理し、他のチームに残す

View Slide

FREEE
社内にはドキュメント
社外には記事やイベント
「あえて共有する」
第4
章ユーザー価値と速さを両⽴する新規プロダクト
の開発実践
「マジ価値」を提供するためにアジリティを追求
開発準備
期間は2
週間
基本⽅針のすり合わせ
DB
設計から画⾯設計まで⼀気通貫で迷いなく作れること
誰がやっても同じように開発できること
⾮同期処理が⾏えること
テストが迷いなくかけて、⾃動テストが実⾏されること
スクラム導⼊コーチとともに、スクラムの勉強
インセプションデッキの作成
プロダクトの⽅向性の確認
メンバー同⼠の⼈となりの確認
基本設計
ユースケース図
オブジェクト図
ER
図
⾔語
メンバーのスキルを⾒てRails
を採⽤
Go
を書きたいメンバーもいたので、⼀部機能でGo
を採⽤して納得感を
得た
レビューを重視した開発環境

View Slide

FREEE
⾃動テスト
コードレビュー
スプリントレビュー⽤の確認環境
Heroku
本番はkubernetes
上で動いていて、環境ができた時にHeroku
は削除
スクラム開発
プランニング
タスク内容の確認
2,3
時間かけても良いので不安を解消
プランニング
認識のずれがないかを確認
ポイントが⼤きければ分割
開発
フロー効率向上のために可能な限りレビューを最優先にする
ペアプロの実施
ペアプロで書いたものはその場でレビューも⾏うことで効率化
情報共有のためのペアプロも実施
プランニング前の事前調査
調査タスクをスプリントに⼊れる
ドキュメントやPoC
コードがアウトプット
QA
のためのテスト設計レビュー
次スプリントでQA
が実施するテストを作る
リアルタイムでQA
視点でのレビューが⼊り、機能の過不⾜に気づきや
すい
レビュー＆振り返り
リリース
ほぼ毎⽇以下の環境に反映

View Slide

FREEE
共通の開発環境
リリース前の県境環境
本番環境
機能フラグで管理
数回のスプリントのうちい1
回を改善スプリント
ユーザーストーリーの開発はせず、改善を⽬的としたスプリント
第5
章プロダクの品質はテストだけでは測れない新
規プロダクト開発における品質管理の考え⽅
チームの壁をなくし、ONETEAM
でスクラム開発を進める
QA
メンバーの固定化
開発メンバーとのコミュニケーションが良くなる
テストも早いサイクルで回す
テストの観点から実装漏れに気づく
テストのFB
による修正も早い
短期間で改善を回せるため、効率化できる
作り込みすぎない
作り込むとメンテ⼯数が増える
E2E
テストは最⼩限に
ユーザーの視点でサービス全体の品質を担保する
理想を追求する
ステークホルダー全員が納得したらリリース
第6
章プロダクトの価値を届けるPMM
の役割とは？
PMM
プロダクトマーケティングマネージャー
出来上がったものをどう売るか

View Slide

FREEE
必要になるタイミング
100
名規模くらいの会社から
freee
でのPMM
のゴール
プロダクトローンチ
戦略的商品の利⽤促進
書くの疲れたのでここでやめます
YOJO
にPMM
が必要になったら書きます

View Slide

FREEEの事例に学ぶ、新規プロダクト開発の進め方

FREEEの事例に学ぶ、新規プロダクト開発の進め方

PharmaX（旧YOJO Technologies）開発チーム

More Decks by PharmaX（旧YOJO Technologies）開発チーム

Other Decks in Technology

Featured

Transcript