読書感想文」カテゴリーアーカイブ

情報は1冊のノートに

少し前に発売されて気になっていた本を読んだ

私も普段

  1. 手帳
  2. ノート(仕事用)
  3. PC

と情報が分散している。用途ごと、カテゴリごとに分けようとも思っていたけど本書にも書かれているとおり

「日記」や「アイデア」というふうに、カテゴリ分けで記入スペースを指定しておけば、見返すときに、まとまっていて便利です。
しかし、カテゴリ分けというのは頭の中でうまくいっていても、実際やりだせばたいてい破綻するものです。(P54)

うん、そのとおり。これを見て思ったのは私は間違いなく破綻するであろうと。私はものを考えるのは嫌いではないんだけど、考えって余り完全なカテゴリに分けることが出来ないんですよね。
また、検索性を向上させるためにPCへ内容を移すことは考えたけど非常に手間がかかる。特に絵を書いた場合なんてめんどくさくてしょうがない。そういう内容の対策として本著で書かれている”索引ファイル”を作るアイデアはとてもいいと思う。今年はすでに手帳を購入してしまったので100円ノートというわけにはいかないけど、別にこの方法は100円ノートに限らず出来る方法なので問題ない。
ついでに言うと、索引ファイルをLiveMeshでシンクロさせておけば家でも会社でもアドエス(Mobile)でも参照できる。これはこれでアドエスの使い道も増えていいじゃないか!って思った。
ナカナカプラスになりそう。

ただ、その一方で少しこの内容であればページ数はもっと薄く出来たと思う。別に今読んでいる本が内容ぎっしり文字びっしりな本なのでそれとどうしても比較されてしまうのかもしれないけどちょっとスカスカだなぁって感じてしまった。いいことが書いてあると思っただけにちょっと残念に思った

トレイルランニングの醍醐味

鏑木さんの著書「トレイルランニング」を読んだ

トレイルランニング (OUTDOOR PERFECT MANUAL)
鏑木 毅
エイ出版社
売り上げランキング: 2165
おすすめ度の平均: 5.0

5 山を走る気にさせる一冊です

1月に鏑木さんのウィンターキャンプに参加するので、必要最低限の内容を理解しようと思ったのだが、最低限を知るというよりも、うん。走りたくなった

トレイルランニングの魅力は

トレイルランニングは文字通りトレイル(山道)を走る。それは分かっている。
分かってはいるつもりだったのだが、読めば読むほどその魅力に気付かされる思いだ。

自然の中を走ることの素晴らしさ。これは街中を走るランニングとは一味もふた味も違った魅力がありそうだ。。。と、マラソン経験のない私が言っても説得力は無いのだが、少なくともロードよりは気持ちの面ではトレイルのほうがあっていそう。
もう、なんだかワクワクしてくる感じだ。

トレーニングあれこれ

また、トレイルランニング向けのメニューも載っている。やはり山道を走るだけあって、階段や斜面を利用したトレーニング等はなかなか面白いものだった。これはちょっと自分では思いつかなかったなぁ。でも、確かに必要なんだな。
いくつかは生活の中でも取り入れることができそうなので、完全にとまではいかないが試してアレンジしてみたい。

その一方で、この本に書かれているトレーニングメニューのサンプルは私には無理があるとも感じた。
平日はどうしても帰りが遅くなってしまうし、休日もまとまった時間がとれるとは限らない。出来るだけこれらに時間を割きたいとは思うが、なかなか難しいだろう。

まずは休日にロードで走り込みを続けて基礎体力をしっかりとつけることを心がけることにする。
今日も2時間ちょっと。26kmほど走ったが、3~4時間くらい楽に走り続けることができるだけの体を作っていくことが先決。
今日は膝を少し痛めてしまった。まだまだ体ができてないのかもしれない。地道だけど少しずつ頑張っていくことにしよう

3月のライオン一気読み

書店で前々から表紙を見てはいたんだけど、まったく手に取ることはなかった。
たまたま、レンタル屋で見かけたのでふと気が向いて1巻から5巻まで全部一気に読んでみた

どっかでみた絵だなと思ったら、以前「ハチミツとクローバー」書いてた人やね。”ノイタチミナ”で見たことがある気がする。
私は少女マンガはどうも絵が苦手で、本書もご多分にもれずそれが理由で手に取ってなかった。。。って、連載ヤングアニマルなんだ。今知ったよ。

まぁ、そんな読まず嫌いで手にとってなかったわけなんだが、いつも立ち寄る書店でよくコーナー作っていたり、4巻の表紙が将棋の絵面だったりで気になり始めていた。

これはちょうど先日読んだ、

どうして羽生さんだけが、そんなに強いんですか?―現代将棋と進化の物語
梅田望夫
中央公論新社
売り上げランキング: 12591

によって将棋に関連した話に敏感になっていたと言うのもある。

ただ、どうして羽生さんだけが~を読んでいたおかげで、世界観はなんとなく把握しながら面白可笑しく読むことができた。
この先、主人公の内面的な成長がどう描かれるのか楽しみですね。

うーん、将棋。
詰将棋の本を持っているので、時々それを開いてはいるけど随分と本将棋はやってないなぁ。
週末あたり、ネット対戦でもしてみようかしら?

知的プロフェッショナル

最近顔を出している株式会社ジョブウェブの朝食会で、以前ジョブウェブの佐藤社長からお勧めされた”田坂広志”先生の本を最近読んでいます。その中の一つ「知的プロフェッショナルへの戦略」はとても面白かった

この本に限った話ではないのだが、田坂先生の本は私が今まで読んできたビジネス書とは視点が異なっている。今までの本はどちらかというと「どうビジネスにおいて動くか」とか方法論が多かったように思える。ただ、田坂先生の本はそれらとは異なり「どう生きるか」というような精神論や思想に近いもののように感じる。

仕事の報酬として給料以外に何を求めるのか。そもそも何のために働くのか。どう考えて行動するのか。自分というブランドをどう確立していくのか。

まだまだ未完成の”自分”という作品をこれから練り直さなければいけない。そう感じた本でした。

世にも奇妙なマラソンたち

珍しく本屋でスポーツ関連のコーナーに足を踏み入れた時に面白そうな本を見つけて思わず購入。

猫まっしぐラン!! おもしろマラソンガイドブック
猫ひろし
エフエム東京
売り上げランキング: 53969

マラソン色々

これほどまでに色々な種類があるものかと思ってしまうほど紹介されている大会はバラエティに富んでいる。
給水ならぬ給スイカが出てくる大会
富里スイカロードレース
川の中をひたすらに走る大会
サーキットを走る大会
カレーライスの材料を集めながら走る大会
いやはや。仮装をして走るなんてのが序の口ではないだろうかと思ってしまうほどの種類だ。

先日トレイルランニングの講習でお会いした方も、以前仮装レースに出たことがあってその時の様子を楽しそうに話をしていた。
マラソンというとストイックなイメージが先行してしまい、キツイとか辛いとかそういう面ばかりが思い浮かんでしまいがちだ。
純粋に走るって事を楽しむ。そういう心もちでこれらの大会は楽しめそうなのでいいですね。
ちょっとどれかに挑戦してみようか?スイカロードレースなんてちょうど千葉だからいいかもしれませんね。

それにしても猫ひろし

マラソンしているんだ。しかも、フルマラソンを3時間18分で走ってるということはなかなか早い。
それだけでも十分すぎるほど驚きだというのにさらなる追い打ちをかける新事実が!!!

生年月日:1977/08/08

猫ひろしって同い年だったのか。。。
絶対にもっと年上だと思っていた。なんだか色々とショックだった。

あぁ、テストエンジニア

いちばんやさしいソフトウェアテストを読んだ

いちばんやさしいソフトウェアテストの本 (技評SE新書 19) (技評SE新書)
石原 一宏 布施 昌弘
技術評論社
売り上げランキング: 14416

ソフトウェアを開発するうえでテストというものは必要不可欠な話である。ただ、ソフトウェアのテストエンジニアや品質管理者というものを目指す!という話をあまり聞いた事がない。これは私が聞いた事がないだけの話かもしれない。
本書はその現状を打破するために作られた本ではないかと思う。
テスト工程は、あくまでテストする対象となる機能。ここで言うとプログラムがない限りは実際のテストは出来ない。もちろん、仕様上の不備・不具合を指摘したりそれに合わせてテスト計画を練る事もとても重要な作業だ。ただ、肝心の開発が予定通り進む事は稀で往々にして遅れが発生する。その時に削られるのはまっさきにテスト工数がやり玉にあげられる。
バグを見つけたら見つけたで開発側からは裏切り者扱いされたりもするかもしれない。もちろん、バグを見つけたという事は間違いなく評価されるべき事で、そのままプログラムが世に出た時の被害を考えれば素晴らしい事。ただ、納期が迫ってただでさえ遅れが発生している開発担当者の感情的な心根としてそういう発想につながってしまう事もあるだろう。
本書でも第6章で涙ぐましい対策が語られている

常に挨拶と礼節を心がけ、開発者とチームメンバーとよりよい関係を目指します!
(中略)
そこで、テストエンジニアは常に開発者と良好な信頼関係を保ち気軽に話ができるようになっておく必要があります。(P126)

開発側に属する私としては色々と頭を下げたくなる内容だ。
これからのソフトウェア開発を考えると品質というものはより求められ、それに比例するかのようにテストエンジニアの価値というものはどんどん上がっていくだろう。
本書がそのきっかけとなってくれる事を願う。

ただ、本書は対象とする読者をどこに置いているのだろうか?実際に開発に携わっている人間にとっては本書は優しすぎる。そうなると、対象読者はだれになるのだろうか?
第1章は優しいものの、その後はV字モデルの説明、W字モデル。名前だけならAllPairsや直交表も出てくる。
うーん、対象は学生なのかな?

既知への向き合いかた

小飼弾氏著「決弾」を読んだ

決弾 最適解を見つける思考の技術
小飼 弾 山路 達也
アスペクト
売り上げランキング: 103246
おすすめ度の平均: 3.5

4 電子書籍で読んでみました
5 もう決断に悩まない
3 頭の体操に
4 機械以下の奴隷にならないために
4 決断は買えない

前作となる弾言とは異なり、本書はQA形式仕立ての構成になっている。
実は今回もiPhoneで購入したのだが…iPhoneはリアル書店と違って試し読みができない。小飼氏がどういう思いでこの構成にしたのかは不明だが、個人的にはあまり好きじゃないなぁーと思った
小飼氏に共感できるか以前に質問に共感できないことがしばしば有るからである
勿論、それらに対してなんて答えるのか?という意味においては、興味深いものも有るのですけどね

あ、それ知ってるな

最近、本をそれなりの量読むようになってきた。私は速読とかフォトリーディングとか出来ない(うまく見についてない)ので、読むスピードは遅いですが。
ただ、「あ、それどっかに書いてあったな」と思うことは良くある。

たいていはどの本の内容も既知の知識であり、人によっては知っている内容です。
けれど、「この知識をこう表現できるんだ」ということは勝間さんの本を読むまでしらなかった。1つの事実に対しても、表現は複数ある。目にとっての読書の楽しみとは、新事実との遭遇ではなく、新表現との遭遇なんです

なるほど、確かに書いて有ることの、私は9割とはいかないかもしれないが、多くは読み手側が既に知っている内容なのかもしれない。知りたいと思う内容に関して、現代では本当の意味での”新事実”なんてそうそう簡単には出てこないだろう。
ただ、知っているのと自分の言葉に出来る、使うことが出来るというのは違う。
こう言う使い方や表現方法も有るんだ!って言う読み方は、自分の言葉にするための手助けになるかもしれないと思った。

私は情けない話ではあるが、セミナー。特に暗転している場のセミナーでは寝てしまうことがある。話の中に「あ、それ知ってるな」があった瞬間に一気に興が削がれてしまう感じ。そして、肝心な部分を見逃すんだから世話ない話だ。
気持ちの持ちようなんだろうけど…ちょっとこの考え方を取り入れてみよう

え?根がいい加減だからそんなことになるんだって?
たぶん、それも当たっているんだとは思う。

何を読み取るのか

これまで、本を読むときには「何かを得なきゃ!」という気持ちが強い。たぶんこれは、”元をとる”っていう意味ではそんなに間違ってはいないスタンスなんだろうけど、得るものが、必ずしも本のタイトルにある分野である必要はないということに気がついた気がする。
もしかすると、これはそもそもの小飼氏の思惑とは外れるかもしれないが、本にある言い回しであったり表現だったり。そこに行きつくまでの背景だったりを読み取ることも一つの成果ではないだろうか。
これらを積み重ねて自分のものとして整理することに今後気をつけていくことにしよう。

謎解き謎解き

ようやく「数学ガール フェルマーの最終定理」を読み終えた

数学ガール/フェルマーの最終定理
結城 浩
ソフトバンククリエイティブ
売り上げランキング: 5141
おすすめ度の平均: 4.5

5 数学は難しいけど、その面白さ、美しさが分かる小説
2 著者のインタビュー
5 数学を魅せる本第2弾
3 数式は良い
5 背理法の切れ味が心地よい

目次

  • あなたへ
  • プロローグ
  • 第1章 無限の宇宙を手に乗せて
  • 第2章 ピタゴラスの定理
  • 第3章 互いに素
  • 第4章 背理法
  • 第5章 砕ける素数
  • 第6章 アーベル群の涙
  • 第7章 ヘアスタイルを法として
  • 第8章 無限降下法
  • 第9章 最も美しい数式
  • 第10章 フェルマーの最終定理
  • エピローグ

そこそこの厚みがある上に数式を毎回追いかけて考えたりするととても読むのに時間がかかる。数式の細かいところはいくつかは読み飛ばしたし、自分の手で計算をしてないから頭には入ってないけどやはり時間がかかる。
ただ、時間をかけるだけのことはあったのではないかとも思う。

ピタゴラ

懐かしいっていうか、習った定義とかってほとんど覚えてないんだな~ということを再実感。もう、色々と思いだしながら読んでいました

  • ピタゴラスの定理
  • 合同
  • 複素数

言葉の定義を覚えていないのはやはり使っていないこともあるけど、本書で出てくるたとえで言うところの”しっくりときてなかった”のだろう。その場その場で覚えた気になっていただけなのだ。

証明せよ

様々な定義や予測を立てながら証明をしていく様を読みながら、私は自分の仕事をなぜか思い出していた。
あちらこちらから来る障害の内容を確かめ、一つ一つ事実を確認しながら最終的に問題点や解決策を探していく。その過程では過去の障害事例や解決案を織り交ぜながら思考を巡らせていく。
それは、すでに過去に証明された内容を定義として利用し、命題を解いていく証明の進め方と結構ダブルのではないだろうか。
著者はJavaの本も多数執筆しているプログラマー。やはり、この仕事は数学的な考え方が。。。。!
ちょっとこじつけかな。

でも、与えられた命題を解く…という意味においては同じ作業なのではないかと思う。
そして、それを楽しいと思えるのは、理系な人間なんだろうなぁと思った。

ソフトウェアアーキテクトが知るべき97のこと

O’REILLYから出ている「ソフトウェアアーキテクトが知るべき97のこと」を読んだ

ソフトウェアアーキテクトが知るべき97のこと
オライリージャパン
売り上げランキング: 747

珍しくAmazonが新刊を速攻で届けてくれた。つまり、予約があまりされなかったということだろう。技術書なんてそんなものだ…。

本書は、読んで字のごとくソフトウェアアーキテクトが知っておかなければいけないことや、何に注力していかないといけないのか?ということに関して数々の人がその考えを述べている。
本全体としてまとまっているというわけではなく、どちらかというと「あなたはどう思いますか?」って感じの質問に対しての解答集のようなものだ。

ちなみに、日本語訳は無いが原文はこちらにある

97 Things Every Software Architect Should Know – The Book
http://97-things.near-time.net/wiki/97-things-every-software-architect-should-know-the-book

日本語版である本書は、上記97の内容以外に日本人アーキテクトによる追加の内容11本を含んでいる

何を知るべきなのか

実際には、それぞれの立場や会社の性質。従事しているプロジェクトの内容やチーム編成によっても立ち位置は変わってくると思うので、「おー!そうだよね!!」って思うこともあれば「ふーん」と思うこともあった。
ただ、まとまっていないといっても、考えることというのは比較的似通っていて、言っていることはある程度のカテゴリに分けられている

  1. 技術を正しく把握・使うことの重要性
  2. コミュニケーションの重要性
  3. ビジネスを考えることの重要性

とってもざっくばらんに分けるとこんな感じじゃないかな?
たぶん、この人たちにとっては”ソフトウェアや技術に対する知識を持っているのは当たり前”で、プラスして何が重要かということが言いたいんだろう。技術ばっかりの頭でっかちになってはだめですよって。本書でたびたび出てくるところの「象牙の塔」ですね

  • 象牙の塔 http://ja.wikipedia.org/wiki/%E8%B1%A1%E7%89%99(Wikipedia:象牙)
    • 現実からかけ離れた夢想の世界。学者が閉じこもる研究室の比喩。ミヒャエル・エンデの『はてしない物語』にも登場する

面白いと思い、やはり悩ましいのはコミュニケーションだろう。

そんなときに必要なのは、昔から定評のあるテクノロジーです。実際、そのテクノロジーは、人類の歴史で最も重要な技術上のイノベーションです。何だと思いますか。それは話し合いです(P.6 Mark Ramm)

ソフトウェアアーキテクトをビジネスとデベロッパーの間に置くとなると、やはりこのスキルは必須になるだろう。これはプロジェクトをチームとして、会社として成功に導くためには間違いなく必要なことだ。
その割に、これにかかるコストだとか労力というものは軽視されがちで、結果としてプロジェクトはとん挫したりする。
また、もうひとつ。重要なコミュニケーションがある

ソフトウェア・アーキテクトは、どのプラットフォームの仕事をしているかにかかわらず、相互のコミュニケーションを円滑にするための手段を持たなければなりません。その手段の1つが、アーキテクチャー/デザインパターンによるコミュニケーションです。(P.84 Mark Richards)

そう。同じプラットフォーム、同じ言語で開発を行ったとしても別のチームのプログラマがすぐに他のチームで活躍できるとは限らない。仕様書が情報を知るための重要なリソースになることもあるが、プログラマであればまずソースを見ることが多いのではないか?その時に内容を理解したり、プログラムの意図や流れというものを理解するのにこれらデザインパターンというのは間違いなく威力を発揮する。
逆を言えば、本来であればデザインパターンを適用すると効果的な場面において適用されていないとすると、不必要な誤解を招く可能性まであるということだ。

私自身は、デザインパターンに対して習熟しているとはまだまだ言えない。
一人の技術者としてのコミュニケーションがとれるよう、勉強していかなければいけないと痛感することになった。

考具を読んだ

加藤 昌治さん著の考具を読んだ

考具―考えるための道具、持っていますか?
加藤 昌治
阪急コミュニケーションズ
売り上げランキング: 1683

この本自体が2003年に発売され、その後の数々の本や雑誌によって発想法は紹介されているので、特別”新しい”というものはなかった。もちろん、これを2003年に読んでいたら目からうろこ状態で歓喜していたかもしれない。
ただ、”知っている”ということと”できている”ということは別の話だ。「あー、これね。うん、知ってる知ってる」って言ったところでやったことがなかったり実際にそこから気付きが生まれる前に辞めてしまったり。
アイデア・発想法に関しては本書にも描かれているとおり「量が質を生む」という性質はあると思う。それがわかっているくせに続かない私はやはりわかっていないのだろう。

というわけで、さっそく会社で試してみることにした。本書とは直接関係はないのだが、KJ法によって「理想の職場」ってテーマでメンバーを集めて話し合ってみた。

KJ法(Wikipedia)
http://ja.wikipedia.org/wiki/KJ%E6%B3%95

やり方を知ってはいたものの、実際にやってみるとまとめるのが難しい!あまり、仕事直結の話以外に関して意見を出し合う機会も少なかったので、なかなか面白い発見がいくつかあった。
なかなか本で得た内容を実践することは難しいが、やはり実践することによって気付くことは多い。これからも忘れないようにしていかなければいけない。