補講：結局FileMakerってどこに使えるの？

久々に文章の形で。ゆかりさんの美声も、mikiユキの合いの手もありません。単なるおっさんの汚い文章で申し訳無い。何故そこまで卑下するか＞俺。いや実際、動画にしてもよかったのかもしれないんですけど、これはあくまで2012年5月7月時点で、という大きな但し書きがついてしまう故、動画にしたところでいつまで持つかというのを考えなければならんのです。あとは今回、知識やノウハウ云々というよりは多分に「意見」の要素を含みますしね。という訳でさっくり書けてさっくり消せる、従来方式を取らせて頂きます申し訳ない。

それで今回なのですが。直接間接を問わず、こんな問い合わせを頂いたり、頂かなかったりします。どっちだよ。

「ところどころでFileMaker推してるけどさ？本当にそれ使えるの？」

まぁそうゆう反応が来てしまうのも致し方ない。実際不安もありますしね。データベースソフト自体、触れる機会が随分と減ってしまったという歴史的経緯もありますから、今更こんなもん導入して大丈夫なのかよ？と訝しんでしまうのもわかります。そんな訳で、「どのような用途であればFileMakerは使えそうか」というざっくりとした指針みたいなものを挙げてみたいと思います。あくまで主観ですし、今回はいつも以上に話半分で聞いておくとよろしいかと思われます。

ではまずはざっと結論だけ羅列してしましょーかね。んっとこんな感じ。

●既存の帳票の置き換えとして
　→有効性：80%以上は置き換え可能
●既存システムやWebアプリケーションの管理機能代替として
　→有効性：50%程度は対応できる？
●iPad/iPhoneによるFileMaker Go利用を前提としての運用
　→有効性：20%未満？→40%程度に再評価

えらくざっくりと言い切ってるが大丈夫か？＞俺。順番に解説突っ込みましょう。

●既存の帳票の置き換えとして

はい、こちらに関しては本編番外編で散々言ってきた通りですね。本編番外編あわせて２時間以上動画でくっちゃべっててるので復習ヨロ。それでもちょっと強めに言ってしまえば、世に流通する数多の帳票は、あらかたDBに置き換えられる、つまり体系化も集約化も80%程度は可能だと思っております。

じゃあ残り20%は何か？を説明した方がいいのかなと。FileMakerに載せきることのできない情報とは？

ということになるんだと思います。要はやたらと図形描写を使用したものとかになる訳です。死にさらせExcel方眼紙とかもそうですね。この類。

もちろんFileMakerではファイル自体をフィールド内に格納できますので、それを用いて図表のExcelファイル直接突っ込んでしまうということもできなくは無いですが。やはり目視しないと中身が確認できない、という時点で利便性としては一段階落ちてしまうよな、というのが正直な感想です。

ちなみに図表であっても、既に完成していて更新の頻度が無い、あるいは低いのであれば、画像化して突っ込んでしまうことは、充分に可能だということは申し添えておきまする。

●既存システムやWebアプリケーションの管理機能代替として

これに関してはちょいとシステム寄りというか、技術者向けになってしまいますすんません。

企業内外で使ってるシステムにせよ、あれやこれやのWebアプリケーションにせよ、常にふたつの側面を持っています。ひとつは利用者側（つまりは私達）が使う機能。もうひとつはそれらを管理する側が使う管理機能です。

勿論利用側も管理側もいっしょくたにFileMakerに置き換えてしまう、ということもできるはできる、かもしれないんですけど。それはそれでリスクでもあるんですよねと。今使ってる機能はFileMakerでは使えないかもしれない。FileMakerの導入コストだけで、これまでの予算ブチ抜いてしまうかもしれない等々。

であれば、利用者側が使ってる機能はそのままに、管理側の機能だけをFileMakerに置き換えて手を抜ｋゴホンゴホン、コストと手数削減につなげることができるんじゃない？という考え方です。

こう言ってしまうと怒られるかもしれないんですが。経験上管理画面でやってることって、案外に簡単な処理で終わってしまうことって思いの外に多いんですよ。DBに値追加するだけとか変更するだけとか。だったらわざわざ専用のUI作るよりも、FileMakerのUIでDB弄ってしまった方が安く早く正確にできるんじゃね？ということなんですな。既存システムへはFileMakerの外部データアクセス機能を使ってしまえばええやんと。

勿論過信は禁物ですけどね。従来であればソースの中でやりたい放題だったロジックも、あの窮屈なスクリプトの中でやらなきゃいけなくなりますし。画面遷移的にも一抹の不安はありますし。だからこそ50%という一見安全圏な数値を設定してる訳です。実際に載せ替えが可能かどうかは、その対象をレビューして決めることになるでしょう。

※あと日本語文字化け対策のために有料の外部プラグイン（actual等）必須とかね。

とはいえこのプラン、案外魅力的ではあると思うんですけどね。わざわざ管理画面こさえてる暇なんかねぇよ、なんてケースにはうってつけでしょうし。管理画面分の工数で数十万すっ飛ばす位ならFileMakerのライセンス買った方が安いじゃん、なんてこともありえますし。という訳で気になる方はご検討をば。

●iPad/iPhoneによるFileMaker Go利用を前提としての運用

さてこれなんですけどね。20%。かなりネガティブな評価をさせて頂いております。今のところは。あぁこうゆうこと言うから私FileMaker畑の方とも仲良くできねぇんだろうなぁ。余計なことを書くな＞俺。

いやですね、確かに大ニュースなんですよ。Ver.12リリースにともなってFileMaker Goが無償化されたのって。特にエンタープライズ案件において、もっともネックになっていたのってFileMaker Goのライセンス料及び運用の手間でした。iPhone100台で回したい？じゃあ2300*100=230000円ね、といった数の暴力から解放されたというのは大きいです。これでようやっとiPod TouchなりiPadなりバラまいて展開できるぞバンザーイ、ができるようになりましたので、血眼になって売り込みかけてるベンダーさん営業さんも、さぞかしいらっしゃるんだろうなぁとは思うんです。

ですがね。いっくらGoが無償化になろうが、それ結局Server無いとメリット無いよね？ということを言わざるをえないんですな。

ご存知無い方に、乱暴な解説を。FileMakerには同時接続数という制限がありまして。ここでは概ねFileMaker Goから同時接続できる数だと考えてください。えーと表にしたほうがわかりやすいかな？

ライセンスFileMaker同時接続数
無印/Advanced9
Server250
Server Adv無制限
※詳しくはこちらで

こうなってるんですわと。えーとさ。正直少なくね？ちょっと大きな部署であれば、9なんかあっという間に使い切ってしまうんじゃね？という根源的な疑問があると。

あとこれはこちらの調べ不足かもしれないんですけど。無印またはAdvを無理矢理ホストにしてGoでも表示させる場合、常にホスト側で当該ファイルを開いたままの状態にしておかなきゃいけないんですな。この時点でホストとGoが、意図せずに同時に編集できてしまうと。それはマズいだろと。では、より確実にファイル自体をiPadに転送すれば、ここはクリアできるんですけど。でもそうすると今度は同期が途切れます（第４回参照）。あちらを立てればこちらがなんとやらですな。

じゃあお金出してそれ解決しましょうという話になりますと。必然的にServer以上のライセンスが必要となります。いっときますけどServerってクライアント兼ねてくれませんからねー。設計や保守には別途無印orAdvが必要ですからねー。つまりこの時点で必然的に最低17万。Server Advなら最低43万ドーン。それに加えてこれ用のサーバとインフラと回線とセキュッリティ維持と。もちろん設計運用にかかる人件費も。

言えるか？これお客さんの前で言えるか？お客さんが好き好んで、それこそ酸いも甘いも嗅ぎ分けた上で導入するならともかく、さしてデータベースにも興味無い状態でこの見積出したところで、鼻で笑われ脇に置かれる、そして捨てられるのがオチじゃね？こちとら無印39,900円ですら通らねぇんだぞ？私情を混ぜるな＞俺。

実際問題、FileMaker自体に一度興味を持ってくれたとしても、ここまで説明すると大抵しょぼーんとなりますよね。正気に戻るという言い方もできますけど。ここまでを踏まえて、導入する意義があるのかを喧々囂々してもらって。これで始めて「次の話」ができるようになるんですよと。

それ抜きにして、iPadだからぁ、カッコいいからぁ、紙使わなくていいからぁ・・・・・・から始まるモノが、はたしてどんな結末を迎えるのか・・・・・・まぁ想像はできますわーなと（カッコいいという価値観を否定するつもりはありませんけどね、それはそれでというオハナシです）。

とまぁここまでdisってはきましたけど。裏を返せば。

な用途であれば、無印だけの最小セットであってもバコーンとハマる可能性はありますからね。そうゆう意味で20％位の数字は残しておいてもいいのかなと。自分の周りの事象が20%の内に入るのかってのは各々で考えませう。

（ここから追記：2012/07/12）

　はい、というわけでここまでが有効性20%主張。ちょいと興味があって、QR＆バーコード読み取りソフトであるところのQRdeCODEとFileMaker Goとの連帯を試してみたところ、思った以上にさっくりいきまして。あぁこれは使い出が増えるし、可能性があるなぁということで、ちょいと評価を上方修正しました。

　だからといってServer前提だよねぇということ自体は変わらないんですが。たとえServerがなかったとしても、Mac/PC側で管理するデータと、Go側で更新追加するデータを完全に分離させて、スクリプトなりCSV出力なりで整合性を合わせる・・・といったことも、知恵と工夫次第ではできるよなぁと思えてきました。

　まぁこういったことも試行錯誤、ではありますよね。

（ここまで追記）

　

といった具合でガガッと書き殴ってみましたが如何でせうか？参考にするなりしないなり、そこら辺は皆様のお好み次第で、といつも通りの言葉を。

ですので当方としては、これまで通りに「あくまで小さい組織前提、無印orADVで細々とデータ共有させて手間暇を減らしましょう」てのを主軸とさせて頂くんですけどね。ただしこれだと言ってしまえば、「いちいちプロや専門家が口出さずとも、現場の方がちょっと経験積んでくれればなんとかなってしまう」話でもありますので、収入には結びつかないのでございますトホホのホ。

うん、これまたいつものオチだなすんません。

戻る