そのFileMaker、もう誰も触れない？｜チーム開発が崩壊する前に決める開発規約と標準化
目次
FileMaker チーム開発で崩壊しないための開発規約とマインドセット
「ローコードで自由に、爆速で作れるのがFileMaker の良さじゃないか！」
そう思ったことがある方は多いはずです。実際、それは間違いではありません。
しかし一方で、こんな経験はありませんか？
「……このスクリプト、何をしているんだ？」
「変数$aって何が入ってる？」
「なぜここでレイアウトが切り替わる？」
そして気づくのです。
──これ、半年前の自分が作ったやつだ。
私たちは、次のような事態を避けるために「開発規約」を定めています。
- あの人が作った機能、あの人しか直せない
- 少し修正しただけで、別の場所が壊れる
- 誰も触れないブラックボックスが増えていく
結論から言えば、規約は「縛り」ではありません。
未来の自分と、チームを救うための“保険”です。
⒈なぜ FileMaker 開発に「規約」が必要なのか？
FileMaker は誰でも簡単にシステムを作れる反面、次のような落とし穴があります。
- 「動いたからOK」
- 「早く作れるのが正義」
- 「とりあえず共通化しておけば後で楽」
……そして数か月後。
- 仕様を知っているのが一人だけ
- レイアウトやTOが迷路状態
- スクリプトの解読に時間がかかる
- 作った本人すら覚えていない
まさに、未来の自分は他人です。
だからこそFileMaker 開発では、属人化を防ぐ「規約」と「標準化プロセス」が重要になります。
⑴属人化が引き起こす具体的な問題
属人化は、抽象的な言葉ではありません。現場では次のような問題として表面化します。
- 修正依頼が特定の人に集中する
- 不具合対応に時間がかかる
- 新しいメンバーが戦力になるまでが長い
これは、チーム全体の生産性を確実に下げます。
⑵効率化の罠と、複雑な抽象化の落とし穴
開発に慣れてくると、ついこう考えがちです。
- もっとスマートに書きたい
- もっと汎用的にしたい
- 自分が楽できる設計にしたい
しかしその結果、
- 一部の人しか理解できない実装
- コメントのない抽象化されたスクリプト
- 読むだけで疲れる構造
が生まれてしまいます。
「速く書けるコード」より「速く読めるコード」
これが、チーム開発における本当の効率です。
⑶複雑な抽象化の落とし穴
一見キレイで速そうに見えるけど、他人（または未来の自分）が読んだ瞬間に思考が停止します。
⑷可読性こそが真の効率
開発に慣れてくると、つい「一部の人しか理解できない、必要以上に複雑な実装」を行って、開発効率を上げようとしてしまいがちです。
しかし、これがチーム開発においてはリスクになることがあります。
チーム開発の「効率」は、「書く速度」じゃなく「読める速度」＝次の3点で決まります。
- 誰でも読める
- 意図が伝わる
- 修正するのが怖くない
可読性を高めることは、結果として
- 修正スピードの向上
- 不具合の減少
- 組織全体の生産性向上
につながります。
⒉開発規約の柱（概要）
開発規約は、未来の自分や仲間へのラブレター（説明書）です。
ここでは、特に重要なポイントを絞って紹介します。
⑴命名規則：迷いをなくす
「ファイル名どうしよう…」「フィールド名、英語にする？日本語にする？」そんなちょっとした迷いが、積もり積もって開発スピードを落とします。そこで、ファイル名、テーブル名、フィールド名には一貫したルールを設けています。
- プレフィックス（接頭辞）： 主キー、外部キー、グローバルフィールドなど、変数やフィールドの役割が一目でわかるように接頭辞を統一しています。
- スペースの排除： ファイル名やテーブル名にはスペースを使用せず、システム的な誤動作や参照ミスを防ぎます。
- カタカナの統一： 半角カタカナは使用せず、全角に統一することで表記ゆれを防ぎます。
「名前で迷わない」だけで、開発スピードは大きく変わります。
⑵リレーションシップ：クモの巣を作らない
リレーションシップグラフがスパゲッティ状態になっていませんか？
リレーションシップグラフがクモの巣状に絡まり、誰も触れなくなった『スパゲッティ状態』。
実はこれ、私たちがご相談いただく中で最も多いお悩みの一つです 。
実際に、オフィス大手のパフィスバスターズ様でも、以前はシステムの複雑化により他社から保守を断られるほどの不安を抱えていらっしゃいました 。しかし、私たちが規約に基づき構造を整理した結果、最終的に処理時間を8割削減し、売上118%達成という成果に繋がっています 。
構造を変えるだけで、システムは『怖くて触れないもの』から『成長を支える武器』に変わるのです 。
ではどのようにしてリレーションシップグラフの整理をしているのか。
２つのポイントをご紹介します。
- アンカーブイ（Anchor-Buoy）モデルの採用： 親（レイアウトの元）から子へ、左から右へと流れるように配置し、コンテキスト（現在位置）を明確にします。これにより、グラフが複雑な「クモの巣」状になるのを防ぎます。
- メンテナンス用TOの分離： 開発者がデータメンテナンスを行うためのTO（テーブルオカレンス）と、実際のアプリ動作で使用するTOを明確に分け、誤操作を防ぎます。
構造が見えるだけで、安心して触れるシステムになります。
⑶スクリプト：可読性ファースト
ちょっと待って。そのスクリプト、コメントはありますか？
- コメントは必須：「何をしているか」はコードを見ればわかりますが、「なぜそうしたか」はコメントがないと伝わりません。
- 余白の美学： ぎっしり詰まったコードは読む気を削ぎます。処理のブロックごとに「空行」を入れることで、視認性を高めています。
- 変数の命名： $n のような省略形は避け、何のための変数かが他者にも伝わる名前を使用します。
スクリプトは「説明書付き」であるべきです。
フィールド定義：ハウスキーピングの徹底
全てのテーブルにおいて、データの「素性」を追跡できるようにしています。
- 作成・修正情報の自動化： 「いつ」「誰が」作成・修正したかを記録するハウスキーピングフィールド（作成タイムスタンプ、修正者名など）を必ず実装し、データの信頼性を担保します。
これらを自動記録することで、データの信頼性が大きく向上します。
次に、規約以外にも、私たちが大切にしている「ノウハウ」をご紹介いたします。
自社のFileMakerが『属人化』していないかチェックしませんか？プロの目による無料相談はこちら
⒊チーム開発を成功させるための運用ノウハウ
規約以外にも、複数人で開発を進める上で大切にしている運用ルールがあります。
- 開発用レイアウトの活用：
ユーザーが見る画面とは別に、開発者がデータ確認やデバッグを行うための「開発者用レイアウト」を用意し、本番レイアウトを汚さないようにします。 - 不要なコードは「断捨離」：
使わなくなったスクリプトやフィールドは、「いつか使うかも」と残さずに削除します。
残された「ゴミ」は、後から参加したメンバーにとって「必要なのか不要なのか判断できない地雷」となります。 - サーバーサイド実行の安全対策：
サーバーサイドでスクリプトを実行する場合、意図しないトリガ発火や無限ループを防ぐため、サーバー判定やコンテキストの固定を徹底します。
「残す勇気」より「捨てる勇気」が、後のチームを救います。
まとめ｜未来への投資としての開発規約
開発規約は、自由を奪うものではありません。
- 迷う時間を減らし
- 属人化を防ぎ
- 本当に価値のある開発に集中する
そのための仕組みです。
「半年後の自分は、今のコードを覚えていますか？」
答えは、ほぼNOでしょう。
だからこそ、未来の他人に渡すつもりで書く。
その優しさが、強いチームを作ります。
未来の自分とチームを守るために現状把握したい方向けの
失敗しない開発チェックリストはこちらから！
参考資料
✏️ ゼロから始める FileMaker 開発 シリーズはこちらから！
🌐 サポータス公式サイト（ソリューション紹介）
L SNS（ Twitter | Facebook）
L FileMaker 導入事例まとめ
