60
24

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

株式会社ビットキーAdvent Calendar 2022

Day 25

創業期の「CTO」に贈るたった一つのアドバイス

Last updated at Posted at 2022-12-24

この記事は株式会社ビットキー Advent Calendar 2022 25日目の記事です。
VPoEの山本が担当します。

みなさんメリークリスマス!

これは何か

現在私はビットキーにおいて「VPoE」という肩書きで活動しています。創業期のスタートアップである当社において、実質的にエンジニアリングを牽引する立場であり、一般的には「CTO」と呼ばれる責務で行動してきたと今は思っています。

なので今日この場ではあえて「創業期のCTO」として記載します。

私の当社でのこうした活動は5年近くになり、今改めて振り返り、私のような役割の方/これからそのような役割を期待される方に、リアルな実体験とたった一つのアドバイスをお伝えしたいと思います。

対象読者

  • 創業期のCTO = 創業初期の開発チームを牽引する役割の方、あるいはそうなりたい方
  • なんらかのモノづくりで起業を志されている方
  • 開発行為にこれまであまり関わりのなかった創業経営者の方

TL;DR

  • 創業初期ベンチャーの「CTO」の仕事は 「狭義のCTO」「CPO」「VPoE」だよ。

  • 実際はこの3つの上位概念に「経営課題の解決」があるよ。究極はこれがむしろミッションだよ。

    • 私自身もそうだったし、創業期を支えて成功した人も、今創業したばかりの人も、そう感じている人が多そうだよ
  • ただ、役職のラベルとは乖離が生まれるよ。

  • そうすると、周りからはあなたの仕事は断片的で、見えにくいものになるよ。

  • アドバイスは「あなたの仕事/課題/スタンスを周囲に表明し、理解を促し助けを求めよう」

    • 私自身の最大の失敗の一つは、自分の役割の自認が浅く、周囲に伝搬/説明しなかったことだよ。

自己紹介

私は、ビットキー設立前から当社のために活動し、創業からエンジニアリングを牽引する立場として、製品開発を中心に社内全域の課題に対して、幅広く活動してきました。

結論を先に

創業期の「CTO」に贈るたった一つのアドバイス、それは

「あなたが今解決しようとしている仕事/課題/スタンスを表明し、理解と助けを求めよう」

です。

以下、本文となります。

スタートアップにおける「CTO」とは

まず、スタートアップにおける「CTO」という言葉への期待役割は一般的に以下に分類されると考えています。

  • CTO: 技術x経営の責任者。
  • CPO: 製品x経営の責任者。
  • VPoE: エンジニアリング組織x経営の責任者。

「技術」「製品」「組織」です。

これはもちろん、個々の会社様の布陣やタレントによって異なりますし、各ラベルの業務期待領域も様々なのが実態ではあると思います。

しかし、これらを超えて、重要なミッションがあります。

創業期「CTO」の実態

それについて、以下、創業期「CTO」の実態として、私の実例、周囲の創業間もないCTOの悩み、IT巨人の創業期の例から考察したいと思います。

ビットキーで実際に私が向き合ってきたこと

まずは私自身について。

以下に列挙したリストは、私がこの5年弱で向き合ってきた領域です。大変多岐にわたるのですが、さっと並べてみました。(そして恐ろしいことに、ここにさらに、書けないような仕事も更に加わります。)

  • 具体製品の開発関連
    • BKP(デジタルキー基盤)の初期設計/開発支援
    • 最初期のハードウェアの開発パートナー選定/PJ推進
    • ファームウェアの設計/実装/評価
    • アプリの開発管理/PdM
    • 各種プロダクトの初期コンセプトの策定
    • 各所技術選定/決定
  • 組織管理的な開発関連
    • ファームウェアチームのマネジメント
    • SaaS開発系チームのマネジメント
    • アプリ開発系チームのマネジメント
    • エンジニアリング組織全体の検討/ビルディング
    • エンジニアリング組織管理
    • 経営等関係者への説明
    • オフショア開発体制構築/運用
    • 委託先管理/契約管理
    • 部門予算策定/管理
    • エンジニア採用
  • その他の開発関連
    • 製品ビジョンの具体化支援
    • 市場/顧客トラブル対応
    • プロダクト知財関連の整理/対応
    • ライセンス管理
    • ソフトウェア開発に関わる予算管理
    • 開発関連取引先との折衝/管理
    • 品質部門立ち上げ/マネジメント
    • 技術広報活動支援
    • 地方拠点立ち上げ
    • 自社/他社イベント登壇
  • 製品/技術にちょっとだけ関係ある開発外のこと
    • プロダクト系DD(製品/知財/セキュリティ)
    • IT監査対応
    • 情シス(CorporateIT)部門のマネジメント
  • 開発に全く関係ないもの
    • CS拠点の選定
    • 会計部門の管掌/課題解決/監査法人対応
    • 税務対応
    • 在庫管理/棚卸し
    • ビジネスプロセス管理部門のマネジメント/課題解決
    • サプライチェーン部門のマネジメント/課題解決
    • バックオフィスシステムの選定/導入
    • 法務部門のマネジメント/課題解決

はい。多いですね。とても多いです。
CTOっぽいもの、CPOっぽいもの、VPoEっぽいもの、なんでやってるの?ってもの、様々です。
下の方に行くに従って、どんどん「何やっとんねん」感が増してきます。会計とか税務とか法務とか、訳がわかりませんね。売上を立てていく部門以外のほぼ全てのことに携わったと思います。
これが、偽りなく確かに私の前にあった現実でした。そして私は、このような中でも「なんで自分がこれをやっているんだ」という疑問にさいなまれる事はありませんでした。(全くなかったか、と言えば嘘になります。)

私だけの事象ではない

一見目を疑うような、上記の課題解決のスコープですが、どうも世の中を見ると、私だけの事象ではなさそうです。以下に2種類の例を示します。

  • 創業期「CTO」からよく相談されること
  • 今をときめく大手検索エンジン = 巨人の創業期の話

創業期「CTO」からよく相談されること

具体例の一つ目として、私が実際に創業期の若手「CTO」によく質問/相談されることを列挙します。

  • どうやって採用していますか/採用コストどれくらいですか
  • 資金調達額のどれくらいまで開発コストに投下していますか
  • 知財のリスクと管理方法について教えてください
  • 部門感のコミュニケーション方法について気をつけていることはありますか
  • 開発組織での文化形成について意識していることはありますか
  • リモートワークと出社についてどのように考えていますか
  • 評価/査定制度について教えてください
  • 経営者(CEO)との対話頻度とその内容について知りたいです
  • 拠点立ち上げとそのプロセスについて教えてください
  • 資金調達プロセスでの製品/技術の役割とやることはなんですか
  • エンジニアの成長支援についての考えはありますか
  • 経営者との合意形成にコツとかありますか
  • etc…

このように、技術的な選択/実現や製品ビジョン、技術的負債と初期技術選定のバランス等について問われることはほとんどありませんでした。この点については、そもそも皆さん自信があってこの道を選ばれているのではないかと思います。
が、逆に言えば、もしかしたらあまり得意ではない、あるいは直面するまであまり考えたことがない、こういった事項を重要な課題として背負うことになるのです。

巨人の創業期の話

また違う例を出します。大成功しているIT巨人の創業期の話です。
私は今年、大手検索エンジンの創業メンバーで現在も同社にてエンジニアリング領域で活躍されている方と対談させていただく幸運を得ました。その中で、私から創業期の同社について質問したところ、その回答は以下のようなものでした。


「最初の3年は全てが壊れていた」
「経営課題となるTOP10の課題を片っ端から解決していく必要があった」
「そしてこのTOP10は毎日変わった」
「このような状況では、スペシャリストよりもゼネラリストが重要だった。解決すべき課題が毎日変化していくからだ」


この言葉に私は強い衝撃を覚えました。
同社の現在は、我々のようなベンチャーから見ると何もかも整っていて、多くのエンジニアから憧れられていて、そんな会社の創業期が(失礼かもしれませんが)同じような状況であったのかと思うと、深い共感が半分、しかし、全く意外だという思いが半分でした。そして私はこの時初めて、私が置かれていた状況、目の前の課題の広漠さが、私だけの特殊性なのではないのだ、と認識するに至ります。

つまり求められるもの = 「経営課題」の解決

これらの例の示唆する所、
創業期においては「CTO」「CPO」「VPoE」とどのようなラベルであっても、つまるところ、その時々の「経営課題」を理解し、解決することが求められ、それは上記のようなラベルとは明確に乖離があるということです。
私の例はあまりにも極端ではありますが、自分の持てる能力で「経営課題」と向き合うとき、全社の中で、最適なアサインであれば、そこがフィールドになるという事なのです。

製品ビジョンの形成や初期的なチームビルド、あるいはPMFが得意なのかもしれませんし、技術の深部を理解しながら現在の要求デリバリに応える開発行為を直接自分で行うことかもしれませんし、製品のあるべき姿を描き、現状の人的リソースを踏まえて、開発チームを長期的にゴールに導くことかもしれません。

私の場合は、自身の強みの一つである、人材の多様な能力を許容/活用してゴールに繋いでいく力、平たく言えばチームマネジメントの力と、ベースにあるそれなりの技術/製品開発理解が、この特性は汎用性が高く、課題解決にたまたま向いており、多くの領域での課題と向き合うことになったのだと思います。

だからこそ生まれる課題

さて、「CTO」「CPO」「VPoE」といったラベルへの周囲のそれぞれの期待値と、現実世界で解決しなければならない経営課題の間には多かれ少なかれ、しかし確実に、ギャップが生まれます。期待されるラベルのスコープで仕事をしていないからです。

この期待値のギャップは、時に深刻な課題になります。

実際に私は「VPoE」という肩書きであるにもかかわらず、技術広報/採用/育成支援/エンジニアリング組織運営・組織横断課題解決といった、およそVPoE的な役割に求められることに注力しないばかりか、全く違うことに強いコミットメントで臨むことも多く、その説明も行っていなかったために、私への期待と私の現実の振る舞いのギャップに苦しんで、本当に申し訳ないのですが、退職に至らせてしまった事もあります。

「あなたにしか解決できないのに、あなたは何をやっているんだ」と他の創業メンバーから叱責いただいた事もあります。

助けようとしてくれる仲間へ、背景や状況や課題やミッションの説明もなく、自分の目の前にある、経営課題への優先順位だけで行動した結果だと思います。私は、「どこまで、誰に、何を伝えるべきか」という判断にかけるコストすら惜しんでしまう時期が長く続きました。

結果としてそれは誤っていました。

シンプルな解決策

このような状況に対する、シンプルな解決策があります。それがこの記事の結論、
「あなたの仕事/課題/スタンスを周囲に表明し、理解を促し助けを求めよう」
です。

何も難しいことではありません。見えている景色を、向かうべき先を、その方法を、口に出しましょう。見えてないなら、見えてないことを、表明しましょう。全ての関係者に表明できていることがより良いと思いますが、すぐ側で、身を案じてくれている仲間にだけでも、伝えましょう。

伝えなければ、見えている景色を理解してもらうことは難しいです。繰り返します。伝えなければ、見えている景色を理解してもらうことはできません。なぜなら、世の中にラベルのない、自分だけの仕事をそのまま理解することは、実はもはや自分自身でも難しくすらあるのです。かつての私がそうでした。

何もせず理解してもらえるはずがありません。それを、そのまま、ありのままを伝えましょう。

まとめ

創業期のスタートアップにおいては、持てる能力であらゆる課題と対峙する事が求められます。それは、成熟した会社での「CTO」「CPO」「VPoE」に求められる専門性や領域とは大きく異なるものです。そしてその立ち向かう姿勢は、会社や経営者はもちろん仲間にとって大きな助けになるでしょう。

しかし、そのような動きは、時に見えにくく、理解し難いものになります。一方、そのような姿勢で会社と向き合っていることを、周囲に表明しておくことは、理解を促し解決のための力を結集でき、結果としてチームの競争力を高めるアクションとなります。

創業期のベンチャーで今まさにそのような事態と直面している方、あなたは一人ではありません。あなただけがそのような最中にいるわけではありません。私もそうでした。

あらゆる問題と戦いましょう。

あなたのその勇気が、製品を形にし、事業を成長させ、会社の存続へと繋がっていきます。そして、伝えましょう。周囲は理解してくれます。信じましょう。周囲はあなたを助けたいと思っています。しかし、周囲と見えている景色が少しだけ違うこと、また、自分自身でも濁流に飲まれながら選択を繰り返していることから、状況を適切に説明しないと、理解してもらうことは難しいです。

昔の自分自身に強く言いたいですが、察してくれと甘えてはいけません。周囲の期待値とは常にギャップが生まれています。仲間を信じて、勇気を持って、自分のスタンスを表明しましょう。

最後に

当社のカルチャーの中に「Hand in Hand」というものがあります。文字通り、手を取り合おう、というものです。また、社内でよく語られる言葉に「背中を預ける」というものもあります。
どちらもとても好きです。

この2つが重なり合ったとき、手を取り合い、仲間を信じて、背中を預けて、押し寄せる課題と向き合えます。それは週刊少年ジャンプの世界観に近いです。日々、勝っても、負けても。ベンチャーの創業期は例えるなら、毎日がスラムダンクの山王戦(知らない方、申し訳ありません)なのです。主要登場人物として、舞台に立つ。このような経験はビジネス人格にとってのかけがえのない宝物となります。

もう一度同じことをやれるか、正直に言って、答えは多分Noだと思います。

しかし、仲間と手を取り歩んだこの5年弱と、幸運による多くの成功とそれ以上の失敗、そして関係した全ての仲間に、感謝するか、答えは圧倒的にYesです。

今、苦しんでいる創業CTOの何らかの力になれば幸いです。

60
24
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
60
24

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?