接尾辞の ‘-ship’ は船の意味ではない

会社員向け研修で講師がアカデミックなことをしゃべり出したら、まず真偽を疑った方がいい。

skinship, internshipなどの接尾辞 ‘-ship’ の語源が船のshipなはずがないことは直感的に分かる。まして「船が港Aから港Bへ人を運ぶことから、人と人の間や関係性を意味する接尾辞」というのは完全に誤りだ。

念のため語源辞典で調べてみる。

https://www.etymonline.com/word/-ship

意味は「品質、条件、行為、力量、技能、事務所、地位、~との関係」など。中英語の ‘-schipe’、古英語の ‘-sciepe’ 、アングル語の ‘-scip’ が語源で、これらは「状態、存在の状態」を意味し、ゲルマン祖語では ‘-skepi-‘ とある。インド・ヨーロッパ祖語までさかのぼると ‘(s)kep’ で、「切る、皮をそぐ、たたき切る」などから ‘shape’ 、つまり「形づくる、創造する」の原義を持つらしい。

一方、船の意味の ‘ship’ の語源は古英語で ‘scip’ 、ゲルマン祖語で ‘skipa-‘、いずれも最初から船、ボートの意味で、もともと「切り出された木、中が空洞になった木」。「切る、裂く」の原義があり、接頭辞 ‘schizo-‘ と同じ語源までたどれるとする説もあるようだ。

接尾辞の ‘-ship’ が「形づくる (shape)、創造する (create)」という意味で木を切る、皮をそぐ、たたき切るのに対し、船の ‘ship’ は同じ木の加工でも「切り裂く (split)」方の意味。かつて精神分裂症と訳されていた ‘schizophrenia’ (統合失調症)の接頭辞 ‘schizo-‘ につながるのはうなずける。

https://www.etymonline.com/word/ship

つまり接尾辞の ‘-ship’ と船の ‘ship’ は無関係どころか、ほぼ反対の原義をもつことになる。

接尾辞の ‘-ship’ は何かを創り出す条件や性質のこと、たとえば leadership なら leader を leader たらしめる条件や性質、sportsmanship なら sportsman を sportsman たらしめる条件や性質を意味していると考えると、なるほどと思える。

高校時代にハイデガーを読んで、やたらと言葉の語源にこだわる。そんな会社員が日本にそう多くないことは分かっているし、いちいちそんな会社員がいることを前提に講師が話す必要もないと思う。

ただ、会社員向けの研修を受けていると、講師が無理をしてアカデミックなことを話して墓穴を掘る場面に出くわし、聴いているこちらが気まずくなることがままあり、悲しい。

PHPをWindows 10上のVisual Studio Codeを使って「Webサーバなしで」デバッグする方法

Windows 10でPHPをサーバサイド開発ではなく、VBScriptやPowerShellと同じようにローカルで実行するスクリプトとして使っている。

MicrosoftのVisual Studio Codeを使えばIntellisenseの自動補完でコーディングもできて便利だが、どうすればデバッグでステップ実行ができるのか、ネットで調べ始めた。

とりえあずXdebugというPHPの拡張機能(DLLファイル)が必要なことは分かった。

Xdebug – Debugger and Profiler Tool for PHP

ところが、Xdebugの使い方について、リモートのWebサーバやローカルにApacheかIISで構築したWebサーバでPHPを動かす前提の記事ばかりで参考にならない。

試行錯誤してようやくWebサーバなしでデバッグする方法が分かった。

すでにPHPスクリプトは実行できる状態になっているとする。

(1) XdebugのDLLのダウンロード

上記リンク先からXdebugのDLLファイルをダウンロードし、PHPのインストールフォルダ配下の「ext」フォルダ内に保存する。長いファイル名のままでいい。

ただしダウンロードするDLLファイルのバージョンを間違えないこと。

正しいバージョンをダウンロードするには、Windowsのコマンドラインで「php.exe -i」を実行、出力結果部分だけをコピーし、Xdebugの下記ページに貼り付け、「Analyse my phpinfo() output」ボタンをクリックする。

Xdebug: Support; Tailored Installation Instructions

すると正しいバージョンのダウンロードリンクが自動的に表示される。

(2) php.iniファイルの編集

php.iniファイルの冒頭に以下の内容を追記する。

zend_extension = C:\php\ext\php_xdebug-2.7.2-7.3-vc15-x86_64.dll
xdebug.remote_enable = 1
xdebug.remote_autostart = 1
xdebug.remote_host = 127.0.0.1
xdebug.remote_port = 9000

「zend_extension」の後のDLLファイルのフルパスは、自分がダウンロードしたDLLファイルのフルパスに適宜変更すること。その他はこのままコピペすればよい。

Webサーバなしでなのに、どうしてremote_hostやremote_portの指定が必要なのかと思うが、これらの記述がないとXdebugが動いてくれないので、何も考えずに記述すること。

ここまででXdebugが正しく動くかどうかは、コマンドラインプロンプトで先ほどの「php.exe -i」を再度実行し、以下のメッセージが表示されないことを確認すればよい。

Failed loading C:\php\ext\php_xdebug-2.x.x-x.x-vc15-x86_64.dll

(3) Visual Studio Codeに拡張機能 PHP Debug をインストール

Visual Studio Codeを起動、メニューの「表示>拡張機能」をクリック。

画面左上に「Marketplace で拡張機能を検索する」という入力欄が出てくるので「PHP Debug」と入力。緑色の「インストール」ボタンをクリックする。

ついでに「PHP IntelliSense」がインストールされていなければ、「PHP IntelliSense」と入力。同様に緑色の「インストール」ボタンをクリックしてインストールする。

(4) 編集するPHPファイルのあるフォルダを Visual Studio Codeで開く

筆者はここでつまずいた。PHPファイルを編集するんだから、そのPHPファイルを開けばいいと普通は思う。

しかしXdebugでデバッグするには、PHPファイルのあるフォルダを開く必要がある

Visual Studio Codeを起動したら、メニュー「ファイル>フォルダーを開く…」をクリックする。

そして編集したいPHPファイルのあるフォルダを開いて「フォルダーの選択」ボタンをクリックする。

その後、メニュー「表示>エクスプローラー」をクリックし、左側に選択したフォルダ内のファイル一覧が出てきたらOK。

本来、Visual Studio Codeはフォルダ単位(プロジェクト単位)でPHPをコーディングするもので、PHPファイルを単体でコーディングするものではないので、ファイルではなくフォルダーを開くのが正しい。

(5) 編集したいPHPファイルを開く

左に表示されたフォルダ内のファイル一覧で、編集したいPHPファイルをクリックすると、右側のエディター部分にPHPファイルの中身が表示される。

(6) launch.json ファイルを作成する

このlaunch.jsonファイルをどうやって作成すればいいのかが、どの記事にも書かれていなかった。

メニュー「デバッグ>構成を開く」をクリックすればいい。

すると開いているフォルダ内に「.vscode」というフォルダが自動作成され、その中にlaunch.jsonファイルが自動作成される。

そして自動作成されたlaunch.jsonがエディター画面に自動的に開く。

中身はだいたい以下のようになっているはず。

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen for XDebug",
            "type": "php",
            "request": "launch",
            "port": 9000
        },
        {
            "name": "Launch currently open script",
            "type": "php",
            "request": "launch",
            "program": "${file}",
            "cwd": "${fileDirname}",
            "port": 9000
        }
    ]
}

このうち後半の「Launch currently open script」の設定部分の「”port”: 9000」という行の直下に、次のような行を追加する。

"runtimeExecutable": "c:\\php\\php.exe"

runtimeExecutableというパラメータに、php.exeのフルパスを指定する。フルパスは自分の環境に合わせて正しく指定すること。

さらに、前半の「Listen for XDebug」のパラメータ設定部分をまるごと削除してしまう。

launch.jsonファイルの中身全体は以下のようになる。太字部分が追加した1行。

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch currently open script",
            "type": "php",
            "request": "launch",
            "program": "${file}",
            "cwd": "${fileDirname}",
            "port": 9000
            "runtimeExecutable": "c:\\php\\php.exe"
        }
    ]
}

編集したらメニュー「ファイル>保存」やCtrl + Sで保存し、このJSONファイルのタブは閉じてしまっていい。

(7) デバッグしてみる

以上で準備はととのったので、実際にデバッグしてみる。

何度も書くが、PHPファイルを単体で開くのではなく、あくまでメニュー「ファイル>フォルダを開く…」でフォルダを開くこと。

つまり左側に開いたフォルダ内のファイル一覧を表示できる状態にすること。(左上隅の書類のアイコンをクリックすると表示、非表示を切り替えられる)

そのファイル一覧からデバッグしたいPHPファイルを開く。

そして適当な場所にF9キーでブレークポイントを設定してみる。(行頭に赤丸が付く)

F5キーでデバッグ実行を開始する。(Ctrl + F5だとデバッグなしの単なる実行になる)

するとデバッグ実行の状態になり、F10やF11でステップ実行ができる。

上記で「launch.json」ファイルから「Listen for XDebug」のデバッグ構成部分を削除したのは、この構成ではステップ実行のデバッグができないため。

上記で削除しておいたので使えるデバッグ構成は「Launch currently open script」のみとなり、正しくステップ実行ができる。

ついにWebサーバなしでPHPのデバッグができるようになった。

(8) 他のフォルダにあるPHPファイルをデバッグする場合

ここまででお分かりのように、PHPファイルのあるフォルダ配下に「.vscode」というフォルダと、そのフォルダ内に上記の「launch.json」と同じ内容の「launch.json」ファイルが必要になる。

そのつど上記の手順で作成するのは面倒なので、「.vscode」フォルダごとコピペすればいい。

これでechoやログファイルへの書き出し結果を見ながらデバッグをする手間がなくなり、楽しくPHPをスクリプト言語として使える。

中国式QRコード決済について(6):「中国QRガー」にだまされないために日本の銀行系「~ペイ」を自習

中国のインターネット決済、主にスマートフォン決済の普及率の高さを手放しで称賛する人々を、5ちゃんねるから言葉を借りて「QRガー」と呼んでいるが、もしかすると日本でのモバイル決済の普及のスピードに追従できていないだけかもしれない。

「中国QRガー」の皆さんは日本に無知すぎるのか

筆者もここ数日ネットで調べて知ったのだが、メディア露出の高いLINE Pay、PayPay、楽天ペイに加えて、大手金融機関も続々スマホアプリによるQRコード決済に進出、個人間送金サービスも始めている。

下記のような日本のQRコード展開状況にまったくふれない「中国QRガー」のみなさんは、わざと無視しているのか、単に知らないだけなのかは分からない。

ただ日本におけるQRコード決済で強調したいのは、とにかくいろんなサービスが乱立し、囲い込み戦略をとっていること。

中国はアリババのアリペイ、テンセントのWeChat Payの2社が寡占している。

「中国QRガー」のみなさんはこの2社で中国全土をカバーできることをメリットだと訴求しているが、寡占状態は必ずしもメリットとは言えない。

しかもアリペイが寡占状態なのは、はもともとアリババの「タオバオ」という、楽天のようなネットモールが中国で寡占状態だった背景の流れというだけ。(ネットモールは京東という競合があるが、オンライン決済ではアリペイの寡占をまったく切り崩せていない)

WeChat Payが寡占状態なのは、もともとテンセントのQQというチャットアプリが国民的な普及率を誇るほぼ独占状態といえるアプリで、テンセントがPCメインだったQQをスマホ対応にするのと並行して、ほぼスマホ専用のWeChatへユーザを誘導したというだけ。

中国ではアリババ、テンセントというネット企業がそれぞれEコマース分野、チャットアプリを中心とするオンラインアプリケーション分野でほぼ独占状態にあったから、アリペイ、WeChat Payも寡占状態にあるだけなのだ。

そういう中国の特殊事情がなく、資本主義の正常な競争が行われている日本のQRコード決済業界について、「統一的なQRコード決済が無いのはダメだ!」的な議論は、完全に筋違いと言っていい。

「中国QRガー」のみなさんは、徹底して日本の現状や日本市場の正常な競争状態を、平気で無視するから煙たがられるのだ。

前置きが長くなったが、日本の金融機関のQRコード決済展開として以下のようなものがある。

みずほ系「Jコインペイ」

J-Coin Pay公式サイト

『スマホQR決済「Jコインペイ」、全国50以上の地銀が3月から導入へ』 (iPhone Mania 2019/02/18 13:24)

『銀行スマホ決済「Jコインペイ」で大競争時代に』 (野村総研 2019/02/18)

みずほフィナンシャル・グループが中心になって、50行以上の地方銀行が参加。参加銀行は順次増やしているようだ。

中国のAliPayとも提携し中国観光客にも対応するという、日本でありがちなスマートフォン決済導入パターンである。

このプラットフォームは個人間送金もできる。筆者は個人間送金ができるのはてっきりLINE Payだけだと思っていたが、Jコインペイもできるんじゃないか!

加盟店側手数料は2~5%程度でクレジットカード手数料を下回り、導入費用はスマホやタブレットがあればアプリをインストールするだけなので0円とのこと。

ゆうちょPay

『ゆうちょ銀行、スマホQRコード決済「ゆうちょ Pay」5月開始、口座直結で支払い』 (iPhone Mania 2019/02/07 00:31)

『なぜゆうちょ銀行がスマホ決済に参入するのか? 「ゆうちょPay」の狙いを聞く (1/2)』 (ITMedia Mobile 2019/04/11 06:00)

ゆうちょ銀行はメガバンクと比べると収益性が低いが、その優位性は言うまでもなく顧客との接点の多さ、ATMと店舗数の多さだ。

この「ゆうちょPay」のポイントはGMOペイメントゲートウェイの「銀行Pay」を利用している点だ。

SaaS型銀行間決済「銀行Pay」

GMOペイメントゲートウェイ 銀行Pay公式サイト

『地銀、ゆうちょ銀行が取り組む、銀行Payとは何か?口座連携のQRコード決済のメリット、デメリット』 (Money Lifehack 2018/10/23)

筆者も初耳だったのだが、GMO運営のこのシステムは、ユーザ向け、加盟店向けのスマートフォンアプリと、加盟金融機関の勘定系システムをインターネット経由で連携するSaaS型プラットフォームで、中国のAlipayにも連携、外部連携APIも提供している。

この銀行Payはあくまでプラットフォームであり、じっさいにサービスを提供するのはこのSaaS型サービスを利用する各金融機関となる。

ゆうちょ銀行以前に、りそなグループ、すでに横浜銀行、福岡銀行、熊本銀行、親和銀行、近畿大阪銀行、沖縄銀行、北陸銀行、北海道銀行が参加。

QRコードでの決済方式は、顧客読み取り型、店舗読み取り型、自動精算機型がそろっており、今後は自動精算機で現金の引き出しまで出来てしまうようだ。

Bank Pay (仮)

これが本命のようだが、日本の三大メガバンクが2018/05にQRコード規格の統一で合意していたようだ。

『スマホ決済、3メガ銀がQRコード規格統一で合意 地方銀行に参加促す』 (日経新聞 2018/05/22 20:04)

ただ、みずほは上記の「Jコインペイ」、GMOがSaaS型銀行間決済プラットフォーム「銀行Pay」、ゆうちょは「ゆうちょPay」をすでにサービスインしているので、この「Bank Pay」は本当に実現するのか不安。

膨大なセキュリティ投資

中国のQRコード決済、インターネット決済について、不正アクセスなどサイバー攻撃のリスクが低いのは、中国のインターネットの内部から外部への接続が強力に規制されていることが最大の理由だ。

このインターネット規制は政府が調整できるため、国外から中国内部への逆方向の接続も、通信遅延が増減するなど明らかに規制を受けている。

インターネット全体が中国全体で保護されているおかげで、中国のインターネット決済はサイバー攻撃などのセキュリティ対策にかけるリスクを大幅に抑えられるメリットを享受している。

他方、中国以外の日本を含む、国外とのインターネット接続を規制していない国は、インターネット決済プラットフォームのセキュリティ対策に莫大な投資をする必要がある。

乱立が健全なんです

結論はこれにつきる。

じっさいにLINE PayとメルPayが提携しても、LINE PayとPayPayが提携しそうにないのは、乱立する「~ペイ」がQRコード決済の普及率向上よりも、顧客囲い込みによる自社の利益を優先しているからだ。

これは自由主義の市場ではきわめて正常でまっとうで健全なことである。

かりに日本のQRコード決済が中国のように寡占状態になり、加盟企業に不利益な状況が発生すれば、日本では確実に公正取引委員会が動き出すだろう。

消費者にとって寡占の利便性と、例えば加盟店の手数料が寡占企業によって引き上げられ、価格に転嫁されることによる不利益はもちろん、どちらかを取れば他方を捨てざるを得ない関係にある。

おそらく日本の公正取引委員会は中国のような2社の寡占は許さないのではないか。

「三大メガバンク」や「三大携帯電話会社」の例からすると、全国の消費者に生活基盤にあたるサービスを提供する事業者は、少なくても3社までが許容限度ではないかと思われる。

いずれにせよ自由主義経済の健全な競争を阻害してまで、中国のような寡占状態のQRコード決済の普及を良いことのように称賛する「QRガー」がいたとすれば、遠慮なく非難してよい。

以上、「中国QRガー」のみなさんに騙されないようにするための基礎知識として、自分自身のためにもまとめておいた。

中国式QRコード決済について(5):自ら存在意義を抹殺する中国デジタル社会報告書

「QRガー」に関連して、重大な欠陥のある報告書を見つけてしまった。極めて価値のある内容であるのに、冒頭の第1章で自らその価値を台無しにするという「自殺」報告書だ。

どうして中国テクノロジーを称揚したい方々の先入観はここまで強いのか。

最初に断っておくと、筆者は10年来の中国ガジェット好きである。届いた翌日に電源が入らなくなるクオリティの中華タブレットを数枚購入したことがある。

スマートフォンは、7~8年前、Huawei製でも数時間で交換式バッテリーが切れてしまうような代物だったころから始まり、ZTE製も使ったことがある。最近は劇的にコストパフォーマンスが高くなり、ここ数年、Xiaomi、OnePlus製しか使っていない。

中国SNSはWeiboと百度貼吧を10年以上使っており、WeChat Payも現地ネット決済のために便利に利用している。

したがって中国のIT産業について普通の日本人ほど偏見は持っていないつもりだ。

問題の報告書へのリンクがある、報告書の筆者の方自身のブログ記事を貼っておく。

「報告書『中国14億人の社会実装―「軽いIoT」が創るデジタル社会』が刊行されました。」 (Aseiito.net 2019/04/09)

リンク先にある報告書『中国14億人の社会実装―「軽いIoT」が創るデジタル社会』(伊藤亜聖・高口康太)が、冒頭にあげた重大な欠陥のある報告書である。

(わが母校の東京大学も目先の利益に直結する研究に偏向し、基礎研究の質を軽視し始めたか)

あえて「重大な欠陥」と強い表現をつかった理由は、報告書全体の議論の前提となる導入部分に深刻なミスリードと統計の意図的な読み替えがあり、報告書全体の価値を台無しにしているからだ。

その重大な欠陥はp.27にある。

図表2、横軸に国レベルの一人当たりGDP、縦軸に「過去1年間に携帯電話またはインターネットを通じた金融機関口座にアクセスした人の比率」をとったチャートだ。

この図表2を元にして「先進国のほうがIT技術を利用した金融機関利用が普及してるといえる。おおむねベースラインの傾向としては、デジタルエコノミーも経済発展水準と相関するのである」

何の説明もなくインターネットを通じた金融機関利用が、デジタルエコノミーの決定要因であるとされている。あまりに乱暴な議論だ。

しかも「インターネットを通じた金融機関口座へのアクセス」にはPC、スマートフォンなど、複数の手段があるにもかかわらず、図表2で見事に「モバイルバンキングの普及比率」にすり替えられている。

論文ではない報告書とはいえひどすぎるミスリードだ。

なぜ日本が高いGDPのわりに「過去1年間に携帯電話またはインターネットを通じた金融機関口座にアクセスした人の比率」が低いのか、妥当な原因に本当に思い当たらないのだろうか。

一つは、言うまでもなく日本が異常に現金決済に執着する社会であること。それはこのブログの一つ前の記事を参照頂きたい

かつ、都市部ではATMがあらゆる場所に設置されているからだ。

あらゆる場所にATMを設置できる主な理由は治安が良いからだ。治安が良いということは、治安の悪い国よりも相対的に現金の管理コストを抑える要因にもなっている。

警察庁の平成29年版犯罪白書で、強盗の発生率(人口10万人当たり発生件数)は2014年で米国101.1、英国81.8、フランス177.9、ドイツ56.4に対し、日本は2.4。先進国の中でも異常なほど低い。窃盗の発生率も他の4か国のおおむね5分の1以下だ。

ATMが普及する前も、日本の金融機関の経営は極めて「非効率」で、支店が全国津々浦々あり、現金の出し入れができた。銀行のない地域は郵便局がカバーしていた。

ウィキペディアによれば、1970年代に金融機関がクローズドなネットワークで相互接続され、平日日中の即日送金を実現した日本は世界最先端の金融情報技術を誇っていた。

さらに街角のクレジットカード端末にATM機能が備わり、コンビニエンスストアにもATMが設置された。

コンビニエンスストアの店舗そのものが過当競争になるほど増えたため、ますます現金の出し入れが手軽になっている。通勤・通学のついでにいつでも金融機関のATM相当の現金の取扱ができる。

一方、インターネットを経由したネットバンキングやモバイルバンキングについては、不正アクセスやマルウェアによる被害を防止するため巨額のセキュリティ投資が、ユーザには見えないところで行われており、日々「進化」するサイバー攻撃に対応するコストは年々上昇している。

強盗の発生率が極めて低い日本であっても、電話やインターネットを悪用した物理的接触のない犯罪の発生率は高止まりするだろう。

日本における強盗による現金被害金額は2016年で4.0億円だが、特殊詐欺(いわゆるオレオレ詐欺)の同年の被害金額は406.3億円と100倍にのぼる。

強盗のような「体力」犯ではなく、通信網を利用する「知能」犯は、日本の物理的な治安の良さをやすやすと乗り越えてしまう。

日本でインターネットバンキングやモバイルバンキングの必要性が低いのは、こういったさまざまな社会的・文化的要素が理由になっているのであって、決して日本のデジタル化が遅れているわけではない。

これらの要素をすべて無視して、日本のデジタル化の遅れだけに言及するのは、日本でデジタル化の技術開発に取り組んでいるすべての人々に対する侮辱だ。

この報告書はさらに次の図表3にも「モバイルバンキング」というミスリードを確信犯的に持ち込んでいる。

それどころか最終的に次のように書いている。

「日本のデジタル化を議論する際に度々言及されるのは高齢化による影響であるが、比較的近い高齢化水準にあるスイスやデンマークではデジタル化が進んでいる。日本のデジタル化の遅れを人口構造のせいにできないのである」

高齢化とモバイルバンキングの普及率に相関関係がないという事実は、「高齢化しているからモバイルバンキングの普及率が低い」という因果関係を肯定も否定もしない。

図表2においても同じ誤りを犯している。日本と中国だけに注目するという恣意的なサンプリングを行いつつ、経済発展水準とデジタル化に負の相関関係があるという事実で、「経済発展水準が高いからデジタル化する」という因果関係を否定している。相関関係は因果関係を肯定も否定もしない。

相関関係は因果関係ではない。統計学の基礎さえ理解していない人は統計数値を使わない方が良い。

以上、p.29前半部分まででこの報告書の筆者にデジタル化一般について議論をするだけの正確な認識や客観的な思考能力がないことが明白になった。

これらの箇所に見られる報告書の筆者の無意識の”Japanophobia”は、p.29の後半に思わず漏れ出てしまっている。

「技術的に可能なことが、経済的・社会的な要因によって社会への導入が遅れる現象」

これは明らかに日本を指している。

日本はGDPが高いのにデジタル化が遅れていてダメ、中国はGDPが低いのにデジタル化が進んでいてすごい!という稚拙な論評に陥っている。

意図的かどうかは別として、この長い報告書の冒頭、第1章の段階で日本人の神経を逆なですることに成功している。

中国のモバイル決済賛美者の皆さんはこのようなフォーマルな報告書でさえ、モバイル決済に話をつなげるための強引なミスリードをし、わざわざ日本人の神経を逆なでするような議論の組み立てをする。

だからこそ自分で自分の首を絞めているのだが、そのことを「中国屋」のみなさんはいつになったら自覚し、改められるのだろうか。

じっさいにはこの報告書の残りの部分は非常に参考になる具体的な記述が満載である。

シャオミ大好きで、シャオミのバックパックまで中国から取り寄せて使っている筆者にとって、じっくり楽しみたい非常に充実した報告書になっている。

しかしこの報告書は第1章だけで普通の日本人読者を拒絶している。この冒頭の議論にイラっとする日本人は読まなくて良いと言わんばかりに、報告書の残りの部分の価値を自ら抹殺している。

非常にもったいない。もったいなさすぎる。

中国式QRコード決済について(4):「QRガー」のみなさんには絶望が足りない

ネット上の「中国のQRコード決済すごい!日本でも普及させるべき!」という人々は、日本のQRコード決済利用実態や現金決済主義の現実から目をそむけ、QRコード決済をまだ使っていない人々への訴求力がほぼゼロである点で、完全に空回りしており、見ものとしては面白い。

以下、このような人々を「QRガー」と呼ぶことにする。この名称はすでに5ちゃんねるで使われている

いかに「QRガー」のみなさんの努力が空回りしているか、下記リンク先の日本でのQRコード決済の実態調査で確認してみたい。IT系でおなじみ、MMD研究所のアンケート調査だ。

PayPayユーザは日本のスマホ所有者の約8.6%

「みんなが一番使っているQRコード決済、現時点でのトップはアレ!」 (GIZMODO 2019/02/06)

引用元のMMD研究所の調査はこちら。「2019年2月 QRコード決済サービスの利用に関する調査」 (MMD研究所 2019/02/05)

なお無用な反論を避けるため、このMMD研究所の調査は2019/01/08~01/10だが、PayPayの大規模キャンペーンを反映していることを別の調査で確認しておく。

「『100億円キャンペーン』はどれくらい効果があったのか? PayPayの利用動向を調査会社が発表」 (Forbes Japan 2019/04/09)

引用元のVALUESの調査はこちら。「『100億円あげちゃうキャンペーン』、その後のマーケティング効果を調査」 (VALUES 2019/04/08)

PayPayをふくむ各種決済アプリの月次ユーザ数推移はこちら。「行動ログ」が基準なのでMAUと考えてよい。

2019/02のPayPayのMAUは599万に達している。インストールベースでは2019/02時点で774万ユーザとある。

NTTドコモ系のモバイル社会研究所の調査によれば2018年の日本のスマートフォン所有率は74.3パーセントのため、スマートフォン所有者のうち約8.6パーセントがPayPayユーザとなる。

インストールユーザ数の推移はこちら。やはりPayPayは2018/12のキャンペーンで現在にいたる8割以上のユーザを獲得しており、MMDの調査期間はPayPayの急激な成長を反映していると考えてよい。

ただそのPayPayも、大きなユーザベースにもかかわらず、1日平均の1ユーザ利用回数は3回以下、キャンペーン終了後は他の決済アプリと大差なく1日平均2回前後と、利用頻度は意外に少ないことが分かる。

このように、MMDの調査は2018/12に一気にユーザベースを増やしたPayPayの急成長を反映していることを確認しておいた。

QRコード決済に消極的、無関心なスマホ所有者は8割

ではそのMMDの調査について、「スマートフォン所有者のQRコード決済サービス利用状況」から見てみよう。

先のVALUES、モバイル社会研究所の調査結果をあわせて、スマートフォン利用者のうちPayPay利用者が約8.6パーセントと計算されたので、このアンケート調査結果でPayPayを「現在利用している」割合の数値8.1パーセントは妥当と考えていい。

このチャートの重要な点は、QRコード決済に対して無関心、消極的な日本人の比率が圧倒的であることだ。

無関心、消極的な日本人の比率は、チャートの緑色と黄色を除いた部分、つまり、「利用したことはあるが、現在は利用していない」+「どんなものかわかるが、利用したことはない」+「聞いたことはあるが、内容はよく知らない」+「全く知らない」の合計だ。

これだけネットで簡単に調べものができる中で、「聞いたことはあるが、内容はよく知らない」のは積極的に調べる気がないとしていいだろう。

消極的な比率がもっとも少ないPayPayの回答者でも82.4パーセント。すべてのQRコード決済アプリで約8割のスマートフォン所有者がQRコード決済の利用に消極的、無関心である。

つぎに「QRコード決済サービスを利用する理由」を見てみる。

回答数887人のうち、QRコード決済を利用していると回答した188人に絞られてしまっている。

ポイントに関係する回答が1位、3位。ポイントは運営会社の囲い込み戦略のため、QRコード決済を社会インフラとして普及させることより、自社顧客の囲い込み優先の運営会社の狙いが反映されていると見ていいだろう。

利便性は2位、5位、6位、8位、10位など。ただしいずれもQRコード決済だけの利便性ではなく、Felica式決済にも共通する内容であり、おそらく回答者の多くはFelica式キャッシュレス決済を併用していると思われる。

「QRガー」のみなさんが、よくメリットとして強調する個人間送金は、13位の8.5パーセント。回答数全体の188×8.5%÷887=1.8パーセント。

日本の全スマートフォン所有者のうち2パーセント弱しか個人間送金を理由として挙げていない計算になる。「QRガー」の一部の方々が個人間送金のメリットを訴求している努力は空回りしているようだ。

「クレジットカードで十分」が4割

つぎは「QRコード決済サービスを利用しない理由」。こちらは母数が699人。

複数回答可で、「クレジットカードで十分だから」が43.1パーセント、2位の「現金で十分だから」が23.6パーセント。日本人が決済手段の変更について異常に保守的だと言える。

3位は決済の取引情報はユーザ別、一件別に記録されるキャッシュレス決済特有の懸念と言っていい。

クレジットカードもQRコード決済も大企業が運営しており、信用の点で大きな差はないはずだが、「クレジットカードで十分」とする人が43.1パーセントである一方、QRコード決済については、情報漏えいの不安が21.6パーセントと第3位になってしまう現実がある。

これこそ、信用にもコストがかかり、誰かがそれを負担しなければならないと筆者が言い続けている点だ。

QRコード決済を利用しない人たちは、そのコストを自分は負担したくないので、QRコード決済は使わない、何かあったときに補償があるクレジットカードで十分だと言っていることになる。「QRガー」のみなさんは常に信用にかかるコストを小さく見積もりすぎている。

意外なのは、「街中で使えるお店が少ないから」という比率が非常に小さいことだ。

「QRガー」のみなさんは使える店舗が増えれば、ネットワーク外部性で利用者も増えると考えているが、QRコード決済を利用しない人にとっては、使える店舗が増えたとしても、クレジットカードや現金の十分さをくつがえす要因になりづらいことが分かる。

以上、MMD研究所の調査結果を見てきたが、フツーの日本人の直感にもほぼ合致していると思われる。

「QRガー」のみなさんが本来やるべきこと

「QRガー」のみなさんが本来やるべきことは、日本人のクレジットカード信仰、現金信仰を「脱洗脳」することだ。

しかし「QRガー」のみなさんがいくら自身の議論の客観性や合理性を主張しても、日本社会の現状の中に置かれた途端に、QRコード決済「信者」になってしまい、両社は宗教戦争の様相を呈してしまう。

筆者がこの記事で「QRガー」のみなさんを「QRガー」とあえて蔑称しているのも、ご自身の主観性やイデオロギー性に無自覚な点を指摘したいからだ。

日本人の決済手段の変更にかんする異常な保守性は、合理性ではなく直感的なものであるため、説得方法も非合理的でなければならない。その一例がPayPayの2018/12の第一弾キャンペーンといえる。

しかしQRコード決済事業者がいっせいに同様のキャンペーンを行えば、日本では行政の指導や規制がなされ、事業者がかんたんに折れることは容易に想像できる。最近ではふるさと納税の規制の例があった。

したがって、「QRガー」のみなさんが日本でQRコード決済を共通の社会基盤として普及させるためにできることは少ない。

ご自身がQRコード決済「信者」だという自覚がなく、QRコード決済の長所を訴える方法しかとれないのでは、決済手段の変更にかんする日本人の異常な保守性を変えることはできない。

筆者がQRコード決済について少しでも否定的なことをツイートするやいなや、たちまち「FF外」からの反論が返ってくるくらいなので。

「QRガー」のみなさんには、現実に対する「絶望」が足りない。

もしもあなたがこの記事に反感を抱いたとしたら、あなたにはこの異常な保守性を変え、QRコード決済を日本の社会インフラにする能力が無いことの、何よりの証拠だ。