【第3回】CTOはWeb技術のトレンドに何を見てきたか

・伊藤 直也さん / 株式会社 一休　執行役員 CTO

新卒入社したニフティ株式会社でブログサービス「ココログ」を立ち上げ、CTOを務めた株式会社はてなでは「はてなブックマーク」などの開発を主導。グリー株式会社では統括部長としてSNSを担当した。2016年4月、一休に入社し執行役員CTOに就任。

 

・大坪 弘尚さん / 株式会社はてな CTO

2008年、東京大学大学院情報理工学系研究科を中退後、アプリケーションエンジニアとして新卒入社。うごメモはてな、Mackerelを始め、はてなの新サービス開発に数多く携わる。2012年より技術グループ チーフエンジニア、2016年に最高技術責任者に就任。 現在は、はてなの事業を支える基盤を開発・運用するチームをマネジメントしつつ、CTOとして技術組織全般の統括にも取り組んでいる

Twitter: @motemen

 

 

「渋谷系」カンファレンスでの出会い

 

 

伊藤さん：motemenさんは2016年から株式会社はてなの3代目CTOをされているわけですが、最初にはてなに来たのは、私が東京オフィスでCTOをやっていたときだったんですよね。

最初はアルバイトとしてはてなに来てくれたんでしたっけ？

 

motemenさん：そうです。当時、はてなでnaoyaさんのチームにいたセコンさんこと館野さんに誘われて。

 

伊藤さん：実をいうと自分は、その前にShibuya.jsという技術イベントの第一回でmotemenさんが発表されたLTを聞いていて、そこでmotemenさんのことを知っていたんですよ。

 

motemenさん：懐かしいですね、Shibuya.js。

あの当時は、いろいろな言語のイベント名に地名を冠するのが流行っていたんですよね。もともとはPerlの文化だったのかな。

 

伊藤さん：PerlのコミュニティにはPerl Mongersと呼ばれるユーザーグループが世界中のあちこちにあって、その名前がだいたい地名.pmなんです。London.pmとか NY.pmとか。

それの東京版をやろうとなって、20年前に宮川達彦さんたちが始めたのが、Shibuya.pmです。

そのJavaScript版みたいな位置づけでShibuya.jsが立ち上がったのだと思います。

 

motemenさん：まとめて「渋谷系」とか言われてましたよね。

 

伊藤さん：そうそう。

それで、そのShibuya.jsの第1回に行ったらmotemenさんがLTで登壇していて、そこで「JavaScriptで高階関数を使ったり関数を合成したりしよう」みたいな話をされていたんです。

そういう書き方をサポートしてくれるMochiKitというライブラリの話とか。

 

motemenさん：はい。

JavaScriptを関数型プログラミングっぽく書けたらおもしろい、という発表をした記憶があります。

 

伊藤さん：それですね。

なにせ2006年のことだから、まだまだ自分を含め普通のWebプログラマーにとっては「関数型ってなんですか、それ？」みたいな時代だったから、motemenさんのLTを聞いて、「世の中にはこんなことを考えている人たちがいるんだ」と思っていました。

 

motemenさん：ちょうど関数型プログラミングが微妙に流行り始めた時期ではあったんですよね。

 

伊藤さん：そういう背景があったので、自分のmotemenさんに対する第一印象は「理論寄りの人」だったんです。

プログラミング言語そのものや計算論なんかに興味関心がある方なのかな、みたいに思ってました。

でも、はてなに入ってきたmotemenさんはぜんぜんそういう感じではなくとてもプラグマティックで、それが意外だったんですよね。

 

motemenさん：なるほど、そういう第一印象があったんですね。

 

 

 唯一の選択肢がプログラミングだった

 

 

伊藤さん：実際、あの当時に「JavaScriptを関数型っぽく書こう」というLTで技術カンファレンスに登壇するくらいだから、学生のときは理論寄りだったんですよね。

 

motemenさん：そうです。

学生のときは一人でしかプログラムを書いていなかったので、実用的なものを作るというよりは、プログラミング自体に興味がありました。

大学で数学をやり出したこともあって、プログラミングについても理論的な背景を探ると面白いと考えて勉強していた感じです。

 

伊藤さん：ということは、プログラミング自体は大学に入る前からやっていたということですか？

 

motemenさん：はい、初めてのプログラミングは小学生のときです。

親がパソコンを持っていて、プログラムを書いていたわけではないみたいなんですが、知り合いにプログラムを書ける人がいたらしく、知識としては知っていたようです。

それでぼくに「こんなの好きなんじゃない？」と言ってBASICの本を渡してくれました。

 

伊藤さん：以前、和田卓人さんが「物心つく時期にプログラミングに出会えた人がうらやましい、むしろ、ずるいとさえ思う」とおっしゃっていたのを思い出しました。

motemenさんもそういう環境出身だったわけですね。

 

motemenさん：そうですね。

ただ、私の感覚だと、むしろ「大学に入ってからプログラミングを始めてそれを仕事にしている人たちがすごい」と思うんですよ。

自分がプログラマーになった背景には「それしか選べなかった」という感覚があるので…。

 

伊藤さん：なるほど。

とはいえ、私もそうですが、プログラマーになることが数少ない選択肢だったという人もけっこういるとは思いますが…。

 

motemenさん：分別がつく年齢になって、いろいろな選択肢の中から自分でプログラミングを選ぶというのは、自分にはなかった体験なので、その体験を経て仕事としてプログラミングをされている方を見ると、やっぱり「自分の道をきちんと選んでいてすごい」と思うんですよね。

 

伊藤さん：じゃあ、その幼少のころからずっとプログラミングを続けている感じでしょうか？

 

motemenさん：一時期やっていなかったときもありますが、中学校に入ると自分の家にWindowsパソコンがやってきたので、そこでVisual Basicに出会ってプログラミングしていました。

友だちの顔写真を使って格闘ゲームを作ってみたり、生徒会室にあったパソコンに自分が作った面白いプログラムを入れて遊んでみんなで笑ってみたり。

 

伊藤さん：そういう、「ちょっと面白いもの」を作ろうとするところは昔から変わってないんですね。

はてなで一緒に仕事をしていたときも、motemenさんはちょっとでも時間ができると何かプログラムを書いていて、それがいつも普通の人が普通に作るようなものじゃなかったんですよね。

必ず何かしら面白い機能であったり、ちょっとした便利な機能を入れていた。センスが良いと言いますか。

 

motemenさん：そうですね。

どうしても「誰かに見せて褒めてもらいたい」という気持ちが働くんだと思います。

 

 

プログラミングで褒めてもらいたい

 

 

伊藤さん：そういう遊び心があるプログラムを作るところが、motemenさんに対する第一印象とはまた違っていたところなんですよね。

 

motemenさん：実際のところ、あの当時私が関数型プログラミングを始めたのも、「イケてそうだから」という側面からだったんですよ。

 

伊藤さん：つまり、「すごい」って言われたい、みたいなことですか？

 

motemenさん：そんな感じです。

当時は学生で時間があったという面もありますが、プログラミングしかできることがなかったので、その道でかっこよくなりたくてSICP（“Structure and Interpretation of Computer Programs”）っていう紫色の表紙の本で関数型プログラミング言語のSchemeを始めたんです。

 

伊藤さん：そこで SICP ですね。

翻訳は『計算機プログラムの構造と解釈』というタイトルで出ている、当時の MITの教科書ですね。

プログラミング言語はこういう具合に動くんだよとか、こうやって作るんだよとか。

 

motemenさん：はい。SchemeでSchemeインタープリンタを作る、みたいな本です。

 

伊藤さん：この頃はまだ、プログラミング言語の作り方を解説したわかりやすい本が今ほど多くなかったので、あの紫色の本がバイブルみたいな扱いでしたよね。

初学者には少しハードルが高い雰囲気もあって、「SICPを読んでる」が一種のステータスみたいな印象もありました。

 

motemenさん：自分がSICPを読み始めたのも、そういう「イケてる」印象からだったんですよ。

 

伊藤さん：Schemeだけでなく、あの当時Haskellも書いていたような記憶があります。

 

motemenさん：書いてました。

オードリー・タンさんがHaskellでPerl 6を実装したという話を聞いて、それで自分もHaskellでJavaScriptの実装を書いてみたり。

あの当時、「台湾の学生がHaskellでPerl 6を実装した」という話は相当な衝撃だったんですよね。

 

伊藤さん：オードリーさんは、いまでこそ台湾のデジタル担当大臣として知られているけれど、あの当時はPerlのCPANライブラリをたくさん書いているハッカーで、自分たちにとってはPerlコミュニティの人だったんですよね。

宮川さんがShibuya.pmに呼んで、日本にも来たりもしていました。

当時Perl 5をアップデートして6にしようという動きがあって仕様がずっと議論されてたんだけど、実際に動くものがまだ存在してなくて、「これ、誰が作るんだろう？」って言ってたら、2006年にオードリーさんが「HaskellでPerl6のコンパイラを書いたよ」って発表して、それはそれは大きな話題になりました。

 

そもそも、自分なんてHaskellっていう言語すらよく知らなかったですからね。

当時、ちょっとHaskellをやってみたけれど、今みたいにHaskellの解説書もあまりなかったから、難しい！という印象だけが残りました。

「世の中にはこんな難しい言語でPerl 6を作っちゃう天才ハッカーがいるんだなあ」って思ってたら、隣でmotemenさんが「HaskellでJavaScriptの処理系を書いてる」って言うから、「すごいなあ」と思っていました。

 

motemenさん：確か、それでHaskellを覚えたんですよね。

 

伊藤さん：オフィスで昼休みに圏論の教科書を読んでいたのも覚えています。

そんな感じだったから、最初motemenさんに抱いていた印象はまさに「理論派」という感じだったんですが、実際に一緒に仕事をするようになったらそんな雰囲気じゃないんですよね。

実際、現在のmotemenさんがいちばんよく使っている言語はGoだと思うんですが、それこそSchemeやHaskellのような言語とは世界観が真逆というか、Goは実践に振った言語ですよね。

どこで今みたいなmotemenさんの立ち位置になったのか、興味深いですね。

 

motemenさん：それもやっぱり、「人に褒めてもらいたい」っていう動機からな気がします。

理論を追及して認められる道よりも、自分が作った面白いものや便利なものを誰かに見せて、それを喜んでもらったり褒めてもらったりする感覚が欲しかったのかな、と。

大学ではSchemeだけでなくJavaScriptも書き始めて、それがメインの言語になっていったんですが、JavaScriptなら自分のブログに書いたのを読者に評価してもらったり、ブラウザを使っていろいろ遊んでもらえますよね。

そうやって面白がってもらえるものを作りたいっていうのが、自分のベースにあるのだと思います。

 

 

はてなとPerl

 

伊藤さん：そんなmotemenさんも、はてなに入っていちばん書くようになった言語はPerlなわけですよね。

当時、はてなのメインの言語はPerlだったので。

 

motemenさん：現在でも、はてなの主力プロダクトにはPerlで書かれているものも多いです。

なので、Perlで新しいコードを書き足していく機会は、まだあります。
とはいえ、全体的には「Perlは減らして行こう」という話はしているので、新しいものを作るときにPerlが選択肢に入ることはないはずです。

 

伊藤さん：やっぱり、今からPerlで新しいシステムを作るのはいろいろ難しいところでしょうか？

 

motemenさん：そうですね。

Perlがどうこうというよりは、型がない言語についての社内の認識が「新しく作るのは高速にできるかもしれないが、これから先ずっとメンテナンスして行くことを考えると難しい」になっている感じです。

たとえば、「はてなブログ」は2012年に大規模Perlで実装されて、チームメンバーの入れ替わりを繰り返しながら長らく続けているのでメンテナンスする能力は社内にあるものの、やはり大変っていう認識があります。

それで社内のモチベーションが「型がある言語に寄せて行こう」になっているんですよね。

 

伊藤さん：なるほど。

昨今のアプリケーション規模を前提にすると、型の支援を受けられることが重要であるという議論ですね。

初めは気軽に作ったものでも、長く運用していくうちに自分たちの想像を超えた規模になるというのは、この10年、20年でWeb開発者たちが学んだことの一つです。

 

motemenさん：はい。

型があると、コードの意図を読みやすいのはもちろんですが、「変更時に他の部分に影響を与えない」という確信を持ちやすいのが大きいと考えています。
たとえば、後から変数名を変えたいことってよくありますよね。

ドメインモデルにどういう名前を付けるかは重要なので。

でも、Perlのコードでここまで大規模になると、変数名を気軽に変えるのも難しいわけです…。

 

伊藤さん：Perlで開発していて、変数名を全部置き換えたいとなったら、EmacsやVimでgrepして直す、という作業になりますからね…。

でもこの話は、もしかすると、現代的なIDEを前提とした開発環境が当たり前になった人にはピンとこないかもしれないですね。

実は一休は以前は .NET がメインだったので、Visual Studio を愛用しているエンジニアが少なくないんだけど、そういうバックグラウンドだとIDE側に「リファクタリング機能」みたいなのが備わっているので、変数名の変換とかは難しくない作業ですから。

 

motemenさん：ところが静的型のない言語で書くときは、最初に名前を付ける時点で、「いま決めた名前は後から変えられない」くらいの意識でやらないといけないんですよね。

だから、「後から適切な概念が出てきた時点で名前を変えられる」ことを、型がある言語の利便性だと感じるエンジニアも多いと思うんですよ。

 

伊藤さん：私自身は、PerlでWebアプリケーションを書く以前にはJavaを書いていたので、EclipseみたいなIDEの便利さ自体を知らなかったわけでもないんです。

でも、はてなでPerlのWebアプリケーションを書いていた当時は「Perlは型を気にせずに素早く作れるのがいい」と考えていたし、あの頃は、少なくともBtoCのWeb開発ではLightweight Languageが全盛だったように思います。

周囲のSNSのサービスを見ても、その多くがPerlやPHPやRubyで書かれていた。

それが少しずつ「やっぱり型があったほうがいい」という話が出てくるようになって、昨今は「型がないと開発しづらい」という話が出てくるようになってきたと思っています。

型推論やIDEの発展もあってのことですが、長期スパンでこういう変化が起きることは当時あまり想像できなかったですね。

 

motemenさん：実際、あの当時はPerlの強みがいろいろありましたからね。

とくに大きかったのは、書き換えたコードの内容がそのまますぐに反映されることで、あれで開発速度を上げていた面があったと思います。

 

伊藤さん：Perlでシステムを作っていた人間にとっては、画面をリロードすると書いたそばから動いているか確認できる気軽さがあって、それが試行錯誤が必要なBtoCのシステムを作るのにすごくマッチしていると思っていたんですよね、当時は。

比較的気軽に「とりあえずここのデータ構造をちょっと変更してみよう、雑でもあとで清書すればいい」みたいなことができていた。

 

motemenさん：そうですね。

その後ScalaとかGoでサーバーを書く機会が多くなりましたが、最初に困ったのは、「前みたいにサーバーに入ってコードを書き換えられない！」ことですから。

 

伊藤さん：そのギャップは面白いですね。

 

私は今でもTypeScriptを書くとき、型があってなくてまだコンパイルが通っていなくても、JavaScriptとしてはそれでも動くから先に実行して動作を確認してみてから型を整える、みたいなことをよくやっています。

動的言語としてのJavaScriptの側面を利用すると言いますか。この感覚は、当時のPerlでの開発に近いかもしれません。

型がちゃんとしてないのは承知で、まずは動かしてみて、動きを見ながらパッチを当てていく、みたいな。

それができるのがLightweight Languageの良いところの一つですね。

でも、長い年月が経つと少しずつ不自由になっていくのも事実で…。

 

motemenさん：つらくなるんですよね。

リファクタリングしたいけど、それがすごく難しい。

実行してみるまでわからない部分っていうのがあるので、信頼性や安全性を保障するのもつらい。

 

それなら、新しくサービスや機能を作るときには型がある言語のほうがいいな、となっているのが現在の状況です。

 

 

エコシステムの変化とOSS

 

伊藤さん：はてなでPerlの採用を徐々に減らしている背景として、Perlのエコシステムの縮小といった影響もあるんでしょうか？

 

motemenさん：主な理由は社内のモチベーションの変化ですが、Perlの勢力が縮小したことによる影響もゼロではないと思います。

たとえば、クラウドサービスのSDKにPerlっていう選択肢はまずないですよね。

そうすると、クラウドに簡単に載せられる別の言語のほうがいい、みたいな話にはなります。でないと普通にサービスとして作れない。

 

あと、それこそPerlが全盛を極めていた時代は世界中のいろんな人が書いたモジュールがCPANっていうアーカイブにたくさんあったわけですが、その勢いが弱まりましたよね。

当時、何かやりたいことがあったらCPANを検索して、そこで見つかったモジュールに乗っかっていける感じでしたが、最近ではCPANでモジュールが見つからないことも増えてきました。

 

伊藤さん：確かに当時は、CPANを探せば基本的なものは大体ありました。

ストレージのドライバ、テンプレートエンジン、HTTPセッション管理、ルーティングのリゾルバなどWebアプリケーションを作るのに必要なインフラストラクチャは、ほぼ自分で作らずに済んでいましたね。

Ruby on RailsやNode.jsなどの新しいフレームワークや処理系が盛り上がり始めて、JavaやPythonなどのPerlと同世代の言語も現代的にアップグレードされていく中で、不思議なことにPerlではエコシステムのシュリンクが起こってしまった。

 

motemenさん：世界的にもプロダクションで使われるケースが少なくなったんですかね。

Perlを使っていた企業としては、ホテル予約最大手のBooking.comがよく話題になりましたが、今はどうなんでしょう。

 

伊藤さん：Booking.com は我々と同じ業界ですが、今もPerlなんでしょうか。実際のところはわかりませんね。私の視点ではRailsの登場は、大きかったなと思っています。

あれ以降Webアプリケーション開発の主体はフレームワークを使うのが当たり前になりましたが、そういうフレームワークとしてPerlには決定的な定番が登場しなかったですね。

もちろん、まったく登場しなかったわけではなくCatalystやMojoliciousなんかはあったけれど、それまでPerlを使っていたところは自分たちでフレームワークを作ることも多かったですし。

ほかの言語の場合、この言語を使うならこのフレームワークが定番というのが比較的はっきりしていました。

フレームワークを前提に言語を選択する場合は、Perlが視野に入らなかったでしょうね。

 

motemenさん：Perlで代名詞的なフレームワークが出なかったのは、本当にそうですね。

はてなも、当時伊藤さんが開発したRailsインスパイアの自作フレームワークですからね。

 

伊藤さん：それに関しては、今となっては「すいませんでした」としか言えない…。

自分たちで気軽にフレームワークを作っても、その後のメンテナンスを続けるモチベーションが維持できなくなってしまいますね、もう二度とフレームワークは作らないと思います！

 

motemenさん：社内の一部では今でも動いていますよ。

 

伊藤さん：あのフレームワークのことは別にしても、はてな社内には今も大規模Perlのシステムがあるわけで、そうするとメンテナンスで何かしらPerlの機能が必要になることもありますよね。

今ではCPANにモジュールがない場合も多いと思うんですが、そういうときはどうしてるんですか？

 

motemenさん：そういう場合は、自分たちで不足している部分を埋めています。

最近だと、GraphQLのバックエンドを書きたいというケースがあり、公開されていたライブラリはあったんですが、ちゃんと動くようにする必要があったので、フォークして自分たちで直しました。

 

伊藤さん：そういう成果はコミュニティにも還元するんですか？

 

motemenさん：そうすることもあります。

graphql-perlのコントリビュータには、はてな社員が何人もいるんですよ。

これは少し前の事例ですが、APISchemaっていう、DSLでスキーマを書いてAPIサーバーのスタブを作ってくれる仕組みをid:hitode909 が作ったものがあり、これはCPANに公開しました。

このように、自分たちでオープンソースとして公開することもあります。

特に、受託の仕事で必要になる機能があって、コミュニティに還元するとよさそうなものがある場合には、その受託プロジェクトの中で開発してしまうと還元できなくなるので、まずOSSのプロジェクトとして作っておいてから受託のプロジェクト側で使う、みたいな場合もあります。

 

伊藤さん：話を聞いていると、はてな社の中では「型がある言語のほうがいい」という社内の開発モチベーションの変化や、Perlのエコシステムの相対的な縮小など、そういう事情はあるけれど、それもだいぶ時間が経ってすでに議論が二周くらいしている印象ですね。

その結果として、現在でもPerlをとても丁寧に使っている印象を受けます。

 

motemenさん：やっぱり、自分を含めてPerlが好きだったりPerlが得意だったりする人たちがまだ社内に多いからだと思います。

「今はGoやTypeScriptを書いているけどPerlが好き」という人が多いから、困っているばかりというわけでもなく、工夫しながら暮らしている、というのが実状です。

Perl自体も、なんだかんだ言って、ちゃんと後方互換性を維持しつつアップデートされ続けていますからね。

 

 

新しい技術スタックへ

 

伊藤さん：そうやってPerlのシステムをメンテナンスしつつも、一方では新しいものを作るときはPerl以外の言語を選択し始めたわけですよね。

具体的には、いま話に出たGoやTypeScriptが現在のメインだと思うんですが、潮目が変わったのはいつぐらいだったんでしょうか？

 

motemenさん：2018年ぐらいです。

はてな社内では、それまで歴史的に開発陣とインフラ部隊の分業体制が続いてたんですが、そのころ、それがわりと良くない状態になっていて。

 

伊藤さん：私がまだ在籍していた頃は、インフラまで含めて開発者が見ていましたが、もしかすると、その辺の開発者がいなくなって「所与のシステムを使う」というスタンスになって分断が起きてしまった感じですかね。

自分で選んだテクノロジーでないと、他人事とまではいかなくても、開発者がインフラまで含めて面倒をみようとはなりづらいから…。

 

motemenさん：そうなんですよ。

昔は開発者も普通に障害対応をしていたんですが、当時にはもう「作ったので運用はインフラ部門に任せます」みたいな感じになっちゃっていたんです。

開発者はどんどんサービスや機能を作り、それを壁の向こうからインフラ部門に投げ込むみたいな状況で、ついにはシステム部門がバーンアウトしてしまった。

 

ついには高度化するインフラの更新が追いつかず、アプリケーションを作る側でも更新できていないインフラ上でサーバーを立てるしかなくなってしまい、身動きが取れなくなってしまった。

これでは良くないから、「もっと開発者がプロダクト全体のオーナーシップを持つようにしよう」という流れになったわけです。

 

伊藤さん：オーナーシップを持ってもらうためには、開発者が自分たちで選択した技術でないとならないから、そこでテクノロジーの幅を広げようという議論になって新しい言語が選ばれた感じですね。

 

motemenさん：そんな感じです。

社内で共通の技術を使っていたのは、運用や構築をひとつの部署に任せる前提があったからなので、その前提を1回ちょっとはずして、「自分たちで運用できるような技術を、自分たちの事業に合わせて選択してください」っていう方向に振ってみたんです。

とはいえ、それでもはじめのうちは「知っている技術でコンサバに」という感じで、変わらない技術が選ばれることも多かったです。

でも、そういう中でも徐々に「小さいものは新しい技術スタックで作ってみよう」という動きが出てくるようになり、現在に至っています。

 

伊藤さん：そこでGoが「自分たちに合った言語」として選択されたことには、何か理由とかきっかけはあったんですか？

 

motemenさん：会社の中でちょっとしたものを作るときに、私が率先してGoを試していて、それがある程度は参考にされた気がしています。

「motemenがやっているから使ってみる」という形で、間接的な影響はあったのかなと。

 

伊藤さん：なるほど。

そもそもmotemenさん自身がGoを使い出したきっかけは何かあるんでしょうか？ プライベートで書いていたとか？

 

motemenさん：いや、その時点でプライベートでGoをやっていたわけでもないんですよ。

どちらかというと、はてラボの実験的なサービスをGoで書いてみたり、社内のサブシステムをGoで書いてみたりしていました。

「世間でGoがメインストリームになりつつあるから、ちょっと何かやってみよう」という感じです。

 

伊藤さん：じゃあ、現在のはてなのGoが社内で主に使われているのは、PerlからならGoに移行しやすいという類の理由が先行したわけではなく、結果的にそうなったという感じなんですね。

 

motemenさん：そうです。あとは、新しい技術を試す機会が増えたのも大きかったと思っています。

昔はでっかい既存のシステムにどんどん機能を追加するっていうプロジェクトが多かったけれど、だんだんそれだと難しくなってきて、もう少しサブのサービスを切り出そうっていうやり方になってきた。

マイクロサービスというほどではないものの、そういう機会ができたので、せっかくだからGoにしてみようかと。でなかったら今でもPerlを使い続けているかもしれません。

 

伊藤さん：昔は、1つの会社でなるべく同じ言語、同じフレームワークで統一したほうが良いと考えていたんですよね。

いろんなチームが好き勝手にいろんな技術を採用してしまうと全体最適でなくなって、人の移動も難しくなれば学習コストも上がってしまうと考えていた。

クラウドやコンテナがまだない時代なので、複数の技術を採用したときに足回りのコストも上がってしまうというのも背景にあったと思います。

 

とはいえ、同じ技術だけで保守的にやっていると、開発する側にオーナーシップを持つ動機が生まれなくなる。

一休でも今は、会社のなかで技術選択の幅をある程度は持っていたほうが良い、という方向になっています。

 

motemenさん：まさにそうで、はてなも昔は「はてなフレームワーク」という共通のベースがあり、全員がどのサービスも見られるし障害対応もできるみたいな感じだったのが、いつの間にか全然そうじゃなくなってしまった。

なので、古い基盤からの脱出に振って、まずは「好きな技術を使っていいよ」と言うようにしたのが2018年ごろだったわけです。

 

伊藤さん：この辺は、CTO目線だとなかなか舵取りが難しいところでもありますね。

エンジニアがそれぞれ好きな技術を使っていいという方向に振りすぎても大変だし、結局はどうやってバランスをとるかを考えることになります。

 

motemenさん：やっぱり、エンジニアが盛り上がって作ったものが後から問題になるみたいな現象はありますからね。作った本人は楽しかったんだろうけど…、みたいなケースが負債になってしまう。

 

伊藤さん：でも、そういうケースになることを恐れてコンサバな選択だけで行くと、それはそれで面白くない。

 

motemenさん：はい。

何かしら面白みを感じるものを選択してほしいけれど、かといって「作って楽しい」だけでは困るというのが悩ましいところです。

 

伊藤さん：「人に褒めてもらいたい」という動機でコードを書いていたmotemenさんも、立派なマネージャーになりましたね。

 

motemenさん：やっぱり、自分もけっこう痛い目を見てきましたからね…。

うごメモはてなっていうサービスを作ったときも、ぼく自身は気持ちよくコードを書いていたけれど、全然メンテナンスできないコードの塊みたいなやつができてしまって、後からいろんな人に迷惑かけたなあと。

 

伊藤さん：システム開発って、いわば「作ったそばからカルマを積む」という仕事ですからね。

何も作らなければこんなことにはならないんでしょうけど。

 

motemenさん：でも、作らないわけにもいかないですしね。

 

 

技術選定にCTOの好みを反映させるべきか

 

 

伊藤さん：僕は2010年にはてなを退職したわけですが、その後に自分が作って残していったシステムに苦しめられている人がいるっていう噂を耳にするたび申し訳ない気持ちになっていました。

たしか、はてなブックマークはアルバイトで同じチームだったid:taraoさんたちが2015年ごろにScalaで書き直したんですよね。Scalaも社内ではけっこう使われているんですか？

 

motemenさん：そんなに大きくはないサブシステムで使ってみたことはありますが、サービス全体をScalaで実装しているケースとなると、はてなブックマークとMackerelの2つだけです。

めちゃくちゃ大きくなることが最初から判明しているサービスを作り出すとかだと別なんでしょうが、今のところ利用は大きく増えなさそうですね。

 

伊藤さん：2つだけなんですね。

そもそもmotemenさん自身がScalaを書くことは、プライベートを含めてあるんですか？

 

motemenさん：Mackerelのアルファ版でディレクターをやっていたときは書いていましたが、今はほとんど書かないです。

プライベートとなると、それこそほとんど書かないですね。

言語として嫌いとかではまったくないんですが、Scalaで作りたいものが特に思いつかないんですよ。

自分にとって普段使いする言語ではないのかな、と。

 

伊藤さん：確かに、motemenさんが普段作っているものは、ブラウザで動くちょっとした遊び心のあるプログラムとか、いろんなGitリポジトリをcloneするのに欠かせないghqみたいな便利なCLIですとか、そういうのが多いですよね。

Scalaのユースケースにはマッチしないのかも。

 

motemenさん：Scala.jsを使ってブラウザで動かすものを作ろうとしてみたことはあったんですけどね。

もしかすると、いま会社でScalaをガンガンに使っていくという方向性になっていないのは、CTOである自分があまりScalaを書いていないのもあるかもしれません。

自分の好みを押し付ける形にしたくないとは思っているんですが…。

 

伊藤さん：その辺は、どうしてもプライベートと仕事が地続きになる面はありますね。

 

motemenさん：はい。

会社でエンジニアが「これ良さそう」って盛り上がっている話に付いて行くためにプライベートの時間で使ってみる、みたいな意味でも地続きなんですよね。

 

伊藤さん：CTOという立場だと、当然、ちょっとした意思決定が会社に影響を与えるから、いろいろと試すことになりますよね。

そこで「自分の好きな技術で引っ張ろう」という考え方のCTOもいるだろうし、逆に合理性を求めて自分のプライベートな好みとは完全に切り離した技術にするっていうCTOもいるだろうし。

 

motemenさん：私は、基本的には「チームでいい技術を選んでください」という方向性だと思います。

あまりコンサバティブな方向、はてなで言うと「Perlで行きます」みたいなのはやめてくれと言っていますが。

 

伊藤さん：私は、けっこうあやふやかなあ。

会社ではTypeScriptとかPythonを書いているわけだけど、自分自身はこれらをプライベートではあまり使っていなくて、家で書いているのはもっぱらHaskellなんかで、最近はたまにRustを触るぐらいなんですよね。

Rustについては会社の仕事で使うことを検討もしています。

とはいえ、あとで話しますが、それは家でRustを書いていることとはあまり関係していない…。

かといってCTOとして会社のテクノロジーを選択するときに自分の趣味を一切反映させていないかというと、そういうわけでもないしで、あやふやなんですよ。

 

motemenさん：そう言われると、私もあやふやな部分はあります。

自分の趣味で決めているとは思いたくないけれど、何かしらの形で反映させている自覚はありますから。

 

伊藤さん：たぶん、その会社とかチームの構成にもよるんですよね。

放っておいても技術的な改善を進める人がいるチームなら、CTOが自分の意向を反映させるために介入することもない。

 

たとえば一休の例で言うと、ホテル事業とレストラン事業があって、レストラン事業は技術選定に対して少し保守的で、なるべく現在の構成技術でやろうとしてしまう傾向にあった。

だから、「せっかくプロジェクトを新しく始めるので少し新しいことにチャレンジしよう」っていう感じで、私が少し自分の意向を反映させた提案を差し込みました。

一方、同じ一休でもホテル事業のほうについては、技術選定にあまり関与せずにやれています。

 

 

PerlとHaskellの間をとってScala

 

motemenさん：Mackerelの場合、Scalaを選んだのは私ではなかったんです。

プロトタイプ版から作っていたリードエンジニアが最初「Haskellで作りたい」って言ってたんですよ。

「さすがにHaskellはちょっと…」となってScalaに落ち着いたんですが。

 

伊藤さん：はてな社には、昔からHaskellが好きな人が何人かいましたね。

私の同期だとHaskellの解説書の謝辞によく名前が載っているmaoeさんとか。

彼は入社時からHaskellが好きだった。仕事で使いたいとは言ってなかったけれど。

 

motemen:さん：手元で動かすちょっとしたツールとしては、Haskellで書かれたものも社内にはありました。

ただ、プロダクションで使うとなると、さすがに…。

 

伊藤さん：そうですね。

HaskellでもちゃんとやればWebアプリケーションは作れるんですが、片手間でプロダクションに採用するとなるとちょっと難しいですね。

 

motemenさん：はい。

なのでMackerelについては、PerlとHaskellの間をとってScalaでいこうと。

 

伊藤さん：その2つとなるとだいぶギャップがありますが、言わんとしていることはよくわかります。

2015年当時だと、JVM上で動いて既存のインフラストラクチャを扱う資産も十分に揃っているScalaはとても現実的だったでしょうね。

今だと、Rustも選択肢になる感じですか？

 

motemenさん：Rustをやりたそうなエンジニアはいるけれど、まだそんなに強い勢力にはなっていません。

 

伊藤さん：意外ですね。はてな社だと、もうRustの嵐が吹き荒れているのかと思っていました。

 

motemenさん：開発合宿などでRustを使ってみよう、というエンジニアもいます。

小さいところでの採用はいいと思うんですが、大々的に採用するのはまだ踏み込めないな、と。

 

伊藤さん：なるほど。CTO目線では、Rustの盛り上がりにどう会社として接していくか問われるようになりつつありますね。今のうちに何か判断基準を作っておきたいですね。

 

少し話が戻るんですが、私は最近、技術選定に関して、必ずしも今の環境から理詰めで考えていくのがいいわけでもないな、とも思っているんですよね。

さっき、一休にはレストラン事業とホテル事業があるという話をしたんですが、これら2つのシステムはそれぞれPythonとGoで別々に実装されているんです。

どういう事情で別々の言語になっているかというと、もともとレストラン事業がPythonを使っていて、その後でホテル事業を書き直そうというときにGoを選択した結果なんですが、保守的に考えればホテル事業もPythonに合わせるほうが短期的には最適なんですよね。

それでも、「いやここは1つの技術に全振りしないほうがいいんじゃないか」っていう直感があって、Goを使ってみることにしました。

 

結果、今はレストラン事業のPython製のシステムのほうが、型システムが十分でなかったり相対的に速度が出なかったりで少し課題を抱えつつあります。

他方、データサイエンス周りはやはりPythonとの接続が便利だったりもします。

2つのプラットフォームを使っているおかげでその差がはっきりわかるのは多様な環境であることのメリットですし、一方に全振りしなかったのは良かったなと思っています。

 

ただ、やはりPythonで書かれたシステムがトラフィックのあるところでは費用対効果がよくないので、いっそのことレストラン事業もGoで書き換えようっていう話も出るには出たんです。

すると今度は、「じゃあ全部Goになるけど、それでいいのか？」となりまして。

というわけで、ここで選択肢としてRustが頭をよぎるわけです。これは少しチャレンジングですけど、ぼちぼちやってみようかなと思って進めています。

まずは大きな更新系業務ロジックが存在しない、GraphQLバックエンドからやってみて、もしうまくいかなかったらそこだけ再度書き換えても手間はかからないし…。

 

motemenさん：脱出できるっていうのは、けっこう重要ですよね。捨てられる部分でチャレンジしないと。

 

伊藤さん：自分たちにとってミッションクリティカルな業務、一休で言うと金勘定系とか予約業務系でRustを使うのは、もう少し自分たちの熟練度が上がってからかなと思っています。

理屈上はRustの型システムを上手に使えば、そういう業務ロジックをより堅牢にできるはずです。

 

 

 睡眠時間を削らなくてもコードは書ける

 

 

伊藤さん：ここまでCTO目線の話が中心だったので、最後に仕事以外の話も少し聞きたいと思います。

ホームページを拝見すると、ちょくちょく何か面白い作品や便利な作品が公開されているから、すごくいろいろやっているなと思っているんだけど…。

 

motemenさん：仕事ではあまりコードを書けないので、プライベートでなんとか時間を確保して書いている感じですね。
こういう話になるといつも、「仕事もゲームもするために何を削るかっていったら命を削るんだ」っていう伊藤さんの昔のツイートを思い出すんですよ。

「伊藤さんは命を削っているけど、自分は命は削れないからな…」って思います。

 

伊藤さん：ツイートでは大げさに言っているけど、あれは要するに睡眠時間を削っていたんですよ。

1日に3時間とか4時間しか寝ないで、アニメを見たりゲームをしながら仕事をしてました。

今はもう無理です！

 

motemenさん：私は、けっこうロングスリーパーなので、睡眠時間を削ると何もできなくなっちゃいます。

だから真似できないんですよね…。

 

伊藤さん：お子さんもいるし、睡眠時間は足りなくなりそうですね。

 

motemenさん：子どもがいると、一緒に寝てしまうので、むしろ睡眠時間は確保できるようになりました。

7時間とか、日によっては9時間くらい寝ています。

それで気づいたんですが、自分はそれくらい睡眠をとっているほうがパフォーマンスが上がるんですよね。

日中にしっかり頭が働くから、仕事の合間の時間でちょっと手を動かしたり本を読んだりできる。

それで、たまに気持ちが盛り上がってきたら睡眠時間をちょっと削ったり、あるいは週末を使ったりして、何かしらコードを書いています。

 

伊藤さん：じゃあ、基本的に仕事が終わって帰宅したらお子さんのお世話をして、それで一緒にけっこう早く寝るんですね。

そのぶん早く起きて活動することもありますか？

 

motemenさん：朝はしんどくて、あまり活動できないんですよ。

だから、普段はとにかくよく寝るようにしていて、たまにタイミングが合う日を見つけて夜中に手を動かす感じです。

日中の休み時間とかも、あまり手を動かしてなくて、手を動かす準備だけをしています。

調べものをしたり、「あそこはこうすればできるのでは？」みたいなのを考えておいて、家でガッとやる。

 

伊藤さん：motemenさんが当時、夜中までオフィスに残ってお酒を飲みながら、酔拳のように趣味のプログラムを書いていたのを思い出しました。

アルコールが入ると、吹っ切れていつもより大胆なコードが書けると言っていました。

 

motemenさん：あれも楽しかったんですけどね。

今は手を動かす時間は減って、手あたり次第にコードを書くことはできなくなってしまったけれど、そのぶん頭の中で練ったものを短時間で書くようにしています。

 

伊藤さん：育児のようなライフスタイルが変わるフェーズでも、外から見ると以前と変わらずに手を動かしてコードを書いているmotemenさんのような人が、一体どうやって時間を確保しているのかって、けっこう気になる人が多いと思うんですよ。

和田さんとのインタビューでも同じように感じたけれど、やはり変化したライフスタイルに合わせて意識的に時間の使い方を工夫しているわけですね。

 

motemenさん：そうですね。

手を動かして思考錯誤する時間は確かに減りましたが、身体が自由にならない時間でも、頭はわりと自由に使えることが多いと思っています。

子どもを寝かしつけながら別のことを考えたり、休日に家族で畑をやってるんでその農作業中に何かを考えたり…。

 

伊藤さん：お子さんが何人かいて、仕事もCTOだし、それでも時間の使い方の質を変えることでアウトプットをしているmotemenさんの姿には、勇気をもらえる人が少なくないと思いました。

これでmotemenさんが、「睡眠時間を削って、なんだったら家庭を顧みずにプログラムしていますよ」みたいな感じだと、世の中的には「特殊な人でないと35歳を迎えてなおプログラミングを続けるのは難しいのか…」って愕然としてしまう。

 

motemenさん：そうですね。時間の使い方の質は本当に変わったと感じます。

 

伊藤さん：そんなmotemenさんにとってのロールモデルみたいな人はいるんですか？

 

motemenさん：エンジニアとして強く影響を受けた人という意味だと、冒頭でも出てきたセコンこと館野さんですね。

実は、同じチームでは仕事をしたことはないんですが、Shibuya.jsやはてなに誘ってくれたのがセコンさんだったので、人生においてもかなり影響を受けています。

 

伊藤さん：セコンさんは、はてな時代は私のチームメイトだったけれど、かなり早い段階からRailsに入れ込んでいて、外からいろんな知見を持ち込んでくれていましたね。

はてな退職後はクックパッドのCTOも務めていました。

 

motemenさん：自分にとっては、何か新しいニュースをキャッチして面白いものを作るエンジニアの姿を目の当たりにしたのがセコンさんだったんですよね。

 

伊藤さん：セコンさんは、どこかから新しい技術を見つけてくるんですよね。

まだはてなを含め世の中のみんながSubversionを使っていたころに「これからはGitだ」と言って、チームの環境にも気づけば入れちゃってたりする。

私も、チームのバージョン管理システムがある日突然Gitに変わってて、「どうやって使うのこれ？」ってGitコマンドの使い方を教えてもらっていました。

結果的にはセコンさんがそういう開拓をやってくれたおかげで、どんどん自分たちの環境が良くなっていきました。突破力のあるめちゃくちゃすごい人だと思います。

 

motemenさん：はい。いろいろ発見するだけでなく、手を動かしてまわりを変えていくこともできるのがすごいなと思っています。

 

伊藤さん：それ、本人に言ったことはあります？

 

motemenさん：ないです。

 

伊藤さん：この対談が記事として公開されたら、きっと本人、喜びますね。

 

motemenさん：あとは新卒当時、むしろライバル視していたという感じですが、同じ時期に新卒入社したエンジニアにも影響を受けました。

コードを読んでいると思想があって、それが自分のそれとは違うんだけれど、それがその人の中では一貫しているし、納得できる。そういうタイプのエンジニアのコードを見ながら刺激を受けてました。

 

伊藤さん：ああ、なるほど。

はてなには「ほかの人が書いたコードをなぞってコードを書く」っていうタイプじゃなく、「こうしたほうがいいんだから、こうするべき」っていう考えをハッキリと持ってコードを書くタイプのエンジニアがけっこういますよね。

motemenさんの同期にもそういう人がいたから、互いにいい感じにぶつかり合って新陳代謝し、その過程で新しいものが生まれていたという印象はあります。

 

motemenさん：ある意味、青春でしたね。

 

伊藤さん：当時のことを思い出しながら、一休のエンジニアの中でも、そういう関係ができるようになるとうれしいなあと思いました。

 

この記事では、大坪弘尚（motemen）さんと伊藤直也さんによる対談をお届けしました。ここ20年でWeb開発に利用される技術、特にプログラミング言語のトレンドがどのように変化してきたか、その選定をするCTOはどのような目線でさまざまな技術を見定めているのか、日頃あまり言葉にして外部に語られることがない本音が垣間見えたと思います。

 

伊藤直也さんがCTOを勤める株式会社一休の採用情報はこちら。

 

 

興味を持たれた方は、ぜひ一度無料相談を利用してみてください。

 

編集協力：鹿野桂一郎（ラムダノート株式会社）
撮影協力：PETALS TOKYO
東京都品川区東品川２-１先