命名規則についてご紹介します。
１．実データのテーブル名
☞ 書式 ［データ名］
(6桁)
データそのものを表す名称を［データ名］として付与します。
一般的な例
・固定マスタデータ 得意先マスタ → 得意Ｍ
部門マスタ → 部門Ｍ
社員マスタ → 社員Ｍ
・累計マスタデータ 請求先売掛残高 → 売掛残
請求先請求残高 → 請求残
品目別在庫残高 → 在庫残
・伝票データ 受注ヘッダ、受注明細 → 受注Ｈ、受注Ｄ
仕入ヘッダ、仕入明細 → 仕入Ｈ、仕入Ｄ
売上ヘッダ、売上明細 → 売上Ｈ、売上Ｄ
注）固定マスタデータ、伝票データ
FileMakerで業務システムを開発する場合、マスタ保守および伝票入力のプログラムを作成する際は、直接上記のテーブルに対して更新は行いません。（行わない方が良いです。）
FileMakerでは入力画面に更新するテーブルがインプリメントされているため、入力して他の項目にカーソルが移動した瞬間に入力途中であってもそのテーブルのレコードが更新されます。
登録ボタンを押下するまでは更新されないということはありません。
新規にレコードを追加する場合は、キャンセルを指定された時にそのレコードを削除すれば良いですが、修正モードとして該当レコードを呼び出し、値を上書き修正する場合、入力途中でキャンセルし、元の状態に戻すには、仕組みを考える必要があります。
☞ 一番安全な方法
・固定マスタデータ・伝票データのテーブルと、同じ内容のテーブルをワークテーブルとして作成する。
・入力画面に割り当てるテーブルは、ワークテーブルを設定する。
・入力画面で登録ボタンが押下されると、ワークテーブルから基のテーブルにレコードを追加する。
・入力画面で更新ボタンが押下されると、ワークテーブルから基のテーブルにレコードを更新する。
ゆえに、固定マスタデータ・伝票データについては常に対となるワークテーブルを作成するようにします。
・得意先マスタ → 得意Ｍ、（得意Ｍwk）
・受注ヘッダ、受注明細 → 受注Ｈ、（受注Ｈwk）、受注Ｄ、（受注Ｄwk）
☞ ワークテーブルの意味で、”wk”を付加しています。
これらは、レコードのロックの代替機能としても利用できます。
２．レイアウト
☞ 書式 “L” + ［業務名］ + “_” + ［処理名］
(1桁) (4桁) (1桁) (4桁)
先頭の”L”は、（L：レイアウト、 T：ＴＯ、 S：スクリプト）の識別子です。
以下に例）を記載します。
業務名称 レイアウト名
・得意先マスタ保守 L得意_保守
・受注入力 L受注_入力
・得意先検索 L得意_検索
３．ＴＯ
☞ 書式 “T” + ［業務名］ + “_” + ［処理名］ + “_” + [データ名]
(1桁) (4桁) (1桁) (4桁) (1桁) (6桁)
注）[業務名]、[処理名]は、レイアウト名になります。
ＴＯは、レイアウト名に、［データ名］を付加した内容になります。
業務名称 ＴＯ名
・得意先マスタ保守 T得意_保守_得意Ｍ
T得意_保守_得意Ｍwk
T得意_保守_担当Ｍ
・受注入力 T受注_入力_受注Ｈ、（T受注_入力_受注Ｈwk）
T受注_入力_受注Ｄ、（T受注_入力_受注Ｄwk）
・得意先検索 T得意_検索_得意Ｍ
17桁はずいぶんと長いと感じます。
只、プログラム（レイアウト）の量が、50本を超えてきた時に、以下のような事態に陥り易くなります。
・このＴＯは、現在使われているの？
・このＴＯは、どのレイアウトで使用しているの？
・このＴＯは、どのリレーションで使用しているの？
☞ ワークテーブルを使用するマスタ保守および伝票入力のリレーション
例）得意先マスタ保守
[得意Ｍwk] ［得意Ｍ］
・得意先コード ---------------------> ・得意先コード
・得意先名 [社員Ｍ]
・担当者コード ----> ・社員コード
・社員名 [部署Ｍ]
・所属部署コード ----> ・部署コード
・部署名
注）［得意Ｍwk］と、［得意Ｍ］とを連携します。
一般的なRDBMSでは意味のない結合ですが、FileMakerのリレーションは、レイアウトにリレーションの主となるＴＯを指定することで、そのリレーションのテーブル全てにアクセスができます。逆に見れば、リレーションから外れているＴＯは非関連テーブルとなり、アクセスできないことになります。
４．スクリプト
☞ 書式 “S” + ［業務名］ + “_” + ［処理名］ + “_” + [機能名]
(1桁) (4桁) (1桁) (4桁) (1桁) (任意)
注）[業務名]、[処理名]は、レイアウト名になります。
スクリプトは、レイアウト名に、［機能名］を付加した内容になります。
業務名称
・得意先マスタ保守
スクリプト名
S得意_保守_初期設定
S得意_保守_初期設定_グローバル値の初期化
S得意_保守_共通_ワークレコード削除
S得意_保守_確認処理
S得意_保守_確認処理_エラーチェック
S得意_保守_確認処理_顧客コード存在チェック
S得意_保守_確認処理_顧客マスタへの更新処理
S得意_保守_顧客検索OPEN
S得意_保守_部署検索OPEN
S得意_保守_終了処理
S得意_保守_終了処理_処理モードのチェック
S得意_保守_共通_ワークレコード削除
赤フォント ①レイアウトから直接呼び出されるスクリプト
☞ そのレイアウトのみで使用され、レイアウトから直接呼び出される。
青フォント ②別のスクリプトから呼び出されるスクリプト
☞ そのレイアウトのみで使用され、スクリプトから呼び出される。
黄フォント ②別のスクリプトから呼び出されるスクリプト
☞ 別のレイアウトでも使用され、スクリプトから呼び出される。（共通）
上記の例では、同じレイアウト内で共通に使われるものとしています。
複数のレイアウトで使う場合は、S共通_[機能名]としても良いです。
命名規則について例を記載してご紹介しました。
作成したものが現在使用されているか、何に使用されているか、どのような目的（機能）で作成されているかなど、実際に存在する各オブジェクトの状態が、整理されていることが重要です。
５．補足
５．１．アジャイル開発
「ソフトウェアの設計段階では詳細な要件、仕様を確定せず雛形のレベルで開発を進めていきます。途中で仕様追加、変更が発生しても、それらは想定内としているため臨機応変に対応できる。」とのことですが、そのようなアプローチには向き不向きがあります。基幹系の業務システム構築には従来のウォーターフォール開発を採用すべきです。アジャイル開発を採用する場合は、数十本で完結するシステム、試験的に検証を目的としたプロジェクトでの一時的な開発などに向いています。
５．２．レイアウト設計書（一般的にはプログラム仕様書）
FileMakerで業務システムを開発するのであれば、いきなりオブジェクトを作成するのではなく、レイアウト設計書をまず作成してから（または併行して作成しながら）開発に臨むべきと思います。
特にＴＯについてはレイアウト設計書に名称をまず決定、記入してから登録処理を行えば間違いが発生し難くなります。
レイアウト毎に以下を記入します。 （あくまでも例です）
１．概要
１．１．目的・用途および処理概要
１．２．使用しているＴＯの全て（リレーション）
１．３．画面（レイアウト）のデザイン
２．詳細
２．１．画面（レイアウト）に配置されている項目等の名前と処理内容
２．１．発生するイベントとそれらの内容
２．２．個々のイベントに対するスクリプト
２．３．個々のスクリプトの処理内容
今後、環境ができれば、レイアウト設計書のテンプレートについても掲示していきたいと思います。
以上です。
