伊能氏が投資先のCTOを集めて議論をしている理由
小笹佑京氏（以下、小笹）：伊能さんは、投資先のCTOを集めてコミュニケーションを活発にする活動をされているとおっしゃっていましたが、どういったところを身につけてほしくて、そういうコミュニケーション活動を促進しているのですか？どういう観点でCTOを見たいと思っているのかにつながるのかなと思っての質問です。
伊能詩吹氏（以下、伊能）：うちの場合は、投資をする際にCxOに対して個別インタビューをするというのが絶対に入っています。
私たちもBtoB特化でやっているので、テックにかなり重要な要件を置いていて、テックDDはしないにせよ、CTOがどういう人間でどういう考え方を持っているかと、組織を作れるかを見にいくというのが入っています。
CEO、COO、CFO、どのタイミングでどのCxOがそろっているかによりますが、共同作業者がいる場合においては、全員がきちんと信頼関係を築けていることがけっこう重要です。
事業が成長していくにつれて、例えば共同創業者のうちの1人が、なにか違う方向性を見にいくという状況が発生してくると、全体的に足元が崩れやすくなって、事業の成長にけっこう大きく影響を及ぼしたりします。
なので、背中を預け合うというところで、どれぐらいこの人たちはできるんだろうという観点でも、CxOに全員インタビューをしています。
私がCTOのみなさんを集めてコミュニケーションを取っている意味合いでいうと、組織が少しずつシリーズAに向けて大きくなっていく中で、シリーズBやCの開始のCTOも全部まとめて何人か呼んで「シリーズが上がっていった時にCTOって何をすべきなんだっけ？」とか、「組織評価ってどうなっているんだっけ？」とか、離職および採用はどういうふうに手を打っているかみたいな部分のディスカッションをけっこうみなさんでする場を設けています。
なので、同じラウンドのCTOを集めているというよりは、けっこう幅広くCTOを集めて、みんなで議論をしているかたちです。
小笹：そういった活動を通して、いろいろなステージで求められることの変化を把握してもらいながら、全体最適を図っていこうみたいな意味合いですかね？
伊能：おっしゃるとおりです。私が全部が全部を話せないので、CTOのみなさんに話してもらったほうが早いよねと、そういうふうにしているというのがたぶん一番クリアな回答かなとは思います。
小笹：ありがとうございます。
CTO単体ではなく経営チームとしてのケイパビリティを見ている
小笹：1つのテーマだけでめちゃくちゃお話ししてもらっていますが、どんどんやっていかないといけないので、次のポイントにいきたいと思います。
かなり近いテーマにはなるかなと思いますが、インタビューをしている中で、こういう目線はもっと持ってほしいな、CTOには今後こういうところも求めていきたいなというのがあれば、ぜひおうかがいしたいなと思います。
CTOからCEOというキャリアでもありますし、山本さんからぜひなにか示唆をいただければと思います。
山本正喜氏（以下、山本）：これは投資家でも別にCEOでもどっちでもいいという感じですか？
小笹：はい。
山本：わかりました。事業目線でお話しします。経営はチームなので、誰がビジネスを見て誰がプロダクトを見るのかという関係性にもよると思います。必ずしもCTOがビジネスでわかっていなきゃいけないわけではなく、テックに尖っていてプロダクトはちょっと弱いCTOもいたりするので、きちんとしたケイパビリティを担保していればいいかなと思います。
シリーズA、B、Cに来た時のCTOは、明確にエンジニアから経営者に立場が変わってくるので、そのフェーズの話をします。
技術戦略を経営戦略にしっかり組み込むというケイパビリティを担保してほしいと思っています。特にプロダクト中心の会社においては、技術戦略が経営戦略、事業戦略におけるインパクトはものすごく大きいです。
技術的負債をどれぐらい溜めて、どれぐらいで返済していくかとか、技術選定は単純に、はやっている、はやっていないだけではなく、それによって採用力が変わってきます。
それが、「日本にどれぐらいのエンジニアが在籍しているんだっけ？」とか「採用要件はどれぐらい高いんだっけ？」とか「うちの会社でそのエンジニアは採れるんだっけ？」とか、そういうことも含めて、事業戦略に必要な、“組織ケイパビリティを担保するための技術”という観点で、いくつかの戦略を並べた解像度の中で、技術はこうすべきだと選定し、それに対する説明責任と、そこに対しての遂行責任を果たしていくという視点があるべきです。
なので、自分の趣味嗜好でやるのではなく、ミッション、ビジョンの達成に向けて技術戦略の意思決定をして、それに対してきちんと理由を説明できるという俯瞰した目線が、シリーズが進んでいくと必要になってくるかなと思います。
現場でコードを書くだけだとダメになってくるのが、シリーズB以降ぐらいかな。
小笹：シリーズB以降ぐらいからですか。それは、経営者によって変わりますか？
山本：シード、アーリーでいうと、とにかくユーザーが求めるものを素早く作って届けるというデリバリーを優先にしながらやっていけばよくて、シリーズAでいうと、一定PMFが見えてきて、組織を作るフェーズになってくるので、対応力と組織構築能力がガッと求められます。
シリーズBでいうと、もう総合力になってくる感じです。なんとなく、僕の感覚ですけど。
小笹：ありがとうございます。そういう観点だと、冒頭でそれこそ湊さんがおっしゃっていた、組織を作れるかというところは、ある種すごく求められるんですかね？
山本：はい。後半のA、Bになるとエンジニアの数が数十人になるので、組織を作れないといけないというのはあります。ただ、CTO単体に組織構築能力がなくても、究極VPoEがセットでいればいいと思います。そういうVPoEを引っ張ってきて、そこに任せられるとか、俺はアーキテクチャをやるから組織は任せたみたいな、そういうコンビができていれば、必ずしもCTOの組織構築能力が高くなくてもいいかなと思います。干渉できる能力は必要ですけど。
小笹：なるほど、CTO単体で見るのではなく、竹内さんもおっしゃったように経営チームとしてのケイパビリティをご覧になっているということですね。
山本：そうですね。CTOとしては経営会議の場に、開発組織のイシューや技術戦略の意思決定を持ち込まなければいけないので、VPoEに現場は任せていて経営にイシューを上げられないとそれは問題かなと思います。
小笹：ありがとうございます。
シード期はシンプルに作りお客さまの要望に早く応えることが大事
小笹：パネルディスカッションなので、ぜひお互いに質問していただければと思います。湊さんはいかがですか？ むちゃ振りですが（笑）。
湊雅之氏（以下、湊）：本当に、山本さんがおっしゃるとおりだと思うんですよね。
CTOとVPoEで役割がけっこう違って、VPoEは比較的組織や人を見るのが得意な人で、CTOはどちらかというと、未来のプロダクトを考える役割という話が多いのかなとは思います。開発リーダーとして、全体感としてどうか？ というところは重要だと思うんですよね。
事業の目線という意味でいうと、それは求めればきりがなくて、先ほど山本さんが言っていることの繰り返しになっちゃうんですけど。
最初、特にシード期はやはり、いかに早くお客さまの要望に応えるかというデリバリーが大事なので、ある意味シンプルに作ることがすごく大事なのかなと思います。
将来こういう構想があるから、このレイヤーを入れようみたいな複雑性を増すことをやるケースがよくあるのですが、このシード期においては、プロダクトの方向性が変わる可能性もあるので、あまり複雑にやらずにシンプルにやるのがいいのかなと思います。
（山本さんが）おっしゃるとおり、シリーズA以降は組織を作れるかで、採用にコミットできるかです。やはり僕らの投資先でも、CTOの90パーセント以上の人が採用に時間をかなり使っているなというのが正直な印象です。
だから、組織のスケールにかなり、プロダクトの進化と実際の売上の部分がついてくるケースは多いかなと思います。
ほとんど繰り返しですね、すみません（笑）、山本さんのをパクっただけみたいになっていますけど。
小笹：（笑）。ありがとうございます。先ほどの、必要以上に実装しないみたいな話ですが、エンジニア的にはYAGNIの法則というのがあって、機能が実際に必要となるまでは追加しないのがいいよという、エクストリーム・プログラミングの原則の1個だったりするので、まさにそういう観点でベンチャーキャピタルの方に見ていただいているというのは、すごく素敵なことだなって、個人的にすごく思いました。
事業と組織を拡大する中でChatwork社のトップが抱えていた思いとは？
小沼晴義氏（以下、小沼）：私も聞いてみたいことがあるんですが、いいですか？
小笹：ぜひ。
小沼：山本さんと竹内さんに聞いてみたいです。山本さんには、Chatworkをお一人で作られた頃から現在まで、事業ステージと開発の組織拡大をどんな思いでされていたのかをおうかがいしたいです。
竹内さんには、創業の頃から現在までの組織の変遷を、トップとしてどんなふうに事業ステージごとに拡大されていたのかを聞きたいですね。
山本：Chatworkの話でいうと、小沼さんに言っていただいたように、最初は私1人から、コードをゴリゴリ書いてスタートしました。
最初は全部兼務していたんですよね。リードエンジニア兼プロダクトマネージャー兼事業長みたいな体制で、ユーザーサポートもするし、営業もするし、ヘルプも書くし、コードも書くし、プロダクトの仕様も考えるみたいなことを初期の頃はやっていました。シード期がそういう感じかなと思ってはいるのですが、ゴリゴリ（コードを）書いていました。
一定、ヒットしてユーザーが大きくなって、組織規模が増えていく中で役割が分化していったのかなと思っていて、最初に来たのが、開発組織を見られなくなったことでした。
エンジニアが、20人を超えたぐらいのタイミングでもう見切れなくなってきて、開発本部長みたいないわゆるVPoEが欲しいなと思って、VPoEを採用しました。ここがシリーズAぐらいのタイミングですね。
シリーズAでVPoEをエージェント経由で採用して、開発組織を任せました。当時私は技術的なアーキテクチャとコードも引き続き書いていたのですが、プロダクトマネージャー、事業長みたいなのをやっていたのがシリーズAぐらいです。
そこからシリーズBぐらいになってくると、もっと大きくなってきて、プロダクトも見切れなくなって、専任のプロダクトマネージャーが欲しくなって、プロダクトマネージャーを採用してそこも渡しました。そこから先、前社長がちょっとアメリカに行っていたこともあって、半ば僕が、日本のCEOみたいなことをやっていました。
上場が近づいてくるとそちら側の業務が忙しくなってきて、もうCTOも譲ろうというかたちで渡したので、順番に席を渡していきながら、最終的にはCEOになったなと、そんな感じの変遷で動いていました。小沼さんも横で見ていたと思いますが、そんな感じです。
（次回へつづく）
