第四回　FileMakerによるシステムの再構築（下）

2017.07.02

連載の第三回では、FileMakerを使ったシステム再構築のケースを6つ挙げ、2つ目までを解説してきました。第四回は、続いて4つのケースを紹介します。

再構築のパターン

＜再構築の詳細＞

③便利なので作ってみたが設計がうまくできてなかった

　これは、FileMakerを使ってデータベースを構築してみたが、使い込んでいくについて、弊害も目に付くようになってくるケースです。
　データ量が多く処理時時間がかかるようになってくることもあります。

　構造を見せてもらうと、項目をつなぐ線がどこからどこにひかれているかわからないくらい氾濫していて、まるでアート作品を見ているようなこともあります。データの正規化がされていない、FileMaker特有の処理方式に対応するためのテーブル項目が多数つくられている、名前の付け方に統一性がないなどの課題が見えてきます。

　この場合、設計し直してきれいな基盤に再構築することにより、処理も早くなり業務もはかどります。さらに範囲を広げた開発も容易になります。

④十数年前に作ったものをそのまま使っている

　かなり前から、FileMakerを使っている方には、データどうしを連動させない閉じた使い方をしてケースが多くみられます。経営者の代替わりや、若手の社員が増えたりした時、業務の効率化や事業展開を考えて、システムをデータ連動させたデータベース的な使い方に変える必要性が出ています。

⑤ 外部に頼んで機能追加を続けてきたがもう限界

　外部の開発会社に依頼して開発を行い、使いながら機能追加をしていくケースでは、ある程度年数が経ったときに不都合が発生しやすくなります。
　FileMakerに限りませんが、開発会社の経営姿勢や担当者の変化などにより、対応が悪くなったり高額な改修費を求められたりすることがあります。ユーザ企業の担当者がシステムの内容を理解せず無茶な要求をしてこうした事態を招いてしまうこともあります。
　FileMakerの場合は、開発会社が受託したといっても担当者個人に依存した開発になりがちで、担当が変わるとプロセスが見えにくくなるのです。

　開発会社には、ユーザー企業の事業展開とともに成長をサポートしていくことが期待されます。ユーザー側は、自社の中にカウンターパートナーをしっかり設け、信頼関係の中で長く付き合えるようにしたいものです。

⑥ 汎用的な機能が詰まっているが自社にもう一つフィットしない

　ソフトを買う際には機能がいっぱい詰まっているのが良いように思えものの、いざ使い始めてみるとその3割くらいしか使っていないものです。
　利用している機能も、システムに合わせるために無駄な作業が増えたり、本当に見たい情報や処理したいことがタイムリーにできなかったりします。
　この場合、自社の業務にフィットしたもっと規模の小さいステムに再構築するというのが良い解決策になります。