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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

● freee株式会社所属  ● Engineer  ● 開発効率高めるのが好き  ● 趣味はrubocopの適用  山崎遼介 moai  Engineer  2

Slide 3

Slide 3 text

3 今日の話をざっくりと 

Slide 4

Slide 4 text

4 日報機能を作りました 

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

8 プロジェクト管理freee  ● プロジェクトにまつわる業務を楽にしたい 

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

『ミッションとの関連』と『作りやすさ』で重み付け  ●   ●   12 作る機能の重み付け  略

Slide 13

Slide 13 text

● プロジェクトに入ってるメンバーのうち業務委託は簡単に請求書を発行したい。  ● なぜならば請求書発行業務がめんどくさいから。  13 大まかな機能概要の決定 

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

30 コストとスケジュール   

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

33 まとめ 

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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