コードを書く人のほうが、CTOよりエラい？―サイバーエージェントCTOが語る、理想のエンジニアとは。

スタートアップが増えた今こそ、明文化すべき役割。

WEB・IT業界において、CTOの役割が語られることが増えてきた。昨年、Tech CrunchではスタートアップのCTO向けのイベント「CTO Night」が開催され、定員を上回る申し込みが入るほどの盛況だったようだ。一方で、CTOというポジションにフォーカスが当たるものの、具体的な役割や仕事についてはあまり明確化されていないようにも感じる。

CTOとは一体、何者なのか。この問いへの答えを探るべく、CAREER HACKでは数多くのCTOにインタビューを行なってきた。今回は約800名にも及ぶ大規模なエンジニア組織を擁するサイバーエージェント社の登場だ。

かつては“営業のサイバーエージェント”と呼ばれていた同社が、“技術のサイバーエージェント”と呼ばれるまでになった背景には、どのようなストーリーがあるのか。大手IT系出版社、大手ブロードバンド配信企業、大手インターネットメディア企業を経て、2006年にサイバーエージェントに入社し技術部門をけん引するCTOの佐藤真人氏に話を伺う。

また、技術のトップを担うCTOから見た「優秀なエンジニア像」を聞くことで、エンジニアが今後のキャリアを考える上での大きなヒントとなるのではないかと考えている。現在スタートアップで働くCTO、そして、これからスタートアップにチャレンジしようとしているエンジニアの読者は必見だ。

CTOは、背中で語れ。

― 早速ですが、佐藤さんにとってCTOの役割とはなんですか。

株式会社サイバーエージェント 執行役員 アメーバ事業本部ゲーム部門 全社システム本部 アドテク本部技術戦略室 最高技術責任者 佐藤真人氏

こんなこと言うと身も蓋もないのですが、CTOという肩書は社内ではあまり意味がないと思っています。10人、20人くらいのベンチャーであれば、その会社で使用される技術を全て広く深く理解し、判断するというCTOの役割は明確なのですが、事業と組織が大きくなってくれば必要とされる技術が多岐にわたってくるので、その技術を組織的かつ自主的に伸ばす意味でも、役割を変えていくべきと思います。

今のサイバーエージェントの規模におけるCTOの役割を定義するとしたら、“技術のプロキシ、経営層からみた相談窓口”と表現するのが一番合ってるのではないでしょうか。現場と経営陣の間に立って、たとえば、広告分野における技術アピールの相談に対する見解を述べたり、要素技術やセキュリティ、事業と直接関係ない基盤技術、そして役員間連携が求められる技術のナレッジを共有するための音頭を取っています。これらは、私自身が技術に対して幅広く理解していないと、「この技術って誰が得意なんだっけ？」と聞かれたときに「この人が詳しいです」というハンドリングもできませんから。少なくとも社内で使用されている技術についてはピンからキリまで理解できるようにしていますね。

また、技術の底上げ、現場力の強化を考えるうえでは、CTOは「エラいのは、自らコードを書いているエンジニアだ！」という価値観を現場に植えつけることが大切です。とはいえ事業を成長させていく上では、「重要なものはそれだけではない」という意識をエンジニア全体に共有していくことも、役割として大切だと思います。

― 現在のような約800名ものエンジニア組織になるまでの経緯を教えてください。

入社した当初は営業会社としての色合いが強く、会社としても社内のエンジニアをどう扱っていいのか困っているような印象を受けました。エンジニアは、外注のコントロールするメンバーを中心に10名弱で、あとは業務委託や契約社員が中心でした。そこで、まずは正規雇用のエンジニアが社内にいることの“価値”を示すことが大切だと考えました。当時、主力サービスであるアメーバブログは高負荷でとても不安定な状態でした。協力会社に依頼し問題の解決にあたっていましたが、スピード感も責任感も欠如した状態でした。そのため、少人数の体制でしたが、内製システムへの抜本改善を行ない、負荷や品質の改善を進めていきました。

成果が出れば、「社員エンジニアを増やすべきでは？」という空気が生まれますからね。同時期に社長自身もエンジニアの重要性を感じていたため、入社してすぐに「エンジニア大量採用を始めます！」と告知をし、結果的に優秀なエンジニアを多数採用することができたため、1年後には数十名規模の組織に拡大しました。

― エンジニアの価値を認めてもらうことで、組織化して、内製化の道を歩むことになったわけですね。ただ一口に内製化と言っても、既存のやり方を変えるわけですから、困難もあったと思うのですが。

内製化したことで、これまで協力会社に委託していたトラブル対応などもすべて自分たちで解決しなければなりませんでした。責任感の考え方と範囲が格段と増えたことにカルチャーショックを受けたエンジニアもいたと思います。

そこで取り組んだのは、発生したすべての障害の一次対応を自分が全部買って出ることでした。“背中で語る”といったら大げさかもしれませんが、業務上の課題と内容・量を把握できていないとマネジメントもできませんからね。

― その後、エンジニア組織が数百名規模へ急拡大するフェーズになり、佐藤さん自身の権限を委譲することへのジレンマなどはありませんでしたか？

ないといえばウソになりますね、自負もプライドもありますし。しかし、CTOとは会社の規模によって要求される働き方が変化していくものだとお伝えした通り、全て私がやってしまったらエンジニアが育ちません。私自身、失敗を経験したことで覚えてきたことが沢山ありました。当時、権限を委譲する過程で懸念していたことが、新体制ではうまく処理できず、「やっぱり厳しいな」と思うことも沢山あったんですが、それもちゃんと経験していってもらえればなと思い、あえて静観していました。自分自身、いつまでも手を動かしているだけでは、現場は成長しませんからね。

― 組織が拡大するときに気をつけるべきことがあったら教えてください。

組織規模が拡大すると、分業体制を敷くケースが多いと思います。でも、少なくともBtoCの業界では分業化はエンジニアの意欲を削いだり、責任感を薄れさせることが多いので細心の注意を払ったほうがよいと思います。当社では経営層からして、“CA8”という制度で定期的に役員が交代するなど、定期的に凝り固まりそうな組織を破壊しています。同様にエンジニア、クリエイターの組織もその時々で技術軸、サービス軸などを考えて頻繁に再編成されます。これにより、エンジニアが自己向上だけでなく、サービスに対する意欲やユーザーに対する責任感を持ち続けることのできる「厭きのこない組織」が維持できると考えています。

ユーザーが求めているものを生み出せるだけでは、優秀なエンジニアとは呼べない。

― 続いて、佐藤さんが考える“優秀なエンジニア”の定義や素養を教えてください。

マインド面が最も重要だと考えています。基本的には、技術に対しても組織に対しても“変化に前向き”であるということですね。先の例でいうと、内製化を始めたときのような大規模な変化が起こっても、自分が所属する組織に固執せず、その変化に最適な体制とそこで求められる技術、業務範囲に対応できるエンジニアです。私自身、採用には8年間携わっているんですけど、エンジニアとしてのマインド部分は最重要視しており、人事とともに厳選に厳選を重ねて見極めています。逆に、厳選して入社したエンジニアが活躍できない場合は、チームメンバーやマネージャーとの相性に原因があることも多いので、マネジメントサイドで責任をもって問題解決に取り組むことが必要だと思っています。

― マインドが最も重要なのは、柔軟に形を変えて成長するアメーバに通じていますね。

先ほど「コードを書く人はエラい」という話をさせていただきましたが、それは何も「要件を満たすコードだけを書いていればいい」というわけではありません。ユーザーやクライアントが欲しているプロダクトを生み出せるということは最低条件。ユーザーやクライアントの潜在意識の奥に眠っている部分を掘り起こして、具現化できるエンジニアこそが優秀であり、理想像だと感じています。もちろん簡単なことではありません。そういう見えないプロセスも手がけることができて、「コードを書く人はエラい」と言えるのです。

― どのような考え方を持ち続けて行動していくことができれば、ユーザーの潜在意識にアプローチできるようなエンジニアになれるのでしょうか。

いろいろな考えがありますが、一つの方法としては常に新しい技術をキャッチアップし、その成果を出していくということが考えられます。

「新しい技術」には単純に研究から生み出されたものだけではなく、ユーザーと向き合うなかで生まれる技術もあります。それらを組み合わせたり、足りないものを補って作り出せるエンジニアは、ユーザーが求めるものを「具現化」できる実践向きですね。たとえば、単なるユーザーの入力補助ツール程度にしか使われていなかったJavaScriptが、今やKinoma Createなどを使えば機器の試作までできるようになっている。以前ではASICのプロトタイプ作成でよくつかわれたFPGAが、今や市販のアプライアンスサーバでも実運用されている。そういう技術進化の先端をくみ取って、今までできなかったものを実現できるようなプロダクトをつくっていくとか。

当社のグループ会社のCAリワードが、RTB（リアルタイムビッディング）でのレイテンシー低減を目指して、リアルタイムOSとFPGAで専用のハードウェアを作ろうとしているのもその試みの一つといえるかと思います。

評価したいのは「自分の仕事は、世の中の役に立っている」という信念。

― サイバーエージェントには、エンジニアを評価する明確な基準などはありますか？

あまりないですね(笑)。強いていえば、エンジニア自身が「自分が学んでいること、つくっているものが世の中の役に立っている」という信念を持って業務に取り組んでいるかどうかが評価のポイントですかね。

直近で役に立っていないとしても、それはそれで構わないと思います。「誰も理解してくれないけど、この技術はいずれ必要になる！」というものがあってもいい。先のCAリワードの話も、確かにFXの取引などは時間の短縮化が求められるので、通常のソフトウェアでの処理からFPJで処理する時代になってきているんですが、広告業界の世界で必要とされる時が来るかどうかはわからない。でも、必要とされると考えて熱意をもって取り組んでいるエンジニアがいるわけで、そういう姿勢は高く評価しています。

短期的な利益で成果を出すことは事業責任者のほうが得意だと思いますが、中期的な視点に立つとエンジニアのほうが得意だったりすることもあります。エンジニアの上司になる人は、そこを尊重しないといけないと思います。

― では、実際にエンジニアを評価するときはどのような点を注意しているのでしょうか？

個別に、可能な限り丁寧なコミュニケーションをとるということですね。エンジニアの価値観って、人それぞれじゃないですか。ただ、最終的には、評価者の主観が入ってしまうものだと思います。だからこそ、密な対話を通して被評価者の価値観を知った上で、評価者や事業責任者の主観とどう融合できるかを考える。

たとえば、ベンチャー出身でビジネスマインドが強く、「どう儲けるか」というビジネスマインドの高いエンジニアと技術、研究者志向で事業にあまり興味のないエンジニアでは、目標とする方向性も求める結果もまるで違う。そういう部分ってコミュニケーションをとらないと見えてこない部分なので、やり取りはマメにしていますよ。

大前提としては、エンジニアの評価は、技術の会話ができる人、つまりエンジニアにしかできないと考えています。ただ、極限のところでは、特定の技術（とくに要素技術）に秀でたエンジニアの、その技術に対する評価は、どうしてもわからない部分が出てくるので、「ここまでの技術はわかるけど、ここから先はわからないから、このくらいの評価でどうだろう？」「君が私だったら、どのように評価する？」というようなコミュニケーションを重ねていくイメージですね。後者のようなエンジニアは「俺のやっている研究の価値が、俺以外のやつにわかってたまるか！」的な気概を持っているエンジニアがほとんどなので、逆に意外と評価は楽です（笑）。

― お話を通じ、規模によって変化するCTOの“役割”や、特にBtoC領域のサービスを手掛けるエンジニアに必要とされるマインドを知ることができました。スタートアップはもちろん、さまざまな企業のCTOやエンジニアにとって参考になるお話だったと思います。本日は貴重なお話をいただき、ありがとうございました。

（おわり）

［取材] 梁取義宣　[文]田中 嘉人

文 ＝ 田中嘉人
編集 ＝ CAREER HACK