miau's blog?

«Prev | 1 | 2 | 3 | 4 | 5 | 6 | Next»

2004年 7月 27日 (火曜日)

ゆとりの法則 − 誰も書かなかったプロジェクト管理の誤解

- 読了@技術書 on miau's blog?
出版社
Amazon.co.jp

「熊とワルツを」の訳者あとがきで引用されてて、気になったので読んでみました。

今まで組織は効率化を推し進めてきたけど、変化のためにはゆとりが必要だ、というお話。

えー・・・感想ですが。
ところどころ心に響くような言葉はあるんだけど、どうも全体として(今まで読んだデマルコ&リスターの2冊に比べると)読後の印象は薄いような。

たぶん
・他の2冊と被ってる部分が多い
・うちの会社はもともとそれほど効率化されてない(たぶん悪い意味で)
あたりが原因かと。

09:55:19 - miau - No comments - No Trackbacks - Permalink

2004年 7月 25日 (日曜日)

プログラミングPerl 第3版

- 読了@技術書 on miau's blog?
出版社(VOLUME 1VOLUME 2
Amazon.co.jp(VOLUME 1VOLUME 2)(第2版

言わずと知れたラクダ本。読むのに丸々一ヶ月費やしてしまいました。
比較的気楽な文体で書かれてるのでなんとか読みきれたものの、この分量をまじめぶった文体で書かれるとたぶん途中で挫折してたかと。

Perl の入門書を初めて読んだのがだいたい 6 年前。
それ以降研究やら仕事やらをかなり強力にサポートしてくれてた Perl ですが、そろそろ文法を一通り押さえておこうということで読んでみました。

読んでみると・・・「Perl ってよく考えられて作られてるなー」としみじみしてしまいます。
元々 Perl マンセーな感じでしたが、さらに惚れ込んだ感じです。
"We will encourage you to develop the three virtues of a programmer: laziness, impatience, and hubris." とかいう哲学っぽい側面だけでも、得るところは大きいかと。
(このへんの解説は このページ とかに詳しいです)

とまぁ文法を把握してなかなか満足してるところですが、スマートさにこだわらなくてもいいので多くの人が気楽に使ってくれるといいなー、なんて思います。"There's More Than One Way To Do It." ということで。


ただこの本、Perl 初心者には決してオススメできません。
確かに導入部で Perl の使い方をさらっとなぞるのですが、それ以降の章立てが各機能ごとに結構深いので。
全体を理解する前にきっと挫折してしまいます。

あと、プログラミングその他の知識もあったほうが読みやすいと思われます。
オブジェクト指向とか、Unix のシステムコールとか。
19:55:52 - miau - No comments - No Trackbacks - Permalink

2004年 7月 23日 (金曜日)

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

- 読了@技術書 on miau's blog?
出版社
Amazon.co.jp
サポートページ

目標管理面談にかこつけて上司のひとに「このプロジェクトダメでしょ」的文句を言おうと思って昨日購入。
面白かったのであっさり読破。購入して2日で読むなんて珍しい。

「ピープルウェア」で有名なトム・デマルコ&ティモシー・リスターによるリスク管理に関する本。
「リスクを愉しむ」と副題があるので「挑戦的なプロジェクトをやっていこう〜」という話だと思ってたんですが、実際にはリスクを顕在化+数値化させ、そのリスクを適切に管理する方法を書いています。

・プロジェクトの見積りは『○月までにできる可能性は○○パーセント』のように確率で出すべき
・通常のプロジェクトの納品期日は奇跡的に何も問題に起こらなかった場合の完成予定日。
 その日を「ナノパーセント日」として「これ以上早く仕上がる確率はゼロ」という基準にすべき
というように、うなずける話が盛りだくさん。

PG として働いてて、チームリーダーに「こういう問題が出てるんだけど、対策にどれくらいかかりそう?」と訊かれて返事に困ることがあったんですが。
こういう場合「本当にすんなり行けば1時間で終わりますけど、根の深い問題なら1週間とかかかりますよ」とか答えてました。
「事実とはいえ、こんなんでいいのかなー」とか疑問を持ってたりもしてましたが、それでよかったんだなー、と霧が晴れました。

にしても、あいかわらず楽しく読める本でした。
「ゆとりの法則」も近いうちに読もうと思います。


・・・余談ですが、セキュリティ関連の人にも読んで欲しいかも。
というのもセキュリティってリスク対策(コスト効果がプラスになり得ない分野)なんでなかなか顧客がつきにくい分野で。
すべての企業でこの本が読まれていれば、たぶん顧客増えるんだろうなー、と。
でもまずサービスを提供する側が読まないとだめだろ、と。
00:16:38 - miau - No comments - No Trackbacks - Permalink

2004年 7月 14日 (水曜日)

ソフトウェア開発のダイナミズム

- 読了@技術書 on miau's blog?
出版社
Amazon.co.jp

最近読んだどれかの本で紹介されてた気がするので N+I で 10% 割引購入
→ちょっと読み始めたらなかなか面白かったので2〜3日で読了。

ピープルウェアと同系色の本。
著者は Visual C++ 1.0 以降の開発マネージャで、それも含めたさまざまなプロジェクトの経験から「どのようにして製品をリリースすればよいか?」ということを説いてます。

独特の切り口でプロジェクトというものを分析しているので、感性的に面白いものがあります。
ただ、多少日本語が難解だったり章ごとにムラがあったりするので、どちらか一冊読むのであればピープルウェアのほうをお勧めします。

特に気に入ったのは #4: ボゾビットをフリップするな という章。
下の2つの言葉が出てきました。

・ボゾビットのフリップ
 「あいつはボゾ(ぼんくら)だ!」と言ってしまう(BOZO = TRUE ビットをフリップする)ことで相手のことを聞き入れなくなること、だそうで。
 要するに「バカばっか」現象ですね。たぶん私今これにハマってます。

・バーンアウト
 いわゆる燃え尽き症候群。症状として以下のものがあるそうで。

・努力の甲斐なく製品が失敗するという揺ぎない思い込み
・チーム運営が救いようがないほどいい加減だという確信
・次のリリースのことを考えたときに催す吐き気
・組織的に問題解決にあたろうとすることに対する悲観的で冷笑的な態度
・ボゾビットの無差別大量フリップ(「あいつもボゾだ」)
・コンピュータに対する興味の喪失(!)

最後の項目以外は該当してるんですけど。


それ以外では思ったこととしては・・・やはり情熱は大切だなぁと。
今のプロジェクト、がむしゃらにがんばってる人はいるけど、情熱を注いでる人はいないんじゃなかろうか。


あと、「優れた人材の採用と教育のために」と題した付録があるんですが、以下の一文が。

「人はソフトウェアの仕事を続ける上で、多くのネガティブな体験に直面せざるをえない。
 無能な上司、設計の選択ミス、不向きな担当製品、チームの機能不全、途方も無く遅れたプロジェクトなどだ。」

あるいはこれら全てだ。
06:17:54 - miau - No comments - No Trackbacks - Permalink

2004年 6月 23日 (水曜日)

メディアの興亡

- 読了@技術書 on miau's blog?
Amazon(検索結果)

読んでみました。(ちなみに読んだのは文春文庫版)
「技術書」ではないんですが・・・まぁ「100 冊」に載ってたのでこちらに。

「100 冊」では「コンピュータによる新聞製作」という点に関してだけ言及されてました(レビューも含めて)が、それを軸として新聞業界の経営判断とか派閥抗争とかそういうドロドロした部分も書かれてます。
それはそれで面白いです。

技術者として、というよりサラリーマンの生き方としてアツいです。この愛社心とかどこから来るんだ、とかなんとか色々考えさせられます。
・会社のカラーがある
・指針がしっかりしている
・成功が約束されていないプロジェクトに乗り出す挑戦心がある
というあたりがポイントかなー、とか思ったりも。

ちなみに IBM OS/360 とか出てくるので、この本読んだあとで「人月の神話」読んだほうが「あの IBM 360 の開発を仕切った PM か〜」という具合にもっと引き込まれてよかったかもしれません。
23:03:35 - miau - No comments - No Trackbacks - Permalink

2004年 6月 19日 (土曜日)

人月の神話【新装版】―狼人間を撃つ銀の弾はない

- 読了@技術書 on miau's blog?
出版社
Amazon 初版

「銀の弾丸」で有名な本。(でも本の副題は「銀の弾」。語呂悪いな)
プロジェクト(特に大規模の)が破綻しないためにどうすればよいのか?というお話。初版から 20 年の間に作者が考えたことに関して記述も追加されてるのは、新装版ならでは。
かなりプロジェクトマネージャ向け。プログラマーレベルの人が読んでもすぐに実践できることは少ないような。将来のために読んでおいたほうがいい本ではあるんですが。

以下、雑然と感想を。

・先にピープルウェアを読んでしまったせいか、本書でひとつのポイントになっている「人月の神話」に関してはあまり感じるところがなかった。当たり前じゃん、みたいな。

・例として 30〜40 年前の開発事例が出てくるけど何のことかさっぱりなので、却って退屈になってしまう。(これはまぁ仕方ないけど)

・本のタイトルだけ知っている人はソフトウェア開発のすべての局面において「銀の弾丸はない=魔法のような解決策はない」と悲観的になったりしないかとちょっと心配。筆者自身も「高水準言語を使うことでプログラミングの生産性は5倍になることもある」と書いているし。

・翻訳がなんか変。文章にわかりにくい部分があるのもそうだけど、変なルビがふってあるのがすごく気になる。たとえば「実現」に「インプリメンテーション」とかルビがついてたりするんですが。
「実現(implementation)」とでも書けばいいものを。
01:12:17 - miau - No comments - No Trackbacks - Permalink

2004年 6月 15日 (火曜日)

詳説 正規表現 第2版

- 読了@技術書 on miau's blog?
出版社
Amazon 初版
http://regex.info/(サポートページ)

「使えればいいや」レベルから「そこそこマスター」レベルになっておきたかったので読んでみました。

えー・・・確かにこれ読めば正規表現はマスター(知識レベルで。実践も必須)できるでしょう。
でも普通の人はここまで理解しなくても困らないと思います。
処理の時間が問題になったり、行いたい処理の正規表現が思い浮かばなくて行き詰まったような場合に読み始めれば十分ではないかと。

というかアルゴリズムとかそういうのが好きな人でないと読むの結構大変かもしれません。
一応導入部で「正規表現入門」っぽいのがあるけど、ある程度正規表現に慣れてから読み始めたほうがいいと思います。

以下雑然と感想を。

・誤記が結構ある。本文中の誤記くらいはいいけど、正規表現なんて一文字違うだけで結構悩んでしまうから、出版社とかで正誤表だけでも提供してほしいところ。

・今までは後方参照できない正規表現エンジンは低級なものとみなしてたけど、エンジンの種類が違うんだとわかると妙に納得。

・Perl とか .NET とか、色んな機能があって便利だとは思うけど、個人的に一番身近なエンジンは BREGEXP なので、実はあまり役に立たない場面が多そう。

・とはいえ、たまに Perl でファイルを一括処理するのでそれは楽になりそう。というか、Perl もいいかげんにしか身に付けていないのでそっちの勉強にかなりなった。
10:44:26 - miau - No comments - No Trackbacks - Permalink

2004年 6月 07日 (月曜日)

ピープルウエア 第2版 − ヤル気こそプロジェクト成功の鍵

- 読了@技術書 on miau's blog?
出版社
Amazon初版

最近ヤル気ないので読んでみました。

「管理者向けだけど管理者以外も読んでおくといいよ」的な評判でしたが、その通りでした。内容が面白いし、忙しいのに3日間くらいで読んでしまいましたよ。

いくつか気になったキーワードを。

・触媒
 「達人プログラマー」にも出てきた言葉だけど、ここでもこの言葉が使われてた。この本では技術力はなくてもその人がいるだけで意思の疎通が良くなる〜みたいな人のことを呼んでるのでちょっと違うけど。技術力がないと思っている人もじっくり観察してみようと思いました。

・プログラミングコンテスト
 本当に魅力的。職場環境を把握するため、という意味合いも含んでいたけれど、普通に結束を高める&やる気出させるだけでもいいような。というか普通に楽しそう。・・・本気で提案してみようか。

・ホーソン効果
 人は何か新しいことをやろうとしたとき、それをよりよくやろうとする(→生産性も向上する)という効果のことらしい。今度新しい技法を使いたくなったらこれをネタにして説得できそう。ただ、あまり一度に色々新しいことやろうとするな、という注意もあったのでそのへん気をつけよう。

・自己防衛的な管理/裃を脱ぐ
 部下に任せなさい、というお話。結構「この仕事はあいつには無理だな」みたいな上司が多いので。んなこと言ってないでちゃんと教育すべきだと思うんですが。

その他「こうなると、部下は会社を辞めてしまう」みたいな話でうんうん頷いたり。世の中には良いオフィスや魅力的な上司がある(いる)ものだなぁ、と羨ましくなったり。色々面白かったです。

ただ、オフィスの環境っていうのにはあまり興味ないかも。そんな広い個室とかで作業しなくても、集中できるもんでは。まぁ作業場所が分散してたり、極端に狭かったり、照明がやたら暗いのはやっぱダメだと思いますが。
01:15:01 - miau - No comments - No Trackbacks - Permalink

2004年 6月 03日 (木曜日)

セキュアプログラミング―失敗から学ぶ設計・実装・運用・管理

- 読了@技術書 on miau's blog?
出版社
Amazon
www.securecoding.org(サポートページ)

一応教養ということで読んでみた。

概論→アーキテクチャ→設計→実装→運用→テスト という章立てになっているけど、どうも前半が退屈。
設計まわりの経験不足+Unix まわりの知識不足っていうのもありそうだけど、本書に寄せられた言葉〜まえがき 部分でかなり期待したのに、1章〜2章でいきなり理屈っぽく始まる構成がとっつきづらいのも原因かと。

でも後半に行くにつれ(個人的に)だんだん面白くなってきて、全体としては満足いく内容でした。感動ってほどではないけれど「ほー」と感心するような所もいくつかあったりして。

今のプロジェクトは社内システムっぽいからそれほどセキュリティは重要視されてないけど、Web システムとか作ることになったら一度読み直そう。紹介されていたテストツールなんかも機会があれば使ってみたいところ。
その他セキュリティ関連の書籍やらサイトやらの情報が結構充実してるのでこれも必見ぽい。
08:26:14 - miau - No comments - No Trackbacks - Permalink

2004年 5月 27日 (木曜日)

コンピュータの名著・古典100冊

- 読了@技術書 on miau's blog?
出版社(サポートページ)
Amazon

結構有名な本ですが、石田晴久さん(たぶん K&R の訳者として有名)が書いてることもあり「自著の売上げ伸ばすための策略じゃないの?」と思って避けてました。
が、ちょっとしたきっかけで読んでみると・・・なるほど確かに良い本でした。疑ってすみません。


「歴史」、「人物・企業」、「ドキュメンタリー」といったセクションの本はほとんど知りませんでしたが、読むと面白そうな(やる気出そうな)本が結構あります。仕事がつまらなくてモティベーション下がっている時なんかに読むとよさそうです。

あと、「アーキテクチャ/OS」や「ソフトウェア開発」セクションの本なんかも、本屋では見かけない(見かけてもたぶん印象に残らないような装丁だったりする)けれど古典として知られている本が紹介されてまして。今の日本を支えている優秀なエンジニアが座右の書としているような本もあるようですし、やはり目を通しておくべきかなと思いました。

ちなみに、私がまともに読んだことあるのはたったの 5 冊。読むつもりで購入してる本もその他 3 冊ありますが、すべて「コンパイラ/言語」か「プログラミング」のセクション。少なすぎ+偏りすぎですね。

アスキーの西和彦さんのコメントで「この 100 冊を各分野別に、月10冊くらい読むといい」とか書いてあって。私は週 1 冊くらいのペースでしか読めていないので、自分の無学さを痛感しました。もっとがんばらねば。
あと、読者のコメントも数多く寄せられているので、技術者の層の厚さを感じることができます。そういう点でも刺激が得られる、良い本だと思います。
07:45:42 - miau - No comments - No Trackbacks - Permalink

2004年 5月 24日 (月曜日)

達人プログラマー―システム開発の職人から名匠への道

- 読了@技術書 on miau's blog?
出版社
Amazon
www.pragmaticprogrammer.com(サポートページ)

プログラミング作法の第9章をまるまる一冊やったような本。
DRY - Don't Repeat Yourself(繰り返しを避けること)
というのが全面に渡って主張されています。

このあたりの思想というか哲学は、エンジニアには必須だと思うのですが・・・なかなかできる人が少ないのが現状です。元々そういうセンスを持っている人はいいのですが、持っていない人は是非読むべきです。
すでにそのような哲学を持ち、行動に移しているエンジニアにとっても価値のある本ではないかと。自分の作業だけでなくもう少し広い視点で DRY というのを適用できることがわかると思います。

以下、気になった章をいくつか。

3 石のスープと蛙の煮物
 「変化の触媒たれ」とあります。個人では達成できないことも、うまく煽動することでチームとして達成できる、というお話。こういうエンジニアでありたいもので。

21 契約による設計
 プログラミング作法や珠玉のプログラミングで「assert() を使え」と書かれていましたが、さらに一歩突っ込んだ話(事前条件、事後条件、クラス不変表明)と、その実装のためのツールが紹介されています。

41 達人チーム
 達人の技法をいかにしてチームに適用するのか、という話。このようなチームであれば仕事楽しいと思います。

# 気が向いたら追記。
00:38:02 - miau - 2 comments - No Trackbacks - Permalink

2004年 5月 15日 (土曜日)

萌え萌えうにっくす!UNIXネットワーク管理ガイド

- 読了@技術書 on miau's blog?
出版社
Amazon

最近忙しいのでこれくらいのサイズ&ページ数の本を読むようにしてるんですけど、これは字が小さいので下手な本よりも分量が多いです。
しかも内容が結構まともで、ネットワークの基礎(TCP/IP とか)から SSH、Apache、snort、tcpdump、ethereal、nmap あたりの使い方まで、ネットワークに関する幅広い分野を押さえている印象。私は UNIX に弱いので、ずいぶんと勉強になってしまいました。

特長のひとつであるオタ向きな注釈もなかなか面白かったり。さすがに全てのネタにはついていけませんけど、読んでておもわずニヤリとしてしまうこともしばしば。

で、まぁタイトルにもある通り「萌え」っぽい本なんですけど・・・その部分はちょっと不満が残りました(謎)
各章(正確には各萌)の冒頭でマスコットキャラの会話+末尾で挿絵、みたいな構成で・・・絵がそれほど好みじゃない(ほっぺに赤丸系)のもあるとは思いますが、とりあえず私は萌えませんでした。会話もちょっと単調な印象受けますしね。
もえたんくらい突き抜けた本にするか、リックテレコムの試験対策本みたいにさりげなくかわいい挿絵(イラスト:岩崎千恵子さん)レベルにとどめるか、どちらかにしてくれたほうが個人的には嬉しいのですが。

・・・ってなんのレビューだか(笑)
20:08:36 - miau - No comments - No Trackbacks - Permalink

2004年 5月 06日 (木曜日)

ソフトウェアテスト293の鉄則

- 読了@技術書 on miau's blog?
出版社
Amazon

「基本から学ぶソフトウェアテスト」の続編みたいなもの。
あちらは体系的に書いてあった気がするけれど、こちらはポイントをまとめたものだから、拾い読みとかにもいい感じ。

Amazon やら何やらの感想を見るとわかるとおり、結構評価がまちまちです。(前著もそうでしたが)

その原因にはやはり日本と米国の開発文化の違い(米国ではプログラマとテスターが完全に分業して作業を行うが、日本では兼業が普通)がありそうです。他のテスト関連の書籍と同様この書籍もテスター向けの本になっており、日本のプログラマにはちょっと馴染みにくい内容かもしれません。
でも「俺はプログラマであってテスターじゃないから」と投げ出してしまうのではなく、「日本ではプログラマーがテスターも兼ねるのだから、これくらい勉強しておかないと」と考えてほしいところです。
まぁ文化が違うのでどうやっても消化不良の部分も残るのですが。

さて、気になったセクションを2つほど。

・第5章 テストの自動化
 先週テストで召集されたときは「自動化すればいいのに」とぶつくさ言っていたんですが、それは「めんどいから自動化しちゃえ」という安直な発想で。これをあらかじめ読んでおけばもっと的確な方法を提案できただろうなぁと。

・第10章 ソフトウェアテストにおけるキャリア
 テスト担当者としてのキャリアについて書かれているわけですが、PG や SE にも当てはまる部分は結構あるような。
 転職指南書としてなかなか良いです(笑)

その他「テストプロジェクト管理」に関しても普通のプロジェクト管理に当てはめられる部分もあったりで。結構役に立つ本だと思います。


余談:訳注で「デグレードは和製英語」とあったけど degrade って普通に英単語(品質が下がる、とかの意)のような。「本場ではこういう場面では使いません」という意味かもしれないけど、それを和製英語と表現するのはどうなんだろう。
05:51:57 - miau - No comments - No Trackbacks - Permalink

2004年 4月 26日 (月曜日)

72のキーワードから学ぶ実践データベース

- 読了@技術書 on miau's blog?
出版社
Amazon

現在仕事で業務系のシステムを作っているわけだけど、たまに「トリガって何?」とか「ストアドプロシージャとユーザ定義関数って何が違うの?」とか聞かれることが。
私はこのあたりは Oracle やら SQLServer やら DB2 の資格を取得する過程で身に付けたけれど、他の人にはどうやって学んでもらえばいいものか。さすがに上記の資格を全部取れ、というのは無茶な気がする。

そう思っていたところ発売されたのがこの本。DB に関する書籍というと、設計者や管理者向けのものが多い(気がする)けれど、その中でめずらしく開発者向けの本。

で、感想としては・・・これを読んでいれば DB を使った開発で困ることはかなり少なくなるんじゃないかと。
「Oracle では〜、SQLServer では〜、DB2 では〜」というように RDBMS 毎の説明もあるので、色々な DBMS を触れるような人にもオススメできます。

欠点としては、上記の RDBMS 毎の表記にムラがあるあたり。「そこって DB2 では違うんだけど・・・」とか思うこともしばしば。


にしてもこの本でも DECLARE CURSOR の WITH HOLD オプションとかは載ってなかった。今回のプロジェクトで結構経験のある開発者×2でも知らなかった部分なんだけど・・・こういうのはどこで知ればいいんだろう。DB Magazine とか読んでれば自然と身につくのかな・・・。
23:16:48 - miau - No comments - No Trackbacks - Permalink

2004年 4月 20日 (火曜日)

テクニカルエンジニア システム管理 コンパクトブック

- 読了@技術書 on miau's blog?
出版社
Amazon

とりあえず読了。情報処理試験の帰りの電車で。(意味なし)

午前が一通り(全分野通して)まとまってるので午前対策にさらっとやると良い感じです。午後対策をこれだけでやろうというのはちょっと無謀です。

システム管理に関わる部分は、他の「システム管理ONLY本」みたいのにも載っているだろうから読み飛ばしてもいいかもしれません。
08:06:06 - miau - No comments - No Trackbacks - Permalink
«Prev | 1 | 2 | 3 | 4 | 5 | 6 | Next»