|
3:（６００は「買い」だ！）： その３ 「未来資産」構築のために ＥＸＣＨＡＮＧＥ 10/10 11:57 ＊ 「次の一手」を考える前に、 ちょっと寄り道して、 「どうして、このような旧式な構築法が使われたのか？」という点を押さえておきましょう。 ＊ それは、なにより「２０００年問題」の裏に存在した「真の理由」と同じようなものです。当時のコンピュータのキャパシティがあまり大きくなかったための「容量節約」です。 （おまけ）：現在かかっておられるＳＥさんと話をして、「こっちの方が容量が節約できるから（そうした）。。」というせりふがあまり頻繁にでるような方だったら、ちょっと要注意ですね。 ＊ 小さいキャパで、きついお客の要望を何もかも一度にやってしまおう！ という涙ぐましい努力が生み出した「芸術（アート）」でもありました。（今でも、そういうことが「プロ的」な腕だ、という信念を持っておられるＳＥさんがおられます。そういう方は概ね、ゲイツさんの容量無駄遣い垂れ流し型のＯＳに非常に嫌悪を感じられるようです） ＊ しかし、「わかよたれそつねならむ」 時は流れ、時代は移り、コンピュータの容量問題は大きく改善されました。（ひとり「オフコン」だけが例外ではない。。） ＊ 現在の「オフコン」（例えばＮＥＣ Ｅｘｐｒｅｓｓ５８００／６００シリーズ）では、 「ＣＰＵのパワー、メモリの量、ディスクの容量などは十分なほど用意されており、必要ならさらに「安価」に増設できる。」 のです。 なんといっても、これは「Ｗｉｎｄｏｗｓ２０００サーバですから。。」 ＊ そこで、本題に戻りますが、私が言いたいのは こうした「プア」なシステムこそ再構築されるべきだ！！ ということなのです。 （ただし、Ｓ７２００以後のマシンをお使いの会社で「ＲＤＢサーバ」「ＳＫＹＬＩＮＫ」も使ったことがない、知らない、 と言う方は「再構築」の前に、まずこれらを「使ってみる」ことからお始めください。 この程度のこともやらずに、「パソコン系システムに替えて誰でも使える形にしたいから」などと比較評価されると、「オフコン」が可哀想ですから。。） ＊ さて、「再構築」に際してどのようなことに留意すべきでしょうか？ 以下、独断と偏見で。。 （１）まず、容量は十分用意されているし、ＡＶＸは元々あまり容量を無駄遣いしないＯＳなので、 「難しいプログラムテクニック」によって「容量節約」を計ったり、「スピードアップ」を計ったりすることは極力避け、 キャパが足りないときはどちらかというと「ハード」の増設で対応するような考え方を取る。 （ハードのパワーに依って解決を計る。「貧乏指向」から「リッチ指向」へ。 ハードの増設の方がソフトの変更より安上がり。 「ハード」はソフトに変更でき、「ソフト」はハード（硬い）であとから変更がしにくい。） （２）「基幹系システム」と「情報系システム」を考え方だけでなく実際のシステム上でも完全に「分離」するように設計する。 ＊基幹系マスタ上では残高に関わる項目のみ集計、更新する。いわゆる「何とか別、何とか別、実績マスタ」などは基幹系に作らない。基幹系データは残高を集計、更新するのに必要な分と、データ作成に参照する必要のある分などに絞る。 ＊ レプリケーション機能をフル活用して、ＳＱＬサーバ（またはｏｒａｃｌｅ）側に、「情報系ＤＢ」を構築する。 こちら側の定型ソフトはＶＢ、ＡＣＣＥＳＳ可。（それの方が長い目で安上がり。理由は後で説明）。 それから、こちら側は「別サーバ」の方がヨリ良い。これはふつうのＰＣサーバ。 （３）他社とのデータやりとりは、単純なバッチなら「パソコンソフト」でＪＣＡ、全銀などを使って、６００シリーズのいわゆる「ＮＴ領域」に落とす。 複雑系は「Ｂｉｚｔａｌｋ」を指向する。 営業所などへのデータ送信で従来Ｓ３１００／１０などを「受け」「受け後」に使っていた場合は、メール連携で「ＣＳＶ添付」に切り替え、その先はＶＢ、ＡＣＣＥＳＳで。 自社内の遠隔端末はＶＰＮを使う。 いずれにせよ、極力「６００シリーズの通信ボード」は使わないように心懸ける。 （４）上記を違和感なく操作できるよう「ＪＯＢ起動ユーティリティ」などを使って、操作員に配慮する。 等々です。 あと、「ＲＤＢＷＡＶＥ」（ｗｅｂ版）というのはいかがでしょうか？（有償だが、安い！） （出来るだけ、ＡＶＸ標準機能を使います。 オープンからＡＶＸＲＤＢ、 ＡＶＸからオープンＲＤＢ といった斜め読みは極力避けます） ＊ こうして、「基幹業務側」から「情報系的な部分」を分離すれば、 （１） 将来にわたって「基幹業務側」の変更はあまり発生せず、この部分の変更は最小限ですむ。（ディーラの「高い」見積もりを拝見する場面が減る） （２） いわゆる「情報系的な部分」は要望などが変化しやすく、ここらはＶＢ、ＡＣＣＥＳＳなど「継続性が当てにならないツール」で作っても被害が少ない。それよりも表示、作表の「表現力」が大事な領域。 あと、この辺は「参照オンリー」に権限しとけば、「江須扇」様のページに出てきた「パソコンちょっとだけ知ってる的にわかプログラマ」を「活用」できる（こっちが「活用」してやるのだ）。 ＊ かくして ＝＝＝ 「未来資産」を創るのです！！ ＝＝＝ ＊ 特に「基幹部分」に関しては、ＡＶＸは抜群に安定度も高く、そのＣＯＢＯＬは今後の一貫した継続性が期待できます。 ＶＢからＶＢ．ＮＥＴへの乗せ換えみたいな苦労を何度もしたい方は、どうぞ「ＭＳで基幹を構築」なさってください。きっと 「 Ｄｏ ｓａｍｅ ｗｉｔｈ ｍｏｒｅ 」 請け合いです。 ＊ また、６００シリーズは、ＡＳ４００みたいにお高くないですし、それに、分離された「基幹業務側」のためには、そんなに大きな６００シリーズでなくてもＯＫでしょう。 その分を「未来資産」の構築に当てるのです！！ ＊ それと、（これは、実はとっても「大事」な点！！） 旧オフコンを６００シリーズに替えて一番驚くのは、きっとその「スピードの速さ」「処理能力の向上」だと思います。 「どうして今まで古いマシンを使い続けてきたのだろう？もっと早く６００に替えれば良かった」と感じられるでしょう。 ＆＆＆＆＆＆＆＆＆＆ ＊ 何？「ＡＶＸが将来も続くか心配」ですって？ どんなものが将来も存続し続け、どんなものがそうでないのか、それは私にも分かりません。 でも、それを予測するのには、今までの「奴ら」の「行動（何をしたかの履歴）」を見ることでしょう。 ＭＳのｗｉｎｄｏｗｓはある程度存続し続けてきましたが、その中身は大きく変わりました。そしてＶＢ、ＡＣＣＥＳＳといった道具も当初とはすっかり変わってしまいました。 ＮＥＣは、過去２０年以上渡って「ＯＳ」「ツール」の継続性をほぼ完全に保証し続けてきました。 この辺あたりで判断するしかないでしょう。 それに見逃してはならないのは、「ＡＶＸ」のバックで「通奏低音」のごとく販売されている「ＡＶＸ実行環境」というやつです。 多分、枯れたＯＳである「ＡＶＸ」を継続することは今後のＮＥＣにとってそんなにシンドイ仕事ではないでしょうし、それに従来のお客さんをあえて逃すという必要もないでしょうし、かりに 万が一「ＡＶＸ」の存続が難しくなっても、 きっと「影の内閣」である「ＡＶＸ実行環境」を充実させ、そこへの移行パスを用意してくれるような気がします。 ＊ え、「それでもまだ心配」ですって？？？ どうしてもそのように思われる方には その時点で 「基幹業務側」を ＪＡＶＡに置き換えることをおすすめしています。 すでに、「基幹業務側」は「分離」され、「最小化」されていますから、置き換えはきっと現在のシステムより「やりやすい」と思いますよ。。 （仕事が忙しくなってきたので、複数号をまとめてワンページに書いて、とりあえず 「完」 ） オソマツ。 |