昨年のマイクコーンの本(
アジャイルな見積りと計画づくり ‾価値あるソフトウェアを育てる概念と技法‾
)といい、この本といい、最近のアジャイル開発の様変わりの様子が、やっと日本語で読めるようになってきた。アジャイル食わず嫌いの人にこそ、読んで欲しい本。
開発組織のリーダークラスの人にもおすすめ。アジャイルの本質から解きほぐしてくれるので、なぜアジャイルかという点で得心が行くし、具体的な規模拡大のアプローチが示されているので、アジャイルに安心して取り組める気になる。
ただ、内容的に今までのアジャイル開発とはかなり異質なので、普通のアジャイル本も併読した方がいいかも。そうすると逆にこの本の価値がわかるかもしれない。
この商品をお持ちですか?
マーケットプレイスに出品する

無料のKindleアプリをダウンロードして、スマートフォン、タブレット、またはコンピューターで今すぐKindle本を読むことができます。Kindleデバイスは必要ありません 。詳細はこちら
Kindle Cloud Readerを使い、ブラウザですぐに読むことができます。
携帯電話のカメラを使用する - 以下のコードをスキャンし、Kindleアプリをダウンロードしてください。
アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive) 大型本 – 2010/2/18
本書では、ディーン・レフィングウェルの顕著な功績を見ることができる。アジャイル関連には多数のプロセスがあるが(XP、スクラム、リーン、DSDM、FDD、統一プロセス、など)、それらのプロセスに関する議論を超えて、ディーンはまず何がそれらのプロセスに共通であるかをまとめた。そして、その後、この本の主目的である、いかにしてアジャイル開発をスケールアップするかを述べている。彼は、すでにたくさんあるアジャイルプロセスに新しいプロセスを加えることはせずに、むしろ、既存の確立されたアジャイルプラクティス(中には奇妙な名前を持ったものがあるが)を取り込み、統合していく。そして、一段上のレベルで、技術視点、マネージメント視点の両面から、新しいプラクティスのセットを加えることで既存のプロセスを拡張しようとしている。無数のメソッドに共通に存在するベストなエンジニアリングプラクティスを統合し拡張するだけでなく、大規模なアジャイルプロジェクトにおけるガバナンスを実現する方法を説明しているのだ。(本書の序文より)
- 本の長さ368ページ
- 出版社翔泳社
- 発売日2010/2/18
- 寸法18.5 x 2.5 x 23 cm
- ISBN-104798120405
- ISBN-13978-4798120409
この商品を見た後に買っているのは?
ページ: 1 / 1 最初に戻るページ: 1 / 1
商品の説明
著者について
・著者紹介
Dean Leffingwell(ディーン・レフィングウェル)
米国で非常に著名なコンサルタントであり、RequisiteProという要求管理ツールを作った会社を立ち上げたことでも有名です。元はRational(IBMに買収された)のVice Presidentであり、現在は違う会社を立ち上げました。
最近の5年ほどは、コンサルタントとして、多数の企業で活躍し、その経験をもとにこの本を書き上げています。
・監訳者紹介
玉川 憲(たまがわ けん)
IBMソフトウェアエバンジェリスト、IBM Rational 事業部テクニカルセールス部長。2000年にIBM Research Tokyo(当時、東京基礎研究所)に入所。超小型腕時計型Linux コンピュータWatchPad の研究開発に従事。2003年よりIBM Rational 事業部に所属。RUP ・要求管理・オブジェクト指向分析設計のコンサルティングなどを行う。2006年より米国在住。アジャイル方法論を用いたソフトウェア開発に従事。2009年から現職。2 歳の息子との建設機械見物が趣味。東京大学工学修士。カーネギーメロン大学経営学修士(MBA)。同ソフトウェア工学修士(MSE)。RUP認定講師。オブジェクト指向分析設計認定講師。ユースケース要求管理認定講師。認定スクラムマスター。
Dean Leffingwell(ディーン・レフィングウェル)
米国で非常に著名なコンサルタントであり、RequisiteProという要求管理ツールを作った会社を立ち上げたことでも有名です。元はRational(IBMに買収された)のVice Presidentであり、現在は違う会社を立ち上げました。
最近の5年ほどは、コンサルタントとして、多数の企業で活躍し、その経験をもとにこの本を書き上げています。
・監訳者紹介
玉川 憲(たまがわ けん)
IBMソフトウェアエバンジェリスト、IBM Rational 事業部テクニカルセールス部長。2000年にIBM Research Tokyo(当時、東京基礎研究所)に入所。超小型腕時計型Linux コンピュータWatchPad の研究開発に従事。2003年よりIBM Rational 事業部に所属。RUP ・要求管理・オブジェクト指向分析設計のコンサルティングなどを行う。2006年より米国在住。アジャイル方法論を用いたソフトウェア開発に従事。2009年から現職。2 歳の息子との建設機械見物が趣味。東京大学工学修士。カーネギーメロン大学経営学修士(MBA)。同ソフトウェア工学修士(MSE)。RUP認定講師。オブジェクト指向分析設計認定講師。ユースケース要求管理認定講師。認定スクラムマスター。
著者略歴 (「BOOK著者紹介情報」より)
レフィングウェル,ディーン
著名なソフトウェア開発方法論者であり、著者であり、ソフトウェア開発チームのコーチであり、彼のキャリアにおいて、ソフトウェア開発チームがそのゴールを達成することを助けてきた。RequisitePro,Inc.の創立者であり元CEOであり、RequisiteProの作成者であり、Rational Softwareの元Vice Presidentである。そこでは、RUPの商品化の担当であった
玉川/憲
IBMソフトウェアエバンジェリスト、IBM Rational事業部テクニカルセールス部長。2000年にIBM Research Tokyo(当時、東京基礎研究所)に入所。超小型腕時計型LinuxコンピュータWatchPadの研究開発に従事。2003年よりIBM Rational事業部に所属。RUP・要求管理・オブジェクト指向分析設計のコンサルティングなどを行う。2006年より米国在住。アジャイル方法論を用いたソフトウェア開発に従事
橘高/陸夫
ソフトウェアアーキテクト。1997年にソニー株式会社入社。放送業務用機器事業部にてニュース製作システム等のソフトウェア開発に従事し、アーキテクチャ設計、コーディング、プロセス改善、グローバル開発プロジェクト管理などを担当。2007年より米国カーネギーメロン大学でスクラムによるソフトウェア開発を実践。帰国後、同事業部にてプロジェクトリーダーとしてスクラムを用いた社内ソフトウェア開発を実践中。早稲田大学工学修士。カーネギーメロン大学ソフトウェア工学修士(MSE)
畑/秀明
1993年日本IBM入社、IBMの社内システムの開発保守に従事。プログラマ、アーキテクト、PMとプロジェクトにおけるあらゆるロールを経験後、開発プロセス標準チームに移りRUPの導入、CMMI活動への参画などを通じてIT組織の成熟度向上に取り組む。2006年よりIBM Rational事業部所属。プロセス&ポートフォリオ管理エリアのソリューションを中心にセールス活動、導入支援・コンサルティングに従事
藤井/智弘
2000年日本ラショナルソフトウェア(当時)入社、2003年よりIBM Rational事業部所属。RUPの導入、特に反復開発や要求管理を中心としたユーザ支援と製品を担当
大澤/浩二
主任ITスペシャリスト。2000年、日本IBM入社、モデル駆動型開発による大規模アプリケーション構築プロジェクトに従事後、オブジェクト指向分析設計のためのIBM資産「GTAM」の開発を担当。2009年よりIBM Rational事業部に異動、現職(本データはこの書籍が刊行された当時に掲載されていたものです)
著名なソフトウェア開発方法論者であり、著者であり、ソフトウェア開発チームのコーチであり、彼のキャリアにおいて、ソフトウェア開発チームがそのゴールを達成することを助けてきた。RequisitePro,Inc.の創立者であり元CEOであり、RequisiteProの作成者であり、Rational Softwareの元Vice Presidentである。そこでは、RUPの商品化の担当であった
玉川/憲
IBMソフトウェアエバンジェリスト、IBM Rational事業部テクニカルセールス部長。2000年にIBM Research Tokyo(当時、東京基礎研究所)に入所。超小型腕時計型LinuxコンピュータWatchPadの研究開発に従事。2003年よりIBM Rational事業部に所属。RUP・要求管理・オブジェクト指向分析設計のコンサルティングなどを行う。2006年より米国在住。アジャイル方法論を用いたソフトウェア開発に従事
橘高/陸夫
ソフトウェアアーキテクト。1997年にソニー株式会社入社。放送業務用機器事業部にてニュース製作システム等のソフトウェア開発に従事し、アーキテクチャ設計、コーディング、プロセス改善、グローバル開発プロジェクト管理などを担当。2007年より米国カーネギーメロン大学でスクラムによるソフトウェア開発を実践。帰国後、同事業部にてプロジェクトリーダーとしてスクラムを用いた社内ソフトウェア開発を実践中。早稲田大学工学修士。カーネギーメロン大学ソフトウェア工学修士(MSE)
畑/秀明
1993年日本IBM入社、IBMの社内システムの開発保守に従事。プログラマ、アーキテクト、PMとプロジェクトにおけるあらゆるロールを経験後、開発プロセス標準チームに移りRUPの導入、CMMI活動への参画などを通じてIT組織の成熟度向上に取り組む。2006年よりIBM Rational事業部所属。プロセス&ポートフォリオ管理エリアのソリューションを中心にセールス活動、導入支援・コンサルティングに従事
藤井/智弘
2000年日本ラショナルソフトウェア(当時)入社、2003年よりIBM Rational事業部所属。RUPの導入、特に反復開発や要求管理を中心としたユーザ支援と製品を担当
大澤/浩二
主任ITスペシャリスト。2000年、日本IBM入社、モデル駆動型開発による大規模アプリケーション構築プロジェクトに従事後、オブジェクト指向分析設計のためのIBM資産「GTAM」の開発を担当。2009年よりIBM Rational事業部に異動、現職(本データはこの書籍が刊行された当時に掲載されていたものです)
Kindle化リクエスト
このタイトルのKindle化をご希望の場合、こちらをクリックしてください。
Kindle をお持ちでない場合、こちらから購入いただけます。 Kindle 無料アプリのダウンロードはこちら。
このタイトルのKindle化をご希望の場合、こちらをクリックしてください。
Kindle をお持ちでない場合、こちらから購入いただけます。 Kindle 無料アプリのダウンロードはこちら。
登録情報
- 出版社 : 翔泳社 (2010/2/18)
- 発売日 : 2010/2/18
- 大型本 : 368ページ
- ISBN-10 : 4798120405
- ISBN-13 : 978-4798120409
- 寸法 : 18.5 x 2.5 x 23 cm
- Amazon 売れ筋ランキング: - 491,582位本 (の売れ筋ランキングを見る本)
- - 2,420位ソフトウェア開発・言語
- カスタマーレビュー:
この商品を買った人はこんな商品も買っています
ページ: 1 / 1 最初に戻るページ: 1 / 1
著者について
著者をフォローして、新作のアップデートや改善されたおすすめを入手してください。

著者の本をもっと発見したり、よく似た著者を見つけたり、著者のブログを読んだりしましょう
カスタマーレビュー
5つ星のうち4.1
星5つ中の4.1
7 件のグローバル評価
評価はどのように計算されますか?
全体的な星の評価と星ごとの割合の内訳を計算するために、単純な平均は使用されません。その代わり、レビューの日時がどれだけ新しいかや、レビューアーがAmazonで商品を購入したかどうかなどが考慮されます。また、レビューを分析して信頼性が検証されます。
トップレビュー
上位レビュー、対象国: 日本
レビューのフィルタリング中に問題が発生しました。後でもう一度試してください。
2010年3月6日に日本でレビュー済み
違反を報告する
Amazonで購入
11人のお客様がこれが役に立ったと考えています
役に立った
2010年6月29日に日本でレビュー済み
Amazonで購入
プロジェクトリーダー以上の方にお勧めの一冊です。
タイトルの「アジャイル開発の本質」という部分が、
第1部から第2部に相当します。
この部分だけでも読む価値はあります。
アジャイル開発をXP、スクラム、RUPの具体的なプラクティスで
解説してあり、違いや共通点が分かりやすかったです。
また、ウォーターフォールの間違えについても参考になりました。
タイトルの後半「スケールアップ」という部分が、
第3部に相当します。
アジャイルを企業に適用する解説です。
実際に行動するにはエネルギーが必要で難しい部分ですが、
面白かったのはアジャイルの計測で、評価するのに
レーダーチャートを用いているところは参考になりました。
サブタイトルの「14のベストプラクティス」で
「14」は何を指しているのか最後まで分かりませんでした。
タイトルの「アジャイル開発の本質」という部分が、
第1部から第2部に相当します。
この部分だけでも読む価値はあります。
アジャイル開発をXP、スクラム、RUPの具体的なプラクティスで
解説してあり、違いや共通点が分かりやすかったです。
また、ウォーターフォールの間違えについても参考になりました。
タイトルの後半「スケールアップ」という部分が、
第3部に相当します。
アジャイルを企業に適用する解説です。
実際に行動するにはエネルギーが必要で難しい部分ですが、
面白かったのはアジャイルの計測で、評価するのに
レーダーチャートを用いているところは参考になりました。
サブタイトルの「14のベストプラクティス」で
「14」は何を指しているのか最後まで分かりませんでした。
2010年3月23日に日本でレビュー済み
Amazonで購入
マイクロソフト Tech Fielders - Agile Day 2でこの本を知り、早速購入した。まだとばし読みであるが、新しい時代の到来を感じる。
自分はコンサルであるが、反復型と呼ばれる開発プロセスを、ユーザー企業の立場で推進し、反復型によるユーザー側のメリットも確認してきた。そのため、アジャイル開発が大規模システムで適用できるという考え方には全く違和感はない。しかし、XPやスクラムなど、具体的なプロセスのプラクティスには関わってこなかったため、それをアジャイル開発の経験と言って良いのかわからなかった。この本は、個々のプロセスの用語にとらわれることなく、アジャイルの本質的なメリットを理解してそれを引き出すことが大切と説く。この世界にアジャイルという統一的な言葉がうまれそうだ。ありがたいと思う。
アジャイル開発を大規模システムに適用することについては、アーキテクチャーの問題が気になっていた。システムの基本的な構造や仕組みを「後付け」で考えるプロセスでは、大規模開発において相当の不効率を生むことになると考えたからだ。
この点については、アジャイルプロセスそれぞれのスタンスがあるが、大規模システムへの適用については、アーキテクチャーが現れることを待つのではなく、意図的に作り出すことが必要だと書かれている。また、そのアーキテクチャーを作り出すチームや期間も必要であり、それをアーキテクチャー助走路と呼ぶということも書かれている。
アーキテクチャー助走路という概念が打ち出されていることで、今後の大規模におけるアーキテクチャーの事前検討の必要性とメリット、またそこに一定のコストが発生することを説明しやすくなった。これも、ありがたい。
目次にさっと目を通したところでは、この本は他にもじっくり読みたいところが満載で、しばらく楽しめそうだ。
自分はコンサルであるが、反復型と呼ばれる開発プロセスを、ユーザー企業の立場で推進し、反復型によるユーザー側のメリットも確認してきた。そのため、アジャイル開発が大規模システムで適用できるという考え方には全く違和感はない。しかし、XPやスクラムなど、具体的なプロセスのプラクティスには関わってこなかったため、それをアジャイル開発の経験と言って良いのかわからなかった。この本は、個々のプロセスの用語にとらわれることなく、アジャイルの本質的なメリットを理解してそれを引き出すことが大切と説く。この世界にアジャイルという統一的な言葉がうまれそうだ。ありがたいと思う。
アジャイル開発を大規模システムに適用することについては、アーキテクチャーの問題が気になっていた。システムの基本的な構造や仕組みを「後付け」で考えるプロセスでは、大規模開発において相当の不効率を生むことになると考えたからだ。
この点については、アジャイルプロセスそれぞれのスタンスがあるが、大規模システムへの適用については、アーキテクチャーが現れることを待つのではなく、意図的に作り出すことが必要だと書かれている。また、そのアーキテクチャーを作り出すチームや期間も必要であり、それをアーキテクチャー助走路と呼ぶということも書かれている。
アーキテクチャー助走路という概念が打ち出されていることで、今後の大規模におけるアーキテクチャーの事前検討の必要性とメリット、またそこに一定のコストが発生することを説明しやすくなった。これも、ありがたい。
目次にさっと目を通したところでは、この本は他にもじっくり読みたいところが満載で、しばらく楽しめそうだ。
2010年3月29日に日本でレビュー済み
Amazonで購入
大変面白く、一気に読んでしまいました。
XP、スクラム、RUP、それぞれ名前は聞いたことがあったのですが、良く理解していませんでした。この本を読んで、これらのメソッドに共通な本質は何か、が良くわかりました。また、それがどうやら大規模なエンタープライズシステムにも適用できそうなのだ、ということがわかってきました。
QCDという言葉があります。品質(Q)、コスト(C)、納期(D)を守らなければならない、という意味です。ものづくりにおいては、特に重要でしょう。しかしながら、QCDを計画するためには、生産活動が事前に予測可能であることが必要です。ソフトウェアの開発は本質的に、今までに無い新しいものを創り上げる活動であり、また顧客の要件も時間とともに変化していきます。ですので、ソフトウェア開発においては、QCDを事前に決めることはできない、という前提からアジャイルの考え方が始まっています。
一定のQCDを事前に決めることができないとなれば、Q、C、Dのいずれか(あるいは複数)にしわ寄せがよってきます。ソフトウェア開発ではどれも起きることです。納期が延びて、そのためにたくさんの人を投入して(コストオーバーラン)、なおかつ品質が保てない、などという話を良く聞きます。
アジャイル開発では、与えられたコストの範囲で納期は絶対守る、その代わり仕様には妥協する、というのが今までのウォーターフォール開発とは大きく異なるコンセプトです。コードの品質には妥協しないのですが、顧客要件については優先順位をつけて、実装できるものだけを期限までに実装する、という考え方です。同時に、常に変化する顧客要件に対応するため、非常に短い反復で動くソフトウェアを作り、顧客に見せてフィードバックをもらいます。
このアジャイルの考え方は、ソフトウェア開発だけでなく、企業における知的活動の様々な局面において応用できるように思います。たとえば、3か月で何かの報告書を作るタスクの場合、完成度は低くても全体像がわかるドラフトを毎週提出してフィードバックをもらう、などのやり方です。
また、チームの構成、コミュニケーションのやり方などは、一般のマネジメントにすぐにでも応用が効きそうです。ソフト開発も組織のマネジメントも結局は人、メンバーのエンパワメントが大事なのだ、と改めて認識させられる本でした。
XP、スクラム、RUP、それぞれ名前は聞いたことがあったのですが、良く理解していませんでした。この本を読んで、これらのメソッドに共通な本質は何か、が良くわかりました。また、それがどうやら大規模なエンタープライズシステムにも適用できそうなのだ、ということがわかってきました。
QCDという言葉があります。品質(Q)、コスト(C)、納期(D)を守らなければならない、という意味です。ものづくりにおいては、特に重要でしょう。しかしながら、QCDを計画するためには、生産活動が事前に予測可能であることが必要です。ソフトウェアの開発は本質的に、今までに無い新しいものを創り上げる活動であり、また顧客の要件も時間とともに変化していきます。ですので、ソフトウェア開発においては、QCDを事前に決めることはできない、という前提からアジャイルの考え方が始まっています。
一定のQCDを事前に決めることができないとなれば、Q、C、Dのいずれか(あるいは複数)にしわ寄せがよってきます。ソフトウェア開発ではどれも起きることです。納期が延びて、そのためにたくさんの人を投入して(コストオーバーラン)、なおかつ品質が保てない、などという話を良く聞きます。
アジャイル開発では、与えられたコストの範囲で納期は絶対守る、その代わり仕様には妥協する、というのが今までのウォーターフォール開発とは大きく異なるコンセプトです。コードの品質には妥協しないのですが、顧客要件については優先順位をつけて、実装できるものだけを期限までに実装する、という考え方です。同時に、常に変化する顧客要件に対応するため、非常に短い反復で動くソフトウェアを作り、顧客に見せてフィードバックをもらいます。
このアジャイルの考え方は、ソフトウェア開発だけでなく、企業における知的活動の様々な局面において応用できるように思います。たとえば、3か月で何かの報告書を作るタスクの場合、完成度は低くても全体像がわかるドラフトを毎週提出してフィードバックをもらう、などのやり方です。
また、チームの構成、コミュニケーションのやり方などは、一般のマネジメントにすぐにでも応用が効きそうです。ソフト開発も組織のマネジメントも結局は人、メンバーのエンパワメントが大事なのだ、と改めて認識させられる本でした。
2013年8月24日に日本でレビュー済み
Amazonで購入
参考になりました。
日本語の訳が少し、キツイですが、専門書の訳の本としては、いいほうだと思います。
おおらかな気持ちで読む必要があります。
日本語の訳が少し、キツイですが、専門書の訳の本としては、いいほうだと思います。
おおらかな気持ちで読む必要があります。