N=1 に張る——受取請求書 × BPO の現場から、製品の芯を掘り当てる FDE チームの実践

Transcript

2. N=1 に張る⸺受取請求書 × BPO の現場から、 製品の芯を掘り当てる FDE チームの実践 ⽥畑雄也(tabatea) 2026年10⽉3⽇
3. AIネイティブ開発チーム エンジニア 田畑 雄也 tabatea 数社ベンチャー企業を経て、2023 年10月にfreee中途入社。 freeeカードや受取請求書プロダク トの設計、開発に従事。
4. 本⽇の流れ 01 1 現場と、今⽇話すこと 2 チームでやる FDE 3 要求獲得のプロセス 4 掘り当てたものの深さと、規律 5 まとめ
5. 他⼈の会社のお⾦を、他⼈が動かす仕事 中⼩企業（顧問先）の経理を、BPO事業所や会計事務所が代⾏し、請求書の処理から⽀払いまでを預かる 「受託したくても、できない業務がある」 — 現場で聞いた声 やりたくても、できない領域が残っている
6. 業務は属⼈化していて、正解は誰も知らなかった BPO の業務は、担当者の頭の中と⼿順の中にある。お⾦が絡むので、外からは⾒えにくい ソリューションが特定済み 問題の特定から始まる ‧競合がいて、解き⽅の型がある ‧業務が属⼈化していて、製品の正解は 誰も知らない ‧要求仕様が降りてくるのは合理的 ‧要求が合っているかを早く確かめるの が最優先 今回はここ 属⼈化した現場に⼊り込んで問題を特定する動き⽅ ＝ FDE が必要だった
7. FDE の解説は増えた。でも「何をしたか」の話は、まだ少ない 世の中の発信 採⽤‧職種化 概念解説 他社事例の紹介 ⼀つのプロジェクトの中⾝ プロセス‧失敗‧意思決定 まだ少ない 今⽇の持ち帰り 1 いきなり作らない。まず要求の芯を明らかにする 2 その芯の引き出し⽅ 今⽇は、⼀次情報で話します
8. 今⽇話すのは、「要求の獲得」まで 要求の獲得 業務分析 触れるデモ FB ループ （製品化） 今⽇は話さない 繰り返す 3⽉ 探索開始 7⽉ お披露⽬ いま 製品化フェーズ この順で進んだ。今⽇話すのは、製品化の⼿前まで
9. 本⽇の流れ 02 1 現場と、今⽇話すこと 2 チームでやる FDE 3 要求獲得のプロセス 4 掘り当てたものの深さと、規律 5 まとめ
10. FDE とは、仕様書を受け取らない動き⽅ この発表での定義 顧客の現場に⼊り、業務を観察して問題を抽出し、動くものを当てながら、 個社対応で終わらせず、製品の芯を掘り当てる ⼀般的な開発と、どこが違うか ⼀般的な⾃社プロダクト開発 この発表での FDE 解くべき問題は、既に定義されて降りてくる 問題の定義そのものを、現場で獲得する 個社対応で終わらせない。成果物は、問題の構造
11. 必要な能⼒は、1⼈で全部持たなくていい freee は、PdM と Eng が職務として分かれている組織 その構造の上に FDE を載せると、この分担になった 課題側 実装側 PdM 2⼈ Eng 2⼈ ⾃分はここ 共創 業務‧要求の分析と引き出し 要求を触れる形に変換 ＋ AI の活⽤ FDE は PdM の代替ではない。分担して、共創する形
12. 本⽇の流れ 03 1 現場と、今⽇話すこと 2 チームでやる FDE 3 要求獲得のプロセス 4 掘り当てたものの深さと、規律 5 まとめ
13. まず、業務を時系列で⾒た イベントストーミング 課題を特定するために、まず業務を時系列で並べた
14. 次に、構造で⾒た — ここで「作らない」が決まる AS-IS TO-BE 作らない 作らない 課題側と実装側が、同時に同じ画⾯を⾒ながら作った 作る 構造で⾒ると、作る部分と「作らない」部分が決まる 作らない
15. 分析をそのまま事業所に⾒せても、要求は引き出せなかった ⽅式を変えた × 触れるデモを作って、当てる 事業所に、そのまま説明しようとした 全部説明しきるのは、しんどい デモは、製品を作るためのものではない。課題を特定するための道具
16. バックエンドは、1 ⾏も書かなかった 0 ⾏ バックエンドの実装 26 ⽇ 発⾜から初期版 100 超 もらった FB 判断は ADR に残し、製品化に引き継いだ ⽬的は課題の特定。製品を作ることではないから、この割り切りができた
17. なぜ、バックエンド 0 ⾏が「割り切り」になるのか freee でバックエンドを書く、ということ 会計との連携が重い 探索フェーズでは マスタの正本も、取引の登録先も freee 会計の側にある。 連携の設計が主戦場になる この重い設計を、 あえて後ろに置いた 連携する基盤が多い フロントだけで当て、 判断は ADR に残した。 いま製品化フェーズで、 この設計をしている 権限、AI エージェント、ファイル、課⾦。 それぞれの基盤と整合を取る設計が要る 重いところを後ろに置けたから、26 ⽇で当てられた
18. ⾔われたものを作らない。芯だけに応える 100 を超える FB 細部に、繰り返し現れる共通の関⼼事 抽象化して、主軸に置く 主軸に合う → 採⽤ 合わない → ⼀段落とす
19. 実例：⾔われたとおりに作らない、とはどういうことか ⾔われたこと 「マスタは会計システムのものと連携してほしい」 フェーズに合わない形 本体連携は、このフェーズには過剰 要求の芯 「マスタが必要」というのは本物 やったこと プロダクト内で完結する最低限のマスタ管理として実装し、当てた 鵜呑みにしないとは、断ることではない。芯だけに、最速で応えること
20. 現場に、名前のない業務単位があった 現場で起きていたこと 顧問先からの依頼 名前を与えて、業務の単位に昇格 業務の束 既にあるまとまりで Google フォーム ⾔葉で検証せずに、実装して触ってもらい「これでいい」を得た
21. 本⽇の流れ 04 1 現場と、今⽇話すこと 2 チームでやる FDE 3 要求獲得のプロセス 4 掘り当てたものの深さと、規律 5 まとめ
22. 単位を閉じると、ミスも不正も起こせなくなる 業務の単位を固定する 中⾝の増減ができない 混⼊‧対応漏れが そもそも成⽴しない 閉じた業務の単位 × × 追加 削除 掘り当てた製品の芯と正しさの担保が、同じモデルの中で同時に実現した
23. 要求を捨てないと、受託になる 顧問先側の効率化 × 1st ではやらないと決めた。BPO 側に集中するため 社内の類似プロダクト × 要求が噛み合わず、 ⼯数がむしろ増えるため使わなかった 判断の問いは、いつも同じ この要求は 他の顧客にも 再現するか? 速く作れることと、作るべきかは別 捨てる基準がないと、その顧客専⽤の受託になる
24. 要求仕様は、書かないのではなく使い分ける 探索フェーズ 製品化フェーズ（今） 要求仕様 要求仕様 書かない デモから逆に抽出する 要求の獲得 ドキュメント 触れるものから獲得する Design Doc を書いている 判断の記録 戦略 ADR に残し、製品化に引き継ぐ 汎化を優先 戦略 N=1 の WOW を優先 PRD を書かなかったのは、フェーズに合わなかったから
25. 本⽇の流れ 05 1 現場と、今⽇話すこと 2 チームでやる FDE 3 要求獲得のプロセス 4 掘り当てたものの深さと、規律 5 まとめ
26. 今⽇持ち帰ってほしいこと 1 いきなり作らない。まず要求の芯を明らかにする 業務を時系列と構造で⾒て、作る∕作らないを先に決める 2 その芯の引き出し⽅ 細部を抽象化して主軸を定め、触れるものを道具に検証する 3 問題の特定から実装まで、エンジニアが⼊れる それは、チームで分担できる これは PdM だけの仕事ではない
27. AI で作ること⾃体の価値は下がった 芯を捉えるために作る価値が上がった 探索フェーズで通った道 業務分析 触れるデモ FB ループ （製品化） ⾃分の⼿で解くという⼿触りは、AI 時代にむしろ増える