珠玉の書籍 「人生を変えた1冊」 yukiさん＆sivchariさん

1冊の本が、エンジニアの進む方向を変えることがある。この企画では、エンジニアが1冊の本と出会った場面から今につながる変化までをたどります。誰かの1冊との物語が、あなたが次の1冊に手を伸ばすきっかけになりますように。Findy Engineer Labで全7回・55名の方にご登場いただいた「珠玉の書籍」が、1記事2名でじっくりお届けする形に生まれ変わりました。

今回のテーマは「人生を変えた1冊」。

ソフトウェアアーキテクトのyukiさんと、Software Engineerの sivchariさん。お2人が挙げたのは、どちらも読んだ直後ではなく、何年も経ってから効いてきた1冊でした。そして「AIに聞けば済む今、なぜ本を読むのか」という最後の問い。知識とは「構造」だと語るyukiさんと、自分の中に「沈める」と語るsivchariさん。同じ結論に、まったく違う道筋で辿り着いています。

yukiさんの1冊

Q. その本を手に取る前、どんな状態でしたか。

この本を手に取ったのは新卒2年目の終わりくらいだったと思います。

私はもともとソフトウェアエンジニアとしてキャリアをスタートするつもりはなく、ITコンサルタントをやろうと思い、就職しています。プログラミングは社会人になって初めて取り組みました。元々上流工程に興味があったため、プログラミングの研修は楽しんだものの自主的に内容を深めるなどはしていませんでした。

ところが配属されたのは予想外の開発チームでした。毎日コードを書かなければならない状況になったのです。最初は、プログラミングに興味があったわけでもなく困りました。ただ、私はあまり意味や意義など深く考えず、とりあえず目の前のことを楽しめるタイプでしたので、毎日コードを書く仕事を黙々とやりました。毎日コードを書いているうちにだんだん楽しくなってきていました。

Q. どこで、誰から、どんな状況でその本と出会いましたか

手に取ったのは秋葉原の書店でした。元々本が好きで、定期的に書店に足を運んで棚を眺める習慣がありました。その頃は、ちょうどプログラミングをもっと深く知り、探究したいと思っていた時期でした。本書の内容が、当時の私のモチベーションとちょうど一致したのです。

Q. どんな本で、特にどこが刺さりましたか

本書で刺さったポイントは、ほとんど裏表紙の文章に集約されています。

加えて、「関数とは何か？」「型とは？」「クラスとは？」といった概念の定義の話を真正面からしてくれるのが本書の素晴らしい点です。こうした言語設計への理解は、当時の私のプログラミングの力を飛躍させてくれたと思っています。

多くのプログラミングの入門書は、定義を真正面から検討しないか、比喩表現でぼかすなどして十分に説明してくれていません。しかし、私のように周りにプログラミングに明るい人が近くで手解きしてくれない環境で育つと教わる機会がありません。初心者がプログラミングをうまくできるようにならないなと思う要因には、登場する概念が結局何なのか、なぜ必要なのかがいまいち理解できず、使いこなせないというものがあると思います。物事への深く正確な理解なくしては応用のしようもないのです。

Q. 読んだ後、仕事や判断がどう変わりましたか

本書は即効性のあるトピックを扱っているわけではないので、読後すぐに何か成果を得られるということはありません。読んだ当時の私も、理解できたのは本書のトピックの半分くらいだったのではないかと思いますし、仕事上の評価がよくなったわけではありません。

しかし業界で数年経ち現場で日々コーディングの議論をしていると、意外にも周りのソフトウェアエンジニアは、プログラミング言語の機能をなんとなくの感覚で使っていると気づかされることが多いのです。コードレビューの際にとくにそれを感じることがあります。「なんとなくこちらの方が好み」という話で終始してしまいそうになることがあります。「なんとなく」を、なぜよくてなぜダメなのか、言語化して切り込んでいけるようになりました。

私はプログラミング言語の機能の使い方がそれでよいかどうかは、だいたいのケースで明確に理由づけられると思っています。なぜなら機能にはそれが設計・導入された背景があるからです。本書はなぜ言語設計者がその機能を導入しようと思い、そう設計したのかという推察を立てる手立てを提供してくれます。ここを知っているとその機能を使わなければならない理由が自ずと見えてくるのです。

本書でのトピックは、のちに私がRustに興味を持ち、書籍を書くなどのさまざまな発信活動を行い、さらにはコンパイラへのコントリビューションに至るまでの情熱を下支えしてくれました。プログラミング言語そのものがこんなにも深くおもしろいものだと教えてくれたからこそ、言語そのものへの情熱を維持し続けられました。

Q. いまこの本を読む人に、何か添えるとしたら

AI時代にプログラミングを学ぶ意義が薄れているのに、ましてプログラミング言語それ自体を学ぶ意義はどこにあるのか？と思う方はいるかもしれません。私の意見としては、仕事の比重が変わり、どうやってうまくソフトウェアを長期的に稼働させられるかにより時間を使うようになるため、プログラミング言語の機能の設計思想を学ぶのは以前から変わらず重要だと考えています。

AIの普及で仕事におけるプログラミングの比率は下がったとは思いますが、引き続き「ソフトウェアエンジニアリング」という行為は求められると考えています。『Googleのソフトウェアエンジニアリング』^[1]という書籍で語られているように、「ソフトウェアエンジニアリングは時間で積分したプログラミング」であり、プログラミングとソフトウェアエンジニアリングは別物です。開発だけでなく保守や運用などを含め、ソフトウェアを時間経過に耐え、持続可能なものにする行為を指します。これは以前と変わらず求められるはずです。

ソフトウェアエンジニアリングは知識の総合格闘技だと思っています。プログラミング言語の設計思想や機能そのものへの理解も、総合格闘技のわざのひとつです。ソフトウェアエンジニアリングの重要性が今後も下がりはしない以上、この本で得られる知識の価値も下がりはしないでしょう。

Q. AIに聞けば済むことが増えた今、それでも本を読む意味はどこにあると思いますか

AI時代に本を読む意味はあるのでしょうか。この質問に答えるためには、まず意味を確定させる必要があります。質問は、読書という行為の目的を問うているのでしょう。今回は、小説などを除き、ノンフィクションや技術書を読む目的を「知識の獲得」にあると仮定します。

ならばこの問いには、逆に問い返したいことがあります。そもそも知識を得るとは、どういうことでしょうか。一問一答に答えられることでしょうか。おそらく、違います。

知識とは「構造」だと私は思っています。プログラミング言語のある機能について、その定義は何で、どのような問題を解決するために存在し、設計者はなぜそれを選んだのか。この論理のつながりを把握していることが、「知っている」ということです。

本には、論証という形でその構造が必ず含まれています。先頭から読んでいけば嫌でも体系が頭に入ります。もちろんAIにも体系的な説明を求めることはできますが、そう求められるのは、そこに体系があると知っている人だけです。扱うべきトピックの量や深さも、自分で見積もらなければなりません。本であれば、その分野のプロである著者がすでにそれを調整してくれています。何も知らない状態から学び始めるとき、この差は小さくありません。

AIは知識の入り口を広げてくれますが、構造を構造のまま渡してくれるわけではないのです。だから私は、AI以前と以後で本を読む意味は何も変わっていないと思っています。

sivchariさんの1冊

Q. その本を手に取る前、どんな状態でしたか。

僕は大学でフランス語を専攻しながら、独学でプログラミングを始めました。Goを書くようになり、大学4年生の頃にはGo Conferenceで登壇する機会もいただいていました。

ただ、goroutineやcontextについては、あることは知っているし見よう見まねで使うこともできるものの、なぜそう書くのかを理解して書けている状態ではありませんでした。goと書けばgoroutineが立ち上がり、channelで値を受け渡せる。contextを渡せばcancelできる。そこまではわかっていても、goroutineをどこで終わらせるべきか、cancelをどう伝えるべきかと聞かれると、自信を持って答えられませんでした。Goにもっと詳しくなりたい、特に並行処理への解像度を上げたい、というのがその頃の1番の関心でした。

Q. どこで、誰から、どんな状況でその本と出会いましたか

その頃、新卒で入社する予定であるサイバーエージェントの内定者メンバーと、Goの言語仕様書の輪読会をしていました。仕様書はGoが何をどう定義しているか、どのようなルールかを教えてくれます。一方で、それらをどう組み合わせて並行処理を書くのか、なぜそう書くべきなのかまでは書かれていません。仕様書は言語の定義であって、使い方を教える本ではないからです。

仕様書を読めば読むほど、その外側にある考え方を知りたくなりました。そこで並行処理について調べていて見つけたのが本書です。Goの並行処理を学ぶならまず名前が挙がる有名な本でした。

仕様を1行ずつ確かめる輪読会と、本書で考え方を学ぶ時間が同じ時期に重なったことは、今振り返っても自分のためになっていると思います。

Q. どんな本で、特にどこが刺さりましたか

本書は、Go の並行処理の構成要素から、pipelineやfan-out / fan-in、contextによるcancelの伝播といったパターン、goroutineを動かすランタイムの仕組みまでを順に解説する本です。

ただ、1番刺さったのはパターンではなく、序盤で語られる並行性と並列性の違いでした。本書では、並行性はコードの性質であり、並列性は動いているプログラムの性質である、と整理されています。並行に書かれたコードが実際に並列に動くかどうかは、CPUのコア数やランタイムのスケジューリングによって決まります。書き手が設計できるのは並行性であって、並列性はその結果として得られるものです。

それまでの僕はこの2つを区別できておらず、goroutineを増やせば速くなる、くらいの理解でした。この区別を知ってから、goroutineは同時に動かすための仕組みではなく、独立して進められる処理を表現するための仕組みとして見えるようになりました。

もうひとつが CSP（Communicating Sequential Processes）の考え方です。独立したプロセスどうしがメッセージをやり取りして協調するモデルで、Goのgoroutineとchannelはこれを下敷きにしています。

そして何より刺さったのは、どちらもGoに限った話ではないという点でした。

Q. 読んだ後、仕事や判断がどう変わりましたか

読んだ後に変わったことを考えると、もちろんGoの並行処理を自信を持って書けるようになったことはあります。goroutineをどこで終わらせるか、cancelをどう伝えるかを、理由と一緒に説明できるようになりました。

ただ、それ以上に大きかったのは、言語が変わっても通用する考え方が手に入ったことです。並行性と並列性の区別も、CSPの考え方も、Go以外の言語やシステムを見るときにそのまま使えます。処理を独立して進められる単位に分けることと、それを実際に並列に動かすことを分けて考える見方は、読んでから何年経ってもとてもいい学びでした。

僕は、本のいいところは、すぐに知識が使えることよりも、1度自分の中に深く沈んで自分のものになり、いつか必要になったときにポンとアイデアとして出てくることにあると思っています。読んだ直後に役立つ知識も、もちろんありがたいです。でも本当に効いてくるのは、読んだことすら忘れかけた頃に、目の前の問題に対して「これはあのときの話だ」とつながる瞬間です。そういう知識は、表面的なパターンではなく考え方として残ります。

これは技術そのものについても同じだと思っています。流行りのライブラリやフレームワークの使い方は数年で変わりますが、並行性とは何か、プロセスどうしがどう協調するのかといった根っこの考え方は長く変わりません。本書を読んで、そういう長く経っても色褪せない知識に触れられたことが、僕にとって1番の収穫でした。

Q. いまこの本を読む人に、何か添えるとしたら

本書をGoの書き方を覚えるための本として読むと、少しもったいないと思います。パターンの細部はすぐに忘れても構いませんし、必要になったら読み返せば十分です。それよりも自分の中に沈めるつもりで読んでほしいです。わからない章があったら飛ばしてもいいですし、1度で全部を理解しようとせず自分にとって将来生きるかもしれない何かを掴むことが大事だと思います。そうして沈めた考え方は、Goを書いていないときにも、きっとどこかで出てきます。

Q. AI に聞けば済むことが増えた今、それでも本を読む意味はどこにあると思いますか

AIに聞けば、たいていの問いに答えが返ってきます。でも、何を聞けばいいのかという問いを立てるための引き出しは、自分の中にしかつくれません。本を読んで、すぐには役立たない考え方まで自分の中に沈めておくことが、その引き出しをつくることなのだと思います。

続きはPodcastで

記事では書ききれなかった話を、お2人の対談でお届けします。AIに要約させるのと通読するのは何が違うのか、若手に本を勧められるのか、積読とどう付き合っているのか。近日配信予定です。