良いCTOは金の草鞋を履いてでも探せ (ZEROBASE BLOG)へ頂いたコメントを紹介します。それをきっかけとして、CTOの職務とは何かについて考えてみたいと思います。「天才エンジニア」と同様に「CTO」という言葉も曖昧に使われがちです。
→素敵な要約をして頂きました：CTOと「技術経営」 - Zopeジャンキー日記
今回のポイント
- CTOの職務は何か？
- それに必要な能力は何か？
前提
「CTOの職務」を論じる上での大前提ですが、「人に仕事をつける」という考え方ではなく、「職務に人をつける」という考え方を前提として読んでください。つまり、「ある天才エンジニアを連れてきてCTOという肩書きを与える」のではありません。さきにCTOという職務と、その職務記述書(job description)があって、そこに「CTOの職務記述書に相応しい人物を連れてくる」という考え方です。
誤解の無いように。「ベンチャーはそういう採用をすべきだ」と言っているわけではありません。人事戦略とはまったく関係ありません。「CTOの職務」を論じるならば、職務だけを（人から切り離して）論じるのが妥当であるという、議論上の都合です。
※なお、今回の文章における「CTOの職務」は、ベンチャーのCTOが果たすべき役割のうち、どのベンチャーでも共通するであろう部分です。例えば、私が「CTO」という肩書きの人に会ったら、そういう職務は担っているだろうと想像します。また、どこかのベンチャーにCTOとして参加しようとジョブ・ハンティング中の人に出会ったら、こういう職務が果たせる人なのかどうかを見たいと思います。
CTOという職務を明確にする必要性
まだCTOがいないときに事業計画書を書くならば、人員計画の一環としてCTOの職務記述書を書くのは有意義でしょう。自社の事業にとって必要だが欠けている（とくに技術に関する）能力は何か。それを理解する責任が経営者にはあります。まだ把握していなければ、その事業を経営する能力に欠けているかもしれません。いちど取り組んでみた方がよいでしょう。「自分一人で出来ないこと」が何なのかを把握していない経営者は、客観的に観て、危なっかしい。投資家やCTO候補者に対しても、「経営陣として（現時点で）欠けている能力」が何であるかを説明できた方がいいでしょう。そういう人材を探しているから協力してくれと頼むこともできるでしょうし。
職務記述書と「職務に人をつける」という考え方
職務記述書に書いてあるのは、人（こういう人が必要）ではなく職務（こういう職責が果たされるべき）です。つまり、「この事業にとって、この職務が果たされることが必要である」という言明が職務記述書です。ですから本来的には職務記述書は事業戦略に従うものです（※）。
職務記述書にマッチする個人を連れてくることができない場合は、複数人で分担するという選択肢もありえます。なにせベンチャーは人材不足です。
また、創業直後のベンチャーは、人材獲得競争でも大企業に対して不利です。
※「本来的には職務記述書は事業戦略に従う」･･･これには「ビジョナリー・カンパニー 2 - 飛躍の法則
「人に職務をつける」という考え方
そもそも冒頭に述べたように「人に職務をつける」ならば、職務記述書を書く必要はないかもしれない。
人に肩書きを与えるだけならばCTOでもGTOでもDDTでも良いではないですか。それは単なる「肩書き」であって「職務」を表していないのですから。
実際、東京で出会うスタートアップ（新興企業）の役員が凝った肩書きつけている傾向と、それらスタートアップで「人に職務をつける」傾向との間に、相関および因果関係があるのではないかと思っています。
繰り返しになりますが、ベンチャーは人不足であり、限られた出会いのなかで奇跡的に経営陣が形成されるのであり、選り好みできません。そのような状況で「人に職務をつける」ほうが自然の成り行きなのは想像に難くありません。
こういう原理が作用して、CTOという呼称が「職務記述書」の裏付けのない「肩書き」として遊離しているのではないかと。
経営陣（マネジメント・チーム）について
少し脱線しますが、経営陣の組成について。人不足で、選り好みできない人材環境にあるベンチャーは、どのように経営陣を組成すればいいか。
創業後に経営陣のメンバーを採用して揃えようとするのは、いろいろな点で難しいです。モチベーション、インセンティブ、「あなた雇う人／わたし雇われる人」の関係になってしまう点など。
ですから、まず経営陣（マネジメント・チーム）を作ってから、実際の創業（事業計画の立案、シードマネーの調達）を始める方がよい。もしできるなら、ぜひそうしてください。おそらく、成功確率や、成長スピードが向上するのではないかと思います（仮説に過ぎませんが、蓋然性は高いかと）。
少なくとも起業家一人より二人。チームのほうが投資家も投資しやすい、という傾向もあるようですし。
VCが投資したいのは経営をしたいチーム。たとえば海外の著名なVC、Y-Combinatorでは最初から「チームで来なさい」と推奨しているほど。 個人ですごいサービスを作ったから投資してくれ、では経営ができるか不安。ちゃんと経営や営業、財務ができる人と組んでから行くのがよいらしいです。 via ベンチャーキャピタルとどう付き合うか？ | IDEA*IDEA
以上、前提でした。長すぎるという声が聞こえてきそうです。
本論
もう冒頭に書いたことをみなさんお忘れでしょう。私も忘れました。仕方ないので再掲します。
良いCTOは金の草鞋を履いてでも探せ (ZEROBASE BLOG)へ頂いたコメントを紹介します。それをきっかけとして、CTOの職務とは何かについて考えてみたいと思います。「天才エンジニア」と同様に「CTO」という言葉も曖昧に使われがちです。
というわけで、まずは頂いたコメントの紹介です。
今回のエントリーでは、私自身がCTOで、単に天才エンジニアを雇えればいいという考え方もあるかなと考えさせられました。 ただ、この業界のエンジニアには上には上がいるし、特に向上心、知的好奇心というところからの成長力、爆発力みたいなものを持った人と出会え、事業と一緒に成長するような夢もあって、そういった人を引き込むにはCTOの席を用意して、共同経営者になって貰えるのが理想かなとも考えています。 投稿者: T-norf | 2008年08月30日 21:56
（※「私自身がCTOで、単に天才エンジニアを雇えればいいという考え方もあるかなと考えさせられました」への対立軸として「そういった人を引き込むにはCTOの席を用意して、共同経営者に」が示されているように読みました。この解釈が間違っていたらすみません。以下それについて論じます）
インセンティブとしてのポジション
なるほど、「やりがいのあるポジション」を用意すること、つまり「インセンティブ」として「CTO」というポジションを提供する、という考え方ですね。たしかにインセンティブとして「やりがいのあるポジション」は有効な場合もあるでしょう。
優秀な才能を獲得する上で「やりがいのあるポジション」というインセンティブは、とくに「経営陣」というポジションの場合、ベンチャーが提供でき、かつ大企業がなかなか提供できない「報酬」の最たるものです。ですから、その活用は（オプションとして）考えておいたほうが良い。なぜなら（前提として述べたように）厳しい人材環境にあるスタートアップにとって、優秀な人材の獲得のために活用できる数少ない切り札の一つが「やりがいあるポジション」だからです。
補足：肩書きそのものの価値
なお、「その企業は何をするつもりなのか」という事業計画とセットでなければ「CTO」という呼称は単なる「肩書き」程度の価値になってしまいます。そんな単なる肩書きとしてのCTOというポジションをやりたがる人がいたとしたら、むしろ採用してはいけないかもしれません。単なる肩書きとしての資格とくにMBAなどをありがたがるタイプである可能性が高くなるので。
あるベンチャーのCTOという職務に「やりがい」があるかどうかは、事業計画とセットです。人によっては「誰と働くか」もセットだったりしますが、さておき、「どんな会社であろうとCTOという肩書き自体が一定の価値（やりがい）を持つ」と思うのは大間違い。
天才エンジニアのためのポジション
さて、「天才エンジニア」に対して「やりがいのあるポジション」をオファーするとして、そのポジションが「CTO」であるべきかどうか。これは一考の余地があります。場合によっては「チーフ・サイエンティスト」「チーフ・エンジニア」という職務のほうが適切かもしれません。
ポイントは、彼の時間の100％を【手を動かすこと（プログラミング）】に使ってもらいたいかどうか。
もし、その「天才」が職人や科学者タイプで、彼が技術面に注力することが事業にとって必要ならば、それは「CTO」ではなく「チーフ・サイエンティスト」「チーフ・エンジニア」として任用すべきかと思います。なぜなら「CTO」の仕事は会議や書類と切り離せず、彼の実プログラミング時間がどんどん削られてしまうからです。
一方、その「天才」が、ビジネス（プロジェクト管理や商品企画・マーケティング）も理解している「マルチタレント」なら、まさに「CTO」の職務を立派に果たせる可能性は高い。そのようなCTOタイプは希有なので、彼自身がプログラミングするよりも、彼の指揮のもとで優秀なプログラマを何人も使ったほうがよほど経済的な価値が全体最適化されるというものです。
説明は省略しますが、分かる人には分かる説明としては、
サミュエルソンの有名な教科書『経済学』に、「タイプが速い弁護士でも、タイピストを雇うほうがよい」という話が出ている。 野口悠紀雄Online - Noguchi Library
つまり、ここで論じているのは「天才エンジニア」本人の生産性を最適化するのではなく、事業全体としての最適化なのです。部分最適ではなく全体最適。その考え方が分からない人は「ザ・ゴール ― 企業の究極の目的とは何か
「天才」
前々回は「天才」という言葉の使われ方に関する議論でしたが、ここで述べたのは「天才」にも二通りいるという観点。天才というと物理学のアインシュタインのような人をイメージする一方で、マルチ型のレオナルド・ダ・ヴィンチを連想する人もいるでしょう。その2通りに分けて、それぞれの適切な任用について論じるのが今回のテーマ。
肩書きの共通理解
ちなみに、ある会社が「CTO」という肩書きを、どういう意味で使うかは自由です。ただ、世間に流通している肩書きを使うなら、世間で容認されている用法が適切かと思います。今回は個別の企業について論じているわけではありませんし。従って今回の議論では「CXO」という肩書きを持つ人は「経営陣」であり「経営責任」を持つ人である、と考えることにします。なお、CXOとはCEO, CFO, CIO, CTO, CMOなどの総称です。変数Xというわけで。
事業の成功に必要な技術力とは
さて、繰り返しになりますが、要するに「CTO」の責任とは、製品開発を成功させることではありません。事業を成功させることです。「事業の成功のためには自社の技術力がどうあるべきか」を考え、計画し、遂行し、成果を出す。そのような責任を負う人が「CTO」です。
良いCTOは金の草鞋を履いてでも探せ。 というのを心がけてみてはいかがでしょうか。（これからネットベンチャーを起業するみなさま） ここは「良いエンジニア」ではなく「良いCTO」なのですよ。個人としてどんなに技術力が高くても関係ない。そのベンチャービジネスにとって必要な「技術」とは何かを経営視点で判断できる人をCTOと呼んでいます。極端な話、じぶんで手を動かす必要もないし、非常勤社外CTOでもいい（その役割だけに限定すれば、の話）。 良いCTOは金の草鞋を履いてでも探せ (ZEROBASE BLOG)
技術力を保有することも、製品開発という行為も、すべて「事業の成功」のための手段でしかない。高い技術力を保有することに、どれほどの資源が必要か、考えないといけない。製品開発という行為に、どれほどの資源が必要か、考えないといけない。
システムを作らずに済ますアイデア
ですから、
いちばんいいCTOは、システム開発を不要にするCTOだ。
という場合すらあります。それがすべてではないにしても、エンジニア出身CTOには欠けている場合があるので、強調しておきたい。
「ハンマーを持つ人には、すべてが釘に見える」と言います。エンジニアには、すべての問題が技術で片付くように見える。しかし、ベンチャーのスタートアップに必要な「技術力」とは、「いかに作らずに済ませるか」というアイデアであったりする。
新しいプロジェクトを始める前に、まず「システム開発が必要か」と問わないといけない。これをしなければCTO失格でしょう。CTOという言葉のイメージとは逆に、いかにローテクで、いかに少予算で、いかに競争力を築くか、という発想をすべき場面が多々あります。
なぜなら、システム開発には多くの資源が必要です。ベンチャーの資源は限られています。ならば、なるべく小さなシステムで、運用でだましだましでも、要件や機能を削って初期投資を抑えることや、工期を短縮することを優先すべき場面というのがある。
スタートアップなら、ほとんどの場合において「なるべく小さなシステム」を目指したほうがよい。
よく見かけるのは、非エンジニアの起業家が、事業計画書をもとに資金調達し、その資金でいきなりシステム会社に数千万のシステムを発注する様子。ほとんどが失敗する。そういう計画に投資するほうもどうかと思う。残念ながら事業を理解していない投資家も多いようです。
起業家ならば「商売を立ち上げる」ことを優先すべき。その基本を忘れて、自分で理解もしていないシステムに多額の投資をしてしまう。「事業におけるIT」を理解していないからこそ、なのですが。そこで、CTOの役割がある。システムを理解していないCEOが多額な投資をしようとするとき、CTOはストップをかけてやるべきなのです。
例えば、まずはMovableTypeやXOOPSベースで、Web制作会社に100万円程度で「でっちあげ」てもらい（つまりセミプロダクトのカスタマイズ程度で、見栄えだけ整える）、そのシステム化が不足する部分は、バイトに人力で処理してもらう（※もちろん単なる例です。金と時間を節約するイメージを伝えたいだけです）。
システムに出来ることで、人間に出来ないことなんて、ほとんど無い。リアルタイム性が若干下がるくらいです。「人力検索はてな」や「OKwave」を見てください。ネットはリアルタイムでなければならない、なんて思いこみを捨てること。Webサービスに必要なのは入力するUIと、結果を表示する画面。入力はメールでスタッフに飛ばして、人力で処理して、結果を打ち込んで、結果画面を生成すればいい。だったらMovableTypeやWordPressで十分でしょう。サイボウズ・メールワイズでも使えばユーザサポートもばっちりできるでしょう。
一般論ですが、システムにとっては、入力と出力がすべて。プロセスはブラックボックス。だったら人力でもいいわけです。ならば最初は人力でやれば、初期投資が10分の1で済むかもしれない。これがどれほど大きなことかを、まず理解しなければいけない、CTOならば。
もちろん、人件費とのトレードオフでもあるし、最初からシステム化したほうが良い場合もある。ただ、多くの人は、こういう発想を持てない。だから強調しておきます。
優秀なエンジニアほど、なんでも技術で解決したがる。だから、技術を使わない解決策は、むしろ難しい。それは能力の不足というより、考え方の欠如であって、いちど開眼すれば、もともと技術に詳しいのだから、いくらでも「技術を使わない解決策」を出せるようになる。
だから、どうしても、知って欲しいのです。
あらゆるWebサービスの画面はHTMLです。HTMLは手で書くことができます。ゆえに、あらゆるWebサービスの画面は手で書くことができます。
これを冗談と受けとめるか、ヒントとして「作らずに済ます」方向性を模索できるか、あなた次第です。
さきほどのMTカスタマイズの例をもう少し続けてみましょう。CTOはCEOに言います。
まずはMTのカスタマイズでサイトを小さく素早く立ち上げ、最低限の構成要素でこの事業の可能性を検証しよう。1ヶ月と100万円あればできる。それでフィジビリをしよう。
次に、500万円で独自システムを開発して置き換える。そのときこういう機能も追加しよう。それにより既存サービスの価値向上と、新しい付加価値を追加する。それについて反応を得て検証する。
その結果も大丈夫であれば、その次のフェーズでは500万円を追加投資しよう。ただ、その時点の開発内容がどうなるかは、その前段階によるから、何ともいえないが、現時点で想定できる要件リストは大ざっぱにこれくらい。だから実際に500万円になるかどうか分からないけど、現時点では妥当な水準だと思う。これについては、随時見直して、予測精度を高めていこう。
というふうに。こういう議論をするのがCTOの仕事だと、私は考えています。
ここで紹介した「仮説検証」「段階的投資」という考え方は、とても大事だと思うのです。戦略選択の不確実性に対して確率思考すること。どうやれば失敗率が下がり、成功率が上がるかを考えること。やらなければ分からない部分は、小さく試してみること。
そのためにプロトタイピングによるフィジビリという考え方があることを以前紹介しました。
開発投資という資源配分について
話を戻しますと、ローテクでも競争に勝つには、どうすればよいか。それには事業戦略の理解が欠かせない。ですから、本人が事業企画の専門家ではなくても、CEOやCSOと議論できなくては話にならない。自社の事業にとってSalesforce.comで十分なところを自社CRM開発などするようではCTO失格というわけです。
一方で、商売の努力だけでなんとかするより、ある程度のシステム投資で競争力を高められるなら、そのほうが良い。やはり「全体最適」の観点で考えないといけないのです。何の最適化かというと「経営資源の活用」であり、その評価指標は「利益」や「事業価値」です。
（※どのような指標を選ぶかは、まさに戦略の根幹であり、個々の企業でしっかり議論して決めるべきですね。文字通り「経営資源の活用」を表しやすく、色々な企業を比較するのにも使えるのはROAやROEなどですが、その企業固有の指標を設定することのほうがずっと大事だと思います。新規事業の立ち上げ局面では制度会計よりも管理会計のほうが大事、というか）
自社でシステム開発しないといけない場合。しかも、かなりの研究開発投資が必要な場合とは、どんな場合か。それは、自社の事業を成功させるためには、どうしても既存のシステムの組み合わせではだめである場合。あるいは、将来、お金が向かう場所（バリューチェーン上で利益が落ちる特定のプロセス）において必要な能力を獲得するために、どうしても自社で技術を保有する必要がある場合。このような場合が例として挙げられます。
あらゆるシステム開発にはコスト（お金）と工期（時間）が必要です。お金と時間という資源はとても貴重です。ベンチャーは調達した資金を使い切ったら終わりです。また、新しいビジネスにとって時間を浪費する暇はありません（※時間に比例して固定費を消費するという話は以前しました）。
経営とは資源配分だ、といっても過言ではありません。資源とは人・物・金・時間・情報などのことです。「資源は有限である」「限られた資源を最大に活用して成果を出さねばならない」ことを強く意識するのは経営陣として初歩的な仕事です。
だから、貴重なリソースを使ってまでシステム開発すべきかどうか、CTOならば問うべきなのです。どうしても「せざるをえない」システム開発だけをすべき。つまり要件を縮小する、システム化計画に関する能力が必要です。何を開発し、何を開発しないか。これを事業全体を俯瞰した上で考える能力が必要なのです。
まず事業から考えること。これをはき違えてしまう人はCTOに任用すべきではありません。逆に、凡庸なプログラマであっても立派なCTOになれるかもしれないのです。
プログラミングをしたいのか、自分が作ったプログラムを使わせたいのか。それが問題だ。 via 404 Blog Not Found:プログラミングとアプリ開発の違い
上記の文章は「プログラミング」と「アプリ開発」の違いとして述べられていますが、示唆的です。今回の論旨を同様の形式にすれば、
プログラミングをしたいのか、ビジネスをしたいのか、それが問題だ。
となります。CTOは「ビジネスをしたい人」であるべき。
CTOとチーフ・サイエンティストの違い
ちなみに、CTOからプログラミングを除いた仕事には、どんなものがあるのでしょうか。
例を挙げると、
- 事業戦略のなかに製品開発・技術開発のロードマップを位置づけて、それに必要な資源（金・人・物・時間・情報など）を見積る。
- それに事業開発にかかる投資や運転資金も加味して事業計画、資金調達計画を作ったりする（CEOやCFOと共に）。
- キーとなる技術が属人的で、外部調達不可能である場合、必要な人材のスペックを明確にして、ヘッドハンティングする。
- 技術部門と経営陣の間に立って、技術の言葉と、商売の言葉を通訳する。
等々。
（※個々の企業によって異なるはずです。前提で述べたように、職務記述書を書くことを通じて、自社に必要なCTOの職責を明確にできるかもしれません）
とまあ、こんな仕事をやっているCTOが、労働時間の何％を【手を動かすこと（プログラミング）】に使えるでしょうか。
だから、技術が事業の根幹をなすハイテク・ベンチャーで、その技術が極めて属人的なノウハウであり、かつ本人がかなりの時間を割いて研究開発に携わる必要がある場合、彼を任用すべきは「CTO」ではなく「チーフ・サイエンティスト」でしょう。
その上で、技術に関する経営陣への報告責任は、CTOの仕事です。CTOがチーフ・サイエンティストを管理する。チーフ・サイエンティスト本人が、できるだけ仕事時間の多くを【手を動かすこと（プログラミング）】に使えるようにするため、CTOが環境を整えてやる。それと同時に、チーフ・サイエンティストの努力の方向性が、事業への貢献となっているよう適切な目標設定をしてやること。
こういうかたちで、経営陣、そのなかのCTO、そこに貢献するチーフ・サイエンティスト、という体制をつくる。これができれば、核となる技術の開発で勝負するハイテク・ベンチャーとしては、なかなか良い体制と言えるのではないでしょうか。やはり「全体最適」の観点で組織設計しなければなりません。
このような理想論があったうえで、現実はどうかというと、そんな「贅沢」は実現しないものです。多くの場合、CTOがチーフ・サイエンティストを兼ねる。これが現時点で東京を拠点としてある程度成功しているネットベンチャーの多くの実態ではないでしょうか。
困ったことに、このような「結果」が「ネットベンチャーのCTO」のイメージを作り上げている。そういうベンチャーのCTOを見た人は、CTOとはアーキテクトであり、プログラマであり、サイエンティストである、と誤解している。
ここではっきりさせておきたい。結果的に兼務されているからといって、CTOとチーフ・サイエンティストの職務をごっちゃにするのは、ベンチャーにとって必要な職能への理解にとって有害です。誤解を解いておきたい。
CTOは、あくまでCXOです。あくまで経営陣（マネジメント・チーム）の一員です。CTOの職責は「製品開発の成功」「技術開発の成功」ではなく「事業の成功」であるべき。
技術開発にだけ責任を負うトップエンジニアの職務は「チーフ・サイエンティスト」や「チーフ・エンジニア」であるべきでしょう。
エンジニアが「CTO」になるには
もしあなたがエンジニアで、今回の意味での「CTO」、つまり経営陣として「ビジネスをしたい」のであれば、あなたが勉強すべきは技術ではなく商売です。
なんのための勉強か。あなたは技術を理解している。そのうえで、CEOやCSOと戦略について議論できるように。経営陣と技術部門の間で通訳できるように。そのための勉強です。
また、人手不足のベンチャーで働く気なら、エンジニア個人としての技術力も必要になる。ただ、そこでも「自分が手を動かす」以外の選択肢、つまりエンジニアを採用するとか、社外に発注するとか、産学連携するとか、そういった選択肢を考慮することがCTOとしての基本動作です。
もし、あなたが思い描いている「CTO」のイメージが「ビジネスをしたい」のではなく「最先端の技術に取り組みたい」なのであれば、あなたがやるべき職務は「CTO」ではなく「チーフ・サイエンティスト」や「チーフ・エンジニア」です。あるいは、そういう優秀な人の下で、いちエンジニアとして働くことだってできる。
繰り返しになりますが、これだけは誤解してはいけない。「CTO」という言葉を「カリスマ・エンジニア」くらいにイメージしてませんか？
ちなみに、
技術が分かってない社長さんは、ネットはすべてハイテクだと思ってますが、いまどき本当の技術力が必要なWebサイトなんて少ないですよ。ですから、「自社に必要な技術力」を過大評価しがちであることを自覚する方がよいでしょう。 via ネットベンチャーに必ず「天才エンジニア」がいる理由 (ZEROBASE BLOG)
と書いたように、あるいは、
プログラミングしたい人々は、物が出来るまでの過程を楽しみたい人である。だから、「DBにクエリーをかけてHTMLにぶちまけるだけの簡単なお仕事」が退屈で仕方がない。 via 404 Blog Not Found:プログラミングとアプリ開発の違い
というように、本当に「最先端の技術に取り組みたい」のであれば、そもそも「ネット」の業界は相応しくないかもしれません。あるいはNTTやKDDIなどの大企業や、学術機関の研究所のほうが向いているかもしれません。
CTOはいずれにしても必要
最後に。CTO役は誰かがやらねばならない。それはCTOという肩書きを持つかどうかではありません。会社にCTOという人がいなくても、実質的に誰かがそれをやっている場合はある。あるいは、CTOの意味をはき違えた会社では、CTOがCTOの仕事をしていないこともある。
なぜ必要か。それは「自社にとって必要な技術とは何か」という問いに、誰かが答えなければならないから。たとえ誰もこの問いに答えなくても、実質的には「自社にとって技術は必要ない」という判断をしていたり、「自社にとって必要な技術はきっとこういうものだ」となんとなく考えていたりするものです。CTOの職務とは、それを明確にすることです。（※文章か、図解か、形式はともかく）
CTOの仕事が、こなされる必要があるのにもかかわらず、こなされない場合、何が起こるか。社長がいきなり数千万のシステムをSIerに発注する。あるいは、いきなり10人のエンジニアを雇って半年間も開発して資金を食いつぶす。いずれにしても事業が成功する可能性は低くなるわけです。
こんな、IT投資における「避けられる失敗」を避けるために、CTOが必要なのです。
今回のポイント
おさらいです。
- CTOの職務は何か？ → 事業を成功に導くための、技術のマネジメント
- それに必要な能力は何か？ → 手を動かす技術力よりも、技術マネジメントの能力
今回は、ベンチャー企業（とくにネットベンチャー）のCTOが果たすべき役割の理想論、実態との乖離、それにより起こりがちな誤解、真のCTOになるために必要なこと、システムを作らずに済ます思考などを述べました。私自身の理解が及ばない点もあるかと思いますので、引き続きお気づきの点はご指摘いただければ幸いです。
→素敵な要約をして頂きました：CTOと「技術経営」 - Zopeジャンキー日記
補足
私自身も忘れていましたが、前回、次のように書いていました。図らずも、その解説になっていました。（記憶力悪すぎ）
だから、「天才エンジニア」がいても「CTO」がいなければ経営としては立ちゆかないケースだってありえます。本件とは少しずれますが。 via 良いCTOは金の草鞋を履いてでも探せ (ZEROBASE BLOG)