【第1回・後編】エンジニア和田卓人のこれからを形作る技術

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

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

 

・和田 卓人さん / プログラマー、テスト駆動開発者

学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努力している。

『プログラマが知るべき97のこと』（オライリージャパン、2010）監修。『SQLアンチパターン』（オライリージャパン、2013）監訳。『テスト駆動開発』（オーム社、2017）翻訳。『事業をエンジニアリングする技術者たち』（ラムダノート、2022）編者。テストライブラリ「power-assert-js」 作者。

Twitter: @t_wada
GitHub: @twada

 

 

Rustは「産業を支える言語」になるか

 

 

伊藤さん：エヴァンスのDDD本の話ばかりでは何なんで、ちょっと別の話も伺いたいんですが、和田さんが最近勉強している技術の話を聞いてもいいですか？
受託開発もやられているので、仕事ではいろいろ必要に駆られて勉強しないといけない話はあると思うんですが。

 

和田さん：仕事だといろいろあるんですけど、個人としてはRustを勉強しているところです。

 

伊藤さん：やっぱりRustですか。Rust、とても勢いがありますね。

 

和田さん：ここまでの話では、技術顧問業や受託開発の話しかしてませんでしたが、実はOSSの開発者も続けていて、Rustはその辺りの文脈から勉強している感じです。

 

伊藤さん：OSSは、受託開発などとはまた違うプレッシャーがありそうですね。

 

和田さん：そうなんです。
基本的には自分の責任でコードを書いて、うまくいくとおびただしい数の人に使われる結果、リリースの責務も果たすことになるみたいな。

自分がやっているOSSで、かなりたくさんの人に使われているものとしては、JavaScriptのテストに使うpower-assertというのがあって、毎週20万くらいダウンロードされてます。

で、Webフロントエンドの世界の話で言うと最近まではWebpackでゴリゴリやってきたわけですが、Denoをはじめ、esbuild、Romeと、足回りとなるNode.jsのツールチェーンが実行速度を求めてGoやRustで置き換えられるようになってきました。

JavaScriptのエコシステムはこれからも続くと思うんですが、その足回りは違う言語にゴリゴリと書き換えが始まっているんです。

となると、自分の興味の問題だけではなく、それこそ「黒船がきた」みたいなやむにやまれぬ理由から、Rustを読み書きできないと参戦できなくなりつつあると考えまして、今は勉強しているという感じですね。

 

伊藤さん：私の個人的な印象では、ここ数年で急にRustの話を聞くようになったなあと。

もちろん以前からも時折耳にはしていましたが、同僚が普通に使っていたり、隣の企業で採用されたり…。
そういう状況を目の当たりにするようになったのはここ最近です。

実をいうと、この間に丸1年くらい、ボーっとしていてあんまり開発ができていなかった時期があったんです。

 

和田さん：Rustという言語自体は、Firefoxの足回りのために作られたものとして2010年ごろからあったので、割と技術面でとがった人はずっとRustに言及はしてましたね。

 

伊藤さん：たしかにそうですね。

Rebuild.fmで森田さんがRustのメモリ管理の話をしていたのを覚えています。

それがたしか4、5年前くらい前だったでしょうか。自分はその当時、「へえ、変わった言語があるんだな」くらいの感覚でした。

当時は「C++の代わりに使われる言語だ」くらいの認識だったのが、気づけばOSSのツールチェーンのバックエンドがどんどんRustになっていて。

最近はlsとかcdみたいな普段使っているUnixコマンドまでRustで書き直したというものがたくさん出てきていて、自分の開発環境も入れ替えたりしたけど、一方で「あれ、なんでこんなことになっているんだろう？」と。

 

和田さん：基本はC/C++の代わりなんですよね。
開発者体験が良くて自分の足を打ち抜かないC/C++、みたいな。

ものすごく雑に言うと、Rustは「リッチな言語体験があるので開発体験が犠牲にならず、なのにシステムプログラミングができてむちゃくちゃ速いバイナリが出る言語」という印象です。

コンパイルさえ通ればほぼ破綻なく動くし、コンパイルエラーもめちゃくちゃ詳しいので、とにかく開発者体験が良いんですよね。
コンパイル時間はなかなか長いんですけど。

 

伊藤さん：そこのポジショニングって、一時期はGoが取っていましたよね。
ツールチェーンを作っているような人たちの間では、最近だとGoよりRustのほうがよいっていう感覚があったりするのかな。

 

和田さん：Webのバックエンドとかだと、必ずしもそういう感覚ではないと思うんですが、OSSのツールチェーンまわりは事情がちょっと特殊なので、そういう感覚もあるかもしれません。

OSSの世界では、やっぱり実行速度は端的に競争力につながるので、とにかく速度が重要というのもあります。

同じことをするツールなら実行速度が速いほうがいいし、フットプリントが小さいほうがいい。
ベンチマークをとってREADMEに貼り付ければ、それだけで威力があるみたいな。

だいたいはマイクロベンチマークでしかないんだけど、それでもやっぱり威力がある。

あと、これはRustに限らないんですが、新しい言語を学ぶときって試しに何かを実装してみますよね。

仕様が良くわかっていて枯れているものを、自分のよく知らない言語で書いてみようという車輪の再開発は、純粋に言語の学びになる。

 

伊藤さん：ToDoリストを作る人もいれば、テスティングツールを書く人もいますね。
Rustの場合、それで試しに書いてみようっていうのが日常使いしているコマンドを対象にしてみる、みたいな感じでしょうか。

 

和田さん：そんな背景でOSSの足回りのRustへの置き換えが進み、それでOSSのRustのコードが増え、Rustを使った開発のやり方みたいなのがみんなに知られて、それでまたフィードバックが回るんですね。

Rustはかなり難しめの言語ですが、そうやってOSSの生きたサンプルコードが増えてきたから、だんだん学びやすくもなってきていると思います。

 

伊藤さん：このままいくと、Web開発のバックエンドにも、ある程度までRustが入ってくるかもしれないなとも思うんですよね。

自分たちはいまGoを使っているんですが、開発者のなかにはRustを普段から書いているエンジニアもいて、Goでは意図をエンコードしづらいと言っていました。

「自分の意図をコードで記述したくても、Goで書くと命令型っぽい書き方になるので、そこの表現力が足りないところがもどかしい」って言うわけです。
学習コストはかかるかもしれないけれど、もしみんながRustを書けるようになるなら、いずれGoでなくRustでWeb開発をやってもいいじゃないかって。

時間の問題じゃないかなとも思いますが、現状ではまだ、Webアプリケーション開発に必要なデータベースまわりのライブラリみたいな部品がRustに揃っているのかとか、その品質は十分なのかとか、そういう肌感がまだわからないんですよね。

なので、このタイミングで選択していいのかというと、難しい。

 

和田さん：いわゆる「産業を支える言語」になりうるかという話ですね。

 

伊藤さん：産業を支える言語っていうとJavaが思い浮かびますが、和田さんのなかでGoはもうそういう段階にある？

 

和田さん：ここで「産業を支える言語」と言ったのは、「いろいろな人があまり学習にコストをかけることなく戦力になる言語」ぐらいの意味なんですが、Goはこの点でうまくいっていると思います。

Rustは、言語としてはすごく良いのですが、でも「すごい人がみんなたしなんでいるけど、普通の人には使いこなせない言語」になってしまうかもしれません。

 

伊藤さん：たしかに、当初の自分のRustに対するイメージもそういう感じでした。

 

和田さん：とはいえ、さっき言ったように、ここ数年でだいぶいろんな人にRustの名前が知られるようになって、コードも増えました。
もう1つか2つくらいブレイクスルーが起これば、より多くの人が書くようになるかもしれません。

一方、Goは最初から覚えることを減らして、みんなすぐにそれなりに書けるようにしようという引き算の言語なんですよね。

しかも、それなりに書けばちゃんとスケールするしデプロイもしやすいという、絶妙なところを狙っている言語。

 

伊藤さん：一休でも、Goを採用しているシステムが多くあって、すごくたくさんの開発者が参加しているんだけど、「開発者が多数参加しても処理効率的な意味で悪くなっていかない」というのが一つ発見でした。

同じくらいの規模でPythonを採用しているシステムもあるんですが、そちらはある程度わかってる人たちだけで開発してたころは問題なかったものの、たくさんの人が参加してコードを書くようになったら、少しずつ綻びが出てきてしまった。

結果的に、現状では2つのシステムの処理効率にすごく差がついちゃっているんですよね。
もちろん、PythonよりもGoのほうが処理系として高速なのはあるんですけれども、数字的な差を見るに、それだけではなさそうだなと。

 

和田さん：Goは、その辺がすごく絶妙なんですよね。
デプロイも容易だし、goroutineによる並行性もそうだし。うまいこと設計されている。

ただ、さっき話に出た「できればRustで書きたい」という開発者の方みたいに、プログラミングが好きで好きでたまらない人にとっては面白みが少ない言語かもしれません。

 

伊藤さん：そうですね。
Rustもそうですし、TypeScriptその他の表現力の豊富な言語と比較してしまうと、どうしてもそうなってしまいますね。

 

和田さん：血気盛んなうちから「仕事でコードを書くっていうのはこういうことなんだ」みたいな諦念を味わってもらいたいわけじゃないから、そうした「もっと良くできるはずだ」という気持ちを包容できるキャリアパスがあってもいいかもしれませんね。

DSLとか独自言語みたいな形までいっちゃうと、ついてこられる人が少なくなってメンテナンス性に問題を抱えるようになっちゃうんだけど。

メンテナンス性といえば、Goはその面も本当によく考えられていて、たとえばGitHubでコードレビューを行う際もブラウザ上である程度見通せるような文法なんですよね。

Googleの社内ではコードレビューのためのツールといったインフラとの親和性みたいなところまで考慮されていて、なるほどと思います。実に渋い言語です。

 

 

引き続き影響力を持ち続ける静的型付き言語と関数型言語

 

 

伊藤さん：RustやGoもそういう感じありますが、いまのプログラミング言語って、ざっくり「強い静的型付けのある関数型言語」と呼ばれるものの影響を全体に受けていますよね。

 

和田さん：ですね。
そうした言語で培われたパラダイムや機能が、エッセンスとしてかなり多くの言語に取り入れられています。

 

伊藤さん：和田さん自身、そういう言語を仕事で使うようなことってあるんですか？

 

和田さん：プロダクトコードだと、ある意味関数型言語という枠でSchemeはあるけれど、Haskellのような関数型の静的型付き言語を本格的に仕事で使うという機会はまだないです。

さきほどサンプルコードがF#で書かれた本の話が出ましたが、そういう書籍のなかに出てくるコードを写経したりはあるくらいです。

 

伊藤さん：私は最近、プライベートでよくHaskellを書いています。

仕事でTypeScriptを書かなきゃいけなくなったとき、恥ずかしながら型システムがなんだか全然わからなくて。
雰囲気で書いてるのを脱したかったんだけど、これはTypeScriptだけやっていても理解するのが難しい気がしたので、ある程度の型システムが備わっている別の言語もやってみようと思って。

結果、TypeScriptもそうですけどRustやSwiftやKotlinなんかも、Haskellのような言語からいろいろな機能を取り入れていっているんだなっていうトレンドが見えてきたんですよね。

最近のフロントエンド領域にしてもそうですし、先に挙げた言語における「代数的データ型を多用してパターンマッチする」みたいな書き方にしても、関数型言語の特長が反映されていますよね。

業界全体、今まで以上に、これからもそういう言語の影響を受けていくだろうなと思っているんです。

長期的にはプログラミング言語のデファクト・スタンダードはこの流れなんだろうなと。

 

和田さん：フロントエンド、特にReactは、そういう影響の先端ですね。

最初に登場したときからそういう傾向がありましたが、ReactはFacebookのエンジニアがどんどんステートレスで関数ベースな設計へと先鋭化させてきて、それにみんな追随してきましたから。

結果、みんなが日々の仕事をとおして「なるほど、副作用ってこういうことね」っていう肌感を持つようになった。

 

伊藤さん：最近のエンジニアは、それこそFunctionalなReactから入るので、これが当たり前なんですよね。それこそ世代の違いがある。

 

和田さん：プログラマは、最初に見た言語とプログラミングパラダイムを親鳥だと思うから。

 

伊藤さん：そうそう、なので当然、これからの大きな流れはそっちにいくんではないかなあと。
強い静的型付けの関数型言語そのものが主流になるとまでは言わないけれど、トレンドとしては外せない。

 

和田さん：エッセンスは間違いなくこれからも入ってくると思います。

 

伊藤さん：DDDも、型を使ってドメインモデリングを表現すると、わりと矛盾なくモデリングできるなってケースがすごく多い気がしているんですよね。

職場でも、この手法を試してみていて、今のところ感触がいいんです。

さすがに社員全員にそれで書くのを要求するかはまだ迷うところですが…。今のところは自分の小さなチームに閉じたプロダクトでのみ実践するようにしています。

 

和田さん：何らかの「地ならし」は必要ですよね。

言語の機能という観点だと、たとえばパイプライン演算子の導入なんかは、そういう「地ならし」に関連する話としてあるかもしれません。

「構造よりも処理の流れで設計しよう」という話になったら、コードの中での視線の流れを処理の流れに一致させたい。

「仕事のルール」に関数としての名前がついていて、それらをデータが順番に流れていくように書ければ、視線の流れと仕事のプロセスの流れが一致するわけです。

業務ロジックをパイプライン演算子で繋げて書けば、見た目として「この次にこれをやって、その次にこれをやって」っていう流れが書ける。
コードを設計と一致させてフィードバックが回るようにするのがDDDなので、そうやって両者の翻訳をスムーズにするのが大事ですよね。

 

伊藤さん：それに加えて、パイプライン演算子の境界は「ドメインイベントが発生するポイント」なんですよね。

だから、「ドメインイベントが発生した状態が遷移して、データがそこを流れていく」のを宣言的に表現できる。
これはすごいなと思っているところです。

 

和田さん：インスタンスメソッドの呼び出しとは見た目的にも違う、というのもポイントですね。

 

 

パソコン少年への憧れと、コンピューターサイエンスへの憧れ

 

 

伊藤さん：型システムとか関数プログラミングの話って、やっぱりある程度やっていくとどこかでコンピューターサイエンスの世界に足を踏み込むことになりますよね。

私の場合、必要に駆られて社会人になって以降に独学でつまみ食いしている感じなんですが、ちゃんとした大学に入って学生のときにコンピューターサイエンスをやりたかったなっていう、コンプレックスみたいなものがいまだにあります。

和田さんはコンピューターサイエンスを専攻されていましたか？

 

和田さん：一応、大学でそれなりにコンピューターサイエンスをやっていまして、CPUとかコンパイラとかの授業は一通り受けました。

ただ、卒業してから思うと、「なんであの先生の授業をもっととらなかったんだ」みたいなのはありますね。
後からすごさがわかって悔しい思いをするやつです。

 

伊藤さん：でも、うらやましいですね。

自分は、高校生のときはもちろん、30才前後に当時のICPCの国際大会に出ていた太田さん（kzk）や田中さん（tanakh）とかにお会いするまで、そういう背景をきちんと知っている人たちのレベル感というのを目の当たりにする機会がなかったから。

学生時代の大量の時間をコンピューターサークルとかに注ぎ込んでいた人たち、本当にすごすぎるんですよね。

TypeScriptにすごく詳しいuhyoさんも、先日なんでそんなに詳しいのか聞いたら、大学の研究室で型システムの研究室にいて、そもそもそういう研究をやっていたらしいんですよ。

「うらやましい…」って思ってしまいました。

 

和田さん：わかります。
仕事で企業の新人研修をやっていますが、みんな自分よりもスペックが高い。
毎回、そんな人たちに俺が何を教えればいいんだって思いながらやっています。

あと、小学生のころからコードを書いていたという人にも、ちょっと劣等感を覚えるんですよね。
電気屋さんの店頭にあったパソコンを触っていた武勇伝みたいなのを持っている人がいっぱいいる。

 

伊藤さん：和田さんには大変に申し訳ないですけど、ぼくは実はそっち側ではあるんです。

プログラミングを始めたのは幼稚園に入る前でした。

ただ、ソースコードの意味はまったく理解していなくて、BASICマガジンに載っているコードをただ写経してました。

 

和田さん：ハードは？

 

伊藤さん：当時、父親が東芝に勤めていたので、東芝のパソピアっていうPCが自宅にありました。その後、小学生になったらMSXをもらいました。

さすがに小学生になるとif文とかfor文くらいは理解できるようになったけど、BASICのルーチンを自分で組み上げるとかはできなくて、ゲームのコードの適当な変数を書き換えて無敵にして遊んだり。

でも、そういう経験が今の仕事に活きているかと言うと、あんまりそういう気もしないんですよ。

むしろ、そうやって遊んでたころにパーソナルコンピューターの可能性を知らなかったっていう劣等感があります。

 

和田さん：ぼくがその可能性に気づいたのは、大学のときにアメリカに留学して、レポートを全部パソコンで書いて提出する、みたいな世界に触れたときです。

当時の日本の普通の高校では、まだ原稿用紙でした。
これまでとの落差がありすぎて、「あれ、世の中はこんなことになっているの？」って思いました。

なるほど、全部コンピューターでやる時代になったのか、と思って。それで日本に帰ってきてから急いでPCを買ったんですよ。

とはいえ、キャリアとしてはちょっと特殊で、コードを書くようになったのはもっと後になってからです。

むしろ、コードを書く前にデータベース設計から始めたんですよ。

 

伊藤さん：そういえば、和田さんはデータベースの人でもあるんですよね。
ただ、『SQLアンチパターン』の翻訳をしているのは知っているけど、RDBMSに詳しい人っていうイメージはあまりないかも。

 

和田さん：そこまで詳しいわけじゃないですよ。
でも、キャリアとかスキルセットとしてはRDBMSです。親父がもともとRDBMSの技術者というのもありまして。

 

伊藤さん：そうだ、親子喧嘩している動画みましたよ。

 

 

知的探求心をもって勉強することは「仕入れ」である

 

 

伊藤さん：若いときと今とで、エンジニアとしてやっていく上で変わったなと思うことってありますか？

 

和田さん：プライベートの話になりますが、子どもが産まれてから勉強量がガクっと落ちたのはあります。
といっても、振り返ると実は4年くらいの短い期間のことで、そのときは割り切って全力で子育てにあたっていました。

きっかけは、牧さんが「子供が本当に子供でいられる時間はものすごく短いから、可能な限り多くの時間を父親として割こう」という趣旨のことをご自身のブログに書かれていたのがすごく印象に残っていて。

牧さんはお子さんが何人かいて、写真を見るとみんな「小さい牧さん」みたいでかわいいんですけど、そのブログを読んで「ぼくも子供を一番大事にするか」と決心しました。

そうしたら、実はやってみると4才になるあたりから話が通じるようになってきて、子育ての難易度がだんだん下がってきました。
お願いしたことをちゃんと聞いてくれる感じになると、もうそこからはだんだんインプットもアウトプットも少しずつできるようになったんです。

いまはもうだいぶ大きくなってきたので、少なくとも、0才とか1才のときみたいに「ほぼ100%のリソースをもっていかれる」みたいな感じではありません。

 

伊藤さん：ソフトウェアエンジニアにとって、勉強と子育ての両立が難しいという話は、先日もTwitterとかを起点に話題になってたのを読んでました。

この業界特有の問題かもしれないけど、自宅にPCさえあれば休みの日でもスキルアップができてしまって、それに対してブレーキをかける要素もないから、やれる人はやっちゃうんですよね。

結果的に、ワークライフバランスを崩してでもスキルアップに邁進できる人が有利、という構造ができてしまっている。

 

和田さん：あんまり健全な構造じゃないですよね、昔から。

 

伊藤さん：かといって、健全じゃないからやるな、とも言えないですしね。
やっている当人はスキルアップのためというより、趣味とか好きでやっている人も多いですし。

今の職場もそうなんですが、自分がいたチームや組織は学習意欲の高い人が多くて、そうすると「勉強してスキルアップするのが普通な環境」が自然とできてしまう。
だからこそ難しいんですよね。

とはいえ、もし勉強する必要があったとしても、「プライベートで勉強しろ」とは言えない。

 

和田さん：個人がプライベートの時間に好きで勉強するのは大変良いことだと思いますが、仕事に関係するスキルを勉強するみたいな活動は仕事の時間の中でやるのが良いと考えています。
仕事の時間の中で勉強をやる。もちろん残業としてではなく。

 

伊藤さん：うちも、テックトークとか部活みたいなのを業務時間内にやっていますね。

 

和田さん：業務時間内に1時間くらいの時間を決めて、チームで勉強会とか読書会をするだけでもいいと思います。

ソフトウェアエンジニアにとっては、知的探求心をもって勉強するという習慣をつけること自体も仕事で、それは知識労働者にとっては「仕入れ」なわけですよ。

仕入れなんだから、業務時間にやる仕事としてやります。

 

伊藤さん：会社で業務中にやることで、これは仕事の一部なんだっていう意味付けにもなりますよね。

 

和田さん：ですね。
重要なのは、自己研鑽も仕事として、会社の業務の1つとして行うことなんだと思います。

 

伊藤さん：Web開発エンジニアの間で、子育てと勉強の両立っていう話題を急に見かけるようになったのって、業界の中心的な世代が今ライフステージのそういう段階に入ったってことなんですよね。

5、6年くらい前も、突然まわりのみんながマネジメントについて語り出すようになったことがあって、そのときも同じように感じてました。

マネジメントについては、自分はもっと若いころに四苦八苦していたんだけど、その当時は誰もそういう話をしてなかったんですよ。
たぶん同年代でそういう仕事をしている人がまだ少なかったからだと思うんだけど、ひとりでもがいてました。

数年後にみんなが急にマネジメントの話をするようになったのを見て、「あのときは誰も話に付き合ってくれなかったじゃないか」みたいな、ちょっと卑屈な気持ちになったり。

たぶん、いま子育ての話をしている世代は、これからみんな家の話をするようになります。
その次は、誰それが病気にかかったとか、退院したとかって話をよく聞くようになって、健康の話を始めるようになると思う。

 

和田さん：それで言うと、自分のいまの話題は眼ですね。
ずっと2.0とか1.5の視力があったんですけど、1年半くらい前からいきなり目がつらくなって、短期間で一気に目が悪くなった。

 

伊藤さん：視力、自分も1年くらい前から会社で仕事していて眼が霞むようになって、びっくりしました。

それまで40年以上、裸眼でプログラミングしていたので、「眼が悪い状態」っていうのを全然知らなかったんですよね。
それが急に健康診断で視力1.2と1.0とかに落ちてしまった。

 

和田さん：やっぱりみんな同じ道を行くんだなあ。
以前、確かartonさんに「現役を続けていくうえでの壁って何ですか？」と聞いたときに、「…眼だよ」って言われたんですよ。

 

伊藤さん：まさかこんなことで自分の生産性が落ちる日がくるなんて、思ってもいなかったですよ。
夜、家に帰って本を読もうと思ったら、もう眼がきつくて。

和田さんは老眼判定されたんですか？

 

和田さん：眼科でいろいろ診てもらったんですが、ほかに原因がないので老眼である、と言われました。

 

伊藤さん：ぼくはね、まだセーフなんですよ。
微妙に老眼は始まってますが、主な原因はそれじゃないって診断されてます。

まあ、とはいえ似たようなもんなんですけど。
もともと乱視があって、今までは若さと筋力で無理くり合わせられていたけれど、筋力が落ちてきたので疲れたときにカバーできなくなったらしいです。
いわゆる老眼の症状とは別と言われました。

結局は老化だし、老眼の症状も始まってはいるので、なんの救いにもならないですけど。

 

和田さん：自分の場合、目が疲れやすくなってきていて、ピントが合わなくなったり文字が二重になったりします。

あと、裸眼では近くには基本的にピントが合わない。
老眼といってもまだ軽度で、近くだけが見えない程度だから、仕事のディスプレイの距離とかをいろいろ調整して乗り切っています。

 

伊藤さん：じゃあ、眼鏡をかけなくてもプログラミングしている間は平気なんですか？

 

和田さん：わりと平気ですよ。

 

伊藤さん：ずるい。
私はちょうどディスプレイの距離がダメなんで、プログラミングするときにも眼鏡をしなきゃいけなくなりました。
ディスプレイと自分の距離を計って、だいたい眼から60cm～70cmくらい先にフォーカスしたレンズを作ってもらっています。

ディスプレイを見ない間は眼鏡を外すようにしてるんですが、それでも眼鏡を使い始めた初日は本当に気持ち悪くて、世の中の眼鏡をかけている人はこんな感じで過ごしているのかって衝撃を受けました。

 

和田さん：わかる。眼鏡をかけ続けるってすごいなって思います。

 

伊藤さん：眼科で説明してもらったんですが、眼鏡をかけ始めて1ヶ月くらい視界がグラグラしたり頭が痛くなったりするのって、脳がその信号を正しく処理できない状態にあって自律神経に変な信号を送っちゃうのが原因らしいです。
船酔いと一緒らしいんですよ。

で、1ヶ月間くらい眼鏡を通した映像を脳に与えると、ディープラーニングと一緒で、脳がそれを学習する。

なので、今はもうまったく平気になりました。
むしろ今は、「この眼鏡さえあればまだプログラムを書き続けられるぞ」って希望すらあります。

 

 

連続してまとまった時間がすごく貴重

 

 

伊藤さん：勉強する時間の話と、視力の話以外に、エンジニアとしての生き方について変わったことって何かありますか？

 

和田さん：やっぱり子育てに関係するんですが、週末が全然使えなくなったことですね。
土日祝日の使い方が大きく変わりました。基本的にずっと子供と一緒にいるんですよ。
なので、週末には1日中コードを書こうとか、そういうのは諦めることにしてます。

「連続してまとまった時間」というのが全然取れないんですよ。

コードを書いていると、3時間経ったころにフロー状態に入るみたいなのがあるじゃないですか。
その感覚に入る機会が深夜くらいしかないのが、今の個人的な悩みです。
子どもの寝かしつけに成功して、奥さんも寝ているという条件が成立すると、書斎に行ってコードを書けるチャンスタイム。

でも、午前1時くらいにインスピレーションが降りてきて、ものすごく乗ってきたときにどうするかというのは、頭の痛い問題なんですよね。
そのままいくと3時過ぎになるコース。翌日起きて子供の勉強を見たり支度をしたりする時間は決まっているので。

 

伊藤さん：ぼくは、会社の仕事が終わって家に帰るとまったく頭が回らないので、どちらかというと早起きして頭がクリーンになった状態でプログラミングするようにしてます。

いずれにせよ、そういう時間はすごく貴重だから、無駄にしないって意識が働いて、だらだらと生産性が低いことをしないぞってなりますよね。

 

和田さん：ですね。

 

伊藤さん：ここまで話を聞いてきて思ったんですが、和田さんってミッドエイジクライシスみたいなのはなかったんですか？

ぼくは、1年くらいプログラミングに対する興味がなくなったことがあって、あれは今思い返すとミッドエイジクライシスだったなって。

原因があったとすると、会社の仕事でマネジメントの比率が大きくなったのがきっかけだったんですが、その1年間はプログラミングの本なんかも1冊も読めなかった。

もう自分はキャリアとしてプログラマーを辞めて「開発のことを知っているマネージャー」みたいになるのかなって思ったけど、突然またやる気が戻ってきて。

 

和田さん：今のところ、そういうのはなさそうです。

子どもが小さい時期と、自分が手がけているOSSがめちゃくちゃ使われた時期が重なってメンタルが落ち気味になったことはあったけど、あれはクライシスというよりは単に忙しすぎて無理だったという。

どちらかというとOSSの作者燃えつき問題かなと思います。やっぱり、ユーザーが多いと要望もすごく数が多い。

 

伊藤さん：私は経験がないので想像だけど、power-assertのようなライブラリ系のOSSって、アプリと違って大変そうですよね。

 

和田さん：この環境だと動かない、これだと動く、こういう機能に対応してほしい、こうなったらいいと思うとか、これで動かないのはなぜか、そういういろんな温度感のコメントがいっぱいくるんですよ。

しかも、いろんなOSSについてメンテナが返事をする速度を測ってスコアリングしている外部サイトなんかもあるので、放置すると心理的なダメージが溜まっていく。

 

伊藤さん：好きにやらせろよ、みたいに思いますよね。

 

和田さん：思いますね…。

 

 

10年後、20年後のロールモデルは？

 

 

伊藤さん：最後に、これからの話もお聞きしたいんですが、和田さんがロールモデルにしている人っていますか？

 

和田さん：自分が20才くらいのときは、「自分が目指すべき20才くらい上の存在が見当たらない問題」っていうのをなんとなく認識していたんですよ。
10才上や30才上は見つかるけど、20才上のロールモデルが見つからない。

10才上は仕事上でかかわることも多いし、30才くらい上だと、父親やその知り合いみたいな感じになるので、「30年後はあんな感じか」って想像しやすかったんですよね。

20才上のロールモデルがなかなか見つからなかった。

でも、気づいたら自分の今の年齢が新卒エンジニアの20才上くらいになっているんですよね。
新卒研修の時期になると、私は20年前の自分にとってのロールモデルになれているだろうかと自問することがあります。

いまの自分より年上で、昔の自分がやりたかったことを体現している人となると、最近は増えてきたんじゃないかと思います。たとえば柴田さんや福井さんは、生涯現役のソフトウェアエンジニアとして、ロールモデルになっていると思います。

 

伊藤さん：私は、実は自分の10年後や20年後をあんまりイメージできなくて。

自分がそのころプログラムを書いているのかどうかもわからない。

ただ、今はCTOをやっているけれど、今から10年後の55才でCTOっていうのは嫌だなっていう思いだけはあるんですよね。

というのも、自分がその会社で働くエンジニアだったとして、自分の会社のエンジニアのトップが55才の自分なのは嫌だなって思うんですよ。なんとなくですけど。

だから、さっさと後進に道を明け渡さなきゃいけないと思っているんです。

でも、そうすると「じゃあ自分はそのとき何をするんだろう」ってなるわけで、その55才の自分の姿みたいなのをちょっと描けていないんです。

 

和田さん：普通にどこかの企業でIC（Individual Contributor、個人貢献者）として活動したり、スタートアップにいってみたりとか、いろいろ道はあると思いますが、どうですか。

 

伊藤さん：選択肢がないわけではなくて、むしろ選択肢はたくさんあるんだけど、それで自分がハッピーかどうかが想像できないんです。

たとえば、いまから5年後の50才で一休のCTOを辞めてスタートアップにいくとして、そこはみんな20代だったりする。
最近は世代が上がっているから、30代後半とか40代のエンジニアも普通に混じっていて、2週目スタートアップみたいになっているけど、50才の自分がそこで耐えられるのか想像がつかないんですよ。

 

和田さん：最近、自分はそれを想像できるようになった感じです。
技術顧問などで様々な現場にお伺いする機会が増えたことで、自分より年上でゴリゴリとコードを書いている人がいる現場を見るようになったのが大きいかもしれません。

 

伊藤さん：ああ、なるほど。
たとえば、先ほど和田さんが名前を挙げた柴田さん、私は直接お会いしたことがないんですよ。

もちろんブログや著作では存じ上げているんですが、そういう人が現場にいる姿とか、その人と一緒に働いている人たちの感覚とか、そこがやっぱりわからないんですよね。

和田さんの技術顧問先の会社に、自分たちより上の世代のベテランがまだゴリゴリやっている会社って、けっこうあるんですか？

 

和田さん：技術顧問先にもありますし、製造業に行くともっと多くなります。
それこそ60代で現役みたいな人もいて、そういう方がリスキリングしてプログラミングしていたりする。

ただ、Web開発の現場だと、自分たちが第一世代みたいな感じなので、そこまで数は多くないですね。

 

伊藤さん：なんか、最近自分とは歳の離れた若い人に少し気を遣うんですよね。

 

和田さん：気遣うって、怖がられないようにするってこと？

 

伊藤さん：20才くらい下のエンジニアと自分の距離って、自分が思っている以上にギャップがあるはずなんですよ。

たとえば、コードレビューで何気なく指摘したことが、こちらが思う以上に本人にとって大きなこととして伝わってしまう。

その年齢差に、更にCTOというポジションが掛け算されてしまうので、それを理解して接しないといけないと思うようになりました。
今後歳を重ねれば重ねるほど、ますます拍車がかかるなあと。

これが、歯に衣着せぬ発言をする同世代のエンジニアのコードレビューなら、めちゃくちゃ気楽なんですが…。

 

和田さん：ああ、そういうことですか。

 

伊藤さん：単純な年齢差だけでなく、世代の違いもあるかもしれない。
彼らを見ていると、お互いの距離感をすごく大事にしていますよね。これ以上距離を詰めたらいけないみたいな感覚がしっかりある。

かつてはモヒカンっていう言葉があったぐらいで、「正しけりゃマサカリを投げてでも指摘しろ」っていう話もありましたよね。
でも、それが必ずしも必要なかったんだなって思っています。

 

和田さん：むしろ不用意にマサカリを投げる態度は、最近ではブリリアントジャークと呼ばれて排除されかねませんね。

 

伊藤さん：私自身ブリリアントジャークという自覚がややあって、どっちかと言うと排除される側にいるので、他人事ではないんですよ。

 

和田さん：ベテランは、石を投げると相手が死ぬという意識でレビューをするのが大事になりましたね。

あとは、インフォーマルな伝え方。
まずは一緒に書いてみようかと言ってペアプロに持ち込むとか、褒めるのはみんなの前でやるけど問題の指摘は直接対面でするとか、記録が残らない形も併用する。
立場上、そのような仕草が求められるのはあると思います。

自分はむしろ、「和田さんがそう言うなら、そうなんだろう」みたいな反応が怖いです。
楽しそうな自転車置き場の技術談義に嬉々として混ざっていくと、みんなの反応が「和田さんがそう言うなら、そうなんだろう」となって議論が終わってしまう。あれは恐ろしい。

 

伊藤さん：「なんでも全部知っている人」って思われていると感じるとき、ありますね。
ぜんぜん詳しくない分野でもレビューの依頼先が全部自分だったり。

とはいえ、そうやってレビューをなんでも依頼してきてくれるのはまだよくて、場合によっては「怖い人」と思われている。

 

和田さん：怖い人と思われている問題、ありますねー。
「話してみたら優しい方でした」とか、よく言われます。もともとの怖い人という刷り込みはどこからきたんだ、って。

 

伊藤さん：私は今の一休という会社に38才で入ったんですが、入社した直後はCTOとはいえ一番最後に入ってきた社員だったから、まわりの人たちのほうが精神的には上の存在だった。

その差が少しずつ埋まっていって、ついに逆転して、最近では「私がCTOとしている会社」にみんなが入ってくる。
そうすると、自分が思っている以上に怖く見えるらしいんですよね。怖いというよりは、距離が遠いということなんだとは思いますけど。

 

和田さん：自分が怖いと思われてるなと感じるのは、やっぱりテストファーストに関する文脈ですかね。
いきなり、「テスト、書いたことがありません」みたいな懺悔をしてこられることもあります…。

 

伊藤さん：私も、わりとプロジェクトの初期テストを書かないタイプなんで、懺悔しなきゃいけないですね。

 

和田さん：またそうやって誤解を広げるようなことを言う…。

 

伊藤さん：でも、以前から和田さんを知っている人からすると、和田さんが怖い人だと思われているのはとても意外ですね。

 

編集協力：鹿野桂一郎（ラムダノート株式会社）

撮影協力：タワーズレストラン「クーカーニョ」／セルリアンタワー東急ホテル
東京都渋谷区桜丘町26-1 セルリアンタワー東急ホテル 40F

 

この記事では、前編と後編の2回に分けて、和田卓人さんと伊藤直也さんによる対談をお届けしました。
お二人のベテランの物静かな言葉の端々からは、その時々の技術や知見をこれまでもこれからも学び続けるのだ、という意欲が感じられたと思います。

技術顧問やCTOという立場で次々に登場する新たな技術の真価を見極め、現場へと還元していく二人の現在のお仕事は、まさにこうした真摯な経験の積み重ねによって培われた成果であることを読み取っていただけたのではないでしょうか。

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

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

 

 

■修正履歴

実状と異なる箇所について文面を修正しました。

「Googleの社内ではメールベースでコードレビューするらしいですが、そういうインフラとの親和性みたいなところまで考慮されていて、なるほどと思います。」→「Googleの社内ではコードレビューのためのツールといったインフラとの親和性みたいなところまで考慮されていて、なるほどと思います。」（2023/1/31）