よく、WebとＤＢを連携させ、ショッピングサイトとか、EC(ヨーロッパ共同体、ではなく、当然Eコマースのほう）とかを実現させたいっていう話がありますよね。
で、そういうセミナーなんかを聞いてきて、ソフトハウスに提案させた場合、結果として、金食い虫システムになってしまうことがあります。
まず、WebとＤＢを「連携させる！」といった場合、連携って行ったら、一緒に動くっていうことだから、同じところにないといけないよね。。。ということになってしまいます。
そうすると、提案は、以下の２とおりに限定されちゃいます。
WebサーバーとＤＢサーバーを社内におく
WebサーバーとＤＢサーバーを社外（レンタルサーバーなど(ASP事業者含む））におく
WebサーバーとDBサーバーを社内におく場合、グローバルＩＰをもらい、Ｗｅｂサーバーを公開すれば、このシステムは実現できます。
ただし、Webサーバーを社内に置くということは、だれか、そのサーバーのお守りをしないといけないということです。
それだけの技術が社内にないのであれば、技術者を雇うか、保守料をはらって、業者になってもらうしかありません。
この場合、WebもＤＢも、社外の、たとえば、レンタルサーバ会社のものになります。だから、「動作がおそーい！」などと、文句は付けられません。その会社は、あなた一人のためにサービスしているのでは、ないのですから。
つまり、もし、そういうシステムを構築した場合かりに、パフォーマンスが悪くても、ちょくちょくサーバーが落ちたり、保守点検で使えなくなったり、あるいは、操作ミスでＤＢのデータが飛ばされたりしても、文句言えない（かりに文句いっても、事態が改善される見込みは小さい）ということです。
結果として、リスクが大きいシステムになります。
結局、大きなリスクをとって社外に置くか（しかし、情報保護の観点から考えても、リスクが大きいので、この線はあまりなさそう）、保守料とかお金を払って、社内に置くしかないことになります。
が、実は、「連携」という言葉さえ除けば、ユーザーから見たとき、似たような効果を出すことが出来るものがあります。
それは、社内にＤＢをおき、Webページを作成してしまって、そのホームページを一定時間に自動的にFTPで転送する方法（コピーするほど儲かるシステムでは、ＤＢのかわりにExcelで、この方法を採用します）、ないしは、ＤＢに入っている商品データをテキストファイルで、サーバにＦＴＰで転送する方法です。
では、「社内にＤＢをおき、そのページ（またはテキストデータ）をWebサーバーにFTPで転送する」場合の問題点はどこでしょうか？つまり、ＤＢを連携しない場合の問題点です。
ＤＢを採用する目的は、一般に「一貫性、共用性、独立性」です。この場合、独立性は、プログラムの書き方で実現できたとしても（カプセル化で）、一貫性、共用性で問題が出ます。
つまり、以下のようなケースです
・データ転送中に、購入している人がいて、一部の購入品目が、データ転送前の金額、他の一部の購入品目が、データ転送後の金額になる可能性がある（一貫性の問題）。
・在庫と連動するようになった場合、在庫がなくなったとしても、Ｗｅｂ上のデータには反映されないので、まだ変えてしまう。逆に在庫が入っても、まだ注文できないこともありえる（共用性の問題）
上記の問題は、リアルタイムに金額が変わるものでなければ、あらかじめ、変更値段を送信しておき、所定の時刻になったら、いっせいに入れ替えればＯＫです。
後者の問題に関しては、これを実現するとなると、社内にサーバーを用意し、システムを組む形になると思います（もし、社外にＤＢがあるとすると、それと連動させるには、社外に在庫プログラムがあり、Ｗｅｂで操作することになる。この動作時間は結構遅く感じるはず）。
つまり、後者を実現させるには、社内にサーバを置くということになるのですが、それを実現するには、かなり大きな投資が必要になります。
したがって、その会社のことを考えたら、
まずは、
・「社内にＤＢをおき、そのページ（またはテキストデータ）をWebサーバーにFTPで転送する」
そして、将来的には、
・「社内にＤＢとＷｅｂページもおくようにする。そのときまでに、お守りの人が手配できるようなビジネスモデルにする」
というのが、妥当な考えです。
でも、どんなにその会社のことを思って、上記の考えを提案書に書いたとしても、まず通らないと考えるのが普通ですよね。
なぜなら、この提案を依頼した人は、多分「WebとＤＢを連携させると、売り上げが上がる（ないしは儲かる）」という話やセミナーを聞いて、提案を求めたのだから、そこへ、「いやWebとＤＢは連携させないようにしましょう」といっても、投資する根拠がありません。
これは、前に書いた、「とんかつ弁当の論理」だ。
さらに最悪なことに、この提案では、結局、最終的には、「社内にＤＢとＷｅｂページもおくようにする。」わけですから、結局、はじめのWebとＤＢを連携させないシステムを作る分、無駄な費用のように思ってしまいます。
このとき、「いや、一見そう見えるけど、じつは、はじめは連携させないほうが、保守費用をはじめから払わないですむ分、結果として安上がりだ」という明察をするユーザーは少ないです（そういうユーザーは、はじめからWebとＤＢを連携させよ！といった技術論の提案を求めないのが普通）。
もし、この提案で行けば、他社の営業から、その点を付かれ、さらに、「このドッグイヤー（っていう言葉も好きだよねーＩＴ業界の人）の時代に、そんな２段が前なことをやっていたら、他社に遅れます」といわれてしまい。。。
結局、妥当な案はＲＦＰの対応表を作っていく中で消され、
WebサーバーとＤＢを社内におくか、社外に置くかの案になる。
で、とくに、社内においた場合、結局、保守が必要になってくる。さらに、この場合、保守料分、損益分岐点が上がる＝たくさん売んなくっちゃいけない。
だから、たくさんアクセスしてもらうために、ＳＥＯのコンサルを入れたり。。。とかになってきて、結局、金食い虫システムとなる。
ちなみに、SEOとかとはちがうけど、乙部綾子さんって入れると、ヒット数上がるみたいよ！？
これが、株式投資であれば、このからくりのおかしさはわかると思う。
Web+DBが儲かるのようなセミナーは、株式投資でいうと、「中国・インド株は儲かる」のような著名なエコノミストのセミナーに相当する。だからといって、そのあと、証券会社の社員を呼んで、推薦の株や投資信託を買ったら、危険がいっぱいっていうことは気づくだろう。
ふつう、自分の投資哲学、投資理念と、資金量に応じて、売買を行う。
ところが、ＩＴ投資となると、著名な先生や事例を信じ、はやりものをどんどん取り入れてしまう。ＩＴ投資に対する哲学、理念がない企業も多いのではないだろうか。
もちろん、長期ビジョンは資金量とは関係なく、借入金をおこして、ＩＴ投資を行うギャンブルに賭ける。
もし、ＩＴ投資と株式投資が投資なんだから同じと考えれば、先ほどの
・「社内にＤＢをおき、そのページ（またはテキストデータ）をWebサーバーにFTPで転送する」
がヘッジにあたり、
・「社内にＤＢとＷｅｂページもおくようにする。そのときまでに、お守りの人が手配できるようなビジネスモデルにする」
で勝負する。という構図も見えるだろうし、もし、大きく負けた経験があれば、ヘッジングの重要性はわかるだろう。
でも、ＩＴ投資と株式投資が一緒と考える人は、まずいない。
ということは、この業界、まだまだ、お金を使ってくれる会社が多数いるということで、安泰なわけだ。
で、そういうセミナーなんかを聞いてきて、ソフトハウスに提案させた場合、結果として、金食い虫システムになってしまうことがあります。
まず、WebとＤＢを「連携させる！」といった場合、連携って行ったら、一緒に動くっていうことだから、同じところにないといけないよね。。。ということになってしまいます。
そうすると、提案は、以下の２とおりに限定されちゃいます。
WebサーバーとＤＢサーバーを社内におく
WebサーバーとＤＢサーバーを社外（レンタルサーバーなど(ASP事業者含む））におく
WebサーバーとＤＢサーバーを社内においた場合
WebサーバーとDBサーバーを社内におく場合、グローバルＩＰをもらい、Ｗｅｂサーバーを公開すれば、このシステムは実現できます。
ただし、Webサーバーを社内に置くということは、だれか、そのサーバーのお守りをしないといけないということです。
それだけの技術が社内にないのであれば、技術者を雇うか、保守料をはらって、業者になってもらうしかありません。
WebサーバーとＤＢサーバーを社外におく
この場合、WebもＤＢも、社外の、たとえば、レンタルサーバ会社のものになります。だから、「動作がおそーい！」などと、文句は付けられません。その会社は、あなた一人のためにサービスしているのでは、ないのですから。
つまり、もし、そういうシステムを構築した場合かりに、パフォーマンスが悪くても、ちょくちょくサーバーが落ちたり、保守点検で使えなくなったり、あるいは、操作ミスでＤＢのデータが飛ばされたりしても、文句言えない（かりに文句いっても、事態が改善される見込みは小さい）ということです。
結果として、リスクが大きいシステムになります。
実は、もう一通り方法がある
結局、大きなリスクをとって社外に置くか（しかし、情報保護の観点から考えても、リスクが大きいので、この線はあまりなさそう）、保守料とかお金を払って、社内に置くしかないことになります。
が、実は、「連携」という言葉さえ除けば、ユーザーから見たとき、似たような効果を出すことが出来るものがあります。
それは、社内にＤＢをおき、Webページを作成してしまって、そのホームページを一定時間に自動的にFTPで転送する方法（コピーするほど儲かるシステムでは、ＤＢのかわりにExcelで、この方法を採用します）、ないしは、ＤＢに入っている商品データをテキストファイルで、サーバにＦＴＰで転送する方法です。
連携させない場合の問題点
では、「社内にＤＢをおき、そのページ（またはテキストデータ）をWebサーバーにFTPで転送する」場合の問題点はどこでしょうか？つまり、ＤＢを連携しない場合の問題点です。
ＤＢを採用する目的は、一般に「一貫性、共用性、独立性」です。この場合、独立性は、プログラムの書き方で実現できたとしても（カプセル化で）、一貫性、共用性で問題が出ます。
つまり、以下のようなケースです
・データ転送中に、購入している人がいて、一部の購入品目が、データ転送前の金額、他の一部の購入品目が、データ転送後の金額になる可能性がある（一貫性の問題）。
・在庫と連動するようになった場合、在庫がなくなったとしても、Ｗｅｂ上のデータには反映されないので、まだ変えてしまう。逆に在庫が入っても、まだ注文できないこともありえる（共用性の問題）
上記の問題は、リアルタイムに金額が変わるものでなければ、あらかじめ、変更値段を送信しておき、所定の時刻になったら、いっせいに入れ替えればＯＫです。
後者の問題に関しては、これを実現するとなると、社内にサーバーを用意し、システムを組む形になると思います（もし、社外にＤＢがあるとすると、それと連動させるには、社外に在庫プログラムがあり、Ｗｅｂで操作することになる。この動作時間は結構遅く感じるはず）。
つまり、後者を実現させるには、社内にサーバを置くということになるのですが、それを実現するには、かなり大きな投資が必要になります。
したがって、その会社のことを考えたら、
まずは、
・「社内にＤＢをおき、そのページ（またはテキストデータ）をWebサーバーにFTPで転送する」
そして、将来的には、
・「社内にＤＢとＷｅｂページもおくようにする。そのときまでに、お守りの人が手配できるようなビジネスモデルにする」
というのが、妥当な考えです。
ところが、この妥当な考えは、提案としては通らない
でも、どんなにその会社のことを思って、上記の考えを提案書に書いたとしても、まず通らないと考えるのが普通ですよね。
なぜなら、この提案を依頼した人は、多分「WebとＤＢを連携させると、売り上げが上がる（ないしは儲かる）」という話やセミナーを聞いて、提案を求めたのだから、そこへ、「いやWebとＤＢは連携させないようにしましょう」といっても、投資する根拠がありません。
これは、前に書いた、「とんかつ弁当の論理」だ。
さらに最悪なことに、この提案では、結局、最終的には、「社内にＤＢとＷｅｂページもおくようにする。」わけですから、結局、はじめのWebとＤＢを連携させないシステムを作る分、無駄な費用のように思ってしまいます。
このとき、「いや、一見そう見えるけど、じつは、はじめは連携させないほうが、保守費用をはじめから払わないですむ分、結果として安上がりだ」という明察をするユーザーは少ないです（そういうユーザーは、はじめからWebとＤＢを連携させよ！といった技術論の提案を求めないのが普通）。
もし、この提案で行けば、他社の営業から、その点を付かれ、さらに、「このドッグイヤー（っていう言葉も好きだよねーＩＴ業界の人）の時代に、そんな２段が前なことをやっていたら、他社に遅れます」といわれてしまい。。。
結局、妥当な案はＲＦＰの対応表を作っていく中で消され、
WebサーバーとＤＢを社内におくか、社外に置くかの案になる。
で、とくに、社内においた場合、結局、保守が必要になってくる。さらに、この場合、保守料分、損益分岐点が上がる＝たくさん売んなくっちゃいけない。
だから、たくさんアクセスしてもらうために、ＳＥＯのコンサルを入れたり。。。とかになってきて、結局、金食い虫システムとなる。
ちなみに、SEOとかとはちがうけど、乙部綾子さんって入れると、ヒット数上がるみたいよ！？
これが、株式投資であれば、このからくりのおかしさはわかると思う。
Web+DBが儲かるのようなセミナーは、株式投資でいうと、「中国・インド株は儲かる」のような著名なエコノミストのセミナーに相当する。だからといって、そのあと、証券会社の社員を呼んで、推薦の株や投資信託を買ったら、危険がいっぱいっていうことは気づくだろう。
ふつう、自分の投資哲学、投資理念と、資金量に応じて、売買を行う。
ところが、ＩＴ投資となると、著名な先生や事例を信じ、はやりものをどんどん取り入れてしまう。ＩＴ投資に対する哲学、理念がない企業も多いのではないだろうか。
もちろん、長期ビジョンは資金量とは関係なく、借入金をおこして、ＩＴ投資を行うギャンブルに賭ける。
もし、ＩＴ投資と株式投資が投資なんだから同じと考えれば、先ほどの
・「社内にＤＢをおき、そのページ（またはテキストデータ）をWebサーバーにFTPで転送する」
がヘッジにあたり、
・「社内にＤＢとＷｅｂページもおくようにする。そのときまでに、お守りの人が手配できるようなビジネスモデルにする」
で勝負する。という構図も見えるだろうし、もし、大きく負けた経験があれば、ヘッジングの重要性はわかるだろう。
でも、ＩＴ投資と株式投資が一緒と考える人は、まずいない。
ということは、この業界、まだまだ、お金を使ってくれる会社が多数いるということで、安泰なわけだ。
アクセス
トータル
ランキング
