lasciva blog

開発して得た知見やwebビジネスのストック

「SQL実践入門」を読んだ

SQL実践入門──高速でわかりやすいクエリの書き方 (WEB+DB PRESS plus)

SQL実践入門──高速でわかりやすいクエリの書き方 (WEB+DB PRESS plus)

目的、モチベーション

  • パフォーマンス改善する際に考える材料として、実行計画周りの原理を理解したい

全体の感想

実行計画周りは思ってたより記載されていなかったです。
WINDOW関数などについても言及されており、効率的なSQLを学びたい初心者と中級者の間ぐらいの方にはオススメです。

メモ

効率的なSQLの書き方もたくさん記載されていましたが、あくまでも原理を理解することが今回は目的だったため、割愛してます。

第1章 DBMSアーキテクチャ──この世にただ飯はあるか

1.1 DBMSアーキテクチャ概要

f:id:hacking15dog:20190901150537p:plain Database Management Systemsより

  • クエリ評価エンジン
    • SQLを解釈して実行計画を行う
  • バッファマネージャ
    • メモリ領域の使い方を管理する
  • ディスク容量マネージャ
    • 永続的にデータを保存できるように管理し、読み込みや書き込みを制御する
  • トランザクションマネージャとロックマネージャ
  • リカバリマネージャ
1.2 DBMSとバッファ

I/Oアクセスを避けて、いかにメモリ上で処理を行うかが、パフォーマンス改善においてはキーになる。

1.3 DBMSと実行計画

データへのアクセス方法はどう決まるのか

  1. パーサ(parser)
    • SQL文を要素に分解してDBMSが処理しやすい形式に変換
  2. オプティマイザ(optimizer)
    • インデックス、データの分散や偏り度合い、DBMSの内部パラメータなどの条件から実行計画を作成して、それらのコストを計算して、実行計画を決定する
  3. カタログマネージャ(catalog manager)
    • テーブルやインデックスの統計情報をオプティマイザに提供する
    • 遅延が発生すると適切な計画が練れない一方で更新コストも高いため、適切な設定が重要
  4. プラン評価(plan evaluation)

第3章 SQLにおける条件分岐──文から式へ

3.1 UNIONを使った冗長な表現

UNIONを使うのは、条件分岐という手続き型の発想から脱していないことに原因があることが多い。
SELECT中のCASEで分岐したほうがテーブルのスキャン回数が減るのでパフォーマンスがよい。

3.3 それでもUNIONが必要なのです

CASEによってINDEXスキャンができなくなるときなどは、UNIONを使ったほうがパフォーマンスが良いケースがある。

第6章 結合──結合を制する者はSQLを制す

6.2 結合のアルゴリズムとパフォーマンス

Nested Loops
駆動表とするテーブルを1行ずるループしながら、もう一方の内部表となるテーブルをスキャンして結合条件に合致するものを検索する方法。
アクセスされる行数は、レコード数の積になる。

内部表の結合キーの列にインデックスが存在すると、ループがスキップできるようになりパフォーマンスが改善される。
このとき、内部表が大きい方がスキップされる行数が多くなり、よりパフォーマンスが良くなることが期待できる。

Hash
小さいテーブルからメモリ上でハッシュテーブルをつくり、もう一つの大きいテーブルをスキャンしてハッシュ値が存在するか調べる。
メモリ内に収まらないとTEMP落ちが発生してパフォーマンスが悪化するので注意。

Sort Merge
対象テーブルをソートして、一致する結合キーがあれば結果に含める。
そのため、片方のテーブルのみハッシュテーブルをつくるHashよりもメモリを消費する。 INDEXなどでソートしなくて良い場合には時間とリソースを節約できるため有効だが、基本的には上述の他のアルゴリズムが優先となる。

6.3 結合が遅いなと感じたら

ケース別の最適な結合アルゴリズム

種類 メリット デメリット
Nested Loops
  • 「小さな駆動表」+「内部表のインデックス」の条件下で高速
  • メモリやディスクの消費が少なくOLTPに適している
  • 非等値結合でも使用できる
  • 大規模テーブル同士の結合に不向き
  • 内部表のインデックスが使えなかったり、内部表の選択率が高いと低速
  • Hash
  • 大規模テーブル同士の結合に適している
  • メモリ消費量が多くOLTPに不向き
  • メモリ不足の場合はTEMP落ちが発生する
  • 等値結合のみで使用可能
  • Sort Merge
  • 大規模テーブル同士の結合に適している
  • 非等値結合でも使用できる
  • メモリ消費量が多くOLTPに不向き
  • メモリ不足の場合はTEMP落ちが発生する
  • データがソート済みでなければ効率的でない
  • そもそも実行計画の制御は可能なのか?
    MySQLは結合アルゴリズムがNested Loops系しかない。

    揺れるよ揺れる,実行計画は揺れるよ
    データ量が変更されることで実行計画が変化され、急にパフォーマンスが悪化することがある。
    WINDOW関数や非正規化などで、結合をなるべく避ける。

    第10章 インデックスを使いこなす──秀才の弱点

    10.4 インデックスが使用できない場合どう対処するか

    インデックスオンリースキャンによる対処
    通常ならテーブルのフルスキャンが発生するようなケースにおいても、選択した列を網羅するINDEXを貼ることで、テーブルスキャンを避けることができる手法。

    CREATE INDEX IdAndName ON users (id, name);
    SELECT id, name from users;
    

    次のアクション

    思ったより深ぼれなかったので、SQLパフォーマンス詳解あたりを読んでみようと思います。

    SQL実践入門──高速でわかりやすいクエリの書き方 (WEB+DB PRESS plus)

    SQL実践入門──高速でわかりやすいクエリの書き方 (WEB+DB PRESS plus)

    Rubyスタイルガイドを読んだ

    RoboCopのRubyスタイルガイドからforkされたスタイルガイドを発見しました。

    github.com

    結構前からあるみたいなので、今更感はあります。。

    CookpadやMoneyforward、Airbnbなど色んな企業のコーディングスタイルガイドがありますが、
    それらと比べて、細かくボリュームもありブレもなくなりそうで良さそうに思いました。
    また、宗教戦争が起こりそうなところは、どちらもアリでプロジェクトの中での決めが重要というスタンスなのも良いなと思いました。
    いくつか知らないものもあったので、メモ代わりにまとめます。

    &&=

    ruby-style-guide/README.ja.md at japanese · fortissimo1997/ruby-style-guide · GitHub

    # bad
    if something
      something = something.downcase
    end
    
    # bad
    something = something ? something.downcase : nil
    
    # ok
    something = something.downcase if something
    
    # good
    something = something && something.downcase
    
    # better
    something &&= something.downcase
    

    使ったことなかったですが、somethingのnilチェックがスマートに行えます。

    Array#reverse_each

    ruby-style-guide/README.ja.md at japanese · fortissimo1997/ruby-style-guide · GitHub

    # bad
    array.reverse.each { ... }
    
    # good
    array.reverse_each { ... }
    

    パフォーマンスが良いそうです。

    Exceptionのメッセージ

    ruby-style-guide/README.ja.md at japanese · fortissimo1997/ruby-style-guide · GitHub

    # bad
    raise SomeException.new('message')
    # `raise SomeException.new('message'), backtrace`とする書き方が存在しないことに注意しましょう。
    
    # good
    raise SomeException, 'message'
    # `raise SomeException, 'message', backtrace`の用法と一貫性があります
    

    Kernel#raiseは下記のように2つの呼び方があり、後者に統一しようとのことのようです。

    # [https://docs.ruby-lang.org/ja/2.6.0/method/Kernel/m/raise.html:title]参照
    raise(message) -> ()
    raise(error_type, message = nil, backtrace = caller(0)) -> ()
    

    Hash#values_at

    ruby-style-guide/README.ja.md at japanese · fortissimo1997/ruby-style-guide · GitHub

    # bad
    email = data['email']
    username = data['nickname']
    
    # good
    email, username = data.values_at('email', 'nickname')
    

    Hashから複数の値を取り出す際には、 values_atを使った方がスマートに書けます。

    Object#__send__

    link

    メソッド名の衝突を避けるために、 sendよりも __send__を使った方がよいというルールです。
    例えばEmailクラスで独自のsendメソッドを定義した際に、衝突を回避できます。
    (そもそもあまり send使いたくないですが。)

    DBのACID特性

    DB周りの理解が浅いなと最近感じ、ACID特性も雰囲気でしか理解してなかったので、自分用にまとめました。
    内容を知りたい方は、wikipediaで十分だと思います。

    ACID特性とは

    一言でいうと、DBに求められるトランザクションの要件のことです。

    • A: Atomicity(原子性)
    • C: Consistency(一貫性)
    • I: Isolation(独立性)
    • D: Durability(耐久性)

    それぞれ、説明します。

    Atomicity(原子性)

    トランザクションに含まれるタスクが全て実行されるか、あるいは全く実行されないことを保証する性質です。
    例えば、ECサイトでユーザが購入完了する処理と、店舗の在庫が減る処理が片方だけ発生してしまったら、Atomicityを満たしてないです。

    Consistency(一貫性)

    トランザクション開始時と終了時に制約を満たす性質です。
    例えば、決済だけ行われて与信枠が減らなかったり、銀行の残高がマイナスにはなるとConsistencyを満たしてないです。

    Isolation(独立性)

    トランザクション中に行われる操作の過程が他の操作から隠蔽されるという性質です。
    独立性とパフォーマンスはトレードオフの関係にあります。
    あまりにも独立性を高めようとすると、一つ処理するトランザクションがあるだけで、他のトランザクションは参照できなくなり、パフォーマンスが低下します。
    そのため例えば、MySQLではトランザクションの分離レベルが設定できます。

    MySQL :: MySQL 5.6 リファレンスマニュアル :: MySQL 用語集

    Durability(永続性)

    トランザクションが完了したら、障害が発生したとしても結果は失われないという性質です。
    ディスクに保存されておらずメモリ上で残ってるだけの状態で、ハードウェアに障害が発生した場合に、データが飛んでしまうと永続性がないです。

    「チャイナ・イノベーション データを制する者は世界を制する」を読んだ

    目的、モチベーション

    • 中国のIT企業の歴史を知りたかった
    • 最近は日本でもキャッシュレスが押し進められていて中国企業を参考にしていると思い、そのケーススタディを知りたかった

    全体の感想

    アリババやWeChatの歴史を中心に俯瞰できてよかった。
    海外規制してるから中国は国内の大きなサービスが育ってるという印象を持っていたが、昼夜問わずハードに働いたり、学術研究に投資して優秀な人材を確保したりするなど、成功すべくして成功してるんだなと思った。
    中国政府は規制に対して厳しい印象を持っていたが、緩やかにその事業が世間にどのような影響を与えるか様子を見て、事業者と連携しながら規制しているのも印象的だった。

    キャッシュレスを制するには、オンラインと連動してクーポンを配布したり、ミニプログラムを提供するなどして利便性を確保して、オフラインとの境界を抑えるのが重要なのかなと思った。
    そこで得たデータを元に信用情報を構築して、新たなサービスも提供できる。
    日本でのキャッシュレスキャンペーンは少し不毛だなと思っていたが、それで一大ブームになって定着するという側面もあるので、一面的には判断できないとも思った。

    中国のITの現状や歴史をあまり詳しくなくて、アリババやWeChatを中心に中国のFintech事情を知りたい人にはオススメです。

    目次

    概要のメモ

    序章 米中貿易戦争とチャイナ・イノベーション

    第1章 習近平国家主席とデジタル強国路線

    国策として推し進めてる。 アメリカから制裁を受けたり、若者の就職先がないことの解決策の一つとして、国が起業やイノベーションを支援する。 その中で中小企業が飛躍できるように大手企業がプラットホームとして、機能などを提供することを要請。 その流れで、アリババやテンセントの決済がプラットホームとなり様々なサービスが生まれていくことになる。 技術の中ではAIで世界一になれるように、教育や、優秀な人材が集まる支援を積極的に行われた。

    第2章 なぜ中国でイノベーションが爆発的に生まれているのか?

    モバイル決済がイノベーションの起点

    3G回線のインフラが整ったことや、シャオミやファーウェイなどの格安スマホによって、爆発的にモバイルのユーザ数が増えた。 また、国土が広くATMが日本と比べて便利なレベルでATMがなく、クレジットカードの普及も進んでいない。
    そのやめ、オンラインでの決済ができないユーザが多かったが、アリペイがその解決になった。

    モバイルの移行に伴い、アリペイウォレットを提供開始。急成長の要因は2つある。
    1つ目は、6%を超える利息を受け取れるMMFマネー・マーケット・ファンド)の発売(銀行の普通金利は0.35%)によって収益を生む財布として人気を得たこと。
    2つ目は、独身の日のキャンペーンで、好調だったアリババのネットショッピングのユーザをモバイルへの誘導が功を奏したこと。

    これらのシェアリングエコノミーは、利用者の信用情報の蓄積にも繋がる。
    芝麻信用では、決済履歴や資産運用履歴、行動特性などの情報を分析し、ゴマスコアとして信用情報を数値化している。
    欧米ではプライバシーが重視されてしばしば問題になるが、中国では利便性をもたらしてくれるなら気にしないぐらいの温度感で社会的にも受け入れられている。

    アリペイのおかげで、サービスに必要な本人認証と決済をプラットフォームに任せることで、オフラインの様々なシェアリングエコノミーも普及している。
    オフラインで使えるサービスを提供し、モバイル決済を普及させると共に、利用データや信用情報を蓄積させ、そのビッグデータから新しいサービスを提供していく。

    データ蓄積によって個人の信用を点数化

    アント・フィナンシャルの手掛けるゴマ信用は、取引履歴や支払履歴、行動特性などのデータを分析し、個人の信用力をゴマスコアとして数値化。
    ゴマスコアに応じて少額融資を行い、TmallやTaobao等で買い物する際にも使える。
    従来の中国人民銀行の信用情報サービスでは、銀行のデータから構築したために半分以上の国民は基礎情報しかないのに対して、ネット企業は様々な情報からスコアリングが行える。

    個人情報が企業に利用される形になるが、利用者の殆どは、様々な利便性をもたらしてくれるならあまり気にしないという温度感。

    第3章 阿里巴巴(アリババ)集団と騰訊控股(テンセント)――中国版巨大プラットフォーマーの誕生

    なぜアリババが成功したのか?

    信用情報が未整備で、クレジットカードの保有率の低い中国では決済のコンバージョンが悪く、eBayなどの欧米のスタイルがなじまなかった。
    それに対して、アリババはエスクローサービスを中国で最初に導入した。
    ジャック・マーの「問題が起きれば、僕が刑務所に行く」という強い決心で開発が急ピッチで進んだ。
    いざリリースしても、非銀行であるアリババを不安に思うユーザが多く、不安を払拭するために全額補償のキャンペーンを行った。
    さらに、手数料を無料化してeBayと差別化を図った。

    独身の日のセールの負荷に耐えられるように、Ocean BaseAliyunを自社で開発し、分散型アーキテクチャに移行して対応した。
    これらの技術力を活かし、他社にもアリババクラウドを提供する。

    決済手段から生活サービスのプラットフォームへ

    ダブル11のオフライン版であるダブル12では、スーパーやレストランなどで半額のキャッシュバックキャンペーンを行い、デジタルに疎い50,60代にリーチすることができた。
    決済件数が増えるだけでなく、加盟店はレジ精算時間も大幅に短縮され業務改善にもつながった。

    海外展開は、ローカルの企業に出資などして提携を結んで進めた。

    微信ウィーチャット)発展史

    単なるメッセンジャーから、SNS的な機能を付け加えていき、国内では独占状態になった。
    「テンセントが進出する事業には手を出さない」という暗黙のルールができるほど無双状態になる一方で、独占状態に批判が集まるように。
    そこでオープン化戦略を取ることにし、サービス提供者向けにユーザとつなげるツールを提供。

    • 購買アカウント
      • 情報発信
    • サービスアカウント
      • 会員管理、販促
    • 企業アカウント
      • 内部管理の効率化、関連企業や顧客とのコミュニケーションの円滑化を支援するSaas

    2017年1月には、wechat内で完結しDLも不要なミニプログラムをリリース。

    お年玉をwechatで送れる機能では、ゲーム性を取り込み、テレビの人気番組と連動したキャンペーンを行い、ユーザを引き込んだ。
    晦日の0〜19時の間で、2000万人が4億回のお年玉のやり取りを行った。

    第4章 2強を追う先端技術企業

    滴滴出行(DiDi)――本家も飲み込む生命力

    滴滴出行は最初は投資家やユーザもおらず、運転手の10数名しかいない状態でスタート。
    SNSのクチコミで徐々にユーザ数が増え、優秀なエンジニアを雇って開発を内製にすると、マッチングの効率化等の改善を行い、事業が成長していった。
    wechatで決済できるなどして連携を図っていく一方で、アリババが出資する快的打车も順調にユーザ数を伸ばす。
    キャンペーン合戦となりお互い大きな赤字を掘り、最終的には合併にいたった。

    UBERは中国に進出し、運転手に高い奨励金を出して繋ぎ止めを図る。
    真っ向から勝負となったが、CS対応は電話が一般的な中国でメールで対応するなどローカライズできず、細やかな改善を重ねた滴滴出行がシェアを守った。
    泥沼の赤字の戦いは、投資家主導で休戦することになり、UBER滴滴出行の5.89%の株式を取得することで幕を閉じた。

    フィンテック企業やAIスタートアップの紹介

    第5章 急速に進むデジタル化の負の側面

    頻発する悪質ネット詐欺

    資金を投資家から集めながらも、私的に利用されて資金が回収できなくなった事例等が紹介されていた。

    ICOでも詐欺的な問題が発生し、規制による取締が行われた。

    羊毛党vsネット企業――テクノロジーを悪用した詐欺集団

    セール商品を大量に転売されたり、プロモーションのキャンペーンを不正に受け取るために、架空の取引を発生させるなどの事例が紹介されていた。 犯罪にもAIが応用されて、ツールが販売するなどして不正収入を受け取られてる。

    第6章 中国型イノベーションの本質と先端企業との付き合い方――ユニクロ、メルカリの事例

    ユニクロの中国戦略

    wechatの公式アカウントを広めるために、シェアすればするほど当選確率の上がるキャンペーンを行った。

    独身の日は売上が立つが、流通が追いつかない。 そのため独身の日だけ、オンラインとオフラインでセール価格を統一して、オフラインの店舗で受け取れるようにした。

    「aCrew Vol.1 for FinTech ~メルペイ、Origami、d払い登壇!スマホ決済サービスのグロース特集~」に参加してきた

    repro.doorkeeper.jp

    本編

    講演 ① App Annie 向井氏 「スマホ決済アプリ市場の海外/日本のトレンドについて」(仮)

    参加できなかったので割愛。

    講演 ② Repro 平田「スマホ決済アプリのグロースのポイント」

    参加できなかったので割愛。

    トークセッション「キャッシュレスアプリとデータ活用(仮)」

    登壇者

    モデレーター

    • Repro株式会社 CEO 平田 祐介
    • App Annie Japan(株)日本代表ディレクター 向井 俊介 氏

    パネリスト

    • Fintech協会 代表理事 丸山 弘毅 氏
    • (株)メルペイ 営業統括 兼 社長室長 金 高恩 氏
    • (株)NTTドコモ プラットフォームビジネス推進部 ペイメントビジネス担当課長 高須 真 氏
    • (株)Origami マーケティング責任者 古見幸生 氏 
    各サービス紹介

    d払い

    • docomoのpaypay w
    • 500万DL
    • 使える店舗も増えてる
    • 1600億ポイント/年
    • 2019FY〜
      • ウォレットチャージ機能
      • ミニアプリ
      • 中小店向け 読み取る決済

    www.youtube.com

    Origami

    • ミッション:お金、決済、商いの未来を創造する
    • 2015年でOrigamiPayローンチ
    • 2016年11月:Alipayと提携
    • アプリの機能
      • 支払い前: 使える店舗の情報、キャンペーンなど
      • 支払い後: 支払履歴など
    • 強み
      • 即時割引
      • チャージ不要
      • キャンペーン
      • 地域活性化型キャッシュレス
      • インバウンド/アウトバウンド
      • オープン化(金融プラットフォーム解放)
        • データも他の銀行とかも使えるように

    merpay

    www.youtube.com

    • 信用を創造して、なめらかな社会を創る
    • 他のサービスとは、給料以外のお金の流入源を持ってるのが大きな違い
    トークセッション

    アプリを使ってもらうために、可処分時間やマインドシェアを取るために、意識してること

    • Origami
      • 部分的にメディアのような機能もあるが、本質的にはメディアではない
      • Suica等と比べると、決済をするためにアプリを立ち上げる時点でそもそも遅いので負けてる
      • なので、決済以外のところでも差別化的な意味でメディアとしての機能は部分的に提供してはいる
      • 食べログのように、ユーザの目的を叶えるレベル感のコンテンツは提供できてない
      • 最近はキャンペーンのお店探しという意味ではワークしてる感はあるが、やりたいことではない感
    • merpay
      • 決済は目的ではなく、あくまでも手段
      • 独立とかメディア化は考えてない
      • メルカリ自体が滞在時間長いアプリで、アプリの種類としてはSNSでの行動に近い
    • d払い
      • 長期的にはメディア化を目指す
      • 決済だけだとお得かどうかで選ばれてしまうので、便利な方向性を目指す
      • ミニプログラムの提供等を通して、安心安全な決済基盤の上に他社が乗っかるプラットフォームを目指す

    日本ではアプリ多すぎるが、どうなっていきそうか

    • Fintech協会
      • どこかに収束していく
      • 決済はあくまでも手段なので、入り口が抑えるのが重要
      • 中国でも2強になるまではリアル展開が苦労していたを抑えてから
      • Alipayは2つ大きく流入源がある
        • ECで売ったお金をリアルで使う
        • オフレコ
      • 10ぐらいになるのでは
    • Origami
      • ドンドン増えていくと予想
      • クレジットカードを見てるとドンドン増えてる
      • Origamiはクレジットカードでいうvisaとかになるイメージ
    • merpay
      • ユーザがどう使うかを重視していて、paymentは手段でしかない
      • merpayを全員に使ってもらうというよりは、paymentがシームレスになることが重要
      • 3,5年後アプリでない形になるのもありえるのでは
    • d払い
      • 6個ぐらいでは
      • QRコードが統一されていないので、淘汰されていく
      • 送金とかの決済以外のシーンとかを考えると特にいくつかに絞られていくのでは

    お金ばらまいてるがビジネスモデルは?

    • merpay
      • 信用を創造して
      • 後払いは既にローンチして使われている
      • paymentという文脈でECとか見てると決済は儲からない
      • 価値交換や物々交換とかを考えると、信用に行き着く
      • 信用でマネタイズしていくのが一つ
    • 銀行
      • 現金なくなった方が管理コスト減るので、ATMの設置費用とか減る
      • B2Bとか含めて送金できてるのが差別化になりそう
    • Origami
      • できることとやっていいことは別
      • 個人情報で信用ビジネスになるのは少しアレルギー感
      • 1企業がデータを持つのはGAFA問題みたいになるので、オープンにしていくべきでは
      • LINE@的なポジションを狙いたい
    • d払い
      • 携帯回線7000万人のデータはある
      • オフラインだけの額はそんなに大きくないが、リアルの決済額は大きいので決済手数料0.5%でも事業は成り立つのでは
    • Fintech協会
      • 信用が変わるのは革新的
        • 現在は、勤め先や収入と給与で信用が今決まってる
        • それ以外で決まるのは、大きな革新
      • マネタイズ
      • キャッシュレスが進むとレンディングは伸びる
        • 今はキャッシュレスの割合が2割とかなので、レンディングの額が小さく使われていない
        • キャッシュレス化が進めば、レンディングの額が大きくなっていく
      • 銀行がAPI使って勝つ可能性も

    外国人に向けた何かは考えているか
    外資のサービスが日本に入ってきていて、データが海外に行ってる。
    日本の労働人口もどんどん減っている一方で、海外からくるヒト(観光客、労働者)も増えてる。
    人口と流通額に依存したビジネルモデルだとシュリンクしていくので、インバウンド狙った方が良いのでは

    • d払い
      • 現状は、国内で手一杯
    • Origami
      • 各社が各店舗に営業していくのは厳しいので、連携していく流れになるのでは
    • merpay
      • 法律で守られてるとこもあるが、データの取扱に関しては別
      • 詳しくはここでは話せない
    • Fintech協会
      • エコシステムでデータ保護主義
        • data flow with trust

    8月のQRコード通化は進めれそうか

    • Origami
      • やりきるつもりではいる
    • merpay
      • やるつもりだが、仕様を早く決めてほしいw
    • Fintech協会
      • 協議会が決めていて、今進めているので仕様はもう少し待ってくれ
    • d払い
      • 努力はしてる

    日本は災害大国だが、災害時の対応は想定しているか

    • Fintech協会
      • 今期のテーマ
    • d払い
      • あくまでも通信インフラ優先。将来的には必要
    • Origami
    • merpay
      • キャリアさんお願いします

    Maas

    ETCの普及はしたが、ドライブスルーの支払いはまだ物理だが、車載のアプリ等で解決しないのか

    • Origami
    • merpay
      • インフラ重要
      • 他の国で進んだのは国策なのが大きい
    • d払い
      • ミニプログラムの根本は、利便性を向上したいというところからなので、そこにつながる
      • 今年は提携業者と組んでリリース。来年は順次解放予定