Webエンジニアのキャリアにはどんな道があるのか、先頭を走ってるいろいろなエンジニアに話を伺うインタビュー連載。第1回はグリーCTOの藤本さんです。

CTOの役割

─⁠─私舘野も最近CTO[1]になって、長年CTOをされている藤本さんが、CTOに対してどんな考えをお持ちなのかを聞かせていただければと思い、本日はお伺いしました。突然ですが、ぶっちゃけCTOってエンジニアなのでしょうか？

藤本：純粋な意味ではエンジニアではないですね。もちろん技術の知識は必要で、エンジニアリングも業務で兼ねたりしますけど、それだけじゃないですよね。

─⁠─大きな技術ビジョンを描いて、それに対して貢献したりとかでしょうか？

藤本：そうですね。会社がある程度大きくなると、そこに経営視点で貢献したり、技術と事業を結び付けたりなど、全体の舵取りをする必要があります。そういう意味ではいちエンジニアではありません。エンジニアの上のポジションであってもいいんですけど、その立場には別の人が技術マネージャとしていてもよいと思います。ただ、大きな技術ビジョンの実現はある種のんきな仕事でもあって、中長期的なことを考えることは本当は必要だと思うのですが、IT業界はサイクルが早いのでなかなか難しいですね。

─⁠─技術知識はどれぐらい必要でしょうか。意思決定に必要な分が必要とすると、会社が大きくなるにつれさまざまな技術、下はネットワーク層から上はグリーさんなら3Dプログラミングまで知る必要が出てきませんか？ どの技術をどの深さまで知ればよいとお考えですか？

藤本：理想を言えば、全部知るに越したことはないんですが（笑⁠）⁠。知らないと正しい判断ができる可能性が減ると言えば減りますが、決めずに進むよりもある程度「ここは弱い」という部分は割り切って決めて進んだほうが速くて、そのバランスをとって決めますね。

─⁠─そういった弱い部分には、その知識を持った信頼できるアーキテクト的な人が社内にいるということですか？

藤本：そうそう、その人とコミュニケーションしてしっかり意見を聞き出せるベースの技術知識があれば、補うことができます。そこが最低必須ですね。

現場でコードを書く力

─⁠─CTOは現場と一緒になってコードを書いて前に進めていく力はあったほうがよいでしょうか？

藤本：手を動かす力がある程度あったほうが価値が出せると思っています。ただ、マネジメントとして現場を前に動かしていく力でも場合によってはよいと思いますし、両方できたらそれはそれでよいですよね。また、技術を深く理解したうえで技術を選択していくアーキテクト的な立ち位置もあります。コードを書く力・マネジメント力・アーキテクト力、この3つはCTOとしてはどれもある程度は必要ですね。ただ、会社やCTO本人の趣味嗜好（しゅみしこう）によって、どこに比重を置くかは変わってきますね。

─⁠─藤本さんは、今はどの辺に比重を置かれていますか？

藤本：理想を言えば、コードをずっと書いていたいです。

─⁠─やはり自分で手を動かして、興味のある分野のコードを書き続けたいですか？

藤本：そうですね、浅くても深くても、個人としてはやりたいですね。でも現実問題、舘野さんもそうだと思うんですけど、現場でバリバリコードを書いてしまうと、それが必ずしもプラスでない場合もあったりしますね。自分でメンテナンスし続けられればよいのですが、できなくなってしまうこともあって、「⁠ここまでコード書いたから、あとは運用よろしく！」だと「ふざけんな！」ってなったりするので（笑⁠）⁠。本当にやるならちゃんとチームに入って業務時間の80～90％をきちんとコミットできないと、なかなか難しいですね。なので、今は現場に1日～2日入って一緒に課題解決するのが限界ですね。

─⁠─なるほど、どこかのチームに継続的に入るのは難しいのでしょうか？

藤本：ですね。ただ、会社に必要なプロダクトをがっつり作るタイプのCTOだと、チームにどっぷり入る方もいますね。

CTOはマネジメントであるべきか

─⁠─藤本さんはマネジメントもだいぶやられてきたと感じるのですが、CTOはマネジメントを行うべきなのでしょうか？

藤本：むしろ、マネジメントのほうが多かったです（笑⁠）⁠。

─⁠─たとえばエンジニアの育成だったりチーム作りだったり、評価だったり採用だったり、はたまた会社の文化作りであったり、いろいろあるとは思うのですが「これは必要だ」と思ってやってきたことってありますか？

藤本：結局、全部必要だと思いますね。ただ順番はあると思っていて、一番初めにくるのは文化作りですね。結局のところ僕らがどういう集団であり続けたいのか、そのことが会社や経営にとってどう大事なのかを、エンジニアにも非エンジニアにも伝え続けることが重要です。言い続ける人がいないと、あいまいになって崩れてしまいます。採用も、組織・エンジニアがこうありたいという視点から行いますし、研修も、どういう人になってほしいかという視点から内容を決めます。ほかにもキャリアの描き方や評価の仕方などにつながっていくので、最初に行うのは文化作りですね。

CTOと経営

─⁠─CTOは経営者であるべき[2]なのでしょうか。「⁠経営がやりたくてCTOをやっている」というよりかは、「⁠CTOなので立場的に経営も見なきゃね」と思えていた時期が私自身昔にありまして、どんな立ち位置で経営者であるべきなんだろうかという質問です。

藤本：CTOなら経営に携わるべきだと思います。「⁠経営は知らない」と言って技術のことだけやるのは現実的に難しいですし、そうしているとしがらみも増え、できないことも増えていってしまうので、自然と経営に携わる必要が出てくると思っています。しかし、技術力があるトップエンジニアを経営者にするべきかというと別の話だとも思っていて、マネジメントとして会社の意思決定に技術的な観点を反映させることができる人なら、経営メンバーとして入れるべきですね。

─⁠─エンジニアの観点を経営に反映させるとは、どういうことでしょうか？

藤本：2つあると思います。1つ目は防衛的な意味で、技術的に明らかに間違った意思決定や、エンジニアにとって不利な意思決定をちゃんと覆しにいけるかということです。事業側とやりたいことが衝突する場合も少なからずあって、その場合ちゃんと議論・牽制することが必要です。そのうえで経営が選択した意思決定をCTOはエンジニアにきちんと伝えるべきですし、そこを怠ると「事業の人はエンジニアをわかっていない」という齟齬（そご）をきたしてしまいがちです。内製でエンジニアがサービスを作っている会社では、技術で物を作る力が結局は会社の競争力になっていくので、しっかりと技術視点から守るべきところは守ります。

─⁠─なるほど。2つ目はなんでしょうか？

藤本：2つ目は戦略的な意味で、たとえば技術的な環境が今後こうなるので、事業的にもこっちに振っていくべきだ、などの技術観点からの意思決定ですね。本当は長期的に研究開発をしっかり行って、100の手を打ちつつ、そのうち1～2個物になって大きな競争力になる、といった考え方もあるんですけど、10年先に手を打ち続けられる会社はIT業界にはなかなかないですよね。1年ぐらいの長さだと、深く考えるより柔軟性や機動力重視の組織を作るほうが現実的だったりしますね。

─⁠─世界規模のプラットフォームがある、たとえばAppleやGoogleだと戦略的に長期的な視点でコミットしてそうですね。

藤本：ですね。ただ自社で作る以外に、M&Aで会社を買うやり方もあって、結局GoogleもAndroidやYouTubeを買っていますね。技術的な観点から相乗効果を見込んでM&Aするのは10年研究開発するよりも身近な話ですし、CTOとして求められる能力の一つであったりしますね。こういったことを考えていくと、直接的なエンジニアリングの仕事が減っていき、現場を見ることとは別の役割が出てきて、別の技術視点から会社に貢献できるようになりますね。

会社と技術の変革

─⁠─会社を小さい規模から大きな規模に成長させてきたと思うのですが、そのとき苦労したことや大変だったことはありますか？

藤本：そもそも楽だったことがないです。後悔していることは死ぬほどあるんですけどね（笑⁠）⁠。

─⁠─なるほど（笑⁠）⁠。

藤本：当時の僕が未熟だったのですが、組織が大きくなる過程で、準備やコミュニケーションをしっかりとせずに組織の上下関係のレイヤを作っちゃって波風が立ったとか。急激にサービスが伸びて負荷で止まったとかも、そのときなりに頑張っていたのですが、最適なアプローチだったかと言えば違うと思います。業務提携[3]を行い100万人のアクセスが急にくるかもというときに、どうやってアクセスをさばくべきなのかをしっかりと把握していませんでしたし、そんな中で数百台サーバを購入してアクセスに備えようと進めるのは相当ドキドキしましたね。ここで「本当にそんなにサーバがいるの？」と偉い人たちが超大作のプレゼン資料を要求してきたとかにはならず、「⁠エンジニアとしてそれだけ必要だというなら買うしかない」と話が進んだので、今思い直すとたいへん平和的でした。そういう意味だと楽させてもらっていますね。

─⁠─ほかにもありますか？

藤本：あとは今後もずっと起こり続ける話なのですが、市場や技術領域の変革に対し、どういった手段で組織を変えていくべきかが難しいですね。一昔前はWebベースの技術、主にブラウザとその周辺技術を考えていればよかったのですが、スマートフォンの登場以降、ネイティブアプリケーションなどが入ってきて技術領域が広がり、プロダクトの開発コストが跳ね上がりました。とはいえ技術領域をどんどん新しい物にスイッチできるかというと、既存事業とのバランスもとらなくちゃならなくて、これは大変と言うより難しかったですね。

─⁠─たしかに今までにない技術スキルが要求されてきていますが、この点はどう変えてきましたか？

藤本：キャッチアップには時間がかかりますが、1つの技術しかできないエンジニアはあまりいなくて、そういう意味では気にしていませんでした。ただ、プロダクトの作り方のプロセスがけっこう変わったり、エンジニアの役割がネイティブアプリへと変わってきたりしましたね。

エンジニアのキャリア

─⁠─キャリアの話っぽくなってきたので、その話をしていただけますか？ GitHubのようなコミュニティやライブラリのエコシステムの発展により技術習得の高速道路が整備され、いわゆる流行の技術をすぐ覚えることができますよね。一昔前ならRuby on Railsとか、今ならスマートフォン開発とか、良い物を再利用してすぐ開発できちゃうんですよね。そういうことを学習するのが好きで好きでたまらず高速道路を突っ走っている特に若いエンジニアと、どこで差別化していけばよいのでしょうか？ 一般論として語るのは難しいかもしれないんですが。

藤本：まず、そこに乗れるのであれば、乗れるようにならなくちゃ、というのが大前提としてあると思います。新しく便利な物をちゃんとキャッチアップする努力を怠ってはいけないです。もちろん昔ながらの方法でできることは知りつつも、必要に応じてちゃんとシフトできる柔軟性が必要です。

─⁠─はい。

藤本：一方で、エンジニアとして求められることは多岐にわたってくるので、サービスやプロダクトにシフトする人もいれば、深い技術にシフトし強みを発揮する人もいます。自分がどういうタイプで何が強みで何に向いているのか、時間をかけて見つけていく必要があります。たとえば僕だと、流行るプロダクトを作るのは得意じゃないんですよ。でも、いかに速いスピード・低いコストで作れるかを技術で実現することは得意分野です。

─⁠─なるほど。

藤本：広い分野をたくさん体験しつつ、自分の強みを見つけてそこで勝負できる組み合わせを選んでいく。いろんな技術のコストが下がる分、広くカバーしつつそれに2～3個自分としての強みを足していくイメージです。あとは技術をしっかりと理解することですね。それがないとエンジニアとしての競争力が薄れてしまいます。もちろん何かを実現するためにはありものの技術を使えばよいと思いますが、しっかり理解しているのとしていないのとでは、できることの深さや広がりに差が出ます。また、技術が背景にある強みを活かしつつ、自分が5年後、10年後どうなりたいのかを考えると、プロデューサーやマネージャーなど、エンジニア以外の道も見えてくるかもしれません。

CTOの楽しさ

─⁠─最後に、藤本さんが思う、CTOの楽しさについてお聞かせください。

藤本：何が楽しいかはタイプによると思うんですけど、今一番楽しいと思っていることは、この立場ならではの解決すべき問題に出会い、得がたい経験・視点を得られることですね。いちエンジニアとしてソフトウェアを作っていたときには絶対出会えなかった問題と出会えるのはすごくエキサイティングなことだと思いますし、問題解決は大変ですが楽しいことだと思っています。まだまだいろいろ勉強できることがある、おもしろい立場だと思っていますね。

「エンジニアの生存戦略」

─⁠─もう1点、藤本さんがブログ[4]で書かれていた「エンジニアの生存戦略」というのがすごく気に入っているので、それを連載タイトルにしてもいいですか？

藤本：ぜんぜんいいですよ。

─⁠─ありがとうございます！ 本日はどうもありがとうございました。