「エンジニアのための時間管理術」 とその関連商品

タイトルには「エンジニア」とあるが、実際にはいわゆる「システム管理者（しかも専属）」の業務を対象に書かれている。と聞くとタイトルに惹かれたエンジニアの方は「役に立たないのでは？」と思われるかもしれないが、ある程度経験を積み「腕っこき」と頼りにされ始め、「掛け持ち業務」が常となりつつあるような「普通のエンジニア」を脱皮し始めた人に取っては役に立つ内容が結構あると思う。

一通り読んで振り返ってみれば書かれている内容は有能なシステム管理者に従事していれば自然と身に付くであろうモノが多いのであるが、そういった「師匠」となる上司や先輩に出会えず、悶々とただ忙殺されてしまっている人にとっては是非本書を読んでもらいたいと思う。 (コモヒコ/2007-01-28)

「エンジニア」となっていますが、機械系と言うよりはSEやSAの方向けの本です。
私は社内の情報システム部門に在籍していますが、本書は具体例も多く、非常にためになりました。
紹介している方法も、決して奇をてらったものでなく、
「デジタルツールの駆使」
というより
「アナログツールも活用した時間管理と仕事の進め方」
と言った内容が多いです。「これならすぐに始められる」といった方法も多いです。
プロジェクトマネージャが「多くのメンバーを管理」するには向かないですが、プロマネ自身の時間管理、そしてメンバー自身の時間の管理などには充分参考になると思います。 (アキンド/2006-11-30)

確かにエンジニアに特化した内容も一部ありますが、事務系のサラリーマンにも役に立つノウハウが一杯です。対人関係や調整の多い仕事では、自分の時間は人任せと考えがちですが、逆説的に自分で時間を管理する効率化の余地は大きいと思います。

「自分の記憶力を信用しない｣、「ルーチンとは、一度だけ考え、何度も実行するための手段である｣、「この世には優先順位は３つしかない｣など、簡潔で鋭い指摘がいいですね。 (じゃま/2008-01-04)

本書はオライリーシリーズだし、ということで購入。
が、これをぜーんぶ守った場合、どうなっちゃうんでしょうね？（笑）

実例チックなトピックスがいろいろ出てくるのですが、事例が極端すぎて参考になりません。それはまだ自分が本物の修羅場を知らないだけかもしれないしれませんが。

で、とにかくすべてを計量化するわけですよ。
１時間毎に自分のPCからビープ音が鳴るように設定し、音の都度、自分の活力と気力を０から１０の段階で数値化。両方の数値が高い時間帯にあわせてスケジュール調整。
これは・・・（笑）
この本の筆者の場合は若い時は午前２時、今では午後２時が頭が冴えているそうです。

最終的に掲げた目標に一歩でも近付く、そのために何でもする、という場合はいろいろと参考になりそうです。個人的に「おわりに」にあるあいた時間の有効利用、という箇所に心を打たれました。地域に還元するさまざまな提案があったからです。

自分だけが良ければいいのではなく、自分がまず何らかの生活の基盤なりパワー（地位、お金、立場等）なりを確立し、最終的に余力を使って人助けに向かうという健全な姿勢。すばらしいと思います。体力は相当いりそうですが（笑） (夜の翼/2007-08-28)

元々、オライリー出版というのはエンジニア向けの技術書を
書いている良い出版者です。

この本は、一風変わっていて、その、
特定の技術に関する「How to」ではなく、
SA(System Administrator=システム管理者)のタイム・マネジメント術
について言及されています。

ＩＴ業界は、常になんだかいそがしいー、というカンジの世界です。
近づく納期、次々に変化する最新技術、、
いろんな意味で、時間との競争という側面をもちます。
ときに、なんで、こんなにいそいでいるのだろう？と
時間を管理しているのではなく、時間に管理されている自分に、なんだか凹みます。笑

面白いのは、
ＰＤＡっていう、チッチャイコンピュータがありますが、
時間管理には、メモ帳を駆使した「ＰＡＡってのもつかえる！」
ってかいてあることです。

限られた時間内で「片付ける」術を、システム管理者の視点でかかれてあり、
精神衛生面についてのケアもなされています。

何より著者の、同業者への愛情が感じられて、そこが何よりの
著者からのギフトとなっています。

オススメです♪
(やーまん/2007-07-29)

システムエンジニアが時間を管理する上でのポイントなどを知りたくて購入、通読
読んでみると、SEがプロジェクトを達成するためのポイントについてまとめたものではなく、システム管理者（複数のサーバー、ネットワークなどの最終管理者）が日常から直面するクリティカルな問題も含む様々な問題と、プロジェクトを管理するする上でのポイントをサイクルシステムというシステムを利用しての提案になっている。システム管理者が持っている能力や義務は確かに他の人たちとは異なることが大きい。その能力を利用して、タスクを自動化したり、義務をどのようにさばいていくかを具体的に記載してくれている。脳内の能力を記憶に使わずに外部装置を利用するべきというのは、様々な本で共通的に提案されていることだが、本書をよんで改めて感じた。
システム管理者として、業務に追われていると感じているのなら、本書を読んでみることを勧める。筆者の提案しているものそのまま完全に利用するのは様々な環境を想定すると難しいかもしれないが、効率よく仕事をこなしていくためのヒントが多々ちりばめられている書籍になっている。
(sickboy/2008-07-02)

まず最初に。この本の英語のタイトルは「Time Management for System Administrators」。日本語タイトルと違って、これはあくまでも System Administrator のための時間管理術。

シスアドというのは、ものすごく「on demand」な仕事が多い。ユーザーはマシンが動かないと悲鳴をあげ、マシンは部品が壊れたとアラートを上げる。どれもこれも「書類入れに積み上げておく」ような対処の仕方は出来ない。問題が起こった所に飛び込んで問題を解いてあげるしかない。

しかし、そのような仕事の仕方は作業効率を著しく下げる。事前準備が出来ないからだ。これは人間だけの話ではなく、RTOSと呼ばれるOSはそうじゃないOSを使った場合の60%ぐらいしか処理性能を出すことが出来ない。「緊急時対応」のためにリソースを一部残しておくと、どうしても100%リソースを使うわけには行かないのだ。

この本を読んでいて思ったのは、この本に書かれているやり方はRTOSのリソース管理方法とそっくりだ、ということ。別の言い方をすると「ちゃんと実践すれば、本当に成果が出るに違いないと思われるし、内容は汎用的だ」ということ。

ただし、60% は 60%。この本を読んだら、無茶なスケジュールを立てても大丈夫、とはならないが、その点だけは警告されていなかった。この本を読む前に、念頭に置いて貰えるといっそう効果が上がると思う。 (fjの教祖様/2008-03-18)

主にソフトウェア開発者に向けたプロジェクト管理のための１冊です。内容は多岐に渡り、一回で読んで全てを理解するのはなかなか難しいと思います。そこでお薦めなのは、自分の現在の状態、仕様検討段階であるのか、コーディング段階であるのか、リリース前であるのか、その段階に応じてその部分について書かれた箇所を読む方法です。前に読めば予備知識になり、後で読めば振り返りになると思います。また、著名な書物からの引用も効果的でなかなか楽しいものでした。
マイクロソフトで、とありますがマイクロソフトに特化したところはなく、一般的な手法として参考になります。 (limegreens/2006-11-07)

文字も小さく400ページ以上もあり簡単には読めるものではないが、プロジェクトマネージャを目指すあるいはその職にある者にとって最良の1冊となるのは疑いない。
現場のプロジェクトマネージャが必ず悩み懸念する事が章建てとして構成されており、他のPM本とは一線を画す。
美辞麗句な言葉はなく、全て著者の実体験に基づいた金言が散らばっている。

この書籍のおかげで、これからも随分と助かる気がする。 (blue/2008-11-16)

タイトルのプロジェクトマネジメントと聞くだけで嫌なものだと誤解して、食わず嫌いだった。しかし、アートオブとついているので、管理が技術だという視点からすれば、ちゃんと読めば良かったと後悔している。
第１０章は、特によい。人の仕事の邪魔をしないで、人の助けをするのが管理の基本である。しかし、多くの管理者、管理本は、人の仕事の邪魔をするようなことを平気でやったり書いたりしている。基本を外した本が多いなか、本書は要点を得ているので読む気になる。

飜訳が日本の文化への移転を十分していないのは、外資系の企業だけでなく、日本の企業でもソフト系の企業はカタカナ語が氾濫しているので仕方がないかもしれない。 (kaizen/2008-02-16)

プロジェクトマネジメントに興味があり本書を手に取りました。
なにか合理的な内容を求めるときは、いつも外国の書籍を読みます。
英語がもつ構造的な論理性に惹かれるのかもしれません。

実用性重視で書かれた多くのプロマネ本に対して、本書は
経験ゼロの人でも理解しやすい内容になっています。
それは数多くの実例と、著者のユーモアに依るところが大きいでしょう
私の本業はITから遠いので、実践的なソフトウェア、Web開発の章は
とばし読みしました。
それでもなお、目の覚めるような内容が含まれています。

１０章「メンバーの邪魔をしない方法」では、チーム内のコミュニケーションに
おける不快さの削減方法が記されています。メールや電話、あるいは立ち話
について、すぐにでも取り入れられることが多いです。
あるいは、１６章「社内の力関係と政治」は、組織に所属する
全ての人がぶつかる問題でしょう。
本章には「政治とは汚いことを表す言葉ではない」とあります。
政治が問題解決の１ツールであるという考え方は、風通しが良いです。

ソフトウェアおよびWeb開発に関する知識が乏しいため、私は本書の
価値を理解できていません。そのための星３つです。
もし知識があれば星５つではないかと思います。
(trafk/2007-03-25)

ITコンサル・プロマネ（職歴18年）視点でのコメントです。

システム開発やプロジェクト管理に関連した書物は、これまで数百冊を読んできました。

その中で三本の指に入る素晴らしい本です。絶品です。感謝です。

特に内容にはコメントしません。

私がこの本に支払ってもよいと考える金額は・・・

８０００円

しかし絶版だったら・・・金額はつけられませんが、何が何でも手に入れたい本です。 (pluto/2008-11-17)

プロジェクト管理の各フェーズで役に立つTipsを集めた一冊という感じです。
内容的には、なるほど、と思わせられるものが多いのですが、
訳がこなれていない上に、翻訳もの特有の笑えないジョークが鼻につくのが、
ちょっと残念、星一つマイナスです。 (palemoon/2007-04-22)

数学的な背景を持った見積もり技法を「サイエンスとしての見積もり」、経験則と単純な公式による見積もりを「アートとしての見積もり」とマコネルは区分けしている。本書では両方を取り扱うが、より「アートとしての見積もり」に重点を置くとしている。
プロジェクトのサイズを大中小と分けるなら、中小プロジェクトが圧倒的に多数を占めるものと思う。こうしたプロジェクトでも当然見積もりは必要とされるが、「サイエンスとしての見積もり」を行うのは少々スペックオーバーに思える。ほとんどの現場では経験則や貧弱な根拠による見積もりが行われ、プロジェクトに混乱をきたしているのではないだろうか。
第1部では、良い見積もりとはなにかの考察が行われる。マコネルは、見積もりとターゲットとコミットメントが異なるものであることを最初に示し、様々なデータを元に見積もりに対する考察を行う。その中で良い見積もりと適切なプロジェクトコントロールは不可分のものであるというメッセージが度々語られている。
第2部では、プロジェクトの規模や種類、ステージに応じた具体的な手法がまとめられている。
第3部では規模、工数、スケジュールなどのそれぞれの見積もりごとの手法と課題がまとめられている。

本文はわずか300ページ足らずなのだが詳細な見積もり技法の本を何冊も読むよりも。現場に立つ開発マネージャーにとって（ただし、中小規模のプロジェクトの）、この本を読み込んだ方が役に立つ実践的な知識と考察が得られるように思う。
(赤戌/2006-11-16)

常に提示される見積もりに疑問をもっていたので、じっくり本書を読んだ。
最初に提示される見積もりとコミットメントの違いの説明で、その疑問の半分は解消される思いがした。通常提示されていたものは見積もりそのものではなく、コミットメントではないかと。　この調子でアートとしての見積もりに関する知見にふれていくことで、見積もりの在り方の理解が進んでいく。
ただしここで提示される見積もりはそれなりにしっかりとしたバックデータに裏付けられた見積もりであり、通常の日本のベンダーではこの様な定量的な分析ができる体制になっているのか疑問であり、残念な気持ちにもなる。
その様な現実的な側面はあるものの、中小規模の開発案件を企画管理する立場の人には見積もりの在り方を考える上で必読の書であると思います。 (tabopapa/2008-03-09)

ミッションクリティカルなシステムを構築してみたいけど、
高価な設備が必要なんじゃないの？とお考えの方に是非読んで欲しい。
前提知識が必要な部分もあり、業務で構築に関わらない方には難しいかもしれませんが、
パラパラとめくって興味のある部分だけ読んでも相当勉強になります。 (ネス/2008-09-26)

この本ははてなやKLabでの実際の運用技術を紹介しています。
昔はインフラ・ソフト開発両方を担当していたのですが、最近はソフトウェア開発主体でインフラはあまり関与していませんでした。そんな私が久々に自身のやる気に火がつきました。
Webサーバ・DBサーバ・ファイルサーバそしてDNS、そうしたものすべてのスケーラビリティ・アベイラビリティが紹介されています。さらに運用面の紹介もあります。24時間運転のサービスはこうやっているのか〜ととても勉強になりました。
あとはハイパフォーマンスWebサイト ―高速サイトを実現する14のルールで中身を高速化してバッチリです。
(Turtle/2008-08-09)

秀和システムの「Linuxアドバンストネットワークサーバ構築ガイド HAサーバ構築編」と併せて、サーバー管理者な人には是非読んで欲しい本です。

自社サービスのサーバ構築の際に、かなり参考になりました。 (tiki/2008-09-01)

High Availability(HA:高信頼)システムに関する書籍自体は少ない。そんななかこのテーマで本が出たことに拍手。記載されているtipsは役に立つものが多い。ただし物凄く「生もの」なので1年後に役に立つかと言われると…。
ここまでで星3つつけています。

しかし。HAに関する書籍が少ないということは、実は「HAの基礎理論」が判っていない人が多い、と言うことです。この本には「HAの基礎理論を1から説明する本」としての側面を期待したのですが…残念ながらこの点に関しては期待はずれ。第1章に少しだけ書いてありますが、これだけでは記載されている『具体例』がどのような理由でそのような選択に至ったのか、理解できないでしょう。と言うわけで、第1章の記載分だけでは星2つには至らず。

結果として全体的に足の早い本になってしまっています。早い目に手に入れて、早い目に読むことをお勧めします。 (fjの教祖様/2008-10-13)

単純なワードの操作法入門ではなく、仕事でドキュメントを作るための思想・姿勢を伝える本です。ドキュメントはコミュニケーションツールであり、コミュニケーションのコストを最小化できる文書を作る為に「人間にしかできない作業にいかに専念するか」のコツを具体的に示しています。

（機械にできることを人間がやるのは）「ドキュメントが提供する価値を創造する作業」以外の無駄な作業に対して時間を要求するということで、成果に対して対価をいただく人間が取るべき姿勢ではない。この言葉には感動しました。

感動したのはもう一つ、次の一文です。

「それが決まりだ」というのなら、決まりを変えるべきです。価値を生まない決まりに存在意義はありませんし、価値を生まない決まりを遵守することに汲々とするだけの組織にも存在意義はありません。

職人の志がこもってます。 (akaz/2008-09-22)

オレがWordで書かなきゃいけないのは、町内会のチラシでもA4一枚の資料でもない。設計書やマニュアル、つまり「ドキュメント」だ！ワードアートなんか使わねぇ！勝手に箇条書きになるな！文頭を勝手に大文字にしないでくれよ。ページを手で振るの面倒くさいよ・・・何とかしてくれ・・・といった嘆きをどれだけ繰り返してきたことでしょうか。
Wordが余計なことをするせいで・・・という悔しい思いをしてきた人も、本書でWordを使いこなすだけの基礎知識が付きます。
Wordによるドキュメント作成の苦労が身に染みている人は是非。 (るー/2008-05-29)

Wordを使いこなしています、という人には不要な本でしょう。

でも世の中Wordが嫌いとかでExcelでドキュメントを記述しているところがあります。なんと嘆かわしい。ソフトウェア業界の人間がワードプロセッサ１つをまともに使えないなんて・・・。

Excelドキュメントが蔓延しているところは絶対この本を読んで考え直すべきです。
また、スタイルシートがうまく使えない人、この本で勉強すれば一発です。 (Turtle/2008-07-01)

HTML+CSSを知ってから、構造とアピアランスの分離ができることの便利さを実感していたので、Wordのスタイル機能を頻繁に使ってきました。しかし、スタイル機能について詳しく説明している書籍は皆無で、仕方なく手探りで設定してきました。誤った設定をすると、クラッシュしてしまうのですが、どこが悪いのか分からないので回復したドキュメントをテキストファイルに写して新しいWordファイルに貼り付けてスタイル設定しなおし、なんてこともありました。特にリストスタイルの設定は非常にむずかしい。それらの問題はWordの悪い部分でもありますが、この書籍では前向きに回避策を提示しています。

後半ではグループ文書機能など、今まで知らなかった機能もいくつか紹介されていました。これまでWordをまじめに勉強するヒマの無かったエンジニア、大学で論文をWordで書こうとしている学生にもぜひ読んでいただきたい書籍です。バージョン2003, 2007に対応しています。 (ゆーすけ/2008-07-30)

この本を読んだ後にWordを触ってみて「Wordの動きを理解すると、Wordでの作業は本当に楽になりそう」と感じています。

他のOffice製品と比べると、ExcelやAccessは基本的に指示したことしかしないので、
指示→結果→なるほど
となること方が多いのですが、Wordの場合、
指示→結果→なんでそうなるの？ とか、 なんでこうならないの？
となりやすいのではないかと。
この本を読むと、そうなったときの理由がわかるんですよね。もしくは最初から意図したとおりの結果になる。

この本を読んで、Wordでの作業が楽に、楽しくなるといいですね。 (関数デザイナ/2008-06-07)

Word初級者（≠初心者）に読ませたい本だと思いました。スタイルくらいなら使ってるよ、というユーザには若干退屈かもしれません。

最近の私のwordを使う上で一番の悩みは、（画面遷移図等の）画像を含んだ作図ですが、本書では華麗にスルーしているようで残念です。

自分で読むには内容の薄い本でしたが、読ませたい奴は周りにいっぱいいます。
まぁ、Wordはワープロソフトとしては出来が悪すぎるので、良い本書こうとしても限界があるよね。
(tmkm/2008-06-12)

エンジニアの方は不幸にもWord2000よりも前から Word を使っていたために
Word で大きな設計書は作れないというすり込みがされている方が多数います。
事実、挙動不審、サイズが大きくなるととたんに不安定になり、ファイルの
そのものが壊れてしまうなんて事もよくありました。
そんな経験のある方は本書を読んで今の Word を見直して見るといいと思います。
これまでに費やした無駄な時間を気付かせてくれるはずです。
なんでこんな馬鹿な事をと思う若手エンジニアはそっと上司に渡してあげましょう。
2000円と少しで膨大な時間を無駄にしなくて済むようになるはずです。 (melito/2008-06-05)

本書は、要求の導き出しから仕様化、要求の変更管理までを網羅している。
システム開発において、的確な要求を導き出すという永遠のテーマについて書かれた良書。
ＨｏｗＴｏ本と読み物としての二つの側面をもつ。
要求導き出しのテクニックなど、具体例をあげ解かり易く書かれているので、これから上流工程へ携わるビギナーの方にもお奨めできる。
また、訳本ではあるが、文章は平易で読みやすいのが大変良かった。（日本語訳、監修の方のご苦労が伺える仕上がりになっている）
本書では、要求の導き出しから仕様化の間に「要求のトリアージ」を行うことを推奨している。システム開発において、予算と納期、要求のバランスをとることは大変重要である。
この時点でボタンの掛け違いをすると、大抵の場合、納期遅延や予算超過などプロジェクトの失敗を招くことになる。
本書の第３章で取上げられている「要求のトリアージ」では、要求を選び出すための技術について触れられており、参考になった。 (ＫＩＴＴＹ/2007-01-08)

　「Mind Hacks」の続編。「Mind Hacks」は、中身の見えない脳をハックすることで、脳や心の働きを調べてみようという良書だった。続編に当たるこの本は、脳や心の「上手な使い方」が中心になっている。
　内容は、記憶術、仕事を効率的にやる方法、アイデア創生法、精神状態の改善法、等々。良く知られている手法も多いが、著者独自の手法や、それを効果的にコンピュータで行なう方法など目新しいものもそれ以上に多く、絶対に読んで損のない本。最近「Life Hacks」流行で、流行に乗った駄本が多く出ているが、それらとは一線を画す良本。「Life Hacksはもう食傷気味だ」というような人にもぜひ読んで欲しい。そういう人には特に「Life HacksのMind版」として楽しめるはずだ。
　コンピュータやそれに類する電子機器などで、これらのMind Hacksを行なうヒントもたくさん載っている。そういうものが好きな人は、この本に載っている方法をすぐにでも手元のパソコンで実行してみたくなるはずだ。オススメ。 (yoshik-y/2007-08-29)

「Mind Hacks」の続編扱いであるが、著者も目的も違う。自己の能力を開発し生産性を上げるためには何をすればよいのかについて具体的に記した本である。著者はこの本を「頭の武道」の本だと言っている。

どこから読んでもいいのだが、たとえば「創造力」の章では「何かを創造するためには環境から種を入れないといけない」という話から始まり、発想法、創造力を高める方法、夢を利用する方法、他人になりきる方法、自らの発想の道筋をトレースする方法などが紹介されている。すぐ使える手法がゴロゴロ転がっている。

ハウツー本の一種ではあるが、グレッグ・イーガンやスタートレックなどギークたちが喜びそうなネタがちりばめられており、無味乾燥ではない。「はじめに」に出てくる人間コンピュータ、メンタートの話も「デューン」から来ている。自らをチューン・アップすることの楽しみが伝わってくる本である。 (福代/2008-05-01)

前作「MIND HACKS」は、どちらかと言うと理論的な内容で、少し退屈だったくらいですが、本作はもっと身近で実用的な内容で、最後まで楽しく読めました。
参考文献も、今まで知らなかったものが多く、また本の出費が重むことになりそうです。 (アキンド/2008-04-25)

LAMPで信頼性の高い中規模以上のWebシステムを構築するにはどのような点を考慮して設計、構築、運用をすれば良いのかを体系的に学びたい方に推奨できる良書です。Flickrのエンジニアリング・マネージャである著者がノウハウを惜しげもなく披露してくれています。特にボトルネックの特定と対策について書かれた章とスケーリングについて書かれた章は参考になりました。また、実務で使えるオープンソースの様々なツールについても、使い方だけでなく、メリット／デメリットも交えて紹介しており、こちらも参考になりました。 (Edge/2007-02-15)

flickrのアーキテクチャの設計者であり、今は身売り先のYAHOOでflickrの技術マネジャーを務めるカル・ヘンダーソンによる、いかにスケーラブルな（拡張や保守・運用がしやすい）WEBアプリケーションを設計するかのノウハウ解説本。

こんだけ具体的に実務レベルでWEBアプリケーションについて詳細に語った本は見たこと無く、flickrに使用された技術やテクニックが広告の帯通り惜しみなく解説されています。

来月からLAMP環境2人（ボスと自分）プロジェクトに携わる身としてはかなり参考になりました。中身は特定の環境に依存しない基礎的なとこについての解説なので、小さなプロジェクトから大きなプロジェクトまでWEBアプリケーション開発に携わる人にとっては充分な指針になりそうな一冊。

古いけど、安価で大量に手に入るハードウェアが長期的な観点からは得策ではないという指摘は目から鱗。GOOGLEなんかの巨大会社で技術力があるとこを除いては大量PCクラスタなんかは開発やテスト環境の整合性が取れなくなったり、OSやソフトの設定ファイルの修正等に費やす時間・労力がかかるリスクを考慮するとそうなるそう。

ベテランからしたら当たり前の内容かもしれませんが、僕の様な新人SEにとってはWEBアプリケーションに対する理解が実務レベルで深まる良書じゃないかと思いましたW (mac/2007-12-29)

泥沼に陥ってるプロジェクトに所属する開発者も、デスマーチになりそうな不安があるプロジェクトに入りそうな開発者も、プロジェクトも順調でお客様との関係が良好な開発者も読んでおいて損はない良書である。

なぜなら、これからの開発者としての取り組み方を考える「MYJOB WENT TO INDIA」や、仕事そのものに対するプロセス改善の指針となる「エンジニアのための時間管理術」、今時のプロジェクトノウハウを詰め込んだ「ShipIt!」等を串刺しにしてプロジェクトの改善というものへの取り組み方を示した本だからということが理由である。

とりあえず、今の仕事に不安な部分がある開発者はこの本を読んでできそうなプラクティスからやらせてくれと言ってみることだ。自分のプロジェクトがアジャイルだとかウォーターフォールだとかは関係ない。仕事場でアジャイルというのが恥ずかしいなら「改善提案」だとか「見える化」とか言語替えしてもいい、今あるものをお客様に動かしてみてもらってもいい、朝ミーティングをやりましょうと言ってみてもいい。必ず何らかのフィードバックが得られてそこから改善が始めることができる。

この本を読むことでプロジェクトを成功に近づける/遠ざける手段を学ぶことができるはずだ。何をすればいいのかさっぱりわからないという人には最初の一歩になるはずだし、いくつかはすでに実践しているという人にはさらなる一歩になると私は思う。
(hsbt/2007-12-28)

面白かったのは「コードレビューのパターン」で、３つの模様を紹介している。コード見直し模様。

オールナイタ
　お奨めしないそうだけど、年に１回はやりたい。ちょうど、昔のJUSE、今のSWESTみたい。徹夜とすればよかったかも。
ピックアップゲーム
　SHIP ITを参照せよとのこと。日本語版の書名は「Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック」。読んでみます。
ペアプログラミング
　ドライバとナビゲータだそうです。運転者と道案内とすればよかったかも。
(kaizen/2008-07-11)

ソフトウェア開発の良い習慣について、コンパクトにまとめられています．
１つ１つの習慣の説明の中で「悪魔の囁き」「天使の助言」を使って、開発者の内面にも触れています．

好きな天使の助言を３つだけ上げるなら
* 批判するならアイデアにしなさい、人ではなく
* 自働化されたユニットテストを習慣にしなさい
* スタンドアップミーティングをしなさい

タイトルに「アジャイル」と付いていますが、アジャイルに全く興味がないディベロッパ、マネージャにも役立つ１冊になっています．
この本を通じて、ソフトウェア開発の現場に良い習慣が広まって行くことを願っています．
(hau01/2008-01-12)

このシリーズの、まるでソフトウェア開発専用であるかのような扱いは、もったいない。およそ「プロジェクト」と名のつく仕事に携わる人はいっぺん読んでみるといいと思う。

アジャイル開発手法が正しいと証明した人はまだいないし、おそらくそれは不可能だ。一方、社会システムの多くが非アジャイルで開発されていて、まがりなりにもうまく動いているわけで、アジャイル陣営は「こっちのやり方でもうまくいく」という事例を積み上げていくしかない。

中でも本書のように「アジャイルの現場の匂い」のようなものを扱った書籍は、実際に自分のプロジェクトにアジャイル開発手法を導入してはみたものの、うまくいっているのか自信が持てないような場合にかなり役立つだろう。

本書では各章の冒頭に、開発者を誘惑する「悪魔の囁き」があり、自分のプロジェクトが「きな臭い」方向に彷徨い始めているのを知るシグナルになっている。一方、各章の終わりには「天使の導き」と、プロジェクトが満たされているべき「香ばしいフレイバー」とも言える「こんな気分」という一節があって、正しい方向に進んでいるという確信を得られるようになっている。もちろんこの「正しい」は先人たちの経験の積み重ねにすぎなくて、証明されたものではない。それでも、道に迷っているときに、誰かが歩いた痕跡を見つけられたら、そりゃぁ安心だよね。

本書は、まだまだ何が出てくるかわからないアジャイルのジャングルに、恐る恐る分け入ってみた勇気ある人々のための道しるべだ。ソフトウェア開発者なら、直感的にアジャイル手法が正しいと感じることが多いだろうが、それでも自分の進んでいる道が間違ってないことを一緒になって確認してくれる、心強い友人のような存在として、そばに置いておきたい。 (ただただし/2008-01-11)

私はプログラミングとは無縁の人間ですが、それでもこの本はとても読みやすく、ためになりました。

まず、各章のまとめ方が、非常に明快。　行間のスペースも適度で目に優しい読みやすい配慮がされていたと思います。
個人的には、悪魔と天使のささやきが良かったです。とても簡潔で、且つ、ありがちな思考を的確に捉えており、それだけ読み飛ばしても本書のメッセージの概要は分かるように構成されています。
内容については、SEの方が使われる用語の中身は詳しくは分からないのですが、それでも説明している内容、注意点、改善するためにどうしたらよいかという手法は結構分かりました。
業種は違えど、仕事の精度と価値を向上させるための思考法にはそれほど変わりはないのだと確信しました。
それだけ本書が基本をしっかりと抑えているということだと思います。
もう一つ、「偉大なプログラマ、ではなく、偉大な習慣を身につけたプログラマを目指す」というあとがきのフレーズには深く共感しました。そう、仕事においても人生においても、偉大なことを成し遂げる人間は偉大な習慣を身につけ、それを常にスパイラルアップさせている方なのです。

読んでいてとても気持ちの良い本でした。
筆者とともに、お二人の日本人監修者に心から敬意を表します。
(rickey/2008-01-14)

なにがワクワクするかというと、書いてある内容がリアルで的を射ているからです。

こういう気持ちを持つと失敗へのアンチパターンであるという「悪魔の囁き」も、アジャイルな
方向で開発を進めているときの気持ちを表す「(天使の)こんな気分」も、
プログラマである自分にとってどちらも「起こっている」か「起こりうる」事象であると自覚できるのです。

いつも技術書を読んでいて感じるのは、本の中の人と自分自身は「他人」で「他所ごと」の話でした。
「ああ、この本に書いてある体験をする時がくるのかもしれないな、その時はがんばろう」という思いが
読後にありました。

しかし、この本は「書かれてあることが『リアルタイムの自分自身』」なのです。
多くの問題・ストレスを抱えており「なんとかしたい」と思っている自分のことが書かれているのです。
それは、この本がチームメンバーや自分自身といった「人」を中心に据えて物事を語っているからだと思います。

プログラマの方はこの本を読んで、その多くをすでに実践しているかもしれません。
しかし、必ず得るものはあります。　非常に読みやすく、一週間もあれば読めるでしょう。

個人的には、自分はいつもMVCモデルのM(モデル)から作っていたのですが、
V(ビュー)から作ったほうがいいのだと自覚しました（当方は少人数チーム）。

開発言語についてはJavaなどコンパイル系の言語を中心に書かれてあるのですが、
PHPやJavaScriptなどのスクリプト言語のプログラマにも十分読める内容かと思います。
また、アジャイルな開発に有用なツールの名前はいろいろ登場しますが、詳細な使い方までは
載っていません。（まぁ、そういうのは他の本が沢山あるでしょうし）

-- 購入するかどうかを書店で判断するには --
１．目次を見る（気になる項目が並んでいるか）
２．巻末の索引を見る（気になる単語が並んでいるか(特に日本語部分)）

この順番で見て、決断されると良いかと思います。
(zico/2008-03-01)

色々と他のアジャイル本を読みましたが、この本が一番、アジャイルソフトウェア開発をプロジェクトにどのように適用すればよいか具体的で分かりやすかったです。

全体の構成も各項目が短くまとめられていて読みやすかったです。
200ページの専門書ですが３日ほどで読めてしまいました。

プロジェクトが上手くいかないと嘆いている暇があったら、読む価値は絶対にあります。
ブタであるプログラマ（読んでもらうと意味が分かります）の生き残るためのバイブルです。 (なか/2008-08-19)

アジャイル開発のプラクティスを紹介した本です。
ソフトウェア開発の進め方、チームのあり方、プロジェクトの運営
等の分野で、約50個のプラクティスが紹介されています。

各プラクティスは、解説、間違った考え方、
どんな状態となると良いか、、などで、1つのプラクティスについて
5〜6ページで紹介されています。

テクニカルな部分は少なく、ソフトウェア開発の進め方、
チームのコミュニケーション、人間関係などに関連する
部分が多かったです。
ですので、「アジャイル」と構えなくても、
一般のソフトウェア開発でも利用できるプラクティスも多かった
印象です。 (lemonerika/2008-06-02)

　本書によれば、「アジャイル」という名前が付けられた開発手法は、2001年2月に発表された「アジャイルマニフェスト」に端を発している。よりよいソフトウェア開発方法を解明しようとして議論した結果、次のような価値観が根底に据えられたのである。
　- プロセスやツールよりも、人と人との交流を（重視する）
　- 包括的なドキュメントよりも、動作するソフトウェアを（重視する）
　- 契約上の交渉よりも、顧客との協調を（重視する）
　- 計画に従うことよりも、変化に対応することを（重視する）

　この「アジャイルマニフェスト」を実現するための具体的手法を、本書は９つの章立てで述べている。
　それぞれ章はいくつかの節に分かれているが、その節の構成がおもしろい。
　まず最初に「悪魔のささやき」が登場し、アジャイルでない方向へ読者を誘い込もうとする。悪魔に負けない解説文を駆使してアジャイルの方向に読者を向けたあと、正反対の結論をこんどは「天使」が高らかに宣言するというベタな展開。秀逸なのがその後の「こんな気分」というセクションで、２〜３行でアジャイルな考え方を的確にまとめてくれる。最後に必ず「バランスが肝心」というセクションで行き過ぎにブレーキをかけているのが、いかにも「アジャイル」だ。

　ドキッとさせられたり、感心したりする指摘が多かった中で、特に身につまされたのが、第６章の次の一節。

　呼び出す側が、呼び出されるオブジェクトの状態に基づいて判断して、呼び出される側のオブジェクトの状態を変更すべきではない。（中略）オブジェクトの外側での判断や状態変更を許してしまうと、オブジェクトのカプセル化を破ることになる。これはバグの温床になりかねない。

　今担当しているプログラムがしっちゃかめっちゃかになってきたのは、そういうことだったのか!!　なあ〜るほど。 (くろやぎ/2008-05-03)

一から十までプラクティスを掲載した書籍。ある意味、プラクティスを知りたければ、まずこの本を読んでおけば、ある程度問題ない状態まで、プラクティスを知ることが出来ると思います。

プラクティス本は他にも色々出ていて、私は色々な書籍を読んでいるので、アジャイルプラクティス自体から得た新しいプラクティスというのは、あんまりありませんでした。

しかし、各プラクティス毎に設けられている、プラクティスを実行していると「こんな感じ」になることを説明していたり、バランスについて説明していたり、構成にかなり凝っていて、好感が持てるし、非常に分かりやすい。

ただ、読んでいると、初心者には分からないであろう単語が幾つも何度も出てくるので、ある程度業界に所属していて、色々な本を読んでいる人が読んだ方が効果的だろうと思いました。もちろん、決していきなりこの本から読んではいけないという訳ではありませんが。

悪魔の囁き、天使の声という実際現場でありそうな葛藤を表現した手法も面白かったです。特に最後にまとめられている天使の声については、読めば書いてあったことがある程度思い出せるので、いい索引になっていると思います。

訳について言及すると、私はこの訳はなかなか良かったと思います。トム・デマルコの「ピープルウェア」程ではないにしろ、非常に分かりやすい言葉、語彙で書かれている。若干専門用語が出てきて、それに対する説明がなされていないのが残念でしたけれど。

全体としては、基本的なプラクティス全般を網羅している作品なので、実際の現場でどんなプラクティスを採用するかを考える時にも役に立ちそうですし、他のプラクティスを知らない人に対しても、説明しやすい内容に仕上がっていると思いました。これ一冊あれば、プラクティスについては十分なんじゃないかと思わせる一冊です。 (Juca/2008-04-03)

アジャイルなチームが、イテレーションごと、リリースごとに行うべき「ふりかえり」について、ふりかえりのはじめかた、やること・進め方、まとめかたなどを説明しています。

本文は200ページに満たない薄めの本ですが、著者らが「アクティビティ」と呼んでいる諸活動（言い換えると、「ふりかえりミーティングの議題」のようなもの。または、議論のすすめ方、意見の表現のしかた、共有のしかたをまとめたもの）が豊富に紹介されていて、大いに参考になりました。

これまで、KPT（Keep、Problem、Try）だけでふりかえりをしていましたが、紹介されているアクティビティから他の工夫も取り入れてみたいと思います。 (izagon/2007-10-06)

「ふりかえり」の手引きというのはとてもよいものだと思います。
反省というと、何か悪いことをしたときだけの意味に使われることが多いからもです。
よい思い出を、思い出そうという趣旨では、振り返りというのはよいと思います。
それも、漢字ではなく、「ふりかえり」というひらがなで表現するのがぴったり感があります。
名古屋アジャイル勉強会でも、ふりかえりの訓練をいろいろやっているようです。 (kaizen/2008-07-11)

”レトロスペクティブ”はいわゆる「ふりかえり」なわけですが、これを読むとその可能性が、ぐーんと広がった。
ここまで活用するか！というぐらい、さまざまなワザが詰め込まれています。

　・チェックイン
　・フォーカスオン／オフ

と呼ばれる、簡単な場の設定方法から始まり、

　・555
　・カラーコードドット
　・ヒストグラム

などのデータ収集，アイデア出しの手法、
さらには、レトロスペクティブ終了時の

　・KPTとか（他にもたくさん！）
　・プラス／デルタ

と呼ばれる気づきの共有方法まで。

他にも、50近くの実践が詰め込まれています。

小飼弾さんの書評で、「カタカナ化過多」と言われてたのはその通り。でも、これで読むのを敬遠するのはもったいないです。（たしかに、読みなれるのにページを要したが。。）

「レトロスペクティブ」に問わず、チームのあらゆるプロセスにおいて活用できる。リーダー、メンバーを問わず、プロジェクトを進める役割を持つ人にとって、チームを活性化させるためのアクティビティを得られます。 (mnishikawa/2007-10-16)