ファイルメーカーで商用ウェブサイトを構築する
第3回　担当者が語る、「開発を上手く進めるための秘訣」（2/2）

前のページ

使いやすい新機能を追加していく

　いったんデータがたまっていくと、いろいろな機能を追加したくなります。こういうものは、最初から思い付くものではなく、使っていくうちにふと、「これがあれば、もっと便利じゃないか」と気付き、トライしていくのです。

　たとえば、関連記事検索機能。「ファイルメーカー」というキーワードが入った過去記事を検索して、本文の後ろに関連記事として、タイトルとURLを載せたいというとき、以前ならばZDNet用の検索エンジンを使ってサーチし、そのタイトルとURLを一所懸命コピー＆ペーストしまくるという、肉体労働が必要だったのです。それを、簡単にやる方法はないものか。ファイルメーカーProに入力されている記事なら、それが簡単にできます。

• 検索するキーワードをコピーし、そのコピーしたものを、グローバルフィールド「キーワード」に入れる（グローバルフィールドとは、ファイルメーカーProの中で使う、一時的なデータの置き場）
• 現在のレコード（データ）のレコードID（すべてのレコードに、ユニークな数字がふられている、その番号）を、グローバルフィールド「元のレコード」に入力する（こうしておくと、あとでここに戻れる）
• 検索するフィールド（たとえば、タイトル）に、グローバルフィールド「キーワード」のテキストを入力し、検索をかける
• 検索されたレコードを、ひとつひとつ、検索結果を吐き出すためのグローバルフィールド「検索結果」に書き出していく（書き出しの形式は、本文をHTMLに変換するときの形式にしておく）
• グローバルフィールド「元のレコード」を使って検索し、元のレコードに戻る
• そのレコードの本文の最後に、グローバルフィールド「検索結果」の内容をペーストする

　とまあ、簡単です。

現在は、「タイトル」「本文」「キーワード」の中から選択し、そこにその言葉が入っているレコードを検索する

　こういうものは、制作システムは、記事をHTML化し、アップするだけのものと考えていては、けっして生まれてこないと思います。このシステムは、記事の作成支援にも役立つことが可能なのです。

　書いた本文をもう一度、エディタで開き直したいときに便利なように、本文テキストのフィールドを、Jeditの新規文書として開くボタンも作りました。また、既にHTML化したファイルを、直接Jeditで開いて修正するためのボタンも作ってあります。HTMLコードから直す必要があるような、不測の事態に備えてのことです。

　これだけに限らず、編集者、つまりユーザーの使い勝手を考えて、常に改善していく姿勢が大切なことだと考えます。そして、ファイルメーカーProが、そういったことに応えられる柔軟な設計を持ったソフトウェアなのは間違いないところです。

　とはいえ、最初からすごく便利なシステムができるわけもなく、ある程度の、仕様の絞り込みをしたうえでスタートし、そこから機能を追加していく、というのが私たちの業態に合致したのだといえるでしょう。小さく産んで、大きく育てる、子育ての基本です。

各部署が要求するカスタマイズ項目と、パッケージ仕様との一致

　さて、ここまでは、自分の担当部署で、システムを作るだけでよかったのですが、ほかの部署向けのカスタマイズを担当する必要がでてきました。これはなかなかの難題です。なぜなら、自分の部署の場合は、「自分がやりたいこと」＝「要求仕様」であり、「できないこと」は、仕様からはずせばよかったのですが、ほかの部署のシステムとなると、そうはいきません。

　ファイルメーカーProは、多機能であり、Webコンパニオン機能を使えば、簡単にウェブインタフェースを作ることが可能です。ただ、われわれのシステムでは、この簡単なやり方ではなく、他のアプリケーションとの連動が容易なファイルメーカーProをクライアントにした方法をあえて採用したのです。その結果、ウェブだけをインタフェースに使ったシステムと較べ、インストールと設定で複雑なことをやらざるをえなくなりました。

　まず、ファイルメーカーProを、利用者のクライアントPCにインストールし、ヘルパーアプリケーションの設定をし、スクリプトのなかでユーザー設定をする場合にはそのスクリプト変更まで行うことが必要となりました。簡単なやり方をあえて採用しなかったことで、その分手間がかかることになりましたが、今回、Windowsクライアントを使う他部門については、池永が担当してくれたので、助かりました。それぞれの部署に一人ずつ、ほかのみんなに教えてあげられる人がいると、さらに助かります。そういう人は、その部署で必要な機能についての提案もしてくれるので、全体からみると、大きな改善につながります。

　ファイルメーカーも含め、大多数のソフトウェアベンダーは、利用者からの声を製品に反映しています。同じことは、社内の専用システムにおいても行うべきなのです。

　ほかの部署の仕様は、できるだけそれまでの利用方法や、仕上がりイメージを崩さないようにしました。それでも、こうしてほしい、というアイデアは出てきます。いや、出てくるはずなのです。それを聞いて、システムに反映するための流れを作ることが、大切なのだと思います。

　もちろん、それは、提案を実装するのが難しくないという前提で、初めて成り立ちます。「改良しにくいシステム」や「改良するのに金のかかるシステム」であれば、そんな余裕はないはずですから。

システム部門と部門システム開発者の協力体制

　第1回の図でも説明したように、ファイルメーカーのシステムは、ユーザー部門とバックエンドシステムの中間に位置します。ですから、バックエンドの仕様が変更されると、こちらのほうも変えていなかければなりません。つまり、彼らの仕様変更が、こちらで対応可能な範囲におさまるよう、働きかけなければならないのです。

　バックエンドの仕様変更で、最も多いのがネットワーク系の変更です。特に、サーバ名が変わったり、telnetで使うコマンドの引数が変わったり、telnetからsshに変えたり、sshも2から3に変えようとしたり、FTPを、SFTPのみにしようとしたり、スクリプトの変更だけで済む場合でも、数十個のスクリプトを手作業で変更しなければならなかったりしたことも数多くありました。

　その後は、それに懲りて、できるだけスクリプトをモジュール化し、バックエンドがからむスクリプトには、修正モジュールを必ずかませるようにしました。そうすれば、あとでサーバ名が変更された場合でも、substitute（置換）するためのスクリプトを使って、1カ所を変えるだけですみます。おかげで、ファイルメーカーProのスクリプトはとってもモジュール化されました。スクリプトの数も半端ではないですけれども。

　システム部門は、セキュリティをできるだけきつくしていく傾向にあります。これはもう、サイトとしては当然のことです。ただ、それを無制限に受け入れるのではなく、自動化に支障あるところは、代替の方法でセキュリティを高めるなどして、「考える」必要があります。最初は部門システムであっても、インターネットを利用する以上、会社全体のセキュリティポリシーが重くのしかかってきます。ぜひ、システム部門の担当者ときちんと話をしたうえで、開発することをおすすめします。

　とにかく、情報は命です。システムの変更によって、ユーザーの利便性が完璧に失われてしまうこともありえます。そうならないように、情報が、自分とシステム部門のあいだでちゃんと共有されるようにしておきましょう。

　次回は、ファイルメーカーを使ったウェブ制作システムの具体的な解説をしていきます。

[松尾公也, ITmedia ]

Copyright © ITmedia, Inc. All Rights Reserved.

前のページ | 2/2 | 最初のページ