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

ZDNet Macの実践ファイルメーカー連載の第3回は、ZDNet MacおよびZDNet Products編集部を例に、「開発を上手く進めるための秘訣」を解説します。

　前回に述べたように、ファイルメーカーProは、広範囲に対応できる、非常にフレキシブルな構造をもち、開発体制が整えられています。しかし、開発側、利用者側の体制もまた、大切です。その両方を兼ねた、ZDNet MacおよびZDNet Products編集部を例に、「開発を上手く進めるための秘訣」を解説していきます。

ZDNet Mac/ZDNet Productsを中心としたスタート部署の思惑

　第1回で述べたように、ZDNet Mac（旧MacWIRE）でスタートしたファイルメーカーの制作システムは、この部署だけに限定されたものでした。このときは、ZDNetのなかの、ほかのチャンネルと連動するなどということは、まったく考えられませんでした。ほとんどが手動もしくは半手動の制作ルーチンだったからです。

　ZDNet Macは、この制作専任者のコストを削ろうと考えました。ほかのチャンネルでは、執筆された記事のテキストをHTMLにして、それをFTPし、ウェブサーバにアップするだけの専任者を置いていました。しかし、その専任者は、記事をアップする時間帯だけ拘束してしまうことになり、支払う金額はそれだけ大きなものになります。予算が潤沢にあれば別ですが、Macのように、市場が限定されたチャンネルで、それだけのコストを負担するわけにはいきません。一方、編集部員からは、「これ以上仕事を増やしてくれるな。編集以上の作業はしたくない」という泣きが入っていたのです。これは、ウェブアップにおいて、編集部員の負担を極力減らすしかありません。

　それまで、Macコンテンツの制作は、編集者の松山由美子が一手に引き受けていました。彼女が異動し、別のチャンネルを担当するようになったため、そのぶんをほかの編集者ですべて負担しなければなりません。しかし、聞いてみたところ、これまでのアップ作業の手順はおそろしく大変ではありませんか。

作業方法を単純化すること

　ファイルメーカー化する以前のデザインを見ていきましょう。

　1996年のMacWEEK Onlineの記事を見ると、けっこう手が込んでいるのがわかります。横幅が広いだけあって、テキストが画像を回り込んでいます。

　1997年1月のMacworld Expoレポートでは、画像を左右に配置しています。これは、この時点では手作業でないとできませんでした。1999年のExpoレポートも同様です。

　また、インデックスの作成にも手間がかかっていました。新しい記事をアップすると、そのタイトルとURLを、以前のインデックスファイルに追加して、再度FTP＆アップするのです。このコピー＆ペーストを間違わずに進めるのもなかなか大変なものなのです。

　そこで、やるべきことは、こちらの作業負担が減るように、構造を作り替えることです。手作業でやりやすいものも、コンピュータにやらせるのは大変というものがあります。たとえば、ある記事から、その日の別の記事にリンクさせるとか、日別インデックスで、次の日へのリンクと前の日へのリンクを入れるというのは、大変な作業になります。翌日へのリンクを入れるという作業は、次の日のインデックスができないと進められません。ということは、翌日のインデックスを作ったら、その前の日のインデックスも作り直さなければならないのです。

　それを回避するために、日別インデックスには、翌日のインデックスを入れないことにして、そのかわりにカレンダーのHTMLファイルを作ることにしました。ユーザビリティにおいてはよくないかもしれませんが、作業上の軽減を図る上では仕方ありません。おおまかに言うと、1日の記事アップの流れは次のようになります：

• 記事単体のHTML化→FTP→ウェブサーバにアップ
• 日付け別インデックスのHTML化→FTP→ウェブサーバにアップ
• 記事インクルードファイルのHTML化→FTP→ウェブサーバにアップ
• トップページのHTML化→FTP→ウェブサーバにアップ
• カレンダーファイルのHTML化→FTP→ウェブサーバにアップ

編集作業も減らせるように

　記事の本文の構造は、できるだけ単純なものにしました。メールマガジンのMacintosh WIRE (現MacWIRE Express) 用に書かれた記事をそのままコピー＆ペーストすれば、そのままHTMLに変換できるというのが理想です。ライターからあがってきた記事テキストを、あまり大きな変更なしでアップできるようにしたいという希望がありました。原稿整理だけではなく、整形の作業まではやりたくなかったのです。

　たとえば、見出しをつけたい場合には、「先頭が●で始まる行」が、

タグで囲まれるようにし、「前後に空行が入ったパラグラフは」

タグで囲むようにしました。前後に半角スペースの入ったURLは、そのURLが入った「リンク」に変換されます。「【テキスト】 ( URL ) 」という形式の部分は、やはりリンクになります。このように、編集者的にわかりやすい置換ルールをある程度作っておいて、必要に応じてそのルールを増やしていくことにしました。

　本文テキストをHTML文に置き換えるのには、Jeditの力を借りました。ファイルメーカーProのスクリプトで、JeditをコントロールするためのAppleScriptを実行させるのです。この部分は、ルールが増えて、テーブル作表や、インタビュー用の名前のカラーリング、注釈のアンカーに飛ばし、アンカーから戻ってくるためのものまで、増やしていっており、いまでも使われています。

　ここのテキスト→HTML変換の部分は、ルールを固定化できる部署と、できない部署があります。すべてを一つのルールで統一するというのは、まあ、開発部門からすれば、「絶対に必須」でしょうが、利用者側からすれば、必要に応じて拡張したいはずです。その拡張方法としては、私が作ったJeditベースのものだけではなく、ファイルメーカーProのスクリプトだけを使ったものもあります。Windowsマシンで使う場合には、そのルールとルーチンを使うことになります。ZDNet Macでは、全員がMacユーザーという前提なので、ファイルメーカーProのMac版＋Jeditという組み合わせで利用しているのです。

　このように、後々発展していきそうなスクリプトは、簡単にいじることができるようにしておくのがよいと思います。これが、自分たちが制御不能なプログラムであれば、おいそれと「変えてくれ」は言い出しにくいものなのです。もちろん、ルールが固定化できるならば、それにこしたことはありません。でも、ウェブサイトの構築においては、現実的ではないでしょう。まあ、AppleScriptを使ったエディタのマクロという、実力にあった方法を選んだのが、私たちの勝因だったようです。

　最初のほうは、なんとかPerlでできないかとやってみたのですが、実力不足でだめでした。あと、Mac OS XならばAppleScriptとPerlの組み合わせでできるのですが、WindowsではActivePerlを新たにインストールしなければならず、難しいものがあったのです。まあ、いつか、置き換えて、さらに高速で高機能なモジュールにしたいと思っています。Perlベースのものができたら、そのモジュールだけ置き換えればよいので、メンテナンスも楽だと思います。ファイルメーカーProの内部関数だけでも、それに近いことは可能です。現に、Windowsクライアント用のHTML化プログラムには、ファイルメーカーProの関数のみを使っています。

　見出しのフォントカラーを変えたいとか、テーブル作成ルールに、新しいのを入れたいとか、1カ月に1回くらいは、必ず何がしか要請があります。そう、編集者というのは、わがままなユーザーなのです。おまけに、ライターからも、こういうデザインにしてほしいという要請があるときがあります。ちなみに、注釈をつけるルールは、こばやしゆたか氏からの要請で入れたものです。

[松尾公也, ITmedia ]

Copyright© 2012 ITmedia, Inc. All Rights Reserved.

前のページ | 1/2 | 次のページ