[IM]新規レコード作成時の挙動

INTER-Mediatorで、テーブルに新たにレコードを作るときの挙動にバグがあり、全体的に見直しをしました。以下の内容は、Ver.3.4以降で有効です。

まず、「新規レコード作成」のクライアント側でのAPI、つまり、JavaScriptベースでの呼び出しは4カ所あります。最初の3つは、主としてINTER-Mediator自身が使うものです。

  • INTERMediator.insertButton(…):レコードの繰り返しの下などに表示されるボタン
  • INTERMediator.insertRecordFromNavi(…):ナビゲーションのボタン
  • INTERMediator.clickPostOnlyButton(node):新規レコード作成専用モード
  • INTERMediator_DBAdapter.db_createRecordWithAuth(args, completion):汎用

最後のメソッドは、INTERMediator_DBAdapter.db_createRecordでもかまいませんが、上記のメソッドだと認証のある場合、ない場合、どちらでも利用できます。

さて、データベース処理に関係する定義ファイル内のコンテキストのキーはまとめるとこんな感じです。ここでは、レコード作成に絞って考えます。

  • name:コンテキスト名、tableがないとこの名前のテーブルにINSERTする
  • table:実際のテーブル名を記述
  • view:(無視)
  • records:(ナビゲーションのボタンでレコードを作ったときの動作に影響)
  • key:(同上)
  • relation:(関連レコードの作成時に利用)
  • query:(この設定は無視する)
  • sort:(無意味)
  • default-values:(フィールドの初期値)
  • script:(新規レコード作成時に実行するスクリプトを指定、主にFileMaker)
  • アクセス権設定:(新規レコードの認可の定義)

一時期のINTER-Mediatorでは、queryキーで指定した内容を、初期値として設定するようなプログラムが組み込まれていました。そうしないと、新規レコードを作った後に「検索されない」という状況が発生するからです。しかし、それはdefault-valuesキーで指定をすることで、検索される状態は設定できるので、あえて、queryキーを無視するようにしました。

一方、relationキーについては、関連レコードのテンプレート処理側では、これに対応した外部キーへの値の設定がないと、新しく作ったレコードは関連レコードになりません。なので、INTERMediator.insertbuttonメソッド内で、コンテキストのこの情報を見て、外部キーのフィールドの初期値を自動的に与えています。なお、演算子は無視しているので、演算子に>があるような場合などは要注意です。INTERMediator.insertRecordFromNaviメソッドは、ナビゲーションのボタンで呼び出されます。従って、通常は関連レコードのコンテキストには適用されず、relationキーは無視します。INTERMediator_DBAdapter.db_createRecordWithAuthについても、relationキーは無視します。

一方、JavaScriptのプログラムで、検索条件、ソート条件、さらに新規レコードの初期値を指定するプロパティが以下のように定義されています。新規レコードの初期値はVer.3.4が初出です。

  • INTERMediator.additionalCondition:(無視する)
  • INTERMediator.additionalSortKey:(無意味)
  • INTERMediator.additionalFieldValueOnNewRecord:(初期値として適用される)

新規レコードではソート条件は関係ありません。検索条件のINTERMediator.additionalConditionについては、新規レコード作成時は一切無視されます。一方、すべての新規レコード作成時に、INTERMediator.additionalFieldValueOnNewRecordに指定した値が初期値として設定されます。

まとめると、新規レコード作成時には検索条件は一切利用しません。その代わり、スタティックな初期値としてのdefault-valuesキー、ダイナミックな初期値としてのINTERMediator.additionalFieldValueOnNewRecordが適用されます。また、関連レコード内でのInsertボタンを押したときにはrelationキーの値が利用されますが、その他の場合にはrelationキーは適用されません。

7つのデータベース7つの世界

7つのデータベース7つの世界」という書籍の書評を書こう(久しぶりに書評を書くぞ)。「7つの言語…」が有名な米国のPragmatic Bookshelfから出版された翻訳本であり、この書籍についてはオーム社から発売された。原書は手にしていないので、翻訳本についての紹介になる。

本書で紹介しているのは、PostgreSQL、Riak、HBase、MongoDB、CouchDB、Neo4J、Redisとちょうど7つだ。まず、このチョイスにMySQLがないことがポイントだ。データベースと言えばRDBという時代が長く続いたがここ数年来NoSQL(Not-only SQL)がブームになっている。とは言え、RDBやSQLがなくなるわけではなく、データベースにも適材適所の時代が来たということである。NoSQLにもいろいろなタイプがあり、キーバリュー、列指向、ドキュメント指向、グラフ指向から代表的なものを選択して紹介しているわけである。

1つのDBあたり、30〜40ページというところで、すべてを知るための書籍ではない。これは「7つの…」シリーズで踏襲されている「その世界をツアーしガイドする」というコンセプトによる。DBの概要となると、言語とは少し違う。本書では基本的なデータの扱いの概念と、そのDBを使ったおいしい事例というところにフォーカスされている。詳細や他の世界との接点については「宿題」として自分で考えましょうというスタンスだ。たとえば、MongoDBではMapReduceの事例をしっかりと紹介しているが、ショートカットや正規表現については宿題として自分で調べることになっている。

NoSQLは何だと言われても、うまく答えは見つからないが、本書はNoSQLの世界への非常に巧みなガイダンスとなっている。DBは何と言っても基本的なデータの扱いという絶対にはずせない情報があり、そこはどのDBについても実践的な解説でうまく体験できるような説明となっている。それぞれのDBについての最初の解説を読むだけでも、DBのコアな仕組みが見えてくる。NoSQLに興味がある人は、まず最初に手に取って読んでみることを勧めたい。

ここからは余談…コンピュータ書籍はオライリーの独断場のような様相であると言い切るとして、その中で、Pragmatic Bookshelfの企画力には注目していた。オライリーはユニークな企画ものもあるけど、やはり「Perl」とか「SSH」といった直球勝負な書籍が中心だ。そのオライリーにもっと早い重い直球で勝負するぞと意気込んだところでなかなか勝てない。しかし、Pragmaticはある意味オライリーがだしそうにない書籍という点で注目できるのである。個人的には「SQL Antipatterns」のファンでもある。そのSQL Antipatternsは、日本ではオライリーから出た。え?なんで?と思って調べたら、Pragmatic Bookshelfの書籍のディストリビューション(意味的には販売会社だろう)はオライリーだったのである。やっぱりオライリーの独断場なのだろうか。

余談は続くが、Pragmaticの書籍をアメリカのアマゾンから買って読んでいた頃、ふと、電子版は割引と書いてある。紙の書籍を持っていないと買えない仕組みである。その絶妙な価格付けで、思わず電子版を買ってしまった。書籍の4分の1ほどの値段で電子版が購入でき、しかも改訂があれば最新版が手に入る。紙の書籍を買って、必要なら電子版を買い、読んだら紙の書籍は古書流通に流す…。これだと、自炊もしなくてもいいし、軽いPDFやePubファイルが手に入る。中身の翻訳はもちろん歓迎されることだが、こうした仕組みも含めて出版社にはローカライズして欲しいところだ。

手入力する文字や数字に関するメモ

追記:6とbも間違うぞという指摘があったので、修正します。

ユーザ名やパスワードは、時として「手で入力する」ことを必要とします。もちろん、コピペもあるんですが、手入力を必要にすることで、意図的にセキュリティレベルを高めることもあるかもしれません。そのとき、印刷状況によって、数字の「1」と「小文字のL」の見分けがつかなかったりということが発生します。もちろん、フォントの工夫と、アルファベットおよび数字などの使用している文字をサンプルとして印刷するということで対処する場合もあるかもしれません。

ここで、いっそのこと、間違えやすい文字列はもともと含めないでアカウントやパスワードを作るのがいいのではないかとも言えます。とはいえ、「間違いやすい」というのもちょっと曖昧な定義です。ご意見をいただければと思います。なお、ここでは記号類、全角文字は排除されているものとします。

数字+アルファベット大文字

  • 0 O(見栄えが似ている)
  • 1 I(見栄えが似ている)
  • Q 9(発音が似ている)

数字+アルファベット大文字小文字

  • 1 l i j(見栄えが似ている)
  • 6 b(見栄えが似ている)
  • 0 O o(見栄えが似ている)
  • Q 9 q(発音が似ている)
  • C c(見栄えが似ている)
  • K k(見栄えが似ている)
  • S s(見栄えが似ている)
  • V v(見栄えが似ている)
  • W w(見栄えが似ている)
  • X x(見栄えが似ている)
  • Z z(見栄えが似ている)

Zとzを間違えるかというと、微妙かもしれませんが、ありそうなことを排除することを考えています。フォントに寄っては、Zとzは区別しずらい、あるいは間違えやすいことはあるだろうということです。それでも、Tとtは区別はつくだろうとうことでリストには入れていません。

Qと9の区別は、日本語だけだろうということもあります。また、大文字と小文字の違いがある場合には発音だけでは判定できません。音声でコードを伝える必要がある場合は、アルファベットは大文字か小文字かのいずれかだけにしないといけないでしょう。どちらを使うかは、使用するシステムに依存すると思います。

上記のルールを適用して間違えやすい文字列を排除すると、使える文字列はこうなります。

数字+アルファベット大文字(30文字)

  •  2345678ABCDEFGHJKLMNPRSTUVWXYZ

数字+アルファベット大文字小文字(3735文字)

  •  234578ABDEFGHJLMNPRTUYadefghmnprtuy

以前、クーポンコードのようなものを考えたとき、その手入力が必要としたらどうなるかを考えました。その仕様がどうだったかはどうでもいいので、現状での記述に揃えます。ただ、ランダムに作るというよりも、生成した乱数をビットに分離すれば、変換はやりやすいと考えました。つまり、base64の原理です。4ビット16文字なら16進表現の方がいいでしょう。6ビット64文字にするには、上記のいずれのパターンも足りません。そこで、5ビット32文字で考えます。「数字+アルファベット大文字小文字」をもとに、さらに微妙に間違いが発生しないかと考えられる以下の53文字を排除するとします。

  • m n r(お互いにデザインが類似している)
  • u y (大文字のデザインにそこそこ近い)

こうして残ったのが以下の32文字、つまり5ビットです。5ビット分ずつ、以下の文字列に置き換えれば、乱数からそのエンコード表現ができあがり、手入力時に間違いやすい文字列が排除されているということになります。

数字+アルファベット大文字小文字(32文字)

  • 234578ABDEFGHJLMNPRTUYadefghprty

こんなことまで考えて、クーポンシステムを作ったのに、全然使われなかった…。まあ、それは仕方ないとして、別件でランダムパスワードの生成が必要になったので、思い出してブログにまとめました。

[FMRP]TOの名前付け

パターンとして微妙、あるいはパターンと言えるほどの考察がないのじゃないのかと思われる1つのパターンを紹介しましょう。しかしながら、問題点は明確であると思います。

カテゴリ:要素

略称:ネーミング

名前:TOの名前付け(Ver.1.0)

問題:

  • TOは任意の名前が設定できる。そして自動的に名前が設定されてしまうが、そのままにすると後から混乱が生じる。
  • TOの名前は、元になるテーブル定義の名前とはまったく関係ない名前をつけてしまうこともできてしまう。
  • 1つのテーブル定義に対してたくさんのTOを定義することも多く、TO選択のポップアップメニューは混乱しがちである。TO選択時に目的のTOを確実に素早く探し出せる名前付けルールが必要である

解決策:

  • TOには、TOグループを端的に示す「グループ名」と、どのテーブルをもとしているかを示す「テーブル名」を含めた名前を付ける

フォース:

  • 1つのソリューションで一貫した名前付けのルールを持たせないと混乱する
  • グループ名とテーブル名だけでは、時として同じ名前の異なるTOが登場し、完全な名前付けができない。そこで、バリエーションにあるように、「用途名」といった補助的な名前を追加する必要が発生する

バリエーション:

  • 「グループ名_テーブル名」を基本とする。TOグループ内で同じテーブル定義を元にしたTOが複数登場する場合には、用途に応じて、「グループ名_テーブル名_用途名」、あるいは、「グループ名_用途名_テーブル名」をTO名とする。この名前付けルールだと、TO選択のポップアップメニュー等で、同一TOグループの項目がまとまる。その中で後半のテーブル名や用途名を見つけ出すという作業になる。TOグループを基準に考える場合には適した方法であると言える。
  • 「テーブル名_グループ名」を基本として、前記のバリエーションと同様に、さらに用途名を付け加える。この名前付けルールだと、TO選択のポップアップメニュー等で、同一のテーブル定義をもとにしたTOがまとまる。その中で後半のTOグループ名や用途名を見つけ出すという作業になる。テーブル定義名を基準に考える場合には適した方法であると言える。
  • TOの結合の流れに従って名前を付ける。名前からリレーションシップの中での関係が一目瞭然になるが、TO名が長くなり過ぎる傾向がある

関連パターン:(TBD)

FileMakerリレーションパターンの前提知識

本当はこれを最初にまとめないといけないのかもしれません。そもそも、パターンの記述を読み込むための前提知識は前提知識として定義できるはずです。パターン集ではあまりそういう記述を見ませんが、パターンなのか、たんなる機能なのかを判断する上でも、必要な情報と考えます。つまり、前提知識はパターンではないというところが出発点です。前提知識は、問題解決というよりも、単一の機能であるとも言えるかもしれません。以下、見出しが前提知識として提示します。

テーブル、フィールドといったデータベースの基本

データベースあるいは表形式のデータそのものは、フォーマットです。もしかすると、広い意味でのシステム構築パターンには「データベースを使う」というのがあるかもしれませんが、ここではリレーショナルデータベースを使用した場合の設計に関する問題解決にフォーカスしているので、フィールドやレコードといった存在、あるいはその概念は前提知識とします。

テーブル演算によるデータ処理

テーブル演算そのものは、パターンでないと考えますが、パターンの中で特定のテーブル演算を使うことはあり得ます。言い換えれば、テーブル同士の演算があるという前提から出発している話なので、これらも前提知識とします。

リレーションシップによるテーブル結合

前項と同じ意味ですが、テーブル同士は結合できるという事実も、前提知識です。いや、むしろ、この仕組みが出発点なのです。これはパターンではなく、いちばんコアな意味での前提知識と言えるでしょう。

FileMakerに関する機能

ここの切り分けが難しいところですし、どこまでの機能が前提知識で、どこからがパターンなのかは問題解決への貢献度や、自明さから考えることになるでしょう。「レイアウト」というのは機能であり、動作は明確であり、目的を持って使えるものです。しかしながら、レイアウトの機能でも「データに応じて文字列の色を変更したい」という問題点から出発すれば、「条件付き書式」はパターンかもしれません。一方、条件付き書式に対するトレードオフはFileMakerで実装しているかどうかの問題しかなく、問題解決で発生する葛藤は薄いでしょう。そうなると、「条件付き書式」はやっぱり単なる機能でしかないかなと考えるわけです。機能そのものがパターンになり得る場合も一部はあると考えますしかしながら、一般には機能そのものはパターンにはなり得ないと考えます。

他に項目を思い付いたらまた追記します。

[FMRP]種類フィールドを持つテーブル

前回の、FileMakerリレーションパターンの記事は、「いいね」が非常に少なくなり、みんなが引いているのが分かりますが、ともかく進めましょう。前回は、「種類フィールドを持つテーブル」というパターンがなぜ問題解決につながるのかを説明しました。パターンでは、そうした発見を、パターン記述にします。そのとき、適当に書き散らすのではなく、項目を決めておくのが一般的です。それもふまえて、「種類フィールド」パータンを記述したのが以下の通りです。

カテゴリ:リレーションシップ

略称:種類フィールド

名前:種類フィールドを持つテーブル(Ver.1.0)

問題:

  • 異なる種類の情報を一元的に管理をしたい
  • 異なる種類の情報を1つのテーブルでまとめて管理をしたい

解決策:

  • 種類ごとにテーブルを作るのではなく、単一のテーブルにさまざまな種類のデータをまとめて記録する。
  • 一般には種類ごとに必要なフィールドは異なるので、テーブルの定義では、複数の種類に必要なフィールドが混在する。不要なフィールドはつかなければ良い。
  • 一部のフィールドは、異なる種類で共通に使って良い。たとえば、「完了」フラグや、「発生日」といったフィールドがその例である。
  • そのときに、1つ1つのレコードに対して、いくつかある情報の種類のどれなのかを記録するためのフィールドが必要になる。そのフィールドには通常は番号を入力して、番号で情報の種類を特定することになる。

フォース:

  • 種類に対応したフィールドを求めるような仕組みはデータベースには一般にはない。そういう仕組みの構築も面白そうではあるが、実用的な意味と、限られた時間でシステム構築する上では、種類を特定する番号と、利用するフィールドの対応付けはドキュメンテーションで済ませることで大きな問題は発生しない。
  • フィールドの命名規則で、おのおののフィールドがどの種類の情報に関連したものかを明示する方法も考えられるが、一長一短がある。たとえば売り上げに関するフィールドは「sales_金額」「sales_個数」、コンタクト情報に関するフィールドは「con_名前」などとする。一見分かりやすそうに見えるが、異なる種類の情報でも、共通に使いたいフィールドが出てきたとき、名前を変えるべきなのかどうなのか、迷う事になる。また、複数の情報にまたがって使うようになっても名前が単一の情報を示してると、誤解を生じる。一般に、開発中のドメインについての理解があれば、「仕入金額」「受注個数」「担当者名前」などの名称で、概ね何の種類の情報かは分かるのが一般的だろう。種類に応じたフィールド名は、メンテナンスの問題が生じないかどうかをよく検討する必要がある。種類を特定するキーワードを入れないとすれば、これもドキュメンテーションにより各フィールドの利用方法を周知させる必要が発生する。
  • 粒度の小さな情報(たとえば、日時のみ、商品名のみ)を一元化したい場合には、このパターンではなく、別のパターン(名称未定、商品名についてはマスター処理と同等)を適用すべきである。このパターンは、複数のフィールドからなる情報がいくつも種類があり、それらをまとめて管理したい場合の1つの設計指針である。

バリエーション:

  • 種類フィールドを持つテーブルのレコードと、実際のデータがあるレコードを1対1でリンクを取ってもよい。たとえば、すでにある種のテーブルが利用されている上で、別の種類の情報と一元的に管理をしたい場合は、新たな情報については種類フィールドを持つテーブルにまとめるとしても、既存のテーブルに対してはリンクを取るだけにすることもできる。このとき、種類フィールドを持つテーブル側に外部キーフィールドーを設定し、元から存在するテーブルの主キー値を代入して対応付けをすれば良い。通常は、種類フィールドを持つテーブルから元からあるテーブルへの参照が多いと考えられるからである。
  • 情報の種類によって表示すべき情報が異なっている場合でも、それらを一覧したい場合もある。そのときは、表示用文字列の計算フィールドを作成すれば良い。たとえば、売り上げ情報なら金額、コンタクト情報なら相手と要件など、種類フィールドの値に応じた計算式を作る事で、1つのフィールドに種類によって異なる内容を表示させることはそれほど難しくはない。
  • あるテーブルから、種類フィールドを持つテーブルの特定の種類のレコードだけを参照したい場合、画面に表示するだけならポータルフィルタを利用できる(別パターンとしてまとめる予定)。また、リレーションシップ自体が特定の種類のレコードに絞られた状態にしたい場合、種類フィールドを持つテーブルとは違う方のテーブルに定数フィールド(別パターンとしてまとめる予定)を用意し、その定数フィールドと、種類フィールドを持つテーブルの種類フィールドの間にリレーションシップを定義する。

関連パターン:ポータルフィルタ、定数フィールド

フォースについて

パターンにおけるフォースの説明は大変難しいのですが、問題と解決策では記述しきれないことをフォースとしてまとめるというのが1つの方法です。フォースの1つの役割は、パターンを適用したり展開するときの前提条件や、制約条件を記述できる点があります。さらに広い意味では、人間の意思に近いものもフォースと言えるかもしれません。まさに、ある種の力関係、力学的作用、そういうものが働くことによってパターンが成り立つというその状況を記述するための項目になります。

電子書籍が売れないとしたら、その理由は?

電子書籍問題の三部作、最後の記事です。今回は、取り次ぎは金融であるというお話です。出版流通での取次というシステムは、電子出版の注目とともに、より世間に知られることになりました。是非はともかく、これまで何十年の間、出版業界を支えていたのは事実です。

この話は、以前に出版を行う会社に居たときに聞いた話で、今は違っているかもしれませんが、大筋はそのままだと思います。その会社の話だけでなく、複数の会社でそうなっているというのを聞きました。出版社が書籍を出版し、取次に納品し、取次が書店に納品する、そして定価販売を義務づけられているけど、書店は自由に返品でき、それは出版社へも返品できるというのが原則でした。むかし、その原則にコンピュータ系ではおそらくただ1社アスキーだけが「返品不可」をやっていたのも記憶されます。しかし、普通は返品自由なので、書店にとってはリスクが低く、とりあえず注文するという気軽な発注にもつながります。

出版社にとっての出版から返品までのサイクルは、早く半年くらい、長くて1年あるいはそれ以上ということを聞いた事があります。今はもっと早いのかもしれません。このとき、驚くことに、出版時の納品によって、出版社は納品しただけの売り上げが立つらしいのです。そして、返品の度に買い取りになるのか、清算になるのか分かりませんが、取次に対しての支払いと、返品されてきた書籍の引き取りが発生します。つまり、出版直後はほんとうに読者の手に渡っていないのに出版社は売り上げになるという仕組みです。事実上、取次が出版社に対して金融しているのと変わらないという気がしますが、どうでしょう?

従って、出版を始めたばかりの出版社は、出だしがきわめて好調です。全部売れるからです(笑)。しかし、しばらくすると、返品の山で実は売り上げていないことが分かります。そうなると、ともかく、タイトル数を増やして突っ込むことで、売り上げを確保するという悪循環が始まるかもしれません。しかし、返品がどっさりとは言え、私の感覚だと、5〜10冊のうち1冊が大きく売れて、残りが損益分岐点程度なら、出版社は十分黒字になると思っています。全部が損益分岐点では人件費が出ません。ですが、時々ヒットを出すくらいでもうまく回るようです。返品があっても、またじわじわ売れるかもしれないし、ともかく、時々ヒットを打つくらいの感じでなんとか行くのです。

電子書籍は売れないと言われます。電子書籍は、まさに売れた分しかカウントされないので、過去の書籍に比べて売れている感じがしないのかもしれません。しかしながら、実は取次による金融システムによって、紙の書籍は売れているという錯覚に陥っている可能性も否定できません。出版後1ヶ月程度で、売れているかどうかは紙の書籍の場合、なかなか分かりません。最近は書店が減っているので大分分かるのかもしれませんが、一方の電子書籍はまさに生データなのです。出版社としてお金がきちんと(かどうかは問題あるんだけど)入ってくるビジネスに主軸を置くのは当然です。そして、お金の論理で「電子書籍は売れないですから」と言う訳です。

電子書籍の世界に、紙の書籍の取次のような金融的システムはあるでしょうか? 取次の闇の部分だけを引き合いにして邪魔者扱いするのはもうやめましょう。現状はともかく、古い時代に書籍の購入者から業界を含めて、読者の利益とみんなが儲かる仕組みを彼らは構築してきたのだとも言えます。ユーザの論理は重要ですが、業界として成り立つ仕組みがないと、絵空事で終わってしまいます。iPhoneが、Apple独自の流通網App Storeによって成り立ち、そしてそれが成功の一員となったことを改めて思い出し、電子出版にも紙の出版物と同様な業界モデルを本格的に模索をしなければならない時期にあるのではないでしょうか。

電子出版のコンテンツが限られるとすれば、その理由は?

日本でもiBooksが開始されました。けっこう時間がかかったという気がしますが、iPadが出た頃の盛り上がりの期待ほどでもないという点からは、時間がかかってサービスが立ち上がったところで誰も損はしていないのかもしれません。

さて、電子出版と言ったときにいろいろなコンテンツが考えられますが、やはり、既存の書籍や雑誌等の紙媒体と同等なコンテンツというのが1つの大きなジャンルになるのは疑いもない事実です。今回は、従来型書籍の電子化において、どうしてタイトルが増えないのかという点についての1つの見方を書きます。とはいえ、今現在はかなり増えていると思いますが、「元年」と言われて2年くらいはほんとにコンテンツが増えませんでした。もちろん、リーダや販売方法などといった、技術的な問題やインフラの問題もあり、そこは多くの人の興味がそそられるところでしょう。しかしながら、契約の問題はあまり深入りされることもなく過ごされています。

紙の書籍を出版すると、筆者と出版社はいわゆる「出版契約」という契約を結びます。正しくは、執筆前に契約するのですが、まあ、そういう事例はほとんどなく、通常は筆者が書き終わって出版するまでの間に取り交わします。文面に、「原稿をいついつまでに作成し…」などと寒い条項があるのは気にせずに進めます(大笑)。また、契約を結ばなくても、一般的な出版契約が結ばれたとみなされる点についても、かなり以前に裁判があって確定しているというのを聞いた事があります。借地権みたいなルールがあるのです。その契約書は、多くの出版社は、日本書籍出版協会のヒナ型を使っています。出版に興味のある方は、ぜひともこの契約を読んでください。最近では、電子出版に対応したバージョンもあります。

この出版契約で微調整するとしたら、印税などのお金の部分と、日時といった時間的要素だけでしょう。他の部分を調整したことを聞いた事はありません。その結果、出版権という権利が出版社に設定され、出版に関する権利を独占的に有することになります。筆者、つまり著作権者は著作物なのに自分で任意の方法で公開する事は契約上できなくなります。契約上の文言は時代とともに変化していますが、独占的な権利を持つという点はずっと同じです。

以前だと、出版物の流通経路は、出版社から書店に至るものしかなかったので、独占契約をしても、他のルートがあったわけではありません。もっとも、A社よりB社の方がたくさん売ってくれそうだとか、A社の担当者と喧嘩しておざなりにされたので別の出版社に変わりたいと言っても、そう簡単には出版した本の出版社は変更できるものではありません。私の経験でも、版元の会社が解散するので別の会社から改訂版を出すようなこと少しありましたが、これはレアケースでしょう。

結果的に、紙の出版物は、出版社が電子出版化することを決定しない限りは、電子出版として出回らないのです。筆者がどんなに希望しても、出版社の決定がなされないといけません。もっとも、出版社に多大な利益をもたらす筆者の場合はそれなりに意見は通るかもしれませんが、それはごく一部の話です。大多数は関係ないという感じです。出版社も電子出版に乗り気ですが、口を揃えて言うのが「電子出版は売れない」という話です。この話は回を改めますが、安定したビジネスの枠組みから出られない出版社ほど、電子化しないということになるわけです。たぶん、この3年ほどで、出版社を中心とした出版界の枠を出てしまった人は決して少なくはありません。その理由は、電子出版に対して消極的な態度を見せた出版社に対する不満が大きいと思います。契約で権利を保持するのはもちろん必要なことですが、独占権を持ちつつ権利を行使しないというのが、現在限られたコンテンツしか電子書籍になっていない状況を生み出しているのです。

ちなみに、出版権は、一般には書籍を廃版にすると消滅されることになりますが、契約の解除をしないと、いつまでも出版社に権利は残ります。私は何度か解除の依頼を出した事がありますが、交渉とか何もなく、即座に対応してくれました。出版社に取っては廃版となると一切お金にならないものは持っていても仕方ないですもんね。でも、在庫が山積みになっていると、なかなか廃版にはなりません。資産の破棄となり、そこで損失が発生するので、実は、廃版というのは会計的な意味でも大変なことなのです。

契約と言えば、私はいくつかの書籍で、珍しく出版前に契約をしたことがあります。がんばって、決められた日付までに原稿を提出して、そこから出版されたのは半年以上経過していました。契約書では、提出後3ヶ月くらいの期間で出版社は発刊するという文言があったのです。ちょっと釈然としないのですが、紳士的に「どうなってんの?」と問い合わせて返ってきた答えがこれまた絶妙でした。原稿の受け取り日は、出版社が自由に決められると言ってきました。つまり、私が書き終わって提出した日ではなく、出版社がさて編集始めるかと決めた日が「受取日」になるというものです。契約と言ってもいい加減なものです。まあ、この出版社はあまりいい末路でもなかったのですが、こういう経緯があっただけに、申し訳ないですが、同情する気にはなれませんでした。

FMリレーションパターンの作成方針

パターンに要求されるもっとも根本的なことは、問題解決のために利用できることです。ありがちな間違った理解は、技法に名前をつけることと混同していることです。あるいは、「自慢の得意技」を集めたものになってしまったとき、単に技法のカタログにしかなりません。問題解決のために必要な事は、当然ながら「問題点」の抽出と、その問題点の一般化による解決手段の提示が含まれている必要があります。

一方、ちょっと違う見方をすると、どこからが「機能」で、どこからが「パターン」なのかという線引きが分からないということもあります。パターンの世界では、いくつかの要件が組み合わされることの矛盾とそのトレードオフを示すということがパターンに対して要求されるということがよく言われますが、これは1つのヒントです。問題が発生するということは、おそらく要求が単純ではない、つまり、複数の要求があってあちらが立てばこちらが立たずという状況になっているということが言えるわけです。1つの機能でそうした複雑な問題に立ち向かえるかもしれませんが、もし、そうした機能があるとしたら、パターンというよりも、「チョイス」と言えるわけです。FileMakerの世界では、複雑な問題を簡単に解決ことができる「プラグイン」が存在します。では、「プラグイン」はパターンかというと、そうではないと私は思います。単一の機能に帰着するものは、シンプルな、つまり、1対1で事が終わるような問題と解法であり、知っているのかどうか、あるいは挙げられているのかどうかといった、ドキュメントの問題や、記憶しているかどうかといった問題で帰着する訳です。

では、パターンとして論じるものはどんなものがあるのでしょうか。次のような問題があるとしましょう。

最初の問題

顧客管理をしていて、顧客1人が1レコードを確保している(前提)。全社的な情報共有のために、顧客の購買記録と、顧客へのコンタクト記録をデータベースに記録したい(要望)。どのように、ソリューションを作るのが適切か?

FileMakerが得意な人は、もうあれこれ解決策は頭の中を巡るでしょう。もちろん、未確定な要素もあるので、そこはそれぞれです。また、上記の問題は、「問題点」がはっきり分かりません。その上で、まずはこう考えるのではないでしょうか。

  1. 購買記録、コンタクト記録は、別テーブルを用意してリレーションシップを定義する。いずれも、顧客レコードとは1対多の関係になる
  2. 特定の顧客に対してのそれぞれの記録は、顧客のレイアウトに、ポータルをそれぞれ配置すればとりあえずは参照できる
  3. 購買記録は他のテーブルにすでに残している事が判明した(状況の追加)。もともと、顧客とのリレーションシップは存在する
  4. コンタクト記録の入力をする場合、入力しやすいユーザインタフェースを作らないと、利用してもらえないのではないか

みなさんがさらに考えた事があれば、追加してください。ポイントは、ここまでは、FileMakerの単純な機能についての検討をしたということです。4については、いろいろあるかもしれませんが、要はFileMakerの機能の組み合わせということで帰着できるでしょうし、おそらくユーザ分析しないとこれ以上は議論できません。この状況から、パターンを抽出するのはちょっと無理かなと思います。FileMakerを勉強すれば、迷うところはありません。しかし、打ち合わせをしているうちに、どうもこういう問題ではないかと問題が拡張されてきます。

状況が追加された問題

顧客管理をしていて、顧客1人が1レコードを確保している(前提)。全社的な情報共有のために、顧客の購買記録と、顧客へのコンタクト記録をデータベースに記録したい(要望)。ただし、購買記録はすでにテーブルが存在する。一方、コンタクトと購買の関連を知りたいというのはユーザの要望としてでてきた。どのように、ソリューションを作るのが適切か?

ここでのポイントは、まず、「購買記録」テーブルは存在し、そこにおそらく販売担当者がレコードを追加する仕組みがすでに動いているということが想定され、自由に設計できない範囲が出てきました。一方、コンタクトは初出の機能だとしたら、ともかく、自由に作れそうです。

さて、「コンタクトと購買の関連を知る」というのは一種の非機能要求です。関連って何? 知るというのはどういう状況? ここの解決はユーザインタビューなどの要求工学的手法になるでしょう。開発者と顧客で喧々諤々の議論の結果、「購買情報」と「コンタクト情報」を交えたリストを1人の顧客に対して見えるようにするという基調の機能でいいのではないかとなってきました。大分具体的になってきました。

ここで、「購買記録」「コンタクト記録」が別々のテーブルにあるとして、統合的なリストを作りたいということが要求としてクリアになりました。問題点は「複数のテーブルを1つのテーブルのように扱う」ということでかなり抽象的に表現できそうです。ですが、まずは、FileMaker的にどのように解決できるでしょうか、いくつか案を考えてみます。

  1. コンタクトも購買テーブルの1レコードとして記録する。つまり、購買の特別な状況としてコンタクトがある。しかし、そうすると、現在の購買テーブルを利用している別のフォームで、コンタクトを見せないようにしないと行けない場合も出てくる。既存の作成物への変更なく終わらせるのはかなり難しい。
  2. コンタクトテーブルを作るのはもちろん、コンタクトテーブルの1レコードとして購買を記録できるようにする。既存の購買処理には表面的には手を加えなくてもよさそうだが、購買記録を付けたとときに、同時に新しいコンタクトテーブルへのレコード追加も必要となる。スクリプトを加えることで、既存の購買機能はそのままに機能の追加だけでできそうだが、購買機能側に、通販、Webなどなど状況ごとにレイアウトがあったりなんかすると、これは作業としてはコンプリートするのがかなり大変かもしれない。
  3. コンタクトテーブルは作るが、第三の(第4かな?)、「コンタクト&購買」テーブルを作る。まとめリストはそちらから取得する。この場合、前の2と同様、購買処理時に「コンタクト&購買」テーブルを作る必要があると同時に、コンタクトテーブルについても同じように、別のテーブルにレコードが必要になる。

どうでしょう、一長一短ありますね。まさにここでどうトレードオフをするのかが開発者の腕の見せ所でもありますし、それを成功させるために、より詳細に要求を詰めることもあるかもしれません。ただ、4つ目があるんですが、それは実はパターンそのものなので、以下に記述します。

こうした分析をすると、1つのパターンが見えて来ます。ここでは「種類フィールドを持つテーブル」と名付けます。どういうものかをまずはまとめます。

  • 複数の異なる情報を1つにまとめたリストとして表示する必要がある場合に適用可能
  • 新規にテーブルを作成し、テーブルの1つのフィールドにそのテーブルの種類を示す「種類」フィールドを確保する。一般には数値フィールドが良く、何らかの方法で、数値と種類の対応はドキュメント化しておく
  • 種類A、B、Cがあったとき、それらに必要なフィールドを、すべて新規に作ったテーブルに確保しても良い
  • 種類A、Bは新たな項目、一方、種類Cはすでにテーブルで存在する場合、種類Cを記録しているテーブ売るに対する外部キーを、新たに作ったテーブル上に確保する。また、外部キーは種類ごとに用意する

前に示した解決案2と3の折衷案的です。なぜ、3ではないのかというと、3のやり方はオブジェクト指向的な言い方で言えば、抽象クラスに相当するレコードを作る事です。1エンティティに常に2レコードを作るというのは、たとえばポータルなどを含めて、FileMakerではスクリプトを作成する以外に実現のしようがない機能です。そうした仕組みが広範囲に渡りそうなのが解決案3です。ここでは、すでに作ってしまった「購買記録」レコードのメンテナンスのためにスクリプトや改造をがんばって加えるとしても、新たに発生した「コンタクト」情報は素直に作ればいいだろうということで上記のような手法が考えられるということです。

「種類フィールドを持つテーブル」は、さまざまなトレードオフを考える基礎になるということで、パターンであると言えるかと思います。パターンは解決を約束するものではないので、これをベースに考えるということです。この問題で発生した、新たな記録テーブルと、既存の記録テーブルの混在という点についても指針があります。

ここまでがんばって読まれた方だと、容易に分かるかと思いますが、上記のパターンの箇条書きを理解するには、リレーショナルデータベースの基本的なことはみんな知っていないといけません。もちろん当然なのですが、言い換えれば「1対多のリレーションを取る」とか「ポータルに配置する」というのはパターンとは言えないと思います。もっとも、「ポータルフィルタ」は問題解決との関連があるので、パターンの1つと考えています。そこの線引きは難しいですね。一般にパターンカタログでは、パターンだけのカタログになっていますが、これから随時紹介する「FileMakerリレーションパターン」では、前提知識的なものもコンパクトにまとめて行くつもりでもあります。

電子出版がはやらないとしたら、その理由は?

電子出版はそれなりに大きな市場が形成されつつあり、多くの人の注目が集まるところです。2009年頃に、Amazonがすでに電子の売り上げが上回ったという話があって、多くの人があわてたところにiPadが発売されて盛り上がり、そこから約3年、思ったほど、というか、その頃に妄想したほどは盛り上がっていません。その理由の1つが、実は牽引役だと思われているタブレット系デバイスにあるんじゃないかとも思えます。その理由を書いてみました。

電子出版をネガティブに見る人が必ず言うのは、「紙の感覚」とか「ぱらぱらめくれる」といったハードウエア的な側面です。そんなもん、電子出版物のメリットに比べたら取るに足らないというのが電子出版に対してポジティブな人の意見でしょう。ここの対立は分かるのですが、この対立点から連想されるのは、「読書体験」の違いです。大まかに言えば、紙の書籍と電子出版物はコンテンツはまったく同一なので、中身が違うということは基本的にないでしょう。もちろん、ePubだとレイアウトがいまいちなことがあるなど細かい問題はさておきます。同じ内容なのになぜ違うフィーリングになるのかという問題が「読書体験」です。

紙だからここがいいという言い方は、電子出版に対する単なるないものねだりになりますので、言い方を変えてみましょう。電子出版に欠けるものの1つは、書籍の所有感覚の違いではないかと思います。もっとも、人によってそれも違うのですが、多くの人は、昔からずっと使っている書籍があると思います。1年に1回しか見ない書籍も、毎日のように見る書籍も、そして、以前は毎日見たけど、最近は本棚に置きっぱなしという書籍もあれこれあるのですが、それぞれが、同一の厚みを持った紙の固まりとして書棚にあるわけです。見たい書籍は、自分の本棚を探します。もちろん、見当たらない場合もあるでしょう。しかし、けっこうどこに並べておいたかがだいた分かるので、久しぶりに見る本でも、本棚をざーっと見て探し当てます。書籍の背表紙の色だとか、ちょっと高さが高めだったりとか、そういう特徴は意外に覚えているものです。それを手がかりに探したりをしまし。

つまり、電子書籍は、本棚に相当するものが提供できていません。もっとも、これは提供側からすれば、「できている」という感覚だと思います。専用タブレットでも、MacでもWindowsでも、Kindoleだったら見れる。つまり、Kindleが本棚だろうという言い方ができます。iBooksは突っ込みどころ満載ですかね。いずれにしても、各社はそれぞれが本棚を提供しているつもりなんじゃないかと思います。一方、単にコンテンツだけを提供している場合もあります。いずれにしても、リアルな本棚に相当するものが今は提供できていないと言えるでしょう。

なぜか? これは明確です。タブレット各社あるいはサービス提供各社が、囲い込みを解かないからです。そのように見せない工夫は随所にあるものの、本棚のように、世界中のすべての出版物に対応したものがないわけです。各社とももちろん、アピール点はあるのですが、それは提供側の論理であり、消費者側の論理とはマッチしません。私たち読者は、あれこれ工夫をしながら、書籍コンテンツを自分で管理するわけです。しかし、大量になると安直には行きません。iBooksのように、本棚のようなグラフィックスを出しているのはどうでもいい話で、デジタル化されたコンテンツの本棚に相当するものができない限りは、過去の読書体験を上回ることはできないでしょう。言い換えれば、特定のタブレットで完結させようとしているのは各社さん見え見えなんですが、それを遣り過ぎるとそろそろ自分の首を絞め始める時期に来ているのじゃないでしょうかと考えます。

もちろん、各社のタブレットは、電子出版の立ち上がりにおいては、一般の人たちに意味が理解しやすい素材として重要な役割を果たしました。その点は功績は高いでしょう。しかし、従来の読書体験を阻害する要因にもなり始めているとも言えるのです。