概要
みなさんこんにちは。プロダクト開発部部長 / フルスタックエンジニアの高瀬 @takasehiromichi です。
今回は、SaaSプロダクトにおける開発の進め方について、ロカオプ流ではありますが解説したいと思います。
SaaSプロダクトを開発する目的
何事も、実行する前に「なぜそれをやる必要があるのか？」「なぜやるのか？」を考えるのは非常に大切です。では、なぜSaaSプロダクトを開発する必要があるのでしょうか。
サブスクリプション型ビジネスであるSaaSプロダクトは、基本的に顧客の課題を解決し、それによってアウトカムが発生することで顧客から対価をいただくビジネスモデルです。
「アウトカム」については、以下でも解説しています。
そのため、SaaSプロダクトを開発する目的は、既存の顧客や、市場におけるまだみぬ潜在顧客に対して、ニーズを踏まえて課題解決を目指すために他なりません。
SaaSプロダクト開発における成功と失敗
上記の目的を踏まえて、SaaSプロダクト開発における「成功」と「失敗」とは何かを考えます。
前提条件
前提として、SaaSプロダクト開発は、稼働したエンジニアの時間分がまるまる人件費としてコストになります。会社という大きな観点で見れば、そのコストから上回るくらいのアウトカムが出る場合、SaaSプロダクト開発としての活動は費用対効果が高いということになります。
逆に、人件費としてコストを支出したが、期待されたアウトカムが得られないような場合は、費用対効果が低いということになります。
SaaSプロダクト開発における成功
まず、SaaSプロダクト開発において作成したプロダクトや機能が使用されなければ、アウトカムが出るかどうかもわかりません。そのため、「作成したプロダクトや機能が使用されるか、使われているか」は、1つ目のポイントになり、前提条件にもなります。
また、既存顧客や潜在顧客の課題を解決するためには、それらのニーズに合致したプロダクトや機能を作成する必要があり、言い換えれば、「潜在顧客・既存顧客のニーズに合致したプロダクトや機能を作成できたか」が2つ目のポイントになります。
最後に、前述したプロダクトを開発する目的に立ち返れば、アウトカムが発生することが重要であるため、「大きなアウトカムを生み出すことができたか」が3つ目のポイントになります。
これら3つのポイントをおさえることができた時、成功といえます。
SaaSプロダクト開発における失敗
失敗は、成功の逆で、「作成したプロダクトや機能が使用されない、使われていない」、「潜在顧客・既存顧客のニーズに合致したプロダクトや機能が作成できていない」、「大きなアウトカムを生み出すことができていない」と失敗となり、これまでの活動を振り返りPDCAを回し早急に改善策を講じる必要があります。
SaaSプロダクトにおける不確実性
突然ですが、「不確実性」という言葉をご存知でしょうか。
「不確実性」とは、そのまま読むと、どのくらい確実ではないかの度合いを指しています。
ことSaaSプロダクト開発の文脈では、もっともらしいこと、確からしいこと、間違いなくそうだと言えることが少ない状態が多いか少ないかということを指します。
不確実性が高いということは、「もっともらしいこと、確からしいこと、間違いなくそうだと言えることが少ない」状態が多いということになり、確度が低いという言い方もします。
逆に、不確実性が低いということは、「もっともらしいこと、確からしいこと、間違いなくそうだと言えることが少ない」状態が少ないということになり、確度が高いという言い方もします。
SaaSプロダクト開発は、不確実性の塊です。
SaaSプロダクト開発を成功させるために、使われるプロダクトや機能を作成したいですが、作成したプロダクトや機能が使われるかどうかは、作成した後でないとわからないため、不確実性が高い状態です。
また、潜在顧客・既存顧客のニーズに合致したプロダクトや機能を作成したいですが、プロダクトや機能を作成する際には、ニーズを事前に予想して作成しますが、作成した後に、実はちょっと違うニーズだった...ということも起こり得るため、不確実性が高いです。
さらに、大きなアウトカムを生み出すことができるようなプロダクトや機能を作成したいですが、大きなアウトカムを生み出せるかどうかは、プロダクトが置かれている環境や状態、さらには顧客の環境や状態、市場の環境や状態によって大きく左右されるため、不確実性が高い状態です。
不確実性が高い状態は、その過程のみならず、結果さえも不確実なものにしてしまう確率が高くなってしまいます。
結果が不確実であるとはどういうことかというと、例えばあるテーマに沿って開発を進めても、不確実性が高いために、その結果が成功するのか失敗するのか不確定になり、ギャンブル性が高まってしまうことになります。
ギャンブル性を低くし、確実に成功するためには、この不確実性をどれだけ低い状態に持っていけるかにかかっています。
SaaSプロダクト開発において、不確実性を低い状態に持っていく方法
それでは、不確実性を低い状態に持っていくためには、どうすればいいでしょうか。
いくつか方法はありますが、まずプロダクト開発初期に有効なのは、ターゲット顧客を選定した上で、そのターゲット顧客に対して課題などをヒアリングし、その課題を解決するようなプロダクトや機能を作成する方法です。
SaaSプロダクト開発の基本に立ち返れば、SaaSプロダクトは顧客の課題を解決することでアウトカムが発生し、顧客から対価をいただくビジネスモデルです。
であれば、顧客の課題を解決するかどうかの不確実性を下げるためには、実際の顧客に対して提供し、その結果フィードバックをいただいて顧客の課題が解決できているか確認するのが一番確実です。
また、プロダクト開発のどのフェーズでも有効なのは、実際にSaaSプロダクトをご利用いただいている顧客の声を聞き、フィードバックとして活かしてプロダクトの作成や機能の作成を行うことです。
アウトカムを生み出せるかどうかは、顧客の課題を解決できるかどうかにかかっています。顧客の課題を解決するためには、顧客の課題に耳を傾ける必要があります。仮想的な課題ではなく、実際の顧客の課題をヒアリングすることで、課題に対する理解度や純度を上げ、不確実性を減らすことができます。
ロカオプにおける活動について
ここからは、実際にロカオプでどのように開発を進めているかをご紹介したいと思います。
すぐやるタスクとエピックタスク
ロカオプでは、SaaSプロダクト開発の不確実性を低い状態にするため、顧客の声を重要視しています。
そのため、プロダクトを使用していただいている方は全て顧客と捉え、エンドユーザー様、代理店様、さらにはロカオプ社員 (営業、CS、などなど...) も含めて、プロダクトに関する声は全てBacklog上のチケットに起票していただいています。こうすることで、Backlog上にプロダクトに関する声が集約されることになります。 (一部直接起票いただくことが難しい顧客については、声をいただいてから内部的に代理起票する形をとっています。)
その後、プロダクト開発部部長によって、それぞれのチケットに対してタグづけをしていきます。
プロダクトへのインパクトが大きく、実装コストが大きくないものは「すぐやるタスク」、プロダクトへのインパクトが大きいが、実装コストも大きいものは「エピックタスク」、すぐやるタスクでもエピックタスクでもないものは、複数要望があった場合に再度検討する「保留」などのタグをつけていきます。
エピックタスクについては、各種部長陣と会話し、優先順位を決めてプロダクトロードマップとし、順に対応していきます。エピックタスクは、そのタスクの粒度によって1ヶ月〜3ヶ月の実施期間をもち、その都度プロジェクトを作成し対応を進めます。プロジェクトは、部署横断的に作成するものとし、プロジェクトによって適切な人選になるよう努めます。
以下は、エピックタスクで対応したものです。
すぐやるタスクについては、エピックタスクの合間に対応するものとし、優先度はエピックタスクの下としています。たまにすぐやるタスクが溜まってしまうことがあるので、その時は突発的に優先度を上げてすぐやるタスクの対応を進めることがあります。
以下は、すぐやるタスクで対応したものです。
最後に
ロカオプでは、より効果的な開発が行えるように、日々開発手法を試行錯誤しながら対応を進めています。
これからももっとより効果的な開発が行えるように注力していきます。
