アカウント名:
パスワード:
ソフトウェアに限らないけど、たとえば「服」なら既製服と注文服で客のほうに「も」知識が要るのは圧倒的に注文服なんですが、それは客も理解してるのよね。事前に金を払ったからといって、早くできるわけでも、注文になかったものまで作ってくれるわけではないので、作ってほしいものがあれば、きっちり注文内容にそれを入れることが必要。
でもソフトウェアになると、なぜかそれが分からなくなってしまう。
既製品(パッケージソフト)で間に合わないから注文品にしているはずなのに、発注側が受注側に何でもかんでも「察する」ことを求めてちゃいけないよね。
形として見えるものじゃないから、分割受注みたいな形(アジャイル)にして「客の」リスク(と受注側のリスク)を下げようとしているのに、それを拒否されたら、どっちも不幸になるだけなのは散々説明されていると思うのです。
注文服の例えを使うと、アジャイルが避けられる理由(の1つ)も説明がついちゃいそうですね。「着丈はもっと長いのがいい」とかの直しようのない要望に後から気づいたら、最悪全部やり直しですから、全体が見えない段階でゴーを出すのは勇気がいるでしょう。それとやっぱり、値段が決まらない内に「買う」という決断はしづらいですね。
「これとこれは最初に決めないといけない。他は後で安く直せるから次のサイクルで検討すればいい」といった、一段上の判断ができてればリスクを抑えられるかな。でもそれができる人なら、きっとウォーターフォールでもちゃんと仕様を出せちゃますね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
既製品と受注品 (スコア:5, すばらしい洞察)
ソフトウェアに限らないけど、
たとえば「服」なら既製服と注文服で客のほうに「も」知識が要るのは圧倒的に注文服なんですが、
それは客も理解してるのよね。
事前に金を払ったからといって、早くできるわけでも、注文になかったものまで作ってくれるわけではないので、
作ってほしいものがあれば、きっちり注文内容にそれを入れることが必要。
でもソフトウェアになると、なぜかそれが分からなくなってしまう。
既製品(パッケージソフト)で間に合わないから注文品にしているはずなのに、発注側が受注側に何でもかんでも「察する」ことを求めてちゃいけないよね。
形として見えるものじゃないから、分割受注みたいな形(アジャイル)にして「客の」リスク(と受注側のリスク)を下げようとしているのに、
それを拒否されたら、どっちも不幸になるだけなのは散々説明されていると思うのです。
Re:既製品と受注品 (スコア:3, すばらしい洞察)
注文服の例えを使うと、アジャイルが避けられる理由(の1つ)も説明がついちゃいそうですね。
「着丈はもっと長いのがいい」とかの直しようのない要望に後から気づいたら、最悪全部やり直しですから、全体が見えない段階でゴーを出すのは勇気がいるでしょう。
それとやっぱり、値段が決まらない内に「買う」という決断はしづらいですね。
「これとこれは最初に決めないといけない。他は後で安く直せるから次のサイクルで検討すればいい」といった、一段上の判断ができてればリスクを抑えられるかな。
でもそれができる人なら、きっとウォーターフォールでもちゃんと仕様を出せちゃますね。