CTOとVPoEの4人が語る、採用・待遇・マネジメント・コミュニケーションetc. 「成功するエンジニア組織」の作り方
CxO塾！とは？
BNGパートナーズでは、「CxO塾！」でベンチャー企業のCxOにご登壇いただき、自社のアップデートに役立つ情報をお届けしています。
10月のテーマは「急拡大するエンジニア組織」。エンジニアにかけるコスト、CTOやVPoEの役割、事業フェーズごとの組織はどうあるべきなのか。テモナ取締役 中野賀通氏をモデレーターに迎え、Sansan CTO藤倉成太氏、クロスガレージ CEO是澤太志氏、Showcase Gig CTO石亀憲氏の3名が登壇。これまでの経験や現在の取り組みなどについて意見を伺いました。
（撮影：植田 翔／取材・文：安住 久美子）
【Speaker】
■Sansan株式会社 執行役員CTO 藤倉成太 氏
オージス総研でシリコンバレーに赴任し、現地ベーンチャー企業との共同開発事業に携わる。帰国後は開発ツールなどの技術開発に従事する傍ら、金沢工業大学大学院工学研究科知的創造システム専攻を修了。2009年にSansanへ入社し。現在はCTOとして、全社の技術戦略を指揮する。
■合同会社クロスガレージ CEO／代表社員 是澤太志 氏
ITエンジニアとして愛媛のベンチャーで2年間働いたのち、モバイルゲーム会社、Speeeなどで開発事業責任者、採用責任者などを経験。現在は、12社目のメルカリで執行役員 VPoEを努めながら、自身が立ち上げたクロスガレージCEOも努める。
■株式会社Showcase Gig 取締役CTO 石亀憲 氏
大学卒業後、受託のシステム開発会社を立ち上げ、エンジニアとして開発事業に従事したのち、ミクシィとの合弁会社tuthを設立。副社長に就任する。2012年にShowcase Gigを共同設立し、CTOを務める。
【Moderator】
■テモナ株式会社 取締役CTO 中野賀通氏
大学卒業後、中学・高校の教員を4年経験したのち、ベンチャーにエンジニアとして従事。クラウド事業やマーケティングのコンサル、新規事業立ち上げなどを経験。2014年にテモナへCTOとしてジョイン。
この記事のPOINT
・会社のフェーズに合わせた組織づくりの重要性
・エンジニア組織の人材配置の考え方
・ビジネスサイドとのコミュニケーション
会社のフェーズに合わせ、必要なポジションを置くために
中野氏は最初に、会社の規模、エンジニア組織の役割、年収について一般的な体制をまとめたスライドを示した。人数の三分の一がエンジニアという組織をイメージしており、会社規模のステージに、役割や年収が対応している。なお、年収は創業メンバーを想定しており、途中から入る人は年収レンジが1段上がる場合が多いという。
出典：CxO塾！「急拡大するエンジニア組織」
石亀氏：僕の場合は会社規模ステージ1のところからのぼっていって、3が長かったですね。PMFを経て、今は4のステージ。会社全体で70名、エンジニアは20名ですが、まだVPoEはいない状況です。
是澤氏：テックの人と事業の人と分れる場合があるので、リードエンジニアがステージ2にも食い込んでくる場合もあるかもしれません。最近、VPoEって何人必要なんだろうと思うんですよ。CTOとVPoEを役割で分けるんじゃなくて、ビジョンを策定する人とそれを遂行する人で分けると、VPoEって数が足りなくなってしまう。ここの考え方が、日本と海外の違いなんじゃないかと気がついてきて。VP of Engineering、その下にDirecter of Engineering、その下にEngineering managerとなっていくと、CTOとVPoEは同列には語れないですよね。会社によってはVPoPがいる場合もありますし、CTOとの違いもよくわからなくなってきています。
中野氏：役員でVPoPの人ってほとんどいないですよね。日本の会社だと、プロダクトに注力している人が経営のほうまでグイグイ行くというのは少ないですね。
藤倉氏：Sansanの場合は、2018年6月に僕が開発部長からCTOになり、同時にVPoEも置きました。他に開発部長がいて、その下に開発マネージャーとそれぞれの役割を持っています。
これらは計算して採用したり、育ててきたかというとそうではなくて、そこにいる人の能力と特性、そして意思の組み合わせだったんです。組織にポジション欲求があり、その能力を持っている人を置いていく。足りないピースを少しずつ埋めていくような作業だと思います。
是澤氏：GoogleってCTOいないらしいんですよね。CTOオフィスっていうのがあって、そこで話し合っている。そういうのも参考になりますね。
中野氏：注力すべき役割があったときに、その役割を作ってあげるというのは正しいかもしれないですね。ただ、スタートアップで5人のうち2人がエンジニアというような規模だと、CTOでも全部やらなくちゃいけないところも多いですね。
是澤氏：CTOが組織の中から上がってくる場合、リードエンジニアがCTOになりますよね。もしくはCTOという肩書をもったリードエンジニアがいるという状況です。ほとんどの場合は、いざ採用やビジョン策定をはじめるとなったとき、ついていけないケースが多いんじゃないかな。そのあたりの言語化が得意じゃないという理由で。Sansanさんのようにやれるケースはめずらしいと思っていて、外からの採用に頼る組織が多いのが実情じゃないでしょうか。
中野氏：藤倉さんはどこのポジションでも、結局できるんじゃないか説ですよね（笑）。
是澤氏：そうなんです。もともとポテンシャルの高い人が最初からいたパターンですよね。いろいろな会社で面談とかさせてもらうんですけど、下からあげていこうとする場合は、だいたい厳しいです。採用は取り合いになりますよね。
エンジニアにかける「コスト」ではなく「投資」と考えるべき
図によれば、会社の規模ステージ2（5~10人）、プロダクト開発責任者の年収相場は600~800万円。しかし採用市場のリアルな流れとして「年収の下限は上がっている」というのが登壇者の総意だ。高騰するエンジニアコストを経営としてどうみるのか、組織づくりはどのように進めるべきなのか。
石亀氏：プロダクト責任者クラスとなると、600~800万という金額では難しいかもしれませんね。
是澤氏：育成を前提にポテンシャルの高い人を採用するならば、新卒のほうが良いというのも現実論としてありますよね。また、図の下のほうになると株をもってないケースが多いです。どこのタイミングで入社したかにもよりますし、役員クラスでも後から入った人は1％くらいしか持っていない場合もありますね。
Googleとかインディードとかは、エンジニアに日本の役員クラス以上の給料を出すことがあるんです。そういったエンジニアは複数プロダクトをリードできるような人材なので、生産性も違います。ビジネスに大きな影響を与えるのでそれだけの価値があるわけです。ただそういう意思決定をできるのが、経営としてすごく大事だなと思いますね。
藤倉氏：会社のフェーズに沿ってみれば、この年収はだいたい合っていますよね。スタートアップの頃って、売上がないのでこの金額しか出せないですしね。でも、今のSansanでリードエンジニアをとろうとしたら、この段が1個ずつずれているかなと思います。採用市場でいえば、この金額では難しいという感覚ですね。
是澤氏：Speeeのときは、基本的にマネージャーやテックリードクラスの採用をやっていました。現場エンジニアを先に採用していて、アーキテクトを決める人と考え方や方針が合わなかったら「どちらを選択するの？」となった場合、マネージャーやテックリードの意見を優先することになります。技術や組織に対してのオーナーシップと何かを変える強い意思を持っている人材ですからね。基本的にCTOクラスの人、開発部長クラスから採用していく。
中野氏：既存の組織があって、新しい人が入ったときのハレーションは大丈夫なんでしょうか。
是澤氏：それは気にしていられないですね。やはり差はあるんですよね。やってほしい役割も違いますし、より難易度の高いことをやるポジションの人はチャレンジしているので、高くて当然です。
藤倉氏：ハレーションというところでいうと、上のレイヤーの人を組織にパチっと入れたときに、その人がアジャストできるのかというところ。下からの信頼を自分の力で勝ち取らないといけないわけですが、それができる人というのはあまり見たことがないですね。出来る人はめちゃくちゃ優秀です。ですから、あえて下からあがってもらい、同じ努力をする中で成果の高さを示して上がってきてもらう、というのを前は意識してやっていました。でも、最近はそれがパチっとはまるようになってきたんですね。
中野氏：経営陣がハレーションがおきないようにコントロールしはじめたということですか？
藤倉氏：いえ、特にそういうわけではないんです。会社のフェーズがまだ若いころは、たとえ部長職でもやらなきゃいけないことが多い。全部をまんべんなくカバーできる人材って、なかなかいないですよね。でも組織が大きくなり、組織的な機能が分かれて、その連携がうまくできるようになってくると、ここさえできればはまりやすい、というふうになってきたのかもしれません。
是澤氏：言葉を変えていうと、ドメイン知識の範囲が変わってきているというのがありますよね。最初はドメイン知識が社内で閉じているので、社内のドメイン知識を吸収しないと成功しない。でも事業ドメインが増えたり、アライアンスを組んだり、自分たちの既存のアセットを飛び越えてしまうと、外から来た人のほうが活躍しはじめるフェーズになると思うんです。
石亀氏：うちも、だんだん規模が大きくなり、外との関わりもおおきくなってきています。内部のドメイン知識はたまってきているので、外部をどう使うかというのは、切り分けていきたいというのが、今思っていることです。僕がCTOとして全部やっているのがボトルネックになる可能性もあるので、適切に分けていこうと考えています。
中野氏：会社のステージに合わせて、目的にあっている人を採用しないと失敗するということ。事業自体が伸びていると変化に対応せざる得ない組織になっているので、そういうときほど優秀な人材をバチっと入れていくチャンスなのかもしれませんね。
BtoBこそ、エンジニアは技術的なチャレンジができる
次に、プロダクト・プロジェクトにおいて、エンジニアはどう関わるべきなのか。中野氏はスライドにまとめた。
中野氏：スライド上側の緑の部分はウォーターフォールに近いところで切っています。ビジネス構想、企画、基本設計、開発、テスト、運用・保守というパッケージ開発みたいなイメージです。
下側がまずCPF（Customer Problem Fit）、お金を払って時間を使ってでも解決したい課題が、そもそも市場に存在していて、どういうペルソナの人なのか。PSF（Ploblem Solution Fit）、そのプロブレム自体が僕らの考えているソリューションでフィットするのか。SPF（Solution Product Fit）、ソリューションをプロダクトに落としたとき、解決策になっているのか。そしてPMF（Product Market Fit）、新規開発も含めてやったときにプロダクト自体がマーケットにフィットするのか、というフェーズで分けています。
エンジニアが関わるのは、この一連の流れの中の赤い部分だと思います。
出典：CxO塾！「急拡大するエンジニア組織」
是澤氏：エンジニアだけでやっちゃうパターンも最近多いですね。プロトタイプで、エンジニアが一人で考えて、一人で作ったものを売るみたいな。技術リテラシーが高い人たちが増えているというのもあって。
中野氏：直近でいうと、ChatWorkなんかもそうですよね。社長が社内システムとして作ってみたら、プロダクトの主力製品になったという。
是澤氏：今後はそういうほうが可能性感じますね。日本という市場が成熟してきて、マーケットイン的なやり方での成功が厳しくなったというのもあると思います。英語圏や中国、グローバルを見て日本語以外の言語でチャレンジするのも必要になってきます。
中野氏：Showcase Gigは今7年目ということですが、プロダクトはPMFするところまで何年かかったんでしょうか。
石亀氏：5年くらいはかかりました。
中野氏：よく耐えましたね（笑）。
石亀氏：理念とか目指しているところは良いとまわりからも言っていただいて、皆さんが応援してくださって。それを信じて頑張ったということですね。今はようやくマネタイズが見えてきて、PMFを高速でまわすようなことをやっています。
中野氏：Sansanは今個人向けの「Eight」もありますけど、BtoBの「Sansan」が長かったですよね。
藤倉氏：法人向けのプロダクトSansanが黒転したのが、3年目だったと思います。一方で、個人向けのEightは、ローンチから7年くらいやってきていて、これからマネタイズしようというフェーズです。Eightのアクティブユーザーは250万人くらいいるんですが、とにかく数を増やす、それまでは赤字でもいい、という考え方でずっとやり続けてきたんです。そういう道筋もありますよね。
中野氏：BtoBのプロダクトで足回り稼いで、BtoCの新規事業の足回り作るというのは、典型的にキレイなやり方だと思います。是澤さんがいたSpeeeも、同じやり方ですよね。
是澤氏：間違いないですね。BtoBで稼がないとエンジニア採用や育成が満足にできないですし、モノを作る人たちは資産なので投資しなければならないですよね。ですからBtoBでちゃんと稼がないといけないと思ってますね。
中野氏：BtoBになるほど、エンジニアを囲うのは難しくないでしょうか。
是澤氏：いや、GoogleってBtoBじゃないですか。でもエンジニアが集まっていますよね。だからそこにいかに投資するかなんですよ。Speeeになぜいいエンジニアが集まったかというと、エンジニアに投資していたんです。営業さんになんて言われようと、エンジニアには良い椅子だったり、エンジニアだけは勤務時間もフレキシブルだったり。BtoBの会社だとそれができるんですよね。
僕はよく言っているのは「BtoBの会社でなぜ技術的チャレンジができないのかわからない」と。営業能力があって、チャレンジした結果、障害を起こしても営業さんが謝ってくれて、付き合いもあるからそれでおさめてくれることが多い。でもtoCだったらユーザはすぐに離れちゃうじゃないですか。なので「toCのほうが技術的チャレンジができる！」、というのは実は幻想だったり（笑）。
中野氏：なるほど、ビジネス的な観点で見たときは逆なんですよね。
是澤氏：そういうチャレンジをやっていかないと、UXは高まっていかないと思うので。ビジネスリスクを負った技術チャレンジをしてもまもれる仕組みがあるところが、今生き残っている気がしますね。
中野氏：UI、UXでいうとtoCから発展するイメージがあって、BtoBになると会社が投資しているか否かが見えるかどうかで変わってくるんでしょうね。
是澤氏：そのためには経営陣に技術をわかる人、技術管掌役員がいて、この投資に対してどう意思決定をして経営を納得させていくか。それが大事なんじゃないかと思います。
中野氏：技術管掌役員が経営の中で発言権を持たないと、うまくいかないということですよね。
是澤氏：そうですね。それはSpeeeのときに感じましたね。
石亀氏：うちの場合は、もともとCEOの新田がミクシィにいて、エンジニアの環境をよく知っていました。ですら、最初からエンジニアの椅子を良くしようとか、端末なども含め、来てもらいやすい環境は突き詰めていきましたね。
中野氏：環境整えるのも、投資と割り切れば安いものだというのもありますよね。なかなか理解は得られないんでしょうけど。
石亀氏：そういう理解を増やしていくのが、僕らの仕事ですね。
「ソフトフェア資産って何年で償却するの？」
中野氏：エンジニアは工程の中で、どこから関わったほうがいいのかというのはどうでしょうか。
石亀氏：僕でいうと、飲食店に関するシステムをやっているので、顧客調査みたいなところでエンジニアに行ってもらったりすると、机上の空論からだいぶ変わっていくんですよね。最初のほうはなるべく行ってもらうと、開発スピードが変わってきたりしますね。
中野氏：自分が作っているものがどう使われるのかということを、はじめからエンジン温めておくというのが大事なわけですね。
藤倉氏：うちもわりとそうですね。一般論で言えば、スタートアップの初期って、市場調査というのは創業者が自分の人生かけて立ち上げをやっているので、当然彼らが主幹になるわけですよね。ですから、ど頭からエンジニアが入る必要はないし、市場調査、顧客調査をエンジニアにやれというのはハードルが高いかもしれません。でも関与はしておくべきだとは思っているので、Sansanではビジネスサイドがディスカッションしているときも同席してもらうようにはしていますね。
是澤氏：メルカリの場合は使っている顧客がわかりやすいんですが、Speeeのときはプロダクトがわからなかったので、僕は入社したてのころに営業同行に行ってキャッチアップをしました。そういうのを自らできる人は少ないですけど、そういう文化を作っていったほうが良いと思っています。
また、０→1を新規で立ち上げするときには、なるべくワンチーム化したほうがいいと話をしていますね。エンジニアはそれぞれの職種が持っている課題を技術で解決するということができるので、営業の課題、プロダクトの課題、CSの課題をテクノロジーで解決していける。ワンチームで透明性を高めておいたほうが、エンジニアは頑張ってくれると思います。ビジネスの難しいことはわからなくても、そこで困っている人を助けることで承認欲求が得られたり、結果としてチーム力が強くなるので。そうやってホスピタリティを鍛えるというのは大事だと思います。
中野氏：ある意味、エンジニアは現場に出るのを嫌がる人たちだと思いますけど、上の人間が必要性を説いて、文化として根付かせていけばいいんですね。
是澤氏：それでも行ってくれない人もいるんですが、その場合は「おまえのやりたくないことを、この人はやってくれている。この人を助けることに意義がある」と、マネジメントの仕方を変えていきますね。事業として成熟をしてきたら、人によって個性があるので、それぞれのやり方で見ていくということですね。
中野氏：プロダクトとかサービスという話になると、フェーズによって最初は突破力のある人が少人数で作って、ある程度見えてきたら少しずつ人数を増やしてやっていくというイメージですが、この辺りはいかがでしょうか。
藤倉氏：うちはもしかしたらちょっと違うかなと思うのが、少人数のときは突破力のある人間がいないといけない場合ももちろんあるんですけど。事業が成熟してきたときに、突破力のある人はどこにいくのかと。そんなにうまく新規ビジネスのネタが出てくるわけではないですよね。
たとえば法人向けのSansanの現場でチーフアーキテクトをやっているメンバーは、年収レンジでも相当高いですし、12年やっている法人向けプロダクトのアーキテクトをいまだにはっている。自分でも手は動かせるし、チーフとして他のアーキテクトを動かす立場もできるメンバーなので。
中野氏：同じアーキテクトをやっているわけではなく、変化させているからということですかね。
藤倉氏：そうですね、立ち上げたときはオンプレでした。そこからAWSがに移行していき、さらに事業が成長していったので、使っていただくユーザーさんの層が、当初1企業5～10IDくらいだったものが、今は数万IDとかになっているんですよ。同じプロダクトでもユーザーの規模がそれだけ違うと、アーキテクチャーも全部変えないと成立しないんですよ。新陳代謝を繰り返してきていますね。
是澤氏：最近まさに「ソフトフェア資産って何年で償却するの？」という話があって。3年～5年で作り変えないとついていけなくなるんじゃないかと。エンジニアは古いアーキテクチャーはいじりたくないわけですよ。ですから3～5年で作り変える前提で、突破力のある人をそういうところに配置していく。戦略的に組織としてやらせていくということですね。
中野氏：エンジニアを囲うための工数をある程度かけていく、ということですね。
是澤氏：そうですね。そういう人たちがいるからこそ、プロダクトが守られていくわけですし、これはお客様のための投資ですよね。ビジネスサイドもそこに対する理解が必要だと思います。
石亀氏：うちの場合は今プロダクトが2つあるので、それぞれ12人と、8人にわかれてやっています。QAは今年から組成しはじめて3人で、大きなフェーズになると、外部のテストセンターを使っています。業務システムなので、プロダクトに対するお客様の依存度がどんどん高くなる。そこを安定してどうやって継続運用していくのかというところに、変わってきている感じです。
ビジネスサイドとエンジニア組織の最適な関わり方とは
最後に、中野氏は「コミュニケーション」をテーマにあげた。経営、営業、開発がそれぞれ理念をもとに動く中で、どのようなコミュニケーションが事業にとって最適といえるのか。
中野氏：経営、営業、開発の中でいうと、どことどこが言葉が通じにくいとか、ご意見ありますか。
是澤氏：だいたい経営とその他がぶつかるんじゃないでしょうか（笑）。営業のインセンティブどうするか、CSはどう人を増やすか、開発にどう投資するかとか。それぞれの専門性を持った人たちをどうマネジメントしていくのかというのを決め、経営側で判断できる人がいないと、うまくいかない場合が多いんじゃないかと思いますね。
中野氏：現場間はどうでしょうね。
是澤氏：開発と営業の現場って10年前と比べると仲が良い会社が増えてきていますね。リテラシーがそろってきたし、エンジニア側も優しい人が増えたと思います（笑）。
藤倉氏：ここは自慢していいですか。コミュニケーション、うちはとてもうまくいっていると思っています。
セールスの観点からいえば、この機能さえあれば売れるのにというケースがありますよね。でも、私たちは自分たちが作りたい世界のために、自分たちが作るべきと信じるものを作っているので、営業から上がってくる機能要求をそのまま作るということはしません。
ここを、営業もきちんと理解してくれている。その機能がなくても使っているユーザーさんがいて、売れているケースがあるとすれば、機能が問題ではなく「提案しきれなくてすいません」と言ってきてくれるんですよ。エンジニアサイドからすると、そんなこと言われちゃったら真剣にやるしかないんですよ。事業の数字を作っているのは彼らなんで、足をむけて寝れませんよね。
ソフトウェアプロダクトなので不具合や、特定のユースケースにおいてパフォーマンスがおちてしまう瞬間もあるんですが、そこは全部CSがカバーしてくれる。私たちが止めるから、エンジニアは自分たちの仕事に集中してくれと言ってくれるんです。
ソフトウェア開発は自分たちにはできないから、それはできる人たちを信じるしかない、というのが隅々にまで行き渡っていて。そういうところが、Sansanのすごく好きなところですね。
中野氏：VOCって、お客様の声はひろっているんですか？
藤倉氏：常に拾っています。営業やCSから社内SNSでバンバンきますし、プロダクトマネージャーはそれを全部インプットしながら、「そうだよな」と思うものはバックログを積んだりします。「そうでもない」と思うものでも、なんでこの人たちはこんなことを言っているんだろうかと、そういう疑問も含め全部管理しています。
そこから、希望された機能とはまったく別だけど、根源的なプロブレムを解決してくれる機能がリリースされたときには、その声をあげてくれた人たち全員に通知する。「あのケースであのお客さんがあげてくれたことは、この機能で解決するはずです。」というのを1回のリリースで何十人にもフィードバックする。これがあるから、インプットを常にくれるという循環なんですね。あげてもらった声がそのままの形ではならないですが、いつかそういう声もちゃんと拾ってあげられるプロダクトでいたいなと、思っています。
中野氏：BtoBであるほど、お客さんの声が大きくなることはありますよね。
藤倉氏：営業には苦労かけますよね。彼らは、目の前にいるお客さんに対して「あなたたちが期待しているものじゃない。Sansanはこういうものです。」という、ビジョンを売りにいっているので。うちの営業メンバーはそれをしっかりやってくれています。
中野氏：フューチャーとかロードマップは誰が決めているんですか。
藤倉氏：今はCPOがいるんですが、細かいものは現場のプロダクトマネージャーが積んでいきます。
中野氏：業務アプリケーションで、紙か否かの世界だと思うんですが。VOCが強すぎたりしませんか。
石亀氏：そもそも「モバイルオーダーって何ですか」からはじまるので、まだVOCが、というところではきていないんです。お客さんに対する説明や教育は営業さんが苦労しているところですね。CSは不具合などの声を全面に受けてくれているので、役割を分担した組織がちょっとずつできてきたと思います。
中野氏：Sansanのプロダクトと違って、現場の通信とか、Wifiとかも影響するんじゃないですか。
石亀氏：そうですね。最近はお店のネットワークを前提としない、SIMごと提供するみたいになっています。
中野氏：そういうアプローチの仕方もありますよね。プロダクトじゃないところに振り回されちゃう問題。だったらそれもインクルードしてサービスにしてしまえばいいんじゃないかと。
テモナはサブスクリプション系の支援会社で、一番最初に出したサービスが「たまごリピート」だったんです。展示会に出店すると、「卵屋さんなんですね。」としょちゅう言われていました（笑）。何故その名前にしたかというと、そもそもリテラシーレベルの低い人たちに、サブスクリプションを説明するためだったんですよ。「にわとりが毎朝卵を生み、鶏を大事に育てていきますよね、、」という営業トークで使うために。ある意味市場のリテラシーとか浸透度に合わせてプロダクトの名称を変えていくというのは、一個のアプロ―チかもしれませんね。
石亀氏：たしかにそうですね。「モバイルオーダー」って、かっこよく言い過ぎちゃってるのかもしれませんね（笑）。
中野氏：でもやりすぎると、上場したときの掲示板に「IT業界の小林製薬」って書かれていて（笑）。最近ようやくサブスクリプションという言葉が浸透してきたので、次世代のサービス名は「サブスクストア」に変えました。リテラシーレベル低いときは大変ですよね。
石亀氏：そうですね、もうこっちがどこまでやるかというところなので。メニューも登録するのが難しかったら、我々がやります。なんとかそうやって使ってもらって、実感してもらうところに持っていきたい。
中野氏：ちなみに、「経営とCSと開発で判断迷うね、言葉が違うね。」となったとき、何を判断基準にすればいいと思いますか。
石亀氏：僕らでいうと、店舗の従業員さんがどう思うかということが一番最初ですね。
中野氏：価値は誰が決めるのか、ということですよね。
石亀氏：そうですね。使ってもらうことが重要なので、そこはやはりお客さんかなと。
是澤氏：会社にもよりますよね。Speeeとかは数字をすごく見る会社ですし、それもある意味正しくて。社長が決めるという会社もあれば、CPOが決めるという会社もありますし。そこを先にはっきり決めておくことが重要ですよね。後出しにならないように。感覚で決めてしまうと再現性がなくなってしまうし、納得感もなくなってしまうので。フェーズによって変わってもいいしいる人によっても変わってもいい。新陳代謝していくのがいいと思います。ルールがフェアである、透明性があるということが大事で。やってみたいとわからないことでもあるので、まず先に決めておいて、どうだったかを検証しておけば、みんなが腹落ちするんじゃないでしょうか。
藤倉氏：うちはビジョンドリブンのところもあれば、日々のところでいえば数字かなと思います。たとえば、こういう機能を作りましょうと言ったときに、セールスに対してどのくらいのインパクトを出せるのか。既存のユーザーさんに対してアップセルやチャーンレートにどのくらい影響するのか、それを作るのにだいたい工数どのくらいかかるのかを計算します。
Sansanのプライべートカンファレンスは、5000人とか来ていただく規模でやっているんですけど、あれも普通にマーケティングコストとして計算していて、ペイする状態になっているんです。これだけの売上があるから、コストこのくらいでも大丈夫だよねと。それはTVCMも同じで、全部数字ですね。
でも先ほど是澤さんがおっしゃったように、いろいろな方法があって、会社の文化、哲学だと思うんです。Sansanはビジョンが強いので、代表が「これは普通に計算するとペイしないけど、これは創業者としてやるべきだと思う。これは不確定要素が多いけれども通させてくれ。」と、明確に言うこともありました。これまでに数回あったかなくらいですけどね。
中野氏：それは経営者としてはかっこいいですね。組織が大きくなっていくと、数字で誰が見ても同じ状態というのは、理にかなっているのかもしれませんね。
是澤氏：データの量がこれまでとは全然違うので、人が判断できるレベルでなくなっていて、それを今までのように判断しようとするとだいたい間違うんです。一定の規模にいくと、データドリブンというのが正しいと思っています。
中野氏：そうすると、昔はお客さんのことを見ていたのに、今は経営者が「数字」ばかり追っている、みたいなことになってくるんですね。
是澤氏：そうなってしまうんですよね。それをつなぐのはストーリーなんですよね。きちんとビジョンを変えていかなくちゃいけないでしょうし、カルチャーを変えていくというのも大事です。コミュニケーションというのは、フェーズが変わると超難しくなる。このストーリーを作れる人がいないんですよね。それができる人がいたら、すごく大事にしたほうが良いと思います。
中野氏：これは誰がやればいいんでしょうね。中に向けてやれる人は少ないですよね。
是澤氏：CEOだったり、CHROとかがいればそういう人になるんでしょうかね。その会社のことを一番知っていて、一番想いがある人たちを集めて、主導できるような人が会社が大きくなっていくときには必要だなと。
中野氏：CTOがそこまでやるとしたら精神崩壊しちゃいますよね（笑）。
是澤氏：CTOは苦手な分野じゃないですか（笑）。
中野氏：いろいろキーワードとして出てくるのは「理念」かなと思っていたんですけど、意外と会社のステージによっても変わってくるんですね。当然目の前の「数字」というのもありますし、大きく見るとこの会社という箱ってなんのためにある箱なんだっけ？という枠で決定していく、というのがキレイなんでしょうね。
でも、経営者という人たちがどこまでプロダクトに口を出すのか、ということもステージによって変わってきたりしますよね。VPoPとか、早めに権限委譲してうつしていかない限りはいつまでも引っ張られ続けて、自分のビジョンだけで走ってしまうという弊害もありますね。
会社フェーズごとのエンジニアの組織設計や投資、ビジネスサイドとの関わり方など、ご経験をふまえた貴重なお話しを伺いました。これから組織を拡大し、CTOやVPoEを置きたい、エンジニア組織を強化したいと考える企業の皆さまはぜひ参考になさってください。
次回のイベント☞
「採用した幹部がスムーズに活躍するには」(12/16・1/23開催予定)
組織マネジメントの株式会社識学と幹部採用のBNGパートナーズによる幹部採用フォローアップセミナーを開催します！
この記事が気に入ったらサポートをしてみませんか？