プロダクトビジョンから作る機能を落とし込む

プロジェクト管理freeeの機能として作業日報の機能を作りました。
この機能を作るにあたって、ユーザーヒアリングやストーリーマッピングを活用しましたが、どの機能を作るかの意思決定をどのようにしていったのかをお話します。

Transcript

1. freee 株式会社
 freee Slide Format freeeのやるやらの決め方
 ~プロダクトビジョンから作る機能を落とし込む~ 

2. • freee株式会社所属
 • Engineer
 • 開発効率高めるのが好き
 • 趣味はrubocopの適用
 山崎遼介 moai
 Engineer
 2
3. 3 今日の話をざっくりと

4. 4 日報機能を作りました

5. 5 この機能のやるやら決定方法を紹介
 • ビジョン
 →ユーザペイン仮説
 • ユーザペイン仮説＋ユーザヒアリング
 →仮説検証
 • ユーザペイン＋現状のプロダクト
 →MVP

6. 6 前提
 ミッション
 プロダクトビジョン

7. Mission スモールビジネスを、 世界の主役に。 freeeは「スモールビジネスを、世界の主役に。」 をミッションに掲げ、 「アイデアやパッションやスキルがあればだれでも、 ビジネスを強くスマートに育てられるプラットフォーム」 の実現を目指してサービスの開発及び提供をしております。 大胆に、スピード感をもってアイデアを具現化することができる スモールビジネスは、様々なイノベーションを生むと同時に、 大企業を刺激して世の中全体に新たなムーブメントを起こすことができる存在だと考えております。 会社概要
 会社概要
 会社概要
 7
8. 8 プロジェクト管理freee
 • プロジェクトにまつわる業務を楽にしたい

9. 9 freeeスマート受発注
 • 外注管理を簡単にしたい

10. 10 ブレインストーミング
 ↓
 機能絞り込み

11. • ユーザーストーリー形式で出す。
 ◦ 〇〇として、▪▪したい。なぜなら△△だから
 ◦ 例）
 ▪ プロジェクトに入ってるメンバーのうち業務委託は簡単に請求書を発行したい。
 なぜならば請求書発行業務がめんどくさいから。
 11 ブレインストーミング

12. 『ミッションとの関連』と『作りやすさ』で重み付け
 • 
 • 
 12 作る機能の重み付け
 略
13. • プロジェクトに入ってるメンバーのうち業務委託は簡単に請求書を発行したい。
 • なぜならば請求書発行業務がめんどくさいから。
 13 大まかな機能概要の決定

14. 14 ユーザヒアリングで仮説検証

15. 
 • 請求業務を処理している人
 • freeeの中で請求業務を請け負っている人
 • freeeへ請求書を送っている人
 • 請求書と一緒に送られる作業日報を作成している人
 15 ヒアリング対象

16. 
 • 請求業務を処理している人
 • freeeの中で請求業務を請け負っている人
 • freeeへ請求書を送っている人
 • 請求書と一緒に送られる作業日報を作成している人
 16 ヒアリング対象

17. 
 • どんなロールがいるのか、その人の背景は何なのか？
 • どのような順番で作業をすすめるのか？
 • 何が一番めんどいと思っているのか？
 • 時間がかかる業務はどこか？
 17 ヒアリング内容

18. 18 ヒアリング結果：コミュニケーション図
 
 業務委託 freee 工数監督 経理 請求処理担当 経理 現場監督 請求担当 請求書再作成依頼 支払い申請 差し戻し 決済/ 差し戻し 請求書 決済申請 作業報告書・請求書 提出 差し戻し 催促 作業報告書 確認依頼 確認報告 催促 請求書を PJ毎にまとめ る 請求書が 来ているかを確認 作業報告書確認が 完了しているかを確 認 作業者 工数不足・超過 連絡 稼働状況確認 ヤバそう

19. 受注者
 （業務 委託）
 作業者
 管理者
 請求担当
 管理部門
 発注者
 請求担当
 PJ管理者
 経理
 工数実績 の記録 稼働状況の ヒアリング 工数入力 状況確認 作業報告 作成 請求書を 稼働状況に 応じて再作成 PJ毎に 請求書・作業報告書を 提出 PJ管理者に 作業報告書の 確認を依頼 リストを元に 請求書の提出状況を 確認する リストを元に 作業報告書の確認状況を 確認する 作業報告書を 確認 請求書の提出 を 催促する 作業報告書の 確認を催促す る 支払う 経理に 支払い申請を上 げる （請求書添付） 提出 済み？ 確認 済み？ Yes No No Yes 不足・超過 有る？ 申請 承認 PJ毎に 見積金額から 請求書を作成 稼働状況 報告 Yes 確認業務

20. 
 • 仮説が誤っていた
 ◦ 請求書発行は困ってなかった
 • 新たなユーザペインがわかった
 ◦ 請求書の確認業務にペインがある。しかも作業報告書を使った確認業務。
 20 ヒアリング結果サマリー

21. 
 • befoer
 ◦ プロジェクトに入ってるメンバーのうち業務委託は簡単に請求書を発行したい。
 ◦ なぜならば請求書発行業務がめんどくさいから。
 • after
 ◦ 社内外の請求書処理担当は作業報告書で簡単に確認業務がしたい。
 ◦ なぜならば確認業務がめんどくさいから
 • 理由
 ◦ 作業報告書にフォーカスしたのは
 ▪ 作業報告書はプロジェクト運営上必要とされることが多い
 ▪ プロジェクト管理freeeが持っている工数のデータと親和性が高い
 21 ヒアリング結果を踏まえて機能概要を変更

22. 22 ユーザーストーリーマッピング

23. オフライン＋でかいホワイトボード
 23 実施方法（物理）

24. 時系列のユーザ行動＋ユーザーストーリー
 24 成果物イメージ

25. • 作業報告書→日報
 • 1日単位の勤怠時間・作業内容を入力できる。
 • 共有機能
 ◦ 管理者はメンバーの作業日報を確認・編集できる。
 ◦ PDFを出力することができ、プロジェクト管理freee外にも共有できる。
 25 日報機能MVP

26. 26 MVPとユーザーストーリー
 

27. • 機能
 ◦ 作業報告書→日報
 • ユーザーストーリー
 ◦ 従業員は作業内容を日次で記録したい。上司に報告するため
 • ラベルを変更した理由
 ◦ 作業の記録と共有は日報機能に近い
 ◦ 日報をエクスポートした姿が作業報告書
 ◦ ラベルを変更することで日報機能に必要なFeedBackを集める
 27 作業報告書→日報

28. • 機能
 ◦ 1日単位の勤怠時間・作業内容を入力できる。
 • ユーザーストーリー
 ◦ 上司は工数の入力漏れをチェックしたい。工数管理のため。
 → 勤怠時間
 ◦ 委託元の会社に作業内容を報告したい。委託元に求められているため
 → 作業内容
 28 1日単位の勤怠時間・作業内容を入力できる。

29. • 機能
 ◦ 共有機能
 ▪ 管理者はメンバーの作業日報を確認・編集できる。
 ▪ PDFを出力することができ、プロジェクト管理freee外にも共有できる。
 • ユーザーストーリー
 ◦ 上司は工数の入力漏れをチェックしたい。工数管理のため。
 → プロダクト上での権限：管理者はメンバーの作業日報を確認・編集できる。
 ◦ 業務委託の会社は工数が契約の範囲に収まるか確認したい。請求書再発行のため。
 → プロダクト外での共有：PDF出力機能
 ◦ 委託元の会社に作業内容を報告したい。委託元に求められているため
 → プロダクト外での共有：PDF出力機能
 29 共有機能

30. 30 コストとスケジュール
 

31. 
 • 大まかな機能絞り込み：3day × 1人
 • ユーザヒアリング：2day × 2人
 • 細かな機能決定：1day × 3人
 • 既存機能のすり合わせ： 7day × 1人
 
 Total: 17 day×人 ≒ 1 month×人
 31 コスト一覧

32. 
 • 大まかな仮説絞り込み：2/2～
 • ユーザヒアリング：2/19～
 • ユーザーストーリーマッピング：3/3～
 • 実装：3/11～
 • QA：3/25～
 • リリース：4/15
 
 Total: 2.5ヶ月
 32 スケジュール概観

33. 33 まとめ

34. 34 この機能のやるやら決定方法を改めて
 • ビジョン
 →ユーザペイン仮説
 • ユーザペイン仮説＋ユーザヒアリング
 →仮説検証
 • ユーザペイン＋現状のプロダクト
 →MVP

35. 35 推しポイント
 • ユーザヒアリングやUSMはコスト的には大したことない。
 • 納得感や無駄な機能を作らなくて済む

36. ヒアリング＋USMで
 無駄のない機能開発を

37. 37 EOF