入社1年目に読んでよかった技術書まとめ

  • 74
    いいね
  • 0
    コメント
この記事は最終更新日から1年以上が経過しています。

読んだ技術書のことを紹介するポエムです。といいつつ、本当に「技術」かというと、「ソフトウェア開発の周辺の思想書」の紹介が多いです。

選出にあたっての原理・原則

プログラマとして仕事をするにあたっての基礎を身につけるのが1年目だとするならば、プログラマというものの動作原理、物理でいうところのニュートンの運動の法則みたいな原理を知る必要があると思います。しかしプログラマの営みは人間の営みなのでそう統一的な理論が存在するわけではなさそうです。「プログラマかくあるべし」「プログラミングかくあるべし」が炎上しがちなのを見るとそう言えるでしょう。

それでも真理と言える、否定する人がいない原理として:

  • 学び続けない者は死ぬ
  • チームで開発できない者は(ごく一握りの天才とラッキーパーソンを除いて)死ぬ

ということは言えると思います。以下、今年度読んだ本(と読みかけた関連する本)から、それぞれについての「読み物」と、「具体的な技術の本」をまとめて紹介しようと思います。

紹介しない本

  • 新人かくあるべし、社会人かくあるべし的な本
  • SEかくあるべし的な本
  • 会社の仕組み・経済の仕組み的な本

社会人基礎とかいう概念に吐き気を覚えてる程度のペーペーの新人がこういうこと書くよりは、IT業界の闇に深く通じるベテランのエンジニアやマネージャーが新人かくあるべしみたいな記事を書くのを待ったほうが有益だと思ったので書きません。

学ぶということについて、「読み物」

★Becoming a Better Programmer / Pete Goodliffe 著; O'Reilly Media, 2014

2014/10に原著英語版が出たばかりで、日本語版は未発売。

タイトルの通り、よいプログラマであるためにはどうするべきか、というTips集。よいコードを書くためのテストとかリファクタリングとかといった話も当然されますが、特に重要だと思った視点として、「コードを愛せ」(Care about code)、「変わらないものはない」(Nothing is set in stone)ということが繰り返し主張されることがあります。学び続けることは必然的にコードへの愛を必要とすることで、ここを強調したのは面白い視点だと思いました。
プログラミングの仕事をする上でのよい習慣を、仕事の全領域、チームメンバーやQAとの関係性というところまで全領域にわたってカバーしてくれていて、勇気付けられる言葉も多い(悪いコードに出会ったときは改善することでステップアップするチャンスと思え、という言葉に何度助けられたことか!)ので強くおすすめします。日本語版の出版に期待。

★アプレンティスシップ・パターン - 徒弟制度に学ぶ熟練技術者の技と心得 / Dave H. Hoover・Adewale Oshineye 著、柴田芳樹 訳; オライリージャパン, 2010

プログラマのキャリアの初期段階を「アプレンティス」=徒弟制度における見習いとみなし、そこから「ジャーニーマン」「熟練職人」へとステップアップしていくための初期段階の学びをどのように組み立てていくか、どのような心がけを持つとよいか、というアドバイス・ヒント集。…と書いてしまうと「親方にはおとなしく従え」的なものを想定しがちだがそんなことはない。謙虚であれということも、熟練者からより多くを学び取るために必要なこととしてそうあるべきと説かれるように、よりよい学び方にフォーカスを置いた心がけが示されます。本書の「演習問題」は技術的な内容は特に示されないが数年単位で時間をかけて考えるべき課題が示されるので、いかに技術者の道が「長い道のり」であるかを思い知らされることでしょう。

Clean Coder - プロフェッショナルプログラマへの道 / Robert C. Martin 著, 角征典 訳; アスキー・メディアワークス, 2012

タイトルからは想像しにくい内容ですが、本書の主張は「倫理的にCleanなCoderであれ」、と言い換えればタイトルとの関連がわかりやすくなります。プロフェッショナルなプログラマの規範を著者の経験談(しかもその多くが「若気の至り」での失敗談である。これだけ著名なプログラマなのに!)をもとに語った本。とはいえこの規範を守るのは容易なことではない。「不可能なことにNoと言え」ということを守れている人はどれだけいるだろうか?「とりあえず〜してみます」と言ってしまっていないだろうか?無理であることはきっちり意見せよという感覚や残業は交渉した上で最終手段として行えという感覚は日本では聞いている限り非常に稀な感覚ですが、このような理想を持つことは悪いことではないでしょう。

ハッカーと画家 - コンピュータ時代の創造者たち / Paul Graham 著, 川合史朗 訳; オーム社, 2005

LISPハッカーでありY Combinatorの創立者(確かにLISPerらしいネーミングだ!)であるPaul Grahamのエッセイ集。個人的に興味を惹いたのは「どうしてオタクはもてないか」「口にできないこと」「格差を考える」といった社会をオタク(nerd)の視点で表現しなおした章や、プログラミング言語には優劣が存在すると明確に言い放った「プログラミング言語入門」「普通のやつらの上を行け」などの章でした。ソフトウェアの世界、コンピュータの世界は「普通のビジネス」と違うというが、その違い、「コンピュータオタク」の視点をわかりやすく表現しています。著者のサイトには出版後に書き足されたエッセイも公開されています。

WEB+DB PRESS Vol.80 / 技術評論社, 2014

「新人応援号」ということでWeb入門・UNIX環境入門といった趣の記事も多いのですが、特に目を引いたのが「エンジニアの学び方」というコーナー。「学び」という営みのモデル化が腑に落ちる形で示されていたのが非常に好感触でした。ちなみにこの記事を発端に現在ではWeb連載記事ができています

プログラマが知るべき97のこと / Kevlin Henney 編, 和田卓人 監修, 夏目大 訳; オライリージャパン, 2010

著名プログラマによるエッセイ集。@t_wadaさん講演会がこれに基づいたもので、それを受けてかなり早い段階で手にとってみたのですが、改めて読み返してみると多くのベストプラクティス本に書かれているようなことは大抵ここになんらかの形で書かれていました。インデックスを張る意味でもよい読み物で、強いて推すならば、歴戦の猛者の実体験の重みがある分でも外せない。

チーム開発について、「読み物」

職業プログラマはチームで開発するもの、という原理について否定する人は少ないと思いますが、そのチームの形態は分野や習慣によって大きく違うため、チーム開発という話題も戦争が起きやすいようです。主にアジャイル陣営vsウォーターフォール陣営になると思いますが(もうその対立すら終わったという話もある)、自分が仕事をしている分野はどちらかというと「軽いプロセス」(=アジャイル寄り)を取ることの多い分野なので紹介する本も「アジャイル」や「Extreme Programming」に端を発する考え方が多いです。「重いプロセス」をちゃんと回す話については PMBOK とか CMMI とかのキーワードで探すといいらしいです。

チーム開発の思想的側面と実際的側面の2つの観点から紹介します。

思想

★Team Geek - Googleのギークたちはいかにしてチームを作るのか / Brian W. Fitzpatrick・Ben Collins-Sussman 著, 角征典 訳; オライリージャパン, 2013

成功するプログラミングチームを作るためのコミュニケーションの方法を解説した本…という表現では説明し足りないでしょう。「人間関係のデバッグ」を行う本、としたほうがわかりやすいかもしれません。チームの構成員に対する「謙虚・尊敬・信頼」の原則をベースに、チームの文化の醸成・リーダーシップの取り方などを説明しています。non-engineerの管理系の人にこういう話が通じたらどれだけ嬉しいことか!

パターン、Wiki、XP - 時を超えた創造の原則 / 江渡浩一郎 著; 技術評論社, 2009

「デザインパターン」などに見られるパターンランゲージの発展と、Extreme Programmingやアジャイルの思想を広げることを手助けしたWikiの成立の歴史を追いかけた本。パターンランゲージはコンピュータ書でよく見かけるのでコンピュータの世界かもしくは数学の世界から出た言葉だと思っていたが建築の世界から出ていたとは思わなかった。具体的な技術を学べるわけではないが、思想の歴史を知りたいという人にはよいと思います。

アジャイルサムライ − 達人開発者への道 / Jonathan Rasmusson 著, 西村直人・角谷信太郎 監訳, 近藤修平・角掛拓未 訳; オーム社, 2011

アジャイル開発の中身・真髄をマスター・センセイが弟子に説く、というスタイルの本。Manifesto for Agile Software Developmentを下敷きにして、なぜアジャイルの個々のプラクティスを行い、どのように回していくか、を解説します。ありがたいことに多くの方法論はチーム内ですでに実践されていますが、これを自分がチームを運営する側になったときにちゃんと説明し導入できるか、というところまで考えると道は長そうです。

実際的な話

リーダブルコード ― より良いコードを書くためのシンプルで実践的なテクニック / Dustin Boswell・Trevor Foucher 著, 須藤功平 解説, 角征典 訳; オライリージャパン, 2012

読みやすいコードとはどういうものか、また読みやすいコードをどうやって書けばよいかを解説した本。実際のコードの書き方の話がチーム開発にどう関係があるんだ?という疑問が起こるかもしれませんが、読みやすいコードを書くことはチーム開発をやる上ではどうしても避けられません。チーム員のコードが読めなければ、またチーム員にあなたのコードが読んでもらえなければ共同作業なんてできないからです。

Redmineによるタスクマネジメント実践技法 / 小川明彦・阪井誠 著; 翔泳社, 2010

タスク管理ツールRedmineの使い方と、Redmineのチケットを作業単位としてプロジェクトを管理する「チケット駆動開発」を紹介する本。チケット駆動開発という名前を使うかどうかはともかく、タスクを分割しシステム上でタスクの追跡を行えるようにすることがチームとしてよい習慣であることはかなり疑いの余地はないでしょう。プロジェクトに関するいわゆる「報連相」がこのツールの上でほとんど行われてしまうのだから非常に強力なツールといえます。

チーム開発実践入門 - 共同作業を円滑に行うツール・メソッド / 池田尚史・藤倉和明・井上史彰 著; 技術評論社, 2014

こちらはRedmineでのチケット駆動開発に限らず、チーム開発におけるよいツールや方法論を網羅的に紹介した本。Gitでの分散バージョン管理とワークフロー、Jenkinsを使った継続的インテグレーション(CI)などといった考え方は開発現場で非常にお世話になります。これらの方法論なしにチーム開発をやることはもう考えられない体になってしまいました。

具体的な技術の本

カバレッジを広げる

具体的な技術の本でジャンル横断的に扱っている本はなかなか少ないですが、プログラミング言語の選択に関しても非常に多くの意見が渦巻いている現在、ジャンル横断的なコンセプトについて「インデックスを張っておき」議論についていけるようになる必要性は高いといえます。その観点ではPragmatic Bookshelfの"Seven in Seven"シリーズは単なるインストールガイドとチュートリアルにとどまらず紹介対象の思想まで学ぶことのできる良書と思います。

  • ★7つの言語 7つの世界 / Bruce A. Tate著, まつもとゆきひろ 監訳, 田和勝 訳; オーム社, 2011 : 紹介対象は Ruby, Io, Prolog, Scala, Erlang, Clojure, Haskell。
  • 7つのデータベース 7つの世界 / Eric Redmond・Jim R. Wilson 著, 角征典 訳; オーム社, 2013 : 紹介対象は PostgreSQL, Riak, HBase, MongoDB, CouchDB, Neo4J, Redis。

具体的な言語の本

私がプログラミング言語の本を読む際には「最初から入れて応用的トピックまで見える本」と「言語設計者もしくはそれに近い人が書いたリファレンス的な本」を1冊ずつ以上読むようにして「実用的な話」と「正しい話」の両方を掴むように心がけています。今年読んだ本はどちらかというと後者のほうが多い…のですが、Scala・Elixir・Dは「実際の現場で使ってみた」みたいな話は本にはまだあまりなっておらず、これからコードを読んでいく中で身につけていくしかなさそうな感じです。もっとも、そうすることがプログラマとしてのステップアップには必要そうなのですが…

  • パーフェクトRuby / Rubyサポーターズ 著; 技術評論社, 2013
    • Rubyは洋書や訳書よりも日本語のほうが最新の事情を反映しているケースが多いようです。
  • Programming Elixir / Dave Thomas 著; Pragmatic Bookshelf, 2014
    • 日本語版未発売。
  • プログラミング言語D / Andrei Alexandrescu著, 中川真宏・原健治 監修, 長尾高弘 訳; 翔泳社, 2013
  • Scalaスケーラブルプログラミング第2版 / Martin Odersky・Lex Spoon・Bill Venners 著, 羽生田栄一 監修, 長尾高弘 訳, 水島宏太 特別寄稿; インプレスジャパン, 2011
    • 通称「コップ本」。