「どんなスキルを習得すればCTOになれるか」は、答えを出すことが非常に難しいテーマのように思われます。実際、世の中に「エンジニアとしてのスキルを向上させるためのノウハウ」はあふれていますが「CTOになるためのノウハウ」を見かけることはほとんどありません。
このブログでは連載形式で、CTO候補の育成方法について考えていきます。今回は第一弾として、CTOという役割について私が感じている課題意識と、CTOに求められるスキルの全体像について記述します。連載で次に何を書くかは、読者からのアンケートを募ってテーマを選んでいきたいと思います。こういった連載は新しい取り組みで、不安と期待が入り混じったような気持ちです。
アンケートの回答はこちらから
このブログの想定読者
- いつか CTO になりたい人
- エンジニアリング組織のリーダー格以上
- キャリアアップを狙っているいちエンジニア
- エンジニアを育成する立場の人
このブログのアウトライン
- CTO的なスキルを持つ人員の育成のためにCTOのスキル構造を可視化しました。
- どのような熟達のプランがあるのかキャリア構築の戦略レベルの参考になればと思います
- この記事ではスキル構造のアウトラインはこの記事で書きます。各項目は詳細の掘り下げが必要なのですが、時間的にも一記事の量としても限界があるため、どこから書いていくかアンケートを取りたいと思います。
アンケートの回答はこちらから
CTOとしてのキャリア構築の難しさ
CTOに必要なスキルは幅広いです。
組織のフェーズが進むにつれて、CTOの役割は変化していきます。創業期からCTOを務めて、初期プロダクトを作り、PMFを経て組織グロースを果たしていく人もいます。最初のプロダクトは立ち上げられたが、PMFまで至らずに残念ながら会社がクローズするケースもあります。また一方で、サービスやプロダクトはPMFまでは果たせたものの、コーディングよりもマネジメントが主体になるような役割の変化にCTOがフィットできずに、その責務を離れて企業の成長を見守ることもあります。
CTOという職業の難しさは「フェーズごとに大きく役割が変わる」点にあると思っています。「名プレーヤーは名監督とは限らない」という言葉がスポーツの世界にはあります。CTOについて言うと、名プログラマーは名CTOであるフェーズと、そうはならないフェーズがあります。そのフェーズの変化が訪れた時に、個人の成長でキャッチアップし役割をシフトできるかどうかが重要です。
プログラミングとは別次元の仕事たち
プロダクトが顧客に受け入れられ始め、組織がグロースしていくに伴い、プログラミングとは別次元の仕事が多く発生してきます。
コーディングよりも開発プロセスの定義やインフラの安定運用などの仕事が増えていきます。創業当初でエンジニアリソースが十分でないフェーズでは、あらゆる仕事をCTOが担う必要があります。
プロダクトが一定形になってくると、今度は組織づくりが大きな責務となります。
採用候補者のペルソナ設定などの採用戦略の検討やエージェントとのやりとり。事業計画にも照らし合わせたオファー内容の検討、オファーが競合したときに競り勝つためのアトラクトなどは、プログラミングとは別次元の仕事であると思います。
CTOであり続けるため、変化を乗り越える
変化にうまくフィットできないときに、組織は厳しい状態に追い込まれることもあります。
たとえば、採用においてブリリアントジャークを見抜けずに採用してしまうなどのケースです。チームに過度な攻撃性が満ちて組織崩壊を起こすと、開発組織は期待される事業価値を創出できません。
ミニCTOとして育成するプランを持ちたい
ここまで述べてきたように、CTOとしての能力を獲得することは簡単ではありません。
しかし、重要だが簡単ではないものだからこそ、仕組みや教育プランで得られる効果が高いと考えます。
「どうしたらエンジニアをCTOとして育成できるのか」は、私のキャリアの中でも通底した問いです。私自身が道半ばであるからこそ難しいのですが。
ファストドクターのメンバーには、私のWillとしてミニCTOとして育成したいということを説明してきました。
具体策を出せているわけではないので、今回改めて自分なりにスキルやコンピテンシーをマップ化して、どのような熟達のモデルがあるのかを考えてみます。特に「明日から取り組めるベーシックな能力は何なのか」について見解を述べます。
CTOスキルマップ
CTOに求められるスキルには、大きなカテゴリとして下記の5つがあります。
- エンジニアとしてのスキル
- 開発組織マネージャーとしてのスキル
- ピープルマネージャーとしてのスキル
- 採用マネージャーとしてのスキル
- 経営者としてのスキル
カテゴリはあえて重ね合わせています。たとえば開発組織マネージャーとしてのスキルとピープルマネージャーとしてのスキルは業務として重なるところがあります。
「1.エンジニアとしてのスキル」と「2.開発マネージャーとしてのスキル」は、これまでのエンジニアとしての仕事の中である程度は培われています。
3から5のスキルはエンジニアとしてのキャリアだけでは培われません。開発組織マネージャーだけでなくピープルマネージャーのカテゴリを設けたのは、CTOはデザインチームなどエンジニアでない職能もマネジメント対象に含むことも多いからです。専門性が異なる職能もマネジメントしていくのには、エンジニアリングマネジメントの範疇を超えたマネージャーとしての力が必要です。
経営者としてのスキルは顧客課題や市場ニーズを捉えて、戦略戦術を描いていく能力です。CTOは経営戦略の中でも、特に技術を用いた技術経営戦略のスキルが必要になってきます。
コアスキル
キャリアのフェーズを問わずに伸長していけるスキルとして下記の7つを挙げます。
これらはCTOとしてのキャリアラダーを上がっていくのに、ベースの走力になるようなスキルです。
- 学習能力
- 構造化思考力
- イシューコミュニケーション能力
- ピープルセンシング能力
- データモデリング能力
- フルスタック性スキル
- API設計能力
それぞれについて概要と、次回以降の連載で扱おうと考えているトピックを説明します。
学習能力
CTOは幅広いスキルをリアルタイムに獲得していく必要があります。 そのため学習能力は根本的なコンピテンシーになります。
学習の対象はプログラミング言語から管理会計まで幅広い領域です。
「こういった分野であればこのように学習をしていく」という学習の型を獲得することで、未開の幅広い領域で技能を獲得できます。
学習能力に自信があれば、企業としてのフェーズが変わってスキルシフトが期待されたときにもスムーズにフィットできます。
学習能力の予定トピック
- プログラミング学習の方法
- デバッグの重要さ
- ドメイン知識を効率よく学ぶには
構造的思考力
エンジニアにとっては構造的思考力が重要です。
一般的には論理的思考力が重要だと言われます。論理とは説明のための技法という点に重みがあります。論理は論理でとても大事なのですが、「理解できる論理的説明」と「動くシステム」にはギャップがあります。
システムにおけるほとんどの問題は「事象を適切に整理できていない」ことで発生します。
理解できる説明は、ある一つの軸でMECEであれば十分なのですが、システムづくりはあらゆる観点でMECEである必要があります。ある観点では十分でも別の観点では考慮漏れがあったときに、システムの不具合として問題が顕在化します。
スタッフエンジニアやアーキテクトとなっていくには、構造化思考力が根本的なコンピテンシーになります。
構造化思考力の予定トピック
- ほとんどの問題は「事象を適切に整理できていない」ことで発生する
- 構造化の3つの視点 〜 抽象具体/階層関係/時系列
- マインドマップでブレスト→整理する
- UMLで設計しよう
- 複数の視点をぐるぐる回す
イシューコミュニケーション能力
イシューコミュニケーション能力とは、課題を捉えて解決を表現し、物事を前に進めていくためのコミュニケーション能力です。自分の印象に合う用語がなかったので、この記事のために造語しました。
具体的には、生産性の高い会議を運営できる、経営陣に端的に論点が伝わる資料を作れるようなコミュニケーション能力を指しています。
組織を動かしていくには会議のアジェンダを適切に設計したり、エンジニア以外にも伝わるようなコミュニケーションをしたりといった必要があります。
イシューコミュニケーション能力の予定トピック
- イシューコミュニケーションを構成する3要素
- なぜ会議をするのか
- 会議の基本構造
- プレゼン資料の基本構成
ピープルセンシング能力
ピープルセンシング能力とは人を感じ取る能力です。この項目を含めるかどうかは悩んだのですが、どうしても含めたかったのは優秀なエンジニアであってもこの領域が不得意なことがあり、躓く人が多いからです。
CTOは1on1や採用面談など1対1で話すシーンが多くあります。
人の情緒や関心を掴み取る能力を磨いていけば、1on1のフィードバックの質を上げたり、採用クロージングの精度を高めたりすることができます。しかし、この領域は非常に学習しにくいことが特徴です。
「人にはそれぞれ個性がある」「それぞれ違う人間だ」ということを観念としては分かっています。しかし、違いを具体的に表現する解像度は低いのが一般的です。人間は自己感覚を通して世界を学んでいます。他人の感覚を聞くことが出来ますが、情報量に圧倒的な違いがあります。解像度が自分を中心に歪んでいるのです。
ピープルセンシング能力の予定トピック
- 対話相手のサインに気づく
- 発達障害についての知識を持つ
- アトラクトの4軸
- 職務経歴書から読み取れるサイン
データモデリング能力
データモデリング能力とはRDBのテーブル設計のようなデータ構造を定義していく能力です。
この能力が特に重要なのは、開発速度への影響やビジネススケールへの影響、PDCAサイクルへの貢献といった切り口で飛び抜けて重要だからです。非常に重要であるにも関わらず、エンジニア以外が関与することは難しい領域でもあります。
データ設計はビジネス設計とソフトウェア設計の帰結です。 良いデータモデリングができるかどうかは、ビジネスの理解度や既存ソフトウェアの理解度、フレームワークの理解度が総合的に試されます。エンジニアとしての技芸の熟達を目指す中で、ぜひマイルストーンとして意識していただきたいです。
データモデリング能力の予定トピック
- 守破離の守としての一次正規形
- データモデリングのトレードオフ
- データモデルと周辺領域の関連
- データモデリング能力を身につける方法
- 複数のデータエンジンを早期に触っておく
フルスタック性スキル
CTOは技術領域を横断的に見ます。そのため、スキル領域の幅が重要になってきます。 将来CTOになるかもしれない準備として、フルスタック性は狙って習得していった方が良いです。
スタートアップの立ち上げ当初は、ある技術領域の専任者をリッチに採用することは難しいです。エンジニアがなんでもやる必要があります。これまでアプリを中心に取り組んできた人であっても、サーバーサイドをデプロイするのであれば、インフラも見る必要も出てきます。
採用にあたっても、幅広く知っていた方が良い技術的な質問ができて、新しい仲間を見つけるのも早くなります。
フルスタック性スキルの予定トピック
- フロントエンドとバックエンドの考え方の違い
- フロントエンドとバックエンドの好きと得意の違い
- Willを持ったキャリア設計
API設計能力
データモデリングに次いで重要なのがAPI設計能力です。
どのようなAPI設計にするかで、大きく開発生産性に影響します。API設計が難しいのはフロントエンドやバックエンド双方の知識が必要な点です。前項のフルスタック性をある程度得た上で、双方の事情を考慮したAPI設計ができるようになることをマイルストーンとして持つと良いです。
API設計能力の予定トピック
- 守破離の守としてのRESTful
- API設計のトレードオフ
- フロントエンドとバックエンドから見た美しさの違い
- 複数の通信方法を知り選べるようになる
技術経営力
- 経営戦略
- 知財戦略
- 財務会計
- マーケティング
- 人事・組織構造
経営陣の一員として、経営も論じられるようになっていく必要があります。また、複数の部署を横断するような施策を推進していく必要も出てきます。
実践的に経営力が身につくというのは中々難しいです。これについては難しい一方で、取れる戦術はシンプルに選べるものしか無いように思います。
ベースラインの知識を身に着けた上で経験を積む
ということに尽きると思います。
技術経営力の予定トピック
- 他部署に寄り添い動かす方法
- 技術経営のベーススキルを獲得する方法
- 経営戦略の知識を「試す」方法
- マーケティングの知識を「試す」方法
- 会計の知識を「試す」方法
おしまいに
書き出すにつれ、自分自身が当初想定していたよりも、広範囲のスキルをCTOの技術として捉えているのだなと感じました。どこから掘り下げていくのが良いか、ぜひエンジニア業界のみなさまからのご意見を頂ければと思います。
アンケートの回答はこちらから
