2013年1月28日月曜日

電子マネーはトマト以下

久しぶりに電子決済について書いてみる。

電子マネーの流動性

電子マネーは、流動性が極端に低く抑えられている。

資金決済法第二十条2に、電子マネーは払戻しをしてはいけないとある。一度買ったらお金に戻せない(売れない)のだ。

これはものすごい規制。およそ自分の持っているもので、売ることができないものなんてほとんどない。臓器とか売春とか猥褻物や偽造通貨…とても悪いものばかりしか思いつかない。

つまり流動性について、電子マネーは、トマトにすら劣るってことだ。(別にトマトと比べる必要はないが)

通貨 > 貴金属 > パチンコの換金用の景品 >> トマト >>>越えられない壁>>> 電子マネー

これが電子「通貨」とか、笑っちゃうね。

なんでこんな規制ができたのか。ちゃんとした経緯を知らないけど、よく問題だと聞くのは、クレジットカードからお金を引き出す手段になる(電子マネーをクレジットカードで買ってそれを現金で払い戻す)こと。あと、RMT に使われやすいとかもあるのかな。まあ、クレジットカードからの現金化は、利用条件で定めて、クレジットカードで買った分は払い戻さないようにシステムを実装すればいいだけなので、あまり理由になる気はしない。

で、実は違う理由だろうなと推測している。あくまで推測。

電子マネーで払戻しができると、電子マネーの流動性が、銀行決済やクレジットカード決済を上回る可能性が高い(と私は見ている)。つまり、

電子マネー > 銀行決済やクレジットカード決済 > 現金 > 貴金属 > …

となってしまう恐れがある。これは、銀行やクレジットカード会社にとっては許しがたい。どんな理由をつけてでも、電子マネーの流動性を抑えたかっただろう。

もうひとつは政府。というか財務省なのかな。財務省はきっと、銀行やクレジットカード会社をコントロールし、日本の経済を動かしている(動かしたい)、と思ってるはず。だから、さらに流動性が高く経済に影響を与える可能性があって、今のところコントロールの手段が見つからない電子マネーの出現を嫌がったのでは。

今のところ、それはうまくいっているようだ。Suica や Edy、ウェブマネーや BitCash が、いくら便利なことがあると言っても、それは限られた場面。日常生活での決済の多くは、依然として銀行、クレジットカード、現金だ。

電子マネーは自分の財産?

自分の財産は自分の所有物なので、原則として好きに売ったりすることができる。基本的人権の財産権(所有権)だ。

電子マネーは自分の財産か。法律で一所懸命に保護してくれているところを見ると、そう扱ってもらっているようだ。が、自由に処分することは禁止されている。

何を守ろうとして? 他者の同じくらい重い権利を守ろうとして(=公共の福祉)、ではなさそうだ。

電子マネーの将来

この一方向関門(現実通貨→電子マネー)が維持されたまま電子マネー側の経済が大きくなるためには、現実通貨の機能がそっくり向こう側にもなくてはいけない。例えば、電子マネーを預かる銀行とか。そうやって経済が成長するには、ものすごい時間がかかるだろう。(それよりも、電子マネーを預かる銀行が現れた瞬間、法律で規制されるほうに私は賭けるが。)

それでいいのかな。たしかにそうすれば、銀行やクレジットカード会社の利権は守られるし、政府は楽ができる。でも、電子マネーに本来あるはずの極めて高い流動性を生かしたマイクロペイメントの市場(主としてコンテンツ市場だと思う)は発展しないと思う。

日本でそのように規制すれば、このネット時代、市場を外国に取られるのは火を見るより明らかだと思うんだが。

軽くて場所を取らず、速く移動できるものが通貨の地位を置き換えてきたことを思うに、国家の通貨(のひとつ)が早晩電子通貨になるのは必定だろう。おかしな足掻きはやめて、ちゃんと将来を考えたほうがいいんじゃないだろうか。

2013年1月20日日曜日

Kindle ストアにもきました

パブーの外部ストア連携機能を使ってアマゾン Kindle ストアにも置いてもらいました。



ランキングをちょっと見てたけど、そこそこ買ってくれている人がいるみたい。ありがたいことです。

パブーのほうはこちら → 「わかる Git」

2013年1月15日火曜日

「サルでもわかるGit入門」がわからないヒトのために

サルでもわかるGit入門」が人気のようです。ツイッターで見ていると、よさそうと言う人とやっぱり分からないという人がいる。私も見てみたが、うん、分からないかもな、と思うところがあった。

そこで、横から失礼ながら、入門編だけちょっと注釈をつけさせてもらうことにします。わからないヒトのお役に立てれば。

履歴を管理するリポジトリ
リポジトリとは、ファイルやディレクトリの状態を記録する場所です。保存された状態は、内容の変更履歴として格納されています。
Git ではひとつのディレクトリ(とそれ以下。あとで出てくるワークツリーのこと。)を管理下に置きます。そのディレクトリの内容のスナップショットがひとつの「状態」としてリポジトリに記録される。その「状態」のつらなりが履歴です。

変更を記録するコミット
コミットを実行すると、リポジトリの内では、前回コミットした時の状態から現在の状態までの差分を記録したコミット(またはリビジョン)と呼ばれるものが作成されます
これは Git の説明としては標準的でないかな…Git ではコミットは差分ではなく、そのときのインデックス(≒ワークツリー)の内容そのもの。コミットを実行する時点でのインデックスの内容が、ひとつのコミットとしてリポジトリに入り、それが(上で書いた)「ひとつの記録された状態」になります。(*1)

(コミットを差分だと理解すると、後で出てくるマージやチェリーピックは分かりやすいんだけど、Git の実装とは離れているので、インデックスやコミットそのものが具体的にイメージしにくくなるのが難しいところ。)

(*1) Git の開発責任者の濱野純氏の著書「入門 Git」2.1節〜2.2節に詳しい。コミットと差分の関係は、p14に以下のように説明されています:
コミットオブジェクトが記録しているツリーオブジェクトは、プロジェクトのコミット時点での状態ですが、このツリーと、1つ前の状態を記録したコミットオブジェクトが記録しているツリーとの間の差分は、このコミットが導入した変更である、と考えることができます。[中略]この差分を計算して、変更点を調査することが可能となるのです。
ワークツリーとインデックス
Gitでは、コミットを実行した時にワークツリーから直接リポジトリ内に状態を記録するのでなく、その間に設けられているインデックスの設定された状態を記録するようになっています。そのため、コミットでファイルの状態を記録するためには、まずインデックスにファイルを登録する必要があります。
「インデックスの設定された状態」ではなく、「インデックス設定された状態」かな。誤植なら直してほしい…

インデックスには、ワークツリーそのままが入れられると思ったほうが分かりやすい。てか Git では実際そうなってる。そしてインデックスの内容が、そのままコミットになる。だから、ファイルを修正しても、インデックスに入れなければ、コミットには入らない。

ファイルやディレクトリが「Git の管理下にある」とは、インデックスに入ってるという意味です。図では CSS ファイルがインデックスに入ってませんが、この例なら入ってるでしょう。そして、html ファイルを修正したからインデックスに入れた、css ファイルは修正していないので以前の状態の css ファイルがインデックスにある、それがコミットされる。

(コミットが差分であると考えるなら、こう理解するといいかも:コミットすると、直前のコミットが表わす状態と、現在のインデックスの内容との差分が、新たにコミットとしてリポジトリに入る。)

以降、リポジトリの共有は概念的な説明なので分かりやすいと思います。変更履歴の統合のところは、ブランチを説明してからじゃないと説明が難しいところをうまく説明しているなぁと感心しました。

これでもまだどうも分からんという人には、拙著「わかる Git」を読んでいただきたいと宣伝するなど (^^;;。有料で、「サルでもわかる Git 入門」よりは長いし、かわいいイラストもないけれど、分かるように丁寧に噛みくだいて説明しているつもりです。上の説明のあたりは試し読みもできますので、気に入ったら是非。