@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- @IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
最低限の設計ルールをお客様に分かってもらうには?
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2008-05-01 15:46
どうしたらよいか知恵をください。
●お客様からシステムの仕様変更をお願いされています。 開発も総合テストに取り掛かかっている状況での依頼です。 依頼された仕様変更は当初の設計ポリシーを逸脱したものです。 特定のデータの組み合わせの場合のみ発生するレアケースです。 ●こちらからお客様への提案は、、、 運用面での工数を考えて レアケースをモデル化し新しく設計ルールを再構築する。 レアケースを例外データとしてデータベース(テーブル)を追加設計する。 ロジックは汎用化してデータベースの値で条件分岐をする。 です。 ●お客様からの更なる注文 ロジックにその条件を組み込めば済む話であり仕様変更の範疇ではない。 なぜ条件を組み込むだけなのにこんなに工数が発生するのか理解できない。 試しにうちの新人にやらせてみたらいとも簡単に出来たが・・・(案の定ハードコーディングでした) こんな新人でも出来ることがすぐには出来ないということは技術力がないってことでは・・・? エンジニアの言い分がなかなか受け入れてもらえず その場しのぎの対応を迫られる状況に陥っています。 分かってていっているのかその見極めのよく分かりません。 かなりのパワーハラスメントで萎縮してしまいます。 お客様に設計ルールを理解していただく手筋はありますか? | ||||||||
|
投稿日時: 2008-05-01 15:59
品質の種類について説明してみてはいかがでしょうか。
品質には大まかに分けて 外的品質要因、内的品質要因。 前者はさほどコストはかかりませんが、 後者を達成するためにはこんだけの工数がかかりますと。 大規模な開発では後者を考慮していかないと 後々破綻することになると言えば少しは危機感を持ってくれるかもしれません。 | ||||||||
|
投稿日時: 2008-05-01 16:08
ありがとうございます。
外的品質要因、内的品質要因ですね。 この切り口からも説得してみます。 あわせて、私どもを技術力がない協力会社と周りに吹聴したり お客様の上長へ報告したりする人権を無視する工作を止めさせたいのですが どうしたらよいでしょうか? システムも完了に近づいたので切りたいがためにやっている風にしかみえません。
| ||||||||
|
投稿日時: 2008-05-01 17:38
さかもとです。
>あわせて、私どもを技術力がない協力会社と周りに吹聴したり >お客様の上長へ報告したりする人権を無視する工作を止めさせたいのですが >どうしたらよいでしょうか? 正直に真面目に現場の仕事をしていればその人(達?)の皮が剝がれていくだけです。 もちろん法的に無視できないところまで行けばちゃんと争うべきですが、、何にせよ、その程度の人は落ち着くべき所に落ち着くものです。 _________________ ------------------------------------------ 拝啓、さかもとと申します♪ | ||||||||
|
投稿日時: 2008-05-01 17:52
超大手企業なので圧力をかけられると太刀打ちができないのが現実です。
ブラックリスト入りされれば出入り禁止になるし、 業界に根も葉もないうわさが蔓延しては仕事が出来ません。悲しい現実です。 品質に関する資料を作るため情報をあたってみます。 そしてその資料を根拠として残して置くことくらいでしょうか。
| ||||||||
|
投稿日時: 2008-05-01 17:57
私が考える最大の問題は、やろうと思えばハードコーディングでいとも簡単に出来るが、無理やりやっているため、設計に歪みが残り、そのため、心配されているようなレアケースに100%対応できなかったり、あるいは、次に新たな仕様変更があるとそれへの対応は簡単にできなくなる、ということだと思います。 プログラムはスクラッチで組むもの、という考えを持った人には、そのような問題を理解してもらうのは大変でしょう。 「スクラッチでいいんですね?」という確約をもらうようなことをすれば良いのかもしれませんが、現実にはまず無理でしょう。開発の契約時に、開発ポリシーのようなものを取り決めておいたり、仕様変更をどのタイミングまで許すか、ということを決めておけば良いのかもしれませんが、これも難しいでしょうね。 | ||||||||
|
投稿日時: 2008-05-01 18:09
ありがとうございます。
私が考えていることと同じです。 システム開発をしている人は皆そうですね。 複雑さ=レアケース1xレアケース2・・・xレアケースn とレアケース追加分の加算ではなく乗算であると説明しましたが たとえが分かりづらかったせいか説得できずにいます。 開発当初の設計ポリシーの確認も実質確認せずに承認しているというのが実情です。 ハードコーディングで逃げるを繰り返すと複雑さが指数的に増大することを うまくたとえるにはどうしたらよいでしょうか? お願いばかりですみません。
| ||||||||
|
投稿日時: 2008-05-01 18:57
東郷さんはまず技術的問題から離れて顧客と信頼関係を取り戻すようにすべきかと思います。
言われているようなパワーバランスがあり、信頼を構築できていない中で東郷さんがどのようなすばらしい「技術的に問題がある」理由をつけても結局受け入れられないのは明白です。 お話からするともはや開発工程の後半であり、大幅な設計変更に伴う工数の追加や期間の延長などはプロジェクトとしては難しいのでしょう。 であれば、短期的に今まで構築した品質が保て、コストが最小となるような設計をするというビジネス判断は妥当です。 ただし、おっしゃられるような複雑化による中長期的な保守コストの増大は起こるでしょうから、そうした問題は説明すべきです。 なので説明は「おっしゃるその方式でできます。コストは最小です。しかしながら将来このような犠牲(コスト)が伴います。よろしいですか。」であるべきです。どの方式でいくかどうかは顧客のビジネス上の判断であるべきで、東郷さんがする判断ではないと思います。 |