一休のCTO伊藤直也氏はファンも多く、日本のエンジニアなら誰もが一度は名前を目にしたことがあるだろう。
伊藤氏は、新卒で入社したニフティで「ココログ」を作り、はてなのCTOとして「はてなブックマーク」を作ったことでも有名だが、伊藤氏の名は、コミュニティにおいて日本のエンジニア文化を育ててきた人物の一人としても広く知られている。現在は関数型プログラミング言語「Haskell」の熱心な支持者でもある。
日本のエンジニアリングコミュニティの成長に大きく寄与してきた伊藤氏に、強く印象に残っている本を聞いた。
CTOは技術力がないといけない
読書は、その人が持っているコンテキストと合わさってその人の読書体験になっているので、「これを読むべき」というようなお薦めをすることはないです。今回は、単純に過去に僕が読んで良かった本を紹介したいと思います。「これを他の人も読むべき」と思っているものではなく、「今思えばこの本を読んでおいて良かったな」という本です。もっとビジネス書みたいなものを期待されているのかもしれませんが、あまりそういうものはなく、技術的な書籍を紹介していきます。
おそらく、CTOの肩書きを持っている人で「今も現役でプログラムをガシガシ書いている」っていう人は多くないように思います。知り合いに会っても、「マネジメントが忙しくなって自分では書かなくなった」という人がほとんどです。
会社に所属して、年数が経ってくると自然と「チームをまとめる・率いる」という役割が求められてくる。だからマネジメントについて学びたいと考える人は多いと思います。僕もそういうことで悩んだ時期もあったのですが、今はもうそこは解決しています。僕は、自分の時間を「マネジメントのようなこと」にはあまり使っていません。もちろん、CTOの役割はマネジメントなんですけど、基本はプログラムを書いたり、現場の指揮を執ったりとか、そちらに時間を使うことが多いですね。
「部下と1on1して話を聞く」とかみなさんよくやっているようですが、僕はあまりそういうことはしません。そういう「上司が部下の面倒を見る」というマインドの組織は作らない。「エンジニアとして技術力を基に引っ張っていく」ことを志向すると、そもそも僕がそんなたくさんの人のマネジメントに介入しなくても普通に開発が回るようになって、結果、自分もコードを書いたり、開発自体のことを考えたりできるようになったんです。
僕はインターネット黎明（れいめい）期みたいな時代に、協力会社も含めて1,000人規模だったニフティに新卒で入って、しばらくしてそれを辞めて、スタートしたばかりのはてなに入りました。はてなの成長過程では、たしかにそういうマネジメントで手がいっぱいになってプログラミングから離れてしまった時期もありました。
ところが、一休に入ったら、社長の榊（代表取締役社長・榊 淳氏）のスケジュールに全然予定が入っていなかったんですね。榊は部下からレポートを受け取るんじゃなくて、自分でSQLを書いてデータを分析して、会社の状況を把握している。だから、レポートを集める必要がないんですよ。本来自分よりも忙しいはずの社長がそうなんだから、その手前のポジションである僕がミーティングでスケジュールが埋まるのはおかしい。それで、僕も同じようなマネジメントスタイルに軸足を移すことにしました。
CTOのポジションの仕事をするにあたって、自分自身の技術力が担保できないと難しいなって思うことが多いんです。僕はやっぱり周囲のエンジニアの作っているものを理解したいと思うし、今の生成AIのような新しいテクノロジーが来たときに、正しく理解して判断したいと思うんですよね。変化の速い業界なので、自己研さんをやめた途端に分からなくなってしまいます。昼間はマネジメント的なことをやって、家に帰ってから技術書を読むというだけでは、現場で日中からプログラムを書いている人には追いつけないんです。
もしかしたら他の会社の多くのエンジニアにとって、CTOは「調整や人事が中心の仕事で、現場の細かいテクノロジーには介在しない人」というイメージなのかもしれません。でも、一休だと、大きな障害が起こったりシステムが動かなくなったりすると、場合によっては僕が陣頭指揮を執ることもあります。だからエンジニアのみんなからすると、ある種リスペクトもあるけど、怖いと思われているかもしれませんね。
上司がテクノロジーを分からない人だったら、本当は1週間で終わる仕事を「1カ月かかります」と言って楽をすることもできる。でも、僕にはそういうごまかしは利かない。僕もエンジニアだから分かるんですが、エンジニアはごまかしの利かない上司にはそういうことはしなくなります。たとえ同僚とはいえ、質の高い仕事をしていくにはそういう緊張感が必要だと思っています。
本質的な知識が、最終的に目の前の課題を解決する
今回は、あまりノウハウを解説しているような書籍は選んでいません。そういうものは時代が移り変われば、あっという間に陳腐化してしまうし、それこそ生成AIが肩代わりしてくれる領域である可能性が高いと思っています。職業プログラマーを目指すならその類の知識もある程度は必要だと思いますが、コンピューターサイエンスの基礎そのものがより重要だと思います。
1冊目は、アルゴリズムとデータ構造の本です。もちろん、他にもスタックが、ヒープが、二分探索が……と各種アルゴリズムを分かりやすく説明している本はたくさんあります。一方、これはMITの教科書にもなった本です。この本には単に「このアルゴリズムはこういうふうに動きます」とか「こう実装すればいい」ということが書かれているのではなくて、「このアルゴリズムは数学的にこういう特性と構造を持っているから、この計算量で動く」という理論が書かれています。数学とアルゴリズムの関係が、クリアに分かるようになっています。
アルゴリズムとデータ構造の世界には「このアルゴリズムはデータが10万件あったら、どのぐらい時間がかかるか」という「計算量」という概念があるんですけど、それもすごく数学的に厳密に記述されていて、「コンピューターサイエンスをちゃんと勉強するとは、こういうことなんだな」と感じられる本です。でも、そこまで難しいわけではない。
今回選んだ本の中では一番入りやすいところだと思います。応用も利きやすいし。相変わらずネットを見ると「アルゴリズムやデータ構造はわざわざ勉強しなくても、最近はライブラリで呼び出せばいい」とか「自分で実装する必要はない」と言う人もいますが、そんなことはないですから。アルゴリズムやデータ構造は計算機を扱うための基礎です。われわれは「計算機」を使って色々な問題を解決する専門家なんだから、計算構造に疎くていいわけがありません。
僕は30歳前後のときにこのあたりの基礎知識を学ぶことに時間を費やしたのですが、それが血肉になって、後々の仕事を助ける場面が数え切れないほどありました。今でもあの時間を取ってよかったなと思います。
だいたいみんな、ある程度ウェブアプリケーションを作れるようになると、僕と同じように「本質的なことが分かっていない」というところでつまずくんですよ。それを乗り越えるには、やっぱりこういう「敷居も高いし即効性は期待できないけれど、大切なことが書いてある本」に深く潜らなきゃいけない。当時はそういう気持ちでした。
僕がまだ若いときに、Googleの社員エンジニアの方の家に行ったことがありました。その方の書棚にはまさにこの手のコンピューターサイエンスの本ばかりが並んでいたんです。一方の僕が読んでいたのはアプリ開発の本とか、そういうものばかりで、全然技術に対するアプローチが違うなと痛感しました。
やっぱり、コンピューターサイエンスの真ん中をちゃんとやってきて、Googleでエンジニアリングをやっているような方は、本質的な知識に常に触れているんだなあと。ハウツーみたいなものは、必要になったところで学べる。最近の人たちは「生成AIを前に何を学習したらよいか悩んでいる」と聞きますけど、別に僕たちも悩んでこなかったわけじゃないんです。
その悩みを取り払うには、こういう古典的な、本当に「技術の本質に迫るような本」を読む必要がありました。
数学の基礎が理解できる、古典的傑作
この『数学入門』は古い本（1959年初版）なんですが、すごくいいんですよ。数学に詰まった僕が読んで、深く感銘を受けた本です。当時、数学を勉強し直したんですけど、勉強したはずの大学の数学があらためてやってみるとよく分からず、それで高校数学まで戻って、何なら中学数学まで戻って、それでも「分かっていない」ということに気が付いてしまったんです。
子どものころに数学を面白いと思えなかったとか、数式の意味も全然分からなくて基礎から勉強し直したいけど、小学校のドリルとか、高校の教科書とかやるのかな……と思っている人にはお薦めです。これはそういう問題を解くための数学書ではなくて、数学の「意味」を解説している本なんです。70年近く前に書かれた本なのに、今でも十分すぎるぐらい古くない。
例えば、ここに水のペットボトルが2本あります。パソコンも2台あります。どっちも「2」という数字で表せるわけですが、まったく違うものがなぜ「2」という数字で表せるのか？ とても素朴な質問ですけど、多くの人は答えられないのではないでしょうか。日頃から自然数やその足し算掛け算を使ってはいるけれど、よく考えるとその「意味」は分かっていない。つまりわれわれは、道具の使い方は多少は知っているかもしれないけれど、「その道具がどういう意味を持っているか、どんな背景でその道具が生まれたのか」についてあまりにも無頓着なんです。この本には、それがなぜ同じ「2」で表せるのか？ ということが書いてある。それこそが本当の「数字の意味」なんです。そういうことを一つひとつ積み重ねていくと、「分かった」と思う瞬間がくる。これが、僕にはめちゃくちゃ面白い体験だったんです。今まで分かっていたようで、分かっていなかった。
よく「プログラマーには数学的素養が必要だ」と言いますけど、少しミスリードなんです。「数学的素養とは何なのか」を語っていないから。そしてかつての僕を含む多くの人は小学校、中学校、高校で勉強した受験数学のことを数学だと思っているから、数式を展開してミスなく素早く計算できることが重要だと思っているんです。でも、多分そうじゃないんです。
数学的素養とは「数ある具体的なものから、抽象的な要素を取り出して、一般化する」ということなんです。無関係に見えるものの中に潜む共通の構造を抽象として取り出して、その一般性を追求して、どんどん純粋性を上げていく。それが数学がやりたいこと、本当の数学的素養だと思うんです。
この数学的素養は、プログラミングとすごく直結します。プログラミングでは、同じものを何度も繰り返して作りたくないから、抽象的な構造を取り出して、それを実装するんですね。処理を共通化するのが抽象化なのではなくて、抽象構造を持ち上げる、それが抽象化なんです。それは数学における抽象化とまったく同じ意味なんですよ。
この本では計算の問題を解かされるということではなくて、例えば三角関数やベクトル、行列などの数学的概念がどういう歴史的背景で生まれて、そもそも何がしたくて作られたのか、そういう数学のいろいろな概念が生まれた背景を説明してくれるんです。何度読み返しても「そういうことだったのか！」と膝を打つ場面がある本です。
プログラミング言語は「意味」を記述するもの
これは、プログラミングに没頭したことがある人なら、必ず面白いと感じられる本だと思います。
プログラミングって、要するに記号ですよね。「そもそも俺たち、なんで記号を使ってコンピューターに命令してるんだろう？」って素朴なことを疑問に思って読むと、「記号には思っていた以上の意味がある」ということが分かります。
代表的なプログラミングのパラダイムに関数型プログラミングとオブジェクト指向というものがあるのですが、それらを記号論で比較した章なんかは、特に面白かったですね。現在は、多くのプログラミング言語に関数型プログラミングのエッセンスが取り入れられてきているのがトレンドなので、そういう意味でもその構造的な違いを知っておくと、より深くプログラミング言語のパラダイムの違いが分かってくると思います。
そして、プログラミングのパラダイムだけではなくて、そもそも記号には人間が思っているよりも深い構造、記号と意味には強固なつながりがあって、極端な話「人間がいなくなっても、記号は存在しているかもしれない」というようなことが書いてあります。記号は人間が便宜上生み出したもののようにみえるけれども、記号こそが世界の意味かもしれないという。とても面白いですよね。
最近は、生成AIをめぐる議論で「生成AIがプログラムを書くようになって、最終的にはAIが中間レイヤーを飛ばしてマシン語を直接吐き出す方が効率がいい。生成 AIもわざわざプログラミング言語を書く必要はなくなる」という意見も見かけます。
でも、僕はそういうふうには思っていない。そうした意見は、おそらく「プログラミング言語は人間がコンピューターを操作するためのインターフェースで、コンピューターにとっては非効率なレイヤーだ」という前提に立っているんだと思うんです。でも、僕は記号というものが持つ力を知れば知るほど、記号列でもあるプログラミング言語は別に人間のためのものだとは思わなくなっていきました。
プログラミングというのはコンピューターへの命令を記述しているように見えて、実際には「意味」を記述しているんです。そして高級プログラミング言語は、マシン語よりも情報の圧縮率、表現力が高い。数式でもそうですよね。コンピューターは積分を四則演算に展開された式で速く計算することはできるけれど、展開した式では「意味」は簡単には分からない。展開されたすべての計算の時間推移を追った上でそれを解釈してようやく「積分だった」ことが分かる。でも積分記号には「積分である」ということそのものが書いてある。積分の記号があるから、2つの別の積分を「積分という意味」の構造を保ったまま合成することができるんです。積分から展開されたものを合成するのは大変だけれど、積分記号同士の合成は合成規則そのままに合成すればいいだけなので簡単です。数式、つまり記号は意味構造を保存したまま合成を可能にする。複雑な概念を高次元に圧縮したまま運ぶことができて、合成することができるってことです。プログラミング言語も同じなんです。プログラミングで僕たちが記述しているのは、高次元に圧縮された意味構造なんです。
つまり、数式やプログラミング言語は推論のためのブースターでもある。生成AIがマシン語を生成できるからといって、思考の中間の構造物を取っ払ってしまったら、生成AIは推論もできなくなる。もちろん、生成AIの方が既存のコンパイラよりも高効率なマシン語を生成できる可能性はあるでしょうし、生成AIにより最適化されたプログラミング言語が誕生する可能性も大いにあります。一方で、高級プログラミング言語そのものがなくなることには僕は懐疑的です。まあ、想像以上のことが毎日起きているので、外すかもしれませんが（笑）。
もとい、「記号というのは人間が勝手に後から作ったもので、人間がいなければ要らなくなるものだ」と考える人が多いですよね。でも、実際には記号というのは、世の中にある「意味」とすごく強い結びつきがあって、記号なくして意味自体を定義できないんだと思います。これは数学やプログラミングにも強く結びついている話です。
取材・文：村上タクタ／写真：尾関祐治（人物）、スタジオキャスパー（書籍）／構成：西 倫英＝日経BOOKSユニット第2編集部
