株式会社justInCase Technologies プロダクトマネージャーの西川です。

2022年12月ついに、私が携わってきたプロダクトである保険SaaS基盤joinsureの提供が開始されました。

生命保険会社・損害保険会社および保証会社に利用していただくことができるjoinsureは、保険商品を高速で構築できる保険基幹システムとなるSaaSです。

この大がかりなプロダクトを、1年半という短い開発期間でローンチに至ることができました。

joinsureのPdM体制は、以下のようになっています。

• joinsure全体(一般的なVPoP/PO)・・・1.5名(兼務を含むため)

• joinsure Record 契約管理システム・・・2名(契約前機能が私・契約後機能が1名)

• joinsure Engagement 保険募集システム・・・1名

私は2022年10月にjustInCaseに入社し、前職の保険査定業務の経験・知識を活かしながら、手探りでPdM業務をキャッチアップしてきました。
SaaSプロダクトのPdM未経験での業務は、想像よりも大変でぶつかる壁も多かったですが、そのおかげで今後プロダクト開発に関わる上で貴重な学びを大いに得ることができました。

このnote記事では、フロムスクラッチのSaaS開発 & 私自身のPdMキャッチアップという経験における反省・その背景・解決策について取り上げていきます。

私のように自己学習で調べながらPdM業務をされる方もいらっしゃると思いますので、そのようにSaaSプロダクトを0から作ったり、Fintech系の企業でPdMとして開発に関わる方に、少しでも役立てば幸いです。

チーム開発に関する3つの反省

それぞれの問題が生じた背景

MVPは主にNotionでまとめていましたが、実装範囲がぶれることが頻発しました。
当社プロダクトの場合、保険業務を一元的に管理・運用できる従来の基幹システムに代わるフルパッケージのプロダクトによる特性上、ユースケースの数が膨大でかつ膨れ上がり気味でした。

そのため同じユースケースでも、それぞれの機能を担当するPdMやエンジニアによって実装範囲の認識が合わないことが多々ありました。

結果、似たような機能でもプロダクトによってはできることに差異が生まれユーザーに混乱を与える結果になってしまいました。

新しく何かを決めるために仕様や方針に関する議論が幾度となく行われましたが、残念ながらその全てが記録として残ってはおらず、その結論に至った経緯を一部の人しか知らないような事態が発生してしまいました。

そのため、「どうしてこうなったんですか？」という質問に個別で回答し同じ質問が他方向からも来てしまったり、同じ議論が別の場所で繰り返されてしまうということが発生しました。

これは、私たちPdMとしてプロダクトの技術的な解像度が低かったことが原因だと考えています。
当初仕様として主に「こんな画面の動きで〜」、「こんな要件があって〜」とかなりユーザー目線でのやりたいことしかまとめられていませんでした。
残念ながらこれでは不十分で、各エンジニアが必要とする情報を仕様として落とし込むことができていませんでした。

例えば、フロントエンドであれば画面上の振る舞いを気にします。
一方、バックエンドで言えばデータの持ち方や使われ方を気にします。

そのため、仕様を簡単に「画面遷移・やりたいこと」をまとめるだけでは不十分で、結果仕様書が機能せず口頭で確認するコミュニーケーションが多くなってしまいました。

各問題に対して行った解決策

認識の合わせるためには、情報を1つに集約しある程度視覚化する必要がありました。
そのため、プロダクトバックログとFigmaを活用して集約&可視化を実現しました。

プロダクトバックログ

MVPとして自分たちが何を目指すか・何をこれからすべきかは、プロダクトバックログを定めて整理しました。
プロダクトバックログの作成方法はいくつかありますが、個人的にはテンプレートを使うことをオススメします。
こちらのテンプレートはプロダクト全体の課題・目的・完了条件の全てが一元的に整理されて、確認しやすくなりました。

Figma

上記、バックログに加えデザインとしてもやることを明確にすることもオススメします。
意外に文字だけでは以外に認識齟齬は生まれやいものです。
そのため、デザイン上どこまでやるかも合わせて明確にするようにしてます。
もちろん今後のバックログ全てをデザインに落とすことは不可能なので、あくまで今できている範囲での明確化になります。
（当社はFigmaを使ってますがデザインツールなら何でもOKです）

ここでの問題はドキュメントとして残さなかったことですが、単純にドキュメントを残せば解決するような簡単な問題ではありません。
根本的な問題はどのようにドキュメントを残せばよかったか不明瞭だったため、ドキュメント作成のアクションを起こしずらかったことでした。
そこでドキュメントの型をある程度定めました。
以下、私が使っているテンプレートです。
至って当たり前の内容ばかりですが、以下3点をポイントとしていつもドキュメントとして残しています。

• 検討案の網羅性

• 各検討案のイメージ

• まとめとして、どの観点で最終その案にしたかの経緯の記載

検討した案についてある程度網羅的にまとまっていれば結論に妥当性が高まります。また、案を文字として記載するだけでは具体的なアウトプットがわからず結論の理解にブレが発生するので、イメージはできる限りあったほうが良いです。
最後にどの案に至ったかの経緯をまとめておくことで、後から見返してもどういった議論がされ最終的に結論が何になったかすぐにわかります。

ここでの問題は各エンジニアが必要とする情報をまとめられていないことでした。
そこで、各エンジニアと連携する際は以下それぞれを最低限連携するようにしました。
PdMが細い実装まで口出しする必要はありませんが、ある程度実装の枠組みを決めた場合と決めない場合の開発スピードやアウトプットの質はかなり違ってきます。

• フロントエンド　→　Figma（デザインツールで作成した具体的なデザイン）

• バックエンド　→　ドメインモデル図・アクティビティ図

ドメインモデル図

ドメインモデル図の作成はDDD（ドメイン駆動設計）が前提になりますが、業務上どんなデータが必要か、各データはどんな振る舞いをするかをここで仕様として整理しました。
これによりテーブルの構成や関係性をビジネス側と目線合わせしながら実装を行うことができるようになりました。

アクティビティ図

アクティビティ図はデータの流れを見える化するために活用しています。
特に画面で表示が難しい裏側のロジックなどを整理するときに有用です。
これにより、ソースコードを見なくてもどんな流れで処理がされているか見える化しどのような形でデータの連携すべきかを整理しました。

まとめ

今回は、joinsure開発における開発チームで発生した問題についてお話ししました。

紹介した取り組みは、実際にやろうと思うとかなり地道な作業が多いですが、プロダクト開発は一朝一夕で完成するものではありません。

PdMの継続的なコミュニケーションや情報のメンテナンスで、開発チームが円滑に回っていくと信じています。

次回は、インフラ編です。インフラ構築の議論を後回しにしてしまったことで起きた問題と解決策についてお話しします！