組織規模とCTOの求められる役割の変化に関する雑記
CTOA Advent Calendar 1日目のバトンを受け取りましたので、1日目となる今回は、CTOに求められる役割の変化について、自分のこれまでの振り返りを兼ねて記事を書いてみようと思います。ちなみに今週はマガジンの連載をこちらの記事に代えさせていただければと。
普段はこちらのマガジンでソフトウェアと経営についてつらつらと書いています。ご興味ある方、年末の時間のあるときにでもご一読いただければ幸いです。
はじめに
この10年、エンジニアとしてのキャリアをスタートして今に至るまで、一桁人のスタートアップから1000人近い規模の開発組織を抱えた大企業まで様々な規模の組織のCTOを経験してきました。おおよその流れとしては、学生時代に小さなスタートアップを3社、その後Gunosyにて一桁人から60人前後の開発組織、現在はDMMのグループにて合計1000人弱の開発組織にてCTOをしています。
CTOの求められる役割は組織規模に応じて変わりうる、と言われることも多いのですが、実際にその変化についての感覚を自分なりの視点から振り返り、参考にしていただければと考えています。特に、CTO協会でもボリュームゾーンと感じる、10人前後の開発者を抱え、これから成長していく組織においてCTOとしてどのように戦っていくべきか、という方をメインに想定して書いていきます。正直、思いつくまま勢いで書いてしまったので冗長な部分などもありますが参考になれば幸いです。
組織のステージ
まず話の全体を整理するため、これまで経験してきた組織のサイズを大きく4段階に分けてみました。
・1〜9人のスタートアップ期
・10人〜99人程度のグロース期
・100人〜数百人程度の事業成熟期
・数百人〜1000人前後、複数事業を抱える大企業フェーズ
人数を区切りに置いてみてますが、おおよそのケースでは人数に応じて事業規模、売上規模も拡大していくのかなと思います。
こうしたステージ区分は、自分が感じてきたCTOとして求められる役割の違いをベースにした区分にもなっています。そうした違いは、事業の不確実性や外部から求められるコーポレートガバナンス、組織の階層増加など様々な要素が絡み合って生み出されています。
一桁人のスタートアップ：自身の時間を徹底してプロダクト開発へ向ける、なんでも屋のテックリードとしてプロダクトを正解にする
そうしたステージ分けの中で、まず一番初めの状態がスタートアップ的な企業です。このステージでは、なんとなくの初期仮説に応じてプロダクトの形を探り、顧客の反応を見ながら様々な施策を試していくフェーズです。
このステージを端的に表現するなら、何を作るべきか明確にするステージと言えるでしょう。取り組むべき課題を明確にし、それに対する大まかなプロダクトの方向性を定めることで、その後の拡大のための発射台を作ります。
そのため、このステージはまったく事業の解が見えない、不確実性のとても高いフェーズになります。このときに想定していた考えの通りに事業が進むことは極稀でしょう。ここでは、たくさんの試行錯誤を繰り返し、だんだんと事業の形や組織のあり方について考え続けていくことになります。
事業規模的にはおよそシード調達くらいまでの規模でしょうか、会社にある現金は数百万〜数千万くらい、半年から1年で現金が尽きるくらいの状況です。
このタイミングで、かっちりした組織ルールや組織設計を頑張っても無駄になりやすいものです。まずはプロダクトを顧客に刺さるもの、売れるものにすることに全てのエネルギーを注がねば、あっという間に現金が底をつきチームが解散することになります。
この時CTOに求められる最も重要な振る舞いは、プロダクトの検証サイクルをとにかく高速に回すために何でも担う、何でも屋的立ち位置です。このときのCTOはユーザーインタビューに取り組み、営業に同行しながらその声を拾い、テックリードとして最も多くのコードを書き、さらに機能やデザインを実現するために必要最低限の人員を確保すべく採用に奔走します。人事から開発まで、プロダクトがどうやれば顧客に刺さるのか、その切り口や形をぼんやりとでも見つけることに必要な全てに取り組みます。
このステージでは、開発組織全体を合わせてもまだ全員と1on1もしやすい規模で、特に評価制度などのマネジメント面で悩む必要はないかと思います。というよりも、一桁ほどの人数のフェーズでは、優先度の高い悩みとしてマネジメントに取り組んでいるという状態は避けなければならない、くらいに私は考えています。このフェーズで事業が止まることはまず会社の終わりを指します。まずはプロダクトとして何を作るべきか追い求めなければ顧客も社員も誰も幸せになれません。
人数が一桁ほどであれば、日々のコミュニケーションである程度はメンバーの状態も把握でき、また一人ひとりとコミュニケーションを取るとしても十分時間は確保できます。ですので、かっちりとした評価等のルール作りよりもそうしたコミュニケーションでカバーすることを選ぶ方がコストパフォーマンスは良いのかなと思います。
明確な制度等の形は、だんだんとプロダクトの形が見えてくる、何を売り物とするのか理解できる、PMFの形がイメージできつつあるという状態まで気にせずとも組織は回ると思います。その段階になって初めて、どういう人を評価すべきか、どういった機能が必要で、どのように責務を分割するかなどの設計に意味が出てきます。プロダクトの形が見え、必要なものが理解できたタイミングで設計を考えていきましょう。少なくともそれはまだ先の話かと思います。
また、採用においては、できるだけ自走できる人材の採用を中心に行いましょう。幸いなことに将来のリターンをまだまだ設計しやすいフェーズでもあります。自走できる人材にまずは副業でも良いので入ってもらいつつ、適切な条件を提示して採用を目指しましょう。
とにかく、このスタートアップなステージでは会社、事業、組織が成長するために何が必要か、何を顧客が求めているのか答えを見つけることに注力するほかありません。そのために自身の時間を徹底してプロダクトへ向けるべきだと考えています。
10人を超えスケールと組織化を始める：変化が激しく最もハードな時期、スケールに備えて組織のビジョンやプロダクトの思想を明文化する
そうしてスタートアップな時期を経て、何を顧客に提供するか、PMFに至るにはどのような形があるのかが見えてくると、1年後にあるべきプロダクトの形や拡大した組織がどのような機能を持っているかなど少しずつ中長期的なイメージが掴めてくるでしょう。
このスケールし始めるタイミングでは、組織も10人を超えてくるタイミングとなります。一人で10人以上をマネジメントしようとすると、だんだんと一人ひとりに使える時間が減っていくことに気づきます。また、スケール期は往々にして事業を急拡大していくことになり、開発含め様々な業務の負荷が高まってくるタイミングでもあります。だんだんと開発組織を一人では見切れない状態になっていくでしょう。
このタイミングでは、事業として何を作るかが見えてきており、将来の組織図についても1年後の形が意識できるようになってきます。こうした組織のあり方、事業のあり方が中長期的に見えてくれば初めて、それに合わせた制度が作れるでしょう。
CTOとしては、事業の求める形に合わせて技術組織とソフトウェア双方のアーキテクチャを整備していくことになります。どのようにプロダクトの担当領域を分割するか、そこにどのようなマネジメント構造を設けていくのかなど考えるタイミングです。
CTO自身を含め、おおよそ1人のマネージャが5~10人程度を目安にマネージするチームを基本単位として、どのようなチーム分割をしていくか検討していきます。理想形はソフトウェアとしてのドメイン単位を考えますが、例えばiOS/AndroidなどのクライアントやSREなどの横断組織など、様々な分割を組織に合わせて提供していくことになるでしょう。一番大切なのは、失敗をコントロールしながら継続的に改善と検証のサイクルを回すことのできる状態をつくり、Agilityを最も高める構造を目指すことだと思います。
こうした組織の形に合わせ、マネジメントについてもある程度の規則、ルール化を目指していくことになります。プロダクトの目指す先が見えてきたフェーズでは、何を評価すべきで、どういった振る舞いを求めていくのか、今後の組織の急拡大に合わせてルールにしていかねばなりません。
実は組織のビジョンやプロダクトの思想について明文化しようと一番向き合うのは、この、まだ10人ほどでこれからスケールしていくというステージなのではないでしょうか。組織が大きくなってもできる限り浸透させられる制度を作るためには、その骨格としてミッションやビジョン、バリューが欠かせなくなってくるからです。このタイミングで経営レイヤや全社での合宿などで各自の想いを話し合いながらベクトルを合わせて一気に明文化し、それをもとにした制度を作っていくなどのアクションが手っ取り早いのかなと思います。
また制度や思想、育成を担うマネジメントについて自分とメンバーの間にもう一層挟まねばならなくなります。マネージャーというポジションを明確に作るのはこのタイミングであることが多いでしょう。誰をマネージャに据えるのか、そのマネージャにはどこまでの責任を持たせるのかなど検討していきましょう。
上下を作らずティール型組織などフラットな組織にするという手もありますが、組織づくりにおいて企業文化・業種等問わず一概にこれが正解だと言えるようなものはないため、単に手法を表面的に取り入れることは何らかの問題につながります。そうした組織を成り立たせられる成熟したメンバーなのか、透明性高い情報共有を維持する仕組みが整っているかなど徹底して向き合って初めて、導入すべきかどうか判断ができるものだと思います。入れた当初はワークするケースも多いのですが、拡大につれて歪みが出るケースをいくつか見聞きしてきました。
多くのケースでは、シンプルなピラミッド型の組織形態を踏襲していくことが最初の一歩として踏み出しやすく、また拡大時の問題もパターン化されつつあり素早く展開できるのではないかと思います。組織をスケールしていくフェーズでは、少なくとも誰が誰のマネジメント責任を持っているのか、全員分かりやすい形態であることが重要かと思います。
自分自身のプラクティスとしては、最初はシンプルな制度を志向したほうが悩みも少なく進められると思っています。最低限、シンプルな組織図と評価の枠組みを設け、1on1を徹底する文化の導入があればまずは問題点を把握することが可能になります。問題の発生に応じて都度メンバーと一緒に乗り越え、それを制度化していくことがよいのではないでしょうか。
こうした制度や組織を作っていくことで、一人一人が安心して挑戦できる環境の維持に繋がります。そうすることによってベンチャーらしさ、初期の勢いを保ち、事業成長につながると思います。こうした動きを技術組織の側面から責任をもって支えるのが、このステージのCTOの役割だと思います。
このタイミングが、初めてCTOを担当する人にとっては鬼門となるのではないでしょうか。初めての組織マネジメントに加え、急速に拡大するプロダクト、それを支えるアーキテクチャ設計が必要となります。さらに経営レイヤでの議論に参加するためには最低限度のPL・BSに関する肌感覚なども求められてきます。
またセキュリティやコーポレートガバナンスに関する対応にも触れることが多いでしょう。監査ログの対応やデータの取り扱い、監査会社などに求められる文書の作成と提出、コミュニケーションなど普通にソフトウェア開発をしているだけだと見えてこない業務が度々飛んできます。
およそこのフェーズの後半ごろには組織がIPOやM＆Aに至ることも多いものです。そうした組織の劇的な変化、成長に伴う痛みをどれだけ緩和できるかは、このグロース開始早期からの組織や制度、プロダクト設計にかかっています。
このように初めて経験することも多く、さらに重責も背負っている立場として、特にこのフェーズで悩まれるCTOは多い印象です。かくいう私もこの時期本当に悩みました。詳しくは様々なインタビューで書かれていますが、たくさんの方に迷惑をかけながら、仲間と共になんとか上場以降まで動いてきたという時期でした。
現在では、このフェーズを経験したCTOも増えており、ノウハウをもったCTOが独立して技術顧問などをされていることも多く見かけます。できれば成長が見えてきた段階ですぐに先達のCTOをメンターとして捕まえておくと良いのではないでしょうか。自分自身はそうしたメンターを何人か（半ば勝手に）定めて相談していました。最近は恩返しとして複数の知人のメンタリングも行っています。
このフェーズは、会社として一つ大人になるタイミングであり、CTOとしても求められるものが急激に広くなるタイミングです。様々な事例に学びながらできる限り地雷を避けて進んでいくことが大切かなと思います。
100人を超えて、一つの山を登ったベンチャー企業：ソフトウェアを作れること以上に、ソフトウェアを作れる組織を作るスキルが求められる
この規模まで開発組織が大きくなれると、事業も軸が複数になったり、そうでなくとも内部の役割が細分化されチーム数が非常に多くなってきます。扱う事業の売上も100億を超えてくることが多いのではないでしょうか。
このステージでは、一人一人全員と向き合える頻度が少なくなってくるため、ミドルマネージメントの役割がより一層重要になってきます。下手をすると1ヶ月全く会話のないメンバーも出てきます。こうした仲間たちに、同じ方向を向いて事業の成長に向き合ってもらい、組織の文化に馴染んでもらうためには、組織文化を体現し、新しいメンバーにもその文化が伝わっていくような環境をつくる良いミドルマネージャが欠かせません。
また、チームや領域によって必要とするメンバーの素養が異なってくるケースも増えてきます。長らく運用され安定性を求められる保守的領域もあれば、常に改善を続ける攻めの領域もあるでしょう。こうした組織のグラデーションを理解しながら、ルールによる規格化（ドライ）とマネージャのスキルに依存した戦略（ウェット）のバランスを選びとっていく事になります。
すべてをルールで解決できるわけではなく、CEOの事業的な意志を汲み取りながら、それを達成できるであろうトレードオフを選択していくことになります。全てをカバーできる規則を作ろうとすれば、その規則は複雑で細かなものとなるでしょう。マネージャのスキルに依存しすぎれば、マネージャの良し悪しで大きく差が生まれてしまいますし、組織としての方向性を見失いバラバラな方向に進みかねません。
完璧な制度設計は困難と理解し、状況と今後の戦略に応じて適切なトレードオフを選択し、経営者として会社の意志を明確にし続けてていくことがリーダーのふるまいとして求められます。さらにメンバーが納得できる形で意志、目標を伝えることができるコミュニケーション能力やナラティブに関するスキルがあることは非常に役立ちます。制度や運用方針を立てるだけでは人は動かず、的確に理解できるよう伝えていく事が重要です。
ソフトウェアを作れること以上に、ソフトウェアを作れる組織を作るスキル、そしてその開発組織に経営意思を伝え、何をやる・やらないべきか明確にすることで更に開発効率を上げていくスキルがこのタイミングから強く必要となると思います。
さらに、初めての事業買収などもこの辺の規模からちょこちょこと発生するのではないでしょうか。買収においては、技術を理解できる経営者として、買収対象のセキュリティ、プロダクト品質、組織とその技術力などを評価しリスクを明らかにした上で買収判断に対して票を投じねばなりません。一度に数億〜数十億といった金額が動き、さらに数年〜10年といった長期での戦略にも関わってきます。
外の組織が仲間に加わるということで、組織文化の融合についても気を配る必要があります。同じ文化にしていくのか、完全に独立させ各組織の良し悪しをそのまま活かすのかなど組織面のPMI（買収後の統合）もあれば、先方が抱えるソフトウェアをどのように自社とつなげるかという技術的なPMIなど取り組むことは多々あります。買収判断と同じかそれ以上に買収後の戦略がCTOにとって重要です。買収を成功とするためにもこうした戦略にまで目を配っていきましょう。
100人を超えてくる組織においては、日に日に増してくる組織の複雑度に合わせて仕組みを変えていく必要があります。このステージでは、エンジニアという立場をより離れ、経営者として組織を動かすこと、そのためのリソース調達や制度作り、支えられるミドルマネージャの育成などに注力していくことがCTOとしての役割となってくるのではないでしょうか。
1000人を超える大組織のCTO：技術者としてだけではなく、経営者、組織全体を導くリーダーとしての役割がより求められるフェーズ
このステージをわざわざ分けて書く必要があったかでいうと、そうではないかもしれません。正直数百人のステージの延長的なものにはなります。ただ、現時点で自分がCTOを務めている組織は1000人弱ほどの組織になりますのでその実態として日々どのようなことに取り組んでいるのか、何度か質問を頂いたこともあったので書いてみたく分けてあります。
この規模では、もはや一つの村のような様相を呈してきます。さまざまな出自のメンバーが所属し、その求めるところも多様となってきます。成長を求める人、安定を求める人などモチベーションの置所も様々です。
また、どのような会社であれこの規模に至るということは事業も複数取り組んでおり、全く色の違う事業が一つの会社に属する事になるでしょう。そうすると、事業ごとに技術のあり方もバラバラですし、組織を構成する人もバラバラです。共通部分としての組織文化とそれを支える制度を除けば、全体に一律で適用しやすいものも少なくなっていくでしょう。
このフェーズでは、技術的な視点を中心にしながらも、事業戦略を形作る一員として、人・物・金をどこに集中させるか、その上で何を目指すのか、それを如何にメンバーに伝えていくのか考えていく必要があります。またそれに対して不足しているものは、採用だけでなく様々な国をまたいだ事業買収やJVの設立なども含めて議論していかねばなりません。
こうした戦略を立案し遂行していくためには、一人の経営者として明確な意思を持つだけでなく、コーポレートガバナンスに対する考え方やスタンスも持つ必要があります。戦略の評価は、適切なガバナンスの上で可能になるものなのではないかと思います。この文脈の上で技術組織を如何にもつべきか意見していかねばなりません。
もはや、技術者という立場ではなくなります。もちろん、戦略立案の上では技術力、今後の技術に対する予測と意思を持たねばなりません。しかしそれと同等以上に重要なのが、様々なステークホルダーを抱えた企業の経営者として、技術に立脚しつつも広い視野を持ちつつ組織全体を導くリーダーシップです。
自分が面接していないメンバーもどんどん増えていきますし、買収などを重ねる中で更に組織は多様になります。そうした組織を率いていくには明確なビジョン、バリュー、戦略、そしてそれを明瞭に伝えるストーリーを語る力や実際の実行を強く支えるリーダーシップが求められます。
日常の業務では、細かな技術的意思決定には関われなくなりますが、
・重要度の高いアーキテクチャ上の意思決定への参加
・戦略上の最注力プロジェクトに対するメンタリング
・評価・育成に関わる人事制度のブラッシュアップ
・重要ポストの採用推進
・戦略の実行状況のモニタリング
・事業や経営目標に対する次の四半期や来期などの戦略の立案
・緊急で舞い込んできた様々な経営的課題への対処
などが大きなウェイトを占めていきます。普段直接関わることのできる人数の割合は組織規模が大きくなるほど減っていくため、正直、各メンバーから見たときに何をしている人かよくわからないと言われることもしばしばです。
具体的には、DMMでは40事業以上（正確には80個ほどの事業PLを管理しています）の事業に対しての推進状況のモニタリングや、横軸で支援に入っている技術組織との定例を通じた戦略推進状況のチェック、優先度の高いプロジェクトチームへのメンタリング、制度設計、1on1、買収における意思決定などが主な業務となっています。また、正直な話、緊急の経営課題に対処するということが結構な割合の時間を持っていく状況でもあります。
一つ一つの開発チームと向き合える時間はだいぶ少なくなりますので、もし接する機会を得たなら、それがたとえ30分や1時間しかないとしても、その時間を最大限に活用せねばなりません。事前に収集した情報などと照らし合わせながら、その場でリソースの集中や方向転換などをすぐ意思決定せねばならないこともしばしばです。様々なタイミングで、限られた情報から最善と思われる意思決定をする必要があるため、日々の情報の集約などが重要となるでしょう。
状況を素早く見抜き、事業戦略に合致した方向に立ち向かうためのアドバイスを提供せねばなりません。そうした意思決定の連続に立ち向かうための情報処理スキルや回答を導くためのロジカルなスキル、そして何よりビジョンや戦略を意識してどっしりと構える胆力・意志力が求められます。コードを書き続ける上で向き合うストレスとはまた違ったストレスと向き合うことになります。
最後に
CTOと一口に言っても、やはり組織の規模でやっている仕事は全く変わってきます。バリバリとコードを書いているころから、社員から見れば何をやっているのかよくわからないと思われる規模まで様々な変化があります。
こうした変化していく役割をすべて一人のCTOでこなさねばならないということは全くありません。VPoEやCPO/VPoPなどの職務の分割も増えてきました。また、自分自身がやりたいステージを意識しそこに特化しつつ、次のステージにバトンを渡していくような戦い方もあるでしょう。
自身のやりたいところと向き合いながら、仲間・事業・顧客の価値を作ることとバランスしつつ立ち位置を明確にしていくとよいのではないでしょうか。
この記事が、新たにCTOとなられた方や、キャリアの選択肢の一つとしてCTOを考えられている方々の参考となれば幸いです。
この記事が気に入ったらサポートをしてみませんか？