ばいちょ(売価調査)、価格比較とネットでのお買い物を楽に

[ご注意ください]
役割
ソフトウェア開発のスポンサーは，組織的，行動的，資金的構造が，開発チームから受け取る価値をどのように左右するかを，本書によって理解できる。
プロジェクトスポンサーは，プロジェクトに直接関わる人に比べて，方法論の細部に注意を払わないことが多い。
しかし，方法論決定の結果については理解すべきである。

チームリーダやプロジェクトマネージャは，座席，チーム編成，個性が，プロジェクトの結果をどのように左右するかを理解できる。
どのような介入がよい結果，あるいは悪い結果をもたらすかもわかる。
方法論の構成と結果を理解し，その改良方法を学習する必要があるだろう。
方法論をできるだけ軽量に，かつ有効にする方法である。

プロセスや方法論の作者は，本書の用語選択や方法論設計の原則を調べて議論すると，方法論の分野で有益だろう。

ソフトウェア開発者は，この内容が専門職の一部に過ぎないと知るはずだ。
新人からリーダになるにつれて，プロジェクトで役立つこと，役立たないことに気付くようにならなければいけない。
環境をより効果的にする方法も学習しなければいけない。
方法論とは，実際にはプロジェクトで従っている慣習のことである。
そのため，方法論を構成する基礎を理解することは，すべての職種における責任である。

本書の構成
本書は，最初にほとんど解答不可能な質問を設定し，最後までその質問に対する答を模索している。

コミュニケーションが根本的に不可能な場合，プロジェクトメンバはどのようにプロジェクトを管理するのか。

すべての人やすべてのプロジェクトが異なるとしたら，生産的なプロジェクト用のルールをどのように作成できるか。

このため，本書の一部を，ミステリー小説の「誰が犯人か」というスタイルで書いている。
まずは幅広い哲学的な議論，「コミュニケーションとは何か」「ソフトウェア開発とは何か」ということから始める。

このような議論は，まだかなり抽象度の高い，「人の性格とは何か」「チーム内のアイデアの移動は何に左右されるか」というトピックに進展する。

そして議論は「方法論の要素と原則は何か」という具体的なトピックに到達する。
これは，具体的な素材を真先に求めるなら，最初に読み始めるべきトピックだ。

議論は，最終的に「軽量で，充分で，自ら改善される方法論とはどのようなものか」「プロジェクトで期限内に成果を出すために，グループはどのようにして独自のアジャイル方法論を作り出すのか」という，具体的な問題に行き着く。

本文の内容をサポートする付録が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）の文章である。

アジャイルは動的で，コンテキスト固有で，積極的に変化を受け入れる，成長指向である。
猛烈な競争の嵐を乗り切るのは，効率の改善でも，コストの削減でも，ビジネスのハッチを板で密閉することでもない。
成功と勝利である。
それは，出現する競争のアリーナにおける成功，多くの会社が恐れる「競争の嵐」の中心にある収益，マーケットシェア，顧客の獲得である。

アジャイルソフトウェア開発シリーズ
ここ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)が，グループのテクニックについての書籍である。

成功したアジャイル方法論のサンプル。
ベースとなる方法論を選択する場合は，すでに似たような状況で成功している方法論を知りたいだろう。
既存の方法論の修正は，新しい方法論の作成より容易で，別の状況下で設計された方法論を使用するよりも効果的である。
クリスタルクリアは，サンプルとなる方法論の書籍である。
他にも多くのサンプルが発表されることを期待している。

商品の説明をすべて表示する