ビジネスモデルを理解しよう ~つよつよSaaSエンジニアへの道~

つよつよSaaSエンジニアへの道のエントリー第3弾です。

顧客の成長が自分たちの成長につながるという点においてSaaSは非常に健全なビジネスです。

エンジニアもビジネスモデルの理解が必要

SaaSのエンジニアにとって技術の知識はもちろんですが、ビジネスモデルを理解することも必要不可欠だと考えています。

「顧客の成長につながるプロダクトを作る」という視点をエンジニアが持つことで、開発の優先順位をつけるときの判断基準が正しくなり、顧客にとって価値のあるプロダクトに成長していきます。

ビジネスモデルを理解しておくことで、いつまでに何を作らないといけないのか判断がしやすくなります。法律の施行にあわせて対応が必要になってくるもの、toB向けのサービスであればどうしても3月の解約と4月の契約が増えるので、そこに向けて新機能のリリースを間に合わせるなどの意識が働くようになります。

業界知識を知っておく

人事労務、勤怠管理、請求会計などバックオフィス系のサービス、弁護士や税理士といったいわゆる士業に関連するサービスは特に顕著ですが、開発を行っていく上では関連する法律や業界の知識が必要になってきます。

業界への知識がないと機能を開発する際に理解が不足したままでの開発になりますし、他のエンジニアと共通の認識で業界のワードを使っていかないと認識のズレが出てきてしまいます。

その他にも技術的側面からもビジネスモデルを理解しておくことでメリットがあります。

どういった人たちをターゲットにしているのか

市場の課題とサービスを適応させる、いわゆるプロダクトマーケットフィットしているかという点からも、どういった人たちをターゲットにしているのかを意識しておくことが大事です。

ネットワーキング効果をどうもたせるのか、マルチテナント環境をどう実現するのかを踏まえた上でインフラや開発言語といった開発環境の構築や設計をしていく必要があります。

もちろん最初からすべてを完璧に作り込むよりはいち早く市場にリリースして反応を見るのが一番です。開発の優先順位にしたがって開発チームの体制が整ってから技術的負債を返していくことになりますが、その時の逃げ道をなんとなくイメージできているとよいと思います。

機能を開発する以外にも、ターゲットを理解することでインフラを最適化することができます。

BtoB、BtoC、CtoCでアクセスの集中する時間帯も変わってきます。toB向けのサービスであれば平日の日中のアクセスが多くなります。その中でも人事労務や会計請求系のサービスは特に月末月初にアクセスが集中します。

例えば請求書発行サービスで1時間サービスが停止してしまったときに土曜の夜間に1時間停止するのと末日日中に1時間停止するのとでは、SLA（Service Level Agreement）上は同じ1時間の停止であったとしても、顧客に与えるインパクト、顧客の満足度は大きく変わってくるでしょう。

今まで業務ソフトをインストールして使っていたものをクラウドサービス化したタイプのプロダクトは、アプリケーションが動いているのがPC上であろうがクラウド上であろうがユーザーにとっては変わらないため、速度を含めた使用感として同等のものを求められる傾向にあります。

料金体系はどうなっているのか

SaaSには定額プラン、複数プランの組み合わせ、ユーザー数による課金以外にも、使った分だけ請求される従量課金、利用料の段階に応じての段階制料金といった複数の料金体系が存在します。

料金体系はプロダクトがどこに価値を置いているか、もっとも明確に反映される場所です。

プランによって使える機能が変わる、従量課金するために使用量を測定するなど技術的な面でも深く関わってくるところです。これが受託案件と大きく異なる点です。

プロダクトがうまれた理由を知る

「エンジニアの人数が増えプロダクトが成長してきた。だんだんと顧客の声が届きにくくなってきた。」そんなときに改めてふりかえっておきたいのが、どういう想いでそのプロダクトが産声をあげたのか、そのプロダクトを初期メンバーがどう育てたかということ。

かなりボリュームがありますが、起業や新規事業などのスタートアップに関わる上での基礎知識についてまとめられている「Startup Science」を読むことで、自分たちのプロダクトがどうやってうまれたのか、その後どういった経緯をたどって今に至っているのか思いを馳せることができます。

Startup Science 2020完全版 (2550 page)

SaaSエンジニアに求められる意識

エンジニアだけに限らずSaaSにかかわるメンバーの意識として、なによりもプロダクトが重要であり、プロダクトがめざすビジョンへの共感がないと難しいと考えています。

作っておわり、の受託案件ではなく、継続的に開発して価値を高めるプロダクト開発に携わりたい、というところからSaaSエンジニアへの道を選ぶ人はうまくいくと思います。そこからだんだんと自分が関わるプロダクトへの共感が生まれてきてチームへ貢献したいという意識が芽生えていきます。

逆に「開発言語が〇〇だから」や「スプリントで開発しているから」などの理由によってSaaSエンジニアを選択するのはあまりおすすめできません。

開発言語やフレームワーク、開発フローはあくまでも顧客に価値を提供し続けるための手段でしかないため、そこが目的になってしまうと変化の多いSaaSの場合にはズレが生じてしまうことが多くなります。プロダクトの状況によってエンジニアからのジョブチェンジなどもあるので、それを受け入れられるような気概が必要です。

まとめ

自分たちのサービスのターゲットや料金体系を知ることで開発時の判断材料になり顧客へ価値を提供することができます。