本

スティーブ・マコネルの『ソフトウェア見積り』を読了した。

『ソフトウェア見積り』は、ソフトウェア開発における工数や期間を見積もる方法について詳細に解説した本。見積もりについて学んだことのない私にとっては、実に有用かつ勉強になった。

知識がある人でも、開発計画立案や見積もりに携わるならば読む価値はあるだろう。PMP (Project Management Professional) を持っている上司が、「読み終わったら貸して」と言ってきたくらいだ。

ちなみに、著者は Code Complete コード・コンプリート を書いた スティーブ マコネル氏だ。最初は気づかなかったが、裏表紙裏に書いてあった。

- 『ソフトウェア見積り』を読んだ理由

『ソフトウェア見積り』を読んだ理由は、自分の見積もりの技能を高めて、チームの生産性を向上させるためだ。2007-01-08 の「デッドラインを読了」に引き続き、プロジェクトをよりよく進めるための読書。

プロジェクトの開始前などで、上司からよく「*** の工数を見積もって」と言われる。しかし、見積もりについての知識が乏しいため、私の作成した見積もりには少なくとも以下の問題がある。

・見積もりが自己流。研修などは受けていないし、そもそも組織内で開催されていない。
・どうやって見積もったらいいかわからない。とりあえず人月や人日は出すが、自信が持てない。
・過去データからの推測しての見積もりや、単純にタスクを積み上げて見積もるくらいしかできない。
・見積もりの正確性が低い。タスクの見落としや過小評価のせいで、見積もりと実績が乖離している。
・見積もりの有用性が低いので、計画を立案しにくく、変更にも弱い。結果、作業効率が落ちる。
・見積もりと実績についてどのように効果測定をしたらいいかわからない。また、その時間もない。

要するに、見積もりについての基礎知識がないのに、何とかこなそうとしている状態だ。

上司や先輩に教えを乞えば済むのではないか、という意見もあるかもしれない。しかし、上司や先輩は非常に多忙で、私にそんな指導をしている暇はない。

学ぶ機会がないからといって、このまま自分の成長をのんびり待つというわけにはいかない。プロジェクトはどんどんアサインされる。アサインされたプロジェクトを成功させるためにも、まずは見積もりの基礎を身につける必要がある。

- 『ソフトウェア見積り』で面白かった点

全編に渡ってとても面白く、役に立つ。以下、何点かメモ。ただ、役に立つ部分が非常に多く一度に書ききれない。まずは全23章のうちの5章までについてだけメモ。

- 経営陣が欲しているのは、「見積もり」ではなく「計画」である。

14ページ「見積もりの真の目的」から。

経営陣は「見積もった結果、間に合わないと思われます」という情報が欲しいのではなく、「間に合わせるための計画」や、「間に合わせるために諦める機能を選ぶための判断材料」や「そのための追加コスト」などの情報を必要としているという指摘。

これは私も常々意識するようにしている。どんな方法があるかを考えたり、それらを提案するのが私の仕事で、決断するのは経営陣の仕事。ワインバーグの『コンサルタントの秘密』に書かれていた「オレンジジュース・テスト」にも通ずることだね。

- 過少見積もりの不利益は直線的でなく限界がない

27ページ。

ソフトウェアにおいて、過大見積もりの不利益は直線的で有限である。一方、過少見積もりの不利益は直線的でなく限界がない。

これはたしかにそうだ。上司も最初から少ない見積もりを要求してくるということもあり、私はどうしても少なく見積もってしまう。ただ、その過少見積もりの結果発生するコストの増大については誰も気にしていない。前述の通り、見積もりと実績の効果測定をしていないし、やり方もわからなかったからだ。もっと言うと、「振り返りたくない」のかもしれない。

しかし、トータルで見れば、たぶん過少見積もりの不利益を被っているはずだ。今後はそれを上申して、全体のコストが最小になるように常に配慮しよう。

ちなみに、過大見積もりの問題については、「計画とコントロールを通して対処する」ともある。

- 混乱を修正してから見積もれ

46ページ「混乱した開発プロセス」から。

コントロール不能なプロセスを正確に見積もることは不可能。先に混乱を修復する方が、見積もりを改善するより重要だ。

「要求を曖昧にしたままにする」、「まずい設計」などの「回避できるはずの混乱」をまず修正してから見積もれ。それをしないと正確性が大きく損なわれる。

- 不安定な要求には、プロジェクトコントロールによって対処せよ

47ページ「不安定な要求」から。

不安定な要求に対処するには、プロジェクトコントロールによる対策を考えよう。

XP (Xtream Programing) やスクラムなどを検討すること。それらの対策がとれないときにどうするかについては、もっと考えなければならないだろうけどね。

- アクティビティの見落としを避けよ

見積もりには、単にコーディングとテストだけでなく、必要なソフトウェア開発アクティビティをすべて入れること。アクティビティ (作業) の漏れや見落としを避けることは、正確な計画や見積もりをつくる上で非常に重要だ。WBS (Work Breakdown Structure - 作業分解図) による作業のリストアップにも通ずる。

48ページでは、忘れられがちな機能要求・非機能要求を18項目挙げている。とても有用。実際に私が過去のプロジェクトなどで見落とした項目がたくさんある。今後はこれをチェックリストとして活用したい。

50ページには、見落とされがちな開発アクティビティの36項目の一覧、開発外アクティビティの10項目の一覧を挙げている。たとえば、テストデータ作成や、あらゆる種類のレビューなどだ。私も、WBS を作るときや計画を作るときに、これらを入れ忘れて失敗したことがある。これもチェックリストとして使える。

72ページ。
COCOMOII 見積もりモデルに基づく補正因子。プログラマの経験やスキル、製品の複雑さなど、それらひとつひとつの要因がプロジェクトに及ぼす影響度を数値化したもの。かなり詳細であるため、これらの係数をひとつひとつ評価して見積もりに反映させるのは、ツールの支援がないと大変だろう。しかし、精度は高まるはずだ。

- 開発者の見積もりを削るな

52ページ。

開発者の見積もりを削ってはいけない。なぜなら、既に十分に楽観的すぎるからだ。

これも心当たり大あり。アクティビティの見落としと相まって、かなり楽観的で小さい見積もりを出してしまうことが多い。私、後輩、みんなこの傾向がある。本人に悪気はないのが救いだ。

私の上司でさえ、要求の変更を指示するときに「*** さんならこの程度の機能は5分で書ける。よろしく。」と言う。冗談交じりに言っていることだし、テストの時間は別途加算してくれてはいるので、まだ良心的ではある。

「開発者の見積もりを削るな」という言葉は、表紙にも書かれている。それだけ重要だということだろう。

Don't reduce developer estimates
---they're probably too optimistic already.

- 6章以降はまた後日メモする

ここまでで、全23章中5章だ。300ページ中80ページ。非常に勉強になった。

残りはまた後日。

『クレジットカードのごほうび』を読了。

カードの有効な使い方と、ポイントや特典が有利なカードを紹介した本。カードをあまり使わない人、特典の恩恵や年会費のコストを気にしていない人向けに、こうすればお得というやり方を説明している。

カードをお得に使うポイントは以下の2点。

・支払いは「一回払い」を使い、手数料や金利がかからないようにする。
・カードは一枚にまとめて、ポイントを集約する。ただし、使い方によってはお得になるカードをもう一枚くらいなら持っても良い。

- 『クレジットカードのごほうび』のおすすめカード

特典が有利なおすすめカードが載っていた。興味を引いたのは以下のカード。

62ページ ANA カード。
マイルをためて航空券に替えられる。飛行機を使うことがわかっているならこれ。

68ページ P-One カード。
常に請求時1%割引。その上ポイントまで付く。公共料金の決済だけでも有利。私が今使ってるのもこれ。2006-11-19 の「すべての買い物が1%割引になるクレジットカード P-One カードを申し込んだ」参照。

70ページ セゾンカード。
ポイントの有効期限が永久。

78ページ 出光カード。
利用額に応じてガソリン代が安くなる。利用額1万円ごとに、リッターあたり1円引き。上限30円引きまで。車をよく使う人向け。

- 少額の支払いでもクレジットカード払いで問題ない

32ページ。

Q.
コンビニでカード払いするのって、ちょっと勇気がいります。

A.
「少額だから、迷惑なのでは」と考える人がいますが、コンビニで130円のおにぎりひとつをカード払いしても、ぜんぜん問題ありません。店員さんだって嫌な顔ひとつしませんよ。
むしろおつりを渡すときのミスがないのでうれしいくらいですと言った店員さんがいました。

カードを使えば自分が小銭を数えたりする必要がなくて楽なんだけど、それは店員さんにとってもおなじ事なんだよね。コンビニやスーパーならばサインも要らないし、便利。

トム・デマルコの『デッドライン ソフト開発を成功に導く101の法則』を読了した。この本では、ソフトウェア開発プロジェクトを成功させるための教訓や考え方が小説形式で書かれている。大いに学ぶところがあり、非常に面白い本だった。

私の上司も過去にこの本を読んだことがあるそうで、「デマルコは読んでおいて損はない」と言っていた。また「言えば貸してやったのに」とも言われた。身近に持っている人がいるとは知らなかったので、今回は自分で購入してしまった。しかし、十分元はとれる良書なので問題ない。

- デッドラインを読んだ理由

私はソフトウェア開発プロジェクトの運営や管理の知識に乏しい。雑誌の特集やコラム、情報処理技術者試験のテキスト、そしてウェブサイト程度でしか学んだことがない。ちなみに誌名を挙げておくと、日経コンピュータ、日経システム構築、ソフトウェアデザインなどだ。文献はほとんどと言っていいほど読んでいない。せいぜい XP (Xtream Programing) 関連の書籍を流し読みした程度だ。

今まではそれでも何とかなっていたが、最近はコードや SQL を書く仕事よりも、設計やチームの運営レベルの仕事が増えてきている。そういった仕事を担当する上で、知識や方法論・考え方の基礎が自分にないことは問題だと感じ、学習が必要だと考えていた。研修や勉強会に参加して学ぶのもよいが、まずは本を読むところから始めようと思い、この『デッドライン』を購入した。

- デッドラインで面白かった7つの点

本書は全編にわたって学ぶべきところが多い。その中でも私がとくに面白いと感じたのは以下7つの部分だ。

・正しい管理の4つの本質
・プロジェクトの数量化の必要性。すべての製品のサイズを測定せよ。
・プレッシャーをかけても思考は速くならない。管理者がプレッシャーを使うことが多いのは、他に何をすべきかわからないから。
・曖昧な仕様書ができる理由は、利害関係者間の対立が解決されていないから。
・設計をしていない開発チームと、なぜ設計をしないのかについての考察。
・部下を尊敬すること、気遣うこと、守ることが、プロジェクトにとっていかに大切か。
・良い目標は実現が難しいところに設定される。良いスケジュールは達成される可能性が高い期日で設定される。

いずれも自分の身の回りの問題として考えることができるテーマだ。とくに、曖昧な仕様書ができる理由と設計をしない理由についての考察は、ここ最近興味を持っているテーマでもあり、何回か読み返した。読んだ結果、設計は一般に考えられているよりも非常に範囲の広い作業であること、上流での設計の善し悪しが、プロジェクトに大きな影響を与えることを痛感した。

- 設計が重要

たとえば、業務の担当を決めるということは一見すると管理者の仕事である。しかし、管理という視点だけで担当を決めてしまうと、開発するシステムの質に大きな影響を及ぼしてしまう。

通常、担当者の決定はシステムの構成や機能の切り分けの後におこなわれることが多い。しかし、これは重大な間違いを含む。なぜなら、担当者を決めるためにまずシステムを切り分けてしまっているからだ。つまり、ここが非常に重要な設計の上流工程だったのだ。これに気づかずに安易に担当を決めたり、担当範囲を曖昧にしたままプロジェクトを開始すると、そのプロジェクトの成果物の品質は格段に落ちる。管理は設計の上流工程であるということを認識した上で、プロジェクトを進めることが必要なのだ。

考えてみれば、今まで設計について学ぶことは少なかった。多少学んだことはあるにしても、実装寄りの部分が多く、プロジェクトを進めるという観点からのものではなかった。デッドラインを読んだおかげで、自分に何が欠けていて、今後どんなことを学んでいくべきかがわかった。

- 一度技術から離れて本を読んでみることにした

今までは純粋な技術書を読むことが多かったが、これからしばらくの間、プロジェクト全体を円滑に進めるにはどうすればよいかという観点から、何冊か本を読んでみるつもりだ。

立花隆の「ぼくはこんな本を読んできた」を読んだ。2006-07-03 の「書斎を作る」の続き。

立花隆はジャーナリスト。昔は今よりも勢いと人気があったようだ。

彼の使っている机については、85ページからの「机を求めて」の節に書かれていた。単行本化する前の出典は (『図書』一九八四・九) となっている。彼が理想の机を手に入れるまでの過程は、読んでいてちょっと面白かった。

私は昔から既製品の机の大きさに不満を持っていた。小さすぎるのである。すぐに机の上がいっぱいになってしまう。

ちょっとやそっとの力でゆすっても、ビクともしないような頑丈で重量感のある机で、しかも、九十センチＸ一八〇センチくらいある巨大な机がほしいと思って、あれこれ探し歩いた。

(略)

結局、机として作られたものは、大きさからも、作りの堅牢さからもすべて落第だった。

(略)

最終的に私が選んだのは、横浜元町家具で作っている一メートルＸ二メートルの特大のダイニング・テーブルだった。板厚が四・五センチ、足が一〇センチ角のオーク材で、きわめてシンプルな作りのものだが、大人二人で持ち上げるのがやっとという重量級で、どんなにゆすってもビクともしない。
見て歩いた中で最高に気に入ったのだが、値段もとびきりである。約四五万円もするのだ。

この後、彼は購入について迷い続けることになる。何度もお店に行ってテーブルをなでまわし、そしてさらに欲しくなって悩む。ここらへんの行動がちょっとかわいい。

最終的に彼は購入に踏み切る。高いと言っても車よりは安い。また、文筆業では机が仕事に貢献する度合いは非常に高いということで買ってしまう。仕事に対する貢献度を判断基準に入れているのは合理的だ。快適な環境があるかどうかというのは、長期的に見て仕事の質と量を大きく左右するからだ。こうすると高い物を買うときに踏ん切りが付きやすい。

一方、車より安いからという考え方は、場合によっては危険なのであまりおすすめできない。とくに、趣味の品を買うときにこの論理を使い続けると身を滅ぼす。オーディオ、テレビ、ゲーム、服、時計、アクセサリ、PC、CD と、ちょっと挙げただけでもこれだけある。良いものはよいのだけど、価格性能比と耐用年数を考えることは重要だ。

この判断は正しかった。いまでも私はこのテーブルが日本で入手できる最高の机だと思っている。そして、いい机という条件が、もの書き稼業にとってこんなにも大切なものかということを日々に痛感させられている。

ここまで満足しているわけだし、彼の仕事を考えると良い買い物だったということには同意。

- メモ

やっぱり机は広い方がいい。その利点はものをたくさん置けるということでしかないが、机の機能を考えると最も重要なことだ。メモリを十二分に搭載したマシンと同じで、一度広い机を体験してしまうともう戻れないんだろうな。

ダイニングテーブルで 200cm * 100cm って特大というほどでもないと思う。短辺を使わなければ、だいたい6人がけ位かな? ただ、これを一人で机として使うというのは確かに贅沢だ。

彼の机についての文章は、今から20年以上前に書かれたことになる。その頃は本当に広い机が少なかったのかもしれない。住宅・オフィス事情が良くなった今なら、もっと手頃な値段でよい机を得られるのでは?

ダイニングテーブルを選んだのは見習うべきものがある。広くて頑丈な机が必要なんだという本質を見落としていないからだ。私が机に求めている基本機能もその二つ。私はどんな机を選ぼうかなあ。

インターネット書斎術を読了した。読了まで26分19秒62。2006-07-03 の「書斎を作る」の続き。


2001年から2002年くらいにかけてのインターネットの使い方や紹介についての本であり、書斎についての本ではない。たとえば3章にはインターネットを使った感想が書いてあるが、2006年の現在では必要ないので流し読み。

わずかながら書斎についての記述はあった。もっとも重要な周辺機器は机で、次いで椅子と書見台が重要というものだった。

もう一点心に残った文章。

122ページ

誰でも三冊は本が書ける。自分の経歴や思い出から一冊。仕事から一冊。趣味から一冊。ほんとは、プロになるには、それ以外の何が書けるかということなんだけどね。

誰でも本にする題材は持っているという指摘。これってウェブサイトにもそのまま当てはまる。当サイトなんて上記3つのテーマしか書いてない。でも、だからこそ書けるということだ。

「リンボウ先生の書斎のある暮らし―知のための空間・時間・道具」を読了した。読了まで1時間53分。2006-07-03 の「書斎を作る」の続き。

- 「リンボウ先生の書斎のある暮らし」に書いてあったこと

「リンボウ先生の書斎のある暮らし―知のための空間・時間・道具」は、著者である林望 (はやし のぞむ、愛称リンボウ) が、文筆業という立場から書斎を論じた本。単に書斎の作り方や使い方だけでなく、彼の考えるライフスタイルから書斎の意義について語っている。もともとは「書斎の造りかた」という書名だったが、文庫として収録されるにあたって改題したようだ。

この本の内容は多岐にわたる。書斎の定義から始まり、書斎の作り方と備品や什器の選び方、書斎での時間の過ごし方、文章の書き方、果ては書斎を通したライフスタイルから趣味の持ち方にまで及ぶ。

私は、自分の書斎をどう設計しようか、他の人たちはどんな書斎を持っていて、なにを重んじてそういう設計にしたのかを知りたくてこの本を手に取った。そんな私にとって有用だったのは、2章と5章。書斎の造り方の方法論が書いてあり、参考になる。とくに、固定観念にとらわれずに、自分がの用途と道具と環境に合わせて書斎の設計を考えるのが大切という姿勢は、大いに見習うべきものだ。

57ページ

かくのごとく、何事も固定観念を覆して考えるということがすごく大切だということです。コンピュータだったら、コンピュータ専用の台が必要だとか、("蛍の光窓の雪"の時代と変わりなく) 机は窓のすぐ下に置いてとか、南に庭をとってとか、こういう固定観念は大禁物です。何がもっとも合理的かと考えていくこと、書斎を造る上でも、これがすごく大切なことなんですね。

5章の細かい方法論は参考になった。
「光は頭上の左後方から当てると本を読むときに反射が少なくて良い」とする照明の当て方。PC と本を同時に参照する場合はの書見台の活用。「機能重視のOAチェアが一番」と断言した椅子の選び方。一つ一つが著者の実体験から語られており、有用だった。私も書見台は10年くらい前から使っているが、かなり便利だ。

一方で、1章、3章、4章、6章、7章、8章、9章はちょっと趣向が異なる。後半の章で語られるライフスタイル論は筆者の知見を表していて面白い。しかし、前半の章にある「パソコンの使い方」や「文章の書き方」などは、本気で学びたいのなら他の本を読んだ方がいいだろう。著者の生き方や考え方のファンなら面白いと思うかもしれないが。

- 方法論は合理的だが、思考の柔軟性に欠ける

また、1章の「書斎の定義」での著者の視野の狭さが気になる。書斎は知的生産のためのもので、ゲームやテレビなどがある部屋は書斎の広い定義からも除外したいという趣旨の記述には賛同できない。考え方は人それぞれなので、ゲームやテレビ鑑賞の良さを理解したくなければそれはそれでいいが、私はこういう立場で書斎を定義したくはない。

31ページ

同時に、テレビゲームをやるということも、私は書斎の営為としては除外して考えるのが筋だと思います。私は、なんでああいうものが面白いのか、まったく理解できません。ロールプレイングゲームなんて言ったって、しょせん人間が考えた一定のプログラムの上で遊んでいるだけであって、無限の可能性のある自然とは全然違うわけだから。

確かにゲームというのは、限定されたルールのなかで遊ぶという状況が多い。しかし、限定と制約が絡み合ってゲームの面白さが作り出されるということを、著者は見落としている。

また、ゲームの面白さはジャンルによって千差万別だ。動物的で本能的な快感を刺激するゲームや、ゲームそのものよりもゲームを通したコミュニケーションを楽しむというものある。一概に「理解できない」とするのは乱暴すぎる。

さらに、著者は以下のようにも書いている。

32ページ

むしろそういう俗世間の、通俗な堕落した遊びからは無縁でありたいと願う人のための橋頭堡が書斎だというふうに思っているので、書斎の中ではまずテレビというのは必要がない。

そして、「ダラダラとテレビを見るのはダメだが、能動的に見るテレビなら良い」としている。ダラダラするのはダメというのには納得できる。しかし、ゲームは能動的に楽しむのでさえダメ、何が面白いのか全く理解できない堕落した遊びであるというのは、あまりに狭量な意見だ。方法論は合理的だが、思考に柔軟性が感じられないのが残念だ。

- 人によって必要な書斎が違う

この本では、著者の考える領域の「知的生産」をする部屋を書斎としている。しかし、私が必要としている書斎は違う。偏狭な一部の領域に限ることなく、私の持っている音楽、ゲーム、本、映画、仕事、その他もろもろの学習や趣味を、効率的・機能的に楽しめる部屋、それが私が求める書斎だ。そういう書斎を作ることにしよう。

佐々木俊尚氏の「グーグル - Google 既存のビジネスを破壊する」を読了。所要時間は1時間57分53秒。

- Google そのものというより、ウェブの潮流を解説した本

この本では、ここ5年くらいに Google が発表したサービス、Google がどうやって利益を上げているのか、そして Google が何をしようとしているのかを知ることができる。技術的な描写はほとんど無い。Google は高い技術力と膨大なコンピュータ資源がある、ということくらいしかない。全体的に読みやすかった。

この本は Google を題材にしているが、取り扱っている題材は Google だけに限定した話ではない。検索、ロングテール、アテンションの収集、データの蓄積などは他の企業なども取り組んでいる。つまり、Web で起きていることと、今後の潮流を書いている本だ。ただ、Google は成長して大きな利益を上げる企業になっているようだし、優れた技術者を大勢抱えていることもあって、Google の動向はいやがおうにも目にとまる。そのため、Google を解説することはこれらの題材の先端の部分を解説することになる。この本はそういう書き方をしている。

第6章の管理と監視が進んだ社会は、改めて指摘されると不安になる。著者も書いているが、これは Google がやらなくても、テクノロジーが進めば多くの企業で十分実現可能になる。それが実用化されるのはいつになるかわからないけど、少しずつ進んでいく。過去にそういう便利な社会を想像して胸を高鳴らせたことがあるけど、いざそれが可能になると、その陰の部分が気になってくる。

個人的には便利さを重視して、こういった社会を受け入れることになりそう。人格を複数用意し、それぞれの人格に情報を分散させて個人の特定をされにくくするなど、ある程度の自衛はするだろうけど、技術が進むとそれも無力なような気がする。というか、今でさえそういった自衛を不完全にしかできていない私なので、技術が進んだ社会で私がそれを完璧にこなすのは難しいだろう。

- グーグル - Google 既存のビジネスを破壊するに書いてあったことのメモ

以下、書いてあったことのメモ。

1章。
Google は、テクノロジーを使って既存の仕組みを破壊していく。様々なサービスを無償でユーザに提供し、既存のプレイヤー達を駆逐し始めている。

2章。
検索は、ユーザーの要求そのものに非常に距離の近い技術である。そこには大きな市場がある。検索エンジン広告は、このことをうまく利用したシステムだ。

3章。
検索エンジン広告は、いままでのメディアがカバーしきれなかった領域や、カバーできたとしてもコストがかかりすぎる領域を低コストでカバーすることができる。羽田空港の民間駐車場の物語はその好例だった。

4章。
検索という技術とインターネットによって、いままでカバーされなかった領域をカバーすることとができるようになった。この領域はロングテールと呼ばれている。

5章。
これからの時代では、アテンション、すなわちどれだけ注目を集められるかに価値がある。注目が多ければ多いほど、人やデータが集まる。そこに広告を絡めることで莫大な利益を生み出す。これは広告代理店のビジネスモデルである。

6章。
あらゆるデータを蓄積していくと、それは神の存在を生み出す。そして、その神から見放されることは存在の消滅を意味するようになる。また、国家による監視よりも、データを持っている民間による監視が進む。

「自分のペースでゆったり学ぶ TCP/IP」 を読了。「圏外からのひとこと」「アンカテ(Uncategorizable Blog)」の essa さんが新人向けの教育本として超おすすめと書いてた本。たまたま見かけたので読んでみた。

アンカテ(Uncategorizable Blog) - 新人向けネットワーク教育超オススメ本
http://d.hatena.ne.jp/essa/20060324/p1

- 新人向けの本として良くできてる

確かに良くできてる。

ネットワークでもプログラミングでも、機能をカプセル化してレイヤに分ける重要性を理解することが鍵となるが、それを繰り返し解説している。「『ホームページ』や『メール』は使ったことあるけど、それらのサービスがどう成り立っているかは知らない」というレベルの人には良い本だ。

入門書としては最適。ただ、概念を理解する上で不要な要素はかなり削り、本質の説明にページを費やしている本なので、それ以上を求めるのは酷。とっかかりとして読んだ後は、他の本に進んだり、ウェブサイトで補ったり、経験を積んでいくのがよいだろう。

理解しなければならないポイントは強調されているし、節ごとにまとめが入るので本質を理解しやすい。説明は会話形式で進められるので、この形式に抵抗がある人には読みにくいかもしれないが。

244ページで、「インターネットで最も重要なサービスは DNSであり、Web じゃない」とい言い切っているのが良い。ネットワークがどう成り立っていて、欠かせない要素とは何なのかを伝えようとしているのがわかる。

著者略歴。網野衛二 (あみのえいじ) さん。失礼ながら初めて聞く名前だ。ん? 網野さんが管理している「3分間 Networking」って、あのサイトか! 過去に読んだことあるよ。ICMP というか ping の説明のところで突然入る「沈黙の艦隊」ネタが好きだった。

3 Minutes Networking No.35 第35回レイヤ３ ICMP(ping)
http://www5e.biglobe.ne.jp/~aji/3min/35.html

博士:
そうだ。
それで水中にある物体を探すソナーが出す信号音の事を探信音[ping]という。このコマンドの名前の由来はそれらしい。

助手:
探信音…。

博士:
うむ。
探信音を出すと、音が物体に当たって跳ね返ってくる。そこから擬音の[ping]が使われているのではないかな。

助手:
…。
…!!  交響曲(シンフォニー)です!!

博士:
…沈黙の艦隊かよ。

他のページでもやってた。沈黙の艦隊好きなんだなあ。

助手:
探信音(ピンガー)ー!!

博士:
おいおい。

助手:
浮上角(アップトリム(20°から最大!! 前部タンク全ブロー、機関全速!!

「SE の読書術」を読了した。

- SEの読書術を読んだ理由

昨年末くらいから業務に押されて勉強する時間を作れていなかったが、今月に入ってやっと時間を作れるようになってきた。私にとって勉強の基本は読書にある。作れた時間を使って、読みかけの本やマニュアルを読もうと思った。そう思って何冊か読んでいたときに目にしたのがこの「SE の読書術」だ。

そういえば、読書術すなわち本の読み方って教わった記憶があまり無い。活躍しているエンジニアたちは、本をどんな基準で選んで、どういう方法や視点で読んでるのか、それを知るためにこの本を読んだ。

- SEの読書術に書いてあったこと

10人のエンジニア達の本の読み方や情報収集の仕方、学び方が書いてある。分量は190ページほどだが、びっしりと字が詰まっているわけではないので、実際はもっと少なく感じる。読了まで2時間はかからないだろう。サラッと読む感じ。

53ページから載っている永和システムマネジメントの平鍋健児さんの話は、本質をつかむという点で示唆に富んでいて参考になった。How To ものではなく、「なぜこうなっているか」に触れることが重要。その流れで、「この技術はどの技術に立脚しているのか」と「この技術は誰に使われるのか」という視点が必要だと説いている。

私も似たような例を最近経験していたので、この話には非常に共感が持てた。HTTP の仕組みを知らずに ASP.NET を使うと、考えられないような勘違いをしたりする。また、システムを使うユーザーや要件を常に意識していないと、作りやすさやなどを優先した設計や仕様となったり、ユーザに必要なものを見落とすおそれがある。

89ページからの富士ゼロックス情報システムの柴田芳樹さんの話も良かった。「図に書けるかどうかで理解できたかどうかがわかる」とか「とにかく継続する」など、言っていることは基本的であたりまえのことだが、経験に裏打ちされていて非常に説得力がある。

132ページに、本を読ませたい上司と読まない部下の話があった。話手は富士ゼロックス情報システム・日本ラショナルの荒井玲子さん。「上司が本を読んでいるグループのメンバーは、同じように本を読む。本を読まない上司だと、部下も読まない。本を読まない上司に限って、部下に読ませたがるというもの。

全く同じ話を高校の恩師に聞いたことがある。先生は国語の教師なので、父兄との面談などで「子供が本を読まないんです」という相談を受けることが多い。しかし、そういうことを相談してくる父兄も本を読んでいない。本を読まない父兄やだったら、子供もそうなるのは当たり前だというものだった。要するに子供は親の振る舞いを見て育つし、部下は上司を見て育つということだ。

ザ・サーチ を読了。Google の歩みについて書かれた本。以下、断片的にメモ。

検索を単なるキーワードマッチではなく「ユーザーが探している答え」を返すものと位置づけ、日々洗練を重ねているとのこと。ユーザーニーズを最重視し、つねにユーザの望む物を提供する。そして、そこにはビジネスチャンスがあるというのが Google の考え方。確かに数年前の Google はこういうイメージだった。私の中には Google に対して今でもこのイメージを持ってはいるが、もうちょっと他の要素が入り込んでる感じがする。上手く言えないけど。

ユーザの探している答えを返すコンピュータの目標としてTVドラマ「スタートレック」に出てくるコンピュータを挙げていた。スタートレックのコンピュータは音声入出力が可能で、声で質問を投げかけると声で答えてくれる。確かに、あれなら誰でも使えるし、ある程度の知性を備えているコンピュータではある。

でも、スタートレックのコンピュータは、エンジニアのベラナ・トレス中尉の独り言にも反応して「質問の意味を理解できません」などとエラーを出してしまい「あなたには聞いてないわ」と言われてたたくらいだから、あんまり賢いというイメージはない。ストレージのデータ量はかなり多くて、膨大なデータは持ってはいるようだけど。

ユーザーのあらゆる行動の履歴は宝の山だ。誰が、いつ、どんなクエリで、どんな情報に、どこから、どんな機器を使って、どれだけの時間アクセスしたか。これをひたすら蓄積し、分析し、サービスを提供するためのデータとして使う。これは検索業界に限らず、あらゆる業種にあてはまる。こういったデータから常にユーザのニーズを意識することが重要、ということを再確認した。

本の構成はオーソドックスで、こういう成功企業分析物ではよくあるタイプ。Google とは何か、検索とは何かから始まり、検索エンジン業界の歴史を紹介。その後スタンフォード大学で Google が生まれ、会社を設立し、IPO し、現在の Google まで解説。そして今の検索エンジンが取り組んでいる課題と、そこから見える将来を解説している。

Google 創業者がスタンフォード大学時代の試行錯誤の連続は面白い。膨大なトラフィックで大学の帯域を食いつぶしたり、相手先サーバに高負荷を与えてトラブルになったり。それを乗り越えて Google が大きくなっていくところは、他の企業と変わらない。違いはその成長の速度が異常に速いという所だ。そこに Google のすごさを見た。

2006-03-03 で書いた「プログラミング C# 第4版」を読んでいて、いいなあと思った表現。

ところがあいにく、それはセモリナ粉の種であり、スパゲッティコードと終わりなき混乱を生み出してきました。

48ページの goto 文についての説明のところで出てきた表現。スパゲティの素材となるセモリナを、スパゲティコード (複雑に絡み合ってメンテナンスしにくいプログラム) の素としたジョーク。

幼い頃に給食で出たスパゲティが入っていた袋にはデュラム・セモリナと書いてあって、それが幼い頃の自分にとっては意味不明というか謎めいていて好きだった。その後、本などで調べて、デュラム小麦というものの中心部分を粗挽きにしたものをデュラム・セモリナと呼ぶことがわかったのだが、それでもデュラム・セモリナという言葉の響きはなんだか不思議な感じがする。

プログラミング C# 第4版を購入。ひとまず全22章中の3章まで読んだ。3章はまだ C# の基礎の部分だが、かなり勉強になる。曖昧な部分が消えていく感じ。「そうなんだ」と発見することもいくつかあり、すでにマーカーや書き込みが10カ所くらい入っている状態。

C と Delphi と JavaScript と Perl と PHP と Ruby と C# のそれぞれの文法や仕様が頭の中でごちゃごちゃになることがある。foreach の書き方とか、ループを途中で脱出するのは last なのか break なのかとか、switch case が使えるのはどれなのかとか、bool 型が使えるのはどれなのかとか、プロパティが使えるのはどれなのかとか。

こんな状況で今後 C# を仕事で使うことに不安を感じてた。とりあえずコードを書くことはできるけど、C# を使いこなせていないので冗長な書き方になったり、コードに曖昧な部分が残ったりしかねない。この本を読むことで、それを解決できそうだ。

言語の基礎を記述している章でさえ「勉強になる」と言ってる状態なんだから、より先の章は推して知るべし。早めに目を通しておこう。

オライリーのメールマガジンを読んでいたら、プログラミングC# 第4版刊行のお知らせが書かれていた。


Jesse Liberty著 鈴木 幸敏、首藤 一幸、株式会社情報技研 訳
5040円

2006年2月発売予定とのこと。まだ amazon に登録されてないようなのでリンクは張らない。「プログラミングC# 第3版」では開発運用編と言語詳解編として分冊になってたけど、第4版では一冊にまとまったのかな? 原書は644ページもあるし、そうなんだろうな。

そろそろリファレンスとして一冊手元に欲しいな。第3版は仕事場では何人か持っている人がいるのですぐに借りることはできるけど、メモを書き込んだり、マーカーを使ったりできないしね。C# 2.0 に対応してるなら買おう。


ちなみに、原書ならば日本の amazon でもすぐに手に入る。

- Programming C# 4th Edition は C#2.0 と Visual Studio 2005 対応

うーん、原書は2005年2月なので C#2.0 は未対応な雰囲気・・・?

oreilly.com -- Online Catalog: Programming C#, Fourth Edition
http://www.oreilly.com/catalog/progcsharp4/

The fourth edition of Programming C#--the top-selling C# book on the market--has been updated to the C# ISO standard as well as changes to Microsoft's implementation of the language. It also provides notes and warnings on C# 1.1 and C# 2.0.

と思ったけど、上記解説によると C#2.0 向けの記述や警告があるとのこと。

amazon に掲載されている第4版の原書の表紙画像の右肩にも 4th Edition Covers C# 2.0, .NET 2.0 & Visual Studio 2005 と書かれてるし、それなら翻訳版も十中八九対応してるでしょう。

via: O'Reilly Japan News 第96号

MCAD/MCSD 取得で、赤間さんの本をもらえるキャンペーン中とのこと。

Get MCAD、MCSD キャンペーン！
http://www.microsoft.com/japan/learning/mcp/newgen/upgrade/g ...

新規にMCADもしくはMCSDを取得し、本キャンペーンサイトでお申込いただいた方全員に、企業開発者必携のマイクロソフトプレス刊行技術書籍「.NETエンタープライズWebアプリケーション開発技術大全Vol.1.NET Framework導入編」をもれなくプレゼント

なんで Vol.1 なのかな。ダブらないようにという親心から出た配慮なのかな? Vol.2 以降は持ってる人多いけど、Vol.1 はその重要性が低く見られてしまっているので持ってる人は少ないだろうし。それとも、Vol.2 以降に比べると値段が手頃なので、プレゼントしても懐は痛まないってこと?

- .NETエンタープライズWebアプリケーション開発技術大全 の略称は?

ところで、「.NETエンタープライズWebアプリケーション開発技術大全」って、略称ないのかな? 「エンタープライズアプリケーションアーキテクチャパターン、原書名 Patterns of Enterprise Application Architecture」 の PofEAA みたいなの。

英語にすると The Complete Developing Technology of .NET Enterprise Web Application かな? これを略すと・・・。 TCDTofNEWA ? わけわかんないし、長すぎて覚えられない。じゃあちょっと短くして、CDofNEW でどう? って、略称以前に、この英語での呼び方、正しいの?

いままで通り「赤間さんの本」って呼ぶのがいいのかなあ・・・。

ファウラーのエンタープライズアプリケーションアーキテクチャパターン、原書名 Patterns of Enterprise Application Architecture (通称 PofEAA) を購入。

6000円とちょっと高めの価格の本だが、私の図書購入予算は十分残っているので気にせず買った。


ちなみに買ったのは邦訳版。黒い表紙の原書の方ではない。翻訳の質があまり良くないらしいが、私の場合は英語よりも日本語の方が早く読めるだろうし、細かい訳や言い回しを追いかけるよりも根源にある思想などをつかむ方が大切だと思い、邦訳版を選んだ。もっとも、あまりに読みにくかったら原書を買ってもいいとは思ってる。

PofEAA はずっと前から読みたいと思っていたんだけど、他にもいろいろ読みたかった本があったりして後回しになっていた。チームのレベルを上げるために設計系の本は一通り読んでおきたいと思ったし、いい機会なので購入。

- 開発における悩み

開発では、どう作ろうかといつも悩む。全体のアーキテクチャはこれでいいのかと悩み、DB のテーブルはこれでいいのかと悩み、クラスの構成はこれでいいのかと悩む。で、これでパフォーマンスに問題がないかと悩み、今後の拡張や仕様変更に強いかどうか悩む。デザインパターンが悩みから解放してくれるんじゃないかと期待した時期もあったが、私の悩みを解決するものでなかった。

結局、すべてを満たす方法はないってことを学んだ。ある設計にはメリットとデメリットがある。現在置かれている状況と、ほんのちょっと先の将来のことを念頭に置いて設計やコーディングするしかないと思った。扱っているビジネスが複雑なんだから、ビジネスロジックやデータ構造が複雑になるのは仕方がないと悟った。悩むのは大切だが、何を切り捨てて何を残したかを明確にしておくことと、とりあえずプロトタイプを作ってみる方が道が開けるということに気づいた。

他の開発者がどう割り切りと妥協をしてどんな設計をしたか。PofEAA を読むことで、そういった設計の思想や試行錯誤に触れられるといいなと思ってる。

- PofEAA の後は何を読もうかな

PofEAA を読み終わってないのに次に読む本を考えるのもどうかと思うが、PofEAA を読んだ後はマイクロソフトコンサルティングファームの赤間さんが書いた「.NETエンタープライズWebアプリケーション開発技術大全」シリーズをもう一度読もうと思っている。今の私は .NET がメインなので、もしかしたら PofEAA よりも赤間さんの本を先に読んだ方がいいかもしれない。

扱っている問題領域も PofEAA より広く、かつ .NET ではどうすればいいかが書かれているという点で実用性が高い。エラー処理やロギングなど、PofEAA が扱わなかった問題についても言及していたはず。その分冊数や分量も多いけど。

Vol.2 のASP.NET基礎編と Vol.3 のASP.NET応用編、Vol.4 のセキュアアプリケーション設計編はざっと読んだけど、Vol.5 のトランザクション設計編 はまだほんの少ししか読んでない。というのも、去年の年末か今年の初め頃に赤間さんのワークショップを受けたとき、「Vol.5 のトランザクション編はいつ出るんですか?」と聞いたら「もう少しで出ますよ。ちなみに Vol.5 は結構重い内容で、レビューが大変だったんですよ。」といったことを言われて、その言葉が結構重くのしかかり、読み始めるきっかけを失っているからだ。そんなこと気にしないで読めばいいのにね。ちなみに Vol.1 はあんまり必要な気がしなかったので、立ち読みで済ませた。

「.NETエンタープライズWebアプリケーション開発技術大全」が終わった後はデータベース設計系かなあ。データモデリング系の本がいいかな。

追記。
Patterns of Enterprise Application Architecture の略称を PoEAA と書いていたが、PofEAA の方が一般的なようなので修正。PofEAA だと なんかウィザードリィのアイテムの名前みたいだ。「STAFFofGNILDA (ニルダのつえ)」とかね。逆に PoEAA だと PPPoE (PPP over Ethernet) みたいな感じ。

「Winny の技術」を読了した。この本はピアツーピア (P2P) のファイル共有ソフト Winny を、その作者の金子勇氏が解説した技術解説本。純粋に Winny の設計と実装を解説した技術本であるため、Winny の使い方や法律論などは載っていない。

2005-10-05 の『Winny の技術解説本「Winny の技術」を発注』で購入しておいたのだが、読むのがだいぶ遅くなってしまった。

- 資料的価値がある

今まで Winny のソースコードやプロトコルは非公開だった。Winny の設計や実装を学ぶためには、配布された実行ファイルをソースコードに逆変換したりするリバースエンジニアリングや、通信パケットを解析するのが一般的だったようだ。また、作者自身とユーザーが掲示板などに書き込んだ情報を元に推測するということもおこなわれていた。

Winny のネットワークは大規模といえるレベルまで成長しており、その設計と実装を作者自らが解説したこの本は、資料的価値がある。以下に参考になった部分を列挙する。

- 上流と下流によるノードの重み付け

Winny では、Winny ネットワークに参加するノードを対等な関係とするのではなく、上流と下流という概念を取り入れ、回線速度や処理性能で分類している。

過去の P2P アプリケーションは参加するノードが入り交じり、全体の効率を落としていた。回線と処理性能に余裕があるノードは上流に位置づけ、大量のデータをやりとりさせる。また、人気のあるファイルは上流でキャッシュするようにし、Winny ネットワーク内での流通速度を上げる。一方、回線や処理性能に余裕のない下流ノードは上流のノードにぶら下がるようにし、相応の負荷に抑える。

この仕組みであれば、上流は負荷が高いがその分大量のファイルを受信できるし、下流よりも広い範囲でファイルを探すことができる。下流は自分の身の丈にあった範囲でファイルを探すことができ、それぞれの住み分けができる。

上流と下流の概念があることで、どんな参加ユーザーでも受け入れることができ、ネットワーク全体の受容能力が高まる。ネットワークの価値は、まず参加しているノードの数で決まる。もちろん、各ノードの持っているリソースの質も重要だが、量は質に転換する。それを踏まえた設計になっているのが素晴らしい。

- クラスタリングによる分割統治

Winny はクラスタという概念を取り入れ、ネットワークの規模が大きくなっても効率を落とさない仕組みを実現している。

参加しているノードの数が増え、ファイルの流通量が爆発的に増えると、流通量全体に占める目当てのファイルの比率が下がる。これはネットワークが成長すると避けられない事態だ。この問題への対処は上流と下流だけでは難しい。そのため、目当てのファイルや保持しているファイルの傾向でノードを分類し、集団 (クラスタ) を形成するようになっている。これにより、目当てのファイルの検索ヒット率と、キャッシュヒット率が向上する。

問題解決の基本は「分割して統治せよ」だ。上流と下流という一次元の軸しかなかった Winny ネットワークにクラスタという別の次元の軸を与えることで、大量のノードを分割して統治することができる。しかも、お互いのクラスタは明確に分割されるのではなく、ある程度のつながりを保持したままゆるく分割されていく。良くできた仕組みだ。

- 自動ダウンロード、自動ハッシュチェック

Winny は自動ダウンロード、自動リトライ、自動ファイルハッシュチェックなど、Winny ネットワークとアプリケーションの信頼性を高める仕組みを導入している。

欲しいファイルを「予約」して Winny を起動しておけば、あとは Winny 自身が勝手にファイルを持っているノードを検索し、リクエストを発行してダウンロードし、ファイルの整合性のチェックまでしてくれる。

この仕組みはユーザの手間を減らすという点で非常に強力だ。とくに、ネットワークアプリケーションで懸念されるデータ化けやファイル破損を、MD5 ハッシュのチェックをおこなうことで回避している点が良い。TCP 自体にエラーチェックの仕組みがあるが、アプリケーションが保証していることが重要だ。

この仕組みがあることで、数百メガバイトを超えるファイルの共有も安心してできるようになる。チェックは自動でおこなわれるので、ユーザーに手間をかけさせない。安心して任せられるので、流通するファイルが増える。その結果、Winny ネットワークはより大きくなる。

全体的に見て、Winny はファイルの交換を促進する良い仕組みを持っている。IX やプロバイダーが Winny のトラフィックの増加に悩んでいたようだが、これだけの機能を備えていれば、それも頷ける。

- 疑問点

共有できるファイルサイズの上限が 2GB というのはちょっと少ない。たとえば、Debian GNU/Linux sarge の DVD ISO イメージは 4GB くらいあったはず。こういう巨大ファイルは分割しなければならない。開発当時のネットワーク回線事情では、この程度のサイズのファイルを気軽に流通させることはできなかったのかもしれない。

表紙がグレーなのは、Winny の利用される形態が「グレーゾーン」だからかな?

2ページ目の鍵の指紋が気になる。金子氏はこれで何をしようとしているんだろう?

Fingerprint:

16B6 7953 A7C1 2DCA 9DEF C7D1 2546 1CCE C03F 2BA3

- Winny の技術 pdf 版を Winny でダウンロード

Winny の技術 winny ネットワーク上で流通しているようだ。以下がファイル情報。左から順に、ファイル名、 Winny 上のトリップ、ファイルサイズ、md5 ハッシュ。

PDF(一般書籍) [金子勇] Winnyの技術 [05-10-03].zip cbwdWRCPoE 1,900,259 9d2dd618c580e38ea6869c51d9ed1107

経営学者のドラッカー氏が老衰のため死去。95歳。


私が読んだことがあるドラッカー本は、「プロフェッショナルの条件」だけ。ちなみにこの本、その昔に仕事場で全員に配られ、一部の人には読了所感の提出も指示された。確かにいい本だった。仕事に対するやる気を引き出すことができる。

最近こういう本あまり読んでない。自己啓発本ってビタミンみたいなもので、定期的に摂取してないとモチベーションなどを維持しにくくなる。書いてあることは正論で当たり前のことが多く、かつ重複が多いために読まなくてもいいような気がするが、ある程度定期的に読む方がいい。

そういえば、仕事場の上司は「プロフェッショナルの条件」が配られたとき、「内容は読まなくてもわかるよ。ドラッカーだから。」って言ってた。それでもちゃんと読んでいたのは、ビタミンの補給みたいなものだったんだろうな。

P2P 型ファイル共有ソフト Winny の技術解説本「Winny の技術」を発注した。


私が発注したときは amazon は「2から3週間以内に発送」だったが、bk1 は「24時間以内に発送」となっていたので bk1 で発注。

- Winny の作者自身が Winny を解説する

著者は47氏こと金子勇氏。Winny の作者だ。

Winny は非常に興味深い。数十万のノードが参加しても破綻無くネットワークが稼働するスケーラビリティや、「中継」による匿名性の確保、クラスタと呼ばれる効率を高める仕組みなどが面白い。アーキテクチャを知りたくて 2ちゃんねるの Winny 関連スレや「次の雑談」スレ、関連ウェブサイトを読んでいた時期もあった。興味深い内容も多数あったが、いかんせんノイズも多かったし、推測するしかない部分もあった。

しかし、「Winny の技術」は作者本人が書いた本。正確さは折り紙付きだ。この本があれば、2ちゃんねるの Winny 関連スレッドの過去ログや、技術を解説したウェブサイトのアーカイブを削除しても困らなくなるだろう。削除するつもりはないけど。

- Winny のバイナリは今でも入手可能

ところで、今でも Winny のバイナリって手に入るんだろうか? 2004-05-14 の「winny 配布ファイルと exe のハッシュ値」で winny 各バージョンの md5 や sha-1 ハッシュをメモしておいたが、ハッシュ値だけわかってもバイナリが手に入らなければ無意味だ。私は手元にバイナリがあるからいいけど、本を読んで実際に動きを見たりしたい人は探す手間がかかるな。・・・と思ったら、Google で Winny2b71.zip を検索すれば配布してるサイトがあるのね。

司馬遼太郎の「城をとる話」を読んだ。

私もそのうち城が欲しいと思って資金を貯めているところで、そのストレートなタイトルに惹かれて手に取った本だ。もっとも、この本は城を手に入れるのではなく陥落させる話なのであまり参考にはならない。ただ、車藤左やおううと赤座刑部の駆け引きや采配は面白かった。関ヶ原の戦国の世も今の世もやってることは変わらないんだね。

車藤左の振る舞いの他で心に残ったのは、直江山城守の「男というものは、子どものころからの夢をどれだけ多くまだ見つづけているかで、ねうちのきまるものだ。」という言葉だ。かっこいいし、ドキっとさせられた。上杉家の要職に就いている彼が言うと説得力がある。

- 牢人?

読み始めてすぐに思ったのは、牢人ってなに? ということだった。Yahoo 辞書で検索しても、goo で検索してもヒットしない。

http://dic.yahoo.co.jp/bin/dsearch?p=%CF%B4%BF%CD
http://dictionary.goo.ne.jp/search.php?MT=%CF%B4%BF%CD&k ...

仕方がないので Google で牢人 浪人を検索したらヒット。NHK のサイトだし、信頼性は高いだろう。

その時歴史が動いた
http://www.nhk.or.jp/sonotoki/2002_08.html

牢人」（ろうにん）は浪人の誤りではないか？
「牢人」とは、主家を去って俸禄を失った武士という意味。江戸時代中期以後はほとんど「浪人」という字を用いるようになったが、「浪人」の字義は、本来は本籍の地を離れて流浪する浮浪の者の意で別儀である。 よって、今回は舞台が江戸時代中期以前であるため、「牢人」の字を用いました。 ちなみに牢人とは、領地や地位・俸禄などを失って落魄（らくはく）することを牢籠（ろうろう）といい、牢籠としている人すなわち牢籠人が縮まって牢人の語となった。（『国史大事典』より）

なるほど。「城をとる話」は関ヶ原の戦いの直前が舞台なので、司馬遼太郎は牢人と表記したのだろう。「るろうに剣心」なんかは明治時代の話だったが、時代が時代なら流浪人ではなく流牢人だったのかも。字面があんまり良くない気がするなあ。

ゲーム脳やメール脳という用語で一時期話題になった森昭雄日大教授の本。

前著「ゲーム脳の恐怖」はその非科学的な論理展開や、実験の手法そのものについて批判があったようだ。私は「ゲーム脳の恐怖」を読む機会が無かったので、そろそろ読もうかと思っていたところ。そうこうしていたら、新しく「ＩＴに殺される子どもたち 蔓延するゲーム脳」が出版されていたのでこちらを読んでみることにした。前作への批判を受けて、多少は科学的になっていることも期待できるかもしれないし。

- ＩＴに殺される子どもたち 蔓延するゲーム脳 ってどんな本?

脳の活性を表現した写真や著者の意見に基づいて、ケータイや PC やゲームばっかりやってると人間らしい感情や理性が無くなる、体を使ったり、自然とふれあうことが大切、という主張の本。

主張したい内容についての因果関係の説明が省略されている部分が多く、科学的な裏付けに乏しい。一方、主張したい事項を繰り返し書くことで、読者の恐怖感を煽っているように感じられる。全般的に IT、メール、ゲームを目の敵にしている雰囲気が漂う。同じ考えを持ってる人には良いよりどころとなりそう。科学的でないから論拠としては非常に弱いけど。

この本から吸収できたことは、「同じ事ばっかりやってるのは良くない」ということだ。あとはどうも非科学的で信頼性に乏しい。「同じ事ばっかりやっているのは良くない」という主張は、過去に類似の例を見たことがある。といっても IT や ゲームではなく、仕事ばっかりやっていた人の例だ。

- 同じ事ばっかりやっているのは良くない

かなり前の NHK の放送で、仕事ばかりやっていて痴呆症になった男性の話が放送されていた。内容を思い出してみる。確か営業か経理か総務をやっていた男性。仕事はバリバリやっていたが、人や物の名前を思い出せないようになってしまう。冷蔵庫を指さされて、あれは何? と聞かれても、名前が出てこないという症状だった。妻の協力で散歩などをするようにして療養しているというもの。うーん、断片的だな。

Google で NHK 痴呆 仕事 妻 名前を検索してみたが、これという情報は見つけられなかった。以下のは違うような気がするし。

クローズアップ現代　放送記録 2001年7月
http://www.nhk.or.jp/gendai/kiroku2001/0107-2.html#tue

7月10日(火)放送
ものを忘れる若者たち

「つい今しがたの出来事が思い出せない・・・」
最近、この“物忘れ”に悩み、脳の専門外来を訪れる20代30代の若者が増えている。会社を解雇されたり、人間関係を壊したりと状況は深刻だ。

むしろ以下の方が私の記憶に近い。

[教えて！goo] 悩んでます！！若年性の痴呆症について
http://oshiete1.goo.ne.jp/kotaeru.php3?q=1070538

ＮＨＫだったかの番組で以前やってました。大変忙しい仕事をしていて、家にまでも仕事を持ち込んで仕事をしていた人が若年性痴呆になったという話でした。細かい計算や、事務の仕事をしていたように思います。
　事務の仕事は最初は大変頭を使うのですが、段々と慣れてくると一部分の脳しか使わなくなって、他がほとんど遊んでしまっている状態です。忙しいということは一日中同じ仕事をし続けているわけですので、一日中頭を使わない日があるということです。
　脳細胞は、筋肉に近いそうで、使うとどんどん使いやすくなるし、使わないでいると、細っていきます。

そういえば、痴呆症は今は認知症と呼ぶんだっけ?

- プロパガンダの四要件

この本に関してはプロパガンダが成立している。私が若かった頃に学んだプロパガンダの四要件に当てはめてみる。この四要件は成功したプロパガンダに共通している項目だ。

プロパガンダを成功させるために必要な四要件
1. 潜在意識の活性化
2. 関心はあるが個人的判断が困難
3. チャンネルの一元化
4. 娯楽性

1. は人間が潜在的に持っている意識を、煽ることで活性化すること。「ゲーム脳」という題目を掲げ、かつ「ゲーム脳」となっている者のネガティブな振る舞いを繰り返し書くことで、読者の潜在的な恐怖感を煽っている。これにより 1. を達成している。

2. は、脳波は素人ではわからない。また、脳の活性などはビジュアル的に表現されていても、それが何を意味するかを読みとるのは困難。これで 2. は達成。

3. は、メディアが反対意見や批判をほとんど載せないことで達成している。ウェブ上の書評などではかなり鋭い意見が出ているが、それがテレビなどを通じて広く伝わらなければ結局 3 を達成できてしまう。

4. は楽勝で達成している。「ゲーム脳の恐怖」や「IT に殺される子どもたち」などというタイトルは衝撃的で刺激的だ。派手な演出も可能だ。

- IT に殺される子どもたち で心に残ったこと

同じ事ばっかりやってるのは良くない
体のいろんな部分を駆使する方が脳は活性化する

私は夜型。仕事場に向かうために部屋を出るのは、早くて午前9時くらい。一時期、仕事場の都合で9時が仕事開始時刻になっていて8時過ぎくらいに部屋を出ていた時期があるが、恩恵は少なかった。

道路はいつもより渋滞していて、運転しててもあまり楽しくない。
朝は掃除してる人がいたり、受ける電話が多かったりするのに電話担当が居なかったりとノイズが多い。
仕事の終了時刻はほとんど変わらない。
早出を強制されてることもあり、精神的な余裕が生まれにくい。

まあ8時出ってぜんぜん朝型じゃないんだけど、いつもより早く出ることがこんなに大変なのか、ということを実感するにはまったく十分だった。しかも恩恵が少なかったので、今の私には朝型に切り替える動機がない。でも、朝型にするといいよー、朝型、もう最高! という意見は多い。じゃあ朝型にして多大な恩恵を受けられるパターンってどんなものなのか、ということを見るためにこの本を読んだ。

- 「朝10時までに仕事は片づける」の傾向

朝型生活についての記述は多くない。朝型でなくても使える一般的な仕事術や、成果主義など著者の仕事観について書かれている。読了までの所要時間は2時間弱。丁寧語で書かれていて、かつ肯定的な表現が多いため歯切れが良く読みやすい。

- 「朝10時までに仕事は片づける」に書いてあった事の要約とメモ

朝型にするのは、空き時間を作るため。能動的に作った時間は効率的に使える可能性が高い。また、体が慣れると朝の方が頭は働かせやすい。

スケジューリングは大切。仕事には必ず期限を設定し、常に前倒しで動け。
言ってることは正しい。

「巧遅 - 巧みではあるが完成が遅い」よりも「拙速 - 出来は悪いが仕上がりは早い」の方がいい。
これは確かにそうだ。とりあえず出してしまったがいい。時と場合によるけど。

話し方のコツ。結論を先に。肯定的表現を常に意識的に使う。未来についての要素を入れる。
「未来についての要素を入れる」は詳しい説明が無かった。現状分析だけでなく展望と見通しを盛り込めということを言いたいんだとは思う。

電通の吉田秀夫社長の「鬼十則」の6番。周囲を「引きずり回せ」、引きずるのと引きずられるのとでは、永い間に天地の開きができる。
なんかトラブルメーカー推奨っぽいことを言っているような気がするが、そうじゃなくて要するに鶏口牛後ってことね。

世界全体で見るとやっぱり成果主義で競争社会。頑張って働いた人が多くの収入を得る。
世界全体で見ると正しい意見だとは思う。

考えてみれば「仕事は朝十時までに終わらせてしまえ」などというのも、仕事好きの一部の人間には首肯されても、仕事より趣味に人生の生きがいを感じている方々にとっては迷惑千万な主張かもしれません。
でも朝型人間は、最近確実に増えてきています。私の顧問先の企業でも、夜の十二時頃まで働いて、朝七時前には出てくる若手が増えてきているそうです。確かにそのような企業は、こんな時代でも業績がいい。社員が嬉々として働いているからです。

202ページから。この部分は、「社員を嬉々として働かせられない企業ではダメ」、「嬉々としてやれる仕事を選べ」ってことかな。

- 鬼十則

106ページに書かれていた鬼十則。Google で鬼十則を検索したら山ほどヒットした。

電通鬼十則（雑誌「致知」より）
http://www2.ocn.ne.jp/~nakahiro/20030521.htm

１．仕事は自ら創るべきで、与えられるべきではない。
２．仕事とは、先手先手と働きか掛けていくことで、受け身でやるものではない。
３．大きな仕事と取組め！　小さな仕事は己を小さくする。
４．難しい仕事を狙え！　そしてこれを成し遂げるところに進歩がある。
５．取組んだら放すな！　殺されても放すな！　目的を完遂するまでは．．．。
６．周囲を引きずり回せ！　引きずるのと引きずられるのとでは、永い間に天地の開きができる。
７．計画を持て！　長期の計画を持っていれば、忍耐と工夫と、そして正しい努力と希望が生まれる。
８．自信を持て！　自信が無いから君の仕事には、迫力も粘りも、そして厚みすらがない。
９．頭は常に全回転、八方に気を配って、一部の隙もあってはならぬ！　サービスとはそのようなものだ。
１０．摩擦を怖れるな！　摩擦は進歩の母、積極の肥料だ。でないと君は卑屈未練になる。

最近は技術書や参考書ばっかりで、小説や新書をあまり読んでない。本を読まなきゃ。何読もう? ウェブ上の書評や感想を見て回って、面白そうだと感じた本をいくつか見繕って読もうか。


「読書力」に「本調子」か。良いかも。読書量が不足している自分に焦燥感をもたらすには、読書の効用や必要性を訴える本を読むのが良いと思う。たまには自分を煽っておかなきゃ。

結局「読書力」を選んだ。「読書力」は岩波新書であるため手に入りやすく価格も安いということが決め手となった。

- 読書力 に書いてあったことで心に残ったこと

本を読もうよ。本は良いよー。
4年間で新書50冊、文庫100冊が読書力のボーダーライン。
読書力とは要約する力。要点をつかむ力。
お願いだから本を買って。出版界が存続できるようにして。
三色ボールペンなどで要点に線を引きながら読もう。読解力と要約力向上の訓練。
巻末の推薦図書リストの本を読んでね。

ワインバーグの本。

ドラッカーは読んだことあるけど、ワインバーグは実は今まで読んだことはなかったりする。ウェブでの反応や書評は非常に良いし、読んでおこうと思って発注。人生訓というか、仕事訓といったものがたくさんあるようだ。心がゆれたときにはこういう本もいいだろう。

アマゾンで検索しても原書しか登録されていなかったが、bk1 には既に「24時間以内に出荷」で登録されていたので発注。

bk1 コード・リーディング
http://www.bk1.co.jp/search/search.asp?partnerid=p-linux6465 ...


仕事でも、趣味的なプログラミングの場合でもきっと役に立つだろう。コードのウォークスルーとかしていて、もっと迅速に問題を見つけて改善案を提案できるようになりたいし。

mycom の立ち読みコーナーでは pdf で少し読める。
http://book.mycom.co.jp/user/preview/4-8399-1265-3/
http://book.mycom.co.jp/book/4-8399-1265-3/4-8399-1265-3.sht ...

Postgres の入門書である「シーラカンス本」の改訂第4版。ターゲットとなるバージョンは 7.4.2。

amazon にはまだ登録されていないけど、bk1 にはすでにデータがあった。
http://www.bk1.co.jp/cgi-bin/srch/srch_result_book.cgi?aid=p ...

未だに7.2 系列の Postgres を使ったシステムも動いてるけど、安定しすぎちゃってまったく手がかからない。激しいトランザクションがある訳でもないし、データの増加は月あたり10万件くらいしかないからかな。セキュリティホールとか致命的なデータ破壊エラーが無いのであればバージョンアップする理由もない。

[pgsql-jp: 33045] シーラカンス本第4版
http://ml.postgresql.jp/pipermail/pgsql-jp/2004-May/008187.h ...

PostgreSQL 7.4.2対応ですので，7.4の機能についてあれこれ書いた結果，特
に3章が膨らんでしまいました．また，5章もチューニングなどで量が増えてし
まいました．そこで第4章のサンプルをダイエットしました．取り上げた言語
はPHPとPerlのみ，どちらもシンプルな共通のデータベースを使ったWenアプリ
ケーションです．PHPの方は，PHP+PEAR+Smartyという今流行のコンビ．Perlの
方は，DBI+DBD-PgにHTML::Templateを組み合わせています．この結果は，トー
タルでなんとか418ページに収まりました．

発売は6/28です．それと，なんと今回シーラカンスのフィギュアが限定でおま
けについています:-)企画的には大変だったと思いますが，ご尽力いただいた
技術評論社の関係の方々に感謝しています．

フィギュアのもらい方:-)その他詳細については，

http://www2b.biglobe.ne.jp/~caco/fourth_edition/index.html

「改訂第4版・PostgreSQL 完全攻略ガイド」サポートページ
http://www2b.biglobe.ne.jp/~caco/fourth_edition/

以下から予約や購入をすると，限定シーラカンスフィギュアがもらえる特典が付いています

まるでダイドー の MIU の「深海生物コレクション」みたいなフィギュアだ。フィギュアプレゼント対象店に bk1 も入ってるみたいだし、次に Postgres を使ったシステムを作るときに買おう。

著者の一人である青木さんの「あおきにっき つっこみつき」に情報があった。
http://i.loveruby.net/d/20040512.html#p02

『Rubyレシピブック』 2800 円で 5 月 28 日配本だそうです。配本つーことは、本屋にはもうちょい後にならぶ？あ、31 日出版となってるな。
とにかくそのあたりです！

Google で Ruby レシピブックを検索してもほとんど情報が無い。amazon や bk1 のデータベースにもまだ登録されていないようだ。たぶん上の紹介リンクも置換前の文字列のままだろう。データが登録されれば表示されるようになるだろうけど。唯一情報があったのが、ソフトバンクパブリッシングのサイト。

SBPストア Ｒｕｂｙレシピブック ２６８の技
http://store.sbpnet.jp/bm_detail.asp?sku=4797324295

RubyのTipsを満載したレシピ集。Rubyを使いこなすうえでのさまざまなテクニックを幅広く解説。様々な難問を即解決！

現時点では詳細な内容や目次の情報がほとんど無いが、Perl クックブックのようなノウハウ集だと私は想像している。Ruby はあまり慣れていないので、ぜひ手元に置いておきたい。2800円という値段も手頃だし。

- 2004年5月17日追記

あおきにっきつっこみつきに追加情報があった。

『Rubyレシピブック』内容紹介
http://i.loveruby.net/d/20040516.html#p04

暗号化と認証を必要とするサービスをインターネット上に作ることになった。この分野は、設計の誤りがユーザの不利益に直結するシビアなもの。「最低限の学習をするために、暗号や認証技術についての本を読んでおこう」と思い立ったとき、真っ先に候補として頭に浮かんだのがこの本。

暗号や認証技術は要求される前提知識が広範に渡っていて追いかけきれなかったり、高度な数学の知識が必要というイメージを私は持っている。でも、結城さんの本ならば、難しいことでもかみ砕いて書いてあるだろうという期待もある。ウェブでの反応を見ている限り、期待どおりの易しい記述になっているようだ。

結城さんの日記 http://www.hyuki.com/diary/ を読んでいたので発売されていたことは知っていたんだけど、まだ必要ないかなと思って購入を見送っていた。

「認証技術 パスワードから公開鍵まで」も良いかなと思ったけど、まずは結城さんの本を読んで、不足があったら買ってみることにした。

C# の仕様を解説。A5版で200ページ強しかないため小さくて持ち運びやすい。机上に置くリファレンス本としては良くできている。

Java や Object Pascal などのオブジェクト指向言語を使いこなしている人には、大きくてページ数が多い解説本よりもこういったリファレンスの方が使いやすい。事実、「Java は得意だけど C# はこれから使い始める」と言っていた先輩は、この本を4時間くらい読んだけでバリバリと C# でコードを書いていた。

正規表現についてもっと深く学びたかったので発注。

7章は Perl、8章は Java、9章は .NET に丸ごと一章を割いて解説してくれてる。プラットフォーム間の差異をあらかじめ知っておけばコードを書くのも楽になるのでありがたい。

オライリーの Perl クックブック初版第1刷 の 106ページに間違いがある。ちなみに和訳版の話。

4章 配列 レシピ4.7 「一方の配列にはあって他方の配列にはない要素を見つける」の解説で、
以下のようなコードが出てくるが、unless exists でないと正しく動かない。

- 間違ったコード

foreach $item (@A) {
    push (@aonly, $item) unless $seen{$item};
    $seen{$item} = 1;    # 一回出現した要素をマーキングしておく
}

- 正しいコード

foreach $item (@A) {
    push (@aonly, $item) unless exists $seen{$item};
    $seen{$item} = 1;     # 一回出現した要素をマーキングしておく
}

- サンプルコード

#!/usr/bin/perl -w
use strict;

my @A = qw(a b c d e);
my @B = qw(b c e);

my %seen;
my @aonly;

@seen{@B} = ();

foreach my $item (@A) {
        push (@aonly, $item) unless exists $seen{$item};
        $seen{$item} = 1;        # 一回出現した要素をマーキングしておく
}

print join("\n", @aonly);

サンプルコードを array_diff.pl として保存して実行した結果。

$ perl -wl array_diff.pl
a
d

SQL 利用経験が一年以上の初級者から中級者向けの本とのこと。

http://www.kaimei.org/note/book_out/eff_perl.html
Effective Perl は一時期買おうかと思ってたんだけど、Perl クックブックがあるから見送った。

http://www.ascii.co.jp/bookmart/pdf/47561/4756130577.pdf には pdf もある。