やっとReleaseIt!を読み終えた

今更かよ、といったくらい時間がかかってしまったけれども、やっと読み終わった。言い訳させてもらうと、途中で嫁さんに貸したからです（嫁さんの会社では運用もやっているので、自分よりも先に読んだ方が良いだろうと思ったから）。

読んでみて最初の感想は、この本をスルーするか迷っていた自分に「正座して読むべき」というコメントを下さったかくたにさんに感謝すべきだと思った。これはスルーして良い本ではない。

色んな箇所で「あっ！？」と気づいたり「あ〜！？」と反省したりする点が多く、どの章がどうとかいぅ細かい感想は書けないカンジ。

「第I部:安定性」「第II部:処理能力」は「ケーススタディ->説明->アンチパターン->パターン」という流れでの説明で、リズムも良く読みやすい。やはりアンチパターンの章が勉強になるし、結構踏んできている自分が悲しくなったりしてとても良い。

「第III部:設計における一般的な問題」は専門的な知識が必要な話も多く難しかったので、あんまり吸収できなかった…。

「第IV部:運用」は運用の話で、自分が運用に携わっていたのは随分むかしになるのだが、それでも身にしみて色々と勉強になった。特に読んでいて勉強になるというか、自分も意識していた内容として「17章:透明性」をオススメしておきたい。この章はとても良い。

全体的に見ると「ここまでやってられるかよ」と感じる内容も多いが、バランスも意識して書かれている。「どこまでやろうか」というバランスは今までも重要だったけど、この本を読んでからはそのバランスを取る位置が確実に変わった。なぜかというと、今までだと「コストが高くなる」と思っていた事を実現するにも、あの手この手色々あるという事がわかって、工夫次第でそんなにコストを書けずに色んな策を施せるという事がわかったし、自分が如何に安易にアンチパターンを踏んでいたかがわかったからw

システム構築に携わっている人は是非読むと良いと思います。以下はかくたにさんからのコメントの引用。

『Release It!』はソフトウェア開発に関わる者は全員、正座して読むべき1冊だと思います。フェーズとかそういう問題じゃないんです ;-)

ちなみに、かくたにさんは18章の"適応"を超おすすめしておられた。

書評:SUBJECT TO CHANGE

ユーザエクスペリエンスの重要さについて書かれた書籍。ユーザエクスペリエンスという単語は昔からあったけど、昨年から急に使われる頻度が上がった気がする。そんなこんなでこの手の話題について結構気にしていたトコにどこかでこの本の紹介を見かけて、嫁さんに「買ってみたら？（俺も読むし）」と勧めてみたところ嫁さんの会社の方が貸し出してくださる事に。で、便乗して俺も読ませていただいた。貸し出してくださった方、ありがとうございました！

この本の特徴として、「具体例が非常にわかりやすい」という点が良かった。おかげで「この章では何を言いたいのか」がわかりやすい事が多い。全体的に、著者の主張については特に新しいものは無いと思うが、どれもこれも具体例が適切なおかげで読んだ端から「Aha!」となるｗ ちょっと経ってから、いやいや今までもずっと聞いてきた事やん、となる。
全体的な感想としては、読み物として楽しんで読むかんじの本、というカンジ。読み物としては十分おもしろかったです。後、この本はAdaptive Pathという会社のメンバが書いている本なのだが、Adaptive Pathの共同創設者のJeffrey VeenはStartup2Startupという、スタートアップのコミュニティを育てるための活動を継続しているらしい…という記事をTechcrunchで昨日偶然見かけた。

余談になるけど、この本を読み始めてすぐに思い出したのが、37signalsの「より少ないシンプルな機能で競争する」。また、こういった本を読む人はEric Sinkの「Eric Sink on the Business of Software 革新的ソフトウェア企業の作り方」もあわせて読むのが良いかもしれない。

最近「へぇ！」となった体験を一つ。ホームセンターへガスコンロのカバーを買いにいった時の事。便利に使えるお気に入りのタイプを求めていたんだけど、いざ店頭で発見してみると微妙なサイズの違いで同じ種類のモノがいくつかあった。で、どれだかワカラン、となったワケです。その時、嫁さんは「ウチはコレだと思う」とひとつ選択した。理由は、サイズとか関係なく「猫のアイコンがついている」という事。サイズごとに包装に違う種類の「アイコン」がついていて、それがまた「猫」とか「車」とか全然違う種類のアイコンになってた。猫と犬とかの差よりもまたわかりやすいし、ガスコンロや料理とかと全然関係ないアイコンってのが覚えやすく迷いにくい。消費者が迷うだろうと考えての事なんだろなー、と感心しましたとさ。

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

めっちゃ時間がかかったけど、やっと読み終わった。

まず率直な感想を書くと「後半部分は読む内容が少なかったかな？」と感じた。非常に良い本である事は間違いないけど、過去に読んだ本との重複がかなり多かったと感じた。これは個人の履歴との兼ね合いだから内容の出来具合とは何の関係もないけれど。まぁ、この本に一番期待していた「見積もり（前半部分）」はこの本でしかえられない貴重な知識だったワケで、結局は大満足してますけどねｗ

こんなデカイ本だと時間がかかりすぎるよ！さくっと読めるヤツがいいよ！って人は「第2部:規模を見積もる」だけを読んでみるといいかも。そこを読んだらたぶんその次も読む事になると思うけどｗ、自分はこの章が一番ためになった。

それ以外では、ちょっと範囲が狭いけど「第4部:スケジュールを立てる/第17章:不確実性に備えるバッファの計画」もためになった。バッファなんて誰だってやるでしょう、とかじゃなくて「説得力のあるバッファ」だと感じた。エンドユーザにも全てさらす事ができるような透明度の高いプロジェクトを理想にしている自分に取っては、気まずくて言いにくい話になりそうな話を、力強く説明できるのは助かる。本からの受け売りでも、ないよりは良い。

ピンポイントで「へぇ！」となったのは「リリースバーンダウン棒グラフ」。これは良いメソッド。こんなの思いつかんかった。作業範囲に何かが追加されてきた時、バーンダウンは「自分が後戻りした」ようなカンジがするし、バーンアップは「ゴールが遠のいた」カンジを受けるし。自分だけかもしれないけど、そんなイメージをもってしまってあまり気分がよろしくないｗ でも、バーンダウン棒グラフはイイ！

過去に読んだ云々と重複してるなーと感じたのは以下の4冊。どれも良い本で、今回読んだ本もまた良い本だけど、後半部分が以下の4冊とびっくりするくらい内容が重なってると思うｗ

• リーン開発の本質 ソフトウエア開発に活かす7つの原則
• アジャイルプロジェクトマネジメント 最高のチームづくりと革新的な製品の法則
• Manage It! 現場開発者のための達人式プロジェクトマネジメント
• Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック

とりあえずポチっちゃぇばいいと思いますよ！

そうそう、過去に読んだ本と内容がかぶってしまって…といぅ意味で最近迷っているのが「Release It! 本番用ソフトウェア製品の設計とデプロイのために」。フェーズ的にはShipIt！的な気がするし、どぅなんだろぅと迷っているｗ

アーキテクチャの生態系

社会学？か何かわからんけれども、単語が難しいせいで理解しづらい本だった。別にこの本が理解しづらいという意味ではなく、たぶん自分は頭がいい人たちの半分もこの本の内容を楽しめてないな、と感じただけ。読みながらiPhoneでWikipediaを引きっぱなし。
とはいえ、各種メジャーなサービスを普段あまり深く考える事が無い視点で観察した話が書かれていて、そういう点でかなり面白かった本。自分の場合は技術としての観点ばっかりなので新鮮に感じた。「主に国内の」以下のサービスについて、海外と比べた日本の文化を背景にどうマッチしたのかなどなど、深い分析が書かれている。

• 2チャンネル
• ニコニコ動画
• ミクシィ
• P2P(Winny)
• ボーカロイド(初音ミク)
• ケータイ小説(恋空)

今から読む人のためのアドバイス

16ページで説明されている、本書で使用されている「アーキテクチャ」という単語の概念と「規範（慣習）・法律・市場」の関係をしっかり頭に入れてから読むと良いと思う。ここをしっかり確認して常に頭において読まないと、著者が読ませたい意図を見落としてしまっておもしろさがわかりにくくなってしまぅかもしれない。

ふと思い出した事

「Web2.0」のアーキテクチャの「生態系」という話が、以前パソナテックカンファレンスで参加したセッション「Webの未来を指し示す技術ベンチャー」で聞いた「Webは新しく誕生した観察可能な新たな自然(Nature)だ」（サイジニア株式会社の吉井氏の発言）という考え方を思い出した。

気になった些細な点

332ページで米国のソーシャルウェアの紹介としてFacebook,Twitter,FriendFeedがあげられているが、FriendFeedのみ「フレンドフィード」と括弧で括られて紹介されていた。なぜFriendFeedのみ括弧付きで書かれたんだろか。著者のお気に入りサービスだったりするんだろか？FriendFeedユーザなので気になった。

結構ボリュームがある本だったけど、そろそろWEB+DBの季節だし、WEB+DBに間に合うよぅなんとか読了できてよかった。あ、もやしもん7巻も届いたんだった…いやいや、クーリエジャポンも2ヶ月分溜まってるんだった…。まぁ、読む本がたくさんあるってのはいい事ですね。

Effective Java第2版

事前の噂通り、大変勉強になる本だった。といぅか、こんなに勉強になる本だとは思ってなかった。日本語訳がちょっとなぁ、的な部分も少しあったけど、それは自分のこれまでの文化の問題で、一般的にはわかりやすい表現なのかもしれない。

難しかった

項目69:waitとnotifyよりコンカレンシーユーティリティを選ぶ
この項に関しては全く理解できなかった。ワカンネとかそんなレベルでなく、難しすぎて理解できなかった。何度も読んだり試したりしてみるとしよぅ。情けないのぅ。

面白かった

11章のシリアライズ関連全般。ぶっちぎりで面白かった。

Javaを触る人なら必ずよんでおかなければならない本だと感じた。自分も、時々思い出して開いてみる事にする（我が家には2冊あるので、一冊はトイレに置いてある）。

Java Expert #03

自分はNetBeansはちっとも使ってないけど、執筆陣に知り合いが多い！ていうのと、BlazeDS目当てで購入した。

• 本を開いて真っ先に確認したのが、じまめ仲間であるid:happy_ryoの「NetBeans日本語コミュニティとねこび〜んの紹介」というコラム。ねこび〜んには正直嫉妬している。Eclipseにもry…MacにEclipseを複数入れてあるので、いくつかのアイコンをねこび〜んに変えようかな？
• 最も注目していた「BlazeDSで始めるらくらくFlex/AIR+Java連携」。そろそろBlazeDS触っておくか…という段階にある人には非常に役に立つ内容だった。おすすめ。
• 次に「ActionScript3の勘所・ハマリ所」だが、これはちょっと初心者向けすぎたか？とも思うけど、おさらいには丁度良いボリュームだった。あ、そうそう、Project AmaterasのAIR GEARも最近1.0.1がリリースされています。さらにさらに、最近InfoQの記事でAIRのUIテストができそうなfluintというプロダクトの紹介があり、それも滅茶苦茶気になっています。
• 次に「JavaFXとJavaFXプラグイン」を読んだ。JavaFXはまぁいいとして、NetBeansのJavaFXへの対応具合に嫉妬した。JavaFXを使う時だけEclipseをやめてNetBeansを使う事にしようと思う。
• 「OpenLaszloによるRIAの試み」は、以前から注目して少し追いかけているOpenLaszloの話題だっただけに嬉しい記事だった。これもBlazeDSの記事と同じように、そろそろ触っておくか…という段階にある人に非常に良いカンジ。NetBeansからRoRのプロジェクトを作ったりする手順に驚いた。
• 「GlassFishを活用したエンタープライズシステム開発」に関しては、そもそもGlassFishをあまり触っていない自分に取ってあまり興味をそそられなかったんだけど、NetBeansがエライ親密にGlassFishと連携していて驚いた！

そんなカンジで興味がある記事を拾い読みして行くカンジで読んだ。NetBeans素人の自分に取っては新しい発見も多くはあったが、最近は「Eclipse以外のIDE→IntelliJ IDEA」という選択肢の方が魅力を多く感じているのでNetBeansはしばらくおあづけかなｗ

おすすめ本の紹介 - Manage It!

Pragmatic Programmer Bookshelfから、でびあんぐるによる訳、というサラブレッド的な本。「現場開発者のための達人式プロジェクトマネジメント」と書かれているだけあって、「非常にバランス感覚にすぐれた本」というのが総合的な評価。まだ一回しか読んでいないが、幅も広いし豊富な知識と経験によって書かれているなと感じるし、読んでおけばいろんな場面に応用が効く内容が書かれていた。
ウォーターフォール（とかフェーズゲート）を全否定するでもなく、「こっちが最高なんだ、いやこっちが最高だ」みたいな話になる事も無く、現場の背景に応じてやるべき事選択すべき事、その時の基準、手法を淡々と説明していくカンジ。
近いうちにもう一度読むと思う。とにかくオススメ！
知識も大事だし、でも現場に乗らなきゃ意味が無いし。背景に応じてそれぞれのいいトコどりをする。バランスが肝心！ですよ。

書評:わがSE人生に一片の悔いなし

このブログで何度か紹介した事もある「「派生開発」を成功させるプロセス改善の技術と極意」も書いている清水吉男氏。「要求を仕様化する技術・表現する技術 - 入門＋実践 仕様が書けていますか?」もそう。 SI技術本というよりはSI業界に携わる人間が心がけると良い事だとか、良い習慣の紹介といったカンジ。SI技術について知りたい目的であれば、この本はハズレ。自分的には「清水氏はどのタイミングで悔い無しの感覚を得たのか？そう言えると感じたのか？」に興味があったので読んでみることにした。 ネタバレになっちゃうけど「どのタイミング？」という観点が間違っていたという事はわかった。例えば毎日、一日のふりかえりを行った時に「今日は悔いは無かったか？」を繰り返していく事のようだ。そりゃ大変な事だ。

いくつか気になった点を。

第2章「まず準備せよ」 - 思い込みと勘違いが交錯する世界

そもそもプロセスとして存在する事に気づけないプロセスがあり、気づいていないのであれば当然次回のプロセス改善でも取り入れられる事は無いので、また失敗するという話。

第3章「習慣が人生を変える」 - 良心の発露を仕掛ける

この節は全体が「そういうやり方があるのかー」と感じた。しかし、組織の中でこういった習慣を取り入れて行く事は本当に難しい事だと思う。やり方を誤れば、逆の効果を生んでしまいそぅだ。これについての話は第4章「能動で動く」 - ピアレビューでの能動の仕掛けでも登場する。

第5章「莫作の力」 - それって顧客の利益になる？

顧客の要求全てを実現する事がCSだと思い込んでいる人が多いという話。これについては自社内で散々話してもいるが、まーまず伝わらない。いかに客から金を捻りだすのか？という事しか考えられていない、ウチみたいな会社はそーなんだろぅな。難しい話ではないはずなのに、ダメダメな会社には絶対ムリ。このあたりを追求したいなら、無駄な労力を使うのは避けて、自分が会社を変えてから考える必要がある。

第5章「莫作の力」 - 難しい要求への対応

上に上げた顧客利益になるか？と同様の話で、ダメダメな会社は如何に顧客に金を出させるかのために顧客に対指定誠実に向き合う事をしないだけでなく、自社のメンバに対してもその方向へ動く。労働力は社員をだまして引っ張りだそぅとする。

まぁこのあたりは「再認識」する程度で、別にこの本を読んでどうとかでもない。あくまでも清水氏が問題と感じる事が述べられているだけで、そこに新しい事は何もない。が、自分の場合は清水氏の考え方（捉え方）自体にも興味を持っているので、読んで無駄だったというカンジも無かった。 清水氏の本を読んでいつも思う「もっとデジタルのツールを活用する事例はないの？」という疑問は今回も残った。デジタルのツールによってプロセスは大きく変わるはずなんだけど、そういった事への言及がいつも足りないというか全くない。その手のツールの話抜きにプロセスや習慣は語れないと感じるのだが、これは世代の違いなんだろうか。

書評:Webアプリケーションテスト手法、ITアーキテクトVol.18

Webアプリケーション テスト手法

この本は、Selenium関連が読みたくて購入した。が！「超初心者向け」の内容で、特に読む箇所が無かった…。
しかし、ActionScriptのUnitTestについての記述があって、これに関しては自分が超初心者なので役に立った。変なところに「まとめ」が挿入されていたり、その重複した「まとめ」も誤字があったり、と品質は低いっぽい。さすがマイコミ。複数の人によって書かれているからかな？
「Perl」「ActionScript」「PHP」「Ruby on Rails」「Selenium」とてんこもりに見える（なぜPythonが含まれてないんだろぅ？）が、どれも超初心者向けで、なんか中途半端な内容、というのが全体的な感想かな。超初心者の人には役に立つ…かもしれないが、少しでも経験している人は、別にこの本を買わずとも、もっと各言語に特化した入門本の方がいいと思う。

ITアーキテクトVol.18

こちらは、どこかで見た「平鍋さんの記事がある」という事で購入した。しかし、その平鍋さんの記事は特に読む箇所は無かった。リーン本からの抽出が多かったからかな？別に記事がショボイとかではなく、ちゃんとイイコトが書いてあるのでリーン本を読んでいない人は損しないと思う。
これ以外では、以下の内容が良かったと感じた。

Jazzプロジェクトの話

興味があったものの詳しく見れていない無いようだから、タイムリーで助かった。

アジャイル開発実践の極意

Part1は上記の平鍋さんの記事で、Part2が別の方の記事。自分が読んで面白かったのはこのPart2の方（もちろん、Part1の記事も良い内容）。
ただ、もっと「アジャイル（…風味とかもどきでも良い）をやろうとして失敗した事例」についての話がどんどん書かれてもいいんじゃないかなぁ、と思うのだが…。そろそろそういった内容をたくさん読みたい(最近InfoQで少しだけ見ましたけれども)。

会社をぶっ壊して、チームを創ろう!

読んだ。久々にオススメ！てカンジの本だったので紹介と感想を。
タイトルはちょっときつめだが、内容はそんな事は無く、かなり「建設的」なカンジで、壊す事よりも建設する事について詳しく書かれている。当たり前だけど。

• Prologue: 幸せな会社を支える不幸な人々
• 壊すべき「会社」、創りたい「チーム」
• 元気が出る会社のぶっ壊し方
• 想像を超えたチームを創る三つの仕掛け
• 「対話の改善活動」がチームを伸ばす
• 卓越したチームへの道

で最近の自分の状況というと、自社がピンチな状況で、本書に書かれている表現を借りると「ゾンビ達」のみが残った状態に陥っている。技術系の会社だったはずなのにもはや一般的なSIerのレベルすら保てていない（どれくらいヒトイかというと、自社Frameworkに頼りすぎてStrutsやら各種ORMといったかなり普及したFrameworkすら扱えない。それどころかJavaだって怪しい）状況で、本書のPrologueをもじると「不幸な会社を支える不幸な人々」という、どないしよぅも無い状況なワケで。

言い訳しておくと、ここ数年は自分でも社内の空気を変えようと、主に上の人間に口うるさく言い続けたワケだが効果はなかった。自分のやり方がまずかったんだろぅ。

そんな中、さすがに社も危なくなってくるワケで「社内の問題点を抽出してみて、そこから最優先の課題を抽出しよぅ」みたいな活動をやりはじめたりしている。その時に、自分の相方はやたら「まずチームだ」「チームを創れる環境からだ」と、「チーム」にやけにこだわっていた。自分もアジャイル関連の資料やポッペンディーク夫妻のリーンについての資料を結構あたってはいたものの、「チーム」という部分はそこまで優先していなかった。
が、最近は本書もそうだし、会社の外のチームでの活動で「あぁーこれはスゴイわ」と。たぶんこのメンバなら、対象が仕事であっても意欲を持ってやっていけるわ、と感じていた。さらに本書を読む事で社内にチームを創るための具体的なアドバイスを手に入れる事ができて、今では十分に「チーム」の重要さをわかるようになった。

3時間もかからず読めるので、是非とも経営陣に読ませたい本ではある。が、ゾンビには響かない可能性の方が大きい…なーんていう考え方は、これはこれで「そんなのムリに決まってるだろ」という「悪魔のささやき」である、と説明されていたので、買ってでも読ませるとするか。まず行動だ。

…だがしかし、そんな事言いながらも考えてしまうのは、ゾンビの世界はゾンビなりに特に文句もなく、完全に腐りきるまでやってりゃええんでないの？俺も文句言わず出て行くから好きなようにやっとけば？とも思うわけで。ちなみに本書にも出てくる話で、以下のようなものもあった。

でも負けたわけではない。モンスターを一人でコントロールする事はできないが、自分の生き方は自分でコントロールできる。それならば、個人と組織の接続を別の舞台で試みるため、新しいチャンスを探した方がいい。とても合理的な考えだ。

「既に周囲のゾンビ化に気づいている個人」の視点でみると、こうなんですよー的な話として出てくるだけで、チームを創ろうと活動する読み手に対しての文章ではないはず。だがしかし、ここが痛烈に印象に残った。
この本はそもそも「会社から見た」話だから仕方ないが、上にも書いたようにチームというのは会社とは関係無く発生、存在できる物だし、そのチームでは会社の枠を超えて仕事だってこなせるはずだ。そんなお宝フィールドが会社の外にゴロゴロしてるんですよ？そんな状況で、特にその存在自体に価値が無い会社を良くするのために、自分の貴重な時間なんて使えないよなぁ。この本を参考に活動をするのは、まずは社外のチームを経験してから、それから会社の価値を考えて「時間を使う価値がある会社か？」「時間を使う事で価値を見いだせる会社か？」という判断をしてからがいいね。

Googleを支える技術 ~巨大システムの内側の世界

読んだ。結構前から読みたいと思っていたが、Amazonで注文しようとするたびに毎回「在庫切れ」の状態で、なっかなか入手できなかったのだ。
構成としては、Googleの内側とあるだけあっていきなり検索エンジンについて話が始まる。次に「スケールアウト」の話が来て、それが終わるとその「スケールアウト」のための具体的な技術について説明がある。

• GFS(GoogleFileSystem)
• Bigtable
• Chubby
• MapReduce
• Sawzal

これらが終わると、「運用コスト」について話が展開される。
そして最後に「Google社内の開発体制」についての説明がくる。

個人的には「Bigtable」「GFS」「Chubby」に興味があったが、実際読んでみると「MapReduce」が最も興味深かった。仕事としてGridを管理するFrameworkを構築したからかもしれない。
また、それぞれの技術に関して、クローンのようなものがOSSで存在していると知った。MapReduceのクローン(?)も最近リリース情報を見かけたし。
ちなみに、2章の途中で「多数のサーバで負荷分散する」という節があるのだが、ここに最後まで良く判明しなかった疑問がある。

利用者からの検索リクエストは、まず最初にロードバランサによって振り分けられ、複数あるGWSのいずれかひとつにつながります。

ここでいう「ロードバランサ」がどんなヤツなのかについて説明が無かった気がした。ここは一般的なバランサを使っているんだろうか？
もひとつ、初めて知った事実として「Google社内ではUbuntuベースの"Goobuntu"という社内向けディストリビューションを使っている」という事。検索してみると、数年前から知られている事実だった。知らなかった。。

そんなカンジに、色々な技術について簡単に、かつ細かく説明されていてかなり勉強になった。だが、最後の章の「Google社内の開発体制」を読めばわかるように、Googleをもっとも力強く支えているのはGoogle社内の技術者達なんだなぁ、と思った。非常にわかりやすい構成で、読みやすかった。オススメ！

参考Link

• GFS,MapReduce,Bigtable,Sawzalの実装をしているproject、Hadoop->http://hadoop.apache.org/core/
• Rubyで構築されたMapReduceの実装、Skynet->http://skynet.rubyforge.org/

開発の現場 Vol.012

読んだ。
今月の特集は以下のふたつ。

• 「見積もり」の極意
• いま"サクサク開発"がすごい！

特に後者に期待して購入したが…読み応えのある物が無かった。ストレスフリーとかストレスレスとかをタイトルに含んだものもあって期待したんだけども、がっかり。
前者の特集では「レビューを駆使してチェック効果を最大化しよう」という記事が良かったかな、と。
開発の現場、次号からは購入する必要がなくなるかもしれん、とオモタ。というか、最近はハズレが多いなぁ。

Life Hacks PRESS vol.2

創刊号に引き続きこっちも読んだ。
今回もそんなに面白い事は無かった…。が、そんな中、以下の記事は大変参考になった。

• 7つの論理と10の技術

前者は、改めてLifeHacksとは？と考え直す非常に良いきっかけになった。痛い指摘もあったし、改めて原点に戻るという意味でもいい事が書かれていた。
さて、次号にも期待…できるか？さらっと立ち読みしてからの方がいいのかなぁ？…全体的に読むトコが少なめ？

Life Hacks PRESS vol.1

読んだ。
主にデジタル系のLifeHacksを期待して購入したのだが、創刊号ということもあってか基本的なモノが多かった。Gmailの移行ツールがあるのは知らなかったから、これは超ありがたい知識となった。他には、アナログツールも結構いいなぁ、と。t-wada氏の有名な腰リールも、具体的な話を見てかなり興味を持てた。
個人的に、最も役に立ったのは「プレゼンが簡単にうまくなる」「勉強会のすすめ」のふたつ。これらはLifeHacksというジャンルなのか？というカンジもするが、非常に良かった。
総合してみると、この号は特に目新しい事も無く読むのも時間がかからなかったけど、vol.2に期待が持てるシリーズです。

アジャイルプロジェクトマネジメント

読んだ。アジャイルマニフェストの時に参加していたジム・ハイスミス氏による本。訳者には平鍋さんの名前も入っている。
「ソフトウェア業界に限った話ではない。」という点を頭において読む必要がある。チームリーダとかの立場よりももっと上の、本格的なマネージャの人向けの本だと思った。
ちょっと堅苦しいカンジを受けたので、まずは各章の冒頭にあるマヤとハーマンの会話の部分だけを先に読んでから、また最初に戻って読み直していってもいいかもしれない。
内容としては、今まで読んできたアジャイル関連の知識がチームリーダ向けだったり現場作業者向けだったりした事とのギャップがあるためか、上記の「製造業界向け」とのギャップのためか、一部納得いかないものもあった。だが、色んな視点でみるという意味では読んでおいて損は無い。
自分は一回では理解できなかった。二回目もさらっと流してみたが、やはりそれでも難しい…。書いてある内容は理解できるが、中々想像つかない点も多い。
営業の担当の人なんかも読んでみればいいと思う。

ITアーキテクト Vol.16

普段は「立ち読みでさらっと見てみる→そのまま棚に戻す」といったカンジのため、めったに買わないITアーキテクトだが、今回は「コンポジットアプリケーション」の話しと出ていたので興味を持って買ってみた。
…中身が浅いなぁ、とオモタ。これで¥1,600は高すぎる。普段からdeveloperWorksやらInfoQやら、色々見ている人には不要だと思う。値段と中身が比例してない。…とかなんとか悪態をつきながらムカムカしつつ電車に乗って読んでいたら、そのまま気分が悪くなって救急車で運ばれたんで、これまた何やら相性が悪いというか、ゲンがワロイかんじの本となってしまったのであります。単なる低血糖だから、当たり前だけどこの本は何にも悪くないんだけどね。
念のためフォローしておくと「具体的な中身までは踏み込みたくないけどさらっと浅く知りたい人」にはいい本なんだと思います。自分には合ってないだけです。

受託開発の極意

読んだ。すげぇいい事が書いてあると思う。文字数も手軽な感じで、少しの時間で読めるはず。
絶対的な評価でいくとすごい良書なんだろぅけど、自分的には「もっと具体的な例を…あ、ここも…」みたいなカンジでイライラさせられる点が多かった。ここまで書くならもちっと踏み込んで、具体的な例を見せてよ！と感じた箇所が多かった。
対象としては、現場作業者がメインだけど、人の管理をする人が読んでもいいし、何より普段はエンドユーザという立場の人にも読んでもらって反応を見たい、かな。
何が何でも読め！て程の本ではないと判断したけど、色んな立場の人による感想を聞いてみたくなる本だった。

BEST SOFTWARE WRITING

読んだ。海外の有名な人の小編を「Joel On Software」の人が集めて紹介したモノ。選りすぐりの小編なワケで、どれもおもしろいし中にはかなり衝撃を受けたモノもあった。「アレ？これどこかで見たぞ？」てのもあった。個人的に強く印象に残ったものは次のもの。

• ブルース・エッケル「強い型付けvs強いテスト」
• ポール・グレアム「すごいハッカーとは」
• グレガー・ホペ「スターバックスは2フェーズコミットを使わない」

逆に、うーん、ワカンネ、となったのは次のもの。

• クレイ・シャーキー「ユーザとしてのグループ：フレーミングとソーシャルソフトウェアのデザイン」

気軽に読める本だと思う。

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

読んだ訳ですが。率直に正直に申し上げますと25%程度しか理解できませんでした。自分のレトロスペクティブに関する経験不足が一番大きな原因だろぅと思います。今のままでは、このまま2周目3周目と読んでも50%に達する事ができるかどぅか、わかりませんのでしばらく置いておこぅと思います。
ただ、負け惜しみをひとつだけ！
「翻訳された日本語が難しい」、と他の方は思われませんでしたでしょうか？なんか、主語がイマイチ曖昧だったりする箇所が多かったよぅな…。とかは訳者の方に大変失礼ですね、気のせいでしょぅね。
この本の中には役に立つであろう、理解したいと思う事がたくさん書いてあるのはわかっていて、ちゃんと理解をしたいので期間を空けて再チャレンジいたします。あ、なぜか9章だけは普通に理解できた。やっぱ俺の日本語読解力不足か経験不足なんだろぅなぁ。悔しい。

夢をかなえるゾウ

読んだ。噂通り良い本だったと思った。好きなのは「決めた事を続けるための環境を作る」。
他にもたくさんあり、全然できていない事ばかり。あとは「やるのかやらんのか」で決まるワケだ。
今のところ完全にすべてに対して同意した訳でもないし全部をやる気は無いけど、いくつかはやってみなきゃワカランと思うので着手しよう。
非常に良い本だと思う。若者応援本ともいえるかも。順番としてはこれを読んでから「ウェブ時代 5つの定理 この言葉が未来を切り開く!」を読むのがいいかもしれない。