誰にとっての「使いやすさ」？（開発者 or エンドユーザ）

前回の記事で、「フィールドを名前で設定」スクリプトステップで一歩前進と評価したが、それはあくまでも開発者としての視点。見方を変えて、エンドユーザの視点だったらどうかという検証が、今回の話。

FileMaker は、「フィールド設定」などのスクリプトでは、フィールドはダイアログ上から選択操作しかできないものの、フィールド名に変更があった場合にも自動的にそれを参照する設定側にも反映されるというメリットがある。オブジェクト名を動的に変えたい時には不便だが、そうでない用途であえて「フィールドを名前で設定」を使う必要もないだろう。

引数が可変になることは開発効率上のメリットはあるが、対象オブジェクトの名前が変更されてもリテラルは追従しないので、引き渡し後にエンドユーザが関係個所を変更すると動作しなくなる。しかも、Get ( 最終エラー ) にエラーが返らないため、EvaluationError の結果もチェックしなければならず、パッと目の複雑さは増してしまう。

分岐によって、ロジックが分かれる時にも、その分岐で何をしているのかは、フィールド名がそのまま見えている方が（普通の人には）分かりやすい（頭の中で変数に入っている値を想像する必要はないから）。テーブル、フィールド、スクリプト、変数、カスタム関数の命名規則も、汎用性や拡張性を考えれば、1バイト文字に統一したいところだが、普通の人には日本語を使う方がずっと分かりやすい。

つまり、開発者がひとつのスクリプトや関数を、より汎用的に、使い回しが効くようにモジュール化して作ろうとするのに対して、プログラムに詳しくないエンドユーザは、ベタな作りであっても、パッと見て分かりやすい方が良い（カスタマイズしやすい）。

仕事柄、何らかのシステムを開発しては納品するわけだが、FileMaker のシステムの場合、納品後はカスタマイズも含めてユーザ自身でメンテするケースも珍しくない。そうしたケースでは、どのように作るのが開発効率が高く、さらに、エンドユーザにも理解しやすく、ユーザ自身で管理できるかという点は非常に悩む部分だ。

すべての箇所で、どの程度の洗練さ／ベタ加減さが程よいのかを確認することができれば良いのだが、普通は、開発期間もコストもそれを許してはくれない。また、ユーザのスキル次第だが、説明しても、その加減によるメリット／デメリットを正確に理解できるとも限らない。

非 IT 部門（現場部門）の人に問題解決の手段を提供するという FileMaker の製品コンセプトと今後の高機能化のバランスをとっていくことは、なかなか難しいテーマを含んでいるように思う。