開発の判断基準は「課題解決総量」 深津貴之氏、マネフォ山田一也氏が語るSaaSプロダクト戦略
こんにちは!Micoworksプロダクトマネージャーの淡島です。
本日はMicoworksの社内企画の一つである、社長トークセッションのレポートをご紹介します。
今回のセッションではMicoworks顧問であるTHE GUILD代表取締役の深津貴之さん、マネーフォワードビジネスカンパニーCSOの山田一也さんの両名をゲストに、「SaaSのプロダクト戦略」をテーマに、ディスカッションを行いました。
【ゲストプロフィール】
UI/UXデザインの良し悪しは「トレーニングコスト」で測る
Micoworks代表 山田修(以下、Micoworks山田):
今日は「SaaSのプロダクト戦略」というテーマで、お二人とディスカッションさせてください。
今MicoworksがSaaSプロダクトを進めている中で、プロダクトの「使いやすさ」と「機能数」は重要なファクターになると考えてます。
ここで頭を悩ませているのが、デザインや開発の優先順位づけや、「何をどこまでやるのか?」といった線引きの判断です。
まずお伺いしたいのはプロダクトの「使いやすさ」の定義についてです。同一のプロダクトでも「使いやすい」と思う人もいれば、「使いにくい」という人もいるじゃないですか。
全体的に見てユーザーフレンドリーなプロダクトといえるかどうかの見極めは、どのような手法で行えばよいのでしょうか。
株式会社THE GUILD 代表取締役 深津貴之さん(以下、深津さん):
「トレーニングコスト」を指標に測ると良いと考えています。
1社員が利用しはじめて使いこなすまでに、プロダクトAは2週間の学習期間がかかる一方、プロダクトBは15分以内に直感的に使えるようになる。
社員1人あたりの平均で、プロダクトAを使うと1日に25件の仕事をこなせる一方、プロダクトBは50件の仕事が処理できる。
こうして比べた場合、プロダクトBのほうが「ユーザーにとって使いやすいプロダクト」といえそうですよね。「使いやすさ」って感覚的なものだと思われがちですが、数値指標で定量化した方が捉えやすくなります。
マネーフォワードビジネスカンパニーCSO 山田一也さん(以下、マネフォ山田さん):
マネーフォワードでは「バックオフィスSaaSはユーザーの滞在時間が短い方がいい」と以前議論に上がったことがあります。
バックオフィスの方々には「月次決算を締める」というゴールがあって、プロダクトの価値は決算を締めるまでの時間をどれだけ短縮できるかなんですよね。
プロダクトの滞在時間が短いとは、それだけ毎月の定例業務のコストが小さくなっているということ。
深津さんがおっしゃるように「使いやすさ」を「トレーニングコスト」と言い換えると、それと同じ発想が出やすくなります。
深津さん:
そうなんです。実は「滞在時間が長い」って、ユーザーがプロダクトを使いこなせてない場合もあるんですよね、行うべき業務が終わっていない状況も示してる。
Micoworks山田:
なるほど。トレーニングコストで定量化すると非常にわかりやすいですね。それでは実際に使いやすいプロダクトをつくるためには、どのようなステップで進めるべきでしょうか?
深津さん:
私だったら、リリース前の工程に時間とお金をかけます。
具体的には、市場調査、技術選定、競合調査、プロトタイプの作成、そしてユーザーテスト。
プロダクトを作ってからユーザーの声を聞きはじめる人も多いですが、作る前にユーザーの声を聞いた方が速いし、打率も高いかなと思っています。
マネフォ山田さん:
リリース前にコストをかけるのは、コストパフォーマンスは圧倒的に良いですよね。
マネーフォワードでは「スプリントゼロ」という取り組みがあります。
スクラム開発の際、開発のスタート地点を「スプリント1」と呼びますが、マネフォでは「スプリントゼロ」を定義して、開発着手前にやるべきことを整理して明確にするプロセスを必ず入れるようにしています。
Micoworks山田:
経営者としては「一刻も早くプロダクトをリリースしたい」と思ってしまうのですが、視野が短期的なのでしょうか。
深津さん:
リリースが早い方がいいかどうかは、プロダクトの市場環境次第だと思います。
最初にシェアを取ったプロダクトが圧倒的に有利な場合は、あらゆるリスクを踏んでも、一番先にリリースすることが重要です。
一方でレガシー産業向けのプロダクトで、業界そのものがコンサバティブであれば、リリースまでに多少じっくり時間かけても何の問題もないと思います。
マネフォ山田さん:
そこは、本当に事業戦略とのかみ合わせですね。
スピードは、あくまで事業を成功させるための一つの手段です。
事業戦略によって、スピードを優先すべきかどうかも変わってきますね。
深津さん:
先行者利益やネットワーク効果(*)が大きいかどうかで判断は変わると思います。(*サービス利用者が多いほど、プロダクト価値が高まること。)
機能開発の優先度を決めるのは「課題解決の総量」
Micoworks山田:
SaaSプロダクト開発において「使いやすさ」と並んで「機能数」を充実させていくことも重要だと考えています。開発の優先順位はどのように意思決定していくといいのでしょうか?
マネフォ山田さん:
課題解決総量、つまり「課題の対象ユーザー数」×「一社あたりの課題解決インパクト」の掛け算がどれだけ大きいかで意思決定することが多いですね。
既存機能の改善は既存ユーザー全体にいきわたるので、対象ユーザーの数は多いんだけれども、一社あたりで見たインパクトの点は少しにしかならない。
一方で、新規機能の開発は、一社あたりで見たインパクトは大きくでますが、新しい機能を求めるユーザー数が少なければ意味がなくなってしまいます。
深津さん:
機能拡張と市場拡張を密結合させるのはやめた方がいいでしょう。
機能を1つ増やして1クラスターを獲得できる状態を考えると、100クラスター取るために100機能増やさなきゃいけないことになります。
そのやり方だと開発が進むにつれて負債が溜まって詰んでしまう。
小さい対象領域を一つ取るために、例外的な機能を開発する意思決定はやめたほうがいいですね。
「Evernote の5%問題」という話が有名ですが、端的にいうと「新機能の利用率が5%以下の機能を作りすぎると詰んでしまう。
だから、基本的に95%のユーザーにとって課題になる点に対して、アップデートを加えるのがおすすめです。
プロダクトへの投資基準は「セールスへの貢献度」
Micoworks山田:
プロダクトリリース前の段階でUI/UXデザインや機能開発にどこまでこだわるべきなのか、その線引きの基準はどこにあるのでしょうか。
深津さん:
プロダクトのUIUXデザインに投資して使いやすさにこだわることが、どれだけセールスに貢献するのか考えることが大切です。
極端な例を出すと、社長同士の会話で導入が決まるプロダクトで契約時の初期費用が大きな金額がとれる場合、導入後のプロダクトの使い勝手が悪いと現場で不満が上がっていても、UI/UXに投資してもセールスにはそれほど影響しないかもしれない。
一方で、プロダクトの普及を目的にする場合や、まずは無料版を提供しヘビーユーザーだけ有料版に移行してもらうというビジネスモデルの場合、 UI/UXがダメだと誰も課金しようとしない。この場合はユーザー体験にこだわるべきですよね。
プロダクトのグロース戦略や構造によって、ユーザー体験の優先順位は大きく変わってきます。
Micoworks山田:
なるほど。UI/UXデザインも費用対効果で考えるんですね。
マネフォ山田さん:
UX 戦略は事業戦略と共通点が多いと思っています。
通常、戦略を決めるとなると「どんな施策を打つのか」という方針に目がいきがちです。でも、良い戦略は方針を決める前段階にある「診断」、つまり現在の課題特定がきちんとできている。
プロダクトのUX デザインについても全く同じで、「プロダクトではどういう体験をつくるのか」という方針の議論に入る前に、「ユーザーは今、どういう体験の悪さを感じているのか」という診断のフェーズが大切です。
Micoworks山田:
体験をより良くするためには、現状の課題を知るところからという意味ですね。
深津さん:
ビジネス全体の戦略とUXデザインや機能開発などのプロダクト設計とは、切り離せない関係です。
市場環境や競合の動きを見ながら、自社プロダクトをどのタイミングでリリースするか、プロダクトのUXデザインや機能改善にどれだけ時間を使うのか、意思決定を進めるといいと思いますよ。
Micoworks山田:
いきなりプロダクトを作るのではなく、丁寧にユーザーの課題を深堀していく点、市場環境を見極めながらリリースタイミングを決めていく点など、『MicoCloud』のプロダクト開発でも実践していきたいと思います。
深津さん、山田さん、ありがとうございました!
▼深津さん、マネフォ山田さんとの社内セッション後編はこちらから