CTOとはどんな仕事?その意味・役割などを徹底解説

CEO(最高経営責任者)、COO(最高執行責任者)などに並び、企業における重要なポジションのひとつであるCTO(Chief Technical Officer / 最高技術責任者)。IT関連のスタートアップ企業でも、経営層に名を連ねているのをよく見かけます。

CTOとは技術的な意志決定を行う最高責任者……という意味は知っているものの、実際に企業ではどんな仕事をしていて、どんな苦労があるのでしょうか? また、一般的なエンジニアと違い、経営層として求められる視点とは?

そこで、株式会社レクターの代表取締役であり、一般社団法人 日本CTO協会の理事を務める広木大地さんに、CTOが果たす役割について話を聞きました。


広木 大地(ひろき だいち)さん
株式会社レクター 代表取締役。
2008年に株式会社ミクシィに入社。同社メディア開発部長、開発部部長、サービス本部長執行役員を務めた後、2015年退社。株式会社レクターを創業。技術経営アドバイザリー。著書『エンジニアリング組織論への招待』がブクログ・ビジネス書大賞、翔泳社技術書大賞受賞。一般社団法人日本CTO協会理事。

CTO(最高技術責任者)、他の「C職」となにが違う?

――「最高技術責任者」と聞くと、“その会社で最も技術に詳しい人”といったイメージがあるのですが……そもそもCTOとは、どんな職業なのでしょうか?

広木さん:もちろん技術力は必要ですが、それだけではありません。最高技術責任者とは「技術を経営に活かしていくための最高責任者」だと思ってください。

会社経営では、「この技術に力を入れたほうがいい」「開発はこう進めたほうがいい」など、技術的な意志決定が必要となる場面があります。その意思決定において、最も大きな責任を持っているのがCTOです。CTOには技術と経営、両方の観点が必要なんですね。

――経営となると、CEO(Chief Executive Officer / 最高経営責任者)やCOO(Chief Operating Officer / 最高執行責任者)といった役職がありますよね。どういった違いがあるのでしょうか?

広木さん:例えばサービスを提供するスタートアップの場合、製品を作り上げるところに責任を持つのがCTO、その製品をお客様に売るところに責任を持つのがCOO、そして全体の経営資源の配分を考えるのがCEO、という役割なことが多いですね。

もちろん、それぞれの役割は独立しているわけではなく、密接に連携をしています。たとえば、CTOは製品開発の組織作りにも責任を持ちますので、事業の伸びに合わせ、必要な人材の採用計画を立てることも少なくありません。事業責任者やCOOと「こうすればチームがうまく回りそうだ」と話し合いながら、組織作りを進めていくことになります。

――なるほど。ちなみに、CIO(Chief Information Officer / 最高情報責任者)という似た名前の役職もありますが……。

広木さん: 一般的に、CIOは社内の情報システムを活用して業務効率化を図るような、「守りのIT」を担当する人を指すことがおおいですね。対してCTOは製品を作り出す「攻めのIT」を担当する役職……といったところでしょうか。

とはいえ、CTOとCIOは兼任されることも珍しくありません。CTOは会社のサイズによって役割が変わってしまうんです。そこが大変でもあり、おもしろいところでもあるんですが。

――スタートアップのように社員が少ないと、CTOが現場のエンジニアも兼ねていたりする、というイメージでしょうか?

広木さん:そんなこともありますね。スタートアップ期は、やはりエンジニアとしてガリガリと製品を作る能力が期待されます。徐々に人数が増えてくるとチームができるので、CTOはチームリーダーやマネジメントを任せられる。さらに100人規模になると、組織戦略として採用強化や教育を考えることになり、もっと増えて500人を越えてくるとR&D領域といった将来像も描かねばならなくなり……と、役割は変化していきます

――組織が大きくなるにつれて、視座を変えていかないといけないんですね。

広木さん:大きい会社になると、「執行」と「経営」が分離されるようになりますしね。現場でチームを引っ張ってマネジメントしていくのは「執行」の役割であり、執行役員やVPoE(Vice President of Engineering / 技術部門のマネジメント職)がロードマップに沿って計画を遂行していくわけです。

一方、「経営」にはCEOやCOOなどのC職が経営方針に携わり、なかでもCTOは「3年後の組織や技術単価はこうあるべき」といった、将来的な戦力を立てることが主な役割になります。

大変になることを知りつつ、「アクセルを踏む」判断をする

――CTOは技術者でもあり、経営者でもある……と。二つの顔を持つからこそ、大変な部分というのはありますか?

広木さん:特に気を使うのは、経営陣とのコミュニケーションでしょうか。開発に必要な資源を調達するためには、経営陣に「今なにができているか」「どこに課題があるか」を説明しなくてはなりません。ただ、ソフトウェアには「見えない」という性質があります

見えないものが適切に管理されているかを把握し、説明するのは、結構大変なことなんですよ。たとえばビルを建てていて、「完成しました!」と言われたのに全然できていなかったら、ひと目で分かるじゃないですか

――そりゃあ、「まだ更地じゃないか!」って言われるでしょうね。

広木さん:でもソフトウェアは見えないものなので、「完成しました!」と言われても、本当に完成しているかわからないんですよ。ふたを開けてみたら全然できていなかった、ということも十分あり得ます。

そんな見えない、管理しにくいものだからこそ、CTOが経営陣にシステムの内容や開発状況をしっかり伝えなくてはいけません。これを怠ると、経営陣が意志決定を間違えることにつながりますから。

――技術者と経営者の双方の顔を持つCTOだからこそ、できることですね。

広木さん:そうですね。経営者と技術者とでは、使っている言葉が違います。ソフトウェアという見えないものが持つ性質や文化を、経営陣にわかる言葉に翻訳して伝えるのもCTOの大切な仕事です

――しかしそうなると、「経営陣がどれくらいITに詳しいか」によって、仕事の大変さが全然違うものになりますよね。ITを知らない経営陣が無茶な計画を立ててしまったり……。

広木さん:それがあまりに無茶な内容であれば、CTOがブレーキをかけないといけませんね。ただ一方で、状況を打開するために無茶を承知で突き進む、アクセルを踏まないといけない場面があるのも確かです。

たとえば、事業会社でITサービスを開発しているとしましょう。納期厳守が求められる請負契約と違い、自社サービス開発はある程度リリース時期をコントロールすることができます。そうなると、CTO判断で「早くリリースするよりも、時間をかけて品質を上げよう」という選択もできるんですね

ところが、そうもいかない場面もあります。仮に、経営判断で「半年後にテレビCMを打つ」と決まったら、新しいユーザーがどっとやってくるその日までに機能を完成させないといけなくなるわけです

▲広木さんの著書『エンジニアリング組織論への招待』(技術評論社)は、2019年の翔泳社によるITエンジニア本大賞(技術書部門)やブクログ大賞(ビジネス書部門大賞)を受賞している。同書は、技術書でありながら人の思考やチーム構築を通して、エンジニアリングの「不確実性」にアプローチする内容

――技術サイドとしては、もっとサービスを作り込みたい。一方、経営サイドとしては、CMを打ってアピールをしたい。CTOとしては板挟みになってしまいますね。

広木さん:そうですね。開発の作業負担をしっているCTOであれば、「半年間で機能開発を終えて、大量のアクセスに耐えうる環境を作らないといけない」という大変さはもちろん理解しています。

そんなことを考える一方で、経営目線で「この事業は成功するはずだから、半年後の目標で勝負すべき」というのも理解している。そうなったら、なんとか実現する方法を考え、リスクをとって、アクセルを踏む決断をしなければいけないこともあります。

――技術側の大変さが分かるだけに、アクセルを踏むのも心苦しいですよね……。

広木さん:メンバーに負担をかけてしまうな……とは、やっぱり考えますよ。ただ、難しい局面だからこそ、「これまでCTOとしてどういう組織を作ってきたか」が試される場面でもあります。

厳しい状況を乗り越える鍵は、技術力だけではありません。サービスの意義や、叶えたいビジョンをメンバーと共有できているかも、重要な要素になります。「それでもやりましょう」と引き受けてくれるのか、「そんなの無理ですよ」と返されてしまうのかは、普段のコミュニケーションにかかっているところが大きいですね。

「穏便過ぎる」状況だって、心理的安全性は損なわれる

――「経営サイドに向けた仕事」だけでなく、CTOとしては「技術サイドに向けた仕事」もあるわけですよね。それはどういったものなのでしょうか?

広木さん:エンジニアが生産性を発揮するための環境整備も、CTOの仕事のひとつです。開発用ツールや自動テスト環境の整備など、技術的な仕組みを整えるだけでなく、勉強がしやすい雰囲気を作ったり、新しいことを試す際の承認プロセスを軽くしたり、といったことも環境整備に含まれます。

――技術的な面だけでなく、「チャレンジしやすい空気」みたいなものを作るわけですね。

広木さん:そうですね。やはり「出る杭は打たれる」みたいな空気では、生産性は発揮できません。特にソフトウェアは見えないものなので、リスクを発見して周りに伝えてくれる人の存在がとても重要です。気になったことを言いやすい環境であれば、問題解決も進みます。

――いわゆる「心理的安全性の確保」ですね。せっかく危険性を訴えて報告したのに、「どうしてそんなことになったんだ」と怒られたら、二度と報告する気がなくなりますし。

広木さん:怒られるのもそうですが、実は自分の意見が無視されたり、穏便すぎる形で処理されたりしてしまうのも心理的安全性を低くしてしまうんですよ。日本では「心理的安全性が高い=職場の雰囲気がいい」と思いがちなんですが、それは違うんです。

――確かに、怒られないなら安全、というイメージがありますが……。

広木さん:せっかく意見を言ったのに、「まぁまぁ」と流されてしまったり、「決まったことだから」とスルーされたりが続くと、言った側は無力感があるでしょうし、言いたいことも言えなくなってきますよね。職場の雰囲気を気にして発言できない環境は、結局心理的安全性が低いわけです。

「これって本当にこれでいいのかな?」と思ったときに、その思いを素直に口に出せて、他の社員も「確かにそれって問題だよね」と向き合ってくれる。そういう環境であれば、ふたを開けてみたら全然できていなかった、ということも起きにくくなります。

▲広木さんが代表取締役を務める株式会社レクターは、CTO経験者複数名による「技術戦略コンサルファーム」。他社からの相談をうけ、組織に合わせた技術コンサルティングを行っている

――なるほど。こうしたこともCTOは考えないといけないんですね。

広木さん:近年、DX(デジタルトランスフォーメーション)が話題ですが、もうひとつのDXとして、「デベロッパーエクスペリエンス」という言葉があります。直訳すると「開発者体験」。開発者にとって働きやすく、生産的な環境を作ることを意味します。

デジタルトランスフォーメーションをしようと思うなら、デベロッパーエクスペリエンスもやはり重要です。2つのDXを両輪にして回していくには、どちらの領域にも責任を持って取り組めるCTOという役割が欠かせないと考えています。

CTOは「スーパーマン」でなくてもいい

――ここまでお話を聞いていると、CTOという仕事は本当に大変だな……と感じます。深い技術の知見が必要なのはもちろん、経営陣に言葉を尽くさないといけないし、現場の空気も気にしないといけない……。たくさんのものを背負わないとできない仕事だなと。

広木さん:正直そうなんですよね(笑)。とはいえ、必ずしもスーパーマンでなくてもいいと思っています。

自分に足りない部分があれば、得意な人を会社に連れてくればいいんです。技術選定が弱いなと思ったら、技術選定が強い人を採用して、CTO室に入ってもらったらいい。「自分たちに足りないものを埋める」のも、経営者としての仕事です。

――広木さんが取締役を努める株式会社レクターでは、技術コンサルティングとして、さまざまな企業でCTO職の支援をされています。これもまた、「足りないものを埋めたい」と依頼されるわけですよね。

広木さん:そうですね。企業によって実現の仕方は違うものの、CTOとして、コアとなる部分はそこまで変わらないような気がするんです。

広木さん:支援先では「うちの会社はBtoBなので」とか「大きい会社だと意外と難しくて」とか、いろいろと難航している理由を聞きます。とはいえ、いろいろな会社のIT事情を見てきた経験を踏まえると「とはいえ、ここはできますよね」というのが見えてくる。

これは言い換えれば、CTO同士が情報を交換する場が足りていないのだと思っています。他社の情報を知っていれば、経営陣との会話でも「他社ではこうです」「こういう事例があります」と説明できますから。

私がCTO協会の理事を努めているのも、コミュニティ活動を通じてCTO同士の横の繋がりができたらという思いからです。DXに代表されるように、これから先、ほぼ全ての産業でソフトウェア化が進むと言われています。より多くの企業で、経営と技術の橋渡し役となるCTOが活躍できたら嬉しいですね。

文=井上マサキ/図版とイラスト=藤田倫央/編集=伊藤 駿(ノオト)

この記事が気に入ったらいいね!しよう

いいね!するとi:Engineerの最新情報をお届けします

プライバシーマーク