« [お知らせ] ようこそ、 TDD.NET へ | トップページ | [記事紹介] @IT ~ .NET で始めるデザインパターン »

2009年7月 2日 (木)

[コラム] アジャイル開発の理念

より良いものをより安く

これは、 製造業やサービス業ではあたりまえのスローガンです。 顧客に何かモノやサービスを提供し代価を得る仕事であれば、 共通の理念でありましょう。

数多くあるアジャイル開発手法の提案者やグル (guru) の人達の中に、 このモットーを唱えている人はいないのではないかと思いますが、 機械設計畑で 10年ほど御飯を食べてきた私には、 アジャイル開発手法が生まれてきた根源も、 同じに思えてなりません。


このサイト TDD.NET のオープンにあたって、 trapemiya さんからお祝いの言葉をいただきました。

The road to C# master trapemiya: biacさんが新サイト 『TDD.NET』 をオープンされました。
2009年7月2日

こんなに褒めていただくと、 とても嬉しいやら、 まるで至らぬギャップに戸惑うやら。
ところで、 その末尾にこうあります。

「TDD は、 アジャイル開発手法から生まれてきた方法なので、 」 という文章は、 私がいつも言っている 「それは何のために存在しているのかを考えてみることが大切である。」 の答えになっています。

TDD は、 アジャイル開発手法の一部として、 アジャイル開発を成功させるために生まれてきた、 と言ってよいと思います。
trapemiya さんの問いかけを借りると、 ではアジャイル開発手法は何のために、 という次の問いが現れます。

アジャイルの理念は 「変化を抱擁せよ」 (Embrace Change) という一言で表されることがあります。 ( "Embrace Change" は、 「XPエクストリーム・プログラミング入門」 ( Kent Beck 著 ) の副題 )
何の変化でしょうか? 端的に言えば、 顧客の要求の変化、 です。 顧客の要求の変化にすばやく ( = agile に ) 対応できることこそ、 顧客により良いものを提供できることになるというわけです。

そして、 これがウォーターフォールに代表される 「重たい」 開発プロセスとの間で、 もっとも異なる部分です。 ウォーターフォールも、 より良いものを顧客に提供しようという理念は同じです。 ただ、 それは計画通りの機能を計画通りに納めることによって達成できると考えるところが違います。
※ したがって現在でも、 顧客の価値観が 「変化」 よりも 「計画通り」 であるならば、 ウォーターフォールが有効だと考えられます。 もっとも、 ウォーターフォールで計画可能な納期が認められるかどうかは分かりませんが。

そのような 「重たい」 開発プロセスとの対比を簡潔に表現した文書が、 2001年に出されました。 「アジャイルソフトウェア開発宣言」 です。

アジャイルソフトウェア開発宣言

私たちは自らソフトウェア開発を行い、 他人のソフトウェア開発を手助けすることで、 ソフトウェア開発のより優れた方法を発見している。 この仕事を通して、 私たちは以下のことを重視するようになった。
・ プロセスやツール   よりも  個々人と相互作用
・ 包括的なドキュメント よりも  動作するソフトウェア
・ 契約交渉       よりも  ユーザーとの協調
・ 計画に従う      よりも  変化に対応すること

すなわち、 左側の項目にも価値はあるが、 右側の項目により多くの価値を見いだしている。
※ 原文: http://www.agilemanifesto.org/
※ 2001年2月米国ユタ州にて開催されたアジャイルアライアンス会議にて採択された

4つの項目が挙げられていますが、 「変化を抱擁せよ」 ( 「計画通り」 よりも 「変化」 ) は、 4番目です。 その前の 3つは何でしょう? 変化を抱擁するために必要なこと、 でしょうか?
「重たい」 開発プロセスであっても、 変化に対応することは可能でありましょう (大量の手戻りをこなすための人海戦術と、 手戻りを見込んだ日程を組むことができれば)。 ということは、 3つの項目は変化を抱擁するために 「必要」 なこと (必ずそうであらねばならないこと) ではありません。   
ここに、 アジャイルの、 そして顧客が望む、 もうひとつの価値観が出てきます。 それは、 「より安く」。 すなわち、 「(重たいプロセスよりも) 安く」 「変化を抱擁せよ」 ということです。
安くするといっても、 開発者の給料を削れというのではありません。 開発に掛ける工数を減らそうということです。
「より安く」 という価値観を入れると、 「アジャイルソフトウェア開発宣言」 の残りの 3項目も理解できます。
下から順に、

・契約交渉 よりも ユーザとの協調
ユーザーと協調してさっさと進めたほうが、 変化に早く対応できるし、 コストも下がるでしょう。
・包括的なドキュメント よりも 動作するソフトウェア
不要なドキュメントは作らずに、 動くソフトウェアとしてお見せします。 ドキュメントを作らずに済んだ分は、 コストが下がりますよ。
・プロセスやツール よりも 個々人と相互作用
重たい開発プロセスの細々とした手続きやプロセス管理用のソフトは、 チームメンバ同士のコミュニケーションで済んでしまうなら、 省略できます。 余計な手続き、 余計な投資が減った分は、 コストが下がりますよ。

※ なお、 工数が減るということは、 人数が同じなら早く終わるということでもあります。 「より安く」 は、 「より安く & より早く」 と言ったほうが適切なのかもしれませんね。 そうすると、 吉野家の有名なスローガン、 『 「うまい」 (良い) ・ 「やすい」 ・ 「はやい」 』 になります。

じつは、 「より安く」 というのも顧客の望むところですから、 重たいプロセスでも対応を考えてきました。
ウォーターフォールでは、 上流の設計をしっかりやることで、 コーディングとテストは経験の浅いものを安く大勢雇って実施できると考えました。 また、 各工程を ( ウォーターフォールの原則を破って ) オーバーラップさせることで、 短納期とコストダウンが計れると考えました。 このウォーターフォールの対応は、 私には上手く行っているようには見えません。
RUP では、 全部を実施するのではなく、 プロジェクトに適したサブセットを切り出して使うことによって、 短納期とコストダウン、 それに変化への対応もできると考えました。 この RUP の対応方法は、 アジャイルと同様に、 プロジェクトによっては上手くいくのではないでしょうか。

「アジャイルソフトウェア開発宣言」 に戻ります。
最初の項目、 「プロセスやツール よりも 個々人と相互作用」 を重視するというのは、 じつは大変なことを言っています。 既存の重たい開発プロセスでは、 プロセスを定義したドキュメントがあり、 実際の開発プロセスはそれに従って進めてきました。 決められた手順に従っていればよかったのです。 逆に、 定められた手順からの逸脱は許されません。
「個々人と相互作用」 (メンバ個人々々のスキルと、 メンバ間のコミュニケーション) を重視するアジャイル開発手法では、 それに従いさえすれば良いという、 決められた手順はありません。 ベストプラクティスはありますが、 いつ・どんなものを作るかということを事細かく決めたりはしていないのです。 いつ・だれが・なにをするか、 ということは、 プロジェクトごとに 「個々人と相互作用」 の中で決めていかねばなりません。
よく、 「アジャイルでは文書を作らない」 という誤解された話が出ますが、 ドキュメントを書くか書かないかも、 顧客が受け取る価値を最大化しコストは最小化する ( より良いものをより安く )、 という文脈の中で、 ケースバイケースで判断することになるわけです。
※ プロジェクトマネージメントの経験に乏しいメンバーだけでアジャイルをやると、 この 「いつ・だれが・なにをするか」 の決定が上手く行かず、 失敗しているように思います。

さて。 これまでに、 「アジャイルソフトウェア開発宣言」 に従う、 多くのアジャイル開発手法が提案され、 実施されてきています。 何十種類もの手法がありますが、 それらは、 それぞれのチーム、 それぞれの顧客、 あるいは、 それぞれのそれまでの企業文化などといった、 異なる条件の元に、 「個々人と相互作用」 の中でベストな方法を探索してきた結果でありましょう。 それら多くのアジャイル手法は、 しかし、 いずれも 「アジャイルソフトウェア開発宣言」 の 4つの価値観を体現するものです。

私にとっては、 それらはいずれも、 「変化」 に価値を見出している顧客に対して、 「より良いものをより安く」 提供するために考え出されたように思えます。 そして、 アジャイルの根源にある理念がそれであるとするならば、 例えば先日 Kent Beck が、 ユニットテストを最初に書かないこともある、 と述べたことにも、 何の不思議も無いわけです。
ユニットテストを書くためにプロジェクトをやっている、 のではなくて、 「より良いものをより安く」 プロジェクトから提供するために必要だと判断したからユニットテストを書く、 のです。

|

« [お知らせ] ようこそ、 TDD.NET へ | トップページ | [記事紹介] @IT ~ .NET で始めるデザインパターン »

*コラム」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック


この記事へのトラックバック一覧です: [コラム] アジャイル開発の理念:

« [お知らせ] ようこそ、 TDD.NET へ | トップページ | [記事紹介] @IT ~ .NET で始めるデザインパターン »