インハウス開発とか

インハウスCADは失敗ではない

面白い。

逆に欠点といえば、仕様がなあなあになりがち、ということだろうか。 つまり、例えば細かいエラー処理やユーザーインターフェイスのような面倒な開発は省略しがちであるように感じた。社内の人同士で仕様を決めているので、「ちょっとこの細かい開発は面倒だからさ、そっちでうまく運用してカバーしてよ」みたいなやりとりが成立してしまう。これはもちろん良い面もあるが、そのまま放置されると運用でカバーしなくてはならない項目が膨大になって、操作を覚えるのが大変になってしまう。このあたりが、パッケージソフトに発展しなかった原因の一つかもしれないな、と思う。

あるなぁ、確かに「運用でなんとかしてよ」は。
ただ、運用のコスト低減が開発コストを上回るのであれば、当然「やるべき」なんだけどね。
だから、UIの向上による利便性とかは尚更気をつけなくてはいけないんだろうなぁ。

人事ローテーションの功罪 これについてはシンプルに箇条書きにまとめてみよう。 * ○ 色んな部署に、かつて開発に関わったことがある人がいて、技術的な事情がユーザー部門に伝わること * ○ 開発チームのメンバーがユーザー部門の仕事をとてもよく理解していて、仕様策定がスムーズに進むこと * × ソースコードに疑問を感じても、それを書いた人はことごとく他部門に移っていて質問ができないこと * × ソフトウェア技術（コードの美しさ、オブジェクト指向設計、etc）は古いままで変化がないこと つまり一言でいえば、What/Why に強く、How が弱い。これはもしかすると、現在のSIerと逆の状況といえるのかもしれない。

大企業はゼネラリスト育成志向が強いから仕方ないかもしれんけど、開発者をあちこちに回さないほうがいいのかね、とは思った。

ソフトウェア技術進化追従への動機としては、「開発コストの低減」が最たるものだと思うし、それってある程度、仕事をルーチン化させないと出てこない気がする。

なんというか、

最初のシステム開発は試行錯誤。
２番目のシステム開発は試行錯誤を反映した、平均的レベルなもの。
３番目のシステム開発はもはやルーチンワークなので、大幅なコスト低減を図れる。

ってことだと思うので。

それからインハウスCADが廃れたのって、やっぱりパッケージCADでもそれなりの質を確保できる程進化したし、安くなったってことなんですかね。