【FileMaker】リレーションシップグラフの闇に勝つために

闇の魔術に対する防衛術というネタがあったので、ちょっと投稿してみました。
仕事でFileMakerを使ったシステム開発をしていますが、お客さま自身や昔から動いているFileMakerシステムをメンテナンスする際に目にする、

巨大な巨大な蜘蛛の巣

。。。

FileMakerを仕事にしている人はわかると思います。
あの、リレーションシップグラフの蜘蛛の巣です。
これが闇ですが、うまくシステムが動いていることが多いので、まさに「闇の魔術」で動いていると思ってます。。。

(本当は画面いっぱいに出してもまだまだ続くすっごい蜘蛛の巣の魚拓を載せたいのですが、コンプラ的に難しいのでそれっぽい画像を検索してみてください)

何が闇の原因なのか

FileMakerではRDBでいうところのviewみたいなものをリレーションシップグラフとして構築して開発していきます。
これが命と言っても過言ではありません。

なので、画面数や画面内で使っているテーブル数が増えるとリレーションシップグラフも増加するわけです。

これをほぐすのは至難の技で、兎にも角にも「」の一言に着きます。
闇具合は、作成した時期が古ければ古いほど深まります。
「なんとか波」を何発も投入しても克服できずにHPを削られて蓋をしてしまうこともあります。
まさに闇に葬られるのです。

「アンカーブイ」方式で表現されている場合はまだ救いがありますが、数が多ければやられてしまいます。

魔術に対抗する防御策

一撃で倒せる白魔術はありません!
しかし、防御術はあります。
可読性や今後の追加案件に対応するために、蝶の羽のように広がったリレーションシップグラフには、とにかく画面やスクリプトを解析してコメントを入れまくるのです。
時間も手間もかかりますが、とにかくあとの人の道を作るためにもやり続けるのです。

私の場合は、以下のようなルールでリレーションシップグラフを書いています。

コメント:
・黄色:機能や画面レイアウトごとの区切りや画面・機能の仕様を書く
・赤:残さなければならない重要な引継ぎ事項
・青:お客さまに確認して「これでいい」となった仕様

TO(テーブルオカレンス):
・赤:マスタテーブルのTO
・青:トランザクション系テーブルのTO
・緑:作業テーブルや一時的に使うテーブルのTO

スクリーンショット 2020-12-12 22.35.35.png

まさに、リレーションシップグラフを要件定義と詳細仕様、引継書として機能させるのです。

闇の魔術に対する防御は地道な作業ですが、巻いた種の功績は大きいことを祈って、今日も戦います。