Author: admin

データベースデザインを、ここでは、「リレーショナルデータベースでシステム開発等を行う場合に、データベースのスキーマ、つまりどんなテーブルやフィールドを用意すれば良いのか」と言う問題であると定義します。データベースそのものの設計ではなく、データベースを利用する場合の問題です。RDBで開発をしている人は、どのように設計をすればいいのかと言うことが大変難しい問題であることはよくご存知でしょう。FileMakerを使って「簡単にテーブル定義ができます」となっていても、操作が簡単なことで設計が適切にできるかどうかは定かではありません。単純なシステムならともかく、今時は手元でやっている複雑怪奇でどうしようもない作業があるからコンピュータにさせようと言うのが動機としては一般的です。したがって、目的とするシステムを実現可能なデータ構造も複雑化しがちです。そう言うことで開発をしようというと、ベテラン、エースあるいはアーキテクトなどと呼ばれる専門家などがスキーマ設計を行うことになります。彼らは、多くの事例にこれまで取り扱ったという経験があり、複雑でどうしようもなさそうな要求をうまくシステムが飲み込んでしまうようなスキーマを作ってしまいます。

そうしたスキルを得るにはどうすればいいか？ 経験を積むと言うこともあります。しかし、経験を積んでもそれができない人もいます。理解をするには理由を知ることが重要です。簡単な問題には「なぜ？」に対する答えは言えるのですが、非常に複雑な問題や、要件が怪奇すぎて微妙な問題に対するうまい解決策などをスキーマ設計者が出してきたとき、なぜそうなのかと言うことは設計者もうまく説明できないかもしれません。もちろん、理由があるのですが、知識を知らない人に説明できるかというとなかなか難しいと言うのが実情でしょう。もちろん、そう言う場合に頼りになるという意味では悪くはないとも言えますが、「自分もそうしたスキルをつけたい」と思ったらどうすればいいのでしょうか？

そう言うわけで、いろんな書籍があり、セミナーなどもやっていて、それらで勉強すればなんとかなっているという人もいるでしょうし、やっぱりわからなかったという人もいるでしょう。私も、ある有名なデータベース設計者のセミナーを参加して気づきました。そのかたの示す設計はもちろん、なるほどと思うところもあるのですが、理由を仔細におっしゃらない場面も多々あり、要するに「常識的にはこうなりますね」的な説明で終わってしまう場面もあったからです。その理由を知りたい、理由を知って応用したいと思うのが通常かと思いますが、やはりデータベース設計の世界は、どうもまずは経験を積んだ人の知見が主なナレッジということになってしまうのでしょう。

私自身はその答えはもう持っていて、クローズドなセミナー等で少しはお話ししています。また、そういうコンテンツを持っているのなら、それをビジネス展開してはどうかと思われるところかもしれません。少しはそう思っていたのですが、いろんな状況が重なり、「そうだ、淡々とブログに書こう！」と思った次第です。不定期にこの話題を積み重ねて行こうと思っています。まず、近々は、以前に所属した会社の社内セミナーで話そうとしていた内容を文章にまとめようと思っています。大まかに説明すると、「同じ名前のものが部署によって異なる対象になる」という事例から、それらはテーブルを分離しないと管理できないという話です。ドメイン駆動開発の世界でのユビキタス言語の考え方を、データベース設計のある側面に適用したお話しです。

そういうわけで、データベースデザインについて書くことにしました。

バンクーバー経由でアメリカに入った帰りは、やはりエアカナダだったのですが、サンフランシスコからカルガリーまでUnited Expressで行き、そこで乗り換えるというスケジュールでした。これも、2014年6月の状況ですが、メモとして残しておきます。

往路は先にエアカナダだったのでいろいろな意味でスムーズだったのでしょうけど、復路は先にエアカナダのコードシェア便でスタートです。そうすると、エアカナダの事前のチェックインは、カルガリーと成田間のフライトしかできず、最初にサンフランシスコで乗るフライトは、空港に行かないとチェックインができません。ちなみに、エアカナダはiOSのPassbookですので、紙はまったく使いませんが、その前には昔ながらのチケットを持ってカルガリーまで移動することになります。

まず、出発のサンフランシスコからの便は、ユナイテッドとエアカナダのコードシェア便で、運用はユナイテッドです。エアカナダのカウンターは国際線側にしかないため、この場合は運用しているユナイテッドの、しかも国内線のターミナル3に行って手続きをすることになります。カルガリーはもちろんカナダなのですが、国内線扱いですね。自動チェックイン機で、パスポートをかざせば、問題なく、チェックインがそこでできました。荷物もそこであずけて、成田行きというタグを貼ってもらいます。そして、セキュリティチェックを受けて普通に乗り込みます。23Aという席だったのですが、いちばん後ろの席でした。小さなジェットで約2時間半でカルガリーです。なお、最初に登場するときにバッグを預ければ、そのバッグの扱いがどうなるかを紙でもらえます。飛行機では税関深刻の用紙を記入しておきます。

カルガリーではまず入国審査をします。そこでけっこう並んだので焦ったのですが、幸か不幸かカルガリー発の飛行機も遅れたので、ダッシュしなくて済みました。アメリカからの便だと全員入国審査があり、たままた飛行機が重なったのか、かなりの列ができました。入国にはビザは不要で（乗り換えだけだから）、単にどこから来て、どこに行くのかを言って、滞在時間くらいを言っただけです。アメリカの入国のように、指紋や写真は撮らないのですぐに終わります。その後、ターンテーブルに行って、まず自分の荷物を持ち、関税申告の用紙の回収場所を通り抜けます。そこを出たすぐのところに、エアカナダのカウンタがあって、そこで荷物を再度預けます。単にチケットのチェックをして、ベルトコンベアに載せるだけです。この荷物の移動を自分でやらないといけないということです。

そして、後は飛行機に乗り込みますが、工事中なのか、迷路のように入り組んだところを通貨して乗り場に行きました。そして、カルガリー発の便に乗る時に、入り口の係の人がパスポートチェックをします。Passbookのチケットとパスポートを渡し、検索をして確認すればOKです。iPhoneとパスポートを返されるときも、紙のチケットと同じように、パスポートにiPhoneをはさんで返してくれます。まあいいのですが、習慣って変わらないのですね。カルガリーからの便は半分ほどしか席が埋まってない感じでした。

ちなみに、サンフランシスコ空港まではいつもBARTを使っているのですが、到着時に何も考えずに往復分のチャージをしました。しかし、今回、朝早い便だったのでBARTで行く事ができず、シャトルで移動しました。チャージされたBARTチケットが余ってしまって困っています（苦笑）。

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

ユーザ名やパスワードは、時として「手で入力する」ことを必要とします。もちろん、コピペもあるんですが、手入力を必要にすることで、意図的にセキュリティレベルを高めることもあるかもしれません。そのとき、印刷状況によって、数字の「１」と「小文字の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

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

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

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

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

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

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

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

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

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

要注意キーワード：　みたいな感じ

想定される問題：

• 類似させたい個所と、異なる結果にしたい個所が、正しく伝わらない可能性がある。
• 良かった点、悪かった点が何なのか明確にならない可能性がある。

用例：

1. トップページはアマゾンみたいな感じでお願いします。
2. この前やったプレゼン、プロみたいな感じだったね。
3. 素人みたいな感じのデザインで、どうかな？

キーワードが発生する要因：

• 例を示しつつも、その通りではないということをほのめかしている。
• 的確な表現が見つからない。対象となるものを全体的に評価しているが、詳細な点についての意図や評価基準を持っていない。
• ネガティブな用例においては、湾曲表現、あるいは、意味をやや薄めた言い方であり、受け取り様によってはなんとでも解釈できる言い方をすることで、あつれきや問題視を避けようとしている。

会話でよく使われる「みたいな感じ」は、話のきっかけとして、大枠と方向性を示すには非常に有効である。しかしながら、「○○みたいな感じ」というのが最終的な目標や要望であるとすると、○○の何を継承し、なにを変更するのかという点は不明確なままになる。そのため、この表現が出た場合、具体的なポイントとして、何を意図しているのかを詳細に問いただす必要がある。

＝＝＝＝＝＝＝＝＝＝＝

…とまあ、パターンを考えながら、パターンのパターンを探っている、みたいな感じでw

以下のメッセージは、今年の1/15にFacebookに書き込んだ内容です。パターンの勉強の一貫として、「書いてみる」ということをちょっとやってみているのですが、いろいろな意見をいただきました。これも、記録としてこっちにも書いておきます。

================================

プロジェクト進行や計画ミーティング等でのパターン：

◎擬態音は崩壊の前兆である

• 例1：この部分はささっと終わらせて
• 例2：ボタンを押すと、ポーンと出てくるのがいいね
• 例3：これでバーンと儲かりますよ！

 

決めごとの中に擬態音が混在すると、そのゴールは人に寄って異なる解釈となる場合が多い。つまり、具体的な方針には成り得ないことが多く、後から問題が発生する場合が多い。あるいは、具体的になにをすべきか分かっていない、あるいは検討されていない場合のその場しのぎで発せられる場合もあり、対処すらできない場合もある。

バリエーション1：濁音＞半濁音＞それ以外、の順に不吉な予感は高まる。
バリエーション2：関西弁の擬態音は、ほとんど省略可能として無視できる。

解決策：
擬態音の部分を具体化するか、非機能要件として定義できれば、崩壊を免れることができる。擬態音が発生した段階で、その擬態音を具体的な要件、あるいは形容詞などで置き換えることを試みる。置き換えができないものは、要件ではないと判断し、検討を重ねる。
また、擬態音を省略した場合、意味が通じるかについて判定する。つまり、コミュニュケーションの手段としてより強調したり、印象づけるために使われている擬態音については要件と分離できるため、無視することも可能である。しかしながら、無視できるかどうかについては、さらにコミュニケーションを深める必要がある。