BtoB SaaS の組織は最小規模の躍動するチームにする

以前 3 年間で ARR が 2 億円規模の SaaS プロダクトを作ったのですが、その時の組織体制は 2 ~ 4 名でした。個人的に立ち上げ ~ 拡大期のチームはなるべく少人数で走ることが重要だとおもっていて、今回はそんな BtoB SaaS のチームについて書いていきます。

前提

• 主に立ち上げ ~ 拡大初期を想定しています。

• セールスや運用でマンパワーが必要な場合はこの限りではありません。例えば飲食店向けのプロダクトなので一斉に全国的に営業が必要 といった場合は（うまくやればアライアンスの強化で自社リソースの必要性を下げられたとしても）初期段階から大量のリソースが必要になるでしょう。

• そのため特定の業界向けのバーティカル SaaS や大手企業のみをターゲットとしたプロダクトなどのイメージです。

• 少人数であることは各メンバーの守備範囲が広いことがある程度前提になります。

小規模なチームの利点

小規模なチームは様々な利点があります。当たり前なもの含め書き出していきます。

• 人件費を抑えられる：SaaS 事業において最大のコストは人件費です。チームの人数が少ないということはそれだけ人件費を抑えやすく、損益分岐点が後ろに来やすい構造のプロダクトでは特に初期の人件費を下げることは大きなメリットです。

• 組織運営コストが低い：メンバーが多い場合、彼らへの情報共有、ビジョンの共有と共感の醸成、人事評価、教育、メンタルケア .. などなどピープルマネジメントのコストが比例して増大していきます。

• 事業運営スピードが上がる：重要なものでも数人で意思決定できると様々な利点があります。例えば開発予定の機能を調整することで特定のクライアントとの商談を受注につなげたり、広告出稿・展示会出展・業務効率化のためのツールの導入 .. などあら施策を即断即決できます。

• 起動力が高い：チーム人数が少ない場合おのずと各メンバーの守備範囲が広く、ビジネス周りが全て見れる人がいたりフルスタックエンジニアがいたりします。そんな人材が多いチームでは、例えばプロダクトをピボットし異なる領域の技術を取り入れたり、販売戦略をセールスからマーケよりに方向転換しても同じメンバーで引き続き走ることができるといったメリットがあります。

どうやってチームを作るか

ではどうやってそんなチームを作るかについて、戦略を紹介します。
想定としては5人目くらいまでのメンバージョインのイメージで、起業家本人が2人目以降を探す、もしくはある程度の規模の企業で新規事業を立ち上げるときのメンバーを探す といったシーンを思い浮かべてください。

どのような方を採用するかとどんな環境を作るかの両面が重要だと思っており、それぞれについて記載します。

どんな方を採用するか

ここまでの流れで「なんでもできるスーパーマン」を採用する必要があるように思われるかもしれませんが、現実的にそんな人材はあまりマーケットに出ませんし、ブランド力のある有力スタートアップや海外テック企業からも引く手あまただとするとなかなか難しいところです。
が、そのような方に会えたとすると「なにもないこと」に魅力を感じてもらう、という方向性は意外と効果があります。「なんでもできる方」にはその守備範囲の広さから「なんでもやってしまいたい」と考える方もいて、そのような方には一定以上の規模を超えた組織はおもいきりスキルを発揮できないと感じることがあるためです。
また、なんでもできる方ではなくても 主体性が強い・興味関心が強い・向上心が強い・責任感が強い といった性格の方であればジョインいただいた後にスキルを伸ばしていく という方向性も考えられます。

どんな環境を作るのか

チームが自走できており、それ故に前述したような方が躍動できる環境を作ります。

チーム内の環境作りとして、以下のような要素が重要です。
いずれも目的はそれぞれのメンバーが自分が事業のオーナーシップを持っていると感じられ、主体的に動き仕事に没頭しできひいてはパフォーマンスが一番高い状態になることです。

• 各人の意思が尊重され、それぞれが主体的に動ける

• できるだけ全ての情報をオープンにする

• 事業や顧客に向き合う以外の時間をなるべく減らす（報告・申請・勤怠 .. といった社内仕事を減らす）

またもしある程度の規模の社内でこういったチームを構築する場合、他のチームや経営からは以下のような状況を実現できると良いです。

• チームにできるだけ権限を与える

• チームに過度に干渉しない

いずれも意外と難しいことではなく、ようするに意思のある人が好きに動けるようにすることで、自然と「好きこそものの上手なれ」状態ができあがるイメージです。

小規模なチームの懸念点

と、小規模チームは素晴らしいという論調でここまで来ましたが、もちろん懸念点やデメリットも存在します。
ここではそういった点についての対応方針を記載します。

属人リスク

チーム人数が少ないと、どうしてもそれぞれの領域がそのメンバーに依存し属人的になってしまう傾向が否めません。特に顕著なのはエンジニアで、スキルの高いエンジニアが多くの領域の開発をしてきている場合、そのエンジニアがチームを去ってしまうリスクは甚大なものです。
そのため、すくなくともエンジニアサイドはこのリスクヘッジをしておくべきと考えており、以下のような活動は重要かと思います。

• 2名以上はエンジニアがいる状態にする

• 常に採用活動を実施する

• ちょこちょこフリーランスの方にヘルプいただき関係性を作り、いつでも声がけできるようにしておく

• なるべくドキュメントを残しておく

ビジネスサイドも比較的リスクは低いとはいえ属人リスクはあります。エンジニア同様最低人数を引き上げるということもありますが、個人的にはビジネスサイドの業務はギリギリまで自動化・仕組み化しておくことが本質的なリスク回避になると考えています。例えばマニュアルやユーザーガイドを拡充することで問い合わせ対応の属人性を下げる、提案書はいくつかのテンプレートにしておいてスキルのばらつきが出たとしてもある程度均質的なセールス活動ができるようにしておく、といった具合です。

社内分断リスク

またもしこの小規模なチームがある程度の規模の企業の中に存在する場合、そのチームと他のチームとの距離は注意が必要です。
チームが自立して動いている状態を作れると、その反面そのチームは社内の他のチームとの協業が少なく、悪い意味でも独立してしまいがちです。
単純に接触が少ない他のチームというのはあまり好意的に映らないものですし、「どちらが優れているか」といった考えに至りがちです。
これに対しては以下のようなことで対策ができると良いです。

• チームの責任者（事業責任者 / PdM / プロダクトオーナー 等）がチーム内で他のチームを称賛する

• 経営陣がお互いのチームを称賛する

事業成長とチーム体制の拡大

冒頭に記載したとおり、この記事では立ち上げ ~ 拡大初期をイメージして書いています。事業が順調に成長している場合、その後着実に売上規模があがり、次第に定型的に事業が回っていくようになります。
そのような時期に入るとチームは少数精鋭からある程度の規模かつそれぞれのメンバーの職務がはっきりとしてきます。
拡大中期からの組織運営についてはまた別の機会に書ければと思います。