この記事は『エンジニアの知的生産術 ―効率的に学び、整理し、アウトプットする』の感想文です。

エンジニアの知的生産術 ―効率的に学び、整理し、アウトプットする

何を期待してこの本を読んだのか?

タイトルの通り、ソフトウェアエンジニアとしての生産性を高める術はないものかと思い、本書を手に取りました。著者の西尾さんの文章をウェブでよく拝見しており、学ぶことが多かったので期待値は高めでした。

期待に応える本であったのか?

「期待に応える本であったのか?」という問いに対する短い返答は「いいえ」です。この本を読むことで、僕の知的生産性が高まったかといえば、そんなことはないと思います。一方で「この本を読むことは時間の無駄であったか?」と問われれば、それも「いいえ」です。

この本が参照している『難解な本を読む技術』には「開いている本」と「閉じている本」という概念が登場するそうです。

開いている本は、読者が自分で考えることを期待して、著者が自分の意見を言っていない本です。閉じている本は、著者が自分の結論を持っており、そこへ向けて論を進める本です。 世の中の多くの本が閉じているのに対して、哲学書には開いている本が比較的たくさんあります。本書『エンジニアの知的生産術』は、私が「情報収集・モデル化・応用」のサイクルなどいくつかの結論を持っていて、それを構築していっているという点では「閉じている本」です。しかし、その私の結論の1つが「具体的にどういう方法でやるかは読者の置かれた状況によって決まるので、読者は自分でそれを構築しなければならない」なので、具体的な方法論に関してはかなり「開いている本」の立場をとっています。

確かに『エンジニアの知的生産術』はかなり「開いている本」です。

たとえば、本の読み方について扱った章では、「速読 (フォトリーディング) する技がある」「繰り返し読むという方法もある」「完全に理解できるまで先に読み進めないという方法もある」「完全に理解することをあきらめてどんどん読み進めるという手もある」などと書かれています。どういう本に対してどういう選択肢を取るかは読者にゆだねられます。

僕は「何も言っていないに等しいのではないか」と感じました。

一事が万事、このような感じで議論が進められており、良く言えば「多方面からの意見を拾っている」ものの、読者としては「結局のところ、どうすればいいんだ?」と思わされました。

「はじめに」の節には次のようにあります。

私は … 業務の一環として、京都大学サマーデザインスクールで、考えを整理してアウトプットする方法のワークショップを行ったり、首都大学東京の非常勤講師として、大学生に研究によって新たな知識を生み出すことについて教えたりしてきました。しかし、限られた時間では伝えたいことが伝えきれません。参考書を紹介しても、たくさん紹介したのでは全部は読んでもらえません。私の伝えたいことが1冊にまとまった本が欲しいです。

この取り組みは、ある種の成功を収めていると言えます。つまり、本書の中では「Getting Things Done」や「ポモドーロ・テクニック」、「フォトリーディング」や「KJ 法」など、それだけで一冊の本が書ける (実際に書かれている) 内容がごった煮されています。

しかし、どのトピックも表面的にしか触れられておらず、たとえば「明日からはこういう方法を試してみよう」と思えることはありませんでした。

まとめ

『エンジニアの知的生産術 ―効率的に学び、整理し、アウトプットする』を読むことで知的生産性を向上できる人は限られているように感じました。

なお、この本のレビュワーの方からも 「で、どうしたらよいの?」がわからない という意見があったそうです。これに対して、著者は次のように答えています。

材料がそろっていないと、結合は起きません。「地」は経験です。本書を読んでしっくりこなかったなら、今回は残念ながら材料が足りなかったようです。でも大丈夫です。経験は日々あなたの中に蓄積されていくので、いつか「あ、これか」とつながるときが来るでしょう。半年経ってからまた読みなおしてみてください。きっと何かが変わるでしょう。