アプリ、インフラ、サービス設計…はてな成長期におけるCTOの役割の変化

CTOに求められるもの

田中慎司氏（以下、田中）：おはようございます。株式会社はてなの田中と申します。1ヵ月か2ヵ月前ぐらいにこのお話をいただいて、非常に恐縮なんですけど、光栄なので引き受けさせていただきました。

「CTOに求められるもの」というお題をいただいたのですが、僕は2010年にCTOになってから日々CTOとしてどうするべきかとか、何がCTOに求められるかとか、どういう役割を果たすべきかとか、時々悩むこともあったので、自分の経験を踏まえたお話をさせていただきます。

自己紹介ですけども、株式会社はてなで執行役員CTOをしております。2006年にはてなが渋谷区の鉢山にオフィスを置いていた頃からはてなに入りまして、はてなの京都移転に伴い京都へ行き、最近東京オフィス勤務になりました。

最近はあまりパブリックな場所に出てなかったのですが、久しぶりに東京に戻ってきましたので、お誘いいただければいろんな場所に顔を出していきたいと思ってます。

あと自己紹介として書いた本。『サーバーインフラを支える技術』とか『大規模サービス技術入門』とか、前CTOの伊藤直也さんと一緒に書いたりしていました。ここ数年くらい、ずっと、いわゆるサーバーインフラまわりをやっていたので、サーバーインフラの人として認識されてるんじゃないかなと思います。

CTOでもエンジニアなので、技術話もしておこうということで、好きな技術を並べてみました。

言語は去年くらいからGo言語にはまっていて、Goカンファレンス、略してGoコンって言うんですけど、そういうので発表したりとか。エディタはEmacsです。これは20世紀から使っているので。AWSは好きなサービスはS3ですね。

やっぱり自分でプログラミングしてるとつくづく思うのがストレージの扱いが難しい所で、S3にいつも頼ってしまうという昨今です。あと実行環境はDockerとか最近流行ですけどこれも注目していて、データストアはMySQLがすごい好みです。

1枚だけPRを入れさせてもらったんですけど、最近サーバー管理ツールのMackerelっていうのをやっていますので、もしご興味がありましたら試していただけるとうれしく思います。詳しくは検索していただけるといろいろ出てくると思います。

シリコンバレーのCTOの役割とは

本題に入っていきたいと思います。「CTOに求められるもの」というテーマですが、まず、「CTOに求められるもの」を考えるためにはCTOとは何かということを考えたいと思います。

CTOとは「Chief Technology Officer」ですが、ひとつCTOに似たポジションとしてVP Engineeringってポジションがあります。もともとCTOはアメリカの企業にあったポジションで、それが日本に輸入されて特にネット系の企業でCTOと名乗ってる、またはポジションが用意されているものだと思います。

アメリカの企業でCTOと並んでエンジニアリングに関するシニア系のポジションがVP Engineeringで、アメリカのブログなどを読んでみてもCTOとVP Engineeringの違いとか、それぞれどういう役割があるとか、いろいろ書いてあるのを見つけることができます。たまに日本のブログにもあったりしますね。

CTOの役割はいくつかあると思ってまして、技術に明るくてコードをバリバリ書く人という認識をされている方もいれば、その会社で作っているシステムのアーキテクトをする人という解釈もある。

エンジニアが増えてくるとそのエンジニアをまとめてマネジメントする人、つまり、その人自身はあまりコードを書かないという場合もある。そのようにいろんな役割があるかなと思います。

海外のエンジニアのブログとかを読んでいると、一番下のマネジメントする人がCTOとかVP Engineeringではないかとか、そういう話があったりします。

このような定義でCTOをとらえている人もいるんじゃないかなと思います。ほかの記事を見るとCTOはシステムアーキテクトで、VP Engineeringがマネジメントをする人という解釈も一般的なようです。

日本ではいろんなCTOの方がいらっしゃって、それぞれの方の役割は会社の規模とかに依存しますし、どれだけ技術的な要素がそのビジネスや事業に重要かとか、そういうのにも依存してくるので、基本的に「CTOとは何か」についてしっかりとした定義をするのは難しいなと思ってます。

しっかり定義するのが難しい上で議論を組み立てていくのもなかなか難しいので、抽象的なことより自分の経験からお話して、その上で、どういうのが求められるかについて私見にはなってしまいますが、少なくとも僕はこういうふうに思っていますというのが言えるといいなと思っています。

ということで、これまでの僕のあらすじということで、少し経歴を振り返られていただければなと思います。

NTT研究所からはてなに

僕の場合は、最初は学生で大学院までいきました。大学院を出た後、NTTの研究所で、6年くらい在籍していました。その後2006年4月にはてなに入社しました。2010年にCTOを拝命しまして今ここという感じですね。

この会場には大企業にいらっしゃった経験のある方も、最初からスタートアップでキャリアを積んでこられた方もいろいろいらっしゃると思いますけど、NTT研究所では、ちゃんと研究に向き合えたし、そこで技術のベースとかしっかりしたものを作ることができたので良かったです。

CTOとしては、2006年にはてなに入ってからが本番で、そこでサービスのスピード感とか技術的な所を磨いて、2010年にCTO交代があったタイミングで就任して、4年ちょっとくらい、CTOとして働いている形になります。

はてなに入ってからどんな感じでやってきたかというと、2006～2010年くらいは最初はエンジニアとして入ってマネージャーになって、その後CTOになりました。

2006年当時ははてなはまだ、僕が19番目の社員だったこともあり、アプリケーションエンジニアとかインフラエンジニアとか、そういう区分けもあまりなくて、最初はアプリケーションコードを書いたりしていました。

1年くらいアプリケーションのコードを書いていたんですけど、2006年の終わりくらいにインフラ系のチームをちゃんと作ってやろうということになって、そこでインフラを頼むと言われてインフラエンジニアになりました。

その後インフラチームをまとめるマネージャーになっていくんですけど、その時やったことは、運用効率化でpuppetを導入したりとか、これは2007年くらいに導入したの当時はまだあまり技術がなかったので最初はおもしろいなということで導入したりしてました。

サーバーに負荷がかかりすぎてブレーカーが4回落ちた

あとは懐かしい感じがするんですけど、2007年くらいに仮想化の技術を導入したりしてきました。

あとはSSDも結構早い時期に導入して、確か2008年の末ぐらいだったと思うんですけど、インテルのX25-Mっていう、定番SSDが本格的に普及した時の最初の定番SSDだったんですけど、それが出てくる前から本番サーバーに突っ込んで。

プチフリーズとか、当時を覚えてらっしゃる方は、そんなのを覚えているかと思うんですけど、プチフリーズを経験したりとか、結構アグレッシブにいろんな技術を導入したりしてきました。

あとは技術的な所じゃなくて、はてなの動きとしてはシリコンバレーにHatena Inc.という子会社をつくりました。ここに1年ちょっとくらい在籍したり、本社が京都移転したので、移転のタイミングから少しして京都に行ったりとかしてました。

この時期何があったかなっていうのを、事件簿的に出してみたんですけど、よく覚えてるのは2007、2008年にブレーカー断（だん）ってのを何回かやってます。ラックにサーバーを積んでるんですけど、サーバーの負荷があがってくると消費電力が増えていって容量が超えるとブレーカーが落ちるというのを、この前記録を数えてみたら4回ほどやってました。

ブレーカーが落ちるとそのコンセントに繋がってるサーバーが全部落ちるので、データセンターの人が青ざめて電話をかけてくるんですけど、だんだん馴れてきてちゃんと常駐化するようになって、ブレーカーを落としてもサービスに影響がないようにっていう進化を遂げていったんですけど。

データセンターの人は普通はブレーカーが落ちないような運営をするのが当たり前なんで、ブレーカーが落ちるっていうのは完全な異常事態なんですけど、はてなとしてはブレーカーが落ちてもそんなにサービスには影響がなかったので、そんなに気にはしていなかったんですけど。

データセンターの人に負荷をかけるのも問題だなと思って少し落ち着いて運用をしたりしました。

「災い転じて福となす」という考え方で運用をしていた

1つ覚えているのは、2008年4月にSibversionリポジトリ破損するっていう事件があって、これはRAIDを組んでいたので大丈夫だと思っていたんですけど、RAID0だったっていうオチがあって、リポジトリが復旧できなくなって。

慌ててサーバーからソースコードを引っ張ってきたり、みんなの手元からソースコード引っ張ってきたりして復旧したんですけど、これは当時はてなスタッフだったそこに座ってる現クックパットの舘野さんが対応してくれたので、ケガの巧妙でわりと早くgit化できたんじゃないかと思ってます。

「災い転じて福となす」という考え方でおおらかな運用をしていたのが当時のはてなだったと思います。

2010年に前CTOの伊藤直也さんがはてなを退職されるということがあって、その引き継ぎでCTOを拝命することになりました。伊藤さんがCTOだった頃は僕がインフラを見て彼がアプリケーション周りを見るって役割分担でした。

最後の1、2年くらいはずっとやってたんですけど、そこでCTOということになったので、インフラから見て更にサービスの設計とか、サービス開発のプロセスとかをちゃんと見るようになりました。

そこでやったことはGitHub Enterpriseを導入したりとか、最近、Scala、Goという新しい言語を導入したりとか、東京オフィスにエンジニア採用を再開したりとか、最近リモートワークを導入したりなどです。いくつかこの辺のサービス開発プロジェクトで新しい取り組みをしています。

結婚式の二次会中にメンテナンスを実施

ここでCTO以後の事件簿です。さすがに新たな運用はなくなってちゃんとキッチリとした運用に移りつつあるんですけど、新しいのが出るたびにSSDをどんどん投機していた時があって、SSDのファームのバグを踏んでこの時確か10枚くらい新しくSSDを買ってデータベースに投入していたんですけど。

起動時間が確か3000時間くらいを超えると突然SSDが止まるっていうバグがあって、まだ発売してた当時飛びついて買ったので世界的にもそういうバグを踏んだ事例がなくて。

一応はてなが踏む1週間くらい前に英語の掲示板のちょっとした所にそういう情報が流れていたんですけど、まったく気づかずにファームバグを派手に踏んで、マスターデータベースが連続的にダウンしていくという、これもだいぶ肝を冷やす事件がありました。

SSDとかマルチベンダで組むようになってバグを踏んでも大丈夫なような設計をしたりしています。あとはセキュリティとかプライバシー系で炎上したことが多くて、はてなブックマークボタンで少しプライバシー上で炎上したり、プライバシー上の問題で炎上したりとか。

あとこれは最近なんですが、ドメインのWHOIS情報が改ざんされて完全にはてなの管理外の所のレジストリ、レジストラの所が改ざんされて、はてなの一部の配信してるディレクトリが書き換えられるということがあったんですけど、そういうセキュリティ系の事件とかはありました。

SSDのファームのバグを踏んだ時は、ちょうど会社のセミナーとかで使うスペースを使って、スタッフの結婚式の二次会をやっていて、二次会中に黙々とインフラエンジニアがメンテナンスを実施するという、インフラエンジニアにとっては武勇伝になるような感じだったので、それはそれでアドレナリンが出る感じで。あとで振り返って見ればおもしろかったかなと思います。

そういう感じで4年くらいCTOとしてやってきたんですけど、ここでどんな感じで僕が意識をしてきたかっていうのをお話できればと思います。