Comments
Description
Transcript
第 14 章 アジャイルソフトウェア開発
第 14 章 アジャイル・ソフトウェア開発 第 14 章 アジャイル・ソフトウェア開発 ソフトウェア開発の 2 つの方法 端的に言って、ソフトウェア開発には 2 つの方法がある。正統的な開発方法と、軽量の開発 方法である。 正統的な方法では、まずしっかりと作業全体の計画を立て、その計画通りに作業が進捗して いるかどうかを常に管理し、必要で充分なドキュメント類を作成し、レビューし、開発したソ フトウェアをいろんな角度からテストし、というような形でソフトウェアを開発する。その考 え方の背景には「開発のための CMMI（当初は SW-CMM） 」1があり、プロジェクトの管理の 方法は PMBOK2に則り、開発手順としてはウォータフォール型3が使われることが多かった。 この方法で開発される場合、開発に成功すればソフトウェアは的確に稼働することが期待で きる。メンテナンスへの対応も、充分に配慮されている。しかしこのような開発にはワークロ ードが多くかかり、開発に要する時間と費用が少なくないという欠点がある。 正統的な方法でのこの問題を解決するために、もう 1 つの開発方法が提案されて続けてきた。 「軽量のソフトウェア開発方法」である。軽量の開発方法では、正統的な開発方法のある部分 を割愛し、作業の流れを変更し、ユーザからのフィードバックを早め、開発に関わる時間とワ ークロードを少なくすることを意図している。 この章では、この軽量の開発方法について述べる。最近広がっているアジャイル・ソフトウ ェア開発は、この軽量開発法の 1 つである。 軽量の開発方法についての経緯 正統的な開発方法によるソフトウェアの開発は、ソフトウェアの開発が始まった 1950 年代 まで遡ることができる。もちろんその間、いくつかの変遷はあり続けた。その一方で軽量の開 発方法は、その考え方や開発の方法などが時代と共に大きく変化してきた。 最初に提案されたこの方法での開発は、1970 年代前半の「チーフ・プログラマ・チーム」 [BAK73]と呼ばれるものだった。 その後 1990 年代前半に、 ジェームズ・マーチン （James Martin） が「RAD [MART91] 」を提案した。 1988 年にバリー・ベーム（Barry W. Boehm）が、スパイラル型開発手順についてのペーパ を書いた4[BEO88]。これはそれ以前から米国などで行われていたソフトウェアの開発方法を論 文にまとめたものと推測されるが、この考え方をベースにして多くのアジャイル・ソフトウェ ア開発の手順が提案された。 その代表選手としての 「エクストリーム・プログラミング」 [BEC00] が 2000 年にケント・ベック（Kent Beck）から、 「適応型ソフトウェア開発」が同じく 2000 年 にジム・ハイスミスから、「クリスタル開発」[COC02]が 2002 年にアリスター・コバーン （Alistair Cockburn）から、それぞれ提案されている。 そして 2001 年 2 月に、米国ユタ州のスキー・リゾート地にアジャイル・ソフトウェア開発 を提唱していた 17 人が集まって協議し、 「アジャイル・ソフトウェア開発宣言」と「アジャイ ル・ソフトウェア開発の原則」が採択された[COC02]。この「アジャイル・ソフトウェア開発 1 2 3 4 「開発のための CMM」と SW-CMMI については、第 40 章で述べる。 PMBOK については、第 50 章で述べる。 ウォータフォール型の開発手順については、第 13 章で述べた。 スパイラル開発手順についても、第 13 章で述べた。 139 第 14 章 アジャイル・ソフトウェア開発 の原則」は、この章末に付 1 として添付する。 以下で、この軽量開発法の概要を記してみたい。 チーフ・プログラマ・チーム チーフ・プログラマ・チーム[BAK73]は、1970 年代に IBM で提唱され、実践された開発方 法である。 ここでは「チーフ・プログラマ」と呼ばれるスーパーSE が中心となって、１人以上のバック アップ・プログラマと、チーフ・プログラマの秘書（Secretary） 、さらに必要に応じてそれ以 外の、例えばデータベースやネットワークなどのスペシャリストなどから構成される。 チーフ・プログラマは単なるプログラマではなく、システム・アナリスト、システム設計者、 プロジェクト管理者など、このチーム内で多くの立場を兼ねることになる。技術者としてだけ ではなく、管理者の役割も演じるところに留意したい。端的に言えばチーフ・プログラマ・チ ームは、ソフトウェアの開発のためにこのスーパーSE であるチーフ・プログラマの技術を 100％引き出すために存在している。したがってバックアップ・プログラマや秘書の役割はチ ーフ・プログラマのために必要な仕事を積極的に引き受け、スーパーSE がソフトウェア開発 に集中できるようにすることである。 図表 14-1 チーフ・プログラマ・チームの技術的背景（[BAK73]より） これが提案されたのは、構造化技法5が提唱された直後だった。したがってチーフ・プログラ マ・チームを支える技術的背景は図表 14-1 に示すように、構造化技法の特徴であるトップダウ ン開発と構造化プログラミングだった。図表 14-1 の最下段にある開発支援ライブラリはテス トデータなどのライブラリであって、 最近議論されている再利用のためのライブラリではない。 チーフ・プログラマ・チームはニューヨーク・タイムズ社の情報バンク構築のプロジェクト 5 構造化技法については、次の第 15 章で述べる。 140 第 14 章 アジャイル・ソフトウェア開発 に適用され、成功を収めたことで名高い。 チーフ・プログラマ・チームは、ある表現の仕方をすればチーフ・プログラマ独裁の組織で ある。その対極に位置する民主的な方式がエクストリーム・プログラム（XP）であるといえる。 ワインバーグが唱えた「エゴレス・プログラミング」も、この XP と基本的には同じ方式をベ ースにしている[WEI71]。 RAD 1990 年代前半には、ジェームズ・マーチンが RAD（Rapid Application Development）を提 案した[MART91]。 RAD とは、ちょうどその直前にやはりジェームズ・マーチンが提案したデータ中心アプロー チ6（米国流の呼び方では「インフォメーション・エンジニアリング」 ）を全面的に採用して、 開発に従事する人たちには事前に充分な訓練を行い、ツール類を充実させて、それらを駆使し てソフトウェアを迅速に、短期間で開発しようとするものだった。 狙いはたいへんに素晴らしく、この通りに実践すれば大きな成果を挙げ得たものと私は考え る。しかし日本では 1990 年代前半に、技術のことが分からないソフトウェア会社の経営者や 管理者などの間でこの言葉が大流行し、RAD の前提としての訓練やツール類の整備が全くな されないまま、 「高い技術力を持った技術者なら、短期でソフトウェアの開発ができるはず」と いう甘い言葉を、どちらかといえばあまり技術力が高くない技術者に語ってその自尊心をくす ぐり、結果として多量の低品質のソフトウェアを量産させたことがあった。 軽量の開発法は粗悪なソフトウェアの開発法とは全く異なるものであるということを、この 章の最後に述べる。しかし RAD についてのこの事実を、我々の反面教師としてしっかりと記 憶しておきたい。 アジャイルソフトウェア開発宣言 2001 年 2 月に、アジャイルソフトウェア開発宣言が採択された[COC02]。これは前述のよう に、それ以前から軽量のソフトウェア開発手法を提唱していた 17 人が米国ユタ州のスキーの リゾート地に集まって、それぞれの人が提唱している軽量のソフトウェア開発方法の共通点は 何か、お互いの意見の相違は認め合うことができるものか、というようなことを議論し、最終 的に合意に達して作成されたものである。この宣言そのものは非常に簡単で、以下の 4 行で表 されている。 プロセスやツールより人と人同士の相互作用を重視する。 包括的なドキュメントより動作するソフトウェアを重視する。 契約上の交渉よりも顧客との協調を重視する。 計画に従うことよりも変化に対応することを重視する。 （http://www.t-doi.org/agile/index.html より） この 17 人には、ケント・ベック、ジム・ハイスミス、アリスター・コバーンの他に、C 言語 の教科書の著者としても名高いワード・カミンガムなどが含まれている。 この宣言採択を機会に、それまで単に「軽量の」開発方法といわれていたものが「アジャイ ル・ソフトウェア開発」と呼ばれるようになった。 世界で最も多くのソフトウェアを必要としているのはアメリカの国防総省だと私は考えるが、 6 データ中心アプローチについては、第 16 章で述べる。 141 第 14 章 アジャイル・ソフトウェア開発 そのアメリカの国防総省は発注したソフトウェアの納品で、多大な文書（ドキュメント)を要求 する。さらに、その開発手順はたいへん厳格である。誰もそうはいわないけれど、このアジャ イル・ソフトウェア開発宣言はアメリカ国防総省の開発標準へのアンティテーゼであるように、 私には見える。 アジャイル・ソフトウェア開発の特徴 前述の通り、アジャイル・ソフトウェア開発宣言は 17 人の方法論の提唱者が集まって採択さ れたものである。それぞれの人のソフトウェア開発についての考え方が違うため、アジャイル・ ソフトウェア開発は最低でも 17 種類の方法があるということになる。その共通するものは、 宣言の中で謳われている 4 項目に集約されている。 このアジャイル・ソフトウェア開発の特徴として、グレーグ・ラーマンは次のように述べて いる[LAR04]。 インクリメンタル（スパイラル）な、反復型の開発手順で開発を行う。この中で、テ ストを特に重視する。 事前に作業全体の詳細な計画を立てたり、全体の仕様を決めたりはしない。今回開 発する部分（1 回のスパイラル）だけの計画を立て、仕様を決めて開発を始める。 所定の開発期間（これを「タイム・ボックス」と呼ぶ）で 1 回のスパイラルを完了 させる。スケジュール遅れが発生しそうになると開発期間（つまりタイムボックス） を延長するのではなく、開発量を削減することでスケジュール遅れを解消する。 1 回のスパイラルの開発の終わりには、原則としてその間に開発したソフトウェア をユーザに提供する。 このインクリメンタルな開発手順は前述の通り、バリー・ベームが提唱したスパイラル型開 発手順がベースになっている[LAR04]。 このアジャイル・ソフトウェア開発宣言の 17 人には入っていないけれど、アジャイルなソフ トウェア開発を実践する上でのポイントをまとめたメアリー・ポッペンディークとトム・ポッ ペンディークの著書から[POP03]、そのポイントを紹介したい。 彼女たちは、新しい製品をどんどん開発することで名高い米国の 3M 社で長く働いていたと いう経験を持ち、トヨタをはじめとする自動車産業の進んだ自動車の作り方を学んで、それを ソフトウェア開発に適用して「リーン開発」と呼んだ。 彼女たちによると、アジャイルなソフトウェア開発のポイントは、次の 7 つであるという [POP03]。 (1)．無駄を排除する。 (2)．学習効果を高める。 (3)．決定をできるだけ遅らせる。 (4)．できるだけ早く提供する。 (5)．チームに権限を与える。 (6)．統一性を作り込む。 (7)．全体を見る。 この「無駄の排除」について、ソフトウェアの設計を行った時にその設計内容を文書に書い て次の作業を行う他の人に引き継ぐのは「無駄」であると、彼女たちはいう。設計者が考えた ことはほとんど設計者の頭の中に残ったままで、文書上に表されるものは少ない。だからここ 142 第 14 章 アジャイル・ソフトウェア開発 では人を変えずに、設計者がそのまま次の行程も担当するのが無駄のない、一番良い方法だと 彼女たちはいう[POP03]。つまり軽量の開発方法は、正統的な開発方法と真っ向から違う考え 方とアプローチをとっている。 ただし彼女たちは、次の点に充分に注意するよう指摘している[POP03]。 無駄を排除することは、全部のドキュメントを捨てることではない。 学習効果を高めることは、決心を変え続けることではない。 決定をできるだけ遅らせることは、決定を先延ばしすることではない。 できるだけ早く提供することは、あせってずさんな仕事をすることではない。 チームに権限を与えることは、リーダシップを取らないということではない。 統一性を作り込むということは、大規模な先行設計をすることではない。 全体を見ることは、詳細を無視することではない。 他のところでも述べるが、アジャイルなソフトウェア開発を行うには、ソフトウェア技術者 として正統的な開発を行う場合以上にモチベーションを高く保ち、自律的に考えて行動し、結 果にしっかりと責任を取ることが必要になる。これはソフトウェア技術者にとって、容易なこ とではない。 エクストリーム・プログラミング エクストリーム・プログラミング（Extreme Programming。以下では、XP と略記する）と は、2000 年にケント・ベックがその著書[BEC00]で提唱した一種のアジャイル・ソフトウェア 開発の方法である。これは、次のような特徴を持っている[BEC00]。 シンプルな設計 「分かりやすさ」を最重要視。 テスト重視 共同所有 全ての設計物とプログラムは、そのプロジェクトのメンバー全てが共有する。 リファクタリング 共同所有されている設計とプログラミングは、いつ、誰が手を加えても良い（再 作成を含む） 。 ペア・プログラミング プログラマは、何をするときも二人一組で共同作業を行う。 継続した結合 一日に何度もビルドを繰り返し、新規に作成したり修正したプログラムは、その 日の中に可能な限り完全にテストを行う。 週 40 時間労働 厳重なコーディング規約 プログラムの共同所有とリファクタリングを実現するため。 この中での一番大きな特徴は、ペア・プログラミングだろう。これは前述のように、プログ ラマは仕事をする時は常に 2 人で一緒に仕事をすることを意味している。例えば 1 人がコンピ ュータを使ってプログラミングしている時、別の 1 人は隣でそのプログラムをチェック（レビ ュー）している、ということがあり得る。あるいは、そのプログラムをテストするためのテス トシナリオを考え、テストデータを作成している、という場合もある。常に 2 人で仕事をする 143 第 14 章 アジャイル・ソフトウェア開発 ことで、全体としての生産性は落ちるかもしれないけれど、品質の向上を期待することができ る。これがペア・プログラミングの目的である。 ただしこのペアは、恒久的なものではない。例えば今日の午前中は、A さんは B さんとペア を組んでいたけれど、午後は B さんとのペアを解消して C さんとペアを組んでいる、というこ とがあり得る。 共同所有とリファクタリングも、XP の大きな特徴である。プログラムを含む全てのドキュメ ントは、チーム全体で共同所有されている。だから誰かが今の成果物は分かりにくい、良くな いと考えれば、いつ、誰が、それに手を加えても良い。手を加えるだけでなく、他の部分に影 響を及ぼさないようにして、全く作り直してもかまわない。これがリファクタリングの意味す るところである。 「当初作った時の成果物の品質は、必ずしもよくないかもしれない。それを複 数の人の目でチェックすることで、その品質を良くすることができる」というのが、リファク タリングのベースにある考え方である。これは、ワインバーグが昔「エゴレス・プログラミン グ」と呼んだものと同じ考え方である[WEI71]。 「週 40 時間労働」というのも、おもしろい。長い間厳しい労働環境の下で仕事を続けること は生産性の面からも製品の品質の面からも決して良くないという我々の常識を、このような形 で表したものである。 ケント・ベックは、次のような状況の下で XP はうまく機能すると書いている[BEC00]。 10 人ぐらいまでのチーム 成果物としての文書を（あまり）要求しない組織 ユーザが常時プログラマなどと行動を共にできる組織 クリスタル開発 アリスター・コバーンは、アジャイル・ソフトウェア開発の一環としてクリスタル開発を提 唱している[COC02]。この考え方を、図表 14-2 に示す。 図表 14-2 クリスタル開発（[COC02]より） クリスタル開発の趣旨は、開発しようとするソフトウェアの性格や開発に参画する技術者の 144 第 14 章 アジャイル・ソフトウェア開発 数で、その開発の手順や方法が異なるべきとするところにある[COC02]。具体的には、次の通 りである。 図表 14-2 の縦軸は、そのソフトウェアがうまく稼働しない場合に失われるものを重要さの順 に示している。最もシビアなケースでは、 「人の命」が失われる。以下順次重要度が下がるにつ れて、失われるものが「貴重な資金」 、 「自由裁量の資金」 、 「快適さ」と変わってくる。このよ うに縦軸は、4 つの区分に分けられている。 横軸は、開発に参画する技術者の人数である。最も小さなところは 6 人まで。以下 20 人、40 人、100 人、200 人、500 人にそれぞれ上限を設け、全部で 6 つの区分に分けられている。し たがって 1 つの表は、全部で 24 の区分に分けられることになる。 さらにこの表が、2 枚用意されている。1 枚の表は「法的責任」を優先する場合のもの、もう 1 枚は「生産性と寛容度」を優先する場合のものである。 したがってクリスタル開発では全部で 48 の開発手順をあらかじめ用意しておき、そのソフ トウェアの重要性や開発に参画する技術者の数などを考慮して、そのうちで最も適切なものを 選ぶという考え方を取っている。この考え方は、非常に合理的なものと私は評価する。ただし、 既にアリスター・コバーンがこの 48 個全部の開発方法の定義を既に終わらせているわけでは ない。 いずれの方法をとっても、正統的な開発方法と比較して作業のある部分が割愛されて、程度 の差はあれそれぞれに軽量化を実現していることに留意したい。この中の一番厳格な開発手順 である「法的責任を優先する L500」は、あるいは正統的な開発手順と同じようなものものにな るだろう。 このように見ると前述の XP は、図表 14-2 で「生産性と寛容度を優先させる」C6、D6、E6、 あるいは C20、D20、および E20 として表されているものということになるのかもしれない。 アジャイルか正統的な開発か それでは我々は、アジャイルなソフトウェア開発と正統的なソフトウェア開発のどちらを採 用するのが良いのだろうか。これについては、バリー・ベームらが１つの見解を明らかにして いる[BOE04]。彼らの意見は、次の通りである。 アジャイルには、それが適したソフトウェアの種類や規模がある。例えば XP については、 前述の通りケント・ベック自身がそれにふさわしい開発環境や規模について述べている。一方 で PMBOK を適用したり、 「開発のための CMMI」に則るような正統的な開発についても、そ れが適した規模やソフトウェアの種類がある。 だから、それぞれが本当に適した領域や規模では、それが適している方法で開発するのがよ い。この 2 つが、直線上に連続して配置される一連の開発手順の両端に位置している。つまり その両者の中間に、無数の規模や領域がある。だからこの中間に位置するソフトウェアを開発 する場合には、両者の方法を折衷するのが良いとする。 これは、ISO／IEC 12207：2008[JIS12a]や「共通フレーム 2013[IPA13]」でいう「修整プロ セス」の適用を意味している。しかしこの「修整」を適切に適用することは、一般にたいへん に難しい。今の場合、アジャイルと正統的な開発方法についての詳細をよく理解し、両者の強 みと弱みを充分に把握した上でないと、適切な修整を行うことはできない。またその「修整」 の結果を実際の開発の現場に適用するためには、強いリーダシップも必要になる。 これからのソフトウェア技術者はこのような高度な知識と技術力、判断力を持ち、適切にリ 145 第 14 章 アジャイル・ソフトウェア開発 ーダシップを発揮して、ソフトウェア開発を成功に導くことが期待されている。 アジャイルな開発法はカウボーイ開発とは違う 世の中には、エドワード・ヨードンがいう「カウボーイ開発」がある。この場合のカウボー イとは、アメリカの開拓時代の西部劇に登場する無法者を意味している。プログラマには女性 もいるため、カウボーイをもじった「カウガール」という言葉もある。無法者ではないまっと うなカウボーイには失礼な言葉と思うが、 ここではしばらくお許しを頂きたい。 このことから、 「カウボーイ開発」 、または「カウガール開発」とは、管理も計画もない、規約もルールもない、 野放図な開発の仕方を意味している。 ソフトウェア技術者は、管理されることが嫌いである。自由奔放に、のびのびとソフトウェ アを開発できることが、彼らの望みである7。だから彼らは一般に、正統的な開発方法があまり 好きではない。 それではアジャイルの開発方法は、彼らが好きな開発方式であるのかという疑問が出てくる。 結論をいうと、それは人それぞれで違うかもしれない。 しかし、ここで 1 つ明らかにしておかなければならないことがある。それは、アジャイルな 開発方法はカウボーイ開発とは全く異なるものであるということである。例えば XP では、リ ファクタリングを行うためにたいへん厳格なコーディング規約を定め、それにチームメンバー 全員が従うことが求められる。もしこの規約を破った場合には、そのプログラムはリファクタ リングの対象になり、すぐに誰かに書き換えられてしまうだろう。あるいはペアを組んでいる もう 1 人のプログラマが、作成段階で強烈なクレームを付けるかもしれない。 正統的な開発方法をとっている場合には、プロジェクトのメンバーであるソフトウェア技術 者の管理は、プロジェクト・マネージャが行う。それでは XP では、誰がその管理を行うのか。 ケント・ベックは、それについて明確には書いていない。XP での作業のやり方を指導するため の「コーチ」と呼ばれる人が、チームにいることがある。このコーチが、あるいは他の人が、 チームの中で管理者的な役割を果たすのかもしれない。 しかし彼が書いたものをじっくりと読んでみるとそのような場合はむしろまれで、ソフトウ ェア技術者自身が自律的、自主的にスケジュールを守り、品質に責任を持たなければならない ように思える。これは他の誰かに管理されているよりも、ソフトウェア技術者としてはるかに 厳しい状況であると私は考える。 いずれにしろ、アジャイル開発はカウボーイ開発ではないし、そうであってはならない。 アジャイル開発は高くつく アジャイル開発はこれまで述べたように、 開発方式としていろいろと優れた点を持っている。 しかしその開発のコストは、ウォータフォール型と比較すると高いものになるようである。 まだ日本ではアジャイルの開発経験が少ないので、必要なだけ充分なデータを集めることが できない。しかしこれまで日本情報システム・ユーザー協会が集めて分析したデータから推測 すると、アジャイル開発はウォータフォール型開発に比べて 2 割程度高くなるようである [JUAS13a]。 キーワード 7 ソフトウェア技術者の特質については、第 42 章で述べる。 146 第 14 章 アジャイル・ソフトウェア開発 アジャイル・ソフトウェア開発、アジャイルソフトウェア開発宣言、チーフ・プログラマ・ チーム、RAD、エクストリーム・プログラミング、XP、リファクタリング、ペア・プログラ ミング、クリスタル開発、修整プロセス、カウボーイ開発 略語 RAD：Rapid Application Development XP：Extreme Programming 人名 ジェームズ・マーチン（James Martin） 、ケント・ベック（Kent Beck） 、アリスター・コバ ーン（Alistair Cockburn） 、バリー・ベーム（Barry W. Boehm） 、ジェラルド M．ワインバ ーグ（Gerald M. Weinberg） 規格 ISO／IEC 12207：2008、共通フレーム 2013 参考文献とリンク先 [BAK73] F. T. Baker, H. D. Mills, “Chief Programmer Team,” Datamation, Vol.19, No. 12, (December 1973), pp58-61. このペーパは、ACM のデジタル・ライブラリ（http://portal.acm.org/portal.cfm）からダ ウンロードすることができる。 （ただし、ACM のメンバーであることが必要。 ） [BEC00] ケント・ベック著、長瀬嘉秀監訳、永田渉他訳、 「XP エクストリーム・プログラミン グ入門 ソフトウェア開発の究極の手法」 、ピアソン・エデュケーション、2000 年． この本の原書は、以下のものである。 Kent Beck, “Extreme Programming Explained : Embrace Change,” Pearson Education, 2000. またこの本には第 2 版が出ていて、その日本語訳と原書は以下のものである。 ケント・ベック著、長瀬嘉秀監訳、 （株）テクノロジックアート訳、 「XP エクストリーム・プ ログラミング入門 変化を受け入れる 第 2 版」 、ピアソン・エデュケーション、2005 年． Kent Beck, Andres Cynthia, “Extreme Programming Explained : Embrace Change 2nd Edition,” Pearson Education, 2005. [BOE04] バリー・ベーム、リチャード・ターナー著、ウルシステムズ監訳、越智典子訳、 「ア ジャイルと規律 ソフトウェア開発を成功させる 2 つの鍵のバランス」 、 日経 BP 社、 2004 年． この本の原書は、以下のものである。 Barry Boehm, Richard Turner, “Balancing Agility and Discipline A Guide for the Perplexed,” Pearson Education, 2004. [COC02] アリスター・コバーン著、長瀬嘉秀他監訳、 （株）テクノロジックアート訳、 「アジャ イルソフトウェア開発」 、ピアソン・エデュケーション、2002 年． この本の原書は、以下のものである。 Alistair Cockburn, “Agile Software Development,” Pearson Education, 2002. [IPA13] 情報処理推進機構ソフトウェア・エンジニアリング・センター編、 「共通フレーム 2013 147 第 14 章 アジャイル・ソフトウェア開発 経営者、業務部門が参画するシステム開発及び取引のために ソフトウェアライフサイクル プロセス 共通フレーム 2013」 、オーム社、平成 25 年． [JIS12a] 日本工業標準調査会審議、 「ソフトウェアライフサイクルプロセス JIS X 0160-2012 （ISO／IEC 12207：2008） 」 、日本規格協会、平成 24 年． [JUAS13a] 日本情報システム・ユーザー協会、 「ユーザー企業ソフトウェアメトリックス調査 2013 ソフトウェアの開発・保守・運用の評価指標」 、日本情報システム・ユーザー協会、2013 年 6 月． [LAM04] クレーグ・ラーマン著、児高愼治郎他監訳、越智典子訳、 「初めてのアジャイル開発 スクラム、XP、UP、Evo で学ぶ反復型開発の進め方」 、日経 BP 社、2004 年． この本の原書は、以下のものである。 Graig Larmann, “Agile and Iterative Development A manager’s Guide,” Peason Education, 2004. [MART91] ジェームズ・マーチン著、芦沢真佐子他訳、「ラピッドアプリケーションデベロ ップメント Ⅰ、Ⅱ」、リックテレコム、1994年． この本の原書は、以下のものである。 James Martin, “Rapid Application Development,” Mccmillan Publishing Co., 1991. [POP03] メアリー・ポッペンディーク、トム・ポッペンディーク著、平鍋健児他訳、 「リーン ソフトウェア開発 アジャイル開発を実践する 22 の方法」 、日経 BP 社、2004 年． この本の原書は、以下のものである。 Mary Poppendieck, Tom Poppendieck, “Lean Software Development An Agile Toolkit,” Addison-Wesley, 2003. [WEI71] ジェラルド・M・ワインバーグ著、木村泉他訳、「プログラミングの心理学 また は、ハイテクノロジーの人間学」、技術評論社、平成6年． この本の原書は、次のものである。 Gerald M. Weinberg, “The Psychology of Computer Programming,” Van Nostrand Reinhold Co., 1971. （2007 年（平成 19 年）8 月 13 日 新規作成） （2014 年（平成 26 年）3 月 20 日 一部修正） 148 第 14 章 アジャイル・ソフトウェア開発 付 1 アジャイルソフトウェア開発の原則 最も重要なことは顧客を満足させること。早く、そして継続的に、価値のあるソフト ウェアをリリースする。 開発の終盤においても要求の変更を受け入れる。アジャイルプロセスは顧客の競争力 を優位にするための道具である。 数週間、数ヶ月の単位で頻繁に実用的なソフトウェアをリリースする。タイムスケー ルは短い方がよい。 プロジェクトの間中、毎日、顧客と開発者は一緒に働くべきである。 やる気のある人を中心にプロジェクトを構築する。環境と必要なサポートを与え、彼 らが仕事を成し遂げると信じること。 開発チーム内で情報伝達を行う効果的で有効な方法は、Face to Face による会話であ る。 進捗を測るには、動くソフトウェアが一番である。 アジャイルプロセスは、継続的な開発を促進する。スポンサー、開発者、そしてユー ザは一定のペースを保つようになる。 優れた技術と良い設計に絶えず目を配ることで、機敏になる。 単純性--最大限に仕事を行わないことは極めて重要である。 最良のアーキテクチャは自己最適化されたチームから現れる。 定期的な間隔で、チームにもっとも効果的な方法を反映することで、調律・調整に従 うようになる。 （http://www.t-doi.org/agile/index.html より） 149 第 14 章 150 アジャイル・ソフトウェア開発