CTOとして意識してきた「攻め」と「守り」
田中慎司氏：CTOとしてやってきたことは、もともとインフラ周りをずっとやってきたこともあって、インフラ周りのアーキテクチャはきっちりある程度見たりしてました。あとはアプリケーションとインフラ技術設定とかは、特に大きめの選定をするときはCTOとして少し話し聞かせてよって言って、いろいろ聞いたりしていました。
あとエンジニアチームの養成で、採用は勿論ですけど、育成各エンジニアと面談しながら相談にのったりしてやってきました。
細かい話はいろいろあるんですけど、CTOとして意識してきたことは、大きく技術面と人材面の2つがあったなと思います。
技術的にCTOが判断することを攻めと守りの2つに分類すると、攻めのところは技術的競争優位をどうやって確立するかと、自分たちのサービスとか既存のサービスとか新しいサービスとか立ち上げるにむけて、技術的な競争優位をそこに組ませることでサービスとして事業として優位に活かせることができないかっていう攻めの面。
あと守りではコスト管理とかスケーラビリティ可用性の確保とか、セキュリティの担保とかそういう守りの部分もしっかりやっていく必要があるんで、攻めと守りでいろんな判断をするところがあります。
攻めの技術的競争優位の確立っていうのは、はてなは一応エンジニアが強い会社と言っていただいていて、自分たちはテクノロジーカンパニーでありたいと思ってるんですけど。
テクノロジーカンパニーを標榜するのであれば、そういうエンジニアリングの力で技術的競争優位を確立して、それがサービスとか事業の競争優位につながって、それで成長していくっていうのがエンジニアとしては一番美しいストーリーで、是非目指したいところだと思っています。
時機を見極めるのは専門家でも難しい
実態としてはそう簡単ではなくて、先々月くらいにPFIの岡野原さんっていう、機械学習とかのプロフェッショナルが、技術と時機っていうブログを書いていたんですが、そのブログの中で彼は「時機を見極めるのは専門家でも難しい。しかし勝負をしないと舞台に上がることすらできない。」と言っていました。
彼は機械学習のところですごい博士をもっていて、東大総長賞とかもらうような機械学習の分野ではすばらしい実績をあげてきた人なんですけど。
彼がやろうとしたのは、今、スマートニュースさんとかがやってるような、ニュース記事を集めてきてビデオとして出していくっていうサービスを出したんだけど、それは時機が早過ぎて上手くいくことができなかったということを、このブログエントリーの中で言っていて。
それが技術的に確かにすごかったかもしれないけど、タイミングが合わなかったのか、もしくはマーケティングが悪かったのかとか、デザインが良くなかったとか、理由はいろいろあると思うんですけど、技術的にいろいろ業績を残して、表彰されたりした人でも、技術一本だけで競争優位を確立するのはなかなかそう簡単ではないなと思ってます。
ですので、CTOとしては、技術を一手段と捉えて、技術で全てを解決するというのは基本的には、それができるCTOとしては理想的ではあるんですが、もう少し現実的には技術を一手段と捉えるほうが良いだろうと考えています。
スピード感のある開発ができるチームを作ることが重要
純粋な技術的要素でビジネス優位を作るのは極めて困難。それには、僕は全く同意するところなんですけど、純粋に技術的要素でいくのはなかなか難しいので。
その事業上とかサービス上の制約を技術的に突破したり回避したりしつつ、その他のマーケティングとかデザインとか、いろんな会社を構成するいろんなプレイヤーと協力しながら、ビジネス上の優位を築いていくと。
その中で技術的な点でしっかり貢献していくというのが、一番CTOとしての役目じゃないかなと思っています。
ビジネスへの技術的貢献っていうのが大事だなと思ってます。競争優位を確立するために、技術的にはいろんな手段があって、例えば、スピード感のある開発ができるチームをちゃんと作るということ。
ちゃんと素早い開発を続けるとか、まだコモディティ化していない技術を採用して、それで競争優位を築くとか、いくつかの手段があるかなと思います。
コモディティ化していない技術っていうのは、例えばiPhoneが出たころのiOSの開発とか、もう少しさかのぼると2000年半ばくらいは、スピード感のある技術もまだコモディティ化していなかったと思うので、それは充分競争優位だったかなと思います。
ただ、技術というのは基本的にはコモディティ化していく宿命があると思いますので、コモディティ化していない技術を採用してから、時間的には2、3年の猶予があると思います。
いずれ競争になるので、どんどん新しい技術を投入したり、新しい開発プロセスを導入したりして、より先端的な取り組みを続けることで、ビジネスを成立させるために、きちんと技術の貢献を続けていくってことが大事なんじゃないかなと思います。
はてなのサービスはperlで開発している
一方守りであるコスト管理で一番問題になるのは、長い期間サービスを運営していくうえでの、いわゆる技術的負債というものです。これはマーティン・フラワーさんの技術的負債の記事の引用しているんですけど、それは返済可能なレベルにする必要があるかなと思ってます。
技術的負債を返済可能なレベルにコントロールするには、そのためにいくつかの技術的な判断が必要になると思ってます。それはいろんなレイヤーで何を選択するかっていう積み重ねだと思うんですけど。
例えばWAFの選定であるとか、開発言語の選定であるとか、どういうミドルウェアを使うかっていう選定、実行環境をどうするかとか、サービスのアーキテクチャをどう設計するかとか。
ここでそれぞれのレイヤーボタンが積み重なっていって、それで技術的にスマートなら負債はたまらないし、間違った選択をしてしまうと、技術的負債が溜まっていって将来的にちょっと困ったことになるというのが現実なんじゃないかなと思ってます。
はてなの場合ですけど、開発言語選定のところでは創業当時からずっとPerlでやってきて、もう十数年Perlで、今もずっとはてなのサービスはPerlで開発してるんですけど、Rubyとかも周辺ツールでは使ってるんですけど、基本的にはてなの本体のサービスは全てPerlで書くってのを基本にしてます。
ただ、Perlの言語の勢いとか周辺ツールの勢いとか、相対的にあまりメジャーではなくなりつつあるので去年の夏にScalaとGoを採用して、もう少しモダンな言語を使って開発用に、ちょっとずつ選定しています。
ScalaとGoを採用したんですけど、実際使ってみると良い点・悪い点ありました。良い所は型つけ言語による堅牢な開発ができるってことと、あと新しい言語を学べるのでエンジニアとしてはモチベーションが上がる点。
あとは採用上Scalaを書きたいのではてなに来たっていう人も、もともとPerlだけでは目を向けてくれなかった人がScalaをやってるんだってことで興味を持ってくれたりとか、そういう採用上の効果はあったかなと思ってます。
良くなかった点としては、新しい言語を習得する、勉強するコストが必要になるので、もちろん、好きな人はどんどん自主的に勉強してやってくれるんですけど、誰もがScalaっていう特定の言語を好きになってくれるとは限らないので。
これまではてなではPerlが使えて、どんなサービスも、その人が移動すればすぐさわれるっていうのが基本だったんですけど。
今、Perlが使える人とScalaとGoが使える人というのがだんだんわかれてきていて、Perlは書けるんですけど、新しいScalaとGoを書ける人は相対的には少ないので、結構ここは、将来的には複数の言語で開発をするってのは、将来的に多少のコストであるかなと思ってます。
結構会社のポリシーによって、開発言語は自由に使っていいってところもあれば、絞り込んでいるところもいろいろあると思うんですけど。
あまり広げすぎると、技術的負債という観点で、サービスを長く運営する必要があるような会社では、いろんな言語をどんどん使っていくと、なかなか技術的負債のコントロールってのが難しくなるんじゃないかなと思ってます。
2つ、3つくらいでおさえておくのが重要なんじゃないかなと思ってまして、はてなとしては当面はPerlとScalaの2本立てで、たまにGoを使うという案配でいこうかなと思ってます。
技術選定はボトムアップで
こうした新しい技術の採用ですけど、基本的にはボトムアップがいいなと思ってます。今回Scalaを採用するのも、そろそろ新しい言語を採用したいっていうのは僕が始動したところがあるんですけど、最終的な技術の選定とかはもう少しいろんな人を巻き込んでボトムアップで決めるようにしています。
トップダウンで技術を決めることは、ある程度は重要なんですが、あまりディテールまで決めてしまうと現場のエンジニアがついてこないことが多いと思います。
そこはちゃんとボトムアップで現場を巻き込みながら選定したり、採用していくのが大事だと思います。
ただ完全に現場に任せてしまうと、あまり後先考えずに興味ある言語に飛びついてしまうことがあるんで。継続的にメンテすることは念頭に置いてます。ちゃんと相談しながらする必要があると思います。
技術的負債にならないようにっていうのは念頭においてですね、若手をスポイルしないように、そこは上手く導いてあげる必要があるかなと思っています。
実行環境選定のところで、似たような話があって、先ほど言ったようにSSDをインテルX25-Mリリース前に導入したりとか、あとはクラウドの導入はTokyoリージョン開設前にやれました。
ここはいずれも時代の潮流に乗れたので、わりと早いタイミングで手をつけることができたので、悪くない判断だったんじゃないかなと思ってます。
アーキテクチャ選定のところは、最近マイクロサービスっていうのが話題になってきて、これも同じくマーティン・フラワーさんのブログを引用してるんですけど。
1つのサービスを構成するときに、1つのアプリケーションだけでやるのではなくてもう少し細かいコンポーネントに分けて、それぞれが全体としては1つのサービスとして動作するようにしようという思想、アーキテクチャの設計方針なんですけど。
そういうマイクロサービスによるアーキテクチャを出すか、もしくは大きなベーシックなアーキテクチャでいくかっていうのがあって、これはもちろんトレードオフだと思いますが。
サービスが小さいと当然ベーシックでいくべきだし、サービスが大きくなってきた段階でマイクロサービスにするべき。実際、いつどのタイミングでマイクロサービス化するかとか、どのコンポーネントからマイクロサービスとして切り出していくかとかを考える必要があると思います。
あと、開発中に並行して振るいにかけながら、新しいマイクロサービス化をやるのかとか、アーキテクチャを移行するタイミングとか、ディテールとかそれぞれの判断に迷うところで、ここは本当ケースバイケースになるので上手く判断する必要があるなと思ってます。
最悪なことは中途半端に手をつけることで、ここを中途半端に手をつけて終わらせると、本当にカオスのようなアーキテクチャになっていくので、そこはCTOとしてはコントロールする必要があると思ってます。
