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

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

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

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

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

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

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

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