超複雑なドメインが絡むプロダクトにどう向き合っていくか / How to deal with products involving ultra-complex domains

by freee

Slide 1

Slide 1 text

⾼⽊悟 2024年5⽉31⽇超複雑なドメインが絡むプロダクトにどう向き合っていくか

Slide 2

Slide 2 text

2 高木悟  プロダクトマネージャー公認会計⼠/税理⼠会計業界出身のプロダクトマネージャー  2011年公認会計士試験合格  2011年〜2014年　新日本有限責任監査法人にて会計監査  2014年〜現在　freee（勤続10年）  副業で会計事務所もぼちぼちやってます  PdM歴は7年。税理士ということもあり「税」と名のつくプロダクトは色々と担当してきました。 

Slide 3

Slide 3 text

　私が担当している/してきたプロダクト法⼈税を代表とした各種税⾦の申告ができるプロダクトターゲットは会計事務所、法⼈経理確定申告‧インボイス‧電帳個⼈事業主の所得税計算を⾏う確定申告。インボイスにおける消費税申告、優良電⼦帳簿等を担当。 freee会計の中での税⾦が絡む領域

Slide 4

Slide 4 text

　 01 複雑なドメインとは 02 チームの課題とその学び 03 要件定義の課題とその学び 04 複雑なドメインに向き合う⼈への応援メッセージ⽬次

Slide 5

Slide 5 text

　 01 複雑なドメインとは 02 チームの課題とその学び 03 要件定義の課題とその学び 04 複雑なドメインに向き合う⼈への応援メッセージ⽬次

Slide 6

Slide 6 text

B to Bのバックオフィスプロダクト開発はドメイン理解が必須！

Slide 7

Slide 7 text

そもそもドメイン理解には2種類ある ①法制度‧計算⾃体の理解 →例：法⼈税とは？所得税とは？インボイスとは？電⼦帳簿保存法とは？ ②ユーザー業務の理解 →例：法⼈税を計算している会計事務所はどういう業務フローになっているのか

Slide 8

Slide 8 text

①法制度‧計算⾃体の理解〜法⼈税のケース

Slide 9

Slide 9 text

②ユーザー業務の理解〜会計事務所のケース

Slide 10

Slide 10 text

開発するためのドメイン理解の難易度が⾼すぎる →このテーマに約7年ほど向き合ってきた学びを PM視点で共有します

Slide 11

Slide 11 text

　 01 複雑なドメインとは 02 チームの課題とその学び 03 要件定義の課題とその学び 04 複雑なドメインに向き合う⼈への応援メッセージ⽬次

Slide 12

Slide 12 text

チームの課題〜全員にドメイン理解を求めるのは酷 →特定の⼈が先駆者になりつつチーム全体の底上げも⾏うモデルへ税務のバックグラウンドない状態がほとんど。開発する内容をまずキャッチアップするだけでも⼤変 Eng /UX 税務のバックグラウンドはあれど、開発のバックグラウンドはない。ドメイン理解以外にも⾊々求められてしまうのはきつい PM 税務のバックグラウンドない状態がほとんど。変更点が多いので変更箇所を追っていくだけで⼤変 QA

Slide 13

Slide 13 text

まずPMがドメイン理解の先駆者にたつ〜①計算/法制度を理解する

Slide 14

Slide 14 text

まずPMがドメイン理解の先駆者にたつ〜②ユーザーの業務フローを⽣情報で理解する

Slide 15

Slide 15 text

コード/デザインに落とし込む時にやっぱり⾃分で理解しないと出来ない。。 Eng /UX ⾃分はばっちりわかった！ PRDに計算定義は書いたけど、これで良いのかな、、 PM ある程度、前提情報がないとそもそもテストに取り掛かることも難しい。。 QA チームの課題〜特定の⼈だけが知ってるだけでは意味がない

Slide 16

Slide 16 text

チーム全体の底上げをする〜ドメイン勉強会を実施しチーム全員を巻き込む

Slide 17

Slide 17 text

チーム全体の底上げをする〜USMを実施し複雑な業務フローの理解をチームで⾏う

Slide 18

Slide 18 text

チーム全体の底上げをする〜不具合対応‧障害対応をチームで⾏う（同じ釜の飯を⾷う）バグチケットをチームで毎日朝会で見る

Slide 19

Slide 19 text

PM機能を「ピュアPM」と「ドメインスペシャリスト」に分割する開発優先度のジャッジ等、⼀般的なPMに求められる機能を満たしていくドメインスペシャリストを活⽤し開発とのブリッジを⾏う。ピュアPM 法制度/計算/ユーザー業務をチームで⼀番理解している存在となる。主に要件定義に責任を持つドメインスペシャリスト

Slide 20

Slide 20 text

　 01 複雑なドメインとは 02 チームの課題とその学び 03 要件定義の課題とその学び 04 複雑なドメインに向き合う⼈への応援メッセージ⽬次

Slide 21

Slide 21 text

他プロダクトのPRD（要求定義書）を流⽤するとこれはこれで必要だが、計算の網羅性を担保できるようなものではない

Slide 22

Slide 22 text

ドメインが複雑（=計算が複雑）なプロダクトにはスプレッドシート等で網羅性と関連性を重視することが⼤事とにかく断⾯での要件定義にせず、多⾯的な要件定義を⼼がける

Slide 23

Slide 23 text

法律が絡む場合は関連団体/サービスからの情報収集が命常にアンテナを貼り続ける複雑なサービスを開発している場合、意外と関連団体があることが多い。その関連団体への加盟/参加を積極的に⾏い、情報収集をし続ける。

Slide 24

Slide 24 text

　 01 複雑なドメインとは 02 チームの課題とその学び 03 要件定義の課題とその学び 04 複雑なドメインに向き合う⼈への応援メッセージ⽬次

Slide 25

Slide 25 text

僕⾃⾝めちゃくちゃ悩みました ①モチベーションが低下しやすく定着しづらい ②難易度⾼そうなので社内で敬遠されがち ③ユーザーからはボコボコにフィードバックされがち ④品質の要求⽔準が異常に⾼い

Slide 26

Slide 26 text

ドメイン難易度が⾼いプロダクトは実はお得かもしれない ● ドメイン難易度が⾼いということ=参⼊障壁がとても⾼いということ ● 開発頑張ってると、離れられない‧唯⼀無⼆のプロダクトにきっとなれている。 ● そして頑張り続けている開発チームは、いつのまにか職⼈集団になっており、そのチーム⾃体が競争⼒の源泉になる（良い意味で簡単に真似できない）

Slide 27

Slide 27 text

複雑なドメインが絡む開発を楽しんで、良いプロダクトを作っていきましょう！

Slide 28

Slide 28 text

No content