どもー、本号発行時にはカリフォルニア出張中の茂田です。
もうすぐ生後9ヶ月になるうちの第4子はとってもよく笑う。目が合うとニコッとする。とてもかわいいのだった。子育てはどの段階もそれぞれ楽しいけれど、赤ん坊の時期は独特というか特別というか、この時期にしかない楽しみがあるかなと思ったりする。
上の2人はもう小学生で、彼らが大人と同レベルで食べやがるので、ファミレスの会計でどひょーん、となる日々であったりする。
●プロが作るのはデータベースじゃなくく「特定業務専用アプリ」だ
僕が本職にしているFileMakerは、「とっつき」がとても良い。大量のデータを放り込んで検索かけたり、自在にレイアウトして表示して印刷してというくらいであれば、本当に一日くらい練習するだけで作れてしまう。
つまりFileMakerを、データ放り込む入れ物や、ワープロでいう「差し込み印刷」のように、いわば"清書機"としてしか使ってない形だけれど、このくらいでも仕事の効率化には十分寄与する。
もちろんFileMakerの性能はこんなものじゃない。もっと業務の効率化に直接寄与し、いつも使う処理を自動化し、さらに「リレーション」という、紙ベースでは表現できない概念を使った処理も可能になる。
特にプロが作るものは、もっとずっと処理のレベルが高い。処理対象となるデータを最適な形で構築し、単なる「データベース」ではなく「特定業務専用アプリ」と呼べるようなものになる。
もうすぐ生後9ヶ月になるうちの第4子はとってもよく笑う。目が合うとニコッとする。とてもかわいいのだった。子育てはどの段階もそれぞれ楽しいけれど、赤ん坊の時期は独特というか特別というか、この時期にしかない楽しみがあるかなと思ったりする。
上の2人はもう小学生で、彼らが大人と同レベルで食べやがるので、ファミレスの会計でどひょーん、となる日々であったりする。
●プロが作るのはデータベースじゃなくく「特定業務専用アプリ」だ
僕が本職にしているFileMakerは、「とっつき」がとても良い。大量のデータを放り込んで検索かけたり、自在にレイアウトして表示して印刷してというくらいであれば、本当に一日くらい練習するだけで作れてしまう。
つまりFileMakerを、データ放り込む入れ物や、ワープロでいう「差し込み印刷」のように、いわば"清書機"としてしか使ってない形だけれど、このくらいでも仕事の効率化には十分寄与する。
もちろんFileMakerの性能はこんなものじゃない。もっと業務の効率化に直接寄与し、いつも使う処理を自動化し、さらに「リレーション」という、紙ベースでは表現できない概念を使った処理も可能になる。
特にプロが作るものは、もっとずっと処理のレベルが高い。処理対象となるデータを最適な形で構築し、単なる「データベース」ではなく「特定業務専用アプリ」と呼べるようなものになる。
もうちょっと具体的に言うと、たとえばメーカーと商品と顧客と担当者のマスターがあって、その中間に取引テーブルを置いてつなげる形としたとする。そうすれば、まず顧客ごとの購入履歴がわかり、メーカーごと商品ごとの売上集計や、担当者ごとの売上や取り扱いメーカー順位などもイッパツで出せるなど、要は多角的にデータを扱えるのだ。
ここで重要なのが、このような多角的なデータ表示や集計において、ユーザ側の操作はせいぜい表示するレイアウトを切り替えるくらいで、データ自体はリアルタイムに自動集計されるような仕組みとなる点だ。正しいリレーションモデルやポータルの活用が理解できれば、こうしたデータ構造の必然性もみえてくるというものだ。
しかし残念ながら、すべてのデータベースにおいてこうした正しい設計がなされているわけではない。FileMakerはとっつきが良く、プロとしての知識がなくても表層的には動くものが作れちゃうので、正確な知識を持たないままお客さんからお金取ってしまっている状況が存在するのも事実だ。
私の会社も、大変恥ずかしながら過去に退社した社員がおかしいものを作ってしまっていて、お客様に平謝りして修正した、という経験はある。お客様側の要求仕様がブレたりが原因のことも多いが、十分に気をつけるよう心がけてはいる。
そこで、FileMakerデータベースとして「こうだったらヤバイ」あるいは開発者について「これができなきゃプロとしてはヤバイ」的なものを、具体的にあげておこう。一般の人からみるとプロはみんなプロだけれど、その中には残念ながら、FileMakerのことを知らない人が混じってしまっているのは、悲しいながら事実なので。
▼繰り返しフィールドを使っている
FileMakerの繰り返しフィールドは禁断の技で、データを入力するものとして原則使ってはいけない。一番簡単な例をあげると、たとえば途中の行を削除したくなったとしても方法がない。たとえば、伝票の細目表示に使うなどはそもそも間違っているので、結果こうした不便が生じるのだ。
▼レコードに展開すべきものをフィールド数増やして対応している
複数の属性を保持させたいからと「カテゴリ1」「カテゴリ2」「カテゴリ3」などとフィールドを増やして対応している例。こうすべき状況もまったくないわけではないが、ほとんどの場合においてリレーションというものを理解できてないがためにこうした構造になってしまっているので、だとしたらかなりヤバイ。
▼スクリプト回してデータ加工をしている
データの集計や加工は、大抵の場合において適切なリレーションと計算フィールドにより実現する形が正しい。しかし、これをちゃんとやるには関数の正確な知識が必要。それがわからなくて、スクリプト回してデータを拾って加工するような作りになっていたら、結構ヤバイと思っていい。
▼FileMakerの素の検索機能を多用させられる
たとえば、商品データベースで目的の商品を探し当てるインターフェースを作る場合、ポータルフィルターなどのテクニックを使うもの。しかし、こうした処理を単なるFileMakerの検索機能だけ使うことを前提とした作りのデータベースは意外と多い。これはプロの仕事とはいえないぞ。
▼実データでリレーションを取っている
これは言語道断。こういうの発見したら開発者に「ここのPK/FKはどれ？」と聞いてみよう。「PKって何ですか」とか言われたら、次に行うべきはその開発者をお帰り口に案内することだ。
▼レコードのプライマリキーにGet（レコードID）を使っている
これも言語道断なんだけど、結構見たことある。理由はそのうちご紹介する。
▼TOG（ティーオージー）のお作法を守っていない
これは専門的な話になるので詳細は別の回に譲るが、FileMakerの技量をはかる明確な指標となる。あなたの会社に来た自称プロがこれを説明できなかったら、やっぱりお引き取り願おう。これは各種ある構築手法のひとつ、とかではなく、FileMakerのプロにとっては最低限の知識だから。
●人を見極めよう
FileMakerについては、その性能を過小評価する嘘がまかり通ってしまっているとは何度か書いているとおり。
先日も「FileMakerの場合は仕様解析が難しく、他人が作ったものの修正は無理」なんていう発言を聞いたのだが、しっかりとお作法に則った設計をしていれば、ほかの人にだってしっかりわかるものになる。逆に設計が悪ければ、どんなツールを使って構築してもダメなものはダメだ。
ほかにも「ファイルが壊れたら修復して使ってください」という、とんでもなく間違った説明をしている人もいるとの噂を聞いた。これはさすがに困るなあ。
もしいまプロに構築を依頼していて、でもちょっと不安だという方、私のほうにデータベースファイルを送っていただければ、簡易レポートと問題点のご指摘をする。私もガキ4人いるんでタダは困るんで、費用も含め相談してほしい。
もちろんもっと詳しい解析や活用法の相談、さらに基本設計の代行からトラブル撲滅もおまかせあれ、である（また宣伝になってしまった）。
FileMakerは仕事のあり方を根本から変える大きな力を持っているから、間違った使い方はしてほしくないとの思いがあるのだ。「見た目動いてればいい」というものじゃ困るから。そういう僕も偉そうなこと言えるのかって指摘はあると思うけど、誰を信じるかはご自分の目を信じ、自分で決めてほしい。それが人生だよね。
【お知らせ：FileMaker講座開催・大阪開催】
今年に入ってから毎月1〜2回は実施している中部・関西でのFileMaker講座。次回は下記内容にて開催となります。詳細およびお申込は下記「株式会社レクレアル」のサイトをご覧ください。
◎LetもEvaluateも語り尽くす！FileMaker関数徹底学習講座（その1：総合編）
FileMakerをしっかり使いこなすためには必須である「関数」を、系列ごとにわけてしっかり学習する講座です。書籍やヘルプだけでは理解しきれない各種関数を、ハンズオンによりしっかり習得します。
日時：2010年3月27日（土）9:30〜18:00
会場：大阪府社会福祉会館（大阪・谷町）
費用：お一人18,000円＋税（OSMC会員の方は割引あり）
講師：茂田カツノリ
【しげた・かつのり】FileMaker公認トレーナー／FileMaker認定デベロッパー。株式会社レクレアル代表取締役。例によってTwitter活動により急激に人生が変化し始めてる。特に仕事方面。だけどこれからTwitterやる人もっと増えるだろうから、そうなったらもう遅いかもね。
Twitter（個人用）< http://twitter.com/shigezo
>
FileMaker情報メルマガ配信中！登録は以下で
< http://www.recrear.jp/
>