技術に関するポエムです。
昔に書いたこの記事みたいに、疑問を投げるだけ投げて終わるやつです。

本日の疑問

あることをしたいときの方法や、その他知りたいことが出てきた、というとき、答えが技術書に書いてある、ということは多い。では、どうやって「どの本のどの部分に書いてあるのか」を見つけ出せば良いんだろうか？

結局調べても分からなくて、後で何かの拍子に「それなら、この本のこの部分に書いてあるよ」ということが分かって「それ、もっと早く言ってよー」とsansanのCMみたいな気分になること、ないだろうか？

……これだけだといまいち分かりにくいので、具体例を出そう。俺自身の経験である。

具体例1

PyConjp 2018の最中、drillerさんの「Jupyterで広がるPythonの可能性」のセッションでの話である。
drillerさんが共著で書いた、「PythonユーザのためのJupyter[実践]入門」という本があり、俗に「Jupyter本」と呼ばれている。
壇上のdrillerさんが著書を紹介していたとき、「matplotlibの豆腐問題に悩んでる人はjupyter本を読めばいいよ!」というようなツイートが流れてきた。
……あらら、「豆腐」も俗称だ。グラフの中の日本語フォントがうまく表示されず、四角い記号になってしまうことを「豆腐」という。

（当該ツイートが見つからないので、drillerさん自身が著書を紹介したエントリを下記に引用する。）

matplotlib について聞かれることのダントツ一位が、「この豆腐なんとかならない？」です。本節ではフォントのインストールから、matplotlibのコード上でフォントを設定する方法、環境変数でフォントを設定する方法などについて解説しています。この情報が体系的にまとまっているところはなかなかないのではないでしょうか。
著者が語るJupyter本の読みどころ - drillerの部屋

そして、「豆腐問題ならjupyter本を読め」というツイートを見た俺は「えー、マジかよ、それもっと早くに知りたかったー」と思った。
その前の月に、このブログに移転して始めて書いた記事は、まさにmatplotlibの豆腐を直す方法についての記事だったからだ。（もっとも、matplotlib単体ではなく、seabornとの複合の問題だったが。）
linus-mk.hatenablog.com

Qiitaとブログのいろいろな記事を見て試行錯誤した結果、やっと問題を解決したのであった。

具体例2

今年の3月、松尾研のデータサイエンティスト講座の最終課題でレポートを書いていた。
締切の前夜になってレポートを書き進めていたが、分析結果を積み上げの帯グラフの形式で表示したくなった。
Excelだとボタン一発でできるから、matplotlibでもできるだろう、どうやれば良いんだろうか。
手元にあったオライリー本2冊をよく参考にしていたので、めくってみたが、それらしい記述はなかった。

締め切りも迫っていたので、あまり長い時間をかけるわけにも行かない。結局、諦めてGoogle スプレッドシート上でグラフを作ることにした。データを入力しグラフを生成して、できたスプレットシートのグラフをコピーしてレポートに貼り付け、提出した。

その後しばらくして、jupyter本の出版社のページ
PythonユーザのためのJupyter［実践］入門：書籍案内｜技術評論社
を見に行き、試し読みのPDFファイルを見た。

積み上げグラフの書き方が（帯グラフじゃなくて棒グラフだけど）載ってるじゃん。マジかよ。

それ、早く言ってよ……

（機せずして2つの具体例ともjupyter本の話になってしまったが、そこに特に意味はない。そういや、2回も惜しいことがあったのに、まだjupyter本を買ってないな……）

再び一般化

具体例はこのくらいにして、一般論に戻ろう。

簡単な悩み事の場合はググれば終わる。
例えば「Pythonで降順にソートしたい場合はどうするか」というような場合、そのまま「Python ソート降順」で検索すれば答えが出てくる。
（某エンジニア塾のようないい加減なコンテンツが検索結果に出てくるという問題はあるが、今回は論じない。）

問題は、疑問が簡単ではなく、粒度がある程度大きい場合である。
そうすると、ググっても出てこない、あるいは出てきたのを読んでもいまいち分からない、という場合も出てくる。

また、疑問の粒度の他に、どこに由来する疑問かという論点もありそうだ。
本（などの教材）が起点の場合は、その教材に書いてあることが多いだろう。「この本のとおりに書いたらこのような結果になった、なぜだろうか」はその本に書いてあることが多い。

しかし、その他の要因で疑問が出てきた起点の場合は「えっ……これ、どこを見れば解決できるの」となる可能性がある。

全然網羅的でないが、例えば以下のような場合があるだろう。

仕事ないし趣味でコードを書いていたら、期待と違う挙動をした。その理由を知りたい。
仕事ないし趣味でコードを書いていたら、特定の処理を実行したくなったが、そのための方法が分からない。

さらに、そもそも知らないので、検索しようとも思わない、というケースもあり得る。以下がそうだ。

特定の処理を実行するために難しい方法でやっていたが、実は簡単な方法・楽にできる方法がある
ある物事を理解するうえでここが肝腎で、ここを理解しておくとグッと分かりやすくなる、というポイントが存在する

俺のブログの過去記事でいうと、matplotlibのグラフの書き方が2通りある問題なんかは「理解しておくと分かりやすくなるポイント」の例かもしれない。

linus-mk.hatenablog.com

解決策？

本代をケチるから悪いのだ。本をたくさん読め。という意見はあるだろう。
なるほど。それはその通りだ。
では、2冊じゃダメなら何冊なら良いんだ? 10冊か？100冊か？
それに、今まで読んだ本の内容を全て覚えているのか？という問題がある*1。

細かい内容までは覚えられないとしても、それぞれの本の目次・大体の内容を頭に入れておく。
で、問題にぶち当たったら「確か……この本のあの辺りにあったような気がする」と言って、見に行くしかないのかなー。月並みだけど。

……と思っていたら、この記事に出くわした。

技術書、最初から完全に理解するか、頭の中にインデックスを作るか？〜 #チェリー本が後半から難しくなる問題を考える - give IT a try

もし、どうしても理解できない難しい内容が出てきたら、とりあえず「頭の中にインデックス（索引）だけ作って、どんどん読み進める」というスタイルにチェンジしましょう。
「頭の中にインデックスを作る」というのはすなわち、「実際必要になったときにあとで思い出せるようにする」ということです。
（中略）
本を読むだけではピンと来ない内容も、実際にそれを必要とする場面が出てきたら自分の経験と本の説明がきれいにリンクし、自分の知識としてしっかり頭の中に刻み込まれるはずです。
（中略）
実際、僕自身も新しい技術書を読むときは、そんなふうに読んでいます。
最初から最後まで完全に理解しようとすると時間もかかるし、読み進めるのも非常にしんどくなります。
なので、「内容が難しくなってきたら最低限見出しの項目ぐらいは頭の中に入れておく。あとは必要になったときにもう一度本を引っ張り出して読み直す！」と考えながら読むようにしています。

「頭の中にインデックス（索引）を作る」というのは言い得て妙である。俺の言いたかったことを上手くピタリと表現している。
引用した記事は、技術書の読み方の話をしているので、「読む方」に焦点を当てている。
そして今書いているこの記事は、その後で悩み事や疑問が発生したとき、「実際必要になったとき」の方に重点を置いている。
「実際必要になったとき」の立場から考えると……どうしたらいいんだろう。
いつどこで「実際必要になって」役立つか分からないけど、普段からいろいろと読んでおいて、頭の中にインデックスを作っておくのが望ましいのかな。
それがいつ実際に役立つかは分からないので、なかなか読書の労苦がいつ報われるのか分からないというのは難しい話である。うーん。

あんまりきれいな結論もないけど、今日はこれまで。
それでは。

*1:蛇足：この部分を書いていたときのツイート