ふと感じた、面倒な操作

FileMaker 関連の情報をネットで漁っていて自分のブログにたどり着いたブログ主です、こんにちは。
その記事というのが、こちら。
「スキーマとデータファイルを分けて」
自分で書いたことすらすっかり忘れてました。というか、このブログの存在を忘れかけていました（笑）。

FileMaker でファイルが分かれることで面倒になることはたくさんあるのですけど、特に面倒なのが各種のダイアログ画面。特に開発中に頻繁に開くデータベース管理などで痛感しますが、こいつらはどこかのファイルに属したダイアログで、他のファイルに移動しようと思うと、一旦閉じないといけないんですよね。

そして、別のファイルを最前面に持ってきて、またダイアログを開く。また元に戻ろうとすると、またダイアログを閉じて元のファイルを最前面に持ってきてからまたまたダイアログを開く。もう書いていても舌を噛みそうな操作を繰り返すわけです。

面倒です。とても面倒です。
［スクリプトの管理］のように、ダイアログではなくウィンドウにして、ファイルごとに開けるようにしてください。

開発者は「なまけもの」でちょうど良い

FileMaker に限らず、開発者はどちらかというとオタク系な人が多いようです。「オタク」というと、「ネクラ」（死語？）な感じがしますが、そういう意味ではなく、「技術にのめり込んだ人」（英語だと Geek）といった意味としておきましょう。

こういう人種は、人の知らないこと、人にはできないことを誇示したり、見せびらかしたりするのが大好きです。これが問題になるのは、ついつい「どうだーっ！」ノリでやらなくても良い機能を追加してみたり、本当の意味での使い勝手よりも見た目や新味のある方法で機能を実現したがったりします。つまり、余計なことをしがちなのです。そのために多大な時間を使ったりします。

システムの目的やエンドユーザの使い勝手という（あとコスト）視点で十分に検討されていることであれば、もちろん良いことなのですが、往々にしてそうではないシステムを見かける機会も多いようです。

年次処理の自動化に膨大な手間をかけたり、無意味にカラフルでアイコンばりばりの華美なデザイン（作った人には意味があるのでしょうが。笑）、画面中ボタンだらけでよく使う機能と使用頻度の低い機能のメリハリがついていなかったり、まあ様々です。

「せっかく、お金をかけるなら」という考えるユーザは、とかく「できることは何でも」という気持ちになりがちです。本当に必要な機能、システム開発の目的なんて、どっかにすっとんで、目の前にある画面、機能の細かいことに固執してしまうことがあります。

そうした時に、開発者は、システム開発の目的は何なのか、本当に必要な機能が何であるのか、それを使いやすくするためにはどうすれば良いのか、といった視点で助言（場合によっては議論、笑）ができないと、結局、目標や目的に対してピント外れなシステムになってしまいます。

『神は細部に宿る』 とも言いますが、システムの場合は、部分最適化よりも、システムを使うビジネス環境を包括した全体最適化こそが大切なのだと思います。私は。

文明の進化は「人が楽をしたい」という動機によるものですが、システムもそうではないでしょうか。使う人がいかに楽をするか、作る人がいかに楽をするか。真面目な人は、つい徹夜した日数、休日をつぶした日数といった、「どれだけ努力をしたか」を追求しがちですが、本当はそんなことには意味はありません。

いかに簡単に、楽に、成果を残すか。営業的には大変さをアピールすることも必要かもしれませんが（笑）、開発者は「なまけもの」くらいでちょうど良いと思います。

決して、目の前の仕事から逃げ出したいというわけではありません。たぶん（笑）。

さて、先日、FileMaker カンファレンス 2010 がありました。たくさんのユーザが集まり、盛り上がったようです。
FileMaker カンファレンス 2010 出展報告

時節柄、FileMaker GO に関係するセッションや展示が多かったようですが、これも流行というものでしょう。３年後に、データベースの利用環境がどのように変わっているのか、非常に興味深いところです。

相変わらず、まとまりがありませんが、思ったことを思った順に書いたということで。。。

FileMaker GO の購入／配布方法

FileMaker GO は、iOS で動作するアプリですので、配布方法は通常のアプリと同じです。
つまり、App Store で購入するか、贈ってもらってから、ダウンロード、インストールということになります。

購入する立場ではクレジットカードが必要になる上に、iPhoneやiPadの管理のためには、デバイス数分の Apple ID が必要になります。個人で使う分には問題ない、こうした入手、配布方法は、法人名義で一括購入して、多数のデバイスが存在する場合には、大きな問題になります。

先日のファイルメーカー社のプレス向け発表会でも話題になったようですが、ニュースサイトの記事にもなっているようです。
iOSアプリは企業での組織的導入に耐え得るか

もっともな懸念です。残念ながら、現時点ではこの問題を根本的に解決することはできません。

が、ブログ主は、先日ジョブズが発表した iOS 4.2 の新機能の中に、「new device management capabilities」というくだりがあった点を見逃してはいません。Apple の iOS 4.2 紹介ページにも記載があります。

Apple - iPad - iOS 4.2 Software Update coming in November

想像するに、これは企業アカウントで複数デバイスを管理するための仕組みではないかと思われます。
11月予定の iOS 4.2 がリリースされ、購入や配布の問題がクリアされれば、FileMaker GO 普及の課題がひとつクリアされることになります。ついでに、App Store が一括購入のディスカウントに対応すればなお良いですが、そこまでは発表されていないので、まあ今回のアップロードではないのかもしれません。

ただ、Apple も iOS の進化で企業向けの機能アップを図ってきましたし、上記ページでも「Enhanced enterprise support」と銘打っているように、今後は、iPhone/iPad の企業向け市場に食い込むための施策を次々と打ってくるでしょう。アプリの配布が App Store に制限されている点から考えても、料金制度の柔軟性は今後は必要になってくるでしょう。きっと。

とりあえずは、現地時間 9/8 に予定されている iOS 4.1 ですね。FileMaker GO がその上で問題なく動作するかをチェックしなければ。。。

あと、余談ですが、某 KP 社のファックス番号が変更になったようです（新番号：050-3156-1409）。
会社情報

噂では、ペーパーレスを目指して、デジタル複合機を廃止、インターネットFAXサービスを利用することなったそうです。
営業ファックスは印刷せずにポイッと捨てられるし、どこからでもファックスを確認できるようになって、何かハッピーな模様です。

ただ、紙を直接ファックス送信できなくなったため、紙はスキャンしてから送信するそうな。大変かと心配されていましたが、実際にはそういう状況がほとんどないことも分かったそうな。皆さん、限りある地球資源を大切にしましょう（笑）。

FileMaker Go と iOS 4.2

先日、スティーブ・ジョブズのキーノートに釘付けになっていた方も多いと思いますが、私もそのクチです（笑）。
iPhone、iPad ユーザでもあるので、iOS のアップデートの情報は楽しみにしていた点ですが、果たして、期待通りの内容となっていました。

なかでも、iOS 4.2 で実現されるという「ワイヤレス印刷」。特に、iPad はシンクライアント、顧客に見せる、顧客が操作できるデバイスとして利用される場面が増えてくるでしょうから、印刷して資料を渡せるようになるのは、大きなメリットでしょう。

ただ、機能の詳細が分からないのですが、iOS 4.2 が出て、すぐに FileMaker Go で印刷ができるようになるかというと、よく分かりません。アプリ側がその API を利用するようになって使えるような機能だと、FileMaker Go のアップデート待ちという状況もありそうです。

FileMaker（Proの方）は基本的にプリンタの用紙設定サイズに合わせて、印刷を行います。FileMaker Pro で開発を行う必要がある FileMaker Go システムだと、どうやって用紙サイズを知ったり、出力できたりするのかは、まだ詳しい解説や資料もなく、今後の Apple 社や FileMaker 社の発表内容に注目するしかないようです。

FileMaker Go も、FileMaker の iPhone/iPad 版というよりは、FileMaker の iOS 版と考えた方が良いかもしれませんね。iOS は今後もハイペースで進化を続けるでしょうから、FileMaker Go もそれにともなって、少なくとも OS 標準のサービス類には対応していくことで機能アップを続けていくでしょう。

数年おきのバージョンアップがルーティン化している PC 版の更新間隔と比べると、より細かい頻度でのアップデートがリリースされることには期待したいものですが、その結果、PC 版とは別の進化の方向も出てくるかもしれません。

データベースの基本機能は同じでも、画面方向の変化によるスクリプトトリガ、カメラやフォトライブラリからの画像取り込み、電話録音、3軸ジャイロスコープや加速度センサーへのアクセス（取得関数経由？）など、FileMaker Go に固有の機能が付いていくことは十分にありえるでしょう（iPhone/iPad市場に真面目にコミットしていくなら）。

FileMaker GO は、最初のリリースバージョンという視点からすると、「再現性」という点で非常によくできていると個人的には思います。今後は、また別の面での機能性に期待したいですね。

「簡単」と「安易」の違い

仕事柄、他の会社や人が作った FileMaker システムの改修や解析を頼まれることがあります。
多くの場合、FileMaker で開発されたシステムは、仕様に関する情報が整備されていないので、ファイルそのものを開いて、仕様や動作の探求を行うことになります。

そこで、よく感じるのは、FileMaker の「簡単」さを生かして開発をしているというよりも、単に「安直」な開発で済ませてしまっているケースの多さです。

FileMaker は、非プログラマの人でもデータベースを作成できる環境として「簡単」さがよくアピールされています。確かに、そうしたメリットがあることに間違いはないのですが、それを一定の規模以上の“システム”として開発する場合には、気を付けなければならない注意点がいろいろあります。

例えば、業務システムであれば複数ゲストでの利用が普通だと思いますが、複数のレコードを一括処理するような機能であれば、排他制御に対するケアが必須です。FileMaker は、標準でトランザクション管理の機能がないので、そうしたケアを行うと、他のデータベースを使う場合よりも、かえって手間がかかってしまったりします。しかし、それを怠ってしまうと、「複数の人が同時に操作を行ったら、意図しない結果になった」という事態になります。

実際には、ユーザ数が少なかったり、ユーザ間で役割分担があって使う機能が重複していなかったりといった運用環境に助けられて、幸運にも問題が生じていなかったり、問題が生じる頻度が低いために「再現性がない」と対処療法で済ませていただろうシステムを結構見かけます。

全置換、レコード移動の Loop 内のフィールド設定、現在／対象レコードの削除、照合インポートなどが、きちんとしたエラー処理もなく、スクリプト内に無造作に置かれているのを見ると、暗澹たる気持ちになります。

他にも、処理速度、ネットワークトラフィックを考えていないシステム、誰でも管理者権限でアクセスできるシステム、操作性が統一されていないシステムなど、「安直」なパターンにはいろいろあります。

システムを開発するためには、開発環境以前に知っておかなければならないプログラミング一般の決めごと、注意事項、禁止事項があります。言い方は悪いかもしれませんが、FileMaker で開発を行っている会社には、単なる「ユーザ上がり」で、他言語、他データベースなら当たり前のマナーを知らずに、システム開発をビジネスとして展開しているところもあるようです。

そうした知識を持たないために「簡単」と「安易」の違いを理解することもなく、システム開発をビジネスとして展開してしまう恐さ。そして、普通のユーザにとっては、そうした会社を見分けることはとても難しいだろうという事実。う〜〜〜ん、どうしたらこうした状況が改善されるのでしょうかね。

別に何も解決策は提示しませんが（笑）、「安易なシステムは恐いなー」と思ったと日記には書いておこう。

［ファイルを開く］スクリプトステップ

実にご無沙汰の更新となってしまいました。何でも某 KP 社はこの夏とても忙しいことになっていたような。

暑い上に忙しいと、みんなが口数が減って、殺気立ってくるので、あまり楽しいブログネタが出てきません（笑）。そういえば、ここ数日２台あるエアコンのうち１台の調子が悪く、涼しい会議スペースにみんなが移動してしまったという事件もあった模様です。

さて、FileMaker についての話題ですが、今回は［ファイルを開く］スクリプトステップです。おそらく、このスクリプトステップを使ったことのない開発者はいないと思われますが、意外に「もっと、こうだったら良いのに」といった話は聞いたことがありません。みんな満足しているのでしょうか？

ブログ主は、はっきり言って不満です。どうあってほしいかというと、このスクリプトステップのオプションとして、ファイルを開くアカウント情報をオプションで設定させてほしいのです。

ご存知の方も多いと思いますが、FileMaker はあるファイルから別のファイルを開くとき、同じアカウント名、パスワードが存在すれば、アカウント情報が継承されます。FileMaker は、複数ファイルにまたがるアカウントの管理機能がないので、元ファイルのアカウントを基準にするのは、シームレスな使い勝手を実現するために、まあ妥当な仕様でしょう。

問題は、この仕組みが一連のファイルの間で同じアカウント名、パスワードの設定があった場合にのみ有効という点です。わざわざ複数のファイル間のアカウント管理機能を開発するほどではない時には、デフォルトのアカウントを設定しない限り、ファイルを開く時に認証のダイアログが表示されてしまうわけです。

デフォルトのアカウントを設定するということは、アカウント名、パスワードを知らない人でもとりあえずファイルは開けてしまうわけで、対策を施したとしても、セキュリティ的に好ましい状態ではありません。なので、現在のアカウントとは違うが、アカウントを指定して他のファイルを開くという機能がほしくなるのです。

まあ、［再ログイン］を駆使してできなくはないのですが、別のアカウントに変わってファイルを開いた後、元のアカウントに戻るという処理をしなければならないので、面倒ですし、途中でエラったときの処理も慎重に行わなければなりません。

結論、「［ファイルを開く］スクリプトステップに、アカウント名、パスワードの設定オプションを付けてほしい」でした。

余談ですが、今年も「FileMaker カンファレンス」が開催されるようです。開発者、ユーザの交流、技術情報、商品、ソリューション情報の共有などのためにも、とても良いことだと思います。なにせ、情報の少ないソフトウェアは使えませんから。

某 KP 社は、今年もショーケースを出展するとのことです。
FileMaker カンファレンス 2010 のお知らせ

しゃちょーも FileMaker Go のテクニカルトラックでスピーカーをするそうなので、是非がんばってほしいものです。