SaaSエンジニアに求められるスキルをTHE MODELから考えてみた

こんにちは！
エンジニアの波多野(@hatamasa1988)です。

Qastというナレッジ共有SaaSを開発・運用しているany株式会社でエンジニアをやっています。

THE MODELを読んだのですがエンジニアの役割が書かれていないので勝手に考えてみましたww

SaaS企業のビジネスサイドについての情報は多いですが、エンジニアについての情報って少ないよねってことで、
SaaSスタートアップでのエンジニア経験を通して感じたことや、ビジネスサイドのTHE MODELへの取り組み方などを加味して一個人としての見解として捉えてもらったら幸いです。

THE MODEL

こちらSaaS界隈では超がつくほど有名な本。

日米のオラクル、セールスフォース・ドットコムを経て、マルケト日本法人の代表を務める福田康隆さんが継承し、みずから作り上げてきた営業・マーケティング戦略の粋について書かれています。

顧客獲得・契約獲得のプロセスを4つ分断して考えており、各プロセスの成果が次のプロセスの母数となるような共業プロセスになってます。

顧客の成功が収益を生む新たなビジネスモデルの構築を「再現性」がある形で設計したのがTHE MODELです。

THE MODELの内容を細く解説するのは本記事の主題ではないので超簡単にだけまとめます。

・マーケティング
来訪者数　x　 獲得率　＝　リード（見込み客数）

・インサイドセールス
リード　x　案件化率　＝　案件数（商談化）

・営業
案件数　x　受注率　＝　受注数

・カスタマーサクセス
受注数　x　更新率　＝　継続数

SaaSの売り上げは受注が積み上がることによって伸びていくのですが、時間軸が関わってくることによって「解約」も発生することになります。

つまり新規案件を取っていくことも大切だけど、同時に解約を防止して積み上げの速度を上げるのが理想でそのためにカスタマーサクセスという新たなプロセスも必要になってくるという概念です。

わからない人はググってみてください。
良い記事がたくさんありますのですぐに理解できると思います。

SaaSエンジニアに求められるもの

ここからが本題です。
THE MODELを読んだ方はすでに気づいていると思いますが、SaaSは売り切りのプロダクトや広告収入など従量課金のプロダクトと性質がだいぶ異なります。
そのため、エンジニアに求められるものも必然的に変わるということですね。

その前に、サービスやプロダクトによってエンジニアに求められるものが変わることが理解できてないエンジニアはヤバすぎるので、
求められるものに対してスキルを磨くかどうかはさておき、すぐにでも考えてください。

何となく下記の組み合わせと重みづけが変わってくると思っています。

・ドメイン知識
金融、不動産、アパレルのような分野

・ビジネススキル
営業対人交渉、マーケティング、マネジメントなど

・テックスキル
フロント、サーバサイド、インフラなど

・ヒューマンスキル
リーダーシップ、コミュニケーションなど

各要素の掛け算でそれぞれの重みが異なるという分析が最適かと思いますのでその観点も含めて書いていきます。

ビジネスとテックのバランス感覚(+ドメイン知識)

当たり前ですが、SaaSエンジニアが開発するプロダクト(=機能)がお金を生み出す唯一の源泉であるからです。

（最後にカッコでドメイン知識をプラスした部分については、ホリゾンタルなSaaSの場合はドメイン横断なので特定のドメイン知識が武器になることはあまりないと感じています。
逆にバーティカルなSaaSでは特定のドメイン知識があるとエンジニアであっても武器になると思います。）

THE MODEL風にいうとSaaSエンジニアはどんな役割になっているかというと・・・

認知し興味を持つきっかけとなるUIはマーケティングに寄与して、
課題を解決できるUXはインサイドセールスとして使い方の提案に不可欠、
契約するにはプロダクトと営業の力が必要、
顧客をサポートする機能や欲しいと思っていた機能を追加することでカスタマーサクセスにもなります。

つまり、エンジニアはビジネスサイドの全てのプロセスに関与し、精通している必要があると考えるべきで、ビジネスサイドとも盛んに情報交換をしていくべきです。

また、会社の規模にもよって、企画はディレクターが担当し、UI/UXはデザイナが担当することもあるかもしれませんが、SaaS企業の多くは産まれてまもないスタートアップ企業です。

かつ、スタートアップは役割をなるべく分断しない傾向があります。
（ビジネスサイド、プロダクトサイドの2つしかなかった会社もあります）

上記の「企画はディレクターが担当」よりもなるべく多くの人からアイディアをもらって、良いアイディアを採用しブラッシュアップしていった方が良いプロダクトになるに決まっているからです。
（これは史上最も早く1000億ドルの会社に成長したAmazonも成長戦略として取っている話しで、Amazonは全社をR&D部門と位置付けて全ての社員にアイディアをチャレンジする権限を与えているそうです。）

そしてプロダクトに対する最終的な意思決定はプロダクトオーナーの役割であり、プロダクトオーナーがエンジニアであることも多いのは技術、プロダクト両方面から考えられるからですね。

それ以前に、産まれて間もないスタートアップはディレクションもデザイナもいませんので、企画から全てエンジニアが担当するなんてザラにあります。

ですので、会社のビジネスをビジネスサイド同様に理解をして、良いモノづくりができる高い技術力を併せ持っていることが必須条件です。
コーディングしかできないし、しないプログラマはバリューを発揮できない環境です。

必要なのはエンジニアです。

プログラマはプログラムを書く人。エンジニアはエンジニアリング（＝科学を実用化し、人間の生活に役立てること）をする人です。
つまりエンジニアはビジネスとテックのバランス感覚が非常に大切になるということです。
当たり前ですが、作ったものが役に立たないではダメなのです。

そうは言いつつテックでは、

・顧客への洗礼されたUIを提供したい
・圧倒的なUXでないと競合優位性を保てない
・ビジネスの一旦を担うような複雑なロジックの実装
・永遠のベータ版なので拡張性はキモ
・企業情報を扱うのでセキュリティは万全にね
・高可用、高信頼、高安全、高保守の4高
・データ分析基盤
・マルチテナントアーキテクチャ

結構やることも考慮することも多くて、横断的に一定レベル以上の技術力が必要です。
拡張性、セキュリティやデータ分析基盤など箇所によっては高いレベルで設計・運用と実装のスキルが必要ですし、特にtoBのシステムとして4高には手を焼きます。

プロダクト・顧客思考

THE MODELの4つのプロセスの全てに関与するため、エンジニアにしても顧客思考が必然的です。

「お客様は神様」のように顧客の言いなりになることではなく、どうしたら顧客の課題を解決できるプロダクト作りができるかという視点です。
THE MODEL風に言うと「顧客の成功が収益を生む」からです。

そして、カスタマサクセスが定期的に顧客の声をキャッチアップしているので、ぶっちゃけC2Cのサービスよりも顧客の声は聞くことができますし、使ってもらってる実感もあります。

当然顧客から求められる機能は重要なのですが、SaaSに追加する機能は全顧客が利用するものなので、機能や課題の一般化が必要になるところも面白いところだったりします。

なぜその要望が発生するのか？を顧客側とプロダクト側から考える必要があります。
顧客の要望を鵜呑みにせずに、裏側に隠れている本質を解決できる機能に落とし込むには、徹底したプロダクト・顧客思考が必要になります。

SaaSは長い成長の時系列からすると継続率が大切になってくるので顧客の期待を常に上回るサービス提供（機能追加や機能改善のスピード）が大切になってきます。
それができないと競合に追い抜かれます。

エンジニアは技術のスキルアップや自分のやりたい技術一辺倒な人もちらほらいますが、SaaSは全員がプロダクトの成長を第一に考える環境なため、
やりたい技術や無駄なこだわりを突き通す人は向いてないと思います。

これも当たり前ですが、機能実装の方向性は会社・プロダクトの現状と成長を、エンジニアも第一に考える必要があるということです。

フットワークの軽さと改善思考

THE MODEL風に言うとSaaSは永遠のベータ版です。
常に顧客成功に導く機能追加と機能改善を続け完成しないためこう表現されています。
有名な話で、Gmailは2004年にリリースされ、その後2009年まで5年に渡ってベータ版として運用されていました。

一般的にベータ版は簡単に言うと試験運用版です。
市場で需要予測や機能に問題ないかを実際に限られたユーザ数など運用して反応を見るような方法として運用されます。

スタートアップは今までにない市場を開拓しているわけなので、新機能にしても顧客に受け入れられるかはリリースしてみないとわからないのが正直なところです。最小限に作ってリリース、ダメなら直すようなリーン的なフットワークの軽さが必須です。
それと同時に、顧客からのフィードバックがないにしても改善をしていく行動が必要になります（顧客は全部話してくれるとは限らない）

時にはデータ基盤を構築して、顧客の操作から課題を発見するような仕掛けを作る必要もあれば、自ら課題をヒアリングしにいくような行動も重要になります。

リーダーシップ

SaaSはwebサービスなため、テックの知見があるエンジニアがイニシアチブを取ってプロダクトを作っていく形が一番スピーディーで理想系なはずです。

また、SaaS企業でエンジニア比率は結構多いです。会社の半分くらいがエンジニアである会社も出てきています。（SaaSが必要とする機能追加と機能改善のスピード、収益力などを考えると半分くらいいる会社も必要な比率なのかもしれません）
そうなると組織開発ではエンジニアが働きやすい方向に、テックドリブンとかエンジニアドリブン？な方向に制度や環境を整えていくことが求められます。
それを一番わかってるのはエンジニアであるので、組織開発においてもエンジニアがリーダーシップを発揮して環境を作り上げる必要があると思っています。

エンジニアの働き方は他の職種の中でも最先端であり、これから他の職種の働き方にも必ず良い影響を及ぼします。
このコロナで証明されたように、テック系ベンチャーやスタートアップのようなエンジニア文化がある会社はリモートワークにあまり抵抗なく移行ができたはずです。

つまりSaaS企業ではエンジニアがリーダーシップを発揮するということは、もはや成長するにおいてmustであると言えるでしょう。

そもそもが少数精鋭のスタートアップ企業では全員がリーダーシップを持つことが必要だと思ってます。
立場上リーダーでなくてもよくて、「周囲を巻き込んで、目標達成に向けて課題を遂行を先導する」ようなことです。
別の言い方をすると主体的であれということですね。

最後に

最後はTHE MODELから外れてしまいましたが、

・ビジネスとテックのバランス感覚(+ドメイン知識)
・プロダクト・顧客思考
・フットワークの軽さと改善思考
・リーダーシップ

以上がSaaSエンジニアに求められるスキルになってくるでしょう。
検索するとyoutubeやまとめてある記事は山ほどあるので、エンジニアであってもSaaS企業に転職したい人はTHE MODEL読んでおくといいです。