小俣泰明（TAIMEI）@taimeidrive

NTTコミュニケーションズなどの大手ITベンダーでシステム運用やネットワーク構築の技術を磨いた後、面白法人カヤックでディレクターを担当。その後、2009年4月に上場企業の取締役に就任。2012年8月にトライフォートを共同設立、代表取締役Co-Founder/CTOに就任。スマートフォンアプリ・ソーシャル領域に特化した開発・運営を展開している

今回もエンジニアtypeの連載にお付き合いいただきありがとうございます。

先日、CTO忘年会という各社の最高技術責任者が集まる会に参加しました。

ここでは採用技術の話や組織論といった多岐にわたるテーマを、素晴らしいCTOの方々から聞くことができます。

CTO会は長く続いていますが、今回は5～60もの人が集まりました。つまり、「5～60社の技術トップ」が集まったことになります。ITベンチャーの勢いを改めて認識させられましたが、それと同時に、「CTOという職種って何なんだろう？」と考えさせられる良い機会になりました。

最近は、「最高技術責任者」という肩書きが付いているだけで、特殊な会合に参加できたり、「すごい人だ！」となる傾向があるように思います。でも、集まっている人たちの話を聞くと、会社の規模も違えば、要求される技術スキルも違います。

大企業の場合、CTOはたくさんいる技術者の中で1人しか選ばれないポジションですが、だからといってCTO以外の技術者が優秀ではないというわけではありません。

そこで今回は、「肩書き」より「果たす役割」が重要だという話をしたいと思います。

最新技術は、あくまでも選択肢の一つでしかない

CTOの仕事とは何か？という壮大なテーマについて考える前に、まずは分かりやすい事例から書きましょう。

CTOは会社における技術の最高責任者なので、自社が手掛ける製品やサービスにどんな技術を採用するか？という点に裁量があります。ここで求められるのは最新技術の知識。課題解決をする手段を多く持っているほど、CTOとしての能力が高いと言えるでしょう。

ただ、ここで誤った判断が生まれやすい。目的なく「最新技術を採用することが正しい」という誤りです。

最適解は必ずしも最新技術ではありません。最新技術を常に知っておく必要はありますが、それはあくまで選択肢を増やすため。そして、最新技術のメリットを知ることで、レガシーシステムのデメリットを把握するためです。

抱えている課題に対して最新技術がマッチしているかというと、実はそうではないという状況が往々にしてあります。そのマッチしてない部分が、大きなデメリットを引き起こす可能性があるわけです。

また、技術は宗教じゃないということにも気を付けなければなりません。AWSが好き。オープンソースが好き。Windows系は嫌い。Railsは神！ といった宗教じみた判断で、技術選定をする人が非常に多いように感じます。

そういったCTOほど、競合技術の評価を怠ります。

例えばオープンソース信者は、Windowsサーバをインストールすらしていないケースが多いです。そんな状態で、果たしてオープンソース技術を正しく評価することができるでしょうか。

おそらくこのケースでは、「ライセンスフィーが高い」、「ブラックボックスだから」ということで、ググった程度の知識で評価をすることになるでしょう。CTOはその程度の知識で技術の優劣を判断してはならないし、宗教的な好き嫌いで判断をすることで、結果としてビジネスの勝率を下げることにだってつながってしまうのです。

技術選定における5つのポイント

CTOに求められる能力の一つは、そういった“技術宗教”にとらわれることなく、手掛けるビジネスの勝率を上げられるかどうかという観点で技術選定をすることです。時に、自分の好きな技術をも捨てる勇気が必要になります。

もう少し具体的な判断基準として、用いる技術選定における5つのポイントを挙げておきます。

【1】エンジニアの確保の容易さ
【2】参考文献、情報の多さ（正確には質の高い情報があるか、情報の増加スピード）
【3】組織への浸透が可能か？（現在のチームに対して浸透ができるほどのコミュニケーションが取れるか。そういった柔軟な組織であるか？）
【4】採用技術自体の体制。更新（バージョンアップ）速度が目的のビジネススピードにマッチしているか？
【5】技術者メリットではなくユーザーメリットになっているか？

最後の【5】は、僕自身への自戒も含んでいます。このライブラリを使っていると楽しいし、開発も楽だし、バグとか防ぎやすいし、メリットだらけ！……みたいな判断で、技術者へのメリットしかないものを採用してしまいがちだからです。

しかし、僕の経験上、こうした判断はビジネスの勝率にあまり影響しません。逆に管理コストが増えて、体制が膨れ上がって動きが遅くなるなどのデメリットを生むことになりかねません（ライブラリなどについては、メンバーから「入れたい」という要望が来ることも多いため、ある程度現場に裁量を持たせるのも必要かもしれないですが）。

CTOの力量が最も表れるのは「平時の課題解決」

話を元に戻して、CTOでなくとも、ある程度の組織規模になっている企業で開発リーダーや技術マネジャーをしていると、CTOと同じような能力を求められます。

つまり、CTOという肩書きがなくても、役割として小さなITベンチャーのCTOと同レベルの判断力を求められるケースは多いのです。

では、そういう人たちに要求される「判断力」とは何か？それは、「課題解決の道筋」を見つけることです。

ビジネス上の課題が見えている状況であれば、難易度はそれほど高くはありません。難易度が高いのは、むしろ課題が見えなくなっている状況の時。現状がうまく回っていて、多くの人が満足している状態の時です。

ここから潜在的な課題を見つけ出し、さらなる成長に向けたアクションプランを作ることができるか。そして、そのアクションの重要性を、組織、チームに浸透できるか？それこそが腕の見せ所になります。

特に業績が良く、目先の業務がうまく回っているような企業だと、そこからさらに上を目指すというモチベーションを生み出すのはなかなか難しいものです。しかし今のIT業界、満足したらそこで成長が止まります。半年もすれば競争力に影響し、 簡単に業界内順位もひっくり返ってしまいます。

「今の状況に満足せず前に進み続けること」

この状態を維持することが重要で、これは口で言うほど簡単なことではありません。こういう状態の時に解消しなければならない課題とは、「徹夜を続けて課題に取り組めば解決できる」といった類のものではないからです。

先ほど書いた技術選定の例一つを取っても、この視点で課題解決ができる人、現状に満足せず前に進もうと考えられる人は、CTOという肩書きの有無を問わずとても優れた技術者です。

優秀なエンジニアを目指すのであれば、ぜひこのマインドを持って前に進んでほしいと思います。「肩書き」にしばられるのではなく、「役割」としてチームに何を与えているかに注目して、仕事をしてほしいです。

「役職」ではなく「役割別」に技術者が集まる会合が必要だ

ということで、本当は「CTOだから偉い」、「すごい技術者だ！」なんてことはなくて、本質的に技術者が目指すべきは「今の会社の中で何を役割として果たすか？」ということなのです。

モチベーションアップのために、CTOや最高技術責任者といった肩書きを付与するケースが多すぎる現在。CTO本来の役割をこなし、CTOになるべくしてなった者と、偶然社内にその肩書きの人がいなかったからなったという人との差は大きなものがあるように感じています。

極端に言えば、すでに「CTO」という肩書きが、技術者の能力を図る手段にはなっていないのです。

僕としては、「CTO会」という役職で括られた会合ではなく、「役割別」に技術者が集まるような会合が必要だと感じています。

最後まで読んでいただいた方へ。ぜひ、「役職別」の会合ではなく、企業を超えた「役割別」の部会設立に僕と一緒に動いてくれたら幸いです。

ありがとうございました。