本当はSQLサーバーに適さない仕事でも
マンガの英訳を、インターネット上での共同作業として不特定多数のボランティアの参加によって実現しているサイトがあった。(だれでも勝手に訳文を書き直すことができるので、サイトのURLは、ここには載せないでおく)
ウェブ上のツールはまだ完成度が低かったが、しかし確かに役に立つものだった。誰かの書いた英訳に、別の誰かが自分の提案を書き添えることができる。英文と元のマンガのふきだしとの対応付けは、Javascriptを用いたブラウザ上のGUIで実現されている。ブラウザの画面に表示されているマンガの上のどこにでも、付箋紙のようなアイコンを設置することができ、それをダブルクリックすると文章の編集ができる。
非常に面白い実用的なツールだ。
ところで・・・ そうやって作成した文書データは、ウェブサーバーの背後にあるSQLサーバー、すなわちリレーショナルデータベースに格納されるようになっているらしい。なぜゆえにSQL? 率直な話、自由な形式の文書データとSQLの相性はそんなに良くない。実際、このアプリケーションでも、SQLサーバーは単にオブジェクトを永続化するだけのために使われていて、SQLで何かクエリーを書いて検索するような、リレーショナルデータベースらしい仕事をしてるようには思えない(その必要もない)。しかしこういう構成はよく見かける。いや、見かけるどころか、この種の「O-Rマッピング」はごく普通の技術的手段といってよい。
リレーショナルデータベース以外のもので、何がしかの構造を持ったデータを管理しようとすると、標準的な手段がない。ゼロから専用のデータベースエンジンを作るのも面倒だし、大金を投じて商用のオブジェクト指向データベースを導入するほどのものでもない。
少々不恰好ではあっても、解決すべき課題を「普通の開発者なら誰もが知っている一般的な道具」に適合するような形に変形して解を実現するというのは、そんなに悪いことではない。手段はなんでもいい、最終的に役に立つものになりさえすればいいのだ。
ただ、道具の都合に合わせて解決すべき課題のほうを変形してしまうというのは、注意していないと使い手を無視して役に立たないものを作ってしまうこともある。手段と目的を取り違えた悲惨な事例はIT関係者なら誰もが耳にする話だ。幸いなことに、私が見かけたサイトの場合は、実際に翻訳作業をしている人たち自身が自分で使うために作ったものなので、そんな心配など私がするまでもない。ちゃんと役に立っている。
個人的な心情としては、オブジェクトの永続化だけのためのRDBを使うというのは嫌いだ。ずっとそう思っていた。なぜなら、SQLでクエリーを書いて何かを検索するという『本来の機能』を全く使わないから。しかし待て。その発想もまた、「この道具は、何が何でもこういう使い方をしなければならない」という思い込みに過ぎないのではないか。役に立てばいいのだ。みんなの役に立つものが手早く作れるなら、それで十分ではないか・・・ くだんの英訳支援ツールを見て、ちょっと反省した。
最近のコメント