学習効率の良い書籍の読み方

書籍の読み方には2種類ある

書籍の読み方には大別して2通りある。最初から最後まで読む通読と、必要な箇所をピックアップして読む参照だ。 通読は小説を、参照は辞書を想像してもらうと良い。

技術書は実用書であり、後者の参照に向いている。 パターンのカタログのような書籍は特にそうだ。PoEAA 、GoFのデザインパターンはもちろん、リファクタリング、レガシーコード改善ガイドなどは、通読するより必要に応じて参照する方が良い。著者もそのことを知っていて、実は序文や第1章に通読より参照してほしいと書かれているケースがある。

参照方法は簡単だ。まず解決したい疑問を頭に浮かべて目次、もしくは巻末の索引からキーワード探す。自分の疑問に答えてくれそうな箇所があればそのページに飛んで読む。 その中で知らない単語があったり、参考文献が紹介されていればそれを辿って読む。知らない単語がある場合、大抵同じ書籍内の別の箇所で解説されている。答えや思索を深める記述にたどり着けなければ、本を替えて同じことをする。

書籍を横断して一つのテーマを読むこの方法をヨコ読みと私は呼んでいる。 頭から最後まで読む方法はタテ読みだ。通読から熟読、さらに韋編三絶とまで行けば良いのだが、長い文章の中から目的の、あるいは自分が面白いと思う情報を探すような浅い読み方なら「通読」よりもタテ読みの方が似つかわしいように思う。もちろん自分独自の言葉ではなく、本のタテ読みヨコ読みナナメ読みは昔からある言葉だ。

そのヨコ読みといえども、やっていることは Web 検索と変わらない。 Google が書籍の目次になり、リンクが知らない単語や別の参考書籍になり、検索結果に上がってくる別の Web ページが他の書籍になるだけだ。

ヨコ読みを実践する

エッセンシャルスクラム

最近、この読み方で業務中に生まれた1つの疑問を解消できた。それは、「toC サービスにおいて、あるプロダクトにおける新規機能のレビュー者は誰が適切なのか」というものだ。

この疑問を持った前提として、プロダクトオーナーはチーム内にいてユーザーのことをチーム内で一番よく知っているものの、純粋なプロダクトのユーザーではない。このため、プロダクトオーナーがよしと言っても、ユーザーが本当に喜ぶかがわからない。よって、レビュー者を外部ユーザーに依頼するべきではないか、しかし単発ならまだしも、定期的なレビューであれば協力者を探すのが大変なため簡単にはできない、さてどうしたものかとチーム内で議論が膠着した。

そこで、スクラムではどのように考えられているのだろうと、エッセンシャルスクラムのスプリントレビューの章を読んでみた。すると、計10ページほどの記述の中で、まさに上記の議論が既にされていた。要約すると「プロダクトのレビューは、内部ステークホルダーで完結するならそれで良いが、定期的に外部ステークホルダーにも参加してもらうと良い」とのこと。

さらに「誰かを招待する時には、常識だけではなく熱意と人格を考慮すると良いだろう」という有益なアドバイスも書かれている。 このように具体的な解決方法の指南のみならず、著者のエピソードが豊富だったり、単なる Q&A 以上のお節介なことが書かれているというのは、エッセンシャルスクラムに限らない分厚い技術書の特徴の一つだ。

レビューについてもう一冊読んだ気もするが忘れてしまった。「プロダクトのレビュー者を誰にするか」という同じ疑問を持ってリーンスタートアップを読むと良いかも知れない。それでは良い読書体験を。

エクストリーム・プログラミング

と、ここで筆を置こうと思ったが、流石に締まりが悪いのでもう一冊実際に読んでみる。 エクストリーム・プログラミング（第2版）の「本物の顧客参加」というプラクティスから引用する。

顧客参加のポイントは、ニーズをもつ人とそれを満たす人が直接やりとりをして、ムダな労力を減らすことである（エクストリーム・プログラミング 2nd Edition、p. 59）

本物の顧客がいなければ、あるいは本物の顧客の「プロキシ」しかいなければ、使われないフィーチャーを開発したり、本物の受け入れ条件を反映していないテストを仕様化したり、（中略）、さまざまなムダを招いてしまう（同 p.60）

前後の文脈から、XP の想定する顧客は toB の受託開発のように読めるが、上記の警告は toC にも当てはまる。

このように、同じテーマの疑問を持って複数の書籍に当たるヨコ読みは、疑問を解決するだけでなくそのテーマの立体的な理解に役立つ。

上記のようにエッセンシャル・スクラムとエクストリーム・プログラミングという2冊の著者が異なる書籍を開くことで、「toC のプロダクト開発で機能のレビューは誰がするべきか」という問いの一定の答えがわかるだけでなく、ソフトウェア開発におけるプロダクトのレビューの目的とアンチパターンも語れるようになった。 つまり、ヨコ読みは学習効率が良いのだ。

なお、上記で答えは答えでも「一定の答え」と書いた。それは、科学的なプロセスを経て辿り着いた真実ではないが、現場で実践するには十分なアイデアとプラクティスではあるというニュアンスを含めているからだ。偉人の経験が詰まった書籍も万能ではない。できれば信頼に足る論文に当たるのがベストだという注意書きを持って本記事の締めくくりとしたい。