June 9, 2004

マーチン・ファウラー特別ラウンドテーブル 現場レポート [前編]

ファウラー 基本的に、一括請負契約という考えは危険な幻想だと思っています。

平澤 それは開発者側の立場から?

ファウラー 開発者と発注者、両方の立場から。(中略)一括請負契約は、開発を開始する前に相手の要求仕様が完全に理解できている場合にはいい考えですが、実際にはそんな状況にほとんど遭遇したことがありません。

一同 (笑)。

いやいや、こんだけ早々たるメンバが集まっていながら「一同 (笑)。」って。笑ってる場合じゃないだろ。
一括請負契約(僕の会社でいう、製造請負)がダメだとすると、残るは業務委託、つまり、人貸し頭数ビジネス、要するに人月計算ということになると思うんだが、マーチンは本当にそういう意図だったんだろうか?
一括請負契約がダメのは、GOALが見えない段階で見積もりをし、GOALが確定しない段階でGOALを保証する契約だからだ(これが、マーチンが言うところの『一括請負契約は、開発を開始する前に相手の要求仕様が完全に理解できている場合にはいい考えですが、実際にはそんな状況にほとんど遭遇したことがありません。』という言葉)。
だから一括請負契約は、開発側が全てのリスクを背負う契約とも言える。それを顧客、開発側双方でそれなりにリスクを分担しましょう、というのが、アジャイルの基本姿勢だと思う。そうすることで一方的に押し付けるのではなく、両者が協調する、と。
でも、実際は開発側も一括請負契約であることをエクスキューズに使うことが多い。曰く、「あれだけわがままな仕様変更に対応したんだから、少しぐらい品質は目をつぶってよ」とか。
ケントベックだったか誰だかは忘れたが、アジャイルで細かく刻んだイテレーション単位で契約するんだ、という話を以前にどこかで読んだ記憶がある。こうすることにより、あるイテレーションの中では、これまでの一括請負契約の形にはなるが、仕様変更は次のイテレーションに回すとか柔軟に対応でき、イテレーションの中では、GOALが明確になるのでリスクは減るというわけだろう。でも、これってベースになるシステムは既にあって機能追加がどんどん発生している状況ではとてもうまくいくだろうけど、最初のベースとなるシステムを開発するフェーズでは難しいような気もする。僕は、このフェーズをうまく回し、継続的イテレーションを軌道に乗せるまでのうまいやり方が知りたい。


Posted by money at June 9, 2004 2:36 PM | TrackBack
Similarly Feeds
Comments
Post a comment









Remember personal info?






Powerd by FC2.com
since 2/Feb/2004