March 9, 2004

仕様のFix

業務仕様とは、どこでFixさせるべきなのでしょうか.
  1. ウォータフォールならば、上流工程でFixさせる。
  2. 最後まで決まらなくて、プロジェクトがデスマに陥るのがこの業界の慣例
  3. 流行のXPやRUP等を用いて変化に対応する。
  4. 無理やりFixさせて客に仕変をせまる。

うーん、理想はやっぱり、(3)なんだろうけど、お客さんを選ぶ必要があります。というのも、最近、むやみやたらとXPやれ、と迫るお客さんが多い。個人的にもいろいろ試してみたいことがあるので、嬉しくなって話を進めようとするとどうも、話がかみ合わない。よくよく話をつっこんでみるとなんてことはない。XPのことなんて少しも分かってなくて、ただ単に、「変化を抱擁せよ」tと言う言葉を勘違いして「XPって、仕様変更の無理が利くんでしょ?」とか、「テストファースト」を勘違いして「いきなりテストからやるんでしょ?メイク工程省けていいね」とかその程度の理解でしかない。そこで、「テストファーストというのは、まずテストプログラムを書いてそのテストがちゃんと動くようにコードを書け、ということです。テストプログラムが通るということは、まずこれさえできればOK,という仕様を決めていただかないと、テストプログラムは書けません。」とか、「最大限、仕様変更には対応しますが、手戻りの工数は全てご請求させていただきますがよろしいでしょうか?」といった話をすると、途端にトーンダウンしてしまう。あと、オンサイト顧客やってくれ、って話もまずは聞いてもらえない。まだまだお客さんに対する啓蒙が必要です。でも、お客さんさえ了承が取れれば、上司は押し切れるんだがなぁ。結局、開発側としては、現時点では自己防衛も含めて、(4)しかなさげ。コツは、お客さんに、「申し訳ない。こちらの検討ミスが見つかったので、お願いだから仕様変更させて!」と思わせること。何事も主導権を取ったもん勝ち、ということで。
でも、自分が開発側であることを一歩離れて考えると、「Fixしないから仕様なのだ」と思う。仕様が全く変わらない開発なぞ面白くありません。仕様とは生き物なのだ。


Posted by money at March 9, 2004 3:51 AM | TrackBack
Similarly Feeds
Comments
Post a comment









Remember personal info?






Powerd by FC2.com
since 2/Feb/2004