子だくさんIT社長のFileMaker日記[30]FileMakerで人々を幸せに!(2)/茂田カツノリ

投稿:  著者:  読了時間:6分(本文:約2,800文字)


こんにちはっ、茂田です。先週の続きです。

●大資本に負けない効率化を!

前回書いた通り、パソコンを清書機としてしか使っていない状況は現場にとっての不幸だ。でも、それは重々わかってるけどシステム開発には結構なお金がかかるから無理よ、という声も多いだろう。

大企業なら億単位以上のお金をかけてシステム開発できるが、中小企業はそうもいかず、また大企業内でも数人〜100人程度のみ利用するシステムについては、そこまでお金かけられない。

さらにいうと、業務を自動化するためには現在の業務を再分析し、例外状況を検討し、必要な結果や効率化のポイントについての決定が必要。大きな会社であれば、仮にIT化されてない部分であっても一定の業務設計はしているものだが、小さな会社では、こうしたシステムに必要な要件を決める部分も効率良くとはいかない。

でもね、「大資本ならできるのに」というだけじゃ世の中つまらない。小資本でも零細企業でも、たった一人でやってる会社でも、大企業と同じレベルかそれ以上の自動化・効率化を実現してみせよう、そしてそれができるのがFileMakerなのだ。

僕自身、そういう思いが根っこにあるので、自分のビジネスが成立する範囲でできるだけ安くて良いものをご提供したいという気持ちでやってきたのだが、それでだいぶ自分の首を絞めた上に、思いがうまく世間に伝えきれなくて絶賛屈折中であったりはするが。



●データベースは設計がすべて

いつも書いているとおり、FileMaker自体は決して個人〜中小企業のためのものでなく、数万人規模の企業におけるサブシステム用としても重宝する。

でもやっぱり何より素晴らしいのは、大資本が億単位のお金をかけて実現するようなシステムを、中小零細や個人企業でも実現できてしまう点だ。

もちろんシステム開発には一定のお金はかかる。でもそれで一人分の労力が浮かせられれば大きいし、なにより顧客からの要望に対して迅速かつ正確に対応できるようになれば、競争力という点で有利だ。

こうした業務効率化については、できるだけある一定期間に集中して改善し、満足のいくレベルまで前進させておくことが大事。

では、どういう手順でシステム開発を進めれば良いだろうか。

できるだけ自分でやりたいという人、開発会社に依頼したいという人ともに共通した、ひとつの重要ポイントがある。それは「データ構造の設計がうまくできてない例が多い」という点だ。

FileMakerにはふたつの要素がある。ひとつは関数・スクリプト・ボタンなどにより、業務処理アプリケーションを容易に作成できる要素、もう一つが高性能なリレーショナルデータベースという要素だ。

このうち、アプリケーションを作成する機能は、実はものすごく簡単。他のアプリケーション開発環境ではここの習得に時間がかかるわけだが、FileMakerではスクリプトは一覧から選んで設定するだけだし、レイアウトにボタンを配置して画面設計をする部分も簡単。関数はちゃんと覚える必要はあるが、そんなに難しくはない。

だが、リレーショナルデータベースという部分の設計にはそれなりにノウハウが必要で、これはたとえばプログラミングはバリバリできるけどゲーム系やってた、という人も含め、一定程度の学習が必要だ。

FileMakerを使っていると、アプリケーション構築的操作に目が行きがちで、このへん覚えたからもうFileMakerは征服したと勘違いする場合も実は多い。しかし、そうして作成した多くの業務ソフトが、リレーション設計の基本が間違っているなんてことがとても多いのだ。

そして、基本設計がうまくいっていないデータベースは、そのあとで機能を増やしてゆくとどこかで破綻する。だから、自分で作るにしても一部外注するにしても、まず一番の初期段階におけるデータベース設計は、信頼できる本当のプロにまかせたほうがいい。FileMakerの関数やスクリプトは見よう見まねでもそこそこいけるが、設計だけはちゃんとした知識を要するのだ。

基本設計というのは、具体的には処理したいデータをどういうテーブルに分け、どういうリレーションキーを付け、どういう関連付けをするか、という点にある。このへんについてはFileMakerにおける「お作法」のようなものが存在するので、これを守って構築しておけばあとの機能追加もラクなのだ。

●総額見積 vs 時間課金

システム開発を業者に依頼すると、やっぱり結構な金額になる。もちろん開発に手間はかかるけれど、それ以上に仕様がきっちり決まらなかったり、ある程度開発が進んだところで機能変更があったりといったリスクが、見積に含まれているという要素もある。

システム開発側にとっては、発注側から明確で具体的な希望が出てこないことや、ある程度進んでから割と根幹に関わる部分の話が変わったりすると、開発は永遠に終らないことになり大変な思いをする。これをいかに避けるかというところが大事で、だから開発前に仕様書や実装機能リストを作成して「ここから逸脱したら追加費用ですからね」と線引きするのが普通。

こうしたチェックリストはもちろん必要ではあるが、開発側の自己防衛が必要な案件はどうしてもそのぶんの手間が増え、費用も増大する。

僕はアメリカで仕事を受けていたときは、原則として時間課金だった。消費した時間とそれによって得られた成果とをお客様に報告し、承認していただいてその結果を課金するという形だ。日本ではこの考えがなかなか受け入れられないので、実装する機能をあらかじめ限定した上で、依頼側の都合で増大しそうな工数も織り込んで見積もることになる。

総額見積と時間課金のどちらが良いかは案件次第だが、固定見積は工数増大のリスクを開発側が負うので、その分のリスクを含んだ形となる。一方時間課金はそのリスクを依頼側が負うぶん、本当の開発工数だけで済むのではあるが、世の中いろいろと難しいものである。

【しげた・かつのり】FileMaker公認トレーナー/FileMaker11認定デベロッパー。株式会社レクレアル代表取締役。本コラムに書いたことを具体的にどうやって解決しようというのだ? という話はある種宣伝めいちゃう部分もあるので割愛。ご興味持っていただけた方は、僕の会社サイトでメルマガ登録をお願い致します。あ、データベース基本設計だけの依頼も大歓迎ですのでよろしくです。

・FileMakerデータベース構築をサポートするメルマガ「FMサポーターズ」
< http://bit.ly/fmsBN >
株式会社レクレアル < http://www.recrear.jp/ >
Twitter(個人用)< http://twitter.com/shigezo >
Twitter(会社用)< http://twitter.com/FileMaker_etc >
Facebook(個人用)< http://www.facebook.com/k.shigeta >