ソフトウェア開発スキルを活かせるB2B SaaS 企業でのポジション
今回は、僕が主に AWS という大きな B2B SaaS 企業で見てきた中で、ソフトウェア開発を活かせる多様なポジションを紹介してみます。
B2B SaaS とはなにか
ソフトウェアをサービスとして提供し、それを企業や公共機関に対して売って生計を立てる業態です。別の言い方をすればクラウドビジネスとも言えますが、 インフラサービスや開発者向けのサービスだけではなく、バックオフィスだったり基幹業務効率化だったり、様々なビジネスが日夜生まれては消えていく、 とても活力のある世界です。
AWS の様な基盤となる B2B SaaS が成長したおかげで、その上にソフトウェアを載せてビジネスを回していくことが以前(10 年くらい前?)よりもはるかに簡単になって、 いろいろなアイデアがどんどんと生まれ、さらに成功した B2B SaaS に乗っかって次のビジネスが生まれていく、というような流れも感じますね。
また、基盤となるもの(生産コスト)がサブスクリプションであることも多いため、自分たちのビジネスもサブスクリプションになっているケースが多いのも特徴です。
B2B SaaS に必要な人材
ソフトウェア開発はもちろん大事です、それこそが商品そのものなのですから。しかし、いいソフトウェアを作れば儲かるというほど甘い世界ではありません。 どんないいものも人々に知られなければ売れませんし、成長のための数字を誰かが追いかけなければなりません。そもそも、ちゃんと儲かる料金体系になっているか、 顧客が本当に求めるものを作っているか、困っている顧客を適切に手助けできているか。こうした、どんなビジネスでも必要になる基本的なポジションは、 B2B SaaS でも例外ではありません。
B2B SaaS が特徴的なのは、そういったプロセスを適切に行うためにはどのポジションでも少なからずソフトウェアに対する理解が必要ということ、 そしてサブスクリプションであるが故に一度売ったら終わりではなく、長期的な信頼関係を築くことが重要になる点です。 そのため、各所のポジションでソフトウェア開発のスキルが活かせて、またビジネスが拡大するほどに顧客との信頼を広げる必要があり、こうしたポジションの必要性も どんどんと増えていきます。
また、B2B SaaS 自体は業界が変わっても大きくビジネスモデルやアーキテクチャが変わるものでもないので、ある企業で学んだスキルが割と他の B2B SaaS 企業でも活かせます。 なので、知り合いを見ていると B2B SaaS の企業間を渡り歩いていく人は結構多い印象です。
なぜ今この話?
ソフトウェア開発をしてる人とキャリアについて話をしていて時々感じるのが、ソフトウェア開発以外のポジションを知らないことが多くて、視野が狭くなってしまっていることがあるなということです。 かくいう自分自身もそうでした。B2C をやってた時には、世の中にはソフトウェア開発者とインフラエンジニアしかいない、くらいにしか思ってなかったのですが、 AWS で B2B SaaS を経験してみて、こうしたキャリアの幅に気づくことができました。1
僕は AWS にいるときに、Solutions Architect という Sales 側のポジションと、Software Developer という Engineering 側のポジションを経験できて、 前者では多様なポジションの人たちと一緒に仕事をし、後者ではそれらをサービス開発チーム側からも眺めることができて、幸運にもこの辺の図式が 良く見通せる位置にいたと思うので、せっかくなので共有しておこうと思います。皆さんの採用計画やキャリア形成の何かの役に立てば幸いです。
免責事項: 以下は僕の個人的な経験に基づく主観ですので、その前提でご覧下さい。AWS がこの通りに組織されているわけでもありません。
ポジション一覧
以下は主に AWS でのタイトル名を使ってますが、呼び方は企業や業界によってまちまちだと思います。適時読み替えをしていってください。
- Support
- Technical Support Engineer
- Technical Account Manager
- Sales
- Solutions Architect / Presales Engineer
- Professional Service
- Account Manager
- Business Development
- Marketing / Training
- Techncal Evangelist / Developer Advocate
- Technical Trainer
- Product / Engineering
- Product Manager
- Technical Program Manager
サポート - 技術的な調査等を通じて顧客との信頼関係の構築
Techncal Support Engineer
主にお客さんからの問い合わせに対して、技術的な調査を行い、お客さんの課題を解決していくポジションです。 サポートという名前から後ろ向きな仕事を想像される方も見かけるのですが、全くそんなことはなくて、 問い合わせに対してゼロから理論を構築していく非常に科学的な営みであり、僕が見てきたサポートの方は ソフトウェア開発者よりもはるかにスキルの高い人も多かったです。
一つ一つの調査を深く丁寧に論理的に行える力、それをお客さんや同僚に簡潔かつ正確に伝えられる文章能力などが重要ですが、 調査対象がソフトウェアなので、それらを支えてくれるのはソフトウェア開発スキルになります。
Technical Account Manager
これは呼び方と業務内容が各社バラバラになるので AWS で説明しますが、既存のお客さんを担当して、 そのお客さんの技術的な課題に最も詳しくなって、上記の Support Engineer や後述の Sales 等とも連携して お客さんの満足度を高めるためのポジションという認識です。AWS だとコスト最適化の提案なんかもしていました。
技術的な洞察力もさることながら、お客さんとのコミュニケーション、お客さんの課題を広く深く見て、同時に社内の リソースに対しても鼻が利く、そんな人達です。特に技術者よりのビジネスの場合、お客さんの技術力も高いので それと対等に渡り合えるだけのスキルが必要です。僕の知ってる TAM はどれもずば抜けて高くて、それ故にお客さんの信頼を 勝ち取ってる人ばかりで、大変尊敬しています。
セールス - 売上を通じてサービスとお客さんの成長に貢献
Solutions Architect / Presales Engineer
お客さんを担当しながら、サービス自身とお客さんの成長に技術面から貢献します。具体的には、まだサービスを使っていない お客さんに対しての営業を支援したり、既に利用中のお客さんの抱えている課題を把握してアーキテクチャの提案や、 新しい機能やサービスの紹介なども行います。2 AWS だと面白かったのが、売上の数値そのものは追わない(なので売上ベースの給与体系じゃない) ので、短期的には売上が下がる提案でもお客さんに良いものであれば普通に話をして、長期的な信頼を築いていきます。
TAM 同様にお客さんに負けない、むしろより広い深い視点から技術的な話をする必要があるので、 ソフトウェア開発スキルは非常に重要であり基礎になります。60 歳を超えてもバリバリと提案しまくっている知り合いもいて、頭が上がりません。 アーキテクチャの話をすることも多いので、たくさんのシステムを見てきた経験も活きます。
Professional Service
B2B SaaS だと、顧客ごとに完全カスタマイズするわけにはいかないので、どうしても手が届かない部分があります。Professional Service は そうしたラストワンマイルをお客さんのビジネスに踏み込んでコンサルティングしていくようなポジションです。 Presales とは違って、有償サービスになることが多いかと思います。
お客さんのビジネスそのものに一番近い場所で仕事をするので、ソフトウェア開発スキルも重要ですが、お客さんのビジネスを理解して 提案できるまさにコンサルティングのスキルも求められます。昨今はドメイン特化のコンサルティングも増えていて、 機械学習だったりビッグデータなどはそうした業務を現場でやられた方の知識経験は非常に重宝されます。
Account Manager
いわゆる営業というやつです。営業嫌いな人も多いと思いますが、営業がいなければモノは売れません。3 また、サブスクリプションのサービスを売るので、お客さんとは長期的に良い関係を維持しなければいけないです。 売上数値に対して目標をもっていて、達成するとめちゃくちゃ給料いいのが特徴です。
何故ソフトウェア開発スキルが営業に活きる?と思うかも知れませんが、特にお客さんがソフトウェア開発者だったりするサービスであれば 営業がソフトウェア開発経験者であることは大変に大きな強みになります。デモや技術的な問答を Solutions Architect よりも上手くできてしまう 営業の人も見てきましたが、あれは強いです。お金の面でも結果がそのまま跳ね返ってくるので、ガッツリ稼ぎたい人は技術営業のポジションは狙い目かもしれません。
Business Development
これも各社まちまちだと思いますが、サービスの数字的な成長に対して多角的にアプローチしていくポジションです。 例えば、どの様なイベントを企画するかといったマーケティングの要素から、新サービスを展開する計画、市場分析に基づく次の攻め手の提案、 現時点の営業数値に対して横断的に打てる施策の立案・実行、ロードマップの把握からお客さんとの接点を増やしてヒアリングを行う、 などなど、これまでのポジションだけだと穴が開いてしまう部分を自身のクリエイティビティで埋めていく とても創造的なポジションです。
AWS だと MBA を持っている元技術者みたいな人がたくさんいて、技術とビジネスの双方のバックグラウンドを使って 誰にもまねできないようなことを、泥臭くやっていけるような超人が求められます。 ソフトウェア開発に飽きてビジネスを学びたい/学んだ人が進んでいく道の一つかなと思います。
マーケティング / トレーニング - サービスをより広く深く知ってもらう
Techncal Evangelist / Developer Advocate
特に技術者相手のビジネスでは、同じ技術者として広告塔となって情報を発信し続ける人の存在は、マーケティングとしてとても重要です。 新サービスや機能をいち早く紹介し、より良い利用方法を常に解説し続ける Evangelist や Advocate がいることで、 コミュニティの形成にも繋がっていきます。
とにかく情報発信力が重要ですが、ソフトウェア開発のスキルがあればこそ、技術者相手のビジネスでは信頼が生まれます。 相手と同じ目線で、何がうれしいのか、どうやって使えばもっと良くなるのか、を語り続けられる、まさに伝道者のスキルが重要です。 ブログ記事や、サンプルアプリケーションなどを作ることも多いです。
Technical Trainer
トレーニングはマーケティングとしても重要ですが、それだけでなくセールスでも重要になります。Evangelist 等の情報では どうしても深いところや体系的な情報提供をすることが難しいですが、トレーニングによってそこを強固に補えます。 資格制度を展開しているビジネスでは、トレーナーの役割は売上にもなりお客さんのスキルの底上げにもなるので、更に重要な役割になってきます。
ここでもやはり、お客さんと同じ目線に立てるという意味で、技術者相手のビジネスではソフトウェア開発のスキルが活きます。 既存のトレーニングの資料の意図を把握するだけでなく、どういった資料があればもっと良くなるのかも常に考え続けます。 また、トレーニングそれ自体の専門性を持っている方は本当にすごくて、AWS の時には講師の技術を指導してもらえて感謝しています。
プロダクト / エンジニアリング - 製品開発とソフトウェア開発
Product Manager
製品について一番詳しい人です。コードを書いている人が一番詳しいでしょ?と思うかもしれませんが、違います。 詳しいとは、実装を知っているという意味ではなくて、製品の目的から仕様、システムアーキテクチャから制約、料金モデルから顧客層、 現在の課題、お客さんの声、市場の状態、ありとあらゆることを知っていて、どんな質問でもほぼ即答できる人達です。 そのユニークな目線を使って、製品の方向を考えて決めていくのが PM になります。
ソフトウェア開発スキルがあれば、実装に対する解像度があがり、開発チームとの会話もスムーズです。ビジネスが技術者向けであれば、自分事として製品の設計もできます。 何より、ソフトウェア開発では得られない、製品そのものの開発に注力できるので、製品に最もインパクトを発揮できるポジションです。 AWS 時代には数々の PM と一緒に仕事をしましたが、皆信じられないくらいにソフトウェア開発やコンピュータ科学の知識経験があり、驚愕しました。
Technical Program Manager
組織の規模が大きくなってくると、複数チームを跨いだプロジェクトが多くなりますが、船頭をとる人がいないと見落としが発生したり、クリティカルパスの 把握を見誤ってしまうことがあります。TPM はこうしたプロジェクトを引っ張っていく人達です。 TPM がいるプロジェクトといないプロジェクトと AWS で経験しましたが、安心感が全然違います。TPM がいると、自分たちの役割に集中できて、 それ以外のことをいい意味ですべて押し付けられます。TPM に全てが集まってくることで、正しい状況判断を下せるようにもなります。
TPM はソフトウェア開発チームと日々会話をするので、ソフトウェア開発スキルがあることは話が通じるということでとても重要です。 また、大規模開発をリードしたことのある人は多かれ少なかれこうした複数チームを跨って仕事をしたことがあると思いますが、 そうしたスキルをより直接的に活かせるのが TPM です。
まとめ
ソフトウェア開発スキルを活かせる B2B SaaS 企業のポジションをいくつか紹介しました。聞いたことのないポジションもあったのではないでしょうか? 世間的にはどうしてもソフトウェア開発者ばかりが注目されがちですが、ここに紹介したようなポジションがなければ、それらの役割が全て 他のポジションに降っていってしまうわけです。当然最初からこれらを全て用意することはないでしょうが、企業の成長に合わせて 適切に役割を切り出していって専門家/専任者を雇うことで、本来やるべき仕事に皆が集中できるようになっていきます。
個人のキャリアを考える際には、こうした多様な役割があることを頭に入れて検討してみると、思ってもみなかった道が開かれるかも知れません。 例えば、海外から日本にサービス展開をしたい企業があれば、まず Marketing、次に Sales と Support がくるわけで、 ソフトウェア開発だけを見ているとポジションがない企業でも、視野を広げるといくらでもポジションはあったりします。
一つのポジションで階段を上がっていくのも生き方の一つですが、様々なポジションを経験していくという生き方もあります。 いろいろやってみた結果改めてソフトウェア開発に戻ることもあって当然で、その場合寄り道していた時間が無駄になるということはなくて、 むしろソフトウェア開発しか知らない人よりも各段に視野が広くなるので、自分の付加価値を上げられると思います。
最後に、他にもこんなポジションあるよ、この記述はこっちの方がいいよ、このポジションのいい紹介記事があるよ、といったコメントがあれば ぜひ @riywo までお願いします!