会議おわったんで、さっきのブログのつづき。昔、失敗しなかった理由とかいう話。
これは、ウィリアムのいたずらの独断と偏見ですが。。。
・そもそも、システム化できなさそうなものを、システム化しようとしなかった。
・昔のシステムは、システムを基本的なビジネス動作にわけ、そのビジネス動作をつなぎ合わせて（このつなぎ合わせるのが ＪＣＬ：ジョブ制御言語）作っていた。
つまり、前のブログで書いた、「失敗しないための命綱」とは、この基本的なビジネス動作（＝いつも、ビジネスパターンと書いているやつ）があって、この動作を仕様書に落とす方法、プログラムにする方法、テストする方法が確立していた（綱のようにつながっていた）ので、あとは、要求仕様である、業務が、このパターンに落とせれば、一本につながるわけです。
そこで、この業務が、基本的なパターンに落とせるものだけを、システム開発していたので、そりゃー成功しますよね。あとは、一連の流れが出来ていて、その上、マニュアルには正しいことが書いてあって、動きが予測できるんですから。
じゃあ、今でも、要求仕様をそのビジネスパターン（基本的なビジネス動作）に落とし込めれば、もっと、安全に開発できるんではないか？そんなことを考えた、あなたのために、ビジネスパターンを書いときます。
こういうのを、昔は、新人教育で徹底的におしえこまされます。
（仕様書の書き方から、プログラム、テストの一連の流れを）
■■ 基本的なパターン
・入出力
ファイル入出力(リード、ライト、アペンド）
コンソールとの入出力（display accept)
画面入出力
－画面用のパターンがある。その使い方
ＤＢとの入出力
－ＳＱＬ(select,Insert,delete,Updateとcommit/rollback)
－カーソル操作
・処理
エラー処理
エディティング
転記、アップデート、計算などなど
基本的に、=で結ぶのは、ここに属する
リスティング（フォーマッティングも含む）
順番＆指定されたところに出力し、適当なところで改行する
適当な形に変形するのも含む
ソーティング
ＳＵＭ
チェッキング・マッチング
マスターの中に指定されたデータがあるか／あるものを抽出する
マージ
マスタデータにトランザクションデータが
あれば、トランザクションに置き換え
なければ、追加する。
だったと思います（他にあったかも）。
新人教育では、これらについて、一通りというか、結構やらされます。
やり方は、このケースだと、このパターンという形です。パターンは
前処理
主処理（繰り返しあり）
後処理
の形で、あらかじめ出来ています。
で、新人教育が終わった後で、「これだけで、システム組めるはずだから」といわれます。ほんとーかいな？と思っていると、結局、これだけですみます。
ちなみに、上記のものは、Javaで全部組めます。
例をJavaで書こう書こうとおもって、今日までこの話をしなかったのですが、
今、Excelのお仕事ばっかりで、会社で、eclipseを開けないので（開いてると、サボっていると一発でばれるので）もう、今日、上げちゃいます。
例は、eclipseが開けるようになってから、別の機会に取り上げます。
全部、HashMapやVector,配列を使うと出来ます。
大事なことは、HashMapのキーを取り出すのは、 hashmapが、ハッシュマップだとすると(String[])hashmap.keySet().toArray(new String[0])で取り出せることです。
したがって、要求仕様作成（業務部分）は、昔だと、業務を、上記のようなやり方がわかっている方法に落とし込む作業です。
一方、今のシステム開発は、業務をどのくらい詳細にしていいか、明確にしないで、どんどん詳細にしていく作業です。
で、むずかしいことばＣＲＭとか、ＥＡとかＥＤＩとかをつかって、なんとなーくわかった感じで、作ってしまいます。
そのため、出来ないようなシステムでも、やり方がわかるところまで落とし込まないので、なんとなくできそうだと受けてしまったり、しちゃいます。
つまりですね、難しい言葉から、実際のプログラムまで、なにをやればいいのかの一貫した流れ（これが、命綱）を、抑えているかどうかわかんないし、そもそも、難しいことばで話した場合、お客さんの言っていることと、自分の考えてることが、一致してるかどうかわかんないです。たとえば、ＣＲＭっていって、どんなシステム？？
人によって、想像するものが違うと思うよ。つーか、どんなものかも想像できない人もいると思うよ。。
で、この一貫した流れというのが、業務の標準化につながってくるわけです。
アクセス
トータル
ランキング
