【背景】
この記事はQuoraの「What does a CTO do?」という質問に対するAmr-Awadallah氏のよくまとまった回答の翻訳です(本人から許可取得済)。
私はMAMORIO株式会社でCTOをしているのですが、最近自分の仕事が何なのかよく分からなくなってきたことがこの記事を書こうと思ったきっかけです。
私はこの記事でいう所の「雑草CTO」であり、たまたま会社の初期に私以外に適任者がいなかったので成り行きで就任し現在に至ります。
そして、人数もプレッシャーも少ない総初期は来た玉は打つの姿勢でコーディングから渉外まで何でもこなしていましたが、メンバーが増え、それよりも早いペースでユーザーと仕事が増えてくると、自分の職務を定義しやることとやらないことをはっきり分ける必要が出てきます。
この翻訳が同じような状況にあるCTOの助けになればと思いますし、誤訳等があったら指摘してください。

出典: What does a CTO do?元のブログ

以下、翻訳です。


【問】
CTOのやるべきことは何なのか?

【答え】
この問いはまさに、私が2012年にClouderaのCTOになった時に追求したことそのものだった。私はこの問いの答えを見出すためにオンライン上でかなりの情報を漁り、また実際に私が尊敬しているCTOたちとも話し合った。

ここでは、私が得た知見を以下の四つの問いへの回答に要約しようと思う。

  • 問1. CTOの使命とは何だろう?
  • 問2. CTOは具体的に何によって評価されるべきだろう?
  • 問3. CTOは社内向けの仕事と社外向けの仕事のそれぞれに対してどういった配分で力を割くべきだろうか?
  • 問4. 社内の各部署に対してCTOが果たさなければならない責任とはなんだろうか?

ついでに述べておくと、私が以下に述べることは「純粋なCTO」を対象としており、CTOになってもなお社内の開発チームへの指示出しまで行っているような場合はその限りではないし、エンタープライズ向けのソフトウェアとそれ以外の違いという点でもバイアスが掛かってはいる。

  • 問1. CTOの使命とは何か?

    • CTOの使命は、以下A~Cの3つの軸に渡るものだと言える。
      • A : 会社の長期的な技術戦略の責任者
        • CTOは企業の技術戦略をきっちりと把握し、深化させ、明言し、また継続的に未来に向けて進化させていかなければならない。
        • CTOは、ダイナミックに進化している競争の激しい領域において会社が最高の技術上の成果を発揮しつづけられるようにしていく責任がある。
        • CTOは、企業の今後を左右するような世間の技術的なトレンドの情報を適切に噛み砕いて説明し、技術戦略とビジネス戦略の適切なバランスを保たなければならない。
      • B : 技術のエバンジェリスト
        • CTOは自身の長期的な技術に対する展望によって社内を沸かせインスパイアしなければならない。また、社外の人々にも、それが世界の行末であり我々こそが諸君をそこへを導くのだとだと確信させなければならない。
        • CTOはマーケットのニーズについて権威ある話ぶりをしなければならないし、自分たちの顧客に対しても確かな知見をもっている必要があるし、自分たちに投資することの価値とROI(投資利益率)について幅広い層の人々に名言しなければならない。
      • C : エンジニアたちの精神的リーダー
        • CTOはエンジニアチームを、長期的視野にたった上での技術的ゴールに向かって導かなければならない
        • CTOは新人エンジニアをここに入りたいと思わせ、新たな才能を組織に供給しなければならない。そのために、組織のエンジニアカルチャーを才能あるエンジニアにとって魅力的であり続けるよう維持しなければならない。
  • 問2. いかにしてCTO のパフォーマンスを測るべきか?

    • 私は以下三つの面があると思う。
      • A : 技術戦略の布石を打つこと。
        • これについては二面性がある。もしも企業が技術のトレンド(例、インターネット)を逃したらダメ、一方で技術戦略とビジネス戦略の協調に失敗したらそれもダメ。この点に関してはサン・マイクロシステムズの Greg Papadopolousの言を引用しておこう。
        • "CFOは四半期ごとの収益に対していちいち責任を持つことはないが、会計上で一度でも想定外のやらかしを犯した場合はクビにすべきだ。同様に、CTOは四半期ごとの開発プロジェクトにいちいち責任を持つ必要はないが、もしも技術上の決定的な波に乗り遅れたら彼をクビにすべきだ。"
      • B : 社内のエンジニアカルチャーのヘルスチェック
        • エンジニアの幸福度と生産性が同時に高いかによって測れるだろう。それらの指数に問題がある場合、すでにいる優秀なエンジニアは摩擦を感じているだろうし、外部の才能あるエンジニアを魅了することはできない。
      • C : 社内における顧客満足度(Internal Customer Satisfaction Survey)
        • CFOに似て、CTOは組織内部における従業員のためのカスタマーサポートセンターのような存在であるべきだ。御用聞きとしてのCTOに対する社員の顧客満足度が低ければ、彼をクビにすべきだろう。
  • 問3. CTOはどのように彼らの時間を内側と外側に分けるべきだろうか?

    • これに対しては完璧な回答はなくどっちもまあ大事(bit of both)としか言いようがないだろう。外部の知識なくしてCTOは組織内で良い仕事はできないし、その逆も然りだ。その両方をこなすことによってこそCTOは組織に対して貢献できる。
    • また、この点に関しては継続的にその組織で実際に働いてみることで落とし所を見つけられるだろう。さらに言えばその答えは君の会社が成長段階のどのステージにあるかによっても異なる。
    • たとえば私の場合、今日という一日を以下のように使い分けた。
      • 社外向け:70%
        • Sales/customers : 35%
        • マーケティング、エバンジェリスト業、分析 : 20%
        • アライアンス : 15%
      • 社内向け:30%
        • チームへ外部の状況を噛み砕いて共有する。
        • 技術的な展望を踏まえてこの会社は実際にどこに向かおうとしているのかを理解してもらうための、継続的なエンジニアリングとプロダクトとビジネスの接続。
        • マーケティングチームのWhite Paper(技術者・専門家向けの資料)づくりに対するアドバイス。
        • エンジニアカルチャーまわり、意思決定、リテンション(社員流出の引き止め)
        • 知財戦略の指導。
  • 問4. CTOの、社内の各部署に対する責任について

    • 以下五つの部署に対してCTOは果たすべき役割があると言える。
      • CEO/企業戦略
      • エンジニアリング/製品開発
      • セールス
      • アライアンス(BizDev)
      • マーケティング
    • 以下、順に見ていこう。
      • CEO/企業戦略
        • 社のビジネスに決定的な影響を与えうるあらゆる技術上の転換点の預言。
        • どの技術に賭けるべきかを長期的視野に立ってアドバイスする。
        • CEOに、与えられた時間の中で取りうる複数の選択肢を提示する。
        • 君は、会社の技術戦略にたいしてニュートラルな見解をずばずば言う奴だと思われるべきだ。
        • ゆえに、CTOはCFOに似て、必然的に、直接何かのビジネスプロジェクトを抱えるべきではない。
      • エンジニアリング/製品開発
        • CTOはエンジニアチームのその日その日のマネジメントに責任を持つ必要はないが彼らの近くで働くべきではある。 彼らに自分たちは正しい道を進んでいると確信してもらうために。
        • 長期的な技術戦略に集中するため、日々の雑事にとらわれるべきではない。
        • CTOにとっての一つの重要な挑戦は、いかにしてプロダクトマネジメントや製品開発に介入することなしに彼らに勝利の栄冠をもたらすか、だ。それこそが、君が努力して自分をインフルエンサーたらしめなければならない理由であり、また、自分が着手するアイディアの取捨選択を厳しくやらなければならない理由でもある(戦場を選ぼう)。
        • VP of Engineeringから君は役員側を代表する人間であると思われなければならないし、彼自身が思ったままを述べられるようにしなければならないし、彼が今抱えている問題についてブレインストーミングするのを助けなければならない。CTOとVP of Engineering は二人三脚(bounded at the hip)であり、決定的な関係を持つべきであり、そのために有意な時間を割くべきである。
        • 雇用と引き止めにも役割を果たすべきである(それにはアカデミックな世界との関係も含まれる。
        • 継続的に組織間のコミュニケーションの無駄を省き、それを内実豊かなものにすべきである。
        • 開発組織間の協調を維持するべきであり、必要であれば、技術中心主義的ないさかいや、どのアーキテクチャを採用すべきかに関する紛争を調停すべきである。
        • 定期的にハッカソンを組織し、そういった場所で発生するイノベーションの初期段階の世話役であるべきだ。
        • マスターアーキテクトとしてプロダクトを超えて奉仕すべきだ。
          • まあ、Clouderaでは私はそれをあまりできていないが、幸いClouderaには私よりも優秀なアーキテクトがたくさんいるし、私にできるのは彼らがそれに集中できるよう手助けするだけだ!
      • 営業に対して
        • まず重要なことが3つある。
          • 1つ目が、案件をクローズすること。
          • 2つ目が、案件をクローズすること。
          • 3つ目が、案件をクローズすること。
        • 重要なので三回強調したが、君自身も重要な取引先と対等で良い関係を持ち、営業をサポートすることだ。
        • 取引先とのミーティングでは技術的なロードマップを雄弁に述べ、取引先に我々こそがその業界のリーディングカンパニーなのだと確信させよう。
        • その市場に対する権威であるかのごとく振る舞おう。得意先のニーズを聞こう。彼らが抱えている問題を素早く理解しよう。そして会社の製品に関して良いアドバイスをしよう。
        • これも非常に重要だが、「わかりません」と正直にいうタイミングを知ることだ。優秀なCTOは決してその場で知ったかぶりや空約束をしない。それを熟知している適切なメンバーに繋いであげよう。
      • BizDevに対して
        • BizDevチームの協業の締結に協力すること。そして協力企業との関係を維持すること。
        • パートナー企業の技術に関して、それがこちら側のプラットフォームや、要望や、カルチャーと本当にフィットするかを踏まえたうえで、適切な注意点と買収目標を示そう。
        • 同じ業界のテクノロジースタートアップ企業の動向に常にキャッチアップし、彼らの技術の特性のマッピングをしよう。CTOは、可能なM&A、自社に欠けている技術、それにおいて(従属的な領域も含め)どの企業がベストな働きをしてくれるか、どの企業が最高の技術チームをもっているか、競合にどこを買収されたらキツイか、などについて明確な見解を持っているべきである。ただし、私は特にこの部分に関しては私の会社のco-founderに依っている。
        • 技術者コミュニティに会社を代表して参加し、プレゼンスを発揮すべきである。
        • パートナーの技術がもともと想定していた自社の技術的なロードマップにおいて重要なインパクトを与え得るかどうかを予測しよう(例えば、新しいクラウドのストレージやコンピュータデバイスなど)。
        • 市場の絶え間ない変化において、何が競争優位性に繋がるかを予測する。
      • マーケティングにおいて
        • 同社の技術に関する公の「顔」としての役割を果たそう。
        • 会社のビジョンと技術の方向性のエバンジェリストとして、カンファレンスや講演会に参加し、広報/メディア/分析における活動を行う。
        • 自分たちにとって重要な業界のご意見番と良好な関係を維持する。
        • 自社の製品を用いたアクティブなコミュニティ(例:ミートアップ、ハッカソン、業界のカンファレンスなど)を形成し、マーケティングチームをサポートしよう。
        • ツイッター、ブログ執筆、メディアへの記事掲載、ホワイトペーパーの発行などによる情報発信を行おう。
  • 要約すると、偉大なCTOは、一歩引いた目線で森全体を見渡し、顧客とエンジニアの双方の声を代表することで、企業にとって掛け替えのない存在になることが出来る。あなたが駆け出しのCTOであれベテランのCTOであれ、私はこの記事が役に立つことを願っている。ここで紹介している意見に同意できない場合や、見落とされているCTOの重要な役割がある場合は気軽に知らせてほしい。健闘を祈る!


【考察】

  • さまざまな役割が挙げられていますが「CTOは四半期ごとの開発プロジェクトにいちいち責任を持つ必要はないが、もしも技術上の決定的な波に乗り遅れたら彼をクビにすべきだ。」がやはり重要で、CTOのやるべきことは全てはそこからの演繹で定義されるべきでしょう。
    • 「波」の例として筆者はざっくりと「インターネット」を挙げていますが、現在の具体的な例としては、アプリというプラットフォームはいつまで続くか?、アプリの開発プラットフォームの選定、サーバレスの導入、どうすれば人工知能と自社の情報資源を組み合わせて価値をうみだせるか?...などの判断が挙げられます。
    • また、筆者が繰り返し述べている外部との交流の重要性や「CTOは直接プロジェクトを抱えるべきではない」という主張も、新しい技術的な潮流が来てすでに自社で使用している言語やフレームワークを放棄することを俎上に載せなければ行けなくなった時に中立的な判断を出来るようにするため、という意味があるでしょう。