FileMaker構築の流れを追ってみた（タイトルてきとー）
いったいどこに需要があるんだ？むしろ無いだろ？とは自分でも思うのですが。なんとなーしに書いてみてしまいます。
FileMakerでやるとラクだよ？と言葉だけは踊っておりますが。じゃあ実際に業務の中で使うとしても、どのように作り方を見せればそれが伝わるのかな？というのには以前から首を傾げておおりまして。じゃあまんま作り方的なものを垂れ流してみたらどうなんだろう？と試験的に書き連ねてみる次第です。
とはいいつつFileMaker自体のフォローはそんなに書いてなかったり。以降はFileMaker触ったことがある位の前提知識を必要とするかもしれません悪しからず。まぁ細かいところはわからずとも、「あぁこんな流れで作るんだー」的にぼんやりと飛ばし読みして頂くのがよろしいかと思われます。あ、あと以下デカい画像てんこ盛りです重くてサーセン。
という訳で何を作ってみるかですが。朝晩ひっきり無しに走ってるあちらこちらの介護施設送迎車の群れを見て、ぼんやりと思いついたこれを。
お題：
とある介護施設「デイケアけやき」（架空です念の為）では、６台の送迎車を使って毎日利用者さんの送迎を行なっているのですが、送迎車にどの利用者さんを割り当てるかで、毎日毎日エラいことになってます。手作業で割り当てをやっている為に、利用者さんが抜けてしまったり、逆にダブってしまって家の前に送迎車が３台なんてことも。 そこでFileMakerを用いて、利用者さんの漏れ・ダブりが発生しないような配車表を、毎日作成するための支援DBを作成しましょう。（20点）
思いついた当初は、それこそどこぞの学校で例題としてやってしまいそうな単純なお題・・・・・・だと思っていたんですけど。いざ始めてみたら難儀することのこの上無しでした。では順番にやってみませうかね。
まずは利用者側から
とっかかりは、やはり利用者さんのデータ化、ということですよねぇ。利用者さんがいなければ配車も何もあったもんじゃない。
※住所氏名は全てランダム生成による架空のものですが。偶然の一致も怖いので一応ぼかしを。
※途中段階のスクショって取ってないんですよね。一部加工したりもしてますご了承を。
さっくりとテーブルを作成。レイアウトも自動生成されるのでそのまま流用。ここまではいいんだな。Excelで作る表の縦と横を、そのままフィールドとレコードに置き換えるだけですから。
次。それぞれの利用者さんが、何月何日に利用するかってのを保存管理しなければなりません。データ自体はまぁ常套手段で。
利用者カレンダーテーブルを作成。DB的には利用日と利用者NoをペアにしてPKにしたいんですけど、FileMakerではできません（FileMakerが欠陥DB呼ばわりされる主因のひとつ、反論できません）。よってキーは無しで。ともあれこのテーブルいっこあれば、
| 利用者No | 利用日 | 利用区分 |
| 31 | 2012/10/1 | ○ |
| 31 | 2012/10/3 | ○ |
| 31 | 2012/10/5 | ○ |
といった具合でデータを積めば、利用者さんと利用日が紐付いた状態を管理できますよと（レコードがなければその日は利用しないということ）。
データ入力でつまづく
さて、最初の壁はここからでした。利用者カレンダーテーブルにデータを投入するための、レイアウトを作成しなきゃならんのですけど。まずは結果から見せてしまうと。
先の利用者テーブルレイアウト下部に、カレンダー形式で利用日が表示・編集できるように追加しました。各日付の所をクリックすると、
別ウィンドウが表示されて利用する／しないを編集できます。個別に○☓打ち込むのがめんどくさかったので、カレンダー下部に曜日単位で一括入力できるボタンも用意。てな訳でひと通りできました。できたのですが。
めんどくせええええええええええええええええええええ
失礼しました。このレイアウトは利用者テーブルのデータを基にしていて、そこから関連テーブルとして利用者カレンダーテーブルをリレーション設定、利用区分（○とか）を引っ張ってるのですが。
引っ張ってくるためにはFIleMakerの「ポータル」という機能を使う必要があります。ていうかポータル以外に選択肢がありません。INNER JOIN？なにそれ美味しいの？レイアウトで見て頂くとこんな感じになります。
○を表示させるところ、これひとつひとつが独立したポータルです。んでもって、
こんな具合にひとつひとつクソ長いフィルタをかけて、「当月１日の利用区分のみを表示するポータル」「当月２日の利用区分のみを表示するポータル」「当月３日の（以下略）」を３１個作ってる訳です。
こんな見栄えなのでいかにも手抜きよばわりされそうなんですが、上述ポータルの他にも、
- 月にあわせた曜日の動的表示（別テーブルにグローバルの計算フィールドを用意して埋め込み）
- 条件付き書式追加（土曜なら青、日曜なら赤）
- 日付チェック（存在しない日付に入力できるのはマズいよね）
- ボタン設定（日付単位にパラメータ付加してスクリプト呼び出しの設定）
- 前月次月処理（スクリプトをガリガリ）
と諸々やってますので相応時間かかってます。ていうかこれ、難易度高いと思います。ポータルの動きをちゃんと理解してないと、１週間１ヶ月あがいても完成できない人もいるのかなと。いやマジで。作るにしたってこれだと、カレンダー形式にするならその部分は工数単価５倍で貰わないと（レイアウト凝るならそれこそ10倍以上）割に合わないというか、普通に工数割れ起こすよなぁ・・・・・・。うん、これがわかっただけでも収穫、ではあります。
でまぁすったもんだありまして。
ようやく利用者さんの利用カレンダーデータが完成。ちなみに登録80人でも一ヶ月でレコード1000超えますね。1000超えのデータExcel手作業で管理修正なんて、考えただけで目眩がしませんか・・・？ちらっ。ちらっ。
次に配車側を
という訳でようやっとです。本題に入りましょう。ここまで前準備なんだっつーの。
配車表作成にとりかかりましょう。とはいえだ。まず「配車って何？」を考える必要があります。どの送迎車にどの利用者さんを乗せるのが一番効率的なの？
今回FileMakerの実ファイルを公開していないのですが、大きな理由のひとつがここになります。というのも「何をもって効率的とするか」は、個別施設によって千差万別ですので、サンプル拾ってもらったところで絶対に実用に耐えないと断言できるんです（他にもハードコーディングが過ぎたところがあってとかもゲフンゲフン）。ですのでもし実用にするのであれば、ちゃんと担当者さんと顔突き合わせて打ち合わせして、というのをやる必要があるのですが。
ここでは担当者さんも居ませんので（架空だしな）、簡略化して極めてざっくりといかせて頂きましたご了承を。要件としてはこんな感じ。
- 普段から地区毎に車走らせてるので
- 当日の利用者さんをグループ分けした上で、人数の多いグループに、定員の多い車を割り当てたい
- 割り当てた後にも変更できるようにして欲しい（自動割り振りだけで最終決定とする必要は無い）
といった具合でざっくりと進めさせて頂くことにします。はい自己満足乙。
んではまずは送迎車から処理していきましょうかね。
素直にテーブル化しただけですね。１テーブルで完結できます。一応車椅子定員とかもつけてはみたんですけど、これ書いてる段階で実装してませんサーセン。
次に利用者さん側にも手を入れないと。地区毎にグループ化、ということなので、そのグループを管理するための受け皿を用意。
複数の地区でひとつのグループ、1:nの関係になりますよと。ではこの地区／グループを利用者テーブルから参照できるように手を入れます。
利用者テーブルに計算フィールド「地区名」を追加、住所から決め手となる地区名を抽出しています（ここがガリガリのハードコーディング）。あとは地区テーブルとリレーションを組んだ上で、グループ名を取り込みました。レイアウト修正のめんどくさささは宿命的につきまといますけど、こういったテーブル／データに対しての追加修正がさっくりとできるのはFileMaker(というかデスクトップデータベース)ならではといったところでしょうか。
さて、これでデータ的に準備は整った。じゃあレイアウトを・・・・・。
画面どうしよう？
とここまできて、第二の壁にブチあたりました。そもそも配車表までたどり着かせるために、どうゆう画面遷移をつくればいいんだ？
で、あーだこーだと試行錯誤して、落ち着いたのが以下の形。まずは一覧画面から。
はいデザインセンスの欠片もありませんねサーセンサーセン。でも一応理由はあって。
配車表を作るにあたって、何日も先のものをまとめて作成するってことは無い筈なんです。当日の利用者さんが確定するのも直前ですし（当日ドタキャンも当たり前の世界）。となれば、新規作成を押したら、これまで作成した配車表の「次の日」のものが、都度作成できればいいのかなと。
なので新規ボタンを押すと、カスタムダイアログにて、
このようにデフォルト日付を設定することでよしということにしました。特定日の配車表だけ作りたいのであれば、手入力で日付変えてくれと。
※カスタムダイアログはレコードのフィールドをそのままダイアログに反映させる形になります。つまりダイアログ表示前にスクリプトから新規レコード→フィールド設定で初期値を突っ込んであげればこうやって反映可能です。
既に作成された分に関しては下のボタンから選択してくれればいいだろうと。その為に「配車表を作ったこと」自体を記録する送迎配車実績テーブルを用意しました（この一覧画面も、送迎配車実績テーブルを基に作成しています）。
データ構造とデータはこんな感じ。今気付いたけど作成フィールドは死にフラグですな（削除機能追加したら使うことになるかと）。
そんな訳で、一覧画面もできましたので、後は本丸残すのみ。新規作成から日付を指定してOK押すと、ガリガリガリガリとスクリプトが起動し、対象日に必要な利用者さん情報をすべて抽出します。その際に地区毎の集計も行って人数の多いグループを算出、そこから仮としての送迎車割り当てまでを一気に片付けてしまいます。
そのスクリプトがこんな感じ。これまたハードコーディングがりがりで、本来はお見せできるようなもんじゃないんですけど。一方でこの一連のキモでもありますので敢えて全部見せます。笑ってくださいまし。あ、あと全面的に信用しないよーにね。既にバグありますから（直せ＞俺）。
送迎配車新規作成(PDF)
でまぁこのクソ長い処理が終わりますと（処理は一瞬ですけどね）、次のようになる訳です。
どうでしょう？まがいなりにも、それなりにはなってませんかえ？印刷時にはひとつの送迎車でA4横１枚に収まるようにしています。あとお義理程度に車椅子スペースが必要な利用者さんのアイコン表記もしておきました。
ただこれで終わりではありません。スクショを見てもお分かりのように、送迎車の定員を既に超えてしまっています。ですので・・・
ミもフタもないですけど、こうやって別の送迎車へと移動させて、各送迎車が定員に収まるように微調整をお願いしますと（変更するとソート再実行が即時反映されます）。
※ちなみに、大きな声では言えないんですけど現時点、定員オーバー時の条件付き書式がバグってます。定員より小さくなっても赤くなってしまったり。何がいけないんでしょうかねぇ？「Self > 送迎車T::定員」ではダメなのでしょうか・・・・・うむむむむ。
最後に、ここまでの作業で反映されたリレーション全体を。
こうやってみると、実はデータの核は利用者カレンダーテーブルにあり、つい目が行きがちな利用者テーブルとかは、主従でいうところの従でしかない、というのがお分かり頂けるかと。もちろん作ってるときは意識してないんですけどね。結果としてこうなった、という話で。ただしそれでも、こうゆうパターンもあるよ、ということを頭の片隅にでもストックして頂けますと、応用できるのではないかと思われます。
おわったー
という訳で以上説明おわりー。つかれたー。こんな長い文章書いたのも久しぶりだし。もうあとがき書く気しないのでおわりおわり。最後までお疲れ様でしたー。