FileMakerの「効率的な開発手法」という属人化
- sago
- 1 時間前
- 読了時間: 6分
―属人性を高めるだけの“オレオレ最適化”から脱却せよ―
今回の記事は主にFileMakerのインハウス開発者に向けて書いています。
インハウス開発者とは、社内向けのFileMakerシステムを作っている人のことです。
「効率化」は孤立を生む
FileMakerの開発現場を見渡してみましょう。
ほとんどのケースで開発者は1人です。
つまり、その人が辞めたら誰もわからなくなります。
「効率的な」スクリプトや「柔軟な」フレームワークが作られていても、
それを理解するには膨大な調査コストがかかります。
しかもドキュメントなんて、まず残されていません。
オレオレフレームワークは美しい（その人にとっては）。でも他人には地獄。
一人だけの効率化は、人に任せにくくする罠でもあります。
なぜなら、その仕組みを理解していないと触れないからです。
フレームワークを組んだ本人以外は、
「このスクリプト、どこで呼ばれてるの？」という調査から始まり、
開発の大半が“解析作業”に費やされます。
「教科書レベル」で十分
だったら、教科書レベルのテクニックで作った方がいい。
それがたとえ一般的なプログラミングのセオリーから外れていても構いません。
同じ設定を何度も繰り返すスクリプトがあってもいい。
似たようなレイアウトが並んでいても問題ありません。
なぜなら、「低いスキルでも再現できる設計」の方が価値があるからです。
誰でも理解できて、誰でも直せる。
それが現場では“強い”開発になります。
「スゴイ人しか触れない仕組み」よりも、
「すごくない人でも安心して触れる仕組み」を残すほうが、
結果的に組織にとっての効率につながります。
属人化の最大の原因は、「開発の効率化」を追いすぎることです。
特にFileMakerのような開発環境では、理解できる人が限られています。
IT人材の営業電話がかかってきても、「FileMakerの人材もいますか？」と聞いて、
「いません」と言われるのが現実です。
「効率化」はリスクでしかない。
具体例：引数にJSONを使うな
「引数にJSONを渡せばスクリプトを再利用できる！」
確かに理屈は正しい。たくさん引数を渡せます。
だが、その「理屈」を理解できる人が社内に何人いますか？
JSONを理解し、正しいキーを渡し、戻り値を解析できる人
そんな人が社内にどれだけいるでしょう。
FileMakerしか触らない業務ユーザーが多い現場では、
学習コストの高い設計は害悪になりやすい。
スクリプトは「再利用」よりも「理解される」ことを優先すべきです。
“読める”ことこそ最大の保守性。
具体例：スクリプトの使いまわしもやめよう
例えば、「新規作成ボタン」。
画面ごとにスクリプトを分けるのは非効率に見える。
だから、一つのスクリプトで「引数」に応じて処理を分ける・・・よくある話です。
だが、その「効率化スクリプト」を書いた本人が辞めたらどうなるか？
残った人、あるいは引き継いだ外部の開発会社は、
引数の構造を読み解くところから始めなければならない。
「なぜこのレイアウトでは動かないんだろう？」と悩む時間が、
結局いちばんの無駄になります。
それよりも、画面ごとにスクリプトを持つ方が理解しやすい。
引数を知らなくても、どの画面のボタンがどのスクリプトを呼ぶかが一目で分かる。
それこそが「現場で使える効率」です。
具体例：テーブル名やフィールド名に“依存しすぎる設計”はやめよう
テーブル名やフィールド名を変更しても自動で連動しないような設計──
これは地味に危険です。
たとえば「フィールドを名前で設定」スクリプトステップ、
あるいは ExecuteSQL や Evaluate 関数。
これらを使った柔軟な設計は、一見スマートに見えますが、
裏では“名前に依存する脆い仕組み”を生み出しています。
テーブル名やフィールド名を少しでも変更すれば、
式の中身は自動で更新されず、気づかぬうちに動かなくなる。
修正コストは想像以上に大きい。
もちろん、「担当者1」「担当者2」「担当者3」…といった
似たフィールドを一括で処理したい場面では有効かもしれません。
ですが、その一時的な効率を追うよりも・・・
そのスクリプトや関数を理解して調整する時間があるなら、手で直したほうが早い。
効率化は常にトレードオフ。
「あとで誰が触るか？」を考えたとき、
複雑な式よりも、地道で安全な手作業が最終的に“効率的”になることが多いのです。
具体例：セレクター・コネクタモデル？をやめよう
セレクター・コネクタモデルは、理論的には正しいかもしれません。
しかし、FileMaker業界でそれを正しく理解している人は稀です。
シンプルに、「左から右へ流れる」ルールで構築すれば十分。
たとえば：
最初にできたテーブルオカレンス(TO)は左に縦に並べる
新しいリレーションを組むときは、左のTOを複製して右に置く
名前は「左のTO_右のTO」形式にする
同じ組み合わせが複数あるなら「#〇〇用」で区別
これだけで誰が見ても分かります。
FileMaker公式教材のやり方が最強
「自分だけの最適解」を探すのではなく、
FileMaker公式が提供する動画やドキュメントで実現できる範囲で作るのがベストです。
なぜなら、それが最も再現性が高く、最も引き継ぎやすいから。
複数人で開発するケースなら話は別ですが、そんな現場は稀です。
大半のFileMakerシステムは一人の開発者によって設計・運用されています。
ならば、その一人がいなくなっても困らないように作ること。
それが何よりも優先されるべきです。
公式教材を活用することで、人材教育をスムーズに進められます。
豊富なテキストや動画コンテンツが用意されているため、まずはそれを見てもらうだけで基礎をしっかり理解してもらうことができます。
結果として、教育にかかるコストや時間を削減できます。
結論：「誰でも触れる、それがいちばん効率的」
FileMaker開発の“効率化”とは、
“自分が早く作ること”ではなく、“他の人が安心して触れること”です。
「自分が辞めたあと、このファイルは誰が守るのか？」
その問いに答えられないシステムは、どんなに高機能でも脆い。
社内の誰かが必死に理解しようとしても時間だけが溶けていく。
設計がわからないままブラックボックスとして使い続けるか、
あるいは、莫大な費用を払って外部の開発会社に頼るしかなくなる。
自分だけが理解できるテクニックは、組織にとって害悪でしかない。
だから、シンプルに作りましょう。
同じスクリプトを何度書いたっていい。
“見ればわかる”構造こそが、最強の効率化です。
「読める」「直せる」「任せられる」
この3つが揃って初めて、あなたのFileMakerのシステムは持続性のある資産になります。
社内で一人で開発していて孤独。
自分のやり方が正しいか不安になった場合は当社にお問い合わせください。教育プラン
Claris FileMaker 用テキストと解説動画
ちょっとした時間にFileMakerのTipsが学べる未来Switchのショート動画
※様々なテクニックを通勤中にサクッと見れます
※教科書に書いてない細かいテクニックが多め
コメント