片貝さんの「安易なシンクライアント化を絶対に阻止する 」がプチ炎上のご様子です。片貝さんとは約20年前のアスキー時代からおつきあいさせていただいています。今もいろいろお世話になっていますが、私は基本的にシンクライアント大好き人間です。ばんちょ～さんにてくてくテクネコは中身も詰まっているところをお見せするためにも(笑)、ここは一つまじめに異論を述べたいと思います。

一口にシンクライアントと言っても、ハードウェアやソフトウェアのアーキテクチャがいろいろあります。以下のシンクライアントの定義は、シトリックス社のPresentation Server製品を前提としています。(Presentation Serverは現時点で名称がXenAppに変更されています。)

私はなぜシンクライアントが好きなのか

私が初めてシンクライアントに出会ったのは、2000年の頃です。当時はERPベンダーに勤めていて、テストのためにサーバーにERPパッケージをインストールする作業が日常的にありました。ちょっとした設定変更や確認をする時は、サーバールームまで行かなくてはいけませんでした。けっこう面倒だなあと思っていたところ、VNCというフリーのリモートデスクトップソフトを導入した人がいて、作業効率が一気に改善されました。

その後、シトリックス社のMetaFrame Presentation Server(Presentation Serverの1世代前の商品)上でERPパッケージの動作を検証することになり、MetaFrameを使う機会がありました。VNCはコンソールを他のPCから遠隔操作するだけでしたが、MetaFrameは一種の仮想PCのように異なるWindowsデスクトップを複数同時に動かすことができました。アスキー時代にUnixサーバーとX端末を使った経験もあって、MetaFrameはWindows版X端末と言うことで理解しやすい概念でした。

(余談ですが、MetaFrameとVMwareは、ブラウザの発明にも匹敵するITを変えるパラダイムシフト製品だと考えています。)

その頃のITシステムのアーキテクチャは、クライアント・サーバー型(C/S型)が主流でした。C/S型ではクライアントとサーバーの間で頻繁に大量の通信が発生します。通信環境が遅くて高価であったため、本社にサーバーを置いて遠隔地のクライアントから使うことは実用的ではありませんでした。MetaFrameでは、本来クライアントPCで動かすアプリケーションをMetaFrameサーバーで動かして、画面の書き換えやキーボード・マウスの入力の分のみネットワーク通信が発生します。このため、ISDNのような遅い回線でC/S型の業務アプリケーションを動かす解決方法として使われることが多かったようです。

ユーザ企業IT担当者の憂鬱

その後、私はIT業界を離れて、ユーザ系企業F社に情報システム部長として入社しました。

F社は一般消費者向けブランド商品販売の会社で、ほとんどの店舗は全国の百貨店や商業施設の中にあります。各店舗の売上や在庫を管理する販売管理システムが基幹システムです。その数年前にシステムを導入した時点では、ISDNの常時接続さえ一般的ではない時代でしたので、各店舗のパソコン上にローカルのデータベースを持っていて、朝晩に本社とダイアルアップで一時的に接続してデータの送受信を行い、データベースを同期する仕組みになっていました。

データの同期は店舗のパソコンと本社のサーバーが直接通信するのではなく、途中のIP-VPN上の中継サーバー経由で行います。理論上は美しい3階層の分散データベースシステムなのですが、実際の運用は簡単ではありませんでした。店舗と中継サーバーと本社の間でいろいろの理由でデータの不整合が頻繁に発生して、情報システム部はその対応に日々追われていました。

シンクライアント化の決断

サーバーの老朽化や処理速度・ディスク容量の不足等で、2004年にシステムをリプレースすることが決まった時、以下の選択肢がありました。

案1)単純にサーバーを最新のものに買い換える

案2)ブラウザベースのアプリケーションに全面的に開発し直す

案3)シトリックス社のPresentation Serverを導入して店舗をシンクライアント化する

案1は技術的に一番簡単で手間が少ない方法でしたが、各店舗の売り上げや在庫をリアルタイムに把握したいという業務上の用件で却下になりました。お金がかかるだけで出来ることは何も変わらない点も、情報システム部としては経営層にアピールしにくいものがありました。

案2は技術的にトレンド最先端でしたが、以下の理由で現実的に無理でした。

• 長年の追加開発でシステムの仕様がわからなくなっている部分がありました。「前のシステムと同じ動き」にすることが非常に困難であると予想されました。
• 年末の書き入れ時を控えて、スケジュールが非常に厳しく、しかもシステムダウンなどの失敗が許されない状況でした。新規開発で始めからトラブル無しを実現するのは無理でした。
• 開発の費用が受け入れがたいくらい大きくなると予想されました。
• 画面のインタフェースがどうしても変わってしまうため、実際にシステムを使う店舗スタッフのトレーニングが必要になります。店舗スタッフは全国に散らばっていて、全員を集めてトレーニングすることは不可能でした。

結局、SI会社で同じシステムをPresentation Serverでシンクライアント化した実績もあって、案3が採用になりました。

シンクライアントシステムでは、本社のサーバーが停まったりネットワークが切断されたりした時に、全店舗で業務が停まるリスクがあります。本社や倉庫のネットワークの増強や二重化、店舗の回線のADSL化などの準備を経て、販売管理システムは無事にシンクライアント化されました。

システム切り替えのトレーニングは店長のみ集めて行っただけでしたが、店舗での起動方法が変わるだけで使い勝手は全く同じであるため、切り替えに伴う店舗スタッフからの問い合わせはほとんどありませんでした。

シンクライアント化によって、データベースは本社サーバーの一カ所のみとなりました。データの不整合が基本的になくなると同時に、最新の各店舗の売り上げと在庫をリアルタイムで情報共有できるようになりました。

時期的にはちょうど個人情報保護法の施行と重なって、百貨店内にある店舗のパソコンに顧客情報が入っていることがリスクになった時でした。他のブランドですが、店舗のパソコンが盗難に遭う事件も実際に起きました。シンクライアント化して成功だったと考えます。

以上が私のシンクライアントの経験です。この経験をもとに後編に続きます。

このエントリはジャストシステムのxfy Blog Editorで書いています。