B2B SaaS開発における顧客要望対応との付き合い方
December 24, 2019 · 9 min read
A1Aでエンジニアをしている住奥です。
今回はB2B SaaS開発にありがちな、顧客要望対応のプロダクト開発への影響とその対処法についてエンジニア視点で書いていきたいと思います。 初期フェーズのB2B SaaSの開発者を中心に、SaaSプロダクト開発に関わる方の助けになれば嬉しいです。
※ 現在A1Aで開発しているRFQクラウドはまだ立ち上げ期のプロダクトで、まだ成功はしていません。成功するプロダクトになるための仮説という気持ちで眺めると丁度良いと思います。
TL;DR;
契約時の顧客要望対応とは次のように付き合う。
- ヒアリングのためなどプロダクトの前にすすめるために対応する
- できるだけ小さくかつ、時期を決めずに対応することをコミットする
場合によっては、厳しい（範囲が大きいかつ、時期が決まっている）コミットをしてでも、顧客理解を深めてプロダクト開発に活かすという選択も必要になる。
厳しい顧客要望による影響を最小限にするために、エンジニアは次の2点を意識した実装が必要。
- とにかくミニマムで提供する
- 捨てやすい設計にする
SaaSビジネスの特徴
まず前提としてSaaSの特徴を簡単に記します。 SmartHRの宮田社長の記事から一部抜粋
【特徴1】1つのプロダクトを、数多くの顧客が使う
・パッケージなどに比べて価格を安く提供できる
・一方で、個別のカスタマイズはやりづらい
【特徴2】売上がミルフィーユ的に積み上がっていく
・サブスクリプション型なので、売上がどんどん積み上がっていく
【特徴3】 先に損して、後で得するビジネスモデル
・最初に大きく顧客獲得コスト（CAC）をかけて顧客を獲得し
・解約率（Churn Rate）を下げて、長期的に利用してもらうことで
・損益分岐点（Break-Even Point）を越え
・契約から解約までの期間の収益（LTV）で時間をかけて回収するビジネスモデル
プロダクトとしては、特定の顧客に合わせたオーダーメイドではなくユニクロのような多くの顧客の要望をコスパよく満たすことが求められます。 よって、多くの顧客に対して汎用的にメリットを生み出すことが重要になります。
また、受注して終わりではなく多くの顧客に継続利用してもらうためには、継続的なプロダクトの改善が必要になります。 よって、プロダクトの開発スピードを落とす技術的負債が重くのしかかってしまいます。
B2Bサービス開発で何が求められるかについては、弊社エンジニアの曽根田が書いた元B2Cアプリ開発者が考える、B2CとB2Bのサービス開発の違いとは？もご参照ください。
顧客要望対応とは
ここでは顧客要望対応とは、契約時に存在しない顧客が求める機能を、要望を聞きながらの実装をコミットすることとします。
SaaS開発において顧客要望対応と聞くと構えてしまうエンジニアが多いと思いますが、これにも良し悪しがあります。 対応の目的と、コミットのやり方の2つの観点で良し悪しを説明します。
顧客要望対応の目的
まず厳しい顧客要望対応を行うとどうなるのでしょうか。
- 技術的負債や、個別の顧客にしか使われない機能が積み上がる→
- これにより、プロダクトの開発スピードが遅くなる→
- プロダクトの成長スピードが落ちると、将来のビジネスの成長スピードも遅くなる
コミットのやり方次第にはなりますが、このように契約で縛られる顧客要望対応には長期的な成長スピードを落とすリスクが多かれ少なかれあります。
よって、短期的なビジネス都合で顧客要望対応を決断するのは、長期的な視点が重要なSaaSにおいては誤った決断になる可能性が高いです。1
では、どのような場合であれば顧客要望対応が良い決断になるかというと、プロダクトを前にすすめることが目的になる場合です。
| 目的 | |
|---|---|
| Good | ヒアリングのためなどプロダクトを前にすすめる |
| Bad | 数値目標の達成など短期的なビジネス都合 |
現在クラウド見積査定システムのRFQクラウドでも顧客要望対応をしているのですが、ヒアリングが目的になっています。
プロダクトを成長させるために機能追加をしようにも、実際に使い物にならなければ意味がありません。そこで、ヒアリングが重要になるのですが、B2Bシステムでは難しいです。 業務システムは気軽に試すことが難しいので、顧客も導入にならないと実際の業務に当てはめるとどうなるかを考えられません。
この問題の解決策として、対応することをコミットして要望を聞かせてもらうという方法をとっています。
次にそのコミットのやり方について説明します。
顧客へのコミットのやり方
| 詳細仕様 | スコープ | 対応時期 | |
|---|---|---|---|
| Good | 決めない | 小さい | 決めない |
| Bad | 決まっている | 大きい | 決まっている |
前述したとおり、契約で契約で縛られる顧客要望対応にはプロダクトへの影響があります。厳しいコミットをしてしまうと具体的にどのような影響があるのか説明します。
本質的でない機能を提供してしまう
対応をコミットした顧客の業務フローが、他の顧客でも利用できる汎用的なものであるとは限りません。 顧客の業務フローをそのまま満たす形で機能を開発すると、他の顧客では利用しない本質的でない機能を提供してしまうことがあります。
例を見ていきましょう。
- 長袖・半袖を切替可能なTシャツの提供をコミットする→
- そのままリリースするが、要望元の顧客以外では利用されない→
- 本来は長袖・半袖を切替可能にするより、カーディガンも合わせて提供したほうが理想だった（要望元の顧客にとっても）
Tシャツの例だとみなさん普段接しているので「こんなことになっててもわかるでしょ」と思われるかもしれません。しかし、B2Bシステムだと自分たちが普段接しないので、顧客の要望があっていると思い込んでしまいがちです。
そこで重要になるのが、顧客の要望を深堀りすることです。どこに痛みを抱えているのかを明確にし、本質的な解決策を見つけることができれば、自然と汎用的な機能となります。
ここで気をつけなければならないのが、契約の際に詳細仕様まで決まってしまうと本質的な解決策をとれない場合があることです。そのため、対応をコミットする際は詳細仕様を決めないことが重要になります。
また、特定の顧客のみ課題を深堀りしても、他社においては当てはまらない可能性があります。そのため、スコープを小さくすることで軌道修正を早くできるようにすることも重要になります。
本来の優先順位通りに開発できない
対応をコミットすると、多くの場合は対応時期が決まります。これにより、本来の優先順位で開発できない場合があります。
例を見ていきましょう。
- 従来提供していたTシャツに発熱機能をつけることをコミットする→
- 実は現状の肌触りがすこぶる悪く、既存の顧客から改善要望が→
- コミットしていることからリソースが割けない状況に
このように契約によって対応時期が決まると、優先順位を変更することが困難になります。
技術的負債が積み上がる
また、対応時期が決まってしまっていると、開発時に気づきに対応する時間が無くなります。 開発が進むと作っている機能の解像度が高まるのでよりよい実装方法に気づくことがあるのですが、時期が決まっていると悪い方法をとってでも終わらせざるを得ません。
これを繰り返すと技術的負債が積み上がり、次第に機能の実装も遅くなってしまいます。
これらを防ぐために対応時期をコミットしないことが重要になります。2
顧客要望対応との付き合い方
顧客要望対応の種類とその影響を見て行きました。では、実際にどのように付き合っていくと良いのでしょうか？
1.良いコミットができる顧客のみ対応する
顧客要望対応をやる際は、まず良いコミットができる顧客のみやることを心がけましょう。
2.厳しい顧客要望も対応する選択肢も取らなければならない場合もある
とはいえ、「時期や作るものもコミットしないで契約を取るのがよい」といっているので、このようなコミットで顧客を取ることは非常に難しいと思います。立ち上げ期で機能の少ないプロダクトであればなおさらです。
その場合は厳しい要望であっても、顧客理解を深めてプロダクト開発に活かすために対応するという決断が必要になります。 良いコミットができる顧客を探す時間も無限にあるわけではありません。
3.厳しい顧客要望対応においてもできるだけ負債を残さない
厳しい顧客要望への対応が発生した場合、作成する機能に優先順位がつけれず、また十分な設計の時間を取ることも困難になります。このような状況において将来の負債を残さないために、次の2点が重要です。
とにかくミニマムで提供する
稼働コミットで追加する機能をできるだけ小さく提供します。そうすることで、本来優先度が低い機能を実装するリスクを小さくできます。
求められている仕様を、工数が少ない or 将来足を引っ張らない方法で代替できないか、CSのメンバーと協力してミニマムで満たすことを目指します。
捨てやすい設計にする
稼働コミットで追加する機能を捨てやすい設計にします。十分な設計がされていない機能は将来負債となる可能性が高くなります。
テーブルを独立するなど既存と依存しない形にすることで、将来の別機能の追加や改修の足を引っ張らないようにします。
おわりに
エンジニア視点で個別顧客対応のプロダクト開発への影響と対処法について書かせていただきました。 （開発についての割合が少なくなってしまいましたが…）
製品の立ち上げ期に顧客要望対応をコミットをせざるを得ない状況は大いにあると思います。そのような時に今回書いた内容が、プロダクトへの影響を最小限に留めながらコミットを乗り切る助けになれば幸いです。
また、立ち上げ期でも契約をとる営業チームや、顧客を成功をに導く導入・運用サポートチームへの感謝の気持ちも忘れないようにしたいですね。 RFQクラウドもまだまだ大変な時期が続くと思いますが、互いに協力しあって顧客を成功をに導く製品を開発したいです。
最後に、A1Aでは継続してエンジニアを募集しています。立ち上げ期のRFQクラウドを互いに協力しあって成長させて行きたい方は是非！応募フォームはこちらです。
