成功するSaaSエンジニア組織は「なぜコミュニケーションするのか」を考える。Sansan CTO藤倉成太に聞く、組織づくりのポイント

SHARE:

本稿はベンチャーキャピタル、ALL STAR SAAS FUNDが運営するサイトに掲載された記事からの一部を転載したもの。全文はこちらから読める。同社のメルマガ「ALL STAR SAAS NEWSLETTER」出資先のスタートアップ転職に関するキャリア相談も受付中

SaaS事業においてサービス開発の核となるのがエンジニア組織。強い組織を作るために試行錯誤しているCTOも多いでしょう。

今回はエンジニア組織の拡大に成功した先駆者でもあるSansan株式会社のCTO※・藤倉成太さんに、「成功するSaaSエンジニア組織の作り方」をお話しいただきました。2021年に事業別組織から機能別組織へと体制を変えた理由や、組織の生産性を測るために必要なこと、マネジメント層に求められるコミュニケーションのポイントなどをうかがっています。

聞き手は、ALL STAR SAAS FUNDマネージング・パートナーの前田ヒロです。

※役職は2022年4月時点。現在は執行役員/技術本部 海外開発拠点設立準備室 室長

SaaSプロダクトは、開発を止めてはいけない

前田:最初に藤倉さんご自身のことと、Sansanの現在地点を教えていただけますか。

藤倉:Sansan株式会社の執行役員とCTOを務めています。Sansanには2009年に入社し、エンジニアとして営業DXサービス「Sansan」の開発に携わったのち、開発部長を経てCTOに就任しました。

Sansanの現在の全従業員数は1,200名ほど。エンジニアや研究員だけだと約300名が在籍しています。これまでにクラウド請求書受領サービス「Bill One」やクラウド契約業務サービス「Contract One」など多数のプロダクトを展開してきましたが、中でも「Sansan」のプロダクトが一番長く、2007年6月の創業時からもう15年作り続けています。

「今はメンテナンスフェーズですか」「完成しきってますか」と聞かれることもあるのですが、そんなことはありません。SaaSのプロダクトは進化が止まると事業が止まってしまうので、開発し続けなければならないんです。

進化しながら開発を続けるには、ただ機能を追加していくだけでは足りません。2019年は「名刺管理から、働き方を変える」、2021年は「名刺管理から、営業を強くする」、2022年は「営業を強くするデータベース」。このように、「Sansan」は毎年のようにプロダクトのタグラインを変えています。

これはマーケティングメッセージであると同時に、プロダクトのコンセプトを表現しています。コンセプトが変わることは、世界観が変わること。エンジニアリング的に言うと、ドメインのモデルが変わることですね。SaaSが進化し世界観がアップデートされていけば、システムの規模やデータベースのスキーマ、アーキテクチャも変わる必要がある。そのため、開発はプロダクトがクローズするまで永久に終わらないものと言えます。

マルチプロダクトなら“機能別組織”が効率的

前田:Sansanは2021年7月に会社の組織体制を大きく変えたそうですね。

藤倉:もともと「Sansan事業部」「Bill One事業部」といった事業別組織だったのを、機能別組織に変更しました。プロダクトの増加にともない会社の戦い方を変えていくためです。

事業別組織は営業やマーケティング、プロダクト開発、カスタマーサクセスといった全メンバーが一つのプロダクトに集中して携われるのが利点。一方で、現在のSansanのようなマルチプロダクト戦略の場合、縦割り体制の事業別組織では余計な調整が増えてしまいます。

事業ごとの「点」ではなく、オールSansanの「面」で戦う。そのための組織変更だと僕は解釈しています。実際、以前と比べて注力したいプロダクトのためにエンジニアリソースやマーケティング予算を割きやすくなりましたし、プロダクト同士の連結がスムーズになりました。

また、事業別組織では事業部長がプロダクトと同じ数だけ必要になりますが、責任の多い役職をそれだけ揃えるのは大変。縦割り組織はマネジメントも複雑になっていくので、機能別組織にすることで社内体制をシンプルにする狙いもありました。

藤倉:具体的に変更後の組織をみてみます。

マーケティングセールスやカスタマーサクセスを行なうのがビジネス統括本部、プロダクトマネジメントやプロダクトUXデザインを行なうのがプロダクト組織。そして社内のあらゆるエンジニアリングを一手に引き受けているのが技術本部です。

技術本部にはプロダクトごとのエンジニアリングユニットが存在しています。人数は「Sansan」が一番多く、現在50〜60人ほど。「Eight」は30〜40人、「Bill One」は40人ほどですね。加えて、全プロダクトのモバイルアプリケーション開発を行なう部署やクオリティアシュアランスを行なう部署があります。「Sansan」であれば、全体で70〜80人が開発に携わっているような規模感を想像していただくといいでしょう。

前田:事業別組織から機能別組織に切り替えた時、現場からはどんな反応がありましたか?

藤倉:現場のメンバーは、最初はすごく不安だったと思います。組織体制が変われば、誰に何を報告するかといったレポートラインも全部変わりますから。ただ、そこで混乱を生みたくなかったので、現場のみんなには「コミュニケーションする相手も、業務の内容も変わらない。ソフトランディングさせて必要な変化を後から追いつかせるから、自分のペースで適応してほしい」と繰り返し伝えていました。

結果的に、変更から1〜2ヵ月が経った頃にメンバーから「組織変更する意味ありました?」と聞かれたことがありました。これは、ソフトランディングがうまくいった証拠だと捉えていますね。その上で現在は次の段階として、ばらばらだった開発レポートのフォーマットやパフォーマンスの測定方法を揃えるなどの整備を進めています。

前田:振り返ってみて、最初から機能別組織を採用していたほうがよかったと感じますか?それとも、事業別組織体制のフェーズがあったからこそ今の成功があるのでしょうか。

藤倉:事業別組織の体制も必要だったと思っています。当社の場合、例えば「Sansan」のローンチ直後は世の中に類似のプロダクトがありませんでした。かっこいい表現をするなら、当時は市場を作りにいかなければならなかったんですよね。

「こんなプロダクトは見たこともないし、誰が買うんですか」と言う顧客に、「僕らはこれがある未来を作るんです」と伝え続けるプロセスです。そこではメンバーが一丸となれることが重要で、事業別組織だからこそ突破できたフェーズはあると思っています。

生産性の測定で重要なのは、同じ基準であること

前田:ここからは、具体的にエンジニア組織の作り方をうかがっていきます。まず、藤倉さんにとって「マネジメント」とは一体、何なのでしょう。

藤倉:開発組織のマネジメントに焦点を当てれば、その意義は開発力の最大化と効率化に尽きるでしょう。メンバーの活躍を測定し、評価することがマネジメントです。個々のエンジニアの生産性向上やその評価方法を考えるとともに、ヘッドカウントを増やすことで戦闘力が上がるなら採用もやるべきだと考えています。

前田:組織の生産性を高めるために意識していることはありますか?

藤倉:前提として、エンジニアの生産性を測ることは深遠なテーマで、そこに答えはありません。もちろん評価をしなければうまくいっているかわからないですし、きちんと測定すればメンバーの手応えにもつながります。だから、必ずやるべきですが、完璧な精度で測定するのは難しいでしょう。

生産性を測る際に重要なのは精度の高低ではなく、常に同じ基準であることです。

開発プロジェクトの工数の見積もりを例にとると、僕が開発部長の時はすべて自分が見積もりを行なっていました。他には、信頼のおけるトップエンジニア1人にお願いしたり、担当者を3人にして合議制にしてもいいですね。体制は色々考えられますが、メンバーを固定すれば、基準ないし精度は一定を保てます。

見積もりをもとに各開発チームに仕事をお願いすると、いつも早く完了するチーム、遅く完了するチームが出てくるはずです。早いチームは背景を理解できていたり動きが素早かったりするでしょうし、遅かったチームはできていないことがあるでしょう。一定の精度で測定し続けることで原因がわかり、結果としてエンジニアのパフォーマンス向上につながります。

前田:なるほど。他に何か工夫はありますか?

藤倉:エンジニアには、1日でどの作業にどのくらい時間を使っているか記録してもらっています。1日8時間働くとして、そのすべてを開発業務に当てられる人はいません。会社が大きくなるほど、全社会議、採用面接、事業部門のミーティング、SaaSとしての運用作業も出てきます。そこで、開発以外に割く時間が増えている傾向にあれば、それらを減らせないか考えます。

あとは、運用コストが30%を超えるものがあればアラートが出る設定も取り入れています。システムが複雑な場合などやむを得ないと判断するケースもありますが、その際も30%というひとまずの基準があることで、「アーキテクチャに困難があって運用コストが上がっているなら、先に技術的な投資をすればトータルコストは安くなるね」といった話ができる。見える化、数値化のメリットですね。

CTOも、採用のOKRを持つ

前田:続いて採用についてうかがいます。藤倉さんはSansanがまだ本当に少人数の時から在籍していますが、採用のフェーズが変わったと感じた時期はありますか?

藤倉:私は入社から13年で、社員番号は18番。エンジニア採用も長年見続けてきましたが、常にアクセルべた踏みという印象ですね。カルチャーフィットや経験を考慮しながら、いつも採れるだけ採用してきました。

十分なリソースで開発が行われなければ事業はグロースしないので、当然、採用には力を入れるべきです。

前田:「採れるだけ採る」という考えをもとに、特に効果的だった取り組みはありますか?

藤倉:状況が一変するような画期的な取り組みはありません。エンジニアは売り手市場でどこも取り合いですし、今も苦労の連続です。

Sansanの場合は、エージェントからご紹介いただくケースが一定数あります。エージェントに足繁く通って、自分の気持ちや事業で成し遂げたいことをしつこいくらい、細かく話していると、他にないスカウトの情報をいただけることもあるので、それは効果があったかなと。

あとは露出を増やしてSansanの名前を覚えていただくなど、細かな努力を積み重ねて少しずつ採用のクオリティを高めていきました。

前田:エージェントも含め、エンジニア以外の方へ自社の魅力を伝えるために、CTOとして工夫している点はありますか?

藤倉:一つは当社のミッションである「出会いからイノベーションを生み出す」がベースにあって、『Sansan』といった営業DXサービスがある、という全体像を伝えること。

Sansanは、人と人の出会いの証しである名刺だけにとどまらず、企業と企業の出会いの証しである請求書や契約書といった領域でも事業を展開、「ビジネスの出会いの価値」に向き合い続けている会社です。

日本国内においては「つながり」ができる瞬間の代表的な行為が名刺交換だから、それをサービス化しただけです。僕も「名刺交換サービスとして大きな企業を目指したい」と言われたら、きっと入社していないと思うんですよ。僕自身も一人のエンジニアとして、それだけのサービスだったら作りたいとは感じないでしょうから(笑)。

もう一つは個人的な感情に基づきますが、日本のソフトウェアやビジネスが国外でも結果を出せるようにCTOを務めている、という意志を伝えること。前職時代にアメリカで仕事をしていると、日本のサービスはグローバルで全然知られず使われない現状があった。でも、僕は日本のエンジニアが優秀だと思っているし、それを証明する事例を作りたいのです。

ソフトウェアならば、国内だけでなくグローバルで何百万人、何千万人に使ってもらえる可能性があって、そういったサービスに携われたら楽しいはず。それこそが醍醐味だとも思っているんですね。特に、エージェントに対しては「藤倉CTOはこういった気合いを胸に臨んでいるんだ」と感じてもらい、他社との差別化ポイントになるように意識しながら話しています。

前田:早い段階から、藤倉さんは採用のKPIを持っていたんですよね。

藤倉:当時は取り組みを重ねて3ヵ月でようやく1人採用できるような状況だったので、KPIと呼べるものではありませんでしたけどね。僕が採用に関わるようになったのも、たまたまです。

ある時、応募してくれたエンジニアについて当時の上司から「技術はたしかだけれど、カルチャーフィットが心配で。どう思う?」と意見を求められたのがきっかけで。それからも都度意見していたら、だんだん採用に関与することが増えていきました。

前田:そうだったんですね。CTOが採用のOKRを持つことについてはどう考えますか?

藤倉:CTOのミッションによりますが、僕は開発のパワーを最大化することを自分のミッションとして持っています。開発能力を高めるためにヘッドカウントを増やすのは一つの手段ですし、「これは人事の仕事だよ」と切り離すことはできないと考えていました。人事と密に連携しながら、人事のOKRと、エンジニア組織としての採用のOKRを合わせて進めています。

BRIDGE編集部註:この後の『面接は「エンジニアの市場価値が高まるか」で見極める』の続きはこちらから

BRIDGE Members

BRIDGEでは会員制度の「Members」を運営しています。登録いただくと会員限定の記事が毎月3本まで読めるほか、Discordの招待リンクをお送りしています。登録は無料で、有料会員の方は会員限定記事が全て読めるようになります(初回登録時1週間無料)。
  • 会員限定記事・毎月3本
  • コミュニティDiscord招待
無料メンバー登録