CTOとはなんなのか、あるいはエンジニアの生存戦略

2013/12/25

Merry Christmas! GREE Advent Calendar もいよいよ最終日、25日目はグリー株式会社でCTOをしておりますふじもとがお送りします。

今日まで24人のGREE Engineersなみなさまにエントリを書いていただいたわけですが、思ったよりも多種多様な内容で、あらためていろいろな方面で素敵なエンジニアがいるなー、としみじみしてしまいました。いやしかしgitとchefの記事人気ですね、そして、「当然CTOはすごい記事書くんですよね」とプレッシャーをかけて楽しむ仲間たちに囲まれてぼくは幸せです、あーすごい幸せー。そんなプレッシャーの中、今までのエントリとはちょっと方向性を変えて、CTOの話でも書いてみようかと思います。なお、ぼくの趣味は多分問題解決です。

そんなわたくしふじもとは来年で、CTOっていう肩書きでお仕事をはじめて10年とかになるんですが、なかなか先輩というかロールモデルみたいなかたも身近にいらっしゃらなかったりします。考えてみればいわゆるインターネット業界の歴史がまだまだ浅いのでこれは当然かもしれません、という一方で、(CxO全般に言えることではありますが)CTOっていう仕事って「なにするひとなの？」っていうのが結構曖昧だったりします。さらには2013年は起業も多かったことですし (リンク先はさておき...正直Ex-GREEのCTOのひととか多分2桁くらいいらっしゃるんですよね...喜ぶべきか、悲しむべきか...)、もっとこの業界がエンジニアリングっていう側面で盛り上がることを祈りつつ、何らかお役に立てればってことでつらつらと書いてみます。あ、最初に書いておきますが、文字ばっかりです。

CTOってなんですか

一旦自分の考えはさておき、とりあえずフロアをうろうろしながら数人の社員のかたに聞いてみましたご協力ありがとうございます:

  • エンジニアの一番えらいひとですよねー (なるほどね)
  • きみ(ふじもと)のことじゃないの？ (まぁそうだけど...)
  • えっと、Chief Technology Officerだよね (間違ってはいない)

いきなりそんなこと聞かれても困るよね、と思ってたらいきなりちゃんとした答えがかえってきました:

  • 技術的な最終意思決定者、だと思ったけど最近はそれだけだとだめだとは思っていて、そうやって立てた道筋をあとからちゃんと修正できる、壊すことも役割として重要

ちょっと耳が痛いです、というか、きみさりげなくぼくdisったよなー、とか思いつつ、なるほどね、と考えたりするのでした。これについては後ほど少しふれさせていただきます。

そしてそして、困ったときのWikipediaです:

The role became prominent with the ascent of the information technology (IT) industry, but has since become prevalent in technology-based industries of all types (e.g. game developer, e-commerce, social networking service, etc.). As a corporate officer position, the CTO typically reports directly to the chief executive officer (CEO) and is primarily concerned with long-term and "big picture" issues (while still having deep technical knowledge of the relevant field).
...

詳細はリンク先を読んでください、ってことで簡単に、且つ多少恣意的にまとめると:

  • CEOのDirect Reportで、技術的バックグラウンドに基づく中長期の戦略を考えるひと
  • 組織によっては、VP (組織としてのトップ) や R&Dのトップとは別にCTOがいるというのもあり
  • 法的な側面や、知財の側面にも関わることがある

っていう感じですかね、分かるような分からないような！

正直なところ、知る限り日本には「プロフェッショナルのCTO」として確固たる地位を築いているひとっていない気がしていて (「経営者」っていうと名前でてくるんですけどね)、だからこそ前にCTO 48のようなイベントがあったり、最近でもCTO Nightとかがあったりするんだろうなーと思います。というか今日しったのですが、日本CTO協会とか、日本CTOフォーラムっていうのもあるんですね、ちょっと業界が違うんですが、これはこれでCTOとしての在り方の多様さを示している一つの証左ということなのかなと。

かく言うぼくも、暇さえあればいろんなかたに「CTOってなにすればいいんですか？」とか聞いて回ったり(一番印象に残ってるのは「採用だよ採用、あとブランディング」というある種割り切った、あんまり参考にならない答えだったりしますが)、挙げ句聞いて回るのが面倒になって、CTO飲み会とか開いて先輩にいろいろお伺いしてたりしてました、懐かしい(なにが懐かしいって、当時CTOだったひとがもうほとんどCTOじゃないという)。

あらためてCTOって

という歴史を経て、一口にCTOといっても、スタートアップな企業におけるエンジニアのトップ、という状況から、超大企業でまさに"big picture"のことだけ考えているパターンまで本当にいろいろなCTOのかたがいらっしゃると思うのですが、ぼくとしてすべてに共通して大事だと思っているのは:

  • 技術的な観点で経営にコミットすること

に尽きるかなと思っています。metaっぽくてよく分からない感じもしますが、一定以上の複雑さを持つ問題に対しては、一つの概念から演繹させることで解決策を認識するしか多分ないので、そういうもんだとご理解ください。

もちろん、会社立ち上げて間もない時期とかは特に、エンジニア組織の長(VP)や、サービスのアーキテクチャどうしようとかとか数限りない側面で仕事をしていかなければいけないですし、それもすごい大事なんですが「CTO」として一番にコミットすることが要求されるのはここになるのかな、と思っています。これまでも、そしてこれからも多くのサービス、プロダクトがつくられていくわけですが、その根幹となるTechnologyを会社としての意思決定にきちんと反映させること、それを持続することは、競争力を持った会社、サービス、プロダクトを作っていく上では欠かせないとやはり思うのです。

...といったところで我ながら未熟もいいところなんですが、改めて肝に命じてがんばっていきたいなと思った2013年末です、はいすいません、努力します。

CTOって必要ですか？

なんか終わりそうな感じですが、まだ終わりませんすいません。

立場上なのかなんなのかここ最近頻繁に、起業をしようとする方のご相談、特にCTOを探しています、というお話を頂くのですが、そもそもCTOって必要なんでしょうか？

いやここで要らないっていうと前述の内容というか、そもそも自分全否定なので、まぁ必要だよね、というここでの結論なわけですが、例えばGoogleってCTOいないんですよね。などといいつつちょっとこれは例外で、Management TeamにどこいってもCTOできそうなひとが集まっているので (Eric SchmidtとかSunのCTOでしたし)、そういう会社でもない限り、やはり会社にTechnologyという血を通わせる役割のひとは、肩書きがどうあれ必要なのかなと考えます。

ということで、世界に羽ばたくインターネットサービスを！というかたは是非良いCTOを見つけていただければと心から願います、多分そのほうが成功確率が上がると思うので。

やっておけばよかったと思ってることを1つだけ

いきなりpracticalな話になりますが、今にして思えば、ということで痛感していることを反省とともに記してみます (これは僕の経験なので、特に小規模な会社、サービスが数年のときを経て成長していく、というパターンで顕著なはなしです、という点にご注意ください)。これは書こうと思えば相当いろいろあるんですが、1つ書いただけで引きこもりたいくらい恥ずかしくなったのでとりあえず1つだけ...。

複数サービス前提でのアーキテクチャ

例えば起業をした場合、多くの会社がまず一つの自社サービスをつくるところ、あるいは既存のサービスをベースにして始まることが多いと思います (あるいは、いくつか作って当たったものに注力したり)。と、そこまではいいとして、アーキテクチャという観点で難しいなーと思うのは、これが2つ、3つになってきた場合のデザインです。

これには大きく分けて2つのパターンがあって、一つは完全に独立したサービスが複数あるパターンで、もう一つは、あるサービスを拡張し続けていった結果として(外形的に)2つ以上のサービスに分かれていく、というパターンです。

前者の場合、「ソフトウェアとして完全に疎であるのだ」と割り切ればそれで済む話なのですが、一方で同じ会社でやっていたりすると「あっちとこっちで同じような開発してると無駄じゃない？」と欲が出てきて「よーし、共通のフレームワーク使おう」「共通のライブラリ使おう」とかとかいう話になったりします。こういったケースでは、あとは共通化することによるメリットと、一方でそれによってそれぞれのサービスに与えられる拘束によるデメリットのトレードオフや、そのデメリットを解消するための解決策について考えればよいわけです (全うなpackagingやversioningそしてdeploy、依存関係のサービスを社内に用意するとかね)。まぁしばらくするとせっかくの共通のフレームワークとかがそれぞれforkして独自進化していたりして、うーんあれはなんだったんだろう、とか容易になったりするわけで、これは言うのは簡単ですが実際に解決するのは結構難しいです。

ただこれはまだ問題解決としてはノウハウも多いし、いくつかの解決方法を思いつくわけですが、さらに難しいのは、サービスを順次拡張していった結果、密結合された複数のサービスになっていた、という場合です。これは我ながらもう書いててツラいので詳細省いちゃいますが (色々な意味でほんとごめんなさい)、いずれにしても:

  • サービスを拡張していくタイミングや、複数のサービスを開発し始めるタイミングで、もう1回アーキテクチャについて真剣に検討したほうがよいです、どんなに急いでいたとしても
  • そして、基本的には結合を疎にしたほうがよいです (そりゃそうだろと思うかもしれませんが、前述の後者のパターンにおいては結構難しいもんです)

そんなの当たり前じゃないですかー、という天の声が聞こえてきますが、一定の連携を要求されるサービスを適切に疎結合な状態で設計するのはそれなりに大変ですしその粒度も正解はないので、都度頭を悩ませることになります。また、油断すると密な結合が「とりあえず1年くらいは」楽だよねー、うまくいったらその後考えよう、などと思ったりしてしまうわけです (思いあたる節があったり...しませんでしょうか？ぼくはいっぱいあります)。また、正解は3年とか5年経ってはじめて分かるという性質の問題ですし、予測不可能な将来に対して最適な選択をしていくのはやっぱり難しいなと思うので、絶対正解だ、というのを求めるよりは「どれが一番確率が高いか？」という考え方を最近はするようにしています、「正解」を考えすぎるとあまりに前に進めなかったりするので。いやしかし、9年とか経つと、あのときこうしておけば...というのは10は20じゃきかないくらいにあるのですが、いやほんとうにみなさますいません。

こういった問題解決の成功確率を上げるには、結局のところ

  • 過去の問題解決手法について振り返って
  • 当時どういう情報、どういう考えに基づいてそのオプションを選択したのか
  • (特に現在後悔している場合は)当時なにが足りていなかったのか (情報なのか、経験なのか、知識なのか、時間なのか)

という「反省」に基づいて現在ないしは未来の判断をよりよいものにしていくしかない、という当たり前の話になるわけですが、意外とこれが難しいので改めてここで自戒を込めて書いてみたというわけです。まぁ何が一番難しいって、中長期的なことばかり考えて5年どころか3年会社やサービスが続かなかったらそもそも仕方ないので、このバランスをとるのが何よりも一番難しいんですけどね！

ひとが増えてきたらどうするか？

さて、おかげさまでめでたくサービスも組織も会社も成長してきました、となると次に来る大きな悩みは(いろいろあるのですが)、1人ではすべてを見きれない、それだけならまだいいんですが、技術分野も多岐にわたり始めるので、自分が一番技術的に詳しい、とはもはや言えなくなってきたりする、というものになったりします、往々にして。例えばグリー株式会社でも、ネットワークの話から3Dまで非常に多くの技術分野に携わることになるわけですが、正直ネットワークと3D両方で専門家とかちょっとムリです。

これについては、前述のWikipediaの記事が教科書的には正解かなと思っていて、「CTO」と「(例えば)アーキテクト」は別であっても構わないと思うわけです。ので、カバーしきれない部分はそこについてのデザインをするひとを別にお願いして、適切に権限委譲をするのがきっと正しい形です、が、これについてはぼくもまだまだだなーと思うのと、あくまで教科書的な話なので、ここでは一旦さておかせていただきます。で、それでもCTOが気をつけるべきだ、と自分で思っていることを一つ挙げておきますと「抽象的に考えるといろんなことが簡単に見える症候群」という勝手に命名した問題です。いやこれはほんと気をつけても結構陥りがちだなと。

どういうことかというと、一定以上のエンジニアリングの経験やスキルを持っていると、多くの技術的課題を(実際にやっていなくても)抽象的に理解できるようになりますし、その理解が大筋で正しいことも非常に多いです (すくなくともチューリング完全という意味ではそうだよね、ということではあったりします)。ただ、これが続くと実際に自分がやっていたときのいろんな苦労を忘れていって、必要以上にものごとが簡単に思えたり、自分ならすぐできる、とか思ってしまったりします。これは、エンジニアリングマネージャとしては一応自戒しておこう、とかで十分だったりしますが、技術的な意思決定においてはこれが致命的なミスになることもあるので、自分で手を動かして0からものをつくる、という苦労を忘れずにいるのは結構大事かなと考えています。なのでぼくがコード書いててもお前ほかにも仕事あるだろとかおこらないでくださいおねがいします (別におこられてないけど)。

5年を過ぎてからの一番のむずかしさ -技術的負債-

そしてそして最近一番難しいと思っているのが、技術的負債(Technical Debt)です。一般には、設計や実装がイケてないことにより発生する問題と捉えられることが多いですが、ここではどちらかというと、長期間に渡るソフトウェアのマネージメント、という観点における難しさで考えてみます。

会社やサービスも、5年続くとどうしても、仮に当時は(先を十分に見据えた上で)bestな解であったとしても、今となっては...というコードが出てきます。これは、外的環境が相当なスピードで変化し続ける以上必然かなと考えるしかないと思っていて、これが発生し得ないと思うのは多少楽観的かなと言わざるを得ないかもです。また、この粒度は様々で、大きくサービスの単位でもありますし、API、ミドルウェア、ライブラリ、クラス、インターフェースなどなど粒度が細かくなればなるほど問題が注目されにくく、対応も難しくなってくることが多いです。この問題は結構解決が難しいと思っていて、多分世界で一番大きなインターネットサービスの会社のかたがたに、具体的なミドルウェアの名前 (うぇぶ2.0時代に一世を風靡したあれやこれとか) を上げてどうマネージメントしてるんですか？と聞いても「うん、いい質問だけどそれは本当に難しい、適切にコストを払い続けるしかないね」ということなのだそうです、ウソを言われた可能性もありますが、多分ほんとっぽかったので、ほんとなのでしょう。

具体的にはどういうことかと言えば、例えばですが (あくまで例えばですので!) 画期的なミドルウェアを開発してそれが社内の多くのサービスの礎になった状態から5年経ったときのことを想像してみると:

  • そのミドルウェアは社内で使われまくっていて、仕様変更やアップデートのコストは上がり続けます (便利だし実績もあるから、依存度も上がりますしね)
  • 一方で、5年もあるとそういった技術の多くはコモディティ化して場合によってはより優れたものがOpen Source Softwareとして提供されていたりします
  • いまさら乗り換えるわけにもいかないので、そのミドルウェアに対してメンテナンスコスト、アップデートのコストを払い続ける必要が出てきます

といったことが起こりえます。こういう状況を想定して、技術選択、開発、運用や組織の設計をしていくのはなかなか難しいところです。もちろん、ちゃんとテスト書きましょうとか、適切なアーキテクチャを考えましょうとかは言うまでもないとして(とはいえ、往々にしてえいやで書いたやつが長続きしちゃったりするんですよね...)、メインの開発者が退職しちゃったり、チームが解散しちゃったりなどなど5年という月日では非常に多くの想定外の事象が発生します。さらには、どうしてもエンジニアたるもの新しいものを作り続けたいし、うーん、じゃぁ外部のソリューションに頼ろうか、といっても(コストの問題はさておき)全部それだと会社としての技術的な足腰は弱まっていってしまうよね、などなど悩みの種は尽きない気がします。

これに関しては、銀の弾丸はないと思っていて、長期的なコストを下げるための投資をし続ける、そのためのコストを見越しておく、内部で開発するかどうかの適切なバランスを取り続ける、ということをCTOないしチームでやり続けるしかないようです。

ということで生存戦略

以上長々とCTOについて、という多くのかたに役に立つんだか立たないんだかよくわからないことを趣味全開で書いてみましたが、いずれにしても、どんな立場でも、継続して変化に対応していかなければ未来がないのは、エンジニアに共通する課題であり続けると思っています。ので、ぼくは、ぼくの初めての上司の言葉を今も結構大切にしています:

「自分で自分を『できる』と思ったらそこで試合終了」 (少し改変)

エンジニアとして仕事をしていくなかで、当たり前ですがいろいろな知識、経験、ノウハウを得ていくことになります。そこで「あ、だいたいわかったな」と思って主体的に勉強する手を止めてしまったり(なぜなら、それでも目下の仕事は問題なく進められるから)、なにか(自分にとって)新しいことを勉強しようとしても「あー、これだいたいこういうことね、あれと一緒じゃん」とかで深堀せずに分かった気になってしまう、ということが続くと、多分5年、10年経って「本当に」老害な感じになってしまうんだと思います (鍵括弧ついてるのは、某Advent Calendarで老害な記事があったのでっていう流れで...)。

逆に言えば、30になっても40になっても、50を超えても真摯に勉強と成長を続けていけば、その年齢でしかできないこと、積み重ねた経験を活かしてでしかできないことっていうのができるに違いない、と信じています、ので、若いみなさまに負けないようこれからもがんばっていきたいなと思う今日この頃です。

さいごに

などと書いてみたらすごい長くなりましたが、最後まで読んでくださったみなさまありがとうございます。

さらにさいごに

それではみなさまよいおとしをー!