〜CSメンバー全員がUI/UXデザインツール「Figma」を使いこなし、デザインをベースに要件定義。ユーザーとともに創り上げる、Vertical SaaSの育て方とは〜

圧倒的な顧客理解が必要とされるプロダクトにおいて、業界知識のないメンバーが中心となって開発を進めていくためには、どのような工夫が必要なのだろうか。

2017年8月に創業し、保険営業のためのクラウド型顧客・契約管理サービス「hokan」を提供する、株式会社hokan。

同社では、カスタマーサクセスのメンバー全員がプロダクトマネージャーを兼務し、顧客の声を開発に反映する体制を取っているという。

その要件定義においては、デザインツールの「Figma」を使ってイメージ画面を作成し、顧客へのヒアリングを実施。ユーザーが最もイメージしやすい環境をつくった上で要件をすり合わせることで、開発の手戻りをなくしているそうだ。

さらに、週に1回のメールマガジンで全リクエストに対する開発方針を伝えるなど、顧客とともにプロダクト開発を進めている。

今回は、同社で事業責任者を務める松元 勇人さんと、カスタマーサクセス責任者の山本 章裕さんに、プロダクトマネージャー不在のSaaS開発の裏側を詳しくお伺いした。

「プロダクトマネージャー不在」のチームが考えた戦略とは

松元　僕は2020年4月にhokanにジョインし、同年9月から事業責任者を務めています。

弊社が提供している「hokan」は、保険業界に特化したクラウド型顧客・契約管理システムです。保険代理店のセールスの方々は、日々の営業活動における顧客管理や事務処理などに多くの時間を使っています。

一方、この基幹システムを提供しているプレイヤーは、ここ10年ほど変化がないんですね。そのシステムにある負を解消したいという思いで、2017年8月にhokanが創業されました。

1〜2年ほどの試行錯誤を経て、プロダクトとして最小限の価値を提供できる状態になり、今年の春頃からはPMFが見えてきたところです。

そこで事業成長を加速させるため、これまで代表の尾花と数名のメンバーがほぼすべてのビジネスサイドの業務を担っていた体制から、いわゆるTHE MODEL型の機能別のチーム体制をつくっていきました。

現在は、業務委託を含めて20名ほどで、そのうち開発サイドとビジネスサイドがおよそ半々です。ビジネスサイドについては、マーケティング、セールス、カスタマーサクセス （以下、CS）の3チームに分かれています。

ただ、そのなかでプロダクトマネージャー（以下、PM）を担えるメンバーがいなかったんですよね。

しかも、hokanのような業界特化型のVertical SaaSは、圧倒的な顧客理解と業界理解が必要になるのですが、創業者を除き、誰ひとりとして保険を売ったこともなければ、代理店を経営したこともありませんでした。

このメンバーでプロダクトを創っていく上では、むしろ専任のPMを置かずに、お客様を巻き込みながらプロダクトを創っていく方がよいのではないかと。

そこで、CSのメンバー全員がPMを兼務する体制にして、プロダクト開発に取り組んできました。

「溢れかえるチケット」の優先度を、3つの軸から判断する

山本　僕は、新卒で大手保険会社に入り、外資系コンサルティング企業を経て、今年の5月に1人目のCSとして入社しました。

僕と松元が入社した頃は、開発の優先度を決める軸が「緊急度」しか定義されてなかったんですね。すると「お客様が強く希望しているから」という理由で様々なリクエストが上がり、開発のチケットが溢れ返ってしまっていました。

松元　僕らの事業フェーズ的には、「目の前のお客様がすごく困っている」という状況に対して、ある程度は解決しなければならないフェーズではある。

しかし、お客様にとっての緊急度と、その機能に汎用性があるのか、それを解決することでどれほどのビジネスインパクトがあるのか、といった事業の視点は、必ずしもイコールにはなりませんよね。

そこで、顧客のリクエストに対する優先度を判断する3つの軸を定め、ビジネスサイドのメンバーがチケットを上げる際に、必ずその項目をHubSpotで入力するというフローに変えました。

ひとつは、その機能がないとお客様の業務にどれくらいの支障が出るのかという「緊急度」。次に、どれくらいの付加価値があるかという「価値向上度」。最後に、それが他の顧客にとっても価値があるのかという「汎用度」です。

それぞれの軸は、項目ごとに5〜7段階で、それぞれどういう状態かを言葉でも明確に定義しています。

▼3つの判断軸と基準（同社提供）

山本　僕は、チケットを作成する本人が、軸に従って「自分なりに根拠を持って判断する」という習慣が大事だと思っていて。よく「お客様からこういうリクエストがあったので、開発してください」といったコミュニケーションをしがちだと思うのですが、これってCSの仕事としてNGだと思うんです。

何かしらの要望をお伺いした時に、その目的は何で、そのためにはどういうことが必要なのか。それがなかった場合、どういうネガティブな影響があるのかをしっかりヒアリングすることが大切だと考えていて。それを当たり前のアクションとしてできるように落とし込んだのが、この3軸です。

これらを記入必須にしたことで、営業やCSのメンバー1人ひとりが「要望いただいたこの機能ってどれくらいの汎用性やインパクトがあるんだろう」と考える土台ができたのが良かったなと思います。

CS全員が「Figma」を使いこなし、デザインベースで要件を固める

松元　各自に挙げてもらった3軸のスコアを参考に、高・中・低の3段階でビジネスサイドとしての優先度を決めた上で、開発サイドに渡しています。

開発サイドは、週に一度のスプリント会議で、その難易度や開発工数などを考慮した上で、いま取り組むのか、取り組まないのか、中長期のロードマップに乗せるかどうかを決める形です。

開発すると決まった機能に関しては、細かい要件を定義していくため、チケットごとにPM担当がアサインされます。基本的には、リクエストのあった顧客を担当するCSメンバーが担当します。

山本　CSチームには現在、業務委託やインターンも含めて4人のメンバーがいますが、全員がデザインツールの「Figma」を使って、イメージ画面を作成し、要件のすり合わせを行っています。

▼実際にFigmaで作成したUIデザイン画面（同社提供）

というのも、お客様は保険営業のプロではあっても、システムのプロではないんですよね。また、ITリテラシーが高い方ばかりではないので、要件定義書などを確認したとしても、合意したイメージと実際に出来上がった機能が全然違っていた、みたいなことが結構あるんです。

であれば、お客様が一番イメージしやすい環境をつくって意見をいただいた方が、開発の手戻りが少なくなり、結果的に早く価値提供することができる。なので、デザインを見せながら「ここはこうしてほしい」などの要件や情報のロジックを確認していく、というやり方にしています。

とはいえ、多くのビジネス側のメンバーは入社前にFigmaを使ったことがありません。僕も、最初はデザインのこともFigmaのことも全くわかりませんでした（笑）。

ただ、デザインそのものよりも大事なのは情報設計なので、Figmaは最低限使えるようになれば問題なくて。それをベースに、お客様の体験をどれくらい鮮明にイメージできるか、そこをコミュニケーションしながら掴めるかが最も大事だと思っています。

開発の方針を「同期」して、顧客とともにプロダクトを創る

山本　また、お客様を巻き込んでプロダクトを創っていくため、開発方針については、お客様にも必ずお伝えするようにしています。

具体的には、スプリント会議で決まった開発方針に基づき、「優先的に開発する方針です」「時期は未定ですが、開発する方針です」といったように、週に1回のペースで全リクエストに対する開発方針をメールでご連絡しています。

▼実際の開発方針を伝えるメール文面（同社提供）

松元　この施策を始める前は、「いつ着手できるかは明言できないものも伝えて意味あるかな」と心配な気持ちもありましたが、「開発の方針が明確にわかるのは嬉しい」という声をよくいただきますね。

さらに、先に開発方針をお伝えしておくことで、実際にリリースされたときにもお客様に喜んでいただけるんですよね。一緒にプロダクトを創っている感が伝わりやすいかなと思います。

山本　とはいえ「検討します」と預かってから「開発のスコープから外れました」というコミュニケーションはなるべく避けたいじゃないですか。

そこで大事なのは、そもそもプロダクトの思想から逸れるリクエストに関しては、CSチームがその場で判断して伝えることだと思っています。

3年後、5年後、10年後かもしれないけれど、その方向性に進んでいくと思われるリクエストに関しては、どれだけ難しい技術的な懸念があってもしっかり受け取る。

一方で、完全にプロダクトの思想から外れるものは、「こういう使い方をしてください」といった形でしっかりとコミュニケーションをして、リクエストを預からない。それをCSができるかどうかが、結構大事だと思っています。

ドキュメントと知見の共有で、コミュニケーションの土台をつくる

松元　その意味では、プロダクトの思想を、そもそもメンバー全員がきちんと理解している状態をつくることが大切です。

弊社では、創業期からConfluenceに情報を蓄積しているので、各機能はどのような背景でどういう業務に対して作られたのかなど、ドキュメントを見ればキャッチアップできるようになっています。

また、プロダクトの全体像を掴むため、「デモレビュー」や「システム説明会」といった取り組みを行っています。

デモレビューは、社内でプロダクトのデモ説明を実施し、13項目の評価ポイントについてフィードバックを受けるという内容です。これはビジネスサイドだけでなく、エンジニアを含めた全社員を対象としていて、自分たちが開発したものがお客様にどのように使われるのか、を理解できるようにしています。

またシステム説明会では、業界全体のシステム構造やその背景、hokanの強みといったところを、創業期からプロダクトに携わってきたメンバーが、主に直近ジョインしたメンバー向けに説明しています。

他にも、代表が「Figma講習会」を開いてデザインのルールや基本の使い方をレクチャーしたりと、基礎知識のベースをつくるような取り組みをしていますね。

こうした取り組みによって、ビジネスサイドもエンジニアサイドも、職種を越えたコミュニケーションがしやすくなり、PM不在でも協力して課題を解決できていると感じます。

「負の解消」の次は、経営にプラスの影響を与えられる開発を

松元　hokanでは、これまで「顧客にとって良いプロダクトを創る」という方針で開発してきましたが、今ようやく保険代理店向けシステムの負を解消できてきたかなという実感があって。

でも、ここで終わってしまうと、スタートアップが参入する意味があまりないと思うんですよね。この先は、それをどう経営や売上にインパクトを与えられるような基幹システムにしていけるか、つまりプラスの価値提供をいかにしていけるかだと思っています。

そのためには、我々が代理店経営というものを理解して、理想に向けて言語化していく必要があるので、今後も徹底的にお客様に向き合ってプロダクトを創っていきたいですね。

また、今後は1人目のPMももちろん採用できたらいいなと思っていますし、もし今回のようにチームに不足する役割があったとしても、全員で補い合っていけるような強いチームをつくっていきたいと思います。

山本　CSとしては、PMのやり方が整ってきたので、今後はさらにお客様に本当にどれだけ価値を届けられるのかに注力していきたいと思っています。

新しい機能がどんどんアップデートされていく中で、顧客への機能紹介や活用の提案をしたり、実際に活用されているお客様の事例をしっかりと言語化して他の代理店様にも横展開していくことが、CSに求められる次の役割かなと思っています。

松元　これまで取り組んできて、やはりお客様にとっても一緒に創っている感があるのはすごくいいことなんだなということも感じましたし、CSメンバーも自分たちが考えたものがプロダクトに反映されていくというのは、やはりSaaS企業ならではの楽しさだと思いますね。

今後も、顧客も社内メンバーも含めて、全員でプロダクトを創っていくことに挑戦していきたいと思います。（了）