Fintechのプロダクトづくりで大切な4つのプロセス
メルペイでDirector of Productとしてプロダクトマネージャー全体を統括しているKajiです。
2018年5月にメルペイに入社しました。
当時はメルカリからの事業移管のPJを担当してしましたが、その後はメルペイスマート払いのローンチをはじめ、リリースしたサービスの改善・運用や新規事業の検討・チーム立ち上げをしています。
4年近く働いている中でFintechの開発プロセスにおいて特に重要なプロセスがあると感じています。
カジュアル面談などで多くの業種の方とお話する機会があり、多くの違いを実感します。
今回はそんなFintechのプロダクトづくりで大切な4つのプロセスとそこに紐づくスキルを書いていきます。
はじめに
メルペイ入社後、「資金決済法」「割賦販売法」「貸金業法」「個人情報保護法」など多くの法令に触れ、実際にプロダクトに落とし込んできました。
ただ、自身で触れたことの無い分野も多々あり、「保険」「証券」「銀行」など、Fintechの中でもこういったことがあるよというのがあれば是非コメントやTwitter等で教えていただけると嬉しいです。
また自身の経験談を元に記事化をしているので、もしかしたら会社特有の話があるかも知れません。
1. リリースまでの継続的仮説検証
必要なスキル
UX Research
MVPとなるプロダクト精緻化とプロジェクトマネジメント
どんな新規事業であれ、リーンにはじめて検証をしていきたいと考える方は多くいると思います。
「やはりプロダクトはMVP（Minimum Viable Product = 実用最小限の製品）で検証していきたいよね」というのは皆さん考えると思います。（SaaSであればMSPですが）
ところがFintechの領域ではMVPに対して大きく工数を取られてしまいます。
それは事業立ち上げに際して業法の取得であったり、関連する法令を守ったり、体制を整えたりする必要があるためです。
たとえば後払いのサービスでは「割賦販売法」が必要となってきます。
クレジットカードのように与信枠を付与してお買い物をできるようにするためには「包括信用購入あっせん業」や「クレジットカード番号等取扱事業」といった登録が必要となってきます。
今回は登録するための内容等は省略しますが、こういった業法取得だけでも相応の時間がかかります。
もちろん、グレーゾーンのような形で法律をくぐり抜けて業法を取得せずに実施できることもあります。
また、クレジットカードの法律を守るために「信用情報機関」との接続をしたり不良債権を売却する先の「サービサー」との契約をしたりする必要があります。
こういった事業者との接続はもちろんベンダーを利用して進めるということはありながらも自分たちでサービスを開発していくところも多々あります。（メルペイではCICとの接続を自社で実現しました）
ここまでの話で、ローンチまで1年はくだらないだろうという話になってきます。
Fintech領域では、とにかくローンチまでの期間で仮説の精度を高めていく取り組みをしていき、必要あれば方向転換していく必要があると考えています。
ローンチ時の高さを出すため、またこれからのバックログを作っていくためにUX Researchを継続的にしていきましょう。
定性・定量意見によって仮説の精度を高めると「本当にMVPはこれで良いのだろうか？」ということにも陥ります。
最低限の要件はしっかり抑えつつ、どのような付加価値を提供するかというのは作っていきながら精緻にしていくと良いでしょう。
ただし、戦略（いつ出して、どう伸ばしていくか）なども含めてプロジェクトマネジメントを意識して進めていきましょう。
2. 法令との戦い
必要なスキル
法令に関する知識
外部の機関との折衝
プロダクトに落とし込むための法解釈と妥協点
法律の変化への対応
Fintechのプロダクトは常に法令を守っているか、また法令を違反しているとみなされないかを確実に知りプロダクトづくりをしていく必要があります。
法令は完璧に要件を記載しているわけではありません。
解釈の仕方により法的に問題ないとみなされたり、逆に問題ないと思っていたが実は問題だったということもあります。
例えば「割賦販売法」や「貸金業法」などは紙ベースで物事が進んでいた時代の記載が多々あります。
書面の発行や保存の要件などの多くは「契約書をお客さまと交わしてそれを保存する」という前提で作られています。
ではアプリで実現するためにはどうすればよいでしょうか？
いくつかの選択肢があります。
外部の法律事務所に相談する。
先行の登録事業者のアプリを参考にしていく形。
監督官庁に対して質問を投げかけて解決していく。
etc…
法律事務所はそれぞれで特定の業法に強かったりします。
自分たちが提供したい体験との落とし所を粘り強く作っていきましょう。
ただし、既存の法令に対してトリッキーな要件で作ってしてしまうと見えないリスクが存在する場合があります。
しっかりとリスクアセスメントをしながら安心安全のプロダクトを実現していきましょう。
とはいえ、法律事務所に対して常に食ってかかるようなことはやめましょう。しっかりと法律の背景を理解しながら、なぜやりたいのか・どんなことを実現したいのかと言うところを明確にし落とし所を一緒に見つけにいきましょう。
また、法令は変化していきます。
最近だと成人年齢が20歳から18歳に引き下がるという話もあり、そういったものに都度対応していく必要があります。
もちろん会社のリーガルやコンプライアンスを担当するチームに頼ることもいいですが、プロダクトマネージャー自身が情報をキャッチアップして対応を推進していけると良いです。
3. 3線体制を意識したリスクマネジメント
必要なスキル
プロダクトだけでなく、オペレーションなどを加味したリスクアセスメント
リスクに対するコントロール
2線, 3線の助言による優先順位の検討
3線体制はあまり聞き慣れない方もいると思います。
スリーラインディフェンスとも呼ばれ、リスクへの体系的なアプローチをするモデルです。
Fintech特有ではないものという認識をしていますが、Fintechでは業法取得等で体制が必要なため初期から整えているケースが見られます。
超概要で説明すると以下となります。
1線が事業を執行しリスクを管理している
2線がリスクマネジメントや財務、コンプライアンスなど間接的に管理し、1線をモニタリングして支援・助言をする
3線が内部監査として1線2線の業務を評価し、助言をする
この体制を意識するために、プロダクトチームは自身のプロダクトに関するリスクだけではなく、オペレーションなども理解して網羅性のあるリスクアセスメントする必要があります。あくまで2線は牽制する役割なのです。
また、リスクへの対応をコントロールしていく必要があります。
具体的にはリスクの影響とと発生可能性から低減、保有、回避、移転といった取り組みをします。
例えば超エッジケースにいつまでも対応し続けることは困難なのでリスク保有をするといった形を取ります。
移転はバックログの優先度としてもコントロールしやすいようにリスク発生可能性と影響度のマトリックスを作成し、共通認識をもちましょう。
2線, 3線の助言による優先順位の検討については、改めて1線で管理しているリスク評価が正しいかを判断するために多くの支援・助言をしてもらえます。
定期的にコミュニケーションを取ることで、リスクコントロールを正しく保ち、対応していけるようにする必要があります。
4. 引き継ぎとオンボーディング
必要なスキル
必要となる業法の説明
背景・意図の言語化
リスクマップの可視化
サービスの大小によって引き継ぎコストは変わってきますが、Fintechは小さいプロダクトであっても引き継ぎのコストが高いように見受けられます。
（良くないことですが）これまでいくつかの会社で引き継ぎ資料がないままにサービスを引き継ぐケースを見たことがありますが、Fintechでは少し問題があります。
それは前述で記載の法律面によるWhy/Whatやリスクコントロールを言語化し、網羅性のある形で引き継ぐ必要があるからです。
法律やリスクだけではなく、セキュリティやその他コンプライアンスなどもあるので多くのことを背景とともに言語化していき、引き継ぎをしていきましょう。
こうした取り組みによって、コンプライアンスチーム等の工数を無駄に取ることなくなります。
お互いの信頼関係のためにも引き継ぎはしっかりしましょう。
もちろん複数のプロダクトマネージャーがいれば集合知によって解決することは多々あります。
ただ、どんなプロダクトに対してもプロダクトマネージャーを複数アサインするのが難しいことがほとんどです。（単純にHead Countや採用の課題）
そのため、これまでの経緯をドキュメントにまとめてしっかりと共有していくための体制・プロセスを作っていく必要があります。
おわりに
Fintechでプロダクトマネージャーとして挑戦したいという方も結構多くいらっしゃいます。
違いを知りたいという質問を受けるときは今回記載をした観点で回答をしています。
Fintechは属人化しやすい領域だと思って4年ほど経過していましたが、改めてこういったことを意識してプロダクトマネージャーの組織をデザインしていくと多くの時間をプロダクトとの向き合いに使えるようになるはずです。
この記事が気に入ったらサポートをしてみませんか？