最低限の設計ルールをお客様に分かってもらうには？

otfさんの書き込み (2008-05-01 15:59) より:
品質の種類について説明してみてはいかがでしょうか。

品質には大まかに分けて
外的品質要因、内的品質要因。
前者はさほどコストはかかりませんが、
後者を達成するためにはこんだけの工数がかかりますと。
大規模な開発では後者を考慮していかないと
後々破綻することになると言えば少しは危機感を持ってくれるかもしれません。

さかもとさんの書き込み (2008-05-01 17:38) より:
さかもとです。

>あわせて、私どもを技術力がない協力会社と周りに吹聴したり
>お客様の上長へ報告したりする人権を無視する工作を止めさせたいのですが
>どうしたらよいでしょうか？


正直に真面目に現場の仕事をしていればその人（達？）の皮が剝がれていくだけです。

もちろん法的に無視できないところまで行けばちゃんと争うべきですが、、何にせよ、その程度の人は落ち着くべき所に落ち着くものです。

東郷さんの書き込み (2008-05-01 15:46) より:
●お客様からの更なる注文
ロジックにその条件を組み込めば済む話であり仕様変更の範疇ではない。
なぜ条件を組み込むだけなのにこんなに工数が発生するのか理解できない。
試しにうちの新人にやらせてみたらいとも簡単に出来たが・・・（案の定ハードコーディングでした）
こんな新人でも出来ることがすぐには出来ないということは技術力がないってことでは・・・？

unibonさんの書き込み (2008-05-01 17:57) より:

引用:
東郷さんの書き込み (2008-05-01 15:46) より: ●お客様からの更なる注文 ロジックにその条件を組み込めば済む話であり仕様変更の範疇ではない。 なぜ条件を組み込むだけなのにこんなに工数が発生するのか理解できない。 試しにうちの新人にやらせてみたらいとも簡単に出来たが・・・（案の定ハードコーディングでした） こんな新人でも出来ることがすぐには出来ないということは技術力がないってことでは・・・？

私が考える最大の問題は、やろうと思えばハードコーディングでいとも簡単に出来るが、無理やりやっているため、設計に歪みが残り、そのため、心配されているようなレアケースに100%対応できなかったり、あるいは、次に新たな仕様変更があるとそれへの対応は簡単にできなくなる、ということだと思います。
プログラムはスクラッチで組むもの、という考えを持った人には、そのような問題を理解してもらうのは大変でしょう。
「スクラッチでいいんですね？」という確約をもらうようなことをすれば良いのかもしれませんが、現実にはまず無理でしょう。開発の契約時に、開発ポリシーのようなものを取り決めておいたり、仕様変更をどのタイミングまで許すか、ということを決めておけば良いのかもしれませんが、これも難しいでしょうね。