2010-02-14

最近でもなく読んだ本

裁断とスキャンが停滞している間にまた部屋の蔵書が幅をきかせ始めた. "最近読んだ本" で自分のページを検索したら, 最後は 2008-01-11. 二年分か. そりゃかさばるわ. さっさとメモして処分したい. 順不同.

(もうすぐ処分します. めぼしいのがあって物理的に無事なら差し上げますのでご連絡を.)

RESFful Web サービス

わかった気になっていたけれどわかっていなかった話が多く, 面白かった. 私が REST だと思っていたのは REST-RPC ハイブリッドだったのかとか, connectedness がないと REST としてはいまいちだとか. 特に 8 章のベストプラクティスについては, トランザクションや一括取得のように素人が考えたらうまく設計できなそうな 話題に定型を与えているのがよかった.

実際のデータは階層化されていなかったり unified interface では記述しにくい操作を色々もっていたりするわけで, 本を読んだだけでは REST にはならない. REST にするという意思を持って制約を受け入れたりデータモデルを調整したりという 経験をつまないと, RESTful な資源を持つことはできそうにない.

私はいまいち RESTful であろうとする動機を感じられていないけれど, それは Web の仕事をしているわけではないからだろうね. あとは一般的なデータモデリングの技量がが足りてないせいで, 実際のシステムを RESTful にするイメージを持てなかった. (RESTful の前段階でイメージを欠いている.) RESTful な設計がそれなりに険しい道程だと理解できたこと自体は収穫だと思う. あと REST と口にする人の理解の程度を推し量りやすくなった.

(状態: 分割済)

アート・オブ・アジャイルデベロップメント

もらいものです(が, 結局 PDF を買ってよみました). 何か書こうと思ったけれど, Amazon を見たら ただただし さんの レビュー が大変まとを射ていたので気が済んでしまった... 要するに 適当な薄い本 を読んで Agile なり XP に興味が持てたならこれ読めばいいんじゃない, といえる網羅的な教科書だった.

著者はソフトウェア開発の敷居を下げるのではなく, 高い理想を示すことでそのバーを上げる. 私はもともと重量プロセスが大変そうだからアジャイルに興味を持ったクチなので, この本に出てくる割と大変なかんじの Agile には現実をつきつけられた感じで少し気が滅入った. 各章に "こんな(困った)時はどうすればいいでしょう?" という問いに応えるコーナーがあるんだけれど, 最終的には "メンターに相談せよ" としている部分が多い. 草の根的に野良ジャイルをしている身からすると, これは "なんとか自分で考えろ" という意味になる. 教科書を読むだけじゃダメだからアタマ使えよな, という当たり前の結論から逃避させてはくれない. アンナ・カレーリナの法則 ("Happy families are all alike; every unhappy family is unhappy in its own way.") は遍在している.

(状態: スキャン済, PDF)

The Back of The Napkin / 描いて売り込め! 超ビジュアルシンキング

図を描けば一目瞭然でみんなハッピー, という話. 定量的なデータを手書きで可視化しましょうだとか, 可視化するにあたって大量のデータの肝となる部分を 見抜くにはどうするかだとか, そういう話だった.

説明に登場する図や絵は確かに高い説得力を持っているけれど, 本の中で説明されている技法に則ってもこの絵に辿りつける気がしなかった. 著者は何か重要なことを説明していないと思う...

それはさておき "量" が色々と図示されていく様子を見ていて思ったことがある. ソフウェアを図示するための記法...というか UML は, ソフトウェアやシステムの構造(要素の幾何的な関係)をうまくとらえているものの, 量に関する情報は十分に扱えていない. サーバサイドのシステムだと, 性能やスケーラビリティといった量の問題が ソフトウェアの設計を決める上で大きな関心事になる. それをうまく扱えないのは問題だと思う. たとえばクライアントとサーバの関係を図に描くと, A より B の方が "量" の情報を うまくとらえていると思う. (ケタが違うはずので不正確には違いないれど.)

性能だけでなくコード規模だとか価格だとか, ソフトウェアにも関心を払うべき量は色々ある. ソフトウェアの記法を使う上でそうした量の扱いに工夫の余地があると気付けたのは収穫だった. そのうち Martin Fowler が Quantitative UML とか言いださないかなあ.

(状態: たぶん無事)

ひろこっちのたのしいかんたんイラスト練習帳

Napkin 本著者が描く図の説得力は, 実は結局絵が上手いんじゃないか? という疑惑により. でもたぶん濡れ衣.

ノート片手に友達と酒を飲みながら読むと楽しい. チュートリアルに従って描いた絵をお互い馬鹿にしあってあそぼう. ただ下書きにペン入れするスタイルを想定しており, ホワイトボード用じゃないかんじ. 下書きレイヤのあるホワイトボードが欲しい.

(状態: 無事)

Performance Solutions

そういえば一時期性能問題について真面目に理解しようと思いたち, 何冊か読んだのだった. (でも理解には辿りつかなかった...)

Performance Solution は Code Complete の参考文献にあったので読んでみた. これは開発プロセスも含めて性能を意識しましょう, という話. 性能評価を開発プロセスのどの段階でやるかという主張, 設計段階での性能評価の仕方, 性能の原則, 性能のでる設計のパターンとアンチパターンなど, 網羅的に性能の話題を扱っている. (去年の私が待ち行列理論の授業を受けたのは, この本の性能評価で待ち行列が出てきたからだった.)

たださすが Code Complete から参照されているだけあって, 言ってることは正しいがすみません無理です, という風情がある. 2001 年刊と古いせいもあり, BDUF ありきな開発プロセスを想定している. 序盤の設計からボトルネックになりそうなユースケースをピックアップし, その性能モデルをたてて, 検証して, 代替案を検討して... コード抜きの設計をきっちりやることができない身には辛い. もう少しインクリメンタルにならないものか...

もっともハードウェアの調達を事前にやるなら, 性能の設計も事前にやることになるのは仕方ない. インクリメンタルな開発手法では性能リスクを回避できない気がする. うまいやり方があるなら知りたい. Amazon とか Rackable とか GAE がはやく普及するといいなあほんとに...

プロセスの話は全般にしんどいけれど, 性能の原則やパターンは読んだ甲斐があった.

(状態: スキャン済)

Release It!

これも性能に関する本だけれど, 性能だけでなく安定性や運用までを扱っている. Performance Solution ほど包括的ではないけれど, そのぶん現実的な内容.

とても良い本だった. 読み終わったあとは自分のコードの申しわけなさと腑甲斐無さに逃げたしたくなった. 感想を書こうとすると生々しく角が立つのを避けられないくらい サーバシステムの問題をよく捉えていた.

私が本を絶賛する時は, 自分は本に書いてある内容をいくらか日々の作業に取り込んでうまくいった感触に基いている. この本も絶賛したいけれど, それは自分が本の内容を取り込めておらず非常にやばいどうしようああ...という焦燥や憤りに基いている. 読まずに炎上してから騒ぐ方が幸せかもしれない. ほんと胃が痛い...

著者の経験から説明が Java 寄りなのがいまどきは少し珍しかった. 何かとデッドロックで困っているのは御愛嬌.

(状態: PDF)

The Art of Application Performance Testing

性能試験をどうやるかの話. その主題についてはよく書けていたけれど, 私の興味はもう少し手前の取り組みにあったのであまり関心がもてなかった. ただ実際に性能試験をやる前には読んで良いと思う. 薄いしね.

それにしても Web まわりは性能試験のツールが充実していて羨しい. HTTP はエライ. 私もたまに独自プロトコル(内製 RPC)で性能試験用 bot を書くけれど, これはかったるい上に案外ちゃんと動かすのが難しい. (落ちる, 切れる, 止まる, 遅い, サボる, 嘘つき...) bot のせいで試験に失敗することもよくある. 高負荷でちゃんと動くコードを書くのって難しいんだよね. 一通り全てのエラーがおこるから...

そういう問題を克服しないと, リアリティのあるシナリオをどう作るかといった もう少し水準が上の話題(この本の主題)に進めない. HTTP が大変羨しい.

(状態: PDF)

The Art of Capacity Planning

こっちはマシンを買い足すタイミングをどうしようという話. 買い足すための情報収集として性能監視の話を手厚く扱っている. 実データからとったと思われるグラフが色々出てきて, それがとても面白い. そのデータをその粒度で集めるのかと, 監視初心者の私には新鮮だった.

そのほかなぜかデプロイの話も扱っている. まあマシン買う人とデプロイする人はふつう一緒なんですね... 詳しいツールの使い方は紹介されていないけれど, ツール名はそれなりに列挙されているのであとは調べればいい. この姿勢が薄さに貢献している.

著者は Flickr の中の人. 正直なところ半分は野次馬精神で読んだ. それなりに野次馬向けサービスもあってよかった.

(状態: PDF)

コンピュータネットワーク

ネットワークの古典. ネットワークスタックの上から下までを網羅的に扱っており, お仕事上読んでないとまずいと思い読んだ.

そして読んでないのは大変まずかった... これを読んでいたら今つかってるライブラリももう少しマシなデザインになったのにと後悔が募る. HTTP より下で働くなら読んでおいて良い気がする.

物理層に近い波長の話なんかはさっぱりわからなかったけれど, スイッチの話やルーティングの話は知らなかったことを恥じた. まあルーティングの話は説明しろと言われてもまず無理だから要復習. 輻輳制御まわりや性能に関する議論も姿勢を正して読んだ. アプリケーション層の話は読んでない.

前に同じタネンバウムの 分散システム を読んだ時に感じた物足りなさは, ビルディングブロックとしてのネットワークに関する知識が説明されていない(前提知識になっている) からだったと気がついた. (たとえばオーバーレイ "ネットワーク" なわけですね.)

私がネットワーク素人なせいもあるけれど, 2001 年出版なのにあまり古さを感じない. 無線(Wifi, 3G), とか光ファイバーとか Gbit のイーサカードとか, 普及したのってここ数年だもんねえ. 次版が出たらきっと未来の読み物みたいに感じるんじゃなかろうか.

(状態: スキャン済)

jQuery in Action

JS 野郎ぽく振る舞うには jQuery を使えばいいのでは?と思い至って読んだ. その後しばらく使っているけれどいまいち馴染めない. DOM まわりの支援が厚いのはいいけどデータ構造とか文字列とかがないとツライ. ちょこちょこっとやっつけたい時にはいいのかも知れない.

...というのは jQuery 自体の話で, この本は jQeury の説明という目的をきちんと果たしていた. もっともオンラインのリファレンスも充実しているから, それで十分という気もする. 私は断線中に読んだ.

(状態: PDF)

Javascript: The Good Parts

JavaScript を書くのが一向にうまくならないため, 藁にもすがる思いで読んだ. 薄いし.

私のように JS 全然ダメな人が読むよりも, よくない JS で経験を積んでしまったプログラマが "bad parts" を unlearn するために読む本のような気がした. JS の good parts は普通にやっていれば身につくと思うので, 現実にはどんな bad parts が現れるのか, それををいかに回避するかを教えてほしかった. 単純に私が経験不足なのかもしれないけど.

(状態: PDF)

Linux DB システム構築運用入門

主に MySQL の高可用性構成に興味があって読んだ. 勉強になった. 詳しい感想は生々しくなるので割愛.

高可用性の部分に限らず, 性能改善についても特に DB 本体以外の部分の話がとても新鮮だった. でも仕事でファイルシステムのパラメタや I/O のスケジューラを変更するのは嫌だなあ何となく... 誰かにうまいことやってほしいです. Amazon とか.

(状態: スキャン済)

入門 git

github のチュートリアルより高度な git の使い方はしてこなかったんだけれど, WebKit ウォッチの都合で必要に迫られ購入. おかげで branch と素朴な rebase はできるようになってきた. コンパクトなのがとても良い. (でもそのうち厚い方も読みたい.)

私はもともと Mercurial から DSCM に入ったので, git は複雑そうで敬遠していた. でもその複雑さの半分くらいは概念の一貫性より常用するケースの利便性を優先した結果なのだと理解した.

(状態: 無事 - カンペとして手元に残す予定.)

CouchDB: The Definitive Guide

Rough Cut の時に買ったせいで半分くらいしか読んでない. リリースされたらしいので読み直したい.

Erlang でコードを書くのに良い題材はないかと読んだ. (そしてユーザとして使う分には Erlang は無関係だった...) CouchDB でいう Map-Reduce が何を指すかわかったのはよかった. JSON を保存して クエリーに JS を使うのは面白いと思ったものの, これといって用途を思いつかず. Erlang だけで Blog を実装するチュートリアルがあったので, ああいうノリで何か作ればいいのかもしれない.

ただその後ちょっと CouchDB のコードを読みがっかりしたので熱は冷め気味.

など. buzz 先行なところが Erlang の質実剛健さと似合ってない. そのうち良くなるのかもしれない.

(状態: PDF)

PageRank の数理

ファン読み物として.

PageRank のアルゴリズムとその改善, 類似アルゴリズム等を延々と紹介している本. PageRank アルゴリズムの基本的なところは読んでわかった (というか前に別のところで読んだのものの復習になった) けれど, 数式の性質を利用して高速化していく話はまったくさっぱりだった. もっともこれがスルスルわかるくらいなら機械学習の仕事をして一山あててると思う. 感度(堅牢性のようなもの?) パーソナライズ, 行列の更新といった話は そういう問題意識があるのね, というところはわかった...

固有値とか固有ベクトルって学生の頃はほんとに何に使うかわからなくて退屈だったけれど, PageRank で使うと言われればもう少し膝を正して勉強したと思うんだよね. もしかしたら.

(状態: 無事)

.NET のクラスライブラリ設計

.NET の周辺の API がどんな方針で設計されているかを説明した本. とても面白かった. 命名, クラスやインターフェイス, イベントやプロパティ, 例外, パターンまで, 隈無く .NET way を説明している. 特徴的なのは, IDE での使いやすさを重視していることと, ユーザビリティ試験の結果を反映していること.

たとえば例外はかなり丁寧に設計, スローするよう念を押しているけれど, これは Visual Studio がスローされた例外を GUI 上で目立たせてくれることと対になっている. 引数ありコンストラクタよりも, 引数なしコンストラクタとプロパティセットを推奨するのは, プロパティは IntelliSence のおかげで探しやすい(引数の一覧はやや見づらい)ことに関係しているだろう. ユーザビリティテストについては 前に紹介した. Java になくて .NET にあるのはこれだよ.

ユーザビリティテストを含め, このガイドラインには API の設計(と実装)にかなりコストをかける前提がある. だからインハウスツールなど, 限られた範囲でしか使われないものにはオーバースペックな方針も混ざっているような気がする. 逆に Microsoft はライブラリを作るのに金かけているな, というか金のかけ方を知ってるなと改めて感心した. 開発者向けツールにここまで投資できる組織ってそうそうないよね.

もう一つ, この本は原書 2 版の翻訳なんだけれど, 2 版には 1 版の内容に MS 内外の識者から寄せられたコメントがたくさん載っていて面白い. 各ガイドラインの末尾にカコミとしてコメントがくっついている. コメントの中身は, ガイドラインに至った歴史的事情(.NET 初期の設計ミスで仕方ないんだよ, とか)や ガイドランを適用できない場面への警告など幅広い. API ユーザビリティの専門家 Steven Clarke も多くのコメントをつけており, 楽しく読めた. 満足.

(状態: 無事)

Solid Code

一般的なソフトウェア開発の本. 位置付けとしては "達人プログラマ" のあたりを狙っているのだと思う.

アジャイル, TDD からはじまり, 性能, スケーラビリティ, セキュリティ, デバッグ...といった章立てで話が進むんだけど, トピックが網羅的すぎて個々の説明が全然足りてない. 講演は効かずスライドだけ読まされるもどかしさに近い. 参考文献もすくないので興味のあるトピックがあっても追いかけられない.

また一般的な話をしているはずなのに VisualStudio を使った説明が出てきたり, 上記の章立ての中で唐突に "マネッジドコード" の話があらわれ, ファイナライザとかラージヒープなんて話をはじめる. 全然粒度があってないよ...

Solid Code を襲名するところへの期待が大きかった分がっかり感も大きかった. 半分くらいで放りだした. 後半が面白かったらすみません.

(状態: 無事)

リファクタリング・ウェットウェア

なんとなく読んだ. 朝一番に日記をつける "モーニングページ" をためしてみたものの, さして変化なし.

年寄に必要なのは, 効率より好奇心や情熱, 体力といった何かを成し遂げるエネルギーではないかと思った. 燃料があってはじめて効率を議論できる気がする. 私は自分の QoL とかキャリアへの関心が足りてないなあ.

ただ, この本を読んで, ワインバーグが昔 "毎日メモをとれ" と言っていた(たぶんスーパーエンジニアへの道だったはず.)のを 思いだして仕事で日々のメモをとるようにしてみた. これは今でも継続している. 今年, 自分の中でいちばん進歩したのはメモをとれるようになったことかもしれない. その話はいずれ書こうと思っていたけれど, 忘れてた. そのうち.

(状態: 無事)

コンサルタントの秘密

でワインバーグ. オレンジジュースの法則とラズベリージャムの法則. 飲み食いの絡む法則しか覚えてないことに愕然とした. 処分は延期していずれ読み直そう...

それにしても, ワインバーグって話はとても面白いんだけれど, それが血肉となるかは別問題な気がする.

マイクロソフト ビルゲイツ不在の次の10年

ファン読み物として.

自分がにわかマイクロソフトファンであることを認めざるをえない読後感だった. Microsoft のビジネス構成から VP に類する有名人の紹介と分析まで, すごい情報量. マイクロソフトの事業全体を俯瞰する内容で, かわりに読み物としてのストーリーはない. それにしても Microsoft はでかい会社だなあ. 輝かしい成功のストーリーがひとつくらいあっても維持できる事業規模じゃない.

ファン読み物としては Hard Code の方が面白いらしいので, そのうち探して読んでみたい.

(状態: 無事)

プログラマーのジレンマ

いただきました.

帯には "人月の神話" と書いてあったけれど, 人月の神話というより "闘うプログラマ" だとおもう. オープンソースのカレンダーアプリケーション "Chandler" の開発を数年にわたり取材した読み物.

かつての成功で財をなしたファウンダー(ミッチ・ケイパー)が優秀なプログラマを集め, 私財を投じて Outlook+Exchange の対抗馬を作ろうとしてもがく様を描いている.

著者のスコット・ローゼンバーグはその苦闘の様子を "ソフトウェアを作るのは難しい" と一般化しているけれど, 個人的にはいまいち共感できなかった. ソフトウェアを作るのが難しいことは何も否定しないけれど, 難しいのがわかっている以上, 最初から無闇に複雑なものを作ろうとするのは理にかなっていない. 手元に何もないなら, 小さくはじめてフィードバックを集めながら成長させていくことしかできないと思う. 大きなソフトウェアを作れるのは既に大きなソフトウェアを持っている人々だけだ.

もっともこうした考えが Chandler のうまれた 2001 年に一般的だったのかわからない. そういう意味で, Chandler は最後の徒花的な大プロジェクトの一つなのかもしれない. もっとも同じくらいの時期に同じようなコンセプトでうまれた Groove は MS に買収されたわけだから, 野心的なソフトウェアが失敗する, というのは軽率すぎるかな. ただ博打には違いないよね.

あと本筋じゃないものの, テクノロジーの選択がいちいち地雷方面に進むため読んでいると胃がキリキリしてくる. P2P, RDF, wxWindows(wxWidgets), GCJ で AOT した Lucene を Python から呼び出す... あいたたたな印象は拭えない. これもあとだしならではの印象だけれど.

(状態: スキャン済)

闘うプログラマー

"プログラマーのジレンマ" をよんだあと, 友達と "闘うプログラマ" の話になった. 彼は "カトラーやばいよ, デスマーチすぎる. 絶対一緒に働けない" という. ちょうど復刊したこともあり, そんな話だったっけと読み直した; カトラーやばい. 怖い. そして技術的にも政治的にも無茶すぎるデスマーチ. 翻される指針, 燃え尽きたエース, 腐った C++ のコード, チーム感の鍔迫り合い, うっかり約束した機能...プロジェクト中ずっとそんな調子. セクハラもパラハラもひどい. 有名なフレーズ "人生を書き換えた者すらいた." はデスマで離婚することだった. もうちょっと englighten な含みがあるものと誤解してたよ...

一番恐しいのはこれだけひどいデスマなのに製品が成功, それも大成功を収めるところ. デスマーチの成果物はひどいものになるという通説/大半の真実を打ち破っている. ただこれは稀代のデスマ奉行カトラー, ぼくらの billg, そしてパーソナルコンピューティングという時代の風が あわさっておきた奇跡であって, デスマーチも成功することがあるという事例には数えてほしくない. 間違ってもステークホルダーには読まれたくない一冊.

でも NT リリース後の最後の場面, 次のデスマを求めて Windows95 のプロジェクトに飛び込んでいくカトラーの姿には ちょっとしびれてしまったりもした.

(状態: 無事)

現代の二都物語

復刊つながり.. 兼, DEC 滅亡つながり.

カトラーといば VAX, VAX といえば DEC. 現代の二都物語は, DEC のような東海岸(ルート128)の企業と西海岸(シリコンバレー)の企業の文化の違いを地域的なものと見なし, ハイテク産業では {形式/家族/自己完結/閉鎖}的 な東海岸カルチャーが, {開放/流動/地域コミュニティ}的な西海岸カルチャーに破れたのだと主張する. 1996 年頃の本だけれどなかなか面白かった. DEC 滅亡の理由が地域の文化によるものだとしたら, 文化というのは避けがたい強力な磁場だということになる.

地域の文化を育てる地理的な要因に関する指摘も興味深かった. ルート 128 では各企業がヘリで行き来するくらい離れて点在するのに対し, シリコンバレーはお互いとても近くにある. だから交流もしやすかったというような話や, 西海岸はワシントンから遠くてロビー活動なんかをがんばれなかったので, 政府の資金が入らないぶん勝手なことがやれたという話など. 地理的な類似性から "おらが町にもシリコンバレーを!" と思う読者がいても不思議ではない. むかしビットバレーとか言ってた人達はこういう主張がきっかけだったのかも.

もともと 90 年代に出た本なので, 今やハイテク企業はこうした地域的, 文化的特性にはものすごく自覚的に違いない. だから今の西海岸ハイテク企業がこの本でいう "シリコンバレー的" かというと, そんなことはないと思う. 企業の性格のどこまでがコントロールできる要素で, どこからが逆らうことのできない引力なのか 興味が湧いた.

(状態: 無事)

インテル戦略転換

むかしから "Only the Paranoid Survive" は名著だと聞いており読みたかったんだけど, こんな名前でとっくに(1997 年)翻訳されていた. わかんないよ... 基本的には情勢に敏感で変化に強くあれという話. インテルがメモリ事業から CPU 事業に乗り換える際の苦難を引き合いに出し, がんばれば大きな変化 (10X の変化) も乗り切れるのだと説く. Intel の(元)社長がいうと説得力があるなあ.

ある種の革新的企業系自己啓発本は特定のパターンに従えば未来は薔薇色という風な話をしたがるけれど, アンディ・グローブにそういう気配はない. 変化を乗り切るためには経営陣も含め "資源の再配分" をすることに躊躇がない. すごい.

しかしパラノイアと言いながら, 例の Pentium バグ が あれほどの一大事になるとは思わなかったといい, なぜなら Intel はまだまだベンチャー企業に過ぎないと思っていたからだ... と振り返っているのは面白い. 自分の姿って見えないものなんですね.

Eric Sink on the Business of Software

いまちらっと読み返して思ったことを書いてみる.

Eric Sink は "パッケージソフトウェアの世界" を Paul Graham (や Joel Spolsky) のいう "ハッカーの世界" と少し違ったものとして描いている. そして二つの差分を "開発者" や "ハーモニー" という言葉であらわしている. それでもパッケージソフトウェア, 製品開発には一山あたる可能性があるから, ベンチャー指向 "ハッカーの世界" とも共通点がある. とびぬけて素晴しいものを作れば, 大きな見返りが得られる.

受託開発だとそうはいかない. ふつう実入りの上限は決まっている. だから Eric Sink が 開発者/ハーモニー として描いた差分, Eric 成分こそが受託開発プログラマに重要な素養だといえるのではないか.

受託開発プログラマもコードは書けないと...いってみれば "中音域" くらいは出せないとまずい. 一方でなんとか中音域くらいは出せても Eric 成分が足りていないプログラマはそれなりに目にする. コミュニケーションスキルやビジネススキル(お目汚しすみません)でもハッカー的プログラミング技能でもない この領域について, 受託プログラマはもう少し議論していいのかもしれない. SE になる他にもやることあんだろと主張する上での骨子になりうると思う.

(状態: 無事)

組織行動のマネジメント

チームというのもの価値を正しく説明できるようになりたいと思って読んだ(のだった気がする).

以前から, 私は成果をあげるには(特定の性質をもった)チームが有効であると主張したかった. (年末にはちょっと主張してみた.)

この本を読んだあと, 成果以前にヒトは社会的な生き物である事実は無視することができないと考えを改めた. "人はなぜ集団に参加するのか" を, 著者は "安心感", "ステータス", "自尊心", "親密さ", "力", "目標達成" という軸で説明している. こうした(なかば本能的な)背景を無視し, 得られる成果だけを軸にチームの価値を主張するというのは, 人間の社会性を無視しているし, 自分自身の本能的動機づけを明らかにしておらずフェアじゃない. 人間は本能的に群れたがるものなのだから, それを活用するチームをつくる方が良い.

それにこうした側面を無視すると, スキルベースで適当にシャッフルしてチームをつくるのが なぜ上手くいかないのか説明するのが難しくなる. チームの価値を説明するには, もう少し社会学/人類学的なアプローチが必要だとおもう.

(状態: スキャン済)

影響力の法則

人にお願いをする時には相手の欲しがるものを差し出しましょう. という話. 人はどういうものを欲しがるのか, 自分は何を差し出せるのかといった "通貨", 通貨を交換するプロトコルに関する議論をしたあと, 上司や部下といったよくあるパターンでのケーススタディーが続く. 表題から想像するよりずっとまっとうな本だった.

たぶん誰かにお願いをするのを苦手に感じて読んだと思われる. いまちょっと読み返し, まったく進歩がないことに気付いた...

(状態: スキャン済)

人はなぜ形のないものを買うのか

オンラインゲームのユーザが "アイテム課金" に金を払う動機を理解したかったために読んだ(のだと思う). 実際には仮想世界の課金モデルや, オンラインゲームやコミュニティについて 非専門家向けに概観した内容で, 期待とはやや違っていた. もっと社会的な動機や関心を説明してほしかった. そういう意味では著者が実際にハンゲームをした記述が 面白いといえば面白かったかもしれない. この分野のエスノグラフィーが待たれる. Dana Boyd が MySpace や Facebook にやったようなことを, モバゲーや GREE に対してやった研究はないものかしら.

(状態: 無事)

ネットワーク分析 - 何が行為を決定するか

ネットワーク分析(社会ネットワーク分析)というのは友人関係とか会社の取引関係といっった 現実のネットワーク(グラフ)構造を分析してあれこれいう学問で, これはその入門というか啓蒙書. 自分の social stickiness のの低さというか薄情さは人として問題じゃなかろうか, とか考えているうちに気がついてたら読んでいた.

この本では前半でネットワーク分析に使う基本的な指標(密度, 中心性, 構造同値, クラスタ, 拘束度...)を 簡単に紹介してから, 後半で実際に行なわれたネットワーク分析をいくつか紹介している. 会社員の人間関係と出世の速度, 夫婦がもつ人間関係, コミュニティ, 企業取引といった話題を扱う. 紹介がおおざっぱすぎて印象の薄いものも多いけれど, 前に途中まで読んだまま挫けている Social Network Analysis の motivated example にはなった気がする.

(状態: 無事)

リーディングス ネットワーク論

ネットワーク分析の古典論文から代表的なものを翻訳し, まとめた本.

これはとても面白かった. 上の "ネットワーク分析" に登場する事例のもとねたがいくつか収録されている他, たとえば有名なミルグラムの "6 次の隔り" や "弱い靭帯の力" も原典が掲載されており, 野次馬精神が満たされもした.

特に "弱い靭帯の力" は, 三者関係(triad)におけるごく単純な過程から強い結論=弱い靭帯の力を導き, また調査でそれを裏付けていく様子が面白い. 知人を通じて転職をした人に "その知人とどういう関係だったか" をアンケートしたところ, ときどき合うだけ(年に数度) と答えた人が 55%, また滅多にあわない(数年に一度) 27% だったという. この調査は 1974 年の話だけれど, 今でもありそうな話に思えてしまう.

そのほかには社会関係資本をめぐる二つの研究も面白かった. 一つ目は "社会関係資本(social capital)" と言いだした人の論文 "人的資本の形成における社会関係資本" で, 人間関係を財産と考えることで合理性の元に色々説明できることが増える, と主張する. おっしゃるとおりでございますな. 続いでどのような関係がより強い影響力を持つのかと議論を進める.

著者のコールマンは "閉鎖性" のあるネットワークが強力だと主張する. 閉鎖性があるというのは, 要するに高密度のネットワークだと考えればだいたい正しいようだ. 閉鎖性のあるネットワークは規範や精細が強力に働く. したがって <閉鎖性は社会構造への信頼性を生み出すといってよいだろう> と結論づけている.

こうしたコールマンの主張に, 二つ目の論文 "社会関係資本をもたらすのは構造的隙間かネットワーク閉鎖性か" は異議を唱える. 著者のバートは, "構造的隙間(structural hole)" を持つ関係に社会関係資本としての価値を見出す. 要するに, "まわりの人が知らない人" を知っている方が, まわりの皆すべてと仲良し, というより強力だと主張しているわけ. 構造的隙間を持つ関係は自分を情報のハブにできるので, 新しい/希少な情報を早く手に入れたり制御したりでいる. だから価値があるとバートは主張している.

この二つの主張の対比は面白い. 近所/職場の人とは仲良くしなさい, 外の世界で知り合いを作りなさい, どちらが正しい主張なのだろうか? バートは論文の後半で, これら二つは相補的な関係にあると議論している.

すべての論文には訳者が解説をつけている. その解説がよく書かれており有り難い. 時代背景や文脈, 著者近況, 日本での類似研究を紹介している. 参考文献も豊富なので, また気がむいたら適当にみつくろって読んでみたい.

(状態: 無事)

Pomodoro Technique Illustrated

おおまかにいうと, 30 分単位で仕事をしましょうという話. そのために脳の仕組みを理解して集中力を保ったり割り込みを防いだりする方法を 丁寧に説明してるんだけど...

実際にやってみて一番むずかしかったのは, 計画時に仕事を 30 分単位に切り分けたりまとめたりするところと, 作業を 30 分という予測通りに終わらせること. レビューやメールの返事みたいな細かい仕事は, 集めても案外 30 分もなかったりする. 逆にコード書きに 30 分で区切りを探すのは大変. ちょっと行き詰まって調べものをするとすぐタイムオーバーになってしまう. 世間の Promodo な人がどういう風に作業を区切っているのか, 実物を見てみたい.

というかんじで挫折中. タイマーだけは何かと便利に使ってるけどね...

(状態: PDF)

誘惑される意志

双曲割引というアイデアで色々なものを説明していく. 経済学でには将来価値は現在価値を指数的に割引く (毎年一定の割合で減衰していく) けれど, ヒトの認知はなぜかそのカーブが指数じゃなくて双曲線になっているため, "意志の弱さ" が あらわれるという話. 意志の弱さ以外にも色々なものを説明しようとするんだけれど, 難解すぎておいてけぼられた. 訳者(山形浩生) の解説でちょっとわかった気が回復.

もともとマクド依存対策にと読んだのだけれど, 改めてマクドナルドの巧みさを確認する結果となった. 双曲線が十分に低減する範囲からマクドを駆逐できる気がしません.

市場リスク 暴落は必然か

よく覚えてないけれど金融関係者だった著者の行く先々でおこる損失を 半生記風に紹介しながら, 最後は "ハイテク金融はもう制御するの無理じゃね?" みたいな結論をだしており, 散々稼いだあとにそういうことを言うかと呆れた記憶がある. あと出てくる金額の桁がおかしくて金銭感覚にインパクトがあった.

(状態: 無事)

依存症と家族

Twitter 依存症にどう取り組もうかと考えるために. 表題からわかるように, 本書の立場は "依存症の症状は個人に出るが, それは家族が抱える問題の表出である" というもの. ケーススタディー風に症例を紹介しながら心的なメカニズムや解決の取り組みを示す. が, 独り暮らしの身にはいまいち興味が持てず. 娘が登校拒否で奥さんが Twitter 中毒といった家庭の人は 興味深く読めるんだろうけど... "依存症と独身" だったら食い入るように読んだかも.

個人的には Twitter に限らず social media 依存症は SE の鬱病と同程度には深刻な問題になりうると思っているので 専門家による真剣な取り組みを待ちたい.

(状態: 無事)

インセンティブ

最近多い経済学読み物の一冊.

まずインセンティブの概念をを "汚い皿", "駐車券", "セールスマン" の喩え話を軸に説明していく... のかと思ったら, 半分くらい経済学用語を肴にしたしょうもないライフハックみたいな内容で ややがっかりだった. もう半分くらいは, 一冊使って書いてほしいようなテーマをさらっと扱う感じ. 経済学の中心にインセンティブがあるのは確かだけれど, これを単一の関心事として切り出すアプローチはうまくいかないのかも.

(状態: 無事)

バイアグラ時代 - "魔法のひと粒"が引き起した功罪

米国でおきたバイアグラをめぐる悲喜を批判的な視点で描く. いかにバイアグラが生まれたかという話から, "女性向けバイアグラ" を巡る探求まで. 米国ではおそらく日本よりだいぶ盛んに使われているらしく, それだけ話題も多岐にわたる. 大変面白かった.

本書は, バイアグラ現象の温床を生んだ社会的, 歴史的, 経済的, 政治的要因に始まる. つまり, 勃起不全という社会問題の創出, ファイザーにおる ED のブランド化, 性機能不全の男性大衆の構築, バイアグラとの関連における <男> についての男性患者や医師による多様な解釈を可能にした要因である. その後, 分析の焦点は, 性機能障害のカップルである大衆の "お相手" - 女性 - に移行する. 私はこれを, バイアグラ現象の "第二段階" と呼び, 結果として生じる "女性用バイアグラ" の探求について記述する. 本書は, 自分の体や性欲, そして(最近亡くなったばかりの)夫を理解しようとする年配女性たちの努力を探り, 女性の性の問題を定義, 治療しようとする権威の競争が起きる科学領域に入る.

個人的に面白かったのは勃起不全が "発明" であるというアイデア. 肥満や鬱など, 人や社会が "発明" したと捉えることができる病気(や不都合な身体的特徴)は他にもある. バイアグラを取り巻く物語が面白いのは, バイアグラはその登場から高々十年程度であっという間に広まり, 社会の認知の認知も急激に変化した点だと思う. おかげで著者のような社会学者がその変化の様子を 包括的に調べることができたし, 時間をかけて変化すれば隠れてしまうような問題も歪みとして表面化した. "社会によって発明される病気" をうつす鏡としてのバイアグラを, 著者はうまく描いている.

正直なところ, 際どい領域の "病気" に "勃起不全" というクリアな名前とを発明して それを撲滅するのが(まるでマラリア撲滅のような)人類への善行であるようなイメージで広報を行い 錠剤のブルーを健全さのイメージカラーに据え, 高齢男性を制覇したら若年, そして女性とスコープを広げていくファイザーの手腕は不謹慎ながら鮮やかで, 倫理的な問題は差し置き惚れ惚れするところがあった. 西新宿の例のビルは敬意を込め勃起御殿と呼びたい.

彼女たちの Sex And The City

"Sex And The City" 視聴者 ("30 代キャリア女性") へのインタビューを通じ, 同ドラマの同時代性を描く. バイアグラ時代にあわせエスノグラフィーブームだったので読んでみた. TV シリーズは見てない. (テレビないしね.) キャリア女性の皆様は大変なのだなあと, ジェンダー的特権にあずかりながら 逆サイドでちんたら生きてる同世代として若干申しわけない気持になった. キャリア(でなくても)男性の危機はリストラとか定年だというから, カウンターがあるとしたら "俺たちの島耕作" だろうか. こっちの方がよっぽど共感できなそうだけど...

(状態: 無事)

クレオール語

"Domain Driven Design" の中で Evans が "Universal Language" を "クレオール" と比喩したのをみて, UL のような希望に満ちたアイデアに植民地の奴隷に押し付けた欧州の言葉をあてるメタファーの適切さに疑問があって読んだ. この本によると, クレオール語の起源や発生過程, たとえば誰から誰に広がったのか, どのくらい土着の言葉の特徴を残しているのかについて, あまり決定的な合意がないらしい. なのでクレオールを持ち出した Evans の民族主義(?) を批判することもできないけれど, クレオールというメタファがソフトウェア開発者に豊かな意味をもたらすこともない気がした. まあピジンじゃないんだぜ, という意味ではいいのかもしらん.

あと一口にクレオールと言っても 沢山ある ことを知った.

(状態: 無事)

子供の貧困

子供というか子供のいる家庭の貧困について. 貧困が世代間で伝播するといった話は他でも読んだことがあったけれど, 世帯所得が "その社会で一番標準的(中央値)の '手取り' の '世帯所得' の半分以下" と 相対的貧困を定義し, 格差との違いを議論するくだりが興味深かった.

著者は日本にあるのは格差問題(だけ)ではなく貧困問題であるという主張を軸に 政府による所得再配分の失敗を含めた様々な問題を指摘する. 特に日本人が貧困の問題を直視しようとしないという指摘や, 子供に対して冷たい傾向への危惧など, 耳の痛い話が印象的だった.

子供に対する扱いの悪さや貧困問題の忌避といった問題にうっすらと絶望するのは, 自分自身がこうした問題と積極的に闘う様子をまったく想像できないからかもしれない.

(状態: 無事)

ルポ 貧困大国アメリカ

貧困つづき. アメリカやばい. 貧乏だと軍隊に送られてしまう. 世代間伝播とかいうレベルじゃない. "子供の貧困" で紹介されていた子どもの貧困率もアメリカが突出していた. 情報産業で働いているとアメリカ最強な感じがしてしまうけれど, 国家としてはだいぶ軋んでるよね.

(状態: 無事)

そのほか新書など

以下小説. 小説はだいたい無事.

ブラックジュース

"ああ, 愛しい子" ぼくの後ろで, マイがすすり泣いた. "ちっちゃなかわいい子"

抱っこしてあげるにはちょっと遅過ぎるよ, とぼくはもう少しで口に出しかけた. ぼくはいらいらして怯えていたし, ばかみたいなことをいうマイにつきあうには大きくなり過ぎていた.

"さあイック, これからわたしたちできれいい飾ってあげるからね" イックの頭を囲むように花輪を置きながら, 母さんがいった. "おまえが逝ってしまっても,ここにくれば花があるから, おまえがいた場所がわかるわ"

"花なんか, ほんとうにすぐ枯れてしまうわよ --- 見たことがあるもの" 閉じた口の隙間から押し出されるイックの声は, くぐもった響きを帯びはじめていた. "熱で萎れてしまうんだから"

短編集. 読み口は軽いけれど印象は新鮮.

ナイン・ストーリーズ

彼女は電話が鳴ってもいっさい何も中断しないタイプの女の子だった. 電話なんて思春期に達して以来ずっと絶え間なく鳴っているみたいな顔をしていた.

小さなマニキュアのブラシを手に, 女の子は電話が鳴っているのをよそに, 小指の爪にとりかかり, 爪半月のところにアクセントをつけていった. それからマニキュアの瓶に蓋をして, 立ち上がり, 左の --- 濡れた方の --- 手を宙で前後に振った. そして乾いた方の手で, 吸殻の詰まった灰皿を窓際の椅子から取り上げ, ナイトテーブルまで運んでいった. 電話はそのナイトテーブルに載っている. メークしてあるツインベッドの一方に女の子は腰を下ろし, それから ---五回目か六回目のベルで --- 電話器を手にとった.

柴田元幸による新訳. 自分の中にあるバブル期 OL のステレオタイプのプロトタイプは これ(の野崎訳)だったと気付いてショックを受けるなどした.

シェル・コレクター

彼女の人生のすべては --- 健康, 幸福, 愛さえも --- 風景によって決定された. 彼女はそのことに気づきはじめていた. 住む世界の天候は彼女の魂の天候と分かちがたく結びついていた. 動脈の風はやみ, 肺には灰色の空が垂れこめた. 耳の奥で脈動が, 流れる血の響きが聞こえた. それは時そのものだった. なめらかに過ぎゆき, とりかえすことはできず, 永遠に失われる瞬間を着々と刻んでいた. 彼女はそのひとつひとつを悼んだ.

奇跡も語るものがいなければ

ねえ, わたしたちのお話を聞かせてよ, いつかわたしたちの子供たちがせがんだとき, 聞かせるみたいに聞かせてよ, と彼女は言った.

結婚して最初の数年, 悲しい気分のときや体の調子が悪いとき, それから夜に眠れないとき, よく彼女はそう言った. 頭を彼の胸にのせ, 両手をあごの下にそっと寄せ, ねえ, わたしたちのお話を聞かせてよ, 子供たちがいたら聞かせるみたいに聞かせてよ, と彼女は言った.

そして彼はいつも決まって, 昔, 昔, あるところに, 軍服姿もりりしい若くてハンサムな兵士がおりまして, ある日, 仲間とダンスパーティーに出かけていき, 目もあげられずにおりあした, とはじめ, するといつもきまって彼女はむっくり頭をもたげ, あきれた顔をしてみせて, 目もあげられなくなんかなかったじゃない, あの晩ずっとわたしに色目を使ってたくせに, と言うのだった.

そして彼はいつもきまって二本の指を彼女の唇に当て, ですから若くてハンサムな兵士は, 気づくと目の前に若くて素敵な女性が立っていて, しかも踊りませんかと誘ってくれるのですから驚きました, と続け, すると彼女は, それからどうなったの? ふたりは踊ったの? ふたりは上手に踊った? と聞くのだった.

特徴的な文体の種明しは訳者あとがきに.

最後のユニコーン

"それで, いつか魔法を見つけたら --- どうなるのさ?"

"そうしたら, あの呪文が解ける. そしてぼくは死に近づきはじめる. 生まれたときと同じように. どんなに偉大な魔術師でも, 普通の人間と同じように年をとる. そして死ぬんだ"

きちんとファンタジーで嬉しかった.

そのほか小説

...

技術書やビジネス書の読み方が年々雑になっていてよくない. すくなくとも読んだ本の話はもう少しこまめに書かないと中身をすっかり忘れてしまうと反省.

小説はなんとか柴田依存を回避しようと右往左往したら全然読めなかった. 嗜好が完全に支配されちゃってるので, 独占を認めて依存しとこう.