とくに、バージョンアップとかに注意だよね！－例：SugarCRMの場合

　先ほどのもので、入出力方法が用意されていないものだと、大幅改造になる場合がある。と書いたけど、その場合、工数の問題だけでなく、バージョンアップのときに取り残される危険もある。

　たとえば、SugarCRMで考えると、バージョン４．Ｘにおいて、
　あるテーブルからの値を参照して、値を設定したい場合は、サブウィンドウというか、もうひとつ、選択用のダイアログを開いて行う。
　これを、プロダウンメニューに設定するようにするには、改造が必要になる（固定値をプルダウンメニューに設定するのは簡単。そのような仕組みは用意されているが、プルダウンメニューにＤＢの値を設定する場合に問題になる）。
　４．Ｘで、この改造を大幅にやってしまうと、５．０での画面の出し方が違うので・・・どーにもならなくなる。

　もちろん、４．Ｘでも、サブウインドウを開いてやる、基本的な方法なら、５．Ｘにいっても、そんなに問題は起きないと思うけど。。

　ということで、このように、入出力を規定の方法以外で大幅にいじってしまうと、工数が増えるだけでなく、バージョンアップのときに面倒になる。
（ちなみに、ＳｕｇａｒＣＲＭで自由に画面を使いたければ、ＳＯＡＰでつないじゃうほうがいいのかも・・）
　なので、極力ＧＵＩは、そのアプリなり、フレームワークが標準で用意するものを使うべきということになる。
　ここの見積もりが大事ということですね！

データ構造の複雑さと入出力方法の分析が甘いと、失敗しやすいっていうことだよね

　昨日、「入出力のほうが、上流にかかわるので、ここでの変更は、開発コストが高くなる」と書いたけど、
　ってことは、「なにを」入出力するかである「データ構造の複雑さ」と、「どうやって」入出力するかの「入出力方法の分析」が甘いと、開発コストが大きくかかって失敗しやすいことになる。


　オブジェクト指向は、おうおうにして、データを抽象化できるから、すべてを分析しなくて良いという風潮になりがちだが、分析しないと、実ははじめに考えていたデータ構造は簡単で、現実はもっと複雑というケースもありえるので（例：正社員の給与体系だけ考えていたら、実は、給与にはアルバイト、契約社員いろいろあり・・・）、システム全体のデータ構造を分析しないと、再利用できないで、開発コストが高くつく場合もある（そのデータ構造体系内であれば、再利用可能となるが・・）


　また、入出力方法が用意されていないものだと、大幅改造になる場合がある。
　ＳａａＳやＡＳＰの場合、入出力方法が用意されているもの（プルダウンとかテキストエリアなどは用意されていることが多いが）を利用する場合は、ちょっとしたカスタマイズでＯＫだが、そうでない入出力（イメージを囲んで、その範囲とかは用意してないことが多い）は、大変なコストがかかったり、そもそも出来なかったりすることもある（サーバーからクライアントのプログラムを勝手に動かすというようなものは、セキュリティ的に出来ないことが多い）。


　このように、データ構造の複雑さと入出力方法の分析が甘いと、失敗しやすいっていうことだよね