ちょっと昨日の話しからは飛んじゃうんだけど、結局考えていたことは、
システム開発の手法としては、２つ考えられる。
（１）フレームワークを作る段階から、あらかじめ単体テストなどをしやすいフレームワークにしておく。
（結果としてMVCにわけ、さらにDB操作なども分離して、モデルと乖離させると思う）。
そこから業務を（通論などを参照しながら）考えるという手法
→若くない人がやることが多い
|
（２）はじめからあるシステム分析理論に基づき（って、たいていUMLだけど）
業務を分析して、それに基づき、システムをつくる
（現状の業務に沿ったプログラムを作る）
→若い人におおい。
|
どちらも致命的な問題がある。というか、下請けの場合、（１）をやらせてもらえないケースがおおい。また、要求仕様をまとめる手順などにおいては、（１）の手法を否定しているものもある。
で、（２）のケースが現在多いわけだけど（この業界、若い人もおおいし）
（２）の場合、致命的な問題がある。
その１：
ユーザーの言っていることを元に、現状のシステムを分析するので、
ユーザーが言った業務が、伝票書きと書類チェックみたいなものを、延々と言いつづけた場合、
（末端の現場の人にヒアリングするとこうる）
あるテーブルを更新するだけのような業務の積み重ねになってしまい、
業務らしい業務が存在しないので、単体テストなしになってしまう。
その上、やっている業務内容の関連がみえない。
そこに仕様変更が入ると、修正した場合に全体が読みきれず、矛盾が起こる
この場合、結合テストで大きな矛盾が出る（しかし、上記のように、単体テストができるしくみには、初めからなっていない）。それを無理にあわせようとして、プログラムがわけわからなくなる危険がある。
（はじめ、在庫で具体論をかいていたが、長くなりそうなので省略。気分が向いたら、今度書きます）
その２：
ユーザーがいう業務内容が、はたして、コンピューターを載せたとき、最適な方法かどうかわからない。
というか、いままで人がやってたから、矛盾をごまかして運用できたけど、コンピューターのシステム化して、矛盾を顕在化させると、成立しないような業務もありえる。
（これも、具体例をあげていたが、長くなりそうなので省略。気分が向いたら、今度書きます）
結局、はじめに決めたフレームワークが悪いと、仕様変更が起こったとき、後からなおせなくなっちゃうのよね。でも、作り直しは、プロジェクトマネージャーとかは認めないしね。
はじめのフレームワーク設計が問題なんだけど、それを問題にしないで、最終的に問題が顕在化する（単体などの）テストの問題にしてしまうケースが、あまりにも気に障ったので、ちょっと書いてみました。
ただ、そんだけ。
でも、ここまでかくと、「じゃあ、どーいうフレームにすんだよ！」といわれそうなんで、それは、気が向いたら書きます。だって、どーせウィリアムのいたずらが、こーいうのがいいっていっても、結局、開発なんて、えらーいアメリカの人が持ってきた考え使うんでしょ。
それを、現場にもってくれば、どれほど多くの人間が苦しみ、多大な犠牲をはらうと、わかっていても。
で、テストできないのがわるいと、プログラマのせいにして、優秀（憂愁？）なプログラマをうつ病にさせたり、病気にさせてしまうと。。。
ＩＴＳＳも、そーいう偉い人の横のものを縦にして、本かいた人が一番えらくて（レベル７）金がとれるとしたんだから、ウィリアムのいたずらのような、フリーの人間が、なにいっても、むだだよねえ。。。この業界、終わってるかも（＾＾）ｖ
アクセス
トータル
ランキング
