開発ルールとは、フィールドやスクリプト、リレーションシップグラフなどの定義や書き方について、命名規則やコメントなどのルールを定めたものです。

 

Claris FileMaker の開発会社であるClaris パートナー企業の大半は、おそらくそれぞれに開発ルールを定めているのではないかなと思います。弊社にも開発ルールがあり社内で共有しています。

 

開発ルールは社内でシステム内製化を進めるユーザーを手助けするツールだと考え、2022年5月9日に「Yes！開発ルール講座」というサービスをスタートしました。

 

本ブログでは、弊社が商品化するほど Claris FileMaker のシステム開発でルールが重要だと考えている理由を、特に大事にしている「命名規則」「リレーションシップグラフでのルール」「スクリプトのコメント」に関するケーススタディ（フィクション）と一緒に解説していきたいと思います。

 

 

命名規則は確認の手間や不要なエラーを防ぐ

 

ケース：命名規則が徹底していたら起こることのないエラー

上司が作成した見積書作成カスタムAppにスクリプトを追加しようとして、もともとあった「税率」という名前のフィールドをスクリプトステップの「フィールド設定」に使用しました。そのスクリプトを実行してみたところ、「このフィールドは変更禁止なので、この操作は実行できません。」というダイアログが出てきたことで、設定したフィールドが“計算”タイプだと気がつきました。

 

 

【解説】

スクリプトワークスペースではフィールドのタイプ（テキスト・数字・計算・集計・オブジェクト）が表示されません。そのため開発者はフィールド名からタイプを判断するか、分からない場合は「データベースの管理」でフィールドの詳細を確認する必要があります。

ケースのようなエラーダイアログが表示される原因は複数ありますが、そのうちの一つが、“計算”タイプもしくは“集計”タイプのフィールドを設定した場合です。そのため、フィールド名でタイプが判断できるような命名規則（例えば、計算タイプであれば「calculation」の「c」を末尾につけて「フィールド名_c」にするなど）を定めておけば「データベースの管理」でいちいちフィールドの詳細を確認する必要や、スクリプト作成後のテストでエラーが起きるといったことをあらかじめ防ぐことができます。

 

フィールド名に限らず、テーブルやTO （テーブルオカレンス）、レイアウトにも命名規則を定めておくことで、確認の手間や不要なエラーなく開発を進めることができ、引継ぎや複数人での開発をスムーズにします。

 

 

リレーションシップグラフを規則正しく作成することで、
分かりやすさと開発しやすさがぐんと増す

 

ケース：蜘蛛の巣状のリレーションシップグラフ

社内で十何年も前から使われているカスタムAppは、リレーションシップグラフを開くとまるで蜘蛛の巣のように四方八方に展開していて、リレーション同士が交差していたり、TO同士が重なっているところがありました。TO名もぐちゃぐちゃです。

TO名に規則性がないため、スクリプト内でTOを選ぶ時は一度リレーションシップグラフを開き、選びたいTOの名前を確認してから設定する必要がありましたが、蜘蛛の巣状だとTO同士のつながりを確認するのに時間がかかります。また、時々TO名を見間違えてしまい、スクリプトで誤ったTOを設定してしまってエラーが起きてしまうこともありました。

TOを新しく追加する際も、どんな名前にすればいいのか迷ってしまいます。

 

【解説】

本来、分かりやすく使いやすいのがリレーションシップグラフです。

ルールなくTOを追加し、リレーションをつなげていくと、気づけば蜘蛛の巣状になってしまう例が少なくありません。

規則正しく作成することで、テーブル同士の関連性や、TOグループの役割がひと目で見て分かりやすいものになります。

またTOの命名規則を定めておくことで、スクリプトを作成する際にTO名をリレーションシップグラフでいちいち確認する手間がなくなり、開発効率がアップします。

 

 

蜘蛛の巣状のリレーションシップシップの例

 

規則正しいリレーションシップの例（この例はアンカーブイモデルと呼ばれます）

 

 

スクリプトのコメントで将来に備える

 

ケース①実は使われているスクリプト　

社内では複数人でカスタムAppを開発しており、それぞれ各自が自由にスクリプトなどを作成していました。ある時、今まで作られたスクリプトを一旦整理整頓することになり、スクリプト同士の依存関係などを確認しながら、不必要なものは削除することになりました。

分析ツールを使ってカスタムAppを解析したところ、分析結果上では現在どこからも参照されていないスクリプトがいくつかあり、スクリプトを確認したところコメントも記載されていないため、一見削除しても問題なさそうでした。念のためひとつひとつテストしてみたところ、サーバー側で使われているような動作のスクリプトがいくつかあり、Admin Console で確認するとやはりサーバーサイドスクリプトとして利用されていました。あやうく気がつかないで削除してしまうところでした。

 

ケース②このスクリプトは意図なの？間違えているの？

引き継いだカスタムAppに一部不自然な動きがあったため、ひとつひとつスクリプトを動かして確かめましたが、何かの目的や意図のあるスクリプトの書き方なのか、それとも単純なミスなのかは判断できませんでした。

 

ケース③自分で作ったはずなのに分からなくなる

自分しか改修しない予定のカスタムAppだったため、コメントを最低限しか記載していないことが時々ありました。数か月後にその部分の改修を行うことになりましたが、スクリプトのいくつかは、パッと目的や意図が思い出せません。スクリプトを一番上から流してやっと「ああ、自分はこういうことがしたかったのね」と思い出しました。

 

【解説】

よくある処理や単純な処理の場合は、他人が作ったスクリプトだとしても容易に理解できることもあります。ただ、特殊な処理や複雑な処理の場合は、開発者によってスクリプトの組み方が変わってくるため、どんなプロの開発者でもそのスクリプトを理解するのに時間がかかってしまいます。

 

ケース①に出てくる分析ツールで、スクリプトについて確認できることは「ボタンやスクリプトトリガに設定されているかどうか」「サブスクリプトとして使用されているかどうか」です。スクリプトメニューからの使用や、サーバー側からの使用、他にもWebビューアやData APIで使用されているかどうかまでは分かりません。

ケースでは、サーバー側で実行していることを一言コメントに記載しておけば、動作を確認する手間が不要でした。

ケース②にあるように、他人から見たら不思議なスクリプトも開発者本人としては意図的に作ったのかもしれません。しかし本人に直接確認がとれない場合は判断しようがありません。

ケース③のように書いた本人ですら、時間が経つと自分が書いたスクリプトにもかかわらず理解するのに時間がかかる場合もあります。

 

コメントを書くのには少し時間がかかりますが、「どこで、いつ、どんな処理を行っているのか、どんな目的なのか」などきちんと残すことで、結果的に、将来の自分や他のメンバーの時間を大切にすることにつながります。

 

 

YWCクリエータ（開発部門）メンバーが「開発ルールがあって助かっている」という話

 

クリエータみんなが言う「ルールがあると“トラブル”と“迷い”が減る」

ルールが決まっていることで伝達ミスなど人同士のコミュニケーショントラブルが減ります。

また Claris FileMaker の開発ではカスタムAppを自由に作れるがゆえの“迷い”が出てきます。

「テーブルの管理や、リレーションシップグラフの作り方はこれで合っているか？」「自分の実装方法は適切なのか？」などなど。

自由であるがゆえの“迷い”は Claris FileMaker での開発の醍醐味とも言えますが、お客様のシステムを開発する際は、高いクオリティを保ちながらも開発費用をできるだけ抑える必要があります。そのためには高いクオリティの開発をいかに短時間で行うかが重要です。“迷い”は時間を消費します。

弊社では開発者が迷いがちな部分をルールで定めておくことで、開発効率をアップしています。

 

 

今から Claris FileMaker を学んで行く！という方へ

 

基本が分かったら早めに実践した方がいい、開発ルール

ある程度作り込まれたカスタムAppを開発ルールに沿って作り直すのは、意外と難しく大変な作業なので、できれば早めの段階から実践していただくことをおすすめします。

Claris FileMaker の基本が身に着いて「さあ本格的に開発を始めるぞ」となったらぜひルール化を検討してください。

臨時の業務のために作るカスタムAppであれば、将来性を考える必要はあまりないのかもしれませんが、ほとんどの業務はその後何年も繰り返し行われることかと思います。その業務用のカスタムAppはその業務がある限り使われ続けられるはずです。そして業務というのは日々少しずつ変化していきます。その変化に合わせてカスタムAppにも都度改良を加えたり、機能を追加することになります。そのたびに開発者を助けるのが開発ルールです。

 

弊社にとって開発ルールは「チームで開発を円滑に進めること」「引継ぎをスムーズに行うこと」「効率的に開発を行うこと」の3つで重要な役割を担ってくれています。

 

 

 

改めて宣伝ですが、ご興味のある方はぜひ「Yes！開発ルール講座」ぜひチェックしてみてくださいね。

サービスサイトはこちら

 

最後まで読んでいただきありがとうございました。