アジャイルサムライ

アジャイルサムライ−達人開発者への道−

アジャイル開発の原則−ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなくてはなりません。
そうはいっても、お客さんのほうにも積極的にはかかわり合いになりたくない理由ならいくらでも挙げられる。たとえば、そのプロジェクトはIT部門から押し付けられたもので、正直なところうんざりしているのかもしれない。あるいは、そもそもそのソフトウェア自体が欲しいわけでもない(あるいは必要ない)のかもしれない。ひょっとしたら、君の説明不足なのかもしれない。君がお客さんに、顧客としての役割がプロジェクトの成功にとってどれほど重要なのかをきちんと説明できていないだけかもしれないよ。まあ、単に忙しすぎるだけ、というのもよくある話だ。
結局何を言いたいのかというと、お客さんとの間に信頼関係を築く必要があるのだとしたら、少しずつ信頼貯金を増やすところから始めよう、ってことだ。これができれば、きっともっと君もお客さんを開発に巻き込んでいけるようになるはずだ。

アジャイルプロジェクトの背景にある考え方をカジュアルに解説された本。
監訳者のお二人は、永和システムマネジメントという、アジャイル受託開発サービスを提供する会社に所属されている。
テスト駆動開発、継続的インテグレーション、イテレーションの運営、ユーザストーリー、朝会など、アジャイル開発については、常に斬新なキーワードと共に語られて、そしてウォータフォール開発のアンチテーゼとして位置づけられることが多い気がしている。
本書を読むと、そのような捉え方が表面的な見方しかしていなかったのだということに気付かされる。上に引用した「お客さんとの間の信頼関係」を如何に築くかという切り口をきっかけにして、背景にある考え方を理解できる。
よくいわれる「コスト」「納期」「品質」に加えて「スコープ」を同じ天秤に乗せて、お客さん自身にユーザストーリの取捨選択を迫る。そのことを納得感を持って聞き入れてもらうためにも、一週間単位のイテレーションで動作するシステムの提供を繰り返して「信頼関係」を築く。
つまり、「一週間単位のイテレーション」とは、あくまでも一つの道具立てに過ぎなくて、あらかじめ締結した開発請負計画に縛られつつも、止めどなく要件変更を繰り返して、最初の見積もりが有名無実化するという不幸な状況を回避するための、一つの具体例に過ぎないのだと感じた。

3.1 プロジェクトがだめになるのはなぜか
ここでの問題は、プロジェクトの開始時点で関係者の認識がそろっていないことじゃない（それはむしろ自然なことだ）。問題は、関係者全員でプロジェクトについて話し合うよりも前にプロジェクトを始めてしまうことにある。
チームメンバが誰もいないところで合意したことを前提にしているから、プロジェクトがだめになるんだ。

アジャイル開発の背景にあるのは、「スコープ策定に開発チームがかかわること」と「開発チームはステークホルダに情報を提供すること」という二つのシンプルな原則に過ぎない。
ウォータフォール開発や業務請負契約が悪者と見做されるのは、この二つの原則との相性が悪いことが原因なのだと思った。
一方で、「キーワードとして語られるアジャイル手法」が、簡単には適用できないプロジェクトがあるのも、また事実として避けがたいものだと感じる。
「アジャイル手法」をそのまま取り入れられそうにないからといって簡単にあきらめるのではなく、自らの置かれている状況下で、どうすれば二つの原則を尊重できるかを模索することが、とても大切なことなのではないかという気がした。