【第5回】「型」はウェブシステム開発に「エンドゲーム」をもたらすか

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

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

 

・鹿野 桂一郎さん / ラムダノート株式会社 代表取締役社長

オーム社にてプログラミング言語やネットワーク関連の企画編集に14年間携わった後、独立して2015年12月に出版社ラムダノートを立ち上げる。
技術書籍の企画編集・発行をする傍ら、Webメディアや雑誌などでの解説記事の執筆や編集なども手掛ける。

Twitter：@golden_lucky

GitHub：k16shikano

 

 

実践と理論が交わるとき

 

 

伊藤さん：鹿野さんには、これまでに和田さん（前編・後編）、uhyoさん、motemenさん、それにAtCoderのchokudaiさんとakensyoさんとのインタビューを記事として編集していただいたのですが、これらの対談の中で何度も出てきたトピックとして、型やHaskellがありました。

よく考えると、鹿野さん自身が『型システム入門』や『プログラミングHaskell』、それに『すごいHaskell』のような解説書の編集を手がけられてきたわけで、そのお話も直接聞けたら面白いと思い、最終回のゲストをお願いさせていただきました。

この間ずっと、SlackやGitHubで記事の編集のためのコミュニケーションなどはしていたのですが、実際にお会いするのは実は今日が初めてなんですよね。

 

鹿野さん：はい。たぶんそれ以前にもお会いしたことはなかったと思うので、本当に今日が「はじめまして」になります。

私は現在はラムダノートという出版社でプログラミングやネットワーク技術の本を出したり記事の編集をやったりしていて、それ以前にもオーム社というわりと大きめの出版社で14年くらいプログラミングの本も作っていましたから、どこかでnaoyaさんをお見掛けしていても不思議ではないのですが、意外とお会いする機会はないものですね。

 

伊藤さん：鹿野さんが手がけてきた本には、わりとアカデミック寄りのものが多いので、ぼくがやっているウェブ開発とはこれまで微妙に重なりがなかったのかもしれません。

とはいえ、最近ではウェブ開発の文脈でもRustのような言語に注目が集まったり、いろいろなプログラミング言語のパラダイムや機能の融合が進んできて、そういうトレンドの中でお互いの関心分野が繋がってきた感覚はあります。

 

鹿野さん：実はウェブ開発の本もやってはいるんですよ。
実際、Ruby on Railsの最初の日本語の本の企画編集者だったりもします。

ただ、言語としてはRubyが多かったので、その辺りも長らくPerlやPythonを使われていたnaoyaさんとは接点がなかった理由かもしれません。

 

伊藤さん：日本のRuby界隈には、Rubyが日本発で開発されたプログラミング言語ということもあって、ウェブ開発をやっている人だけでなく「言語処理系そのものに興味がある人」もかなり多いですよね。

鹿野さんが接点のあるRuby界隈は、もしかするとRailsでウェブアプリケーションを作っている人たちというより、そういう言語処理系に興味がある方が多いのかも。

 

鹿野さん：確かに、そういう傾向はありそうです。

先ほどnaoyaさんに言及したいただいた『型システム入門』も、静的型付けの本なのですが、実はRuby界隈でプログラミング言語自体に興味がある方々との繋がりがきっかけだったんですよ。

 

伊藤さん：動的型付き言語であるRubyがきっかけで、型に関する専門書が日本語で出版されたというのは、ちょっと面白いですね。

 

鹿野さん：Rubyの開発者であるまつもとゆきひろさん自身、静的型付き言語、特に型宣言には否定的という印象もけっこうあると思うので、そこは本当に面白いと思います。

訳者の一人はRubyのコアコミッターでもある遠藤侑介さんなんですが、「『型システム入門』は動的型付けの言語しか知らないRubyユーザにこそ読んでほしい」ともおっしゃっていたんですよね。

遠藤さんは現在ではRubyの静的型解析のためのツールであるTypeProfも開発されています。

 

伊藤さん：Rubyで静的型検査の仕組みが検討されるにあたって、『型システム入門』の訳者が活躍されているわけですね。

 

 

いまこそ『型システム入門』を読みたい

 

 

伊藤さん：『型システム入門』が出版される10年くらい前は、まだウェブ開発の界隈では今ほど「型が大事」という考え方が主流ではなかった印象もあります。
ぼく自身も、むしろ「ウェブ開発では静的型付けでないほうがいい」くらいのスタンスでした。

それが今では、RailsやPHP、Perlなどを書いていた人たちの中にも「型がないと大変だね」という話をしている人がすごく増えてきました。

 

鹿野さん：motemenさんとの対談も、まさにそういう話でしたね。

 

伊藤さん：はい。ここ10年くらいの大きなトレンドの変化として、そういう「型に対する考え方」の変化がけっこう大きかったと思います。

 

鹿野さん：motemenさんとの対談では「SICPブーム」の話題も出ていましたが、『型システム入門』を出版した当時、そのSICPを読んでいたような人たちからは「ようやく翻訳が出た」と歓迎された記憶があります。

それでも、当時のトレンドとして「型の何がうれしいのか」という空気感は自分も感じていました。

 

伊藤さん：実際、そういう空気感はありましたよね。私自身、「ウェブ開発には動的型付けの言語が適している」と言ったこともありました。

しかし、気づいたら現代は静的型付けの時代に突入していたんですよね。ここまで急激にトレンドの変化が起きるものなんだな、と。

ああいう発言は謹むべきだったと思うくらい、今となっては「型があるほうがいい」と考えています。

 

鹿野さん：一冊の専門書の出版によってトレンドが変化したとも思えませんし、この10年の間にいったい何が起こったんでしょうか？

 

伊藤さん：ウェブの人たちが型を重要視し始めたきっかけが何だったかというと、SwiftやScala、Goなどの新しい言語に注目が集まったことも一端としてはあったと思うのですが、やっぱりTypeScriptの影響が相当に大きいのではないかと思っています。

ウェブ開発者であれば多かれ少なかれほとんどの人がJavaScriptとはかかわりがあって、そこにTypeScriptがやってきたので。

 

鹿野さん：ああ、なんとなくわかる気がします。

TypeScriptの本をかなり早い時期に書かれたわかめまさひろさんにお会いしたとき、「『型システム入門』の編集者です」で通じたことがあって、それがすごく印象的でした。

TypeScriptに注目された方々が「型安全って何？」に対する答えを求めて『型システム入門』にも注目されているのかもしれない、と感じた記憶があります。

同時に、『型システム入門』はいわゆるIT系の技術書とは違って数学書のような書き方の本なので、「これは入門じゃない！」という声もかなりよく耳にしました。

 

伊藤さん：確かに、この本をいきなり読むのは難しい印象で、私自身も買ってはいるものの読めてはいません。

 

鹿野さん：でも『型システム入門』は、この手の本のなかではかなり読みやすい部類だと思うんですよ。他の教科書に比べると行間が広くなくて、きちんと言葉で丁寧に説明されているので。

 

伊藤さん：AtCoderの方々とのインタビューで話に出てきた田中秀行さんも、ご自身のブログで「原書は学生のときに読んだ」と書かれていたし、専門性の高い人だけが読めるめちゃくちゃ難しい本ではないはず、とは思います。なんですけど、初見では少し圧倒されてしまいますね。

 

鹿野さん：いかつい図式とか、見慣れない数学の証明とかが目立つので、それに圧倒されてしまうのはあるかもしれません。

ただ、そういう一見して難しそうに思える部分も、原著者としてはむしろ「読者へのサービス」のつもりで書いているとはずなんですよね。

たとえば、冒頭に本書で使う数学の基礎がまとめられている部分があって、これはまさに「数学を履修していない学部生でも読み始められるように」というサービスなんですが、プログラマーとしてキャリアを始めた人にはそこで読むのを挫折してしまう人もいるみたいです。

 

伊藤さん：難しい本の中では読みやすい、っていう感じなんですよね、きっと。

 

鹿野さん：そういう感じかもしれません。

あと、実はこの本、「手を動かして実装してみる系の本」であることがあまり知られていない気がします。
あえて言うと、「クラスベースのオブジェクト指向言語を作ってみよう」という本でもあるんですよ。

motemenさんのインタビューで、台湾のデジタルIT大臣であるオードリー・タンさんが学生のときにPerl 6を実装して世界を驚かせた話が出ましたが、オードリー・タンさんがPerl 6を実装したきっかけって、確か大学の課題で『型システム入門』の原著を読み、せっかくだからPerl 6を実装した、という感じなんですよね。

 

伊藤さん：え、そうだったんですか？

 

鹿野さん：はい。私自身、それを聞いたときに、この本がそういう「言語処理系を作る本」なのだと知りました。

 

伊藤さん：そう聞いて改めて目次を眺めてみると、いくつかの章の見出しに「実装」とありますね。

 

鹿野さん：そうです。形式的な理論の章と実装の章が交互に出てくる感じです。

一本道に実装だけをする本ではないわけですが、基本的には「型なしラムダ計算」という電卓に関数だけが付いたような一番シンプルな言語から徐々に基本型を備えた言語を育てていって、最終的には継承ができるオブジェクト指向言語ができるという構成になっています。

なので、章タイトルに「実装」とある部分から手を動かして、それから前の章に戻るみたいな読み方もありかもしれません。

ただし、実装に使う言語がOCamlなので、それで敬遠してしまう人はいるかもしれませんね…。

 

伊藤さん：なるほど、先入観で「難しい本」と思っていましたが、後半は確かにオブジェクト指向の話になっていますね。

最近、よくHaskellを書いているので、OCamlなら文法で躓くこともないはず。いまなら読めそうな気がしてきました。

 

鹿野さん：自分自身は、練習問題などを自分で解くような勉強をしたわけでなく、あくまでも編集の仕事として何度か本文に目を通したくらいの立場なので、そんなに偉そうに読み方をおすすめできるわけでもないんですが、ぜひ読んでみてください！

 

 

TypeScriptとIDEがウェブエンジニアの型への関心を押し上げた

 

 

鹿野さん：それにしても、naoyaさんとの話で『型システム入門』から入ることになるとは想像していませんでした。

 

伊藤さん：そうですね、ウェブエンジニアの間で再注目されている、とまでは言えないですが、少なくとも自分の周りでは「そろそろきちんと『型システム入門』を読みたい」と思っている人や、「読んだ」という人は、確実に増えている感じです。

 

鹿野さん：その背景には、やはり「TypeScriptをもっと使いこなしたい」という動機があるのでしょうか？

 

伊藤さん：実は、TypeScriptを書くだけなら雰囲気でも型を使えるんです。

理論的な背景を理解していなくても、なんとなくで使えてしまう。そうでなければここまでTypeScriptが多くの人たちに受け入れられることはなかったと思います。それはTypeScriptのすごくいいところでもあります。

ですが、一歩進んで「型を中心に据えてプログラムを設計する」ということを考え始めると、理論的な背景を知っておかないと難しくなってきます。

具体的には、uhyoさんとの対談であったように、代数的データ型を意識できるかなどはかなり重要だと考えています。
TypeScriptが流行り始めて、Reactでフロントエンドのアプリケーションを作るためのツールとして型を「使っている」段階では、あんまりそこまでは考えなかったんですが…。

 

鹿野さん：自分はHaskellをよく使うんですが、Haskellでは使いたい関数を型で検索するぐらいなので、それなりに型を意識できないとライブラリを使ったり、ましてや提供できないという現実はあります。

一方で、TypeScriptでそこまで考える必要があるのかは、あまり実感として想像できていません。

自分がTypeScriptやReactでの開発経験が皆無なのもありますが、実際のところ、従来のJavaScriptと同じようにTypeScriptでもクラスベースでライブラリやアプリケーションを設計すること自体は可能なわけですよね？

 

伊藤さん：もちろん可能です。

が、TypeScriptで本格的に大きいシステムを作ろうとか、Reactまでいかないまでも、ライブラリや汎用の部品を提供する側に回ると、ライブラリを使う側のためにもより厳密かつ抽象的に型を考えられるほうがよいです。

特に最近は、型がきちんと整備されているライブラリではIDEで賢く補完が効いてくれるのが大きいですね。

これは使いやすさに与える影響が大きいので、機能としては同じようなライブラリであっても、型付けをよくわかっている人が作ったものとそうじゃないものとでは、使っている側の体験を大きく左右してしまうことがあります。

 

鹿野さん：なるほど、「IDEの補完が強力になるので型があるとうれしい」という話にはすごく納得感があります。

 

伊藤さん：そうなんですよ。

この手の話題でエディターが注目されていることは多くないように思うのですが、いま改めて型が注目されている背景として「VSCodeをはじめとするIDEの普及」はかなり大きいと考えています。

 

鹿野さん：型が再注目されるようになった背景にあるTypeScriptの流行の、さらにその背景みたいな話ですね。

 

伊藤さん：はい。

TypeScriptがシェアを広げたのは、言語が素晴らしいのは当然として、VSCodeの利用者増加による影響もかなりあったんじゃないかと個人的には思っています。

リアルタイムに型をチェックしてくれたり、型情報から高度な補完を提供してくれたりするわけですが、そういう恩恵がほぼゼロコンフィグで得られるので。

 

鹿野さん：私も、そろそろVSCodeをまじめに使うようにしないとだめかなと思いつつ、なかなかEmacsやEmEditorから移行できないんですよね…。

 

伊藤さん：実をいうと、私もVSCodeを使い始めてから1年くらいしか経ってないんです。

それまではEmacsでずっと生活していて、身体がEmacsに最適化しすぎていたから、なかなか移行できませんでした。
SublimeTextやIntelliJを試したこともあったんですが、そのたびにすぐEmacsに戻るのを繰り返していた感じです。

でも、仕事でTypeScriptを書くことになって、それまでと同じようにEmacsを使おうとしたら、ぜんぜん書けなくて…。

 

鹿野さん：EmacsにもTypeScript向けのモードはあるし、LSP（Language Server Protocol）も使えますよね。それでは不足だった？

 

伊藤さん：きちんと設定すればそれでいけたんじゃないかとは思います。

実際、VimやEmacsでTypeScriptを書いている人たちはたくさんいるはずです。開発者にとってのエディターは料理人にとっての包丁みたいなものなので、愛用の包丁一本でなんでも上手に料理できてしかるべきという意見もあると思います。
自分も、TypeScriptという言語をもっとちゃんと理解していれば、最初からEmacsで書けたのかもしれません。

でも、当時は型も文法もよく理解していない状態だったので、Emacsでは手がでなかったんですよね。TypeScriptをまだ書けもしない段階でEmacsの設定を作り込むモチベーションはなかなか湧きませんし、ブートストラップに失敗してた感じです。

それで、試しにVSCodeで書いてみたら、IDEの支援のおかげで認知負荷がぐっと下がって、TypeScriptをスラスラと書けるようになりました。それから真剣にVSCodeを使い始めました。

 

鹿野さん：いわゆる、アンラーニングというやつですね。

 

伊藤さん：まさにそうですね。

それまで長年Emacsというエディターを使いこなせていると思っていたんですが、いつしかそれが自分の足枷になっていたことに気づきました。

 

鹿野さん：Emacsのアンラーニングには何ヶ月くらいかかりましたか？

 

伊藤さん：Emacsは20年近く使い続けてきたので、VSCodeに切り替えて2ヶ月くらいは、それまで何も考えずにできていたことが全然できなくてめちゃくちゃストレスがありました。
脳みそを慣れさせる辛い作業をしていた感じです。もう1年くらい経ちますが、いまだにEmacsのほうがやりやすいって思っている部分も少なからずあります。

特に、Emacsではdiredというファイラを使っていたんですが、VSCodeではdiredほどはファイルシステムを素早く操作できそうにないので、そこは今でもストレスを感じることがあります。

 

鹿野さん：TypeScriptがスラスラ書けるようになった以外に、EmacsからVSCodeに切り替えてよかったと感じることは何かありますか？

 

伊藤さん：いろいろなプログラミング言語を使い分けるときのスイッチングコストがすごく低くなったと感じています。
何が決定的な差なのか、まだよくわかっていないのですが、IDEが別の言語でわかっていない部分を上手くサポートしてくれて、それで認知負荷が下がるのかもしれません。

実際、仕事で複数の言語を使うので、この点はトータルで見ると大きいと思っています。

 

 

問題を型で考えるため、Haskellを学ぶ

 

 

鹿野さん：認知負荷については、前回のAtCoderさんとのインタビューでもメインテーマの1つでしたね。

変な言い方ですが、naoyaさんがプログラマーの定年のように言われがちな35歳を過ぎてから競技プログラミングやHaskellを本格的に始めて、しかも「認知負荷がなくなる」まで練習されているというのは、本当にすごいと思います。

 

伊藤さん：そこはやはり、過去のいろいろな伏線があってのことですね。

インタビューでも何度か触れましたが、オードリー・タンさんがHaskellでPerl 6を実装して手を出したけれど全然わからなかったとか、Haskellマスターの田中秀行さんに会ったときにレベルが違いすぎてショックだったとか、はてなの同僚だったmaoeさんからHaskellの面白さをずっと聞いていたとか。

そんな流れがあったので、自分にとってHaskellはすべてのプログラミング言語の頂点かもしれないというくらい憧れがありました。Haskellって、どこかそういうイメージがある言語じゃないですか？

職場の同僚に聞いてみたら『HaskellやLispは、「難しそうだけど使いこなせたらかっこいい」という枠の言語。ただ、「仕事ではなかなか使う機会がない」とも思うので、ラテン語みたいな感覚もある』と言ってました。

 

鹿野さん：ラテン語みたいというのは、言い得て妙だと思います。

日常的には使われないけれど現代の英語などへの影響が確実にあるように、HaskellやLispも業務で使われているさまざまなプログラミング言語に相当な影響がありますから。

実際、JavaScriptを設計したブンレンダン・アイクなんかは、もともとブラウザにScheme（Lispの方言のひとつ）を入れようと思っていたらしいです。

 

伊藤さん：私もその同僚も、プログラミングを本格的に始めたのは業界に入ってからなので、自分にとってプライマリーな言語は「仕事でシステムを作るために学んだ言語」なんですよね。

そこから次に学んでみる言語としてLispやHaskellのような関数型言語というのは、仕事で使う機会を見つけるのも難しいので、何かしら別の動機がないと手が伸びないとは思います。

どちらかというと「教養のため」といった動機になりそうですよね。手を延ばしてみても、「ちょっと書いてみる」以上には勉強を続けにくいのもあります。

 

鹿野さん：それでもnaoyaさんは、あえてHaskellに手を伸ばし、しかも競技プログラミングで使うというストロングスタイルをとったわけですね。

 

伊藤さん：そうですね。ある日突然「やろう」と決めて、その日からずっと書いています。

 

鹿野さん：たしかHaskellを始めた動機として、和田さんとの対談では、「雰囲気でTypeScriptの型を書いているのを脱したかった」といったことをおっしゃっていましたよね。そこで「ならばHaskellだ」となるのが、かなり面白いと思っていました。

uhyoさんの「TypeScriptの仕様を読み込む」という方向もすごいですが、まだストーリーとしては納得しやすかったです。

 

伊藤さん：TypeScriptの型システムはJavaScriptとの互換性を壊さないように設計された側面もあってか、結構ややこしい印象で、もう少しシンプルな型システムのほうに先に慣れることができたらいいんじゃないかと思いまして。Haskellは、言語のコア機能だけを見るとシンプルじゃないですか。

実を言うと、10年くらい前にも一度Haskellの勉強をしたことはあったんです。

そのときは、何か月間かずっとElixirとErlangを触っていて、他の関数型言語とも比べてみようと思ってHaskellもやりました。

ただ、当時はあくまでも遅延評価の関数型言語としてHaskellを捉えていた感じで、あまり型については意識していなかったんですよね。今のように型が大事だと考えるようになる以前のことですから。

 

鹿野さん：実際のところ、TypeScriptとHaskellでは採用されている型システムが異なりますが、「Haskellを使うことでいろいろな問題を型で考えるようになる」という傾向自体はすごくあると思います。

ところで、ElixirはともかくErlangもだいぶ独特な世界観の言語ですが、それらは仕事で使っていたのですか？

 

伊藤さん：その当時、ウェブアプリケーションのバックエンドがAPIサーバーとしての役割に徹するようになり始めていたんです。それよりも昔は、HTMLのレンダリングもUIもバックエンドのサーバーが全部担当していたんですが、「もうバックエンドはAPIに特化していいよ」となりつつあった時代です。

それで、「サーバーの仕事がAPIをさばくだけになるなら、従来とは別の、より適切な処理系があるのではないか」と考えて、いろいろ試していたんです。

1つの回答としてはNode.jsもあるわけですが、これはこれでシングルスレッドで運用が難しいところもある。もっと堅牢かつ安定的にたくさんのコネクションをさばける処理系はないかなと考えて行き着いたのがErlangとElixirで、それで何ができるかを探っていました。

ElixirやErlangの並行処理を支える軽量プロセスやアクターモデルはかなり面白いと思いましたが、残念ながら仕事で使う場面はありませんでした。

 

鹿野さん：そこまで調査をされて、それでも仕事でElixirやErlangを使うに至らなかった理由に、少し興味があります。

 

伊藤さん：ちょうどフリーランスから一休の社員になったころで、当時の会社が持っていた技術の延長線上で考えた結果、ErlangやElixirは採用できないなと思い至りました。自分の好みのシステムを押し付けるわけにもいきませんからね。

結局一休ではNode.js、Goという感じに使い分けるようになって、最近Rustを使うようになったのは過去のインタビューでもお話しした通りです。

 

 

年齢を重ねて勉強がしやすくなった

 

 

鹿野さん：それにしても、naoyaさんの話を伺っていると、どんどん新しいことを勉強したり練習したりし始めて、しかもそれを深堀りされますよね。

新しいことを始めるときって、いろいろ不安がありそうなものですが…。

 

伊藤さん：新しいことを始める不安ですか? 自分にはその感覚があまりないかもしれないですね。

 

鹿野さん：「これを新しく始めることで、自分が別のことに使える時間が減ってしまうが、大丈夫だろうか」といった不安はありませんか？

 

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

新しいことや特定のことに集中してエネルギーを注ぐという観点で言うと、年を取って感覚が麻痺してきたことが功を奏しているかもしれないと感じています。

昔だったら、たとえばフロントエンドの新しいフレームワークなんかが出ると「すぐに触ってみないとまずい」という感覚がすごく強くありました。

でも最近は、新しいものに対する感覚が鈍っているからか、「仕事で使う日がきたら、その場で調べて覚えられるだろう」くらいに割り切って考えられるようになっています。

「そのときそのときで大事だと思っていることや、興味があることに落ち着いて取り組んでいけば大丈夫。トレンドは、いずれキャッチアップできるだろう」ぐらいの感じですね。

 

鹿野さん：その感覚はわかる気がします。

 

伊藤さん：プログラマーって、年を取ることをネガティブに捉えがちですが、実際に中年になってみたら案外そうでもないなと思うことは多いです。

むしろ、年を取ることで「あれもやらなきゃこれもやらなきゃ」みたいな気持ちになりにくくなり、おかげで1つのことを続けるのがよくできるようになった面があると思います。

いまの自分が「Haskellでアルゴリズムをやる」という気持ちをシンプルに維持できているのも、そういうことかもしれないな、と。

 

鹿野さん：自分はそこまでは達観できていないです。
新しく難しいことを始めるたびに、「何かに挑戦した」という記憶だけしか残らず結局は身につかないのではないか、という不安がぬぐえません…。

 

伊藤さん：あと、これは個人的な生活習慣の話ですが、年を取って寝る時間がすごく早くなったのも若いころより好都合な点だと感じています。

最近は、家に帰ってご飯を食べると眠くなってしまって21時とか22時にはもう寝てしまう日が多いんです。そうすると明け方の3時とか4時には目が覚めるんですが、まだ家族も寝ているし、SlackやTwitterの流量もないから、プログラミングするくらいしかやることがない。
昨今はリモートワークで出勤もないですから、仕事が始まる9時とか10時まで、たっぷり5、6時間はプログラムに時間を割けるんです。

若いときは、朝4時に起きて1日の5、6時間をプログラミングに使うなんてことはできなかったから、これは年を重ねたことの効果としてすごく大きいと思っています。

 

鹿野さん：その話を聞いて、若いときに朝4時に起きて通勤までの時間を勉強に当てていたのを思い出しました。「SICPブーム」のころも、それでSICPの練習問題に一通り手を付けたんですよね。

今の自分にはもう同じことは無理です…。

 

伊藤さん：朝活としてSICPを読むのは、どちらかというとエネルギッシュで、たぶん若かったからできたことなんですよね。

今の自分は、もっと肩の荷が下りた状態というか、年を取って自然とそういう生活習慣になっただけという感じがしています。

「朝3時に起きて会社が始まるまでプログラミングしている」と言うと、めちゃくちゃ意識が高い人みたいに聞こえますが、全くそういうわけではなくて、早起きしてしまって、やることがないからパソコン開いてカタカタやってると言う感じです。

 

鹿野さん：逆に、寝る前に勉強することはないんですか？

 

伊藤さん：仕事から早く帰れて時間があるときもありますが、そういうときに難しい本を読もうとしても、もうまったく頭に入って来ませんね。これも多分年ですね。

朝起きた瞬間は頭が空っぽだから、いろいろな知識が入りやすいのかもしれません。

 

 

十数年前に欲しかった『プログラマーのためのCPU入門』

 

 

伊藤さん：先ほど『型システム入門』の話を少し伺いましたが、これは鹿野さんがオーム社にいた時代の本なので、ラムダノートを立ち上げてから出版された本についても少し話を聞かせてください。

先日、ラムダノートから出た『プログラマーのためのCPU入門』という本を読んだのですが、これが個人的にとても面白かったです。

 

鹿野さん：本の感想をもらえるのは本当に嬉しいです。
読むのに時間がかかる本ばかり出しているせいか、Twitterなどで「買った」という反応はけっこういただけるのですが、Amazonレビューを含めて書評などが少ないのが寂しくて。

この『プログラマーのためのCPU入門』も読み応えがある本なので、そういう不安があったのですが、発売直後からCPUを作っているような強い人たちからの好意的な反応がたくさんあり、すごく喜んでいます。

 

伊藤さん：この本のすごくいいところは、「あとがき」にもあるんですが、CPUの構造に基づく整理ではなく、ソフトウェアを遅くする要因に分解するという観点からCPUを解説している点だと思うんですよ。
これがかなり面白い。

 

鹿野さん：CPUの解説書には、すでに高く評価されている名著が数多くありますが、どうしてもCPUのハードウェア的な仕組みの説明が中心になるのですよね。

ハードウェアの基礎はもちろん重要ですが、ソフトウェアを書いているエンジニアからすると、その基礎的なハードウェアの仕組みの上で自分が書いたプログラムが高速に実行できている現実まで、かなりギャップもあると思います。これは、そのギャップを繋ぐ本なんですよね。

 

伊藤さん：「どういうことをしたら遅くなるのか」は、ソフトウェアを作っている人たちが知りたい文脈なので、まさにプログラマーのための解説だなと思いました。

とはいえ、自分のようなウェブアプリケーションエンジニアはもっとレイヤーが高いところでプログラムを書いているので、ここに書かれている最適化のテクニックのような内容については「コンパイラの仕事だな」とか思いながら読んでいました。

 

鹿野さん：そこはそういう読み方でいいと思います。

 

伊藤さん：あと、私は昔インフラの仕事をやっていたこともあるんですが、そのときにまさに知りたかった話も書かれていたんですよ。

 

鹿野さん：ツイートされていた話ですね。

 

伊藤さん：そうです。

十数年前にApacheを使っていたとき、トラフィックが大量にくるとCPUが過負荷になるので、対処療法的にマルチプロセスをマルチスレッドに変えたら負荷が下がったという経験をしたことがあったんです。

それで終わらせるのはよくないので調べようということになったのですが、マルチプロセスからマルチスレッドにしたら負荷が下がると言うことは、ユーザ空間ではなくカーネル空間でのコンテキストスイッチの話だろうなと思って、カーネルのソースコードを見たわけです。

しかし、カーネルの実装の世界ではマルチスレッドとマルチプロセスに大きな違いはなく、メモリ空間を切り替えるときに新しいポインターを作るか作らないかくらいの差しか読み取れませんでした。

 

鹿野さん：それで、何かが起こっているとしたらさらに下のレイヤーのCPUだろう、と。

 

伊藤さん：はい。どう考えてもCPUの世界で何かが起こっているんですよ。

ソフトウェアは読めるのでカーネルのレイヤーまでソースコードを追いかけることはできるけれど、そこから先のCPUの世界になると突然ブラックボックスでした。

当時もCPUのドキュメントをいろいろ漁って、「TLBにおけるキャッシュミスのコストが高いかもしれない」ぐらいの情報まではたどり着いたんですが、「CPUの世界ではどういう処理にどれくらいコストがかかるのか」に対する感覚があまりなかったので、TLBミスの影響がどれくらいかまでは突き止められませんでした。

 

鹿野さん：CPUのベンダーから出ているドキュメントはたくさんありすぎて、継続的に触れていないと知りたい情報になかなかたどり着けないですよね。

 

伊藤さん：しかも、Intelのドキュメントなんかを読んで、そこからTLBミスと分岐予測とでどっちの影響が大きいかといったことを読み解くには、いろいろな背景知識が必要なんですよね。

TLBミスという現象自体は理解できても、それがCPUのコストにとってどれくらい支配的かまでは読み取れない。それが、この本を読んだら、めちゃくちゃ高コストなんだということがわかりました。

しかも、もしかしたらマルチプロセスでページサイズを大きくするという手段でも問題が解決できたかもしれない、といった話まで書かれている。

 

鹿野さん：そういう観点で読んでもらえる人の手元に、この本が届いたのは、本当にうれしいです。

 

伊藤さん：インフラをやっている人たちの中には、最近もカーネルの中身を追いかけてOSの挙動を把握するのに努めている人たちがそこそこいるはずなので、そのような人たちにはかなり刺さりそうだと思いました。

著者の主観という断りがありつつも、CPUを作っているような人たちが持ち合わせている感覚について比較的に明確に日本語で書いてくれている本が読めるのは、相当に大きいことだと思います。

 

鹿野さん：実際のところ、英語圏にもヘネパタのような優れた教科書はいろいろありますが、こういう観点でCPUについて解説された本はほとんど見かけない気がします。

なので、本書の企画について著者であるTani Takenobuさんから最初に相談いただいたときは、かなり興奮しました。

 

伊藤さん：かなり特徴のある本ですが、著者の方からの持ち込みだったんですね。

 

鹿野さん：そうです。その時点で原稿もかなり書き進められていて、それをざっくり拝見してすぐに「これはぼくが読みたかった本だ」と思いました。

それで、当社の不定期刊行誌である「n月刊ラムダノート」にスタンドアローンの記事として掲載しつつ、一冊の書籍としても完成版を目指しましょう、とお返事しました。

 

伊藤さん：全編を通して、縦軸にCPUのステージを配したわかりやすい図も多いですが、こういう図は著者の方がご自身で描かれるんでしょうか？

 

鹿野さん：この本のほぼすべての図には、Taniさん自身がパワーポイントで描かれた下書きがあります。

CPUのマニュアルや教科書にもよく出てくるスタイルの図ではありますが、「分岐命令があったらこういう動きになるよ」といった観点でここまで丁寧に図説されることはあまりないと思うので、直感に対する良いサポートになっていますよね。

 

 

技術書の企画はどうやって始まるのか

 

伊藤さん：『プログラマーのためのCPU入門』は著者の方からの持ち込みとのことですが、逆に鹿野さんから「こういう本を書いてみませんか」と専門家に持ちかけることもあるのでしょうか？

 

鹿野さん：あります。

ただ最近は、読者が本に求める専門性が上がっていると感じていて、自分がふわっと考えたネタから著者を探すという機会は減りました。

自分がたまたま知っているフレームの中だけでネタを考えることには、どうしても限界があるんですよね。ネタを思いついても、「こんな本があったらいいな」とTwitterでつぶやいて終わり、みたいなケースが増えています。

 

伊藤さん：いま一休のエンジニアが読んでいるラムダノートの本に『検索システム』があるんですが、この本も著者からの持ち込みですか？

 

鹿野さん：検索システムの本は、著者の一人である打田さんが「現代の検索システムを扱うのに必要な知見が多すぎるので、それを一冊で把握できるような本が欲しい」という構想をGitHubで広く公開されたのが一番最初のきっかけでした。

そのリポジトリにスターがたくさん付いて、自分も最初は「実現したら面白そうな本になりそうだな」と他人事のように楽しみにしていたんです。

そうしたら、『Goならわかるシステムプログラミング』という本をうちで書かれている渋川さんが打田さんと知り合いで、渋川さん経由で自分のところにも話をいただいて、それでいろいろあって私が編集することになりました。

 

伊藤さん：自分も過去に本を書いたことはあるんですけれど、そのときは編集者の方から「こういう本を出すので、この章を担当していただけませんか」と打診される流れがほとんどでした。

 

鹿野さん：そのほうが一般的なケースだと思います。

自分も、駆け出しの編集者だったころはこちらからアクションするしかないので、昔は「ネタを想像して書いてもらえそうな人に相談する」のをよくやっていました。

 

伊藤さん：uhyoさんとの対談でも、「Qiitaに記事を投稿していたら出版社の方からJavaScriptの記事を書いてほしいと連絡をもらった」という話がありましたね。

やはり著者を探すとなると、そうしたウェブの記事などをあたる感じになるんですか？

 

鹿野さん：そういうことが多いと思います。

たとえばオーム社に入ったころに、「書店の数学書のコーナーとコンピューター書のコーナーの間を埋めるような本が必要だ」と考えて、『プログラミングのための線形代数』という本を企画したことがありました。

最終的には平岡さんという方に執筆をお願いできたのですが、そのときは平岡さんが学生向けにウェブで配布していた線形代数のプリントをたまたま見つけて、「こんなふうに説明してくれている線形代数の教科書、なかったじゃん！」と思ってメールでアクセスし、それから何年かして本として出版できました。

 

 

型への理解を深める本が欲しい

 

伊藤さん：実はいま、個人的にすごく欲しい本があるんですよ。

私のチームではTypeScriptを使っていて、型を中心に据えた設計で開発をしているのですが、そのためのメンタルモデルについて説明されているような本が欲しいんです。

 

鹿野さん：メンタルモデルというのは、開発の仕方に対するものですか？

 

伊藤さん：いや、プログラミングそのものに対するメンタルモデルです。

クラスベースのオブジェクト指向言語でずっとやってきた人の中には、「型は入力と出力を守ってくれるもの」、「関数はコンピューターに命令するための手続き」と認識している人もいます。

それに対し、ぼくは「型は集合みたいなもの」、「関数は集合から別の集合に写すもの」と認識しているので、会話をすると噛み合わないことがあるんです。

 

鹿野さん：どちらも根本的な概念としてはそんなに変わらないはずですが、噛み合わなくなってしまうんですね。

 

伊藤さん：たぶん、型や関数をどういう抽象度で捉えているかが違うんですよ。「オブジェクトの中に閉じ込められている状態を手続きで書き換える」というイメージを頭に描いている人と、「集合から集合へと写す関数で宣言的に状態を表現する」というイメージを頭に描いている自分とが、同じような用語を使って話していると、認識にずれが生じるんです。

それを毎回すり合わせるのは大変だから、「この本を読んで」と渡せるものがあると助かるんですよね。

 

鹿野さん：すり合わせのためのツールとして本が欲しいという話ですね。

和田さんとのインタビューでは“Domain Modeling Made Functional”という本が話題に出ていましたが、あの本だと違う感じですか？

 

伊藤さん：あの本の特徴は、「いわゆる業務システムのドメインモデルは代数的データ型で表現できる」という観点で書かれていることですね。

業務システムのエンティティは、「ある状態」から「ある状態」に変化するものなので、それぞれに適切な型を用意して組み合わせればロバストな設計になる、といった内容になっています。

とはいえ、基本的にはDDD（domain-driven design）がテーマなので、「プログラミング言語における代数的データ型をどう捉えるべきか」といった話にまでは踏み込まれていません。

 

鹿野さん：なるほど。あの本については、実は何年か前にTwitterで教えてもらったことがあり、そのときにサンプル公開されている章を眺めたりはしていたんですが、そこまでは読み取れていませんでした。

 

伊藤さん：DDDでなく代数的データ型など、アプリケーション開発のための型入門を主題にしたコンパクトな本があると、もしかすると、TypeScriptのような言語でのみんなのプログラミングレベルが一気に上がるんじゃないかなって思うので、誰か識者の方に書いていただけないかなあと。

 

鹿野さん：そのときに必要な本は、まさに『型システム入門』かもしれません。

代数的データ型をベースとして、クラスやインターフェースといった仕組みを実際に作っていく本なので、一通り読むと両者が表裏一体なことがなんとなくわかると思います。

たとえば、いわゆるデザインパターンには「インターフェースを切ることで解決する」系のものがいくつかありますよね。『型システム入門』を読むと、それらは代数的データ型がある言語ならそもそも不要なテクニックではないだろうか、みたいな疑問がわくようになる気がします。

もちろん、これはぼく個人の感想で、本書に理論的な答えが書いてあるわけではない素朴な疑問にすぎないのですが。

 

伊藤さん：実際、そういったケースはあると思います。ちなみにTypeScriptで代数的データ型を表現するときも、結局はインターフェースを使います。

 

鹿野さん：そうだったんですね。ずっともやもや疑問に感じていたことに対する1つの答えが得られて嬉しいです。

 

伊藤さん：まさに鹿野さんがなんとなく疑問に感じていたようなことを、自分も半年ぐらい前まで同じように感じていて、その答え合わせをuhyoさんとのインタビューでしていたんですよね。

いまはみんな、こういう具合に人と話をしたりしながら、答え合わせをしている最中なんだと思います。そういう答え合わせのヒントになるような本があると、けっこう嬉しい人が多いのかなと。

 

鹿野さん：本として「これが答えだよ」って言うには、しっかりした説得力を持たせるのが難しい話かもしれません。個人のお気持ちで書かれた本だと後世に遺恨を残してしまうので…。

もちろん、説得力を持たせる手段は『型システム入門』のように数学的な証明でなければならないわけでなく、実務を通して得られる十分な傍証でもいいと思います。

 

伊藤さん：TypeScriptから型がある言語に何となく入りましたというエンジニアは、自分を含めて少なくないのですが、どうしても雰囲気で型を書いている面があります。
基本がわかっていないので、いまはまだ「型とは何か、何ができるか」を理解して訓練し始めた段階にあるような気がしています。

uhyoさんとのインタビューでも、「TypeScriptには代数型があり、unionという仕組みもあるんだから、余計な状態を作ることなく、今までnullで表現していたことをよりロバストに書ける」といった話をしたわけですが、「クラスでこう表現していたことは、こういう型で表現できて、この状況ではこっちのほうがいい」みたいな話をもっと知りたいんですよね。

 

鹿野さん：なるほど。型で何ができるかを突き詰めたい、という感じですね。naoyaさんがいまHaskellをやっている話にも繋がってきそうですね。

 

伊藤さん：HaskellとTypeScriptでは型システムも違うので、Haskellの話がそのまま通じるわけではないし、TypeScriptなら別のやり方のほうがいいケースもあると考えていますが、そういう概念的な違いをきちんと説明できたうえで使いこなせるところを目指したいんですよね。

 

 

業務システム開発の世界は必ずしもうまくいっていない？

 

 

鹿野さん：“Domain Modeling Made Functional”は型の本というよりもDDDの本という話がありましたが、アプローチがオブジェクト指向から関数型プログラミングになっても、引き続きDDDという枠組みは有効なんですね。

 

伊藤さん：はい、そう思います。

DDDは、一時期は加熱しすぎている面もありましたが、「ドメインモデルを考えることでより深く業務を理解しよう」、「問題解決のモデルとプログラミングのモデルを乖離させないようにしよう」といった基本的な考え方は便利に使えると思いますし、それは特定のプログラミングパラダイムに依存している話ではないと思います。

 

鹿野さん：現場ではDDDをどう使っているのでしょうか。やはり開発会議のような場で分析のためのプラクティスを実践しながらドメインモデルを検討していく感じなのですか？

 

伊藤さん：会議室にみんなで集まって付箋を使いながらユースケース分析などをやっているチームもあると思いますが、我々は違っていて、比較的テックリードが引っ張っていく感じです。

重要なのはそういうプラクティスを実践することではないと考えていて、欲しいのはドメインモデル、もっと言えばそのドメインモデルに対する各開発者のメンタルモデルです。それが得られるならプラクティスは何でも良いと考えています。

結果、ある程度わかっている人が周りを巻き込んで作っていく感じで進めるようになっていますね。

 

鹿野さん：問題とそれに対する実装を整理するためのフレームワークとして使っている感じですね。

 

伊藤さん：そうですね。

実装に関して言うと、DDDでは「業務システムの比較的大きめのモデルを扱って、そこで更新処理をまとめて実行することにより、不変条件を維持する」というのを目指しているわけですが、この考え方は現実のシステムで有用なんですよ。

たとえば、一休ではレストランやホテルの予約を扱っていますが、予約の更新には決済の状況やクーポンの有無、空き部屋の有無など、いろいろな状態が関与してきます。
それらが一貫したルールに基づいて更新される必要があるわけですが、複数のプログラムやバッチ処理なんかがばらばらにデータベースを更新してしまうと、制約が保てなくなって大変です。

実際、昔のシステムではあちこちから更新が飛んできて想定外の不具合が頻発するようなこともありました。データベースに入っているデータが、業務要件的に正しいことが保証できてない状況ができてしまうわけですから。

 

鹿野さん：アトミックに扱うには、何か大きなクラスを1つ作るのですか？

 

伊藤さん：DDDではそれを集約と呼びますね。

例えば一番外側の「予約」に相当するエンティティの中に、料金計算や在庫という子エンティティなどが集められて構造化されているイメージです。
何かしらの業務を行って状態を変更するときはこの「予約モデル」を使うようにする。

そして予約モデルは、予約モデル単位、つまりそこに含まれる子エンティティまで含めて必ずまとめて保存します。
集約は大きすぎても小さくても問題なので、適切な境界をどう見つけるか、などにドメインモデリングがかかわってきます。

DDDの本には、こういう経験的にも「こうしたほうがいい」ことが明らかなやり方が書いてあって、それを意識的に実践するうえで単純に便利なことがあります。
和田さんの回でも話した通り、今となっては古くなってしまったことや、現代のシステムを前提としていないことを含めいろんなことも書いています。

その辺りは引き算しつつ、「やらなくてもいいことは別にやらなくていいか」ぐらいのところに着地しているのが現状だと思います。

 

鹿野さん：それをF#という言語が備える機能を活かしてやる方法が、“Domain Modeling Made Functional”には書かれているわけですね。

 

伊藤さん：そうです。ただ、私がこの本に注目したのは、DDDを関数型プログラミングでやりたかったからではないんですよ。

 

鹿野さん：なるほど、DDDの本として手に取ったわけではない。

 

伊藤さん：はい。前提を掘り下げると、そもそも気になっているのは、サーバーサイドの業務システム開発のありようがここ10年くらいあまり変わっていなかったことなんです。

 

鹿野さん：あまり進化していないのは、サーバサイドの側だけなんですか？

 

伊藤さん：フロントエンドについては、ここ10年で大きく変化がありましたよね。

JavaScriptや、せいぜいCoffeeScriptを書いていた時代から、ReactやVueが出てきて、TypeScriptも普及して、みんなが宣言的プログラミングを実践するようになった。それに伴ってスタイルも大きく変化しています。

 

鹿野さん：サーバサイドも、言語のトレンドだけを見ている限りではScalaやGoの登場で進化しているように思っていましたが、そうでもないんですね。

 

伊藤さん：はい、少なくともフロントエンド開発ほどの変化はなかったと思います。使う言語は進化していて、明らかに新しい機能はあるんです。

でも、バックエンド開発では変わらずクラスベースのオブジェクト指向でやることも多いので、「このままでいいんだろうか」みたいな気持ちがふつふつと湧いていました。

それですべてがうまくいっているなら特に疑問を持つこともなかったんでしょうけど、100%満足できる状況にはほど遠いという感覚はずっとありまして。この本を読んでみたのも、そういう文脈からでした。

 

鹿野さん：それに対する答えやヒントは本から得られたのでしょうか？

 

伊藤さん：そこでエポックメイキングだと感じたのが、やはり新しいプログラミング言語の機能に合わせて「型を設計の中心に置く」という点でした。

私たちの従来のやり方とは違って、クラスではなく型でドメインモデルを表現している。これを中心的な考え方に据えることで、サーバサイドの開発スタイルが少し変わるかもしれないなと思って、現在進行形でいろいろ試しているところです。

 

鹿野さん：サーバサイドの開発スタイルがここ十数年であまり変わっていなかったというのは、個人的には意外な話で、とても興味深いです。

それは業界で共通認識になっているのでしょうか？　それとも、naoyaさんが抱いている危機感ですか？

 

伊藤さん：共通認識にまではなっていないと思います。

というのも、業務システム開発の世界がまったくうまく行っていないわけではなく、従来のやり方でも70点ぐらいは取れていると思うんですよね。

でも、100点にはまだ距離があるわけです。
実際、数年運用していると設計が崩れてきて仕方なく作り直すというのを繰り返しています。だから従来のスタイルがベストではないんだろうなあと。

それにプログラミング言語自体は進化しているわけですから、作り方が変わらないのはおかしな話しです。

 

鹿野さん：一方で、フロントエンドはこの間に大きく進化したという話もありました。フロントエンドが進化できたのはなぜなのでしょうか？

 

伊藤さん：フロントエンドは、もともとのやり方が原始的すぎたので、変化に対する動機が十分にあったのだと思います。
DOMに状態を埋め込むような方法で作っていて、みんな「これ、大きくなったら大変だけど、どうするんだろう」と悶々としていました。

 

鹿野さん：jQueryなんかも、出た当初は画期的でしたが、現場ではわりと悶々としていたんですね。

 

伊藤さん：最初はよかったんですよ。jQueryもちょっと使うだけなら便利なんです。

でも、大きくなるとアプリケーションの状態を管理しきれなくなってメンテナンスが難しくなってしまう。
巨大な泥団子ができあがってしまい、「いやこんなはずじゃなかったんだけど…」となるわけです。

 

鹿野さん：泥団子にならなくても、ソフトウェアは当然のようにどんどん作り変えていきますが、世間的にはそうじゃないですよね。
「なんでITのエンジニアは作っては壊し作っては壊しやっているんだ」と思っている人も少なくないと感じています。

 

伊藤さん：自分たちでさえ「ソフトウェアってこんなに作り変えるものなんだな」と思ってますからね。

いま一休で作り直しているシステムも、6、7年前に一回作り変えたものなので、さすがにもう少し持たせたかったという話はしています。

 

鹿野さん：そういうものなのですね。

 

伊藤さん：このことを考えるとき、いつも思うんです。人間には根源的に「永遠に続くもの」を渇望する欲望があるけど、この願望はきっと叶うことのない願望なのだろうな、と。

ソフトウェアにしても、一度作ったら完璧で二度と変更しなくてもいい最高のツールになってほしいけれど、現実にはこんなに頻繁に作り変えている。自分が作ったものをできるだけ壊さずに長く使いたいけれど、永遠に存在するものは多分世の中になくて、ずっと使うには作り変えていくしかない。

 

鹿野さん：ソフトウェアは特にそうですよね。

 

伊藤さん：きっと書籍もそうですよね。
物理的な形があって、永遠に存在するものであってほしいという願望はあるけれど、読み継がれていくためには時代にあわせて作り変えていく必要があるのではないかと。

 

鹿野さん：それは本当にそうだと思います。

 

 

究極や原理をゆっくりでも突き詰めよう

 

 

鹿野さん：こうして話を伺っていると、最近naoyaさんが理想のキーボード追及にのめりこんでいるのも妙に納得できる気がしてきました。

常に「今よりもいいものがあるんじゃないか」という気持ちがすごくあるんですね。システムにしろキーボードにしろ、究極を目指したい。

 

伊藤さん：どうやら、そういう性格らしいです。
性格診断的には「最上志向」というみたいですね。自分はその性質が他の人よりも強いみたいです。

 

鹿野さん：キーボードにはまっている人たちの間には、自分の理想のキーボードにたどり着くことを指して「エンドゲーム」と表現する文化がありますが、きっと業務システム開発でもエンドゲームを目指されているのだろうな、という印象を受けました。

 

伊藤さん：キーボードについては、さすがにどこかに終わりはあるはずだと信じているんですけどね。キーボードに関しては鹿野さんもかなりはまっていますよね。

 

鹿野さん：はい。実は今日、いつも使っているキーボードをnaoyaさんに見せびらかしたくて、予備機を1台持ってきました。

 

伊藤さん：おお、これはすごい。絶対に市販されてないやつですよね。
明らかにキーの数が少なくて、数字も記号もCtrlキーとかもないんですが、一体どうやって使っているんですか？

 

鹿野さん：ほとんどのキーには、アルファベットを入力する以外にも何かしら特殊な役割があって、それらを押しながら別のキーを打鍵することで全キーが入力できるようになっています。

 

伊藤さん：その特殊なキーとの組み合わせは、自分で考えてプログラムしているんですよね。

 

鹿野さん：QMKというファームウェア開発のためのフレームワークがあるので、自分でゼロから制御を書く必要はないですが、どういう組み合わせにするか、単キーの入力でなく組み合わせとして認識されるタイミングを何秒にするか、そういうのは自分で考えて設定しています。
それを意識せずに使えるようになるまで使い続けて慣れる感じです。

 

伊藤さん：自分で考えたキー配列に、自分自身を最適化していくわけですね。

少し前の自分だったら、「そんな大変なことを、なぜ…」としか思わなかったと思います。

でも、いまちょうど45年間使い続けてきたJISキーボードからUSキーボードに切り替える訓練をしていることもあって、「なるほど、やればできそうだ」という気持ちです。

 

鹿野さん：実際、このキーボードを使うための特別な練習とかをしているわけでもなく、使っているうちに慣れてしまうだけなんですよ。

正直なところ、身体で覚えてしまっているので、どの組み合わせが通常のキーボードのどのキーに相当するかを聞かれても答えられないです。

 

伊藤さん：EmacsからVSCodeに移行する話もそうなんですが、基本的には脳みその回路を組み替える作業をしているだけなんですよね。
組み替えた回路が出来上がったら、そこに認知エネルギーを割かなくてもよくなるので、難しいとは感じなくなる。やっていることが難しいかどうかではないんですよね。

 

鹿野さん：まさに、AtCoderさんのインタビューのときの話ですね。

 

伊藤さん：はい。

最近では、あらゆることについて、「難しいと思っていることに自分の脳をいかに慣れさせるかどうか」なんだろうと考えています。慣れるまでのコストはものによって違うけれど、ことキーボードについては、われわれは使っている時間が圧倒的に長いので、慣れますよね。

『型システム入門』も、いまなら頑張って読めば読めるだろうなって気持ちになっています。

 

鹿野さん：読むだけなら、自分でも読めるくらいなんで、絶対に読めますよ。

 

伊藤さん：でも、おそらくなんですが、若いころのほうが脳の回路や配線を切り替えたるのにかかる時間は少なくて済むはずなんですよね。
なので若いうちにこの辺の知識にもっと触れておきたかったという気持ちも、ないではないです。

 

鹿野さん：わかります。

その一方で、年をとってようやく素直にいろいろな勉強ができるようになったな、とも思います。

少なくとも自分は、若いころのほうが意固地で、新しいことにトライできなかった自覚があるんですよ。もしかすると、単に知っている世界が広がったので「たぶんこんな感じだろう」くらいの類推で知らないことに鈍感に手を出せるようになっただけかもしれませんが。

あと、さきほどnaoyaさん自身もおっしゃっていたことですが、歳を取ったことで若いときほど「すぐに成果を出さなきゃいけない」という焦りがなくなったのも確実にあると思います。

 

伊藤さん：それは全然、感じなくなりましたよね。

 

鹿野さん：このキーボードにしても、「小さいキーボードがほしい」くらいの軽い気持ちで基板を手にしてから最初の1つを作り始めるまで、2年くらいかかっているんですよ。

というのも、これは制御にArduinoを使っているんですが、単なるUSBキーボードなので原理的にArduinoが必須なはずがないんですよね。
そんなことを考え始めたら、そもそもUSBキーボードをPCに繋いだときに何が起きてるのかが不思議になって、それでUSBのプログラミングやマイコンの仕組みの勉強から始めちゃったんです。
それをのんびりやっていたら2年くらい経ってしまいました。

 

伊藤さん：それを知らなくても、作って使うことはできるわけですよね。若いときだと、それこそ手に入れてすぐに使いたいから、原理を知るのに2年もかけていられないですよね。

 

鹿野さん：まさに若いときはそんな感じだったと思います。
こうやってゆっくり勉強できるようになったのって、少なくともぼくは、それなりに歳をとってからなんですよ。

 

伊藤さん：歳をとってもなお、プログラムを書く人には生き方があるということなんですよね。本当にいい話だと思います。

 

この記事では、ラムダノートの鹿野桂一郎さんと伊藤直也さんによる対談をお届けしました。
過去4回の対談で伊藤さんの念頭にはどのような業界に対する問題意識や個人としての課題設定があったのか。
文章化のために生録音を聞きこんだ鹿野さん相手だったからこそ、改めて明確に言語化された要素がたくさんあったのではないでしょうか。

 

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

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

 

 

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