Pragmatic Programmers 20th Anniversary Edition-書評

最初にPragmatic Programmersを読んだのは、15年ほど前だったと思います。当時の私はJavaを主に扱っていましたが、「なるほど、こんな考え方があるのか」と思う程度のものでした。次に読んだのは約５年前でしたが、様々なエンジニアリングの現場を経験してから読むと、知恵の宝庫のように感じました。最初に読んだ時は技術開発の経験が少なかったために、100％理解していなかった点や、共感できない点が多かったのですが、ある程度経験を積んでから読むと、眼から鱗な内容が次から次へと出てきます。

そんなPragmatic Programmersですが、20周年記念の本が出ると聞いた時は、内容を変えずに再リリースするだけかと思いましたが、本を開いてみると、20年前に発行されたものよりも良い本になっていました。

まず、登場するプログラムや具体例はより現代使われているものが登場します。例えばDSLを紹介するセクションでは20年前の原本はWindowsやメインフレームを対象としたプログラム例が出てきますが、今回の20周年記念ではRSpecなどのテスト用のフレームワークを紹介しています。RSpecといえば、20年前はTDDなんていう言葉は存在しませんでしたが、今はTDDなしにはテストのことを語れません。今回の20周年版はTDDについても言及しています。具体的には、TDDの奴隷になるな、というテーマで、TDDを提唱しすぎると、実際に自分が解こうとしている問題がなんなのかを見失う危険性があるとしています。その例として、TDDでSudokuを解こうとしたRon Jeffriesのブログと、純粋な問題解決としての観点からSudokuを解こうとしたPeter Norvigのブログを紹介していました。この二つのブログは読んでみて面白いと感じました。Jeffriesはプロセスを重視するあまり、一体どんな問題を解こうとしているのかという大局観を見失ってしまっている中、Norvigは淡々と問題を解き、さらに「難しいパズルを生成するにはどうすれば良いか」という応用問題まで説いていきます。

最近はCTOという立場上、プランニングに費やす時間と見積もり力が求められる場面に多く直面します。今回の20周年版では、PERTという米国海軍が使っている見積もりの手法が紹介されていて、参考になりました。見積もりが正確でない時の原因は、「分からないから数字を膨らませる」ということから起きることが多いため、不確実な現象や作業の工数を見積もる場合に「消極的」、「積極的」、「確率が高い」という３ケースを想定して、それをベースにプロジェクト全体の工数と時間を見積もるという方法です。著者たちは「アジャイル」なプロセスを提唱するので、このPERTも一つのやり方だが、やはり正確な見積もりにはならないとしています。「どれくらい時間がかかるか」という質問に対しての正解はただ一つ、「I’ll get back to you」（検討してお返事します）らしいです。（笑）これは20年前から変わっていません。

最後に、ソフトウェア開発という職業について、こういう言葉で結んでいます。「We start with a blank page, and we can create pretty much anything we can imagine. And the things we create can change the world」（我々は真っ白な画面から始めて、想像できる限りのものを創り出すことができる。そしてその創作物は世界を変えることができる。）

FacebookやUberなどのテクノロジー企業への風当たりが強くなっていて、ソフトウェア開発者としては複雑な心境の時代になりつつあります。でも、Dave ThomasやAndrew Huntのようなプログラミングにおける歴戦の古豪がそういうのであれば、「世界を良い方向に変えうるプログラム」を目指してキーを叩き続けようと思える良書でした。