リスト：名古屋アジャイル勉強会で読んだ本 を表示しています。（全 19 件）

「７つの神話」として、ありがちな誤解、ありがちな方向性を示唆している部分がとても参考になりました。自分も、スピナッチパワーの土屋さんに、ペアプログラミングって、「警察の刑事の捜査みたいなもの」と教えてもらうまで、誤解していたところがありました。
「１人でできる仕事を２人で行えば、仕事量が２倍になる
　１人で作業することがなくなる。そんなことには耐えられない。
　ペアプログラミングは、適切なパートナがいないと成功しない
　ペアプログラミングはトレーニングに適している。しかし、作業方法を覚えたら、時間の無駄である。
　私の成功は何も認められない。すべての業績をパートナーと共有しなければいけない。
　ナビゲータは、構文エラーを見つけるだけだ。なんて窮屈なんだ。コンパイラの方が、エラーを見つけるのは上手だ。
　実作業を行ったのは１人の時だけだ。今は、どの仕事も終わらないだろう。ペアプログラミングには参る。
」（kaizen / 2008-07-11）

ペアプログラミングに関する包括的な解説書．XPが有名になるにしたがってよく知られるようになったペアプログラミングですが，XPを含め特定のプロセスにとらわれずに説明されています．内容は非常に明快に書かれていて，よくある質問や懐疑，批判の多くに対してきちんと答えてくれる．特に，プロジェクトへの導入の仕方（上司や同僚の説得の仕方），スキルと経験に応じたペアの組み方とその特徴（メリットや注意点），勤務スケジュールとペアリング，ペアプログラミングを潤滑に進める上での障壁などが印象的．本文の一部や付録に書かれているユニットテストおよびテストファーストの説明も分かりやすく，ペアプログラミングがテストファーストを推進するのに役立つという論旨をクリアに導いている．また，!ペアプログラミングの拡張として，トリプレット（三人一組のプログラミング），多面的なペアリング，プロジェクタを使ったペアプログラミング，分散型ペアプログラミングなども面白く，今後いくつか試したいと思わせるものもあり収穫があった．（鈴木純一 / 2003-05-01）

内容は悪くないと思うんですが（原書の評判は良いようですし）、翻訳がちょっと...。
日本語として全く意味の通らない部分や、逆の意味に訳出しているのではと思われる部分がちらほらとあります。（ / ）

翻訳した文章が若干気になりますが、内容は有益だと思います
専門家－専門家、専門家－新人、外向型－内向型、など
様々なペアの組合せ毎の解説がしてあり、とても参考になりました。
ペアプロを行うメリットも細かく説明されておりますので、まだペアプロを
導入して無く、導入を検討している方もそうで無い方も是非読んでみてください。（ / 2003-04-11）

ペアプログラミング、つまり二人でペアになってプログラミングをすることを言う。私はまだ新入社員でペアどころか、複数人で集まってのプロジェクトや開発チームに加わったこともない。しかし、そんな未熟者の私にも非常に明快に書かれていて面白かった。本書はペアプログラミングについての重要性、必要性、はたまたペアの組み方についての解説、そしてそこから生まれるメリット、デメリットを懇切丁寧に解説してある。また最終章では開発に関わる７つの習慣が述べられており、これらはペアプログラミングに関係なくあらゆる開発やプロジェクトに必要不可欠なことではないかと思った。経験者の方が本書を読んだらどのような感想を述べるのかわからないが、非常に興味深い１冊だった。（ / ）

この作品については賛否両論、様々な意見がすでに挙げられているが、
私は、是非、この本は様々な方、お子さんにもお勧めしていきたいと思う。
その根拠は3つ。
まずは、そのストーリーの内容。
一見、主要人物の涼宮ハルヒは、わがままで自分勝手な子だと思われがちだが、
その突発的な行動の中にも、大人が忘れかけた、「小さい頃の疑問」や「冒険への憧れ」
が窺える。
たとえばそれは、「宇宙は何処まで続いているのか」なんて表現で、よく現れる。
また、涼宮ハルヒは、それを自ら探しに行き、さらに、その謎を解こうとしている。
そんなハルヒの考えを、是非、たくさんの人に知っていただき、共感して貰いたい。

また、二つ目の根拠、それは、作者の表現の独特さにある。
それらの言葉には、普段、あまり使わない、意味があやふやになっているものも多い。
この本を機会に、色とりどりな言葉の意味を、再確認してみるのもどうだろうか。

三つ目の根拠は、読みやすさ。
なかなか深い話の題材を取り扱いながら、スラスラと読める文章は、
本嫌いなお子さんにも是非、お勧めしたい。
中には、大人でなければ、この本の意味は分からないだろうという意見もあるが、
私の付近では、小学生でも多くの人が愛読しているし、
初めは、意味は分からなくてもいいのだ。後々気づくことになるのだから。
しかし、いささか、憂鬱一巻では、少々展開が速すぎてついて行けないかもしれない。
是非、購入の際は、2,3巻一度に購入していただきたい。

また、蛇足かもしれないが、いとうのいじの挿絵もあいまって、萌え、を求めている方にも、
なかなか満足できるのではないだろうか。
朝比奈みくるのメイド服や癒しキャラ、寡黙な長門有希、ツンデレのような発言をする涼宮ハルヒ、
そのほかのキャラクターも、そんな要素満載である。
しかし、単なる萌え系で終わらないのがこのシリーズの凄さだ。（時雨ルカ / 2007-12-22）

涼宮ハルヒは、一見我が儘で、高飛車（タカビー）です。
しかし、涼宮ハルヒが自分がちっぽけな存在であることを自覚したことが、涼宮ハルヒが大きな力を持つ、ひとつのきっかけになったそうです。
涼宮ハルヒのタカビーなのは、自分自身に対する要求の高さの反面だと知ることができます。
自分の能力の限界を知ったときに、自分の周りに超能力者たちを集合させるきっかけになったというのは驚きでです。
３巻ほど読むと、わがままたっぷりのように見える涼宮ハルヒは、一方で一番常識人であることが分かるかもしれません。ぜひ、３巻分は読んでみてください。実は、私も憂鬱だけを読んだときには、ピンと来ませんでした。
何事にも前向きで、積極的に行動する子供が、大きく育つためには、周りの理解が一番かもしれません。
涼宮ハルヒは、指導者にとってのよい教訓がつまっているかもしれません。
傲れるものは、久しからずといいます。世間の常識に対して、涼宮ハルヒは挑戦はしても、傲りではないような気がします。
時雨ルカさんも書評で書いていますが、シリーズの２−３巻を読み進まないとわからないかもしれません。
文学作品としてだけでなく、さまざまな学習用教材としても使えるかもしれません。
文章で使っている単語を調べていくだけでも勉強になるほど、言葉をよく選んで描写しています。SFなら当たり前だと言われればそれまでですが、SFを知らない人にも違和感がないところがよくはないでしょうか。
ps.
内容を素直にアニメ化した京都アニメーションにも拍手を送りたい。
文学（ライトノベル文庫）とアニメ（DVD）の両方を楽しめる作品である。
アニメ（DVD）は英語になっているが、文庫が英語版が早くでないか心待ちである。
アニメ（DVD）の英語は、文化をうまく変換したかどうかよくわかりません。
文学（ライトノベル文庫）を誰に翻訳を頼むかは、角川文庫の将来がかかっているかもしれません
ハリーポッタ、ポリアンナ、赤毛のアンを超える、世界の名作になることができると思います。
どんな翻訳者がいいでしょうか。水色勾玉を訳した人はどうでしょう？
（kaizen / 2007-12-14）

この本を原作にしたアニメーションが面白かったため、
購入してみました。
ヒロインの涼宮ハルヒが中心となってストーリーが展開し、
それを常に主人公キョンの視点で描写しています。
ハルヒと、彼女を取り巻く世界が、ひたすら破天荒な
内容を繰り広げているにもかかわらず、
それを冷静に対処してしまうキョン。
この流れが意外とテンポが良く、
普段から本を読み慣れていない方でもスラスラと読める作品です。
挿絵が気に入った、もしくはアニメが気に入っている、
もしくはこれから見る予定だけど、
本はあまり得意ではないという方には
オススメできる作品だと思います。（forester / 2006-05-04）

自分の世界をつくるとしたら、
誰を連れて行きたいだろう。（shigekey / 2010-02-03）

　娯楽作品として素直に読み通せました。
　楽しかったです。
　批判している方には、キャラに感情移入できない…とか、作者の国語力が…とか、賞を受賞した作品のわりには…とか、いろいろと主張があるようですね。
　生理的に受け付けない人はやむを得ないにしても、正当な文学作品として評価するというのはどうなんでしょう？
　まるで、「インスタントラーメンの中では『ラ王』がうまい」と伝え聞いた美食家かぶれの人が、「こんなもの、スープはコクがないし、メンにはコシがない。器も…」と、本物のラーメンと同じ視線で酷評しているようです。
　私もいい年ですので、気持ちが全くわからないわけではないですが、批評をするのであれば、ある程度自分から歩み寄る姿勢を持つべきではないか？　と、思います。
　作品自体は多くの方が好評価しているように、ライトノベルとしての設定、テンポ、構成、完成度、続編以降に続く世界観の広がりなど、実によくできています。
　（ライトノベルの）ＳＦやファンタジーの場合、文字量の関係で怒涛のごとく流し込まれる世界観を消化するだけで労力を消費してしまい、完読前に力尽きてしまうことがありますが、「ハルヒ」は日常の舞台がごく普通の学園生活であり、主人公キョンの「疑いを持った視点」で物語が進んでいるのがミソです。
　この視線は、リアルタイムの学生より、すでに何事も起こらなかった学生時代を経験済みの読者の方が実はシンクロしやすいのではないでしょうか？
　そういう世代には、ハルヒの「エキセントリックな行動」や現実にはありえない展開がより光って見え、物語に吸い込まれていくはずです。
　実際、キャラ「萌え」や、メディアミックスによる販促戦略だけでは、ブームにまでは発展しません。あらゆる視点から考えても、やはり、芯となる原作のポテンシャルが高かったことがヒットの要因であるはず。そのあたりを意識して、ぜひ、読んでもらいたいです。（kibio / 2008-02-24）

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

アジャイルなチームが、イテレーションごと、リリースごとに行うべき「ふりかえり」について、ふりかえりのはじめかた、やること・進め方、まとめかたなどを説明しています。
本文は200ページに満たない薄めの本ですが、著者らが「アクティビティ」と呼んでいる諸活動（言い換えると、「ふりかえりミーティングの議題」のようなもの。または、議論のすすめ方、意見の表現のしかた、共有のしかたをまとめたもの）が豊富に紹介されていて、大いに参考になりました。
これまで、KPT（Keep、Problem、Try）だけでふりかえりをしていましたが、紹介されているアクティビティから他の工夫も取り入れてみたいと思います。（izagon / 2007-10-06）

”レトロスペクティブ”はいわゆる「ふりかえり」なわけですが、これを読むとその可能性が、ぐーんと広がった。
ここまで活用するか！というぐらい、さまざまなワザが詰め込まれています。
　・チェックイン
　・フォーカスオン／オフ
と呼ばれる、簡単な場の設定方法から始まり、
　・555
　・カラーコードドット
　・ヒストグラム
などのデータ収集，アイデア出しの手法、
さらには、レトロスペクティブ終了時の
　・KPTとか（他にもたくさん！）
　・プラス／デルタ
と呼ばれる気づきの共有方法まで。
他にも、50近くの実践が詰め込まれています。
小飼弾さんの書評で、「カタカナ化過多」と言われてたのはその通り。でも、これで読むのを敬遠するのはもったいないです。（たしかに、読みなれるのにページを要したが。。）
「レトロスペクティブ」に問わず、チームのあらゆるプロセスにおいて活用できる。リーダー、メンバーを問わず、プロジェクトを進める役割を持つ人にとって、チームを活性化させるためのアクティビティを得られます。（mnishikawa / 2007-10-16）

　レトロスペクティブとは「ふりかえり」のことです。
　私はリリース後の反省会としてKPT（Keep/Problem/Try）を利用していました。
いや、それしか無いと思っていました。
しかし、この本で多くのプラクティスや進め方を知り、
レトロスペクティブの重要性を認識できました。
　次のような進め方を推薦しています。
　1.場を設定する
　2.データを収集する
　3.アイデアを出す
　4.何をすべきか決定する
　5.レトロスペクティブを終了する
それぞれの項目に豊富なプラクティスを紹介しています。
　本のボリュームは約160ページと少ないのですが、
得られるものは大きいです。（なか / 2010-01-09）

序文に、DEMARCOが機動性について述べている。
「SEIやCMM同様XPは今の世の中に欠くことができない」
この言葉にピンと来る人は、この本を最初に読んでもよいと思います。
そうでない人は、同じシリーズの入門から読まれることをお勧めします。
ps.
ケントベックが日本に来た際のXPユーザ会の会合は、
ネクタイ半分、ラフな格好半分と、プログラマのコミュニティとしては、
現状を反映していたような記憶があります。
XPのコミュニティの反映にとっては、大事な１冊だと思います。（kaizen / 2008-01-17）

日本語として成り立っていない、ロジックが変わってしまっている、など、出版物としてのレベルに達していないと感じた。
これだけXPに関する情報(しかも日本語の)が巷にあふれている今となっては、わざわざ読む必要性は低い。（ / ）

薄い本のため読みやすいのだが、内容的には抽象部分が多いような感じがした。
あと、訳本のためか少々日本語的にも読みづらい箇所がいくつかある。
「XPって何？」というような初心者の方には簡単に読めていいかもしれない。
ただ、どうせ読むならこちらより「導入編」の方がいいかも。（XPについて具体的に触れているため内容が濃いから）（みふぃ / 2001-09-10）

「XPとは何か？」「イテレーションをどう繰り返していくのか？」というという疑問については、答えていると思う。導入編より一歩進んだとは思うが、まだXPの全貌を説明しきっていない。
しかし、「ストーリーをどの様式で、どのレベルまでどう書くか？」「テストをするにはどんなツールを使うのか？」のような具体的な疑問については答えがない。
これらの疑問の答えは、XPシリーズの別な本を読まないといけないようだ。（motofji / 2003-02-17）

これまでいくつかでたXP本の不満を解消してくれる一品です。（ / ）

要求仕様について合意するための具体的な方策が体系的に列記されている。
ワインバーグの書籍では、一番何度も読み返して利用している本である。
実際に経験したこと、実際に思い当たることなどが、沢山書かれていて共感できる。
要求仕様を明確にせずに、後で手直しについて騒いでいる人達が、何故この本を読まないか不思議である。手直しが儲け頭なので、要求仕様を明確にするとお金にならないということなのでしょうか？
（kaizen / 2008-07-08）

ソフトウェア開発で収入を得ている全ての人に本書を勧めます。一概にソフトウェア開発と言っても、プログラム経験が無いに等しい方から開発ソフトウェアの全体像を知らないままプログラムを作成する方々まで、多岐に渡る範疇を含みます。そして、ソフトウェア開発中には必ずと言って良いほど、作業手戻りや抜けなど発生します。この根本原因についての検討を本書では行われています。内容構成としては、S/Wに対する要求分析と開発の進め方をシミュレートして、我々に身近な問題点を洗い出していくものです。（ / 2000-12-01）

その名の通り要件定義フェーズの為の本である。示唆に富んだ内容を「保証印ゴキブリ退治器」、「収束設計プロセスセミナー」などの比喩を使って面白く書いてくれていてとても読みやすくなっている。
　要件定義フェーズをあつかった本は、"いかに曖昧さを減少させるか"、"いかにユーザーニーズをコントロールするか" といった収束手法に傾倒しがちなものが多い中、"いかに関係者のアイデアを引き出すか"、"いかにユーザーの満足度を高めていくか"、などニーズ生成手法にも力を入れている。その根底には、"ユーザーの満足度＝プロジェクトの成功尺度"という当たり前だが軽視しがちな基本がしっかりと根付いている印象を受けた。
　要件定義の初め方から終わり方まで抑えるべきポイントを具体例をもって示してくれていて新しい発見もあったし、参考にもなった。ただアプローチの具体例はいかにもアングロサクソン的なものが多く、日本的なアプローチへのアレンジは要りそうだ。（dat247 / 2002-05-23）

本書のよいところは、アオキさんのレビューに尽くされています。非常に多くの研修機関や大学の情報系学科で推奨されてもいます。でもなぜか、持っている人が少ないようだ。考えてみたら、本書の前提として、ソフトウェア工学、特に要件工学を、それなりにわかっている必要がありそうです。Wieger "Software Requirement" MicrosoftPress,や　Alan Davis "Software Requirement" Prentice Hall　あたりを押さえておくと、この本の本当のおもしろさがよくわかります。（ / 2002-03-01）

気楽に面白くよめる。ワインバーグだからね。
若いエンジニアだったら予習になり、ベテランだったら自分も同じような経験をしたねと楽しくよめるでしょう。
品質管理の仕事をしている人はよむといいね。品質のもつ意味が違って見えてくるでしょう。
比較的、価格も高いが、名人の話を聞くと考えれば、安いものですよ。（アマ・チュア / 2006-05-17）

とにかく翻訳（日本語）のひどさに苦労させられました．もしかしたら元の英文を読んだ方が正確に理解できたかもしれないし，フラストレーションも少なかったかもしれない．社内の勉強会の準備のために訳書を読んだが，この翻訳の質なら原文をじっくり読んだ方が得られるものが多いと思う．せっかく原文がしっかりした内容なので，翻訳者にはもっと英語の分かっている人を選ぶべきではないでしょうか（技術的知識は当然のこととして）．（ / ）

TDDの手順が、プログラマの思考過程を含めてシナリオチックに、じつに事細かに書かれており、これだけでも本書の価値はある。アジャイルのような従来のプロセスからはかなり異質なものに初めて取り組む時、誰かの思考過程をそのままなぞることができれば、その第一歩としてはこれ以上のものはないだろう。あとは応用するだけだ。
ただし、言語も複数登場するし、特定のツールの使い方が説明されているわけではないので、ハウツー的な要素は薄い。実際に適用するときは、利用するxUnitの解説や、特有ツールの運用を含めた別のドキュメントが必要になるかもしれない。
それにしても、XP関連書籍の例に漏れず、翻訳の質がひどい。日本語のレベルでどうにかしてもらいたい箇所が無数にある。（ただただし / 2004-08-14）

非常にまわりくどい表現が多い。Kent Beckの性質だろうか。
例でもってテスト駆動開発を実演する部分の「くどさ」と「屈折」は置いておくとしても、パターンの部はで明快にはっきりといいたいことを表現してほしかった。
パターンの部は、デザインパターン・リファクタリングの基本的な知識があることを前提として書かかれているようである。
また、パターンの部は、デザインパターンの書式に準拠していない。
ある程度の設計・実装する力があると何か得るものがある書物と思う。
Kent Beckの表現に問題があるとしても、翻訳の質はひどい。（ / ）

ケントベックの文章は、回りくどい表現を多用するといった特徴から翻訳しにくいというのは自分も実感しているが、それを考慮しても本書の翻訳はひどい。
文法の整合性が取れていない箇所や、文と文のつながりを完全に無視して翻訳している箇所など、日本語としておかしい所がかなり目立つ。
翻訳者の長瀬嘉秀氏は、XPやagileの形を定義づける貴重な名著群の価値を、片っ端から劣悪な翻訳で貶めていることを自覚してほしい。（hirokawa / 2009-07-11）

本書は「こうすれば良い」といった啓蒙ではなく、具体例を挙げ「この場合はこうした」といった事が書かれているため、直ぐに読めてかつ身に付く実践の書。
例えば「完全に合理的な設計が結局は誤りだった」といった言葉で表されるように、TDDの効き目を実感できる。
従来の考え方をがらりと変えざるを得ない良書である。
ベテランも初心者(には少々難しいか...)もぜひ読んで実践しよう。
オススメ。（Tokyo Disney ... 関係ではありません / 2003-09-05）

泥沼に陥ってるプロジェクトに所属する開発者も、デスマーチになりそうな不安があるプロジェクトに入りそうな開発者も、プロジェクトも順調でお客様との関係が良好な開発者も読んでおいて損はない良書である。
なぜなら、これからの開発者としての取り組み方を考える「MYJOB WENT TO INDIA」や、仕事そのものに対するプロセス改善の指針となる「エンジニアのための時間管理術」、今時のプロジェクトノウハウを詰め込んだ「ShipIt!」等を串刺しにしてプロジェクトの改善というものへの取り組み方を示した本だからということが理由である。
とりあえず、今の仕事に不安な部分がある開発者はこの本を読んでできそうなプラクティスからやらせてくれと言ってみることだ。自分のプロジェクトがアジャイルだとかウォーターフォールだとかは関係ない。仕事場でアジャイルというのが恥ずかしいなら「改善提案」だとか「見える化」とか言語替えしてもいい、今あるものをお客様に動かしてみてもらってもいい、朝ミーティングをやりましょうと言ってみてもいい。必ず何らかのフィードバックが得られてそこから改善が始めることができる。
この本を読むことでプロジェクトを成功に近づける/遠ざける手段を学ぶことができるはずだ。何をすればいいのかさっぱりわからないという人には最初の一歩になるはずだし、いくつかはすでに実践しているという人にはさらなる一歩になると私は思う。
（hsbt / 2007-12-28）

ソフトウェア開発の良い習慣について、コンパクトにまとめられています．
１つ１つの習慣の説明の中で「悪魔の囁き」「天使の助言」を使って、開発者の内面にも触れています．
好きな天使の助言を３つだけ上げるなら
* 批判するならアイデアにしなさい、人ではなく
* 自働化されたユニットテストを習慣にしなさい
* スタンドアップミーティングをしなさい
タイトルに「アジャイル」と付いていますが、アジャイルに全く興味がないディベロッパ、マネージャにも役立つ１冊になっています．
この本を通じて、ソフトウェア開発の現場に良い習慣が広まって行くことを願っています．
（hau01 / 2008-01-12）

このシリーズの、まるでソフトウェア開発専用であるかのような扱いは、もったいない。およそ「プロジェクト」と名のつく仕事に携わる人はいっぺん読んでみるといいと思う。
アジャイル開発手法が正しいと証明した人はまだいないし、おそらくそれは不可能だ。一方、社会システムの多くが非アジャイルで開発されていて、まがりなりにもうまく動いているわけで、アジャイル陣営は「こっちのやり方でもうまくいく」という事例を積み上げていくしかない。
中でも本書のように「アジャイルの現場の匂い」のようなものを扱った書籍は、実際に自分のプロジェクトにアジャイル開発手法を導入してはみたものの、うまくいっているのか自信が持てないような場合にかなり役立つだろう。
本書では各章の冒頭に、開発者を誘惑する「悪魔の囁き」があり、自分のプロジェクトが「きな臭い」方向に彷徨い始めているのを知るシグナルになっている。一方、各章の終わりには「天使の導き」と、プロジェクトが満たされているべき「香ばしいフレイバー」とも言える「こんな気分」という一節があって、正しい方向に進んでいるという確信を得られるようになっている。もちろんこの「正しい」は先人たちの経験の積み重ねにすぎなくて、証明されたものではない。それでも、道に迷っているときに、誰かが歩いた痕跡を見つけられたら、そりゃぁ安心だよね。
本書は、まだまだ何が出てくるかわからないアジャイルのジャングルに、恐る恐る分け入ってみた勇気ある人々のための道しるべだ。ソフトウェア開発者なら、直感的にアジャイル手法が正しいと感じることが多いだろうが、それでも自分の進んでいる道が間違ってないことを一緒になって確認してくれる、心強い友人のような存在として、そばに置いておきたい。（ただただし / 2008-01-11）

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

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

数学とは何なのか。
学校で教わる数々の数式にはどんな意味があるのか を小説形式で教えてくれる一冊。
登場人物によってレベル分けしてくれていて、
初心者はテトラちゃんと、中級者は主人公と、上級者はミルカさんと一緒に考えていけばいいように作ってある。
想像していたよりはるかに面白かった。
物理を専攻してる私にとって数学は道具であり、苦痛を伴う作業でしかなかった。
しかしこの本のおかげで、数学を見る目が変わった。
数学の面白さに少しふれた気がする。
数学を専攻する人の気持ちが少しわかった気がする。
特にテイラー展開する意味を知ることができたのは大きな収穫だった。
高３、大学１年生程度の知識があった方がより楽しめると思う。（あう / 2009-03-29）

とても面白い本です。高校3年生の難しい目レベルの数学＋αが楽しんで学べる本です。基本的には元理系なんだけど数学を使うような仕事をしていない大人が高校生くらいを思い出しながら…という内容な気がします。甘酸っぱいストーリーは現役高校生、大学生にはちょっと「くさい」かもしれません。
本書の中の”ぼく”も述べていることですが「自分で数式を書いてみることが大切」です。そのために紙とペンを用意しましょう。（通勤電車の中では数式を書きづらいのが難点ですね。）
オススメの読み方はとりあえず一回通してとにかく読んでみることですね。それで久しぶりに数式に触れたいという意欲が出てくると思います。あとは読み返しながら休日にゆっくりと数式と向き合うと楽しめます。（木下牛 / 2007-12-15）

　著者のwebページでも話題の、(女の子にだけでなく)萌えられる数学(^_^;)。
　不思議な才媛ミルカさんと、元気っ娘テトラちゃんの間で心を揺らしながら、「僕」が数学の問題を考えていく。この手の本でありがちな、子供だましの数学ではなく、おもにオイラーがやったような無限級数や母関数の話が中心なので、良い意味で読み応えがある。ミルカさんは数学に関しては天才的だが、テトラちゃんはそうではないので、テトラちゃんに理解できるように書かれているところを良く読めば、彼女と同じ高校１年生レベルの読者でも理解しながら読めるはずだ。
　また、オイラーなどに興味があり、こういう数学もある程度知っている数学愛好家にも新しい発見があるだけの内容であると思える。そのような人は、出て来る数式を楽しみつつ、「僕」と二人の女の子の数学以外の話も楽しめるはずだ。
　さらに、根っからの理系で、数学自体に萌えているような人にもオススメである。何故なら、ミルカさんの魅力がわかるのは、まさにそういう人だと思えるからだ。（yoshik-y / 2007-06-27）

著者は、プログラマの数学や各種コンピュータプログラミング関連図書で知られる結城博氏。
本の大きさはカバンにすっと入れられるサイズで、電車の中や待ち合わせの時間つぶしに持ち歩いても邪魔にならない。
こういうところはよく考えられていると思うし、プログラマの数学を買ったときに不便に思った点なので、改善されていてうれしい。
内容的には中学生でもわかる〜大学生でも難しいと幅広いものがあり、老若男女問わず楽しめる一冊。
楽しめるけれども、きちんとした数学書で、丁寧な解説が随所でなされているのには驚いた。
個人的には、数学があんまり好きじゃないという人にこそ、読んでほしいと思う。
数式が理解できなくても、小説のように図を追って話を読むだけでも、十分に数学の楽しさに触れてもらえると思うので。
また、理工系大学を目指す学生や、そういった大学に所属する学生さんにもぜひ読んでほしい。数学の知識が無いまま読んでも面白いが、数学の知識があれば、噛むほどに味が出てくる一冊だと思うからだ。
僕と数学ガールとの対話が軸となってストーリーが進んでいくので、そういった形式の本がニガテな方には若干つらいかもしれない。（正直、私もなれるまではつらかった）
この本で、数学好きな人が一人でも多くなってくれればと思う。（にゃんた / 2007-07-31）

純粋に楽しめました。数学――例えば、フィボナッチ数列とかテイラー展開、そして対数や虚数など――は、学校へおみやげとして置いてきてしまいましたが、読み進んでいくうちに、ああ確かあったあった、あの頃も楽しんで方程式を解いていた、と懐かしさがこみ上げました。
しかもかなり高度な数式を遊び心を入れながら解き明かしていきます。単純に解いていくという単なる専門書ではなく、ちょっと甘酸っぱいストーリーの中で数学というものが語られています。
思春期の不確かな部分と、数学という記号や数で証明できるものとの対比がお見事です。（小口栞 / 2008-01-30）

思考スピードで身につくテスト設計入門！
これはわかりやすい。
テスト技術に関して、基本がしっかりと詰まっている本にもかかわらず、テストに関してはほとんど素人の私にもサクッと読めました。
　・マインドマップ、テストの基本 から、
　・仕様分析
　・テスト計画
　・テスト設計
　・テスト実装
　・テスト報告
といった、テスト技術の基本をプロセス順にしっかりと説明。
1冊読み終わるころには、マインドマップと、テスト技術者としての基礎知識がしっかりと頭に定着します。
テストのことを知らないとか、これからテストにかかわるといった人はもちろん、開発メンバーも、基本的な素養として、本書のテスト知識（＆マインドマップの書き方）は必要だと思うので、とにかくおススメです。
（mnishikawa / 2007-08-05）

本書は、単なるマインドマップの解説書ではなく、マインドマップを利用して学ぶことが出来るソフトウェアテストの入門書です。
マインドマップを知らない人でも、基本的なマップの書き方から学ぶことが出来ますし、テスト初心者からベテランまで幅広く、
マインドマップを使ってテスト工程や思考過程について楽しく学ぶことが出来ます。
本書ではソフトウェアテストの仕様分析からテスト報告まで、一連のテスト工程を様々なマインドマップを描きながら、
どのような「気付き」を得るのか、その過程が詳細に書かれており、かなり実践的な内容でもあります。
本書を一読すると、ソフトウェアテストがいかに創造的に行うべきものなのかという事を理解することが出来ると思います。
マインドマップを使った思考法は、テストフェーズ以外にも当てはめられるため、その意味ではソフトウェア技術者全般が
「気付き」を得るためのノウハウを学べる一冊とも捉えられます。（もつさん / 2007-07-02）

マインドマップという単語に惹かれて読んでみましたが、「はじめに」で筆者が主張しているように、テストの作業工程に焦点をあて、しっかり書かれています。
自分のことを振り返ってみても、新人にテストを教えるのは大変なのですが、テストの意義とイメージをつかんだうえで、テスト行程とその作業の説明がされているので、新人にテストという仕事を理解させることができます。いままでこういったテストを仕事として行うためにはどうすればいいかという本はなかったので、目新しいと思います｡
また、マインドマップを使って思考の見える化を行うことで、新人は自分の考えをまとめることができ、先輩に説明を行うことが容易になり、一方先輩は新人の思考が見えることで適切なアドバイスを与えることができます。テストは個人の頭の中だけで行われることが多いので、コミュニケーションの手法として非常に効果があります。
内容はほとんどテスト技法に触れられていないのですが、巻末のブックガイドで保管すべき知識を得るための本が紹介されているので、それも役に立つでしょう。テストの入門書を読むための入門書と考えると合点がいきます。
教育効果が非常に大きいので、先輩が新人に与える最初の一冊として最適だと思います｡
また、先輩も部下の指導に参考にすることができるでしょう。
ただ、中間成果物としてのマインドマップを作成した後に、ドキュメントに落とす部分がもう少し詳しく書かれていたら良かったと思います。
この点が残念だったのでマイナス一点としました。（たまねこ / 2007-08-29）

ソフトウェア試験の意図をよく掘り起こしている良書だと思います。
ところで、本書ではV字モデルといって、要求分析から受入テストへ矢印が伸びています。
受入テストから要求分析へ矢印がのびてはいけないのでしょうか。
V字モデルというものを、何か限定的に捉えている根拠がわかりませんでした。
また、マインドマップとは、意識図、脳図、意図図のどれでしょう。
あ、意図でいいんだ。意図には図という漢字が含まれているから。なんだ、日本語の方が解りやすい。
本の表題は、「ソフトウェアテストからはじまるマインドマップ」のように順番が逆の方がよかったかもしれない。あるいは、「ソフトウェア試験の意図」でもよいのかもしれません。
（kaizen / 2008-07-11）

基本的にマインドマップを書いて、テスト計画書・仕様書の作成を行いましょう、という内容です。
マインドマップ自体の書き方は他の書籍をあるので、そちらで十分です。
概略は「新人君がマインドマップを使って、ベテランの指導を受けながら
テスト計画を作成する」という内容で展開されています。
えっと、展開が・・・
1:まず要件定義書の目次を参考にせよ。
2:ない場合は、要件を確認せよ。
で始まります。この辺でおや?っとなりますが・・・
さらに、話の展開のなかで、テスト計画に問題があるところは、ベテランが指示をする、という形で具体例が展開されていきます。
しかし、このベテランが「なぜ、そのような要件を思いついたか？」はまったくの白紙です。
つまりは、テストの網羅性等をカバーするノウハウは記述されておらず、
「天から降ってくる」という内容になっています。参考になりません。
（しかも、ケースになっているのはインフラをベースにしたSTの例だけで、UTやCT、とくに網羅性に関してはゼロという状態です。）
これから、まじめにテストにとり組もうという人が、まず手に取るべき本ではないなと感じました。
たしかにマインドマップを用いた、情報整理は非常に有効で
私自身も使っています。しかし、テストに関しては、世の中に多くの知見や
実績に裏打ちされた理論があるのも実情です。それらのノウハウを礎にせずに
いきなりマインド・マップで「創造的テストが可能」と主張するのは
いかがなものか、と思います。
帯では著名な平鍋氏や西氏が絶賛していますが、彼らのような著名人がこのような本を入門書として薦めていること自体が、ちょいと無責任かな？と感じますし、
日本のソフトウェア産業の「品質」がなかなかあがらないものむべなるかな、というところです。
まー、マインドマップを利用するとこんなこともできるぜ！という例を
出しているのは評価できますが。「ソフトウェアテスト」と表題で銘打つは
看板に偽りありではないかと思います。
（御神苗 / 2007-08-27）

これまで出版されたXPシリーズを読んで、「実際にはどうしたらいいのだろうか？」と感じていた疑問がすべて解けました。特に衝撃を受けたのは、どうせ途中で要求が変わってくるのだから、最初からシステム全体にわたる完璧な設計をしてもムダである、という点です。設計に要する時間は、10分が理想。直ちにペアを組んでコーディングに向かうべし。コメントは、最小限にして、コードにすべてを語らせるべし。プロジェクト管理ツールを使うな、など、従来の開発手法からすると、「だいじょうぶなの？」と思わせるような提案が満載ですが、全体を読むと、さまざまな手法が効果的に組み合わせられていて、うまく行きそうな気がしてきます。おそらく、最大のポイントは、コミュニケーションの強化なのでしょう。<P!>これからXPを試してみようと思っている開発者にとっては、バイブルになると思います。
翻訳については、特に問題を感じませんでした。読みやすかったと思います。（XXXYYZZZ / 2001-09-03）

英語の文献は英語でよむプログラマが増えて欲しい。ただし、英語が読めるプログラマが偉い訳ではない。C言語ならC言語が読めればよい。
本書は、受入テストや小さなリリース、単体試験、テストファーストなど、あたりまえのことがあたりまえに書かれています。
おかしなプロセスモデルには、やらなくてもよい管理事項ばかり書かれていて、肝心のやらなくてはいけない技術的な事項がすっぽり抜けていることがあります。
原著の事例はSmallTalkだそうです。ただし、訳者らがJAVAに書き換えたものを付録につけているのでC言語系のプログラマでも理解できると思います。
エクストリームプログラミングって、普通にやっていることを少し誇張して極端に（extremely)書いただけのものだと思います。
そう感じない人がいたら、その人の仕事で大切なことが抜けているかもしれません。
ps.
ＸＰ関連のイベントで、ペアプログラミングについて、スピナッチパワーの土屋さんから、刑事が２人で捜査するようなものだと教えていただきました。これまで、ペアプログラミングに関する誤解が一気に解消しました。ありがとうございました。（kaizen / 2008-02-26）

　XP自体は画期的で注目していたのですが、まだ日本には書籍も情報も少なく、出版されるとすぐにこの本を購入しました。読んですぐに感じたのですが、日本語訳が変です。内容的には（日本語的には）間違ってないのですが、 なんというか受験英語的訳というか、何度か読み返して
その日本語が理解できるという感じで、読むのに苦労します。あんまりお勧めできる本ではないですね。（ / ）

カタカナ語が多いので読みにくいかもしれない。
日本語に翻訳しながら読むと、内容がよく分かる。
イテレーションは、繰り返し。
最初のイテレーションプランは、初回計画。
ストーリーは筋書き。
リリースプランは出荷計画。
日本語に直すと、文章が短くなって、内容が浮き出てくる。
JAVAの実例があるので、プログラムだけを追っかけるのもよいかもしれない。
（kaizen / 2008-07-08）

この本は実際に２人のプロジェクトでXPを行った場合にどんなことが問題となり、どのような利点があり、結果としてどういう収穫があったかを示しています。開発者が自分の言葉で書いているところが何より良い点で、とても読みやすいです。XPの実践は、２人（顧客を入れると３人）という小さな単位でも十分可能で（というより、むしろ向いている？）、重要なのはコミュニケーションだということがはっきりわかります。厚くなく、薄くなく、ソースコードも豊富で、XPシリーズの中では今のところ、これが一番さらっと読めました。（ / ）

理論面を書いたXPの書籍は多くありますが,実際の現場でのレポート例は
少なかったのではないでしょうか?
そういった意味で貴重です.
ただ,やはり日本と海外の文化の違いや,時代の違いを意識して読まないと
いけない点も多々あるように見受けられました.（IT侍 / 2006-09-28）

　XPのお話を大まかに掴むのにちょうどよいかもしれない。
書籍だとどうしても内容が古くなってしまったり、現実にそぐわない事例になってしまう感じがする。この本ではとあるネット関連の体験談を載せているが、生きた体験談を欲するならネットの方が豊富に落ちているし、自分の環境に近い実施例を見つけられると思う。（リーパー / 2002-07-23）

XPはあたりまえのことを極端に表現しているだけかもしれません。
つまり、eXtreme Presentation。
そんなことはどっちでもよく、自分達のやっていることが本に書かれているので共感できる。
ソフトウェア工学という名目の本に、抽象論ばかり書いてあったり、特定の場合しか成立しないようなウォータフォールモデルの例が書いてあっても嬉しくない。
自分が実際にやっていることと同じことが１０分の１でも書かれていれば、安心して読めます。
ps.
ＸＰ関連のイベントで、ペアプログラミングについて、スピナッチパワーの土屋さんから、刑事が２人で捜査するようなものだと教えていただきました。これまで、ペアプログラミングに関する誤解が一気に解消しました。ありがとうございました。 （kaizen / 2008-05-12）

エクストリームプログラミング(XP)を実践するための価値観・プラクティスが説明されている本。
だというのを4分の1程読んだあと,ネットで検索することによって理解した。
XPに関する知識が全くない状態からこの本を読むと,何の話をしているのか,どの方向に話が向かっているのかさっぱり分からなかった。
「XPとは何なのか？」という疑問を解決したくこの本にあたったが,正直この本だけで解答を得るのは不可能であろう。読了した今でも十分に理解しきれなかった箇所が何点かある。
ある程度基礎知識もしくはXPに近い開発形態を経験した方にのみこの本を真に理解することができるのかもしれない。
しかし「入門」とタイトルにある以上,まったくの予備知識がない者にも理解できるような構成にしていただきたかった。（tigerbird / 2009-05-31）

これ1冊ではXPの全容は理解できないが、XPの概要を大掴みにする、という目的は十分に果たしている。シリーズ本の第1巻なのだから、位置付け的には正しいはずだ。詳細を必要とする人は、適宜本シリーズの他の本を読めば良い。XPを始めるための第一歩として良書と思う。&#60;br /&#62;&#60;br /&#62;但し、翻訳の質があまりにひどいと感じた。第1版でも翻訳の質の悪さを指摘するレビューが多く見られたので、第2版では改善が見られるかと期待したが期待外れだったようだ。XPを使うか否かに関わらず基礎知識として多くの人に読んでもらいたい内容であるだけに、訳の悪さは非常に残念。（Yazin / 2006-06-04）

アメリカの貧弱なソフトウェア開発体制の暴露本。何故アメリカのソフトウェアの品質が悪いかよくわかる。日本のソフトウェア技術者は読む必要が全く無い。トヨタ生産方式を引き合いに出しているが、2,000年の歴史と文化を背景にして確立された日本人の人間性を基にして生まれた生産方式をアメリカ人には理解出来るとは思えない。（アメリカで仕事をしているので原版で読んだ。）
（Shin / 2009-05-04）

ソフトウェアを開発する際に、読んでおくとよい本です。
大規模開発の特定のやり方に依存した説明が蔓延している中で、本当に自分達に必要なことは何かを考える際に、考える視点を与えてくれます。
最後には、自分達の仕事のやり方の原則を作り出し、他の人達とどうやって合意を形成するかを実践していくとよいかもしれません。
実は、これまでやっていたことがすごくよいことに気がつくかもしれません。（kaizen / 2008-03-18）

リーン開発の７つの原則を一つひとつ丁寧に説明しています。筆者の開発現場やコンサルでの経験に基づいたアドバイスが盛り込まれていて、原則を一つ読み終えるたびに、仕事の改善アイディアが湧いてきます。
日本語が自然で、とても読みやすいことも特筆に値します。
管理者の方は、「経営の未来(ゲイリーハメル著)」も合わせて読むと、組織(チーム)運営上のヒントも得られるでしょう。（たけ / 2008-03-18）

「リーン」とは、「ムダのない」という意味で、トヨタ生産方式（TPS:Toyota Production System)にの考え方に基づく手法につけられたもう一つの名前です。「リーン」の考え方は、製造（生産管理）だけでなく、製品開発や様々な分野に適用範囲を広げています。
この本は、ソフトウェア開発（ITシステム開発）に「リーン」の考え方を適用した「リーンソフトウェア開発」の理論とソフトウェア開発における実践方法、それを裏付ける様々な事例、そして導入指針を紹介しています。
製造（生産管理）における「リーン」の実践方法を、そのままソウトウェア開発に持ってくることはできません。しかし、その実践方法の背景にある「リーン」の考え方（理論）をソフトウェア開発に適用するれば、ソフトウェア開発においてもムダをなくし、生産性を飛躍的に向上することができるはずです。そこで生まれる実践方法は、まさに「アジャイル開発手法」のプラクティスそのものです。そして「リーン」の理論は、「アジャイル開発手法」を理論的に裏付ける考え方として広まってきています。
ケント・ベック氏（agile XP手法の提唱者）による本書のまえがきにある「ソフトウェア開発は、多くのつながりを持つ鎖である。全体の効率を改善するには、その鎖全体に目をむかなくてはならない」という言葉に表されるように、「リーン」の考え方を支える根本は、「TOC（Theory of Constraints:制約理論）」同様、全体最適という考え方です。理論という点では、「リーン」とは、まさに「TOC」と同じ考え方です。つまり本書は、「TOC」をソフトウェア開発に適用した手法であるとも言うことができると思います。
本書では、前作「リーンソフトウエア開発〜アジャイル開発を実践する22の方法〜」で説明した「リーン」原則について、さらに数多くのソフトウェア業界や他業界における事例を載せており、導入のためのガイドとなる内容になっています。
また前作との違いとしては、この本では「価値」（顧客価値）という点を特に強調しています。
「リーン」（TPS）では、「価値」を生まない作業は、基本的にムダと考えます。
本書では、ソフトウェア開発（IT開発）においても顧客に「価値」提供するという考え方が最も重要であるとしています。
私も、「人売り」の商売から脱却するためにも、顧客価値を重視する考え方が、ソフトウェア開発（IT開発）において最も重要であると思います。
本書は、これからのソフトウェア開発の指針を示す書籍として、ソフトウェア開発（IT開発）に関係する全ての方（開発者はもとより、営業、SE、PM、マネージャ、顧客、ユーザ・・・）に読んでいただきたい一冊です。
本書のまえがきにジェフ・サザーランド氏（agile SUCRUM手法の提唱者）が述べているように、ディスクに常備し、定期的の読み返すことをお勧めします。
（jadler / 2009-10-06）

全体的なアジャイル開発の進め方、という意味では割とあっさりとした、でもポイントは抑えた内容かな、と思いました。
素晴らしい点は、
開発の重要なポイントは「コードを書くこと」という観点で、
OOPの原則、デザインパターンの説明をしつつ、
アジャイル開発らしく、
「実際に動く」「変更を受け入れる」「簡潔なコード」を
重視した実装をどのように進めていくかが、
とてもよく解説されています。
「基本」と「応用」を一体化させたような印象で、
まさに「奥義」とはこういうことを言うのかもしれない、と感じました。（ / 2004-08-21）

この本を読むまで、Singletonってなんのことかさっぱりわかりませんでした。
16章の「singletonパターンとMonostateパターン」を読んで、はじめてああ、そうだったのだわかりました。
Singletonは単一生成、monostateは単一状態なのですね。なぜ、みんな日本語で言わないのでしょうか。たしかにプログラムで書く用語は、プログラムの用語のままの方がよいことはわかります。でも、翻訳するのなら、日本語に翻訳すれば、意味がわかって、説明が同じ量でわかります。そのため、singleton(単一生成)、monostate（単一状態）でよいでしょうか。single, monoの語幹の意味の違いがまだよくわかっていません。
翻訳しない単語は、意味をわかるのに、説明を訳注として追加すれば、同じ水準まで理解が進むと感じました。よろしくお願いします。
（kaizen / 2008-07-11）

特に、オブジェクト指向の原則、プラクティスなど開発者に
とってかなり有意義な内容だと思う。
他の本でも似た内容がちらばっていることはあるが、原則、
プラクティスとしてまとまっていると理解しやすい。
欲を言えば、デザインパターンの部分が多すぎるから、減らして
安くしてほしかった。（ / 2004-09-22）

IT業界では、見える化をすると、原価がはっきりし、原価しか支払いをしてもらえない状況がある。その状況をどのように打開するとよいかを考える最初のきっかけとなるとよい。
長い時間でソフトを書く能力の低い人にほど支払いが多く、短時間で完成する能力の高い人には支払いが少ないという状況を、関係者はどう打開するつもりだろうか。
著者らの努力に期待したい。（kaizen / 2007-12-17）

プロジェクト・マネージャやＰＭＯのメンバーが対象・・・といいつつも、
「プロジェクトで発生した事象、あるいは起こりつつある何かの予兆を「見える化」すること
さらに、見えたものから真の問題が何かを「言える化」し、
問題の対応策を策定する「直せる化」を含めて、
現場に立脚した方法論を創出することを目標としている。」
というので、プロジェクト・メンバー全員が知っておくべきこと、と思います。

「見える化」だけでなく、
「言える化」「直せる化」は、本書で新たに提案する呼び方、
を提唱されています。

この本で取り上げている「下流」とは、
読む前は、システム開発の「下工程」・・詳細設計からＣＤ／ＵＴあたりのことか、
と思っていましたが、「結合テスト〜総合テスト工程」のこと。
下流工程編ですが、
掲載されている数多くの図・表、チェックリスト等は、
システムの基本構想書やプロジェクト実行計画書、品質保証計画書等の
策定・整備時にも参考になると思います。
（papillon / 2007-10-06）

プロジェクトの下流、実際にソフトが出来上がっていく過程が中心。
状況を「見える化」し、問題点を「言える化」したら、
さらに、その問題を「直せる化」するため、
使えそうなツールや手法が、色々と紹介されてます。
内容の粒度やレベルが、揃っていない印象を受ける箇所もあり、
ごちゃごちゃしてて、全体としてのまとまりは良くない感じですが、
色々な手法が、結構、具体的に紹介されているので、
ここは、使えそう、という部分が、多分、あると思います。（palemoon / 2006-08-24）

ITプロジェクトの「見える化」は何のためにやるかで、そのやり方も違うかもしれません。
この冊子での報告を参考に、自社の目的、自部門の目的、個々の社員の目的を明確にして、見える化を進めるとよいと思われます。
見える化の費用が、改善による費用削減を上回らないように、なるべく費用がかからない方法がよいと思われます。（kaizen / 2008-01-18）

　昨年でた「下流工程編」は、
　システム開発のライフサイクルの下流部分にあたる「システムテスト」「運用テスト」に
　焦点をあてた「見える化」でしたが、
　今年の「上流工程編」は、「要件定義」と「システム設計」工程の「見える化」です。

　下流工程編が、システム開発のシステムテスト工程以降を
　　医療の現場をアナロジーにして、
　　健康状態・病気の診断、対症療法で説明したのに対して、
　上流工程編は、
　　飛行機のフライトにおける目標値設定と飛行計画に例えています。

　内容的には、
　プロジェクトにおける「定性的見える化アプローチ」を、
　　まず「自己評価シート」に基づくセルフチェックと、
　　アセッサーによる「ヒアリングシート」におるアセスメントの実施で把握。
次に、
　　「定量的見える化アプローチ」
　　測定尺度・・・ＣＭＭＩの「測定プロセス」の指標そのものになるか、と思いますが、
　　この指標項目を見ているだけで、しばし考えさせられます。
　「曖昧性と不確実性のマネジメント」は、
　　　ズバリ、リスク管理。
　そのリスクも踏まえた上での「見切り」をどうするか。
　　「良い見切り」と「悪い見切り」を考えます。
　具体例として、
　　失敗工学・・・にならって、失敗プロジェクト事例が５８も載っています。
　　これだけでも、一読の価値あり、と思います。
（papillon / 2007-08-06）

１０箇所の改善事例が取り上げられている。この改善事例をどうやって活用するとよいかはその組織の状況によるかもしれない。
教育機関に対して、ソフトウェア技術教育として、How-TO（ハウツー）を教えて欲しいという要請がしばしばある。
教育でWhat（何）を知識として教えてもらっても、どうやればよいかが分からないので、無駄な知識として廃棄されていくことになるそうだ。（場合によっては人も含めて）
ハウツーは、現場、現地、現物によって違うので、一律に教えることができない。
教えるときは、ある一つの事例でのハウツーを示すことになる。一つの事例を鵜呑みにして、異なる現場で、習ったハウツーをそのまま実践しようとする人がいる。それでは、いい迷惑だと思うのは現場の人達だけかもしれない。また、事例集にありがちなことは、本が出たときには、その活動をしていた組織では活動が下火になってしまっていることがある。本書の事例を見たら、現状ではどのような展開になっているか、機会があれば調べてみるとよいかもしれない。
ps.
取り上げられている富士通STの会議室で名古屋アジャイル勉強会が開催されたときに、富士通プライムソフトの改善のポスターが今でも貼ってあることを確認した。
時間とともに、ハウツーであるやり方は変わっていくが、本質的な改善の火が消えていないことが大切だと感じた。すべての事例の火が消えていないかどうかを確認することは難しいが、一つでも消えていなければよしとしてはいけないでしょうか。（kaizen / 2008-02-25）

モデルを利用して、現場の問題に行き当たることがあります。
モデルを利用しなくても、現実の問題を抽出できることがあります。
モデルは網羅性を確保するための１手段です。
モデルを振り回す人は、現場、現実、現物から離れていることがしばしばあります。
なぜ、モデルを使いたいのか、
なぜ、自分よりもモデルを信用するのか、
なぜ、現実を先にみようとしないのか。
間接部門のための改善は嫌ではありませんか？
顧客のためでない改善に意味がありますか？
世の中のためにならない改善は楽しいですか？ （kaizen / 2008-02-05）

改善は、現場、現実、現物によるのが基本ではないでしょうか。
それに対して、抽象的な「プロセス」を問題にする趣旨がよくわかりません。
作業を改善するのなら、もっとちゃんとした作業分析をして欲しいものです。
本当に不必要な作業か、必要な作業かは、そんなにはっきりと分かるものではないと思います。
いかがでしょうか。（kaizen / 2008-02-05）

プロセス改善に関する基本的な知識が理解しやすく書かれていて、初心者にはとても助かる存在だと思います。
プロセス改善の目的、それをどのように実現するのか。
単にプロセス、プロセス、と言っても、プロセスとは何なのか。
改善、改善と言っても改善とは何なのか。この理解無くして、プロセス改善はあり得ないのですが、
言葉だけが先走ってしまうのではなく、行動をきっちりと合わせないといけないですね。（徳明木 望 / 2007-12-17）