勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

翔泳社さんの技術書がKindleでセール中の模様

定点観測結果。久しぶりに割と翔泳社さんの大型技術書が50%前後オフのセールになっている模様。
これですね。10/2まで。

めぼしい、既読を中心におすすめのものをピックアップ。

組織パターン

組織パターン

  • いわゆるソフトウェア開発組織改善のタネ本。よくある悩みがパターン化されているので、よく読み返してるな。

エッセンシャル スクラム

エッセンシャル スクラム

  • すいません、実は未読です。

実践ドメイン駆動設計

実践ドメイン駆動設計

  • すいません、実は積読です。

旧書の類

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

  • 最近DDDの話題が盛り返している印象もありますが、原典として。

レガシーコード改善ガイド

レガシーコード改善ガイド

  • いつ果てるともないレガシーとの戦い方。

エンタープライズアプリケーションアーキテクチャパターン

エンタープライズアプリケーションアーキテクチャパターン

  • 再読しているのだけれども、こちらも名著の類ですね。

他に、情報処理技術者試験対策本もセールになっている模様。
受験予定の方はチェックしてみると良いかもしれない。

久しぶりにKindleで20%オフの大規模セールで技術書が買い時かも

昨日くらいから、Kindleで割と大規模にポイント還元が始まっている模様。20%ポイント還元。最近こういったセールの頻度が下がっている印象もあるので、要チェック。個人的な観測では「みんなではじめるデザイン批評」が初めてセール対象になったような気がしてて、購入するか迷っている。

値引きが大きいもの

C#実践開発手法 デザインパターンとSOLID原則によるアジャイルなコーディング

C#実践開発手法 デザインパターンとSOLID原則によるアジャイルなコーディング

残念ながら未読。気にはいるのだけれど・・・
ポイント還元も考慮すると実質半額。

プログラミングの心理学 【25周年記念版】

プログラミングの心理学 【25周年記念版】

名著のひとつ。とりあえず「なか見検索」ができるので内容を確認すると良い。
ポイント還元も考慮すると実質半額以下。

Code Complete 第2版 上 完全なプログラミングを目指して

Code Complete 第2版 上 完全なプログラミングを目指して

こちらも名著のひとつ。上巻だけだけどポイント還元も考慮すると実質半額以下。
とはいえ、世の中にはこういった意見もあるのでご注意。

とにかく長すぎる。名著ではあるのだと思うが、時間に余裕があるか「俺はあの Code Complete を読破したんだぞ!」という満足感を得たいのでもなければ、もはやわざわざこの本を読まなくてもいいと思う。重要なトピックごとに、もっと深く掘り下げていてこれほど長くはない本がある。特に、良いコードを書くための知識については「リーダブルコード」のほうが良いと思う。

その他めぼしいもの

みんなではじめるデザイン批評

みんなではじめるデザイン批評

  • 作者: アーロン・イリザリー(Aaron Irizarry);アダム・コナー(Adam Connor)
  • 出版社/メーカー: ビー・エヌ・エヌ新社
  • 発売日: 2016/07/26
  • メディア: Kindle
  • この商品を含むブログを見る
未読。最近出た本。冒頭にも書いたけれど、初めてここまで値段が下がった気がする。
この記事を読んで、購入するか迷っているところ。

SOFT SKILLS ソフトウェア開発者の人生マニュアル

SOFT SKILLS ソフトウェア開発者の人生マニュアル

既読。良い本なのだけれども、あまり真新しい事は書かれていない。
他の話題の自己啓発本を読んでいるようであれば、手に取る必要はないかも。
ただ、非常に読みやすいのでこの手の本を読んだ事がなければお勧め。

未読。気になっているのだけれども読む時間が作れない。

こちらも未読。

サーチ・インサイド・ユアセルフ ― 仕事と人生を飛躍させるグーグルのマインドフルネス実践法

サーチ・インサイド・ユアセルフ ― 仕事と人生を飛躍させるグーグルのマインドフルネス実践法

既読。興味深いのだけれども、タイトル通り瞑想に関する本なので注意。
かなり意識高くないと、ひとりで実践は難しい印象。

既読。これも技術の本ではないのだけれどいろいろ参考にしている。良書。

How Google Works

How Google Works

既読。Googleがすごいってことはわかる。しかし真似できないよ、という感想。

テストから見えてくるグーグルのソフトウェア開発

テストから見えてくるグーグルのソフトウェア開発

既読。個人的には、本書をテストの本ではなく組織改革の本だと思っている。
学ぶ事の多いお勧めの一冊。

エンタープライズアプリケーションアーキテクチャパターン

エンタープライズアプリケーションアーキテクチャパターン

いま実は再読している。高額なので購入のチャンスかも。
ただ、翔泳社の木曜セールでもっと割引される日が来るかもしれない。

ソフトウェアシステムアーキテクチャ構築の原理 第2版

ソフトウェアシステムアーキテクチャ構築の原理 第2版

既読。アーキテクトの教科書としておすすめ。高額なので購入のチャンスかも。

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

既読。難しいけれど得るものが多い良書。高額なので購入のチャンスかも。
ただ、翔泳社の木曜セールでもっと割引される日が来るかもしれない。

実践ドメイン駆動設計

実践ドメイン駆動設計

積ん読中。まずい。高額なので購入のチャンスかも。
ただ、翔泳社の木曜セールでもっと割引される日が来るかもしれない。

既読。エンタープライズアジャイルといった事を検討しているSIer所属の人におすすめ。
こちらも高額なので購入チャンスなのだけど、翔泳社の木曜セールでさらに割り引かれる可能性はある。

他にもいろいろセール対象になっているみたいなので検討している本があればチェックしてみるのがよいかと。

週報 / Snippetsのススメ

昔から習慣として「週報」を書くということをしている。最近発売された「 SOFT SKILLS 」という本を読んでいたら週報を書くことについて言及されていて面白かったので、「週報」についての自分の考えなどを整理してまとめてみた。

新しい会社に入るたびに私がまずしていたのは、何に時間を費やし、その日に何を達成したかを日録に書くことだ。その内容をもとに、毎週金曜日に週間サマリーを書いて上司に送ったのである。私はこれを自分の「週報」と呼んでいた。(中略)この週報は、私の存在をアピールするために役に立っただけでなく、人事考課の時期には自分自身にとっても役立つ資料となった。週報を読み返して、その年の主要な達成を拾い出せばよかったのである。自己評価を書くとき、私はその年にしたことを日付とともに正確に書けたのである。
SOFT SKILLS ソフトウェア開発者の人生マニュアル/第9章 出世階段の上がり方

SOFT SKILLS ソフトウェア開発者の人生マニュアル

SOFT SKILLS ソフトウェア開発者の人生マニュアル

週報の習慣

別に自慢するようなことでもないし人に強制するようなことでもないのだけど、個人的には日次の作業ログと、週次のまとめ(いわゆる週報)は随分と昔から書く習慣になっている。指示されてというより、自発的に書いている。

  • 日次の作業ログは、もともとはお客様まわりのトラブル回避を目的に始めたような記憶がある。いわゆる「言った、言わない問題」に抗弁するため(その話は何月何日の会議で言われたと記憶してますが違いますか?と言えるように記録してる)。実際作業ログ何度も救われており、成功体験が習慣化を強化している。
  • 出来るエンジニアはログをつける、というハッカー文化への憧れ(?)
  • GTDブーム以降、始業時にタスクを洗い出して着手するスタイルになったので、これに実績を書き込んで日次ログを作成。
  • 最近はGoogle Calenderと連携してEvernoteに日次作業ログのたたき台を自動作成して若干省力化。
  • 週報はだいたい週末に、その週の日次ログと積み残しのタスクリスト、次週のカレンダー等をインプットに週のふりかえりを行いながら執筆。GTDで言う「週次レビュー」の代替としてやる感じ。
  • 書いた週報をメールで関係者に送付。2レベル上の上司、直上司、関係するグループの同僚を宛先に入れる。
  • プロジェクトによっては計数の報告を定期的に行うこともあるけれど、それとは別扱い。
  • 反応はほとんどないけど、何かあった時などに「ああ、あの話ね」で済むので便利。
  • 体調不良や家庭の事情で休む時も引継ぎが楽なのもメリットである。

週報のフォーマット

自分のよく書くパターンはだいたいこんな目次。

  • ロール別のトピック
  • プロジェクト別のトピック
  • ネタ、雑感(最近読んだ本、技術ブログ紹介やプライベート関連トピックなど)
  • 来週の予定サマリー

それぞれの項目について普通に文章でやったこと、次にやることを書いている。ただ、前週の内容をコピーして追記する形式にしないように気をつけている。たとえばこういう記述にはならないようにしている。

プロジェクトAについて、顧客XからZZZの指摘あり。
(7/29)調査中だが十分な時間が取れず。整理に時間を要する状況
(8/5)顧客Xから確認の連絡あり。

コピペばかりの変化に乏しい文書は読まれなくなる。週報は勝手に送りつけているのだけれども、読んでもらえる文章で出すのが礼儀である。また内容を整理することで頭の整理もできるのではないかと考えている。

7/22、顧客XからプロジェクトAについてZZZの指摘着弾。他作業の兼ね合いで前週に回答出来ず。
当週改めてトレースの連絡を受けるが、どのように回答すべきか悩んでいる状況。次週初最優先で対応予定!

あと、こころがけているのは関係者に対するお礼の表明。もちろん個別適時に本人には「ありがとう」「たいへん助かりました」「よろしくお願いします!」みたいな声かけや連絡はしているのだけれども、週次のタイミングでも改めて感謝を表明するようにしている。もちろん忙しくてスッ飛んでしまうこともあるけれど。

週報を書く習慣の良いところ

個人的に「一定サイクルで何かをやる」ということを重視している。だから、自分のワークスタイルでは「週報」のリズム、ハートビート間隔は非常に重要なイベントである。「週報」を書くタイミングで、一週間前に自分が考えていたこと、計画とのギャップを振り返ることができるし、向こう一週間以上のすごし方を考え、作戦を見直す良いきっかけになっている。

またリズムがあるというのは、自分と仕事上で関係のある人たちにとっても良いことだと思っている。リズムがあれば、同期がしやすいのだ。べつに必要な時に聞いてもらっても良いのだけれども、割とたいていのことは週末私から発信されるメールに(たぶん)書かれている。急がない事柄であれば、週末まで待ってもらえればアップデートは配信されるし、もしくは前週の週報に書いてある。自分が繁忙でアップアップしてる時には「ごめん、いったん先週の俺の週報見て!」とか「今週末の週報にコメントしておくから週末まで待って〜」とか言えるので、便利でもある。

というわけで、今週も自分勝手に週報を書いて皆に送りつけるのである。

Kindle以外で気になる電子技術書籍をまとめてみた

主に自分用のメモ。セール等を活用してKindleではもりもりと技術書籍を購入しているのだけれども、一部の気になる書籍についてはKindle非対応、出版社独自に電子書籍化という場合もある。というわけで現時点で気になるKindle非対応の技術書籍をいったん整理してみた。一種のいつか買う予定リスト。

O'REILLY

カンバン仕事術

www.oreilly.co.jp
PDFのみというのが悩ましい。

マイクロサービスアーキテクチャ

www.oreilly.co.jp
PDF、ePub、mobi対応。というわけで購入すればスムーズにKindleで読める。近日中に購入したい

Serverspec

www.oreilly.co.jp
PDF、ePub、mobi対応。

オーム社(達人出版会)

新装版 リファクタリング

tatsu-zine.com
PDFのみというのが悩ましい。

アジャイルレトロスペクティブズ

tatsu-zine.com
PDFのみ。以前に紙書籍で一度読んでいる。

アジャイルプラクティス

tatsu-zine.com
PDFのみ。以前に紙書籍で一度読んでいる。

情熱プログラマー

tatsu-zine.com
PDFのみ。以前に紙書籍で一度読んでいる。

エクストリームプログラミング(新訳版)

tatsu-zine.com
達人出版会からはPDF販売。Kindle版はAmazonで販売。
旧約版は何度も読んだけれど……

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

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

アジャイルサムライ

tatsu-zine.com
PDFとePub対応。Kindle版はAmazonで販売。自分は紙版を以前読んだ

アジャイルサムライ――達人開発者への道

アジャイルサムライ――達人開発者への道

マイナビ出版(達人出版会)

スクラム現場ガイド

tatsu-zine.com
達人出版会からはPDF販売。Amazonからはリフロー版と固定レイアウト版が出ている。選択が難しい。

アジャイルな見積りと計画づくり

tatsu-zine.com
達人出版会からはPDF販売。Kindle版もある。自分は以前に紙書籍で一度読んでいる。

技術評論者

[改訂新版]Spring入門

gihyo.jp
技術評論社のサイトからはPDFとePub販売。Kindle版もある。

プライムセール連携でSOFT SKILLS等技術関連本がKindleで50%オフのセール

本日のAmazon プライムセールの関連で、最近発売された「SOFT SKILLS」「リモートチームでうまくいく」などが割引+50%のポイント還元セールになっている模様。3日間限りというと7/15までかー。
【7/16追記】SOFT SKILLS以外の本は引き続きセール中の模様。購入時には価格にご注意ください

割と最近発売された本

SOFT SKILLS ソフトウェア開発者の人生マニュアル

SOFT SKILLS ソフトウェア開発者の人生マニュアル

今読んでいるのだけれども、なかなか面白い。50%オフはかなりお得な印象。
7/16 この本は通常価格に戻ったようです

積読

高額技術書カテゴリ

Code Complete 第2版 上 完全なプログラミングを目指して

Code Complete 第2版 上 完全なプログラミングを目指して

Code Complete 第2版 下 完全なプログラミングを目指して

Code Complete 第2版 下 完全なプログラミングを目指して

最近だとこんなレビュー記事がちょっと気になった。

とにかく長すぎる。名著ではあるのだと思うが、時間に余裕があるか「俺はあの Code Complete を読破したんだぞ!」という満足感を得たいのでもなければ、もはやわざわざこの本を読まなくてもいいと思う。重要なトピックごとに、もっと深く掘り下げていてこれほど長くはない本がある。特に、良いコードを書くための知識については「リーダブルコード」のほうが良いと思う。
Code Complete 第2版 下 - @kyanny's blog

長いのはその通りだけど、とりあえず高すぎるので買うならセールの今がお勧め。定価はきつい。

ソフトウェア要求 第3版

ソフトウェア要求 第3版

上流工程の教科書的に。ちなみにこれは改定されてアジャイル開発プロセスまでフォローされている。

ソフトウェア見積り 人月の暗黙知を解き明かす

ソフトウェア見積り 人月の暗黙知を解き明かす

先の記事でも紹介しているが鉄板的にお勧め

C#実践開発手法 デザインパターンとSOLID原則によるアジャイルなコーディング

C#実践開発手法 デザインパターンとSOLID原則によるアジャイルなコーディング

積読

その他目に付いたもの

テストから見えてくるグーグルのソフトウェア開発

テストから見えてくるグーグルのソフトウェア開発

パーフェクトソフトウエア

パーフェクトソフトウエア

プログラミングの心理学 【25周年記念版】

プログラミングの心理学 【25周年記念版】

The DevOps 逆転だ!究極の継続的デリバリー

The DevOps 逆転だ!究極の継続的デリバリー

なぜ、システム開発は必ずモメるのか?

なぜ、システム開発は必ずモメるのか?

デッドライン

デッドライン

ピープルウエア 第3版

ピープルウエア 第3版

熊とワルツを リスクを愉しむプロジェクト管理

熊とワルツを リスクを愉しむプロジェクト管理

アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン

アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン

ソフトウェア見積もりと納期のいくつかの真実とウソ

ソフトウェア開発の見積もりと納期について言及されたブログ記事を見て違和感があったので掘り下げてみた記事。ソフトウェア開発の「見積もり」というと少なからずSIer臭がする。しかしSIerや日本のソフトウェア開発の現状を憎悪するからといって、見積もりというアクティビティの重要性は変わらないし、軽視してよいものではないというのが個人的な考え。
Brueghel-tower-of-babel

ウソ:ソフトウェアの納期見積もりは、星占いレベルのものである

論点を単純化するための釣りタイトルだと思うのだけれども、ソフトウェア開発における「不確実性のコーン」はスケジュールではなく、スコープ(工数、コスト、機能)の見積もりに関する分析であって、納期、スケジュールに関する分析ではない点には注意が必要である。

この本に「不確実性のコーン」という開発フェーズごとの見積もりの正確性に関する図がある。これを見ると、最初の企画の段階で実施した見積もりは、誤差が何と16倍もあり、概算見積もりのレベルでも4倍の開きがある。画面帳票仕様を「確定」したレベルでやっと1.6倍程度の開きになる。
ソフトウェアの納期見積もりは、星占いレベルのものであると思う - メソッド屋のブログ

ソフトウェア開発における「不確実性のコーン」は、初期コンセプトの時点でのソフトウェア規模の予測が困難であることを示すものであって、これはある意味当たり前であろう。物理的な建築物などであれば平均坪単価などである程度の費用工数を見積もることが可能であるが、ソフトウェアはそうではないということを示しているに過ぎない。

ソフトウェア見積り 人月の暗黙知を解き明かす

ソフトウェア見積り 人月の暗黙知を解き明かす

真実:初期コンセプト段階でのソフトウェアスコープ(工数、コスト、機能)の正確な見積もりは難しい

これは自明な事であるのでことさらと掘り下げるつもりはない。が、一方で初期コンセプト時点での予算確保などを検討する場合、「過去のプロジェクトの実績」掛ける「予想される生産性の向上」などで割り引いた予算確保を行うことは大きなリスクである。これは最近のソフトウェア開発データ分析でも言及されている事である。過去に書いた以下ブログ記事もあわせて参照。

  • 2004年~2012年の間で、SLOC生産性は変化していない(生産性向上も低下もない)

ソフトウェア開発プロジェクトは、低価格と短納期の強いプレッシャーに晒されることが多々ある。また、予算管理や価格交渉等の場面で、年率5%の開発コスト削減や前年度比10%のライン単価低減等が要求されるケースが散見される。しかし、データによる裏付け等の根拠が希薄であると、このような状況は開発プロジェクトのリスク増大や品質低下を招く恐れがある。

IPA/SEC「ソフトウェア開発データが語るメッセージ2015」を読む - 勘と経験と読経

真実:見積もりとスケジューリングは別の活動であり混同すべきではない

混同されがちなので念のため。またスケジューリングの決定は、政治、交渉の問題でもある点を理解すべきだろう。前述の「ソフトウェア見積もり」本でも、まるまる1章を割いてこれを論じている。

交渉がふさわしい情報もあれば、そうでない状況もある。私たちは太陽の表面温度や五大湖の全容積といった事実について交渉することはない。これらは、調べさえすればわかることだからだ。同様に、ソフトウェア見積もりは分析的なアクティビティの結果である。したがって見積もりについて交渉することは道理に合わない。だが、見積もりに関係のあるコミットメントを交渉することは、理にかなっている。
ソフトウェア見積り 人月の暗黙知を解き明かす /第23章 政治、交渉、問題解決

また、政治的なスケジュールの交渉についてはこの本が詳しくて参考になる(アンチパターン集が含まれている)

Manage It! 現場開発者のための達人式プロジェクトマネジメント

Manage It! 現場開発者のための達人式プロジェクトマネジメント

スケジューリングと見積もりは2つの異なるアクティビティだ。スケジューリングとは各タスクの順序付けであり、相互依存関係が見えるようにすることである。一方、見積もりとは、特定のタスクに必要な工数を推測する作業のことだ。スケジュールを編成する方法はタスクの工数と必要な人材の見積もりに依存するので、両者は密接に関係している。
Manage It! 現場開発者のための達人式プロジェクトマネジメント/第4章 プロジェクトをスケジュールする

見積もり、計画、スケジューリングをどんなにがんばっても、スケジュールをゲームにしてしまうスポンサーや管理者やチームメンバーが現れるものだ。ゲームプレーヤーを現実に連れ戻すのはプロジェクトマネージャの仕事である。でもその前にスケジュールゲームを見極める必要がある。
Manage It! 現場開発者のための達人式プロジェクトマネジメント/ 第6章 スケジュールゲームを見極めて回避する

ちなみに紹介されているスケジュールゲームのアンチパターン(第6章 スケジュールゲームを見極めて回避する)は以下の通りだけれども、タイトル見るだけでワクワクできる。

  • 岩をもってこい
  • 願望が最重要の戦略
  • 現実否認の女王
  • カーペットの下に隠してしまえ
  • ご機嫌な期日
  • 尻に火をつける
  • 焦点の分裂
  • スケジュールは確約に等しい
  • 行き当たりばったり
  • スケジュールツールは常に正しい(スケジュールの夢の時間)
  • 何が何でもやってくれ。でないと黒こげだ
  • ノーとは言えない
  • スケジュールチキンレース
  • 90%完了
  • これからペースが上がっていく
  • スケジュール催眠

ウソ:見積もりが困難だから、計画することには意味はない

そんなことはなく、当然、意味はある。ただし、それはコミットメントをすることにおいてのみではない。

見積もりや計画づくりがそんなにも難しくて、プロジェクトの終わりになるまでは正確に見積もれないのであれば、そもそも見積りや計画づくりをするのはなぜだろうか? わかりやすい理由として、働いている組織から見積りの提出を求められることが挙げられる。その理由はさまざまだが、いずれももっともなものだ。マーケティングキャンペーンの計画を立てるためだったり、プロダクトのリリース作業の予定を立てるためだったり、組織内のユーザをトレーニングするためだったり。いずれの場合にも計画や見積りが欠かせない。見積もるのが難しいので計画やスケジュールは作成しない、という言い訳は通用しない。しかも、見積りや計画づくりという大変な仕事に取り組むべき理由は、こうした消極的なものだけではない。もっと根源的な動機があるのだ。
見積りと計画づくりは、期日やスケジュールを決定するためだけのものではない。計画づくりとは価値の探求なのだ。
アジャイルな見積りと計画づくり ?価値あるソフトウェアを育てる概念と技法?/1章 計画の目的

同書は見積りからいかに価値を生み出すか、という点で非常に示唆に富んでいて、個人的にはマコネルの見積もり本と合わせてオススメしている。ソフトウェアの見積もりの工学的な側面をマコネル本で学び、適切にコントロールするという観点は本書を読むのが良いと思う。

真実:受発注契約の関係において納期は絶対である

ポイントは「契約の関係に於いて」という点である。つまり

  • 自社エンジニアが便宜上「納期」と呼称する単なる作業完了のコミットメント
  • 請負契約の関係に無い利害関係者が便宜上「納期」と呼ぶ完成マイルストーン

についてはこの限りではない。
一方で、いうまでも無く契約上で定義された納期は絶対のものであり、これが遅延した場合契約債務不履行になるので「ソフトウェアの見積もりなんて星占いみたいなものだから、納期なんて守れるはずないし、守らなくて良い」なんて思わないように。
参考:システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance

ただ、実際はソフトウェア開発の不確定性を考慮して契約するのが適切だろう

  • ソフトウェア開発の完了予定日(例えばリリース日)と契約書上の納期は分ける
  • スケジュール上のバッファをきちんと設定して、本番稼動後に改めて納入を図る
  • 超過の可能性がある場合は、相手先と今後の係争に抗弁できるような合意形成を行う

納期を越えて

冒頭で紹介した記事は、「納期なんて考え方はやめてしまえ」という意見を示しているのだけれども、個人的にはちょっと疑問がある。SIer的な「ソフトウェア開発完了のコミットメント=納期」は、単純に外注契約を無くしてしまえば回避できるだろう。しかし、ソフトウェア開発を取り巻くすべての利害関係者が期日やコミットメント無く協働していくビジネスというのはちょっとイメージしにくい。経営やマーケティング、運用などの観点ではやはり大小のコミットメントを拠り所として推進せざるをえないのではないだろうか。
ただし「守ることのできないコミットメント(納期、期日)」や「無意味なコミットメント」などは生産性阻害要因であることに変わりない。いま目の前にある期日が何のコミットメントで、最新の状況においてどういう意味があるのか、そして変化がある場合にどのようにすべきなのかについて考えることが必要であるのだと思う。

2016年上半期に読んだ本からお勧め図書を選んでみる(文芸、ビジネス、技術書)

昨年に引続き、2016年1月~6月に読んだ本についてふりかえってみるもの。カウント対象は期間中に読み終わったものに限り、読みかけの本は対象外としている。あと雑誌コミック類もけっこう読んでいるのだけれども、これは除外。全般的には旬な本をぜんぜん読んでいないな・・・

2016年上半期に読んだ本を並べてみた










































オススメ文芸書編

色々と読み散らかしているけれども、ITエンジニア的に以下スライドを見て手に取った「赤めだか」が面白かったし名著だったので一番のオススメ。教育論としても読めるけれども、単純に内容が面白くて楽しく読める。古典落語にも興味を持ってしまった。

赤めだか (扶桑社BOOKS文庫)

赤めだか (扶桑社BOOKS文庫)

もうひとつ。今年映画化もされた「火星の人」はジャンルとしてはSF小説だけれど万人向けのエンターテイメント作品となっているので強くオススメしたい。逆境に立ち向かうエンジニア魂に震えるし、その経過を面白おかしく日記形式で書くという構成はソーシャルネット時代向きで楽しい。

火星の人

火星の人

オススメビジネス書編

今年前半は割と人類の進歩を実感することが多かった。重力波の検知が報道されたり、日常的に人工知能の話題が聞こえるようになってきた。というわけでレイ・カーツワイル氏の「シンギュラリティは近い―人類が生命を超越するとき」を取り上げたい(なおこの本は2005年の著作である)。現在読んでも非常に刺激的だが、電波な内容も含んでいるので注意(同氏は自身の肉体で実験を行いながら不老不死を目指していたりする)。


とりあえず同書を読んで、自分は2045年まで生存することを優先度の高い目標にしている。

オススメ技術書編

残念ながら最近の旬の技術書をタイムリーに読めていない。「マイクロサービスアーキテクチャ」とか「カンバン仕事術」「スクラム現場ガイド」なども読みたいのだけれども辿り着けていない。2015年の積ん読をこなすので精一杯である。
ソフトウェアシステムアーキテクチャ構築の原理 第2版」は有用度で文句なしの一品。アーキテクト関連の仕事をするのであれば目を通すべき鉄板本。
一方で「ビヨンド ソフトウェア アーキテクチャ Object Oriented Selection Classics」はサービス開発、製品開発に関わるエンジニアにお勧めしたい本。受託開発の人にはあまり響かない気がする。

オススメしないけど面白かった本

今年前半での大きなニュースの一つが「アルファ碁」であることは間違いないと思う。

で、ミーハーではあるものの改めて碁に興味を持ったので、いろいろ調べた結果以下の本で学習を始めてみている。

なんとなくルールと指し方はわかった気になっているが、ブラウザでできる碁ゲームでは9路盤で時々勝利できる程度。まったく上手にはならないけれども頭の体操としては楽しめている感じ。

最近の読書環境について

画像からも見て取れるように、読書の大半はKindle端末で読んでいる。読書時間のほとんどが通勤時ということもあり、物理図書だととても持ち歩けない分厚い技術書などが読めるのは大変に便利である。新型の端末が発売されているけれども2013年に購入したKindle PaperWhite(第5世代)を継続して使用中。バッテリーの持続時間は短くなっているのかもしれないけど1週間以上は持つので、まったく不便はない。

故障などで買いなおす事になったとしても、たぶん同じ機種(PaperWhite 広告なしWi-Fiモデル)を買うだろう。物理ボタンはあったら便利かもしれないけれど故障リスクもあるわけで、あまり興味は無い。

Kindle以外の本はだいたい公立図書館で借りたものを読んでいる。というわけで物理図書を購入するのは現在、または将来子供と共有したい時だけである。

読書の大部分は通勤時間と書いたけれども、最近の本の読み方は具体的にはこんな感じ

  • ビジネス書、技術書、文芸書を並行して読む(気分にあわせて選ぶ)
  • 通勤時間、電車等が混雑していない場合は読書。混雑している場合はPodcastなどを聴いている
  • だいたいKindle端末で本を読んでいるけれども、状況によってはスマートフォンKindleアプリで読むこともある
  • 就寝前も読書。Kindle端末はバックライトがあるので便利
  • 技術書とビジネス書は読了後、カフェか自宅で読書ノートをまとめる習慣を継続中

年齢的にはそろそろ老眼が怖いのだけれども今のところは大丈夫。まぁそうなったらKindleで文字サイズを大きくして読めばいいのだけれど。