MKCスタットのノーツDBは、
- 通達や申請書、全社掲示板、稟議書など全社共通の情報を格納した共通DB
- 各拠点ごとに必要な業務情報を格納したローカルDB
- 複数の拠点で必要に応じて設置されるローカル共通DB
の3種類に分かれている。
この3種類のDBの中で、1の共通DBは各拠点で共通にシェアする必要がある。そのためハブサーバを大阪に設置して、全国13カ所の拠点にレプリケーションが行なわれている。たとえば、長野のノーツDBが更新されると、次回更新時には松本のハブサーバのDBが更新され、他の拠点のDBもハブサーバのデータをさらにレプリケーションする。全国的に同期がとられるまで、2回のレプリケーションが行なわれるわけだ。更新のタイミングだが、スピードが要求される稟議書のワークフローなどは、1時間ごとに更新がかけられ、各拠点にレプリケーションするように設定されている。
一方、3ローカル共通DBはハブサーバを経由しないレプリケーションを行なっている。図を見てもらえば分かると思うが、同じ首都圏事業本部でも、東京近郊にはいくつも事業所が散在している。これらの事業所間や各拠点同士のDBはハブサーバを経由せず、ローカルDB同士でレプリケーションがとられている。「たとえば東京と名古屋で1つの大きなプロジェクトを進めるといった場合、各拠点、事業所で同じようにそのプロジェクトに関するノーツDBを見る必要があります。そういった場合は、ローカルDB同士をレプリケーションする方法をとります」(水谷氏)。
ノーツのDBがこれだけ分散配置されていると、こうしたレプリケーション方法にも工夫が必要になってくるようだ。各拠点では専任のノーツサーバとネットワークの管理を兼任する担当者が設置されており、ノーツDBの管理はもちろん、定期的なバックアップや、トラブル時の対応まで行なっている。こうした運用に関しても、関西事業本部がイニシアチブをとっており、技術本部でまかないきれない専業的な部分をフォローしているという。「普通の企業だと、こうした仕事は余分と見られがちじゃないでしょうか? でも、最近のお客様の要望をみると、CやCOBOLでプログラムを組める人より、こうしたインフラを作れるとか、Web技術とかノーツに詳しいとか、そういった人のほうがニーズがある。ですから、こうしたシステム作りや管理を勉強させて、人材を育てていくんです」(水谷氏)という社員教育という面も持っている。
こうした環境を構築することで、各地に分散した拠点から共通にノーツDBが利用できるようになったのがメリットだという。たとえば、「新しい製品を開発することが決まったが、具体的にどうしたらいいか分からない。経験ある方は何か教えてください」といった書き込みを掲示板に行なうと、場所が離れていても、関連する社員が掲示板に書き込んだり、メールを投げるといった親身になった社内サポートが行なわれているという。
また、ノーツDBだけでなくノーツメールもホームサーバ(ノーツクライアントのデフォルトとなるサーバ)拠点でなくとも、全国どこからでも利用できる。たとえば、別拠点に出張になっても、IDファイルの入ったフロッピーを携帯し、現地のマシンからログインすることで、ノーツからメールを利用することができるわけだ。
