技術ドキュメントを読む速度

あおぞらAndroid教室でプログラム素人にプログラムを教えていると、 プログラムの解説を読むのがすごく遅い、という事に気づく。

自分にとってプログラムの本を読むのは娯楽なので、 あんまり早く読もうとはしていないし、 その結果として自分はプログラムの本を読むのがそんなに早くも無いと思っている。 だが、その自分と比較しても何倍も遅い。 なので自分（や普通のプログラマ）がプログラムの本を読む速度が早い理由を考えてみたくなった。

構造の予想と内容の予想

例えば今、【書籍】CppConcurrencyInActionを読んでいる。 けれど、読んでいる内容は文字の半分以下なんじゃないか。 普通のプログラマは、プログラムの本を全部は読んでないよな。

章のタイトルを見て、節のタイトルなどを見て、そこで何が書いてあるのかとかを予想して、 適当にパラパラ見つつサンプルコードとかはちょっと時間を掛けて見て、 コードで説明したいであろう事とその後の説明が一致しているのを見て、 説明が一致しているのを確認したらそれが終わるまでは飛ばしている。 たまに予想外の事があるともう少し戻って読み直したりする。 大半は読んでるんじゃなくて、たぶんこういう事が書かれているんだろうな、という事を確認しているんだよな。 なんかマッチングしているだけで、読んでない。

でもこういう読み方の方が、理解は圧倒的に深いし記憶にも良く残る。 しかも本を読むモチベーションとか集中力を保つのにも役に立っている。 たぶん飛ばしたりそういう判断をする所で休んでいるんだよな。 実際には読む時間を減らしているんだよな。 そして手戻りも少ない。 なんかまっすぐ全部読んでいくと、なんかぼーっとしたりして、「あれ？今何読んでたっけ？」みたいなのがなったりして進みが悪いんだよな。 内容を予想してマッチさせていくだけの方がそういう手戻りが無い。

一方で、何か重要な所では止まって、ググったり他の情報源を見たり、 実際にPCで動かしたりして試したりする。 緩急があるんだよな。

読むのが遅いのが予想の欠如だとすると、その理由は以下の２つがある気がする。

• そもそも予想をしようとしていない、予想を訓練した事も無い
• 予想出来る予備知識が無い

例えば新しい言語を学ぶ時には、プログラムの言語の本というのがどういう構成で書かれているかはだいたい知っているんだよな。 他の言語の本をいっぱい読んできたので。 新しい言語は内容は知らないんだろうが、どういう順番でどういう話があるかはだいたい知っている。 だから構造の予想は最初から出来る分、予想しなきゃいけない事が少ないんだよな。 しかも四則演算とか制御構造とかは内容までも知っている事が多くて飛ばせる。

知識だけじゃなくて、同じような事を何度もやっているから、練度にも違いがある気がする。

読むのが遅い人を見ていると、あまり構造に目を向けない。例えば目次とかを何度も見たりしない。

こういうのは理系の教科書とか読むにはみんなやっている事に思うし、 論文とかでもやっていると思うので、プログラマどうこうでは無いが、 こういうのを全くやってこなかった人というのも世の中には一定数いて、今教えているのはそういう人たちに思う。

そういう理系の普通の基礎スキルみたいなものと、そもそもプログラム界隈でのサンプルの多さから、 プログラマはプログラムの本やドキュメントをめちゃ早く読めるという事なんじゃないか。

そのドキュメントで分かる事と分からない事を見分ける能力

あと、見ていると、分からない事に対する慣れが大きく違う気がする。

なんか技術系のドキュメントは「そんな説明じゃ分かるわけ無いじゃん！」みたいなのが結構あって、 我々はそういうのに慣れているよなぁ。 例えばKotlinのツアーとかを読んでいて、 なんか分かりそうに無い話が出てきても「これはこのツアーじゃ分からなくてリファレンス読みましょうって事ね」と判断出来る。 mimallocの論文とか読んでいても、 この辺はこの論文では良く分からないのでソース読むか、と判断出来る。 Googleの良く分からない社内システムにつながっています、とか言われても、 知らんがな、と思いながら先に進める。

一方で、自分は分かってないがそのドキュメントで分かるはずの事で、 出来たらここで分かっておきたい事、というのもなんか判断出来るよな。 分からない事を全部分からないと飛ばしてしまうんじゃなくて、 そのドキュメントを読んでいる目的みたいなのが心の中にあって、 それに必要な所はちょっと頑張る。 分からない事を全部飛ばすなら誰でも出来るのだが、 この飛ばすヤツと頑張って踏みとどまるヤツの判断というのは、 言われてみるとなんで分かるのか謎が多い。

これもやっぱり、なんかそのドキュメントの種類みたいなのに対する慣れがあるんだよな。 ツアーだとこんな事が分かっていれば良い、 とか、プログラム言語の本のこの章はこれが分かっていれば良い、 とか、そういう事を、程度の差はあれどある程度知っているんだよな。

技術ドキュメントを読む練習がいるんだろうか？

教えていると、技術ドキュメントはもっと早く読めた方が良い気がする。 そして訓練すれば早く読めるようにもなる気がする。

でも一方で、自分も別に早く読む訓練とかしてないし、 もっと言えば早く読もうとすらしていない。 絶対にここ読むの無駄だよな、と思いながら読んでいる所も結構ある。 実際自分は無駄なもの読んでないでもっとさっさといろいろ読んだ方が、 きっと良いプログラマなんだろうな。 なんか自分でやってない事を人にやれというのもなぁ、という気もしてしまう。

そうは言っても、ツアーをざーっと読んで分からない所はリファレンス見たり他の情報源に当たったり、 みたいなのはプログラマの日常で、 それを一定以上の速度では出来る必要はある。 どの速度以上なら十分なのかは良く分からないが、 さすがにこれは遅すぎだろう、という速度の時に、 そういう練習をするのは必要な事なのかもしれない。

でもそんな練習とか、やらせてるのもしているのもあんま見ないよな。 論文を早く読むとかはそれなりにある話だが、 技術ドキュメントでそういう話って見た事無い気がするな。

うーん、なんか教えてみるか？何を教えたらいいんだろう？ とりあえず自分がやっているようなことを練習させてみるのか？

追記：少し考えた事を書き出している＞技術文書の読み方 - RandomThoughts