よく一緒に購入されている商品
商品の説明
[ご注意ください]
役割
ソフトウェア開発のスポンサーは，組織的，行動的，資金的構造が，開発チームから受け取る価値をどのように左右するかを，本書によって理解できる。プロジェクトスポンサーは，プロジェクトに直接関わる人に比べて，方法論の細部に注意を払わないことが多い。しかし，方法論決定の結果については理解すべきである。
チームリーダやプロジェクトマネージャは，座席，チーム編成，個性が，プロジェクトの結果をどのように左右するかを理解できる。どのような介入がよい結果，あるいは悪い結果をもたらすかもわかる。方法論の構成と結果を理解し，その改良方法を学習する必要があるだろう。方法論をできるだけ軽量に，かつ有効にする方法である。
プロセスや方法論の作者は，本書の用語選択や方法論設計の原則を調べて議論すると，方法論の分野で有益だろう。
ソフトウェア開発者は，この内容が専門職の一部に過ぎないと知るはずだ。新人からリーダになるにつれて，プロジェクトで役立つこと，役立たないことに気付くようにならなければいけない。環境をより効果的にする方法も学習しなければいけない。方法論とは，実際にはプロジェクトで従っている慣習のことである。そのため，方法論を構成する基礎を理解することは，すべての職種における責任である。
ソフトウェア開発のスポンサーは，組織的，行動的，資金的構造が，開発チームから受け取る価値をどのように左右するかを，本書によって理解できる。プロジェクトスポンサーは，プロジェクトに直接関わる人に比べて，方法論の細部に注意を払わないことが多い。しかし，方法論決定の結果については理解すべきである。
チームリーダやプロジェクトマネージャは，座席，チーム編成，個性が，プロジェクトの結果をどのように左右するかを理解できる。どのような介入がよい結果，あるいは悪い結果をもたらすかもわかる。方法論の構成と結果を理解し，その改良方法を学習する必要があるだろう。方法論をできるだけ軽量に，かつ有効にする方法である。
プロセスや方法論の作者は，本書の用語選択や方法論設計の原則を調べて議論すると，方法論の分野で有益だろう。
ソフトウェア開発者は，この内容が専門職の一部に過ぎないと知るはずだ。新人からリーダになるにつれて，プロジェクトで役立つこと，役立たないことに気付くようにならなければいけない。環境をより効果的にする方法も学習しなければいけない。方法論とは，実際にはプロジェクトで従っている慣習のことである。そのため，方法論を構成する基礎を理解することは，すべての職種における責任である。
本書の構成
本書は，最初にほとんど解答不可能な質問を設定し，最後までその質問に対する答を模索している。
コミュニケーションが根本的に不可能な場合，プロジェクトメンバはどのようにプロジェクトを管理するのか。
すべての人やすべてのプロジェクトが異なるとしたら，生産的なプロジェクト用のルールをどのように作成できるか。
このため，本書の一部を，ミステリー小説の「誰が犯人か」というスタイルで書いている。まずは幅広い哲学的な議論，「コミュニケーションとは何か」「ソフトウェア開発とは何か」ということから始める。
このような議論は，まだかなり抽象度の高い，「人の性格とは何か」「チーム内のアイデアの移動は何に左右されるか」というトピックに進展する。
そして議論は「方法論の要素と原則は何か」という具体的なトピックに到達する。これは，具体的な素材を真先に求めるなら，最初に読み始めるべきトピックだ。
議論は，最終的に「軽量で，充分で，自ら改善される方法論とはどのようなものか」「プロジェクトで期限内に成果を出すために，グループはどのようにして独自のアジャイル方法論を作り出すのか」という，具体的な問題に行き着く。
本文の内容をサポートする付録が2つある。1つ目の付録には「アジャイルソフトウェア開発宣言」を掲載する。この宣言には，多くの経験を積んだ17人のソフトウェア開発者と方法論者が署名している。
2つ目の付録には，3つの文献からの抜粋を掲載する。掲載する文献は，素晴らしい内容であるにもかかわらず，それほど広く読まれていない。本書で記述しているトピックの中心になっている文献なので，ここで収録した。
本書のアイデアの由来
本書のアイデアは，25年間の開発経験と10年間のプロジェクト調査に基づいている。 IBMのコンサルティンググループから，最初のオブジェクト指向方法論を設計するように依頼を受けたのは，1991年のことだった。当時，相互に矛盾する「方法論」の書籍をかなり懐疑的に見ていた。私と上司のKathy Ulisseは，プロジェクトチームから実際の仕事内容を聞くことにした。驚いたことに，彼らの言葉は書籍の中の言葉とまったく違っていた。
インタビューは今でも貴重で，成功事例を持つプロジェクトを訪れては，プロジェクトメンバが体験したこと，学習したこと，薦めることを調査している。インタビューの前に行う重要な質問は，「また同じ方法で仕事をしたいか」である。私の語彙にない言葉を用いて相手が経験を語った場合は，その経験が，私が区別や言葉を知らない，新しい領域における経験であることを示している。
本書を出版した理由は，結局，言葉や区別が，プロジェクトの存在や結果の記述に相関するからである。言葉や区別は，診断や介入を行う際，これまでに使用したどのツールよりも貴重だった。
本書内のアイデアは，数十の開発チーム，8つの方法論設計，関与したいくつかの成功プロジェクトから得たものである。
[ご注意ください]
アジャイル
私だけがアジャイルな考え方をしているわけではない。
Kent BeckとWard Cunninghamは，1980年代後半から1990年代後半にかけて，XP（エクストリームプログラミング）と呼ばれる方法論に取り組んでいる。
Jim Highsmithは，90年代中頃に複雑で適応可能なシステムの言語とビジネスでの使用を研究し，その言語のソフトウェア開発への応用をAdaptive Software Developmentという書籍に著した。
Ken SchwaberとJeff Sutherlandは，ほぼ同時期にスクラム（Scrum）開発方法論を構築していた。そして同じ頃，多くのプロジェクトリーダが似たようなアイデアを記述するという，似たような試みをしていた。
2001年2月に会議を開き，お互いの相違点と類似点を議論してみると，意外に共通点が多かった。私たちの意図を表す言葉としてアジャイル（agile）という言葉を選択し，アジャイルソフトウェア開発宣言を発表した（付録A）。
私たちは共有の原則を形式化する作業を続けている。会議の存在を知らなかった，またはスケジュールが合わなかったため2001年2月の会議には出席できなかった人たちの中にも，私たちと同じ考えを持つ人が多くいることもわかった。
アジャイルソフトウェア開発の中心は，軽量だが充分なプロジェクト活動のルールを使用することである。そのルールは人指向，コミュニケーション指向である。
アジャイルとは機動的ということである。機動的であることは，以前よりも重要になっている。Webにソフトウェアを配置することで，ソフトウェアの競争は以前よりも激しくなっている。ビジネス上の要求には，ソフトウェアを出荷し欠陥を減らすことだけでなく，ユーザと市場の要求を常に追跡することも含まれるようになっている。ビジネス上の勝利は，ソフトウェア開発ゲームの勝敗に依存する度合いが強まっている。ソフトウェア開発ゲームにおける勝敗のカギは，そのゲームの方法を理解することにすべてがかかっている。
ビジネスにおけるアジャイルを一番よく表現しているのは，以下に挙げるGoldman（1997）の文章である。
アジャイルは動的で，コンテキスト固有で，積極的に変化を受け入れる，成長指向である。猛烈な競争の嵐を乗り切るのは，効率の改善でも，コストの削減でも，ビジネスのハッチを板で密閉することでもない。成功と勝利である。それは，出現する競争のアリーナにおける成功，多くの会社が恐れる「競争の嵐」の中心にある収益，マーケットシェア，顧客の獲得である。
私だけがアジャイルな考え方をしているわけではない。
Kent BeckとWard Cunninghamは，1980年代後半から1990年代後半にかけて，XP（エクストリームプログラミング）と呼ばれる方法論に取り組んでいる。
Jim Highsmithは，90年代中頃に複雑で適応可能なシステムの言語とビジネスでの使用を研究し，その言語のソフトウェア開発への応用をAdaptive Software Developmentという書籍に著した。
Ken SchwaberとJeff Sutherlandは，ほぼ同時期にスクラム（Scrum）開発方法論を構築していた。そして同じ頃，多くのプロジェクトリーダが似たようなアイデアを記述するという，似たような試みをしていた。
2001年2月に会議を開き，お互いの相違点と類似点を議論してみると，意外に共通点が多かった。私たちの意図を表す言葉としてアジャイル（agile）という言葉を選択し，アジャイルソフトウェア開発宣言を発表した（付録A）。
私たちは共有の原則を形式化する作業を続けている。会議の存在を知らなかった，またはスケジュールが合わなかったため2001年2月の会議には出席できなかった人たちの中にも，私たちと同じ考えを持つ人が多くいることもわかった。
アジャイルソフトウェア開発の中心は，軽量だが充分なプロジェクト活動のルールを使用することである。そのルールは人指向，コミュニケーション指向である。
アジャイルとは機動的ということである。機動的であることは，以前よりも重要になっている。Webにソフトウェアを配置することで，ソフトウェアの競争は以前よりも激しくなっている。ビジネス上の要求には，ソフトウェアを出荷し欠陥を減らすことだけでなく，ユーザと市場の要求を常に追跡することも含まれるようになっている。ビジネス上の勝利は，ソフトウェア開発ゲームの勝敗に依存する度合いが強まっている。ソフトウェア開発ゲームにおける勝敗のカギは，そのゲームの方法を理解することにすべてがかかっている。
ビジネスにおけるアジャイルを一番よく表現しているのは，以下に挙げるGoldman（1997）の文章である。
アジャイルは動的で，コンテキスト固有で，積極的に変化を受け入れる，成長指向である。猛烈な競争の嵐を乗り切るのは，効率の改善でも，コストの削減でも，ビジネスのハッチを板で密閉することでもない。成功と勝利である。それは，出現する競争のアリーナにおける成功，多くの会社が恐れる「競争の嵐」の中心にある収益，マーケットシェア，顧客の獲得である。
アジャイルソフトウェア開発シリーズ
ここ10年間，ソフトウェア開発におけるアジャイルに関わってきた人の中で，Jim Highsmithと私は多くの共通点を見出した。そこで，2人で力を合わせて，比較的軽量，効果的かつ人間中心のソフトウェア開発テクニックに基づいた，「アジャイルソフトウェア開発シリーズ」を出版することにした。
このシリーズは以下の2原則に基づいている。
プロジェクトによって，必要なプロセスや方法論は異なる。
プロセスよりもスキル，コミュニケーション，コミュニティに注目することで，プロジェクトはより効率的かつアジャイルになる。
このシリーズは，以下の3つのトラックに分類される。
特定の仕事を行う人の効率を改善するテクニック。その仕事はユーザインタフェース設計，要件収集，プロジェクト計画，設計，テストなどである。このような仕事に携わる人なら誰でも，その仕事に向いているタイプの人を知りたいだろう。Writing Effective Use Cases（Cockburn 2001c，邦訳：『ユースケース実践ガイド 効果的なユースケースの書き方』2001）とGUIs with Glueは，個人のテクニックについて書かれた書籍である。
グループの効率を改善するテクニック。これにはチーム編成，プロジェクト回顧，意思決定などのテクニックが含まれる。具体的には，Improving Software Organizations（Mathiassen 2002）とSurviving Object-Oriented Projects（Cockburn 1998)が，グループのテクニックについての書籍である。
成功したアジャイル方法論のサンプル。ベースとなる方法論を選択する場合は，すでに似たような状況で成功している方法論を知りたいだろう。既存の方法論の修正は，新しい方法論の作成より容易で，別の状況下で設計された方法論を使用するよりも効果的である。クリスタルクリアは，サンプルとなる方法論の書籍である。他にも多くのサンプルが発表されることを期待している。
登録情報
|
この商品を見た後に買っているのは？
カスタマーレビュー
最も参考になったカスタマーレビュー
39 人中、32人の方が、｢このレビューが参考になった｣と投票しています。
形式:単行本
ピーター・コードは昨年のJavaOneのBoFで、開発プロセスを不断にみがいていくことが重要と言っていた。では、何か教科書を選んで、開発手法を採り入れて、その教科書への忠実さを徐々にあげていけば良いのだろうか?しかし、ここで少し冷静になってみると、教科書に忠実なプロセス＝磨きのかかったプロセスという論理には無理があることに気づく。二の間には様々な要因があり、ケースバイケースというのが実状ではないだろうか。アジャイルソフトウェア開発では教科書的な視点より、「みがきをかける」ために必要な視点を提供することが重視されている。そのため、教科書本やHow to本のように、一度読んで、その後は辞書的に使うといった類の本ではない。何度も時間があれば読み返し、自分の現状と照らし合わせ、考えるための本だと思う。そのためカルい気持ちで読むよりは、しっとり読みたい。開発に携わる人間なら、その価値は充分にある。最後に急いで訳出したためだろうか、「ユニーク」でよいところをあえて「愉快な」と訳してみたり、利己的な遺伝子で知られるドーキンスの「ミーム」を「メメ」(太文字強調付き)と訳していたりする。コーバーンの引用は実に幅広い分野から取られており、訳出するのは大変だとは思う。しかし、日本語訳が良ければ、5つ星に相当する射程を持っていることは間違いない。シリーズの今後の訳には期待したい。
8 人中、7人の方が、｢このレビューが参考になった｣と投票しています。
形式:単行本
「方法論」って何か？という根本的な問題から始まり、方法論を考えるための視点、そして活用しよう！という内容がメインだと思います。
方法論と言えば、手順（プロセス）、成果物というキーワードで語るもの、と思ってましたが、この本で目が覚めました。
方法論と言えば、手順（プロセス）、成果物というキーワードで語るもの、と思ってましたが、この本で目が覚めました。
今まで、ＸＰとかアジャイル等の本を読んでも、「ピンとこない」ことが多かったんですが、この本を読んで、その原因がわかりました。方法論の捉えかたが違ったんでした。ＸＰやアジャイルの根本にある考え方が、わかった気がします。
結構、読むのにパワーがいりましたが、その分の価値を得られた本でした。
実際、この本を読んだから、「方法論が身につく」ことは、ないかもしれませんが、今後の情報システム開発を行う上では、役に立つ考えかた、視点が身についた気がします。
形式:単行本
→アジャイルという開発方法論を
発想の原点から実践例まで説明してくれます
５Ｗ１Ｈを余すことなく．．
→すなわち、ソフトウェア開発というものは
そもそもどういった人たちが（ＷＨＯ）
どんな時間的制限下で（ＷＨＥＮ）
どんな環境で（ＷＨＥＲＥ）
どんなソフトウェアを（ＷＨＡＴ）作るのか
．．そして、それをうまくやるためには
どうやったらいいのか（ＨＯＷ）
それはなぜか（ＷＨＹ）．．
→この本の中で著者は、
対象とする開発量の大きさを
「軽量級」と「重量級」という言葉を使い
それぞれに対応する方法論を提示してくれています
その分析の明快なこと 明快なこと！
→さらには、
ソフトウェア開発が人で行われているということをふまえ
その「人の行動特性」、特に「失敗する」ということに
着目した分析は見事！
「間違える」「保守的な失敗を好む」「調べるよりも作る」
「習慣の生物である」「一貫していない」
の５つの解説は、忘れがちな人間の行動を本質から捉えており
秀逸です！
→付録で
剣豪、武蔵の論文が紹介されています
また、この解説がすばらしい！
時間がない方は、ここだけでも！
発想の原点から実践例まで説明してくれます
５Ｗ１Ｈを余すことなく．．
→すなわち、ソフトウェア開発というものは
そもそもどういった人たちが（ＷＨＯ）
どんな時間的制限下で（ＷＨＥＮ）
どんな環境で（ＷＨＥＲＥ）
どんなソフトウェアを（ＷＨＡＴ）作るのか
．．そして、それをうまくやるためには
どうやったらいいのか（ＨＯＷ）
それはなぜか（ＷＨＹ）．．
→この本の中で著者は、
対象とする開発量の大きさを
「軽量級」と「重量級」という言葉を使い
それぞれに対応する方法論を提示してくれています
その分析の明快なこと 明快なこと！
→さらには、
ソフトウェア開発が人で行われているということをふまえ
その「人の行動特性」、特に「失敗する」ということに
着目した分析は見事！
「間違える」「保守的な失敗を好む」「調べるよりも作る」
「習慣の生物である」「一貫していない」
の５つの解説は、忘れがちな人間の行動を本質から捉えており
秀逸です！
→付録で
剣豪、武蔵の論文が紹介されています
また、この解説がすばらしい！
時間がない方は、ここだけでも！
リストマニア
|
|
同じキーワードの商品を探す
フィードバック
- カタログ情報、または画像について報告
- 著者からのコメント
- 出版社からのコメント
|
