
2025.02.12
職員一人あたり52時間の残業削減に成功 kintone導入がもたらした富士吉田市の自治体DX“変革”ハウツー
リンクをコピー
記事をブックマーク
小笹佑京氏(以下、小笹):伊能さんは、投資先のCTOを集めてコミュニケーションを活発にする活動をされているとおっしゃっていましたが、どういったところを身につけてほしくて、そういうコミュニケーション活動を促進しているのですか?どういう観点でCTOを見たいと思っているのかにつながるのかなと思っての質問です。
伊能詩吹氏(以下、伊能):うちの場合は、投資をする際にCxOに対して個別インタビューをするというのが絶対に入っています。
私たちもBtoB特化でやっているので、テックにかなり重要な要件を置いていて、テックDDはしないにせよ、CTOがどういう人間でどういう考え方を持っているかと、組織を作れるかを見にいくというのが入っています。
CEO、COO、CFO、どのタイミングでどのCxOがそろっているかによりますが、共同作業者がいる場合においては、全員がきちんと信頼関係を築けていることがけっこう重要です。
事業が成長していくにつれて、例えば共同創業者のうちの1人が、なにか違う方向性を見にいくという状況が発生してくると、全体的に足元が崩れやすくなって、事業の成長にけっこう大きく影響を及ぼしたりします。
なので、背中を預け合うというところで、どれぐらいこの人たちはできるんだろうという観点でも、CxOに全員インタビューをしています。
私がCTOのみなさんを集めてコミュニケーションを取っている意味合いでいうと、組織が少しずつシリーズAに向けて大きくなっていく中で、シリーズBやCの開始の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の話でいうと、小沼さんに言っていただいたように、最初は私1人から、コードをゴリゴリ書いてスタートしました。
最初は全部兼務していたんですよね。リードエンジニア兼プロダクトマネージャー兼事業長みたいな体制で、ユーザーサポートもするし、営業もするし、ヘルプも書くし、コードも書くし、プロダクトの仕様も考えるみたいなことを初期の頃はやっていました。シード期がそういう感じかなと思ってはいるのですが、ゴリゴリ(コードを)書いていました。
一定、ヒットしてユーザーが大きくなって、組織規模が増えていく中で役割が分化していったのかなと思っていて、最初に来たのが、開発組織を見られなくなったことでした。
エンジニアが、20人を超えたぐらいのタイミングでもう見切れなくなってきて、開発本部長みたいないわゆるVPoEが欲しいなと思って、VPoEを採用しました。ここがシリーズAぐらいのタイミングですね。
シリーズAでVPoEをエージェント経由で採用して、開発組織を任せました。当時私は技術的なアーキテクチャとコードも引き続き書いていたのですが、プロダクトマネージャー、事業長みたいなのをやっていたのがシリーズAぐらいです。
そこからシリーズBぐらいになってくると、もっと大きくなってきて、プロダクトも見切れなくなって、専任のプロダクトマネージャーが欲しくなって、プロダクトマネージャーを採用してそこも渡しました。そこから先、前社長がちょっとアメリカに行っていたこともあって、半ば僕が、日本のCEOみたいなことをやっていました。
上場が近づいてくるとそちら側の業務が忙しくなってきて、もうCTOも譲ろうというかたちで渡したので、順番に席を渡していきながら、最終的にはCEOになったなと、そんな感じの変遷で動いていました。小沼さんも横で見ていたと思いますが、そんな感じです。
(次回へつづく)
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
PR | 2025.02.07
プロジェクトマネージャーは「無理ゲーを攻略するプレイヤー」 仕事を任せられない管理職のためのマネジメントの秘訣
2025.02.06
落合陽一氏や松尾豊氏の研究は社会に届いているか? ひろゆき氏が語るアカデミアの課題と展望
2025.02.05
「納得しないと動けない部下」を変える3つのステップとは マネージャーの悩みを解消する会話のテクニック
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.02.10
A4用紙を持ち歩いて殴り書きでアウトプット コクヨのワークスタイルコンサルタントが語る、2種類のメモ術
2025.02.05
エンジニアとして成功するための秘訣とは? ひろゆき氏が語る、自由な働き方を叶えるアプリ開発とキャリア戦略
2025.02.04
日本企業にありがちな「生産性の低さ」の原因 メーカーの「ちょっとした改善」で勝負が決まる仕組みの落とし穴
2025.02.03
「昔は富豪的プログラミングなんてできなかった」 21歳で「2ちゃんねる」を生んだひろゆき氏が語る開発の裏側
PR | 2025.02.04
能登半島地震で自宅は全壊、「これでどうやってDXするねん」 被災したサイボウズ社員と支援者らが語る災害支援のノウハウ
新人の報連相スキルはマネージメントで引きあげろ!~管理職の「他責思考」を排除~
2025.01.29 - 2025.01.29
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29
【著者来館】『成果を上げるプレイングマネジャーは「これ」をやらない』出版記念イベント!
2025.01.10 - 2025.01.10
片付けパパ対談【特別編】 整理術×行動術×メモ術で、仕事も人生も自在にデザイン!
2024.12.16 - 2024.12.16