産業用電気機器 卸売業 様
(本社所在地: 東京都)

システム導入の課題・要望

　先ず、利用拠点が10ヶ所あるのですが、結局Accessシステムはパーソナルの域を出ないので、ローカルな環境では機能を発揮しますが、それらの集中管理ができないので、利用拠点ごとに仕組みをコピーして、各モジュールとデータベースをセットで各利用拠点に展開していました。そういう状況の中で、業績拡大を図る会社経営陣からして見ると、システム自体が力不足ではないかと指摘を受けていました。
　また、AccessのMDBで扱える大きさが、2GBの制限がある中で、税務上10年ぐらいは過去のデータを残しておく必要があります。その他、営業的にもお客様から過去の取引の引き合いが何度かあると、更にデータが溜まっていくわけです。
　そのような2つの点から、大量データを管理するには不安がありますし、各モジュールを点在する各利用拠点で保持するということは、運用コストが掛かることになるわけです。直近での１番のイベントは消費税増税(5%→8%)、このようなイベントがあると、待ったなしに全利用拠点への対応に追われてしまいます。このようなイベントがあると集中管理したいということになるわけです。

dbSheetClient・Access版を採用した理由

　当初は、パッケージ（クラウド型）システムを最終的に、3社ピックアップして、デモンストレーションまで行ってもらいました。社内でデータエントリーを行うメンバー（利用者）に評価してもらいましたが、見た目のギャップ（Accessシステムで慣れた操作性とパッケージシステムとのギャップ）があり、実際の導入に際しては、そのギャップをどのようにして埋めていくか（改善するか）という問題が出てくるので、それなりの時間が掛かるという結論になりました。

　その後、グループ会社（システム専門会社）に、Accessで作り直すイメージで見積もりを取ったところ、逆に、ニューコムさんのdbSheetClient・Access版の紹介を受けました。パッケージシステムの導入には、かなりの時間（ギャップを埋めるために）掛かるというので、先ずは、データ管理と集中管理をしたい当社ニーズに対して、Accessシステムのままで、即効性を求めるには、このシステム（dbSheetClient・Access版）の導入が1番であることが確認できたので採用に至りました。

1. データの集中管理が出来ること → データはサーバーの強固なデータベースで管理が出来ること。
2. 各モジュール(プログラム)は、サーバー経由で自動配信出来ること。
3. 内部統制を構築するシステムとして、運用管理・メンテナンスが集中管理(1ヶ所)出来ること。

　これまで、各拠点のAccessシステムは、コピーした瞬間から独自の歩みを行っていました。拠点ごとのモジュール（プログラム）を管理しながら、大きなイベントがあった場合、n倍（拠点の数）の作業が発生していました。これが解決できるのは大きなメリットです。

システムの導入・開発の経緯と導入効果

　先ず、2014年11月に、ニューコムさんのプレゼンセミナーに参加しました。その後、直接、システムの提案を受けてから、2015年2月に導入しました。2月末に、dbSheetClient・Access版の教育を受けて、3月～4月の2ヶ月間で、ニューコムさんが提供しているAccess APIを適宜モジュールに組込みを行い、5月～6月の2ヶ月間で、本社の2拠点でテスト運用を行い、7月から本稼働に移行しています。

　開発者の立場からは、システム改修する上で、「CockpitViewer」と「ServerLogViewer」には、大変お世話になっています。 「CockpitViewer」は、データベースの更新状況を調べるためです。「CockpitViewer」はGUIが優れていて、SQL文の書き方が分からなくてもデータ検索ができること。また、検索した時のSQL文が表示されて参考にできること。そして、GUIから作ったSQL文をアレンジでき、更に 簡単にExcelへ書き出せることです。
　「ServerLogViewer」は、システムが安定していない状況下では、朝からウオッチしながらエラーの発生を調査しています。利用者の感心度が低いとエラーが発生しても開発まで連絡して来ないので、バグの収束が進まないため、大変助かっています。

＜CockpitViewer(コックピットビューアー)の画面例＞

　システム管理者や開発者がサーバーDBを一元的に閲覧できるビューアーです。（SQL Server/Oracle等の異なるDBをコンボボックスだけで選択し、テーブルの中身を見ることができます）

CockpitViewerが提供する基本機能は以下のとおりです。

1. dbSheetClientサーバーに登録済み「データベース(DB)」の一覧を参照することができ、各DBのテーブル一覧およびレコードが参照できます。
2. 対応するデータベース(DBMS)はSQLServer、Oracle、MySQL(ODBC)、PostgreSQL(ODBC)です。
3. 接続データベース(DB)に対しSQL（クエリ）の結果を表形式で参照できます。
4. 各DB内のビュー(View)やストアドプロシージャの定義を参照することができます。
5. 一覧表示されたレコードをそのまま「Excel」表示し、Excelファイルとして保存することができます。
6. さまざまな検索方法(前方一致、中間一致、あいまい検索等)でレコード検索が可能です。

＜ServerLogViewer（サーバーログビューアー）の画面例＞

ユーザーがdbSheetClientサーバーにログインし、プロジェクト実行開始からログオフするまでの操作ログ情報を確認できるビューアーです。

ログ情報は以下の操作がおこなわれたときに記録されます。

1. ログイン時刻（プロジェクトは選択されていないのでプロジェクト名は空白）
2. 実行版・開発版でプロジェクトが実行開始されたとき
3. 実行版・開発版でプロジェクトが実行終了されたとき
4. 実行版で、保存・印刷処理が実行されたとき
5. 実行版でショートカットキーを利用して許可されない保存・印刷・終了処理が実行されたとき
6. 実行版でタスクタイプの「ログ情報書込み」処理が実行されたとき（上記以外の実行環境での操作でログ情報として書込みが必要な操作については開発版でタスクタイプとして定義します）
7. 開発版でプロジェクト定義情報などの各種アップロードが実行されたとき
8. ログオフ時刻（ログイン画面に戻ったとき）
9. 端末ログオフ時刻（dbSheetClientを終了したとき）
10. 実行版で、実行時にエラーが発生したとき
11. 実行版で、ファイルアップロードが実行されたとき
12. 実行版で、ファイルダウンロードが実行されたとき
13. 実行中にエラーが発生したとき
14. 実行版・開発版でＳＱＬ文を実行する処理をおこなったとき

　管理者の立場からは、修正したモジュールをサーバーにアップするだけで、自動的に各拠点の端末のプログラムが更新されるので、管理が大変楽になりました。以前は、モジュール（プログラム）を変えた時には、各拠点に案内を出して、切替用のコピーモジュールを送って、きちんと各拠点で更新してもらうことに結構神経を使っていました。その作業工数が、1/10になったわけです。もちろん、運用管理・メンテナンスが集中管理（本社で）出来るからです。
　また、システム利用者は、これまでの操作性のままで使っているので、ある面、別システムを入れることに比べてはるかに問題（違和感、あるいはストレス）なく、スムーズに移行ができました。
　当初は、パッケージ（クラウド型）システムの導入を検討しましたが、相当な工数・費用を掛けないと移行は難しかったと思います。dbSheetClient・ Access版は、既存のAccessシステムを短期間で、生まれ変わらせてくれる画期的な開発ツールだと思います。

今後について

　社内には、まだ、dbSheetClient・Access版を組み込んでいないAccessシステムが複数存在するので、あと、半年ほど掛けて開発を進めたいと考えています。また、社内には、Excelの定型業務もあるので、今後は、dbSheetClient・Excel版で、新たな業務システムを構築して、業務の効率化を図っていきたいと思っています。