Rubyist Hotlinksにインスパイアされて始まったRubyistめぐり。第1回は高橋征義さんをゲストに迎えて、お話を聞きました。こちらは後編です。前編はこちら。
Rubyが他の言語に与えた影響
藤村：第2部、高橋さんについて聞いてみようと思います。今更ながらRubyについて聞きたいんですけど、好きな機能とかありますか？
高橋：好きな機能ですか？あんまり機能としてこれというのなくて、全体的に使い勝手がいいですね。まあでも、そういう意味でいえばオープンクラスの方がいいんじゃないの？みたいな感じがしますね。オープンクラスじゃないRubyはつらそうだって。
藤村：確かに。
高橋：つらそうというかつまらなさそうですね。オープンクラスが原因でつらいことになるのはわかるんですけど、でもあれがないんだったら他の言語でもいいよね、って。
藤村：Rubyがああじゃなかったら他の言語は今のようになってなかったかもしれないですよね。Rubyがオープンクラスでつらいというのを踏まえた上で、TypeScriptが流行ったみたいな…そういうものでもないか。
高橋：Rubyのおかげで流行ったのはBundlerの仕組みが導入されたこと。あれは他の言語にもなかったはずです。パッケージマネージャはOS単位のもので、1つのOSに対して、その中で1つのパッケージの置き場所があって、そこに各パッケージを置きましょうとなっていた。それに対してアプリ単位でディレクトリを用意してそこにbundleするという流れができたのはBundler以降だと思うので、あれは大きかったんじゃないかと。RubyGemsはそれ以前にPerlのCPANとかがあったので、新しいものではなかったですよね。
藤村：Bundlerって最初に作ったのは誰でしたっけ？ wycatsですよね。なんか突然出てきて一発で流行りましたよね。
高橋：流行りましたよね。でもやっぱり容量を食うわけですよ。その頃はみんなディスクもメモリも少なくて貧乏だったので、あんなに富豪的にバカスカインストールするのはどうなんだ、みたいな感じもあったし。OSをやってる人たち*1にはあんなに無秩序にユーザーランドに突っ込むのはいかがなものかと言われることもありました。
藤村：Bundlerも2010年代？ですよね。Rails3の時ぐらい。
高橋：もしかしたら2000年代だったかもしれないけど*2、その頃だと思いますよ。
藤村：Rubyが他の言語に与えた影響で一番大きいもののひとつって感じですよね。
高橋：あとはRSpecでしょうね。RSpecはRubyだとまだいいんだけど、Ruby以外の言語でRSpecを真似してたら大体読みづらい感じがします。みんな真似しない方がよかったんじゃないでしょうか。
藤村：どの言語にも大体RSpec Cloneがありますもんね。さっきも話したんですけど、Haskellにすらありますからね。
高橋：つらそうですよね、他の言語のRSpecっぽいボキャブラリを無理やり使ったやつは。
藤村：どうなんだろうな。僕はユニットテストを書くのは、RSpecで書くのが一番多かったので、他の言語でもRSpec-ishなやつを使っちゃうんですよ。assertって書いてもいいんだけど、みたいな感じでもういっかーみたいな。
高橋：assertとかのボキャブラリでもよかったんじゃないのかなと思う時は今でもあります。
藤村：それはそうですね。僕もいろんな思いがあるというか…。RSpecはいろんな弊害というか、やらかした設計があったのかな。
高橋：Ruby以外に与えた影響、ネガティブな影響が大きかったかも。
藤村：Rubyが他の言語に与えた影響みたいなの、Rubyをやっている我々が喋るのは難しいなという気持ちもありつつ、でもたしかにBundlerはそうかもしれないですよね。
高橋：初期にRubyをやっていた、2000年ぐらいまでにRubyをやっていた人たちは、大体Ruby以外の言語にそこそこ詳しかったんですよ。なので、ある程度他の言語の話もできる人たちが多かったですね。
藤村：2000年代のオブジェクト指向界隈の熱量を受けて、Railsができたわけですけど、今のRailsをレール通りに作ると、オブジェクト指向設計的には物足りなくてディレクトリを増やしたり、RailsでDDDをやりたいみたいな話が出ているわけじゃないですか。ああいうのを高橋さんがどう見ているのか聞いてみたい。
高橋：言いたいことはいっぱいあるんですけど…RailsのActiveRecordの話をすると、Railsが出た当時のオブジェクト指向が好きな人たちは、オブジェクトをそのまま保存したかったんじゃないかと思うんですよ。PoEAAとかを読むと、なんだかんだ言って、オブジェクト指向データベース（OODB）がそのうち流行る、いつか来るはずで、それが来た時にはOODBを使えばいいんだけれど、それまではRDBで頑張りましょう、あるいはRDBでOODBっぽいことを頑張りましょうみたいな感じだったように見えるんですよね。けど、Railsはそうじゃないですよね。
Railsは基本的にRDBは大変良いものなので、それをそのまま使いましょう。RDBのデータ設計、データモデルっていうのは素晴らしいものなので、それに則ってオブジェクトもモデリングすればいいという発想で、そうすると自動的にアクティブレコードパターンになるっていう。それはオブジェクト指向の人たち、特にオブジェクトのモデリングが好きな人たちの中では異端だったと思うんですよ。だけど、我々にとってはそれが正解だったのかなと。少なくともそういう解があり、それを選んだおかげでRailsは今でも生き残っている。
RailsってStruts*3と大体同じような年代にできたフレームワークなんですよ。今Strutsを使ってる人はどのくらいいるんでしょうか。最近Struts6.1がリリースされていてびっくりしたんですけど、Apacheが一応メンテしててリリースも続いている。でも、新規で使う話は聞かないじゃないですか。それに比べるとRailsはめちゃくちゃ長生きしてると思ってて。なんだけど、昔のその時代に「StrutsとRails、どっちが長生きしますか？」って言われると、きっと笑われましたよね。Railsが生きてるわけないだろ、どういう神経でStrutsよりもRailsが生き残ると思ってるの？って感じだったわけで。Railsが生き残っているのはActiveRecordを選択し、それが便利になるよう実装できたからっていうのはすごいあると思います。
藤村：ここにいるみなさんにも聞いてみたいんですけど、2000年代のオブジェクト指向を見てきた人からすると、RDBMSが透けて見えるからこそRailsのActiveRecordはこれじゃないというか、言われていたActiveRecordは違うなみたいな感覚があるんですか？
高橋：RDBMSが透けてみえてはいけない、モデルはモデルでRDBに引っ張られずにモデリングするべきというか。もっとも、PoEAAのアクティブレコードパターンはRailsのActiveRecordよりももっとしょぼいやつで、あんまり似てないんですよね。アソシエーションとかも持ってない、本当にデータベースのレコードに毛の生えたようなオブジェクトを作って、そこにロジックを置きたいときに使える、置けなくはないけど微妙だよねという雰囲気でアクティブレコードパターンが紹介されているので。DHHはでもそれがいいんだ、微妙じゃないんだみたいな感じで開き直って、そこにあれもこれもと機能をくっつけていった感じですよね。
Railsで成功するにはデータベース設計をちゃんとやる
藤村：高橋さんはRailsをどんなふうに作るのかを聞いてみたいんですけど、いろいろな流派があるじゃないですか。どういうスタイルでRailsは作るのがいいと思っていますか？
高橋：あんまり独自のもの、変わったものは使わないんですが、ActiveRecordにごちゃごちゃ書かないっていうことが『Sustainable Web Development with Ruby on Rails』に書かれてて、理由を見てなるほどねと思いました。サービスクラスというか、ただのPOROみたいな言い方をするかわからないですけれど、別のクラスを作ってそこに置くのもありかなと思いますけど、普通のRailsでできるだけ頑張りたいって感じですね。
藤村：RailsとかRubyのベテランの人に聞くと、こういう答えが返ってくるっていうのがよくあるパターンかな。
高橋：あとはgemに切り出すのがいいんじゃないですかね、変にレイヤーを作るよりは。gemってよくできると思うんですよ。gemの単位に何かの機能を閉じ込めるっていうのは。
藤村：あんまりでも、Railsアプリを作っている時にgemに切り出すって、そんなに今やられている感じもしないです。
高橋：どうなんでしょうね。gemのメンテがめんどくさいんですかね。
藤村：そうかもしれないですね。libの中にいろいろ、いろんな他のものに依存してるんだけど、libっていう名前で入れちゃうみたいなので、お茶を濁すパターンが自分の場合もほとんどだったなっていう気はする。
高橋：そうするとlibの中にいろいろ混ざりあってしまってつらくなるっていうのがよくあって、そうなりがちなのもわかるので、それならgemにわかれていた方がまだマシでは？というか。
藤村：確かになあ。
高橋：独自のライブラリ管理の仕組みを作るよりは、gemを使った方がいいのではと思いますね。あと、私が触っているものでRails エンジンを使っているやつがあるんですけど、エンジンはやばいですね。
藤村：やばい？良くないですか？
高橋：いやー、大変です。
藤村：どこら辺がエンジンはつらい？
高橋：いろいろとしみ出してきたりとか。あと、今時のフロントエンドと組み合わせると地獄になるんですよ。
藤村：なるほど。エンジンとフロントエンドでどうなっちゃうんですか？
高橋：エンジンから見えていいやつ、見えちゃいけないやつをどう隠すかみたいな話になり、そのアプリ側でエンジンを上書きしてみたいな感じのつらい話になり、いかにもぶっ壊れそうになるじゃないですか。壊れるんですよ。
藤村：なるほどな。Djangoってやられたことあります？
高橋：ないです。
藤村：Djangoって、エンジンありきみたいな設計になっているんですね、ある種。
高橋：なんと。Railsのエンジンとはちょっと違うんじゃないかと感じますが…。
藤村：違うと思います。Djangoを最初触った時、全部エンジンだ、みたいな気持ちになりましたね。
高橋：もうちょっとわけやすい仕組みにしといた方が。
藤村：もうちょっとわけやすかったです。
高橋：Railsのエンジンはそこがつらい感じになる気がしますね…。
藤村：Rubyでソフトウェアを作る上での様々なエコシステムで、他に高橋さんがつらいと感じるところってありますか？
高橋：あんまりこれっていうのはなくて、Railsがつらいというよりも、ソフトウェアがつらいみたいな。
藤村：確かに。
高橋：あとデータベースがつらいとか。なんですけど、Railsとデータベースの話で言うと、Railsはデータベースが密結合になっているじゃないですか。あれは良し悪しではあるんだけれど、Railsはそれでいいような気がしています。というのは、Railsをうまく使いこなすにはデータベース設計ができないといけないわけですよ。それってプログラマに要求するスキル的にもすごいハードル高いじゃないですか。ハードルが高いんだけれど、データベース設計をみんなでできるようになりましょうという圧力がかかるのはすごい大事なことで。
データベースを設計する人とアプリを書く人がわかれると、絶対うまくいかないと思うんですよね。という意味では、Railsの方向性は大変だけど、間違ってはいないのかなという感じはしますね。
藤村：結局Rails以降というか、オブジェクトデータベースが話題だった時期から、今はもうRDBを裏側にしたシステムをウェブで動かすっていうのが、いろんなものを作る上ではデファクトスタンダードになったってことなんですかね。
高橋：ですよね。クラウドの時代になって、RDBもなくなるかなとか思ったんですけど、なかなかなくならないじゃないですか。
藤村：そう思いたかったんですけど、MongoDBがうちの会社では動いてっていうのはあったりもします。
高橋：なので、NoSQL、例えばDynamoDBとかも使うところは使うんだけれど、やはりRDBが、最近ではNewSQLにもなったりしながら、クラウド時代でも生き残って頑張っている。これは素晴らしいと思っています。
藤村：そうですよね。SQLだけはまだ生き残り続けている。
高橋：この辺りは基本的な仕組みは1990年代とほとんど変わってない。
藤村：そうですよね。
高橋：30年経っても全然オワコンにならないわけですよ。あれはすごい。
藤村：なんであんなにうまくいったんだろうって、僕も不思議に思いながら本とかを読んでますね。
高橋：ですよね。で、Railsはそこに乗っかっているので、今でもまだ勝てている。
藤村：Railsで成功するにはデータベース設計をまじでちゃんとやるっていう。
高橋：そこなんじゃないですかねー。もちろん、開発が進むにつれて設計や仕様も変わっていくわけで、そこが変わったら扱いたいデータとデータベースのテーブルも異なってくるんですが、そういう時には泣きながらマイグレーションを頑張るしかないですよね。
藤村：マイグレーションでデータベースを変えたら、テストが落ちるから直せるみたいな。あれは強いですよね。
高橋：本当はデータベースをいじるのはつらいので、もう一層かませる感じにどうしてもなると思うんですけど、でもデータベースとのずれを直さず一層かます方がつらくなると思うんですよ。どこかで。
藤村：確かに。
高橋：アプリを作る人とデータベースの設計をする人が分かれると、データベースはアプリの人の責任ではなくなってしまいますが、でも自分の責任ではないですってアプリの人が言い出したら負けだと思うんですよ。Railsのいいところは、どうやってもデータベースをいじる権限をアプリの開発者が握る、プログラマが責任を持つっていう、そこにあると思っています。
藤村：昔はそうじゃなかったってことですよね。
高橋：そうですよね。データベースアドミニストレーター（DBA）様が君臨しているので、DBAの許可なしにカラムを追加したいですとかやっていると、めちゃめちゃ怒られる。
藤村：お客様の中でDBAと仕事をしたことある方はどのくらいいらっしゃるんでしょうか？
（数名 手を挙げる）
ogijun：触らせてもらえないですね、プログラマは。
高橋：DevOpsのよくある話と同じで、DevとOpsが分かれているとつらいことにしかならない。
角谷：インフラとかもそうだったじゃないですか、あれと同じ感じで、依頼しないと変更できない。
ogijun：めちゃくちゃ高かった*4から、そんなに多くの人は触れない。
藤村：データベースの変更を、今のRailsやっている人に依頼されたら「自分でRails Guidesを読んで」ってなりますもんね。
okuramasafumi：Railsのマイグレーションって1.0からあったんですか？
高橋：あれいつからでしたっけ…？でもだいぶ初期から。
角谷：ほぼ最初からありましたよ。当時の我々はマイグレーションのことはマーティン・ファウラーのシグネチャーシリーズの『Refactoring Databases』*5で学んだりしていた頃で、「うん、これはよくできてるな」と思ったものですよ。
高橋：いやー、でも「よくできてるな」と思っても「これはつらすぎるから…本番環境でやるの大変だろ」みたいな感じじゃなかったですか、正直。
ogijun：あれはDHHじゃないんですよね。
藤村：へぇー。
ogijun：最初、なんか3桁の連番で、1000個くらいしか作る必要がなかった。DHHはMySQLをGUIで直接操作してる。
藤村：(笑) マイグレーションも、Rails、Rubyの大きなエコシステムに影響を与えたやつかもしれないですよね。
高橋：本当にあれは大事だと思いますよ。データベースをちゃんと直す、手入れするっていう。めちゃめちゃ大変ですけどね。
藤村：まあそうですね、マイグレーション…。
高橋：すごいおっかない。
藤村：失敗もしますしね。みなさん、マイグレーション失敗Kaigiをやれるぐらい、いっぱい持ちネタがあるんじゃないかっていう気もする。
高橋：怖くてもやることが大事なので、怖いからやらないっていうふうになったらもうダメみたいな感じはしますよね。いや怖いけど。
Railsは同じように作ることがよしとされている
藤村：確かになあ。ちょっと話は変わるような戻るような感じなんですけど、2000年代のオジェクト指向設計の話からRailsが出てきて、結局データベース設計とデータベースを触わるのが重要というところを踏まえて、2023年の今、他の言語ではRailsじゃないわけじゃないですか、バックエンドシステムって。で、GoだとLayered Architectureを使ったりしている感じじゃないですか。そういうのってRubyとずっと関わってきた高橋さんからすると、どういうふうな印象を持たれてるんですか？
高橋：Goはよく知らないんですが、Goって自社でもりもり作れる体制がないとつらいんではないのかなという印象はあります。私が御社を手伝わせてもらっているように、サービス全体はよくわからないけどRails開発でお手伝いしますねみたいな感じで、Goのアプリケーションを触るにはちょっとハードルが高そうというか。そこで作られているアプリのコードを頑張って読み込まないと、そのアプリのお作法がよくわからんという感じになりやすいというのがあります。
藤村：Railsはそうですよね。大体同じように作られているから。
高橋：同じように作るのがまあまあ良いことで、あんまり突飛なことはしない方がいいという前提がありますよね。みんなつらい目に合ってきたので、あんまり変なことをやるとろくなことにならないと学習してきたので。
藤村：そこまでの強固なある種、レールというかコンベンションみたいなのを維持し続けられている他の開発手法って意外とないですもんね。
高橋：Goを使いこなしているところはたくさんコード書いてる人がいるのか、すごくもりもり書ける人がいるのかもと想像しています。逆にRailsだとたくさん人がいて同じアプリをみんなが同時にいじってるとつらいみたいな話は、正直それはそうかもと思うので。
藤村：確かになあ。それぞれの形をちゃんと理解してやらないといけないみたいな。
高橋：開発体制によるのかなって。それでいくとRailsのアプリケーション、Railsじゃなくてもいいんですけど、Webアプリケーションで開発する人があまりいない、得意な人が少ないかいないんだけど、メンテしたいみたいなサービスとかがあるじゃないですか。そういう時にRails以外を使うと大変そうだなと思います。
藤村：RailsはRailsでそれやると、気がついたらバージョンがめちゃ古くなっちゃってあげようと思ったけどどうしていいかわからないし、使い捨てだと思ってテストも書いてないからどうしようみたいなパターンもよくある。
高橋：そのパターンもあるんだけれども、古くてテストも薄いけど一応Railsで作られていて売上もあがってる場合、お金さえあれば、凄腕の人を連れてくればなんとかしてくれそうみたいな淡い期待もありますよね。そういうことを仕事としてやられている方が、ここにもいらっしゃるようですし。
藤村：たしかになぁ。
高橋：古いやつを頑張ってバージョンアップする仕事をやりますみたいな。
藤村：確かになあ。やりゃなんとかなりますもんね、しかも。
高橋：ある程度パターンが決まっていると思うんですけど、Goだとそういうパターン化はできなさそうじゃないですか。どうするんですかね。
藤村：Goのバージョンアップをどうしているかというか、他の言語でRailsほどバチバチにレールが敷かれていないもので作ったもののバージョンアップとか大変そうですよね。
高橋：バージョンアップじゃなくて基本的にフレームワークの乗り換えとか自力でもりもり書くとかにしかならないんじゃないのかな…。
藤村：ああ、もう書き換えに近いですよね。なるほどな。
バックエンドシステムが主戦場
藤村：高橋さんがプログラマとしてどういうことを大事にしてコードを書いている、どういうコードを良しとして書いているみたいなところってあったりされるんですか？
高橋：あんまりないですね。
藤村：意外な回答でした。
高橋：基本的にすでにあるコードに合わせる。そういう意味では、アーキテクチャ設計ってある程度統一されていれば何でもいいところってありますよね。それよりもすごく頑張った設計が2つ、3つ混ざっているようなアプリケーション*6の方がよっぽどつらそう。
藤村：1つの方向で揃っているのが大事っていう。
高橋：自分としてはこうしたいと思っても、他のコードが揃ってなかったら、まあそうしない方がいいかしらみたいな。
藤村：なるほどな。まあそうですよね。0から自分で書く場合はRailsはこうする、それもさっき話したような感じでデータベース設計を頑張ってて、ほどほどに。
高橋：あとフロントエンドについては好きな人と好きじゃない人が多分いて、私はあまり好きじゃない方だと思うんですよ。フロントエンドって、例えばゲームが好きかどうかっていうのと相関ありそうと思っていて、ゲームが好きな人って普通にいっぱいいますよね。そういう人たちはゲームとかでよくできたUIに親しんでいて、そういう理想に詳しいと、フロントエンドにもこだわりたくなってくるんじゃないでしょうか。私はゲームには全然愛がなくて。テレビゲームなるものを自分で持ったことがないんですよ、ファミコンとかも含めて。
藤村：全然やらない？
高橋：やったことはあるんだけど、自分の家にあったことはないです。
藤村：面白さの軸、何が面白いのかがわかりづらいなっていう感覚なんですかね。
高橋：ああいうのが好きな人はフロントエンドやりたいだろうなぁって、自分の思ったように動作するとすごい嬉しいだろうなぁというのはあるんだけど、そこにはあまりうれしさを感じないです。
藤村：バックエンドシステムみたいなところがやっぱり主戦場っていう感じなんですかね？
高橋：元々の好みでそういうのがあったのかなぁという感じがしますね。
藤村：バックエンドシステムを作っていてどんな時が嬉しいですか？
高橋：どんな時が嬉しいか…。
藤村：僕もこんなこと聞かれたらどうしようってなっちゃいますけど。うまくできた時とか言っちゃいそう。
高橋：やばくない時は嬉しい、やばくないやつはみんな嬉しいって感じです。これはやばいとかこれはつらいとかあるじゃないですかね、あれはつらいので。
藤村：ちゃんと動いてるし読めるみたいな。やばいやつもありますもんね。
高橋：やばいやつもわかってる人が触ればなんとかなるんだけれど、そうじゃない人が触るとつらいみたいなのもあれば、誰が触ってもつらそうみたいなのもあるんですけど。
藤村：フロントエンドとかUIみたいなところになるかもしれないですけど、プログラミングで難しいな、苦手なものってあるんですか？
高橋：フロントエンド側のUIとかのプログラミング自体に、あまり興味がないっていう感じですね。
藤村：進化が激しくて面白いってところは、僕はあるかなって思ったりもしますけどね。
高橋：まあそれはそういうのが好きな人が頑張っているっていう。
藤村：なんかフロントエンド以外でここはさほど興味がない、もしくは苦手であるみたいなのとか？
高橋：なんですかね。インフラを作る仕事もあんまり興味がないかもしれないですね。
藤村：バックエンドのアプリケーションレイヤーがやっぱり主戦場なんですかね。なんかコンピュータとかプログラミングとかの関係で、最近ここ数年の関心ごとってあったりするんですか？最近興味がある注目しているやつみたいな。
高橋：最近興味がある注目しているやつですか。なんだろう…。興味がない方から言うと、競技プログラミングは興味がないですね。
藤村：おー。
高橋：そもそも競技とかが苦手なので。
藤村：競技プログラミングは僕も興味がないんで、興味がある人にぜひ面白さを教えてほしい。あとは聞いてみたかったのが、さっき話したオブジェクト指向もそうなのかもしれないですけど、最近注目されてないけど重要だろうなって思ってるものってありますか？
高橋：セッションの前にちょっと言いました*7けど、個人的にはWeb Componentsはなんとかならないかな*8と思っていますね。
藤村：どこら辺が面白ポイントというか、ありがたいポイントなんですか？
高橋：みんなが頑張ってタグを作ってくれれば、そのタグをペタペタするだけで、こんな便利なアプリケーションが作れて便利って感じですよね。
藤村：確かに。そんなにめちゃくちゃ流行っているわけじゃないみたいな感じになっちゃいましたもんね。
高橋：できることが限られるというか、限られていること以上のことをやるとするとつらくなるので、それだったらまともなフロントエンドのフレームワークを使った方が早いですよっていうのは、まあそうだなと思うんですが。
コンピュータ書鑑賞
藤村：出版業をやってらっしゃるじゃないですか。普段何の本を読んでるんですか？
高橋：普段ですか？まあコンピュータ書は普通に読みます。
藤村：コンピュータ書はやっぱりその一通り本屋に行って、ちょっとめくって買ってみるみたいな読み方をされてるんですか？
高橋：最近はあんまりそうではないんですけど、昔『このコンピュータ書がすごい！』*9をやってた頃は割とそんな感じでしたね。
藤村：どういうコンピュータ書が好きですか？
高橋：面白いやつですね。
藤村：高橋さんの面白さを知りたい。
高橋：コンピュータ書ってそもそも面白さで読む人って全然いないんですよ。なんだけどSFとかミステリーの世界はみんな面白いかどうか、どこがどう面白いかみたいな話で盛り上がってるわけですね。なのでコンピュータ書をそうやって読めば読めるはずなんだけど、みんな読んでないから自分がやってるみたいな。
藤村：コンピュータ書鑑賞っていうジャンルを開拓されているに近い状態なのではないかと思ってるんですけど。コンピュータ書鑑賞における喜びというか、どういうところが評価ポイントなのかを聞いてみたいな。
高橋：世の中には埋まっていない、まだ書かれていないコンピュータ書の領域というのがあるわけですね。なんだけどたまにそこを埋める新しいのがポコっと出たりすると、これはこの未踏の領域に挑んでいるのですごいみたいな感じですかね。
藤村：代表的な本だとどういうものがありますか？
高橋：なんだろう。ちょっとすぐには思いつかないです。
藤村：こんな領域を書いた本があったのか！みたいな。最近、ここ数年でコンピュータ書で面白いやつありました？
高橋：最近面白かったやつはなんだろう。最近でもないけれど、面白かった本はNTTコムウェアさんで書評のコーナーがありまして、そこに3ヶ月に1篇くらいかな、書かせていただいているので、だいたいあれが私のおすすめです。古い本も結構入っているんですけど、古い本も改めて読むと面白いですよね。
藤村：月に何冊ぐらい、全部読んでいないのも含めてどのくらいのコンピュータ書に目を通しておられるんですか？
高橋：どうだろう…今一番読んでいるのは技術書典というイベントがありまして、技術書典アワードなるものがあるんですよ。これは自薦式で応募された作品を対象にするんですけど、応募作品は全部読んでいるのでその期間だけめちゃめちゃ読書量が上がる。
藤村：ちょっとレベルが違いすぎる話が。
高橋：全ページも開いているわけではないんですけど。
藤村：通年人類史上ベスト3技術書あげるとしたらどこら辺になるんですか？
高橋：個人的に印象があった本だとやっぱりSICP（『計算機プログラムの構造と解釈』）は印象が強いんです。あとは『Amazonランキングの謎を解く』ですか。
藤村：SICPは読んだことない方が今や多いとは思うんですけど、どこら辺が感動ポイントですか？
高橋：あれの感動ポイントは、世界とはプログラムである、世界を認識することはプログラムを書くことっていうプログラミングに対するすごく都合のいい世界観があるわけですよ。もっと言うと、世界とはプログラミング言語であり、プログラマはプログラミング言語の設計者であるみたいな感じですね。言語というのは入力と出力があるもので、だいたい世の中のあらゆるものは入力と出力があるので、それっていうのはある入力を解釈するものであって、それっていうのはコンピュータプログラミング言語でエミュレートできる。
藤村：いつでしたっけあの本って？
高橋：2000年前ですか？90年代とかかな。
hogelog：1985年らしいですね。
高橋：私が最初に読んだのは大学生の頃だったので、1993、4年頃だったと思います。
藤村：その頃のコンピュータへの期待の高まりというか、ある種人文学的なコンピュータへの期待の高まりが詰まってそうな話ではありますよね。
新井素子の魅力
藤村：コンピュータ以外の本も読まれるんですか？
高橋：最近、ミステリーは全然読まなくなっていて、SFはたまに読むくらい。あと新井素子は新刊が出たら読むっていう感じです。
藤村：新井素子さんの本はどこら辺が魅力ポイントなんですか？
高橋：それは話すと長いんですよ…。
藤村：僕はそれを聞きたいんですよ。
高橋：そうなのか。新井素子はエンターテインメント寄りのSFを書いてる作家さんなんですが…そもそも人が生きていく上で大事なこと、考えるべきことは何かというと、究極的には人はどう生きてどう死ぬかということだと思うんですが、新井素子の作品はそういう話を延々と書いてるところがあって。
なんだけど、元々の想定読者は女子中高生とかだったので、そういう人に読ませたい、そういう人が読みたがる話に仕立て上げるわけですね。それってすごい難しいことなので、どうするかとあれやこれや頑張ったりしているわけで。そしてSFの人なので、個人がどう生きるかどう死ぬかみたいな話って考えるのも答えるのも難しくなるんだけど、そこで主語を大きくして「人類」にしてしまう。個人が死にかけたりするんじゃなくて人類が滅びかけたりするわけです。人類が滅びつつある時に人類の意味は何だったのか？みたいな話に置き換えて、それを中高生だったり、もっと歳が上になったりする主人公である「私」が一生懸命考えるわけですね。あれが面白い。
藤村：ある種哲学的なところを含めた関心がある問題ってそういうところもあるんですかね。
高橋：普通に自分がどう生きるかどう死ぬかって大事ですよね。
藤村：そうですね。
高橋：最後はそこになるじゃないですか、仕事をするにしても、どういう仕事をするかとかっていうのは、結局どう生きてどう死ぬかっていう。それをどういう生き方をしたいのか、どういう死に方をしたいのかっていうことを、ちゃんと考えさせる本っていうのはあまりないので。
藤村：そうですね。
高橋：しかも大体新井素子の結論は、あまり考えても意味がないっていう。
藤村：（笑）
高橋：突き詰めると人生に意味はない、生きる意味は大してないとなっちゃうんだけど、でもみんな頑張って生きていきましょう、善く生きましょう。「善く」っていうのは「善」ですね。そういう結論になるっていう。
藤村：なんか哲学的っていうか、啓蒙的な内容もあるんですよみたいな？
高橋：いやー読んでる間は全然啓蒙は感じないですけどね。それを普通のエンターテイメントの枠内で頑張るんですよ。お話としてはどこからどう見てもエンターテイメントでしかないので。
藤村：みなさんぜひ読んでみてください。僕も読んでみたく…
高橋：でも私以外の人が読んでもあんまりそうは思わないかも？
藤村：なるほど？感じ方がいろいろありうるっていう感じなんですかね。
高橋：小さい頃からずっと新井素子を読んでいるとそういう考えになるだけなので、大人になってから読んでも…というのはありそう。
本との出会い方
藤村：最近読んだ本でなんか面白いやつとかありましたか？
高橋：最近読んで面白かった本、えーっとですね。ちょっと出すのをためらうんですが、小松原織香さんっていう、基本的にはフェミニズムや哲学をやってる人*10なんですけど、『当事者は嘘をつく』っていう本を去年出されてて、あれがめちゃめちゃ面白かった。だけど、あんまり人には勧めないっていう感じの本*11ですね。
藤村：へー。
高橋：あとその人が今出てる『文藝』っていう雑誌の春号*12に「〈文学が生まれる場〉にいた話。同人作家と「サークル村」の女たちを繫ぐ試み」というエッセイを書いてて、これがめちゃめちゃ面白かった。ですけど、これもあんまり人には勧められないですね…。どう面白かったのかというと、この著者さんは昔、同人誌を書いてたり、即売会で売っていたり、またケータイ小説を書いてた時期もあったのですが、その頃を振り返って、あれはすごい場だったんだけれど、結局何も生み出せなかったという。でもそこで、言葉を書いたり読んだりしていくことには大いに意味があるんだけれど、あの頃のエモーショナルな感動は今はもうないし、読者の感想が書かれた手紙も読み返すことはないみたいな。
藤村：あのメディアで見るからこそだったんですかね。
高橋：いや、まあ何て言うんでしょうね。そういう特殊な場っていうのはあって、それこそが〈文学が生まれる場〉だったと私は思ってるみたいな感じの本ですね。
藤村：そういう本にどこからたどり着くんですか？
高橋：いやー、なんかふらっと。新刊棚にいったら『文藝』があって、「あ、新しい号が出てる」と思って目次を見たら小松原織香って書いてある、みたいな感じです。
藤村：本屋さんで発見ですか？
高橋：そうですね。
藤村：どこの本屋さんですか？
高橋：ジュンク堂書店池袋本店ですね。
藤村：やっぱそうですね。他に行くところもあります？なんか気分を変えてここに行くこともあるんだよな。
高橋：気分を変えてというか、池袋が遠いので、新宿の紀伊国屋書店に行ったりもします。
藤村：おー。新宿の紀伊国屋書店って僕の中ではさほど特徴がない本屋*13っていうイメージもあるんですけど。ブックファーストの方が謎のこだわりが。
高橋：わかりにくいですよね*14…。
藤村：新宿はわかりにくいですね。コンピュータ書のコーナーが地上からマジで遠いっていう。ジュンク堂書店池袋本店はもうなんか入ったら最後みたいな。カゴ持っちゃったみたいな感じですよね*15。僕も毎回入るたびに絶対に読まない本を大量に買ってしまいます。
高橋：あとは国立国会図書館の個人配信が始まって、これは会員登録をしないといけなくて、身分証をブラウザからアップロードするんだったかな？みたいなのがあるんですけど、昔は国会図書館に行かないとアカウントを作れなかったのが今はデジタルでできるようになったんですよ。なので、あれは絶対作るといいです。作ってます？
藤村：作ってないです。
高橋：今から作るべき*16。
藤村：なるほど。フィジカルに国会図書館に行けるってことですか？
高橋：行かなくても登録できるんですよ！個人向けのデジタル配信が最近始まったんですが、これがめちゃめちゃ便利で。検索も最近強化されて、ちょっと前の本、絶版だけど著作権はまだ残っている本もネットで探して読める。超便利。
藤村：それはちょっとあれですね。僕も読みたいけど、買えなかった本を読みたい。
高橋：そこそこ古い本までが対象で、90年代とか80年代はまだダメなんですけど。
藤村：それは有力な情報ですね。
高橋：時間がどんどん溶けていきます。
藤村：高橋さんの本の買い方について教えていただけないでしょうか？どんな風に普段本を買っているのか。
高橋：最近はさすがにちょっともう物を増やさないように頑張りたいっていう感じなので、2ヶ月に一度しか池袋ジュンクに行かないんですけれど、まあでも、行くと1万円、2万円使ったり使わなかったりですかね。
藤村：上から順番に全部見るスタイルですか？それとも気が向いたところに行く？
高橋：気が向いたところ。まあ6階*17は行きますが、それ以外は気が向いたところですね。
藤村：6階以外のよく行くコーナーってどこら辺なんですか？
高橋：4階はなんだかんだで行くのと、あと2階も行きますかね。昔は地下に行ってたんですが、最近はあんまりっていう感じ*18ですね。まあたまに行くみたいな感じで。
藤村：最近、今積んでるけど次読みたいなって思ってる本ってなんですか？
高橋：えっと、何だっけ。『ちょうぜつソフトウェア設計入門』は積んでます。あと、『継続的デリバリーのソフトウェア工学』も積んではいますね。
藤村：そこら辺の本を読むときって、鑑賞なんですか？それとも知識の導入なんですか？
高橋：いや、もうこの辺になると、NTTコムウェアの連載で紹介するかどうかを考えながら読む。
藤村：個人的に知りたいだけなんですけど、一般的にはお勧めしないが、個人的にめちゃ推しの技術書ってありますか？
高橋：技術書ですか？
藤村：マニアックな喜びがあるやつ。
高橋：マニアックな喜び、何ですかね。
藤村：あんまり知られてないけど、僕がみんなに読んでほしいなと思うのは『Making Software』とかですけどね。面白かった。
高橋：あれを勧めるかどうかは悩ましいですね。
藤村：そっか。地味ではありますよね。
高橋：地味だし、ちゃんと読むんだったら論文を読んだ方がいいんじゃないみたいな感じになったりするので。
藤村：ソフトウェア工学、ガチのやつをちゃんと読んだ方がいいじゃんって。ちょっと古いですしね。
高橋：そうですね。技術書、何だろう。何かありますかね。
藤村：この本は作品性あるなみたいな。僕は『The Little Schemer』（邦題:『Scheme手習い』）がめちゃ好きで、あれとかは人によく勧めたりしてましたけどね。あれはやっぱり技術書にしてはかなり特殊なスタイルで面白いなと思ったりしてましたけどね。
高橋：何だろうな、これっていうのはすぐに思いつかない*19ですね。
藤村：Ruby関係の本で、これが印象的だった、エポックメイキングだったみたいなのは？
藤村：最新版が出たらいいですけどね、あの本とかも。
高橋：まあ、出なくてもあれはあれで。今とは全然違いすぎるというのはあるかもしれないですね。
藤村：考古学的には面白いっていうのはあるかもしれないですね。
オブジェクト指向を理解するには？
藤村：終盤になってきたんですけども、みなさまから何か聞いてみたいこととかがあれば。もう早く飲みたいっていう感じなのかもしれないですね。
高橋：そうですね。飲みながらでもいいですけどね。
藤村：昔話に僕は価値があると思ってるんですよ。なぜならみんな知らないからっていう。
高橋：本当に昔の知識ってどんどんロストしていくので、あれはまずいなと思いますよね。今更知りたくないよ、みたいな人がいっぱいいるのはわかるんですが。
藤村：僕はやっぱりRailsからオブジェクト指向プログラミングに入ってるんで。Railsからオブジェクト指向プログラミングに入ったっていうのが、もう怒られそうな感じもありますけど。その前がわからないので、比較とか評価のしようがないんですよ。
高橋：そういう意味では、例えばDDDから入るのは本当によくなくて、DDDはオブジェクト指向ソフトウェア開発設計、開発プロセスの流れを汲んでるものだと思って読まないと、訳わからなくしかならないんじゃないのかな…と私は思ってます。他の人はどう思ってるのかわからないですけど。
藤村：歴史的な経緯を踏まえないと読むのは難しい本っていう感じなんですかね。
高橋：そうなんですよ。しかもその時代に出てた他の本が今は軒並み入手困難になってるわけじゃないんですか。あれだけ読んでもしょうがないだろみたいな。
藤村：オブジェクト指向入門っていうのが今まさに求められてるのかもしれないですね。
高橋：オブジェクト指向入門ならあれですよ、WEB+DB PRESS Vol.132 のきしださんの特集（「オブジェクト指向神話からの脱却」）を読めば。
藤村：あれを読めばいいのか。
高橋：あの記事はすごい良くできてます。よくできてるというか、あんなにオブジェクト指向入門して大丈夫なのかみたいな感じ。
藤村：なるほどな。
高橋：タイトルが『オブジェクト指向神話からの脱却』なんですけど、内容は本当に突っ込んだ入門で、これは今どき流行ってないのでは？みたいな話も含めて延々続くみたいな。
藤村：そういう意味では2000年代のオブジェクト指向は我々はもう脱却したっていうことなんですかね？
高橋：脱却できるところは脱却しつつあるんだけれど、単に忘れてしまっているところは忘れられている。
藤村：知らない、俺はよくわかってないのでは？っていうのが未だにずっとあるんですよ。あの時代のことがよくわかってないんで。
高橋：そうか。その辺、まだ時間は大丈夫ですか？
藤村：はい。
高橋：最近、オブジェクト指向で特にJavaですね、Javaの何が良かったかっていうのは、オブジェクト指向よりもGCが導入されたことではないかと思ってるんですよ。メモリ管理って大変じゃないですか。自分でmallocしてfreeするとどうしてもバギーになりやすくて、しかもこのバグってsegvで死ぬみたいな感じの致命的なバグですよね。そこを頑張らなくて済むようになったっていうのがJavaの一番すごかったところなのかなあと。そうするためにヒープとかスタックとかを気にしないで、全部オブジェクトに置くっていうオブジェクト指向っていうのができたっていうのが、当時としては一番すごい発明だったのでは。
藤村：何書いてるってところだけを書けばよくなったって感じなんですかね。裏側っていうか。
高橋：このオブジェクトはいつまで生きてるのか、いつ死ぬべきなのかっていうのをプログラマが考えなくてよい。メモリリークして落ちたりしない。メモリリークするかどうかっていうのは人間がわざわざ考えたいことではないじゃないですか。コンピュータにやらせたい仕事ですよね。
藤村：考えたくないですね。
高橋：そういうのをちゃんと言語の方で面倒見てくれるようになったっていうのは大発明ですよね。もちろんJava以前の言語でもGCがついてる言語はありましたけど、それが一般向けの広く使われる言語にGCがついたっていうのはJavaが大きかったのではないのかなという感じがしています。
ogijun：昔のJavaはあまりよくできてなくて、リファレンスが残ってると代入されにくいので、nullを代入しましょうとか。GoogleとOracleが競ってJavaVMを強化し始めてから圧倒的に良くなった。
高橋：なのでオブジェクト指向が素晴らしかったわけではなくて、GCがすごかった*21ところもあるんですよ。多分。
藤村：なるほどなあ。
高橋：今でもすごくて、GC以外でメモリ管理をさぼれる何かっていうと、最近だとRustで所有権を駆使するみたいなのがありますけど、あれも簡単に使えるかと言われるとまだちょっと難しい*22ですよね。そして他にめぼしい技術もなさそうですよね。
藤村：GCですよね。そういう意味ではね。なるほどな。ではやっぱりきしださんのあの記事を読もうって感じなんですかね。
高橋：ほんとかなぁ…まあでも読む価値はあると思います。
藤村：すみません、そろそろ時間が来ているので皆さんの質問がなければ懇親会に突入しようと思います。高橋さん、長い時間ありがとうございました。（完）
Rubyistめぐりは、第2回の開催を予定しています！イベント情報はTwitterで投稿していますので、ぜひTwitterのフォローをお願いします！
https://twitter.com/storesinc_tech
*1:ディストリビューションのパッケージ管理をされてる人たち。ディストリビューションでは各ライブラリの依存関係をていねいに解消してアプリをスムーズに導入しやすいそう心がけていたのに対し、そういうのを無視してがんがんbundle installする風習は粗雑に見られていた用に思われます。（高橋）
*2:rubygems.orgに登録されている最古のバージョンは2009年の0.3.0で、1.0.0が2010年だったようです。 https://rubygems.org/gems/bundler/versions?page=4（高橋）
*3:JavaのWebアプリケーションフレームワーク。（高橋）
*4:前半でも少し出てきましたが、MySQLやPostgreSQLがこなれてきたのがRailsが登場した頃で、それ以前のRDBはみんなそれなりに良いお値段だったのでした。（高橋）
*5:原著は2006年出版、日本語版は2008年出版（角谷）
*6:開発時期によって違う設計方針のまま作られてそのままになっているアプリとか、一時期書き換えを行おうとしたけど全部はできずそのままになっているアプリとかを思い浮かべてました。そういうのありますよね？（高橋）
*7:最近Litを触ってるんですよみたいな話をしてました。（高橋）
*8:現状はなんともなってない気がしますね…。特にForm周りとか。そりゃあReact・Vue・Svelte等々を使いたくなるよねと思いました。（高橋）
*9:毎年1月にジュンク堂書店池袋本店で行っていたイベント。前年に出たコンピュータ書を200冊くらい（？）紹介するいろいろ大変な企画でした。（高橋）
*10:もともとはてなダイアリーでフェミニズムや本や映画の感想について書かれてた人で、「よく読んでるブロガーの人が本を出してメジャーデビューした」みたいな感じです。（高橋）
*11:この本は性暴力の問題について掘り下げている本で、個人的には去年読んだ本の中でもっとも感銘を受けた本。とはいえこういう題材に興味のない人にはまったくおすすめできない本で、こういう記事でセンシティブな本を紹介するのもどうかと思ったのですが、先日NHKで著者さん本人が取材を受ける番組が放映されてそれなりにメジャーな扱い（？）になりつつあるようなので掲載してもらうことにしました。（高橋）
*12:正しくは「文藝 ２０２３年春季号」でした。（高橋）
*13:特徴のなさでは以前の紀伊国屋新宿南店の方が特徴なかったような…新宿本店の方は適度にまとまってる、まとめました感があった気がします。が、現在は大幅改装中のためしばらく落ち着きがなさそうです。（高橋）
*14:売り場が一部ジャンルによって物理的に分断されているため、複数ジャンルを横断してみたい場合はとにかくつらい。（高橋）
*15:ちなみに私（高橋）は6階についたら本を手に取る前にまずカゴを持つ派です（6階につく前にカゴを持ってない場合）（高橋）
*16:ここを読まれてるあなたもぜひ作ることをおすすめします。（高橋）
*17:コンピュータ書売り場があるフロアです。（高橋）
*18:と言ってみたものの、実際には立ち寄らないわけではなく、立ち寄るけど買わないで他のフロアに行くだけな気もしてきました。（高橋）
*19:あとで考えたんですが、『Androidを支える技術 I』 『同 II』があるかも。あの本の著者さんは別にAndroidそのものの開発者ではないので、他人が作ったものとしてAndroidを解説していくのですが、II巻の最後の最後で著者さん自身の仕事とAndroidが一瞬交叉するシーンが出てきて、叙述トリックのような鮮やかな感動がありました。…とはいえ、「一般的にはおすすめしない」わけじゃなくて、一般的にもおすすめです。はい。（高橋）
*20:今なら全文が https://i.loveruby.net/ja/rhg/book/ で読めます。（高橋）
*21:なんでこんなことを考えていたかというと、80年代〜90年代頃オブジェクト指向に走らず、構造化プログラミング的なもの＋レコード型や構造体的なものでなんかうまいことやる道があったのかな…と考えたところ、わかりやすい障壁として「メモリ管理つらい」みたいなことがありそうだな、と思ったからなのでした。また、私の私見なので、実際こうなのかどうか確証はないです。あしからず。（高橋）
*22:Rustを使いこなす訓練が足りてないせいもありそうですが…まあでも（性能にこだわらなければ）GCより簡単になったりはしないですよね？（高橋）
