MVP開発をするための要求の詰め方/How to think about requirements for MVP development

Transcript

1. © RAKUS Co., Ltd. MVP開発をするための要求の詰め⽅ #RAKUS Meetup 株式会社ラクス  楽楽精算開発部 製品管理課 紀井 美⾥ 2023/12/6 1
2. ⾃⼰紹介 2 PG/BrSE PjM PdM 紀井 美⾥ 株式会社ラクス 楽楽精算PdM 2013 2017 2022
3. 本⽇お話すること 3 インボイス制度対応を事例にMVP開発とするために、どのような⼯夫をし て要求を詰めていったか プロダクト４階層を⽤いた要求を詰めるための実施アクション • 意志決定要素の構造化（システム思考） • やらないことを決める • ステークホルダーと適切な単位ごとに合意形成をする
4. インボイス制度とは 4 インボイス制度とは？ 2023年10⽉1⽇から施⾏された新しい消費税の制度 国が定める「適格請求書発⾏事業」の登録を受けた事業者が発⾏する適格請求書に 基づく消費税しか原則、仕⼊税額控除を認めないとする制度(国税庁より抜粋) 楽楽精算を利⽤しているユーザーへの影響 • 各種精算時に「適格請求書発⾏事業者」が交付した「適格請求書」であるかの判断 と「適格請求書」の保存が必要 • 上記を判断した上で税額の計算をする必要がある(仕⼊税額控除)
5. インボイス制度とは 5 インボイス制度とは？ 2023年10⽉1⽇から施⾏された新しい消費税の制度 国が定める「適格請求書発⾏事業」の登録を受けた事業者が発⾏する適格請求書に 基づく消費税しか原則、仕⼊税額控除を認めないとする制度(国税庁より抜粋) 楽楽精算を利⽤しているユーザーへの影響 • 各種精算時に「適格請求書発⾏事業者」が交付した「適格請求書」であるかの判断 と「適格請求書」の保存が必要 • 上記を判断した上で税額の計算をする必要がある(仕⼊税額控除) 事業者は原則回避することができない！！
6. プロダクトの取り巻く環境 6 経理業務ドメイン領域 インボイス制度 仕⼊管理 経費管理 会計システム 売上管理 販売管理 請求書発⾏ 仕訳デー タ 仕訳デー タ ドメイン×インボイス制度×製品の関係性 債権管理 固定資産 管理 原価(⼈件費) 管理 仕訳デー タ 決算報告書 適格請求書 確定申告書
7. © RAKUS Co., Ltd. 7 意志決定要素の構造化 (システム思考) #RAKUS Meetup
8. プロダクト４階層 8 プロダクト開発を進める時に効果的だとされる考え⽅ 書籍　プロダクトマネジメントのすべて　より抜粋
9. プロダクト４階層 9 Why、Whatにフォーカスしていく 書籍　プロダクトマネジメントのすべて　より抜粋
10. Why 「誰」を「どんな状 態にしたいか」 意志決定要素の構造化(システム思考) 10 What ユーザー体験 優先度 要素 ユーザーに提供する価値 プロダクトの価値提供としてや らないこと 課題仮説の⽴案 MVPの機能の策定スタンス MVP開発で提供する状態 「今」は開発をやらないこと コア コア
11. 意志決定要素の構造化(システム思考) 11 要素 ユーザーに提供する価値 プロダクトの価値提供としてや らないこと 課題仮説の⽴案 MVPの機能の策定スタンス MVP開発で提供する状態 「今」は開発をやらないこと コア コア 1 2 3 4 5 6 依存関係が物事を 考える順番
12. 意志決定要素の構造化(システム思考) 12 要素 ユーザーに提供する価値 プロダクトの価値提供としてや らないこと 課題仮説の⽴案 MVPの機能の策定スタンス MVP開発で提供する状態 「今」は開発をやらないこと コア コア 1 2 3 4 5 6 要素のコアを定める ※変更不可部分
13. 意志決定要素の構造化(システム思考) 13 要素 ユーザーに提供する価値 プロダクトの価値提供としてや らないこと 課題仮説の⽴案 MVPの機能の策定スタンス MVP開発で提供する状態 「今」は開発をやらないこと コア コア やらないことを 決める 1 2 3 4 5 6
14. MVP(Minimum Viable Product)とは 14 ユーザーに最⼩限の価値を提供できるプロダクトのこと 初期の顧客を満⾜させ、将来の製品開発に役⽴つ有効なフィードバックや実証を得られる機能を 備えた製品のバージョンを指す。 Crisp社のブログ記事 より抜粋
15. MVP(Minimum Viable Product)とは 15 ユーザーに最⼩限の価値を提供できるプロダクトのこと 初期の顧客を満⾜させ、将来の製品開発に役⽴つ有効なフィードバックや実証を得られる機能を 備えた製品のバージョンを指す。 Crisp社のブログ記事 より抜粋 MVPを決めるために、 やらないことを決める！！
16. 思考プロセス概要 16 Why What ユーザーへの 提供価値 仮説課題の ⽴案 MVP機能策定 スタンス MVP開発での 提供状態
17. © RAKUS Co., Ltd. 17 やらないことを決める #RAKUS Meetup
18. やらないことを決める 18 要素 ユーザーに提供する価値 プロダクトの価値提供として やらないこと 課題仮説の⽴案 決定内容 • 法律を遵守した適切な経理業務 ができる • 業務負担の軽減 • プロダクトの担う役割以外はや らない Viable Viable編 やらないことを決める上での重要なこと • 外部環境、内部環境の理解 • 経理業務の範囲×インボイス制度の影響範囲×プロダクトの担う役割範囲の理 解 Why What ユーザーへ の提供価値 仮説課題の ⽴案 MVP機能策 定スタンス MVP開発で の提供状態
19. やらないことを決める 19 外部環境 内部環境 • 法律 ◦ インボイス制度、電⼦帳簿保存法、 消費税法、法⼈税法、会社法、etc... • ユーザーのインサイト • 競合 • 関連システム • プロダクトの担う役割(ベストオブリード) • 社内の関係部署(PMMとの連携) ◦ マーケティング(プレスリリース)、 カスタマーサクセス(インボイス制度 対応LP) • 経営資源(開発期間、開発リソース) プロダクトの取り巻く環境を把握する Why What ユーザーへ の提供価値 仮説課題の ⽴案 MVP機能策 定スタンス MVP開発で の提供状態
20. やらないことを決める 20 プロダクトの取り巻く環境は「なぜ⾃社がするのか」の部分 書籍　プロダクトマネジメントのすべて　より抜粋 Why What ユーザーへ の提供価値 仮説課題の ⽴案 MVP機能策 定スタンス MVP開発で の提供状態
21. ドメイン × インボイス制度 × 製品の関係性 21 経理業務ドメイン領域 インボイス制度 仕⼊管理 経費管理 会計システム 売上管理 販売管理 請求書発⾏ 仕訳デー タ 仕訳デー タ 経理業務の範囲×インボイス制度の影響範囲×プロダクトの担う役割範囲の理解が必要 Why What ユーザーへ の提供価値 仮説課題の ⽴案 MVP機能策 定スタンス MVP開発で の提供状態
22. やらないことを決める 22 要素 ユーザーに提供する価値 プロダクトの価値提供として やらないこと 決定内容 • 法律を遵守した適切な経理業務 ができる • 業務負担の軽減 • プロダクトの担う役割以外はや らない Viable 課題仮説の⽴案 • 外部環境(法律、関連システム情 報)、内部環境(プロダクトの担 う役割、既存機能の制約や前提) から⽴案 • 業務フロー ◦ 誰が、どのシーン、実 害、あるべき Why What ユーザーへ の提供価値 仮説課題の ⽴案 MVP機能策 定スタンス MVP開発で の提供状態
23. やらないことを決める 23 MVPの機能の策定スタンス MVP開発で提供する状態 「今」は開発をやらないこと 法要件に関してのスタンス • インボイス制度対応において、あ くまで楽楽精算はお客様の業務を ⽀援する⽴場である 顧客に提供する価値の依存関係 • 法律を遵守できることが前提とし て、業務負担の軽減がある 課題仮説の分類 • 課題の解決⽅針として、機能開発 のみか、運⽤回避が可能なのか 提供する機能として「今」は作らない • 課題の解決⽅法に運⽤回避がある Minimum Why What ユーザーへ の提供価値 仮説課題の ⽴案 MVP機能策 定スタンス MVP開発で の提供状態 要素 決定内容
24. やらないことを決める 24 MVPの機能の策定スタンス MVP開発で提供する状態 「今」は開発をやらないこと 法要件に関してのスタンス • インボイス制度対応において、あ くまで楽楽精算はお客様の業務を ⽀援する⽴場である 顧客に提供する価値の依存関係 • 法律を遵守できることが前提とし て、業務負担の軽減がある 課題仮説の分類 • 課題の解決⽅針として、機能開発 のみか、運⽤回避が可能なのか 提供する機能として「今」は作らない • 課題の解決⽅法に運⽤回避がある Minimum 要素 決定内容 Minimum編 やらないことを決める上での重要なこと • 外部環境、内部環境の理解 • ⾃プロダクトの既存機能理解 ◦ 制約や前提 Minimum Why What ユーザーへ の提供価値 仮説課題の ⽴案 MVP機能策 定スタンス MVP開発で の提供状態
25. © RAKUS Co., Ltd. 25 ステークホルダーと適切な単位ごとに 合意形成をする #RAKUS Meetup
26. Why 「誰」を「どんな状 態にしたいか」 ステークホルダーと適切な単位ごとに合意形成をする 26 What ユーザー体験 優先度 要素 ユーザーに提供する価値 プロダクトの価値提供としてや らないこと 課題仮説の⽴案 MVPの機能の策定スタンス MVP開発で提供する状態 「今」は開発をやらないこと コア コア 1 2 3 4 5 6 要素の単位で依存 関係のコアから順 に合意形成をする
27. ステークホルダーと適切な単位ごとに合意形成をする 27 コミュニケーションの取り⽅ 適切な単位 • 意思決定要素の単位 合意形成単位 • 意思決定要素をそのまま合意形成の単位に、意思決定要素の依存関係のコ アから階層順に合意形成の順番とする • 情報を依存関係を元に構築した単位であるため、合意形成のスコープが明 確になり発散しにくい
28. まとめ 28 MVPを決めるポイントは3つ • 外部環境、内部環境の理解 • 経理業務の範囲×インボイス制度の影響範囲×プロダクトの担う役割範囲 の理解 • やらないことを決める
29. © RAKUS Co., Ltd. 29 ご清聴ありがとうございました #RAKUS Meetup