2021年8月24日（火）から26日（木）までの3日間、日本最大のコンピュータエンターテインメント開発者向けカンファレンス「CEDEC2021」(CEDEC=セデック：Computer  Entertainment Developers Conference 主催：一般社団法人コンピュータエンターテインメント協会、略称CESA)が開催。昨年に引き続き、新型コロナウィルス感染拡大を防止する観点から本年もオンラインで開催された。

　本稿では、8月26日（水）に開催されたセッション「プリントシール機にQRコード決済を導入した話　～エンジニアがプロジェクトを立ち上げてリリースするまでの道のり～」の模様をレポートしていく。

【講演者】

　

　

　

プリントシール機を開発するフリューの業務体制とは

　フリュー株式会社は「人々のこころを豊かで幸せにする良質なエンタテインメントを創出する」という理念の元、プリントシール、コンテンツメディア、キャラクターマーチャンダイジング、ゲーム、アニメなど、幅広いエンタテイメントを事業としている。

　なかでも、プリントシール事業はトップメーカーとして位置しており、台数シェアはナンバーワン。プリントシール機で撮影した写真を取得できる「ピクトリンク」では、有料会員150万人を獲得している。なお、CEDECのような技術イベントでプリントシール事業に関する話をするのは、今回が初めてになるとのこと。

　プリントシール機とは、ゲームセンターに設置されている自動写真撮影機のこと。それぞれの機種に応じて特色と世界観があり、ユーザー間では「プリ」という愛称で親しまれている。

　筐体は、事前ブース、撮影ブース、落書きブース、印刷ブースの4つに分かれている。写真を装飾する落書きブースでは、最近はユーザーごとに識別を行い、好みの映り具合を調整することも可能だ。

　筐体のハードウェアでは、Windows PCにさまざまなデバイスを接続して制御している。一眼レフカメラ、シールプリンターは、USBで接続。各種メカの制御と入力デバイスをCOMで接続。通信機器では、LTE、Ethernetを通じて単体での通信も可能だ。

　プリントシール機は、年間で3機種。加えて、筐体をバージョンアップするキットを年間で3、4タイトルを開発。開発部署は、企画、ハード、ソフトの3つに分かれているが、それぞれが深く関わって開発を進めている。

　田村氏が所属するソフトウェア開発部は、その中でさらに3つの担当に分かれており、ゲーム、落書き、画像処理を担当者が開発を進めている。それぞれの担当部署から、開発機種ごとに1、2名がアサインされ、合計5名前後で1つの機種のソフトウェア開発に取り組んでいる。

　利用技術は、全体でWindows Embeddedを使用しながら、ゲームではC#、Unityを利用。落書きはC++、Unity、画像処理はC++を利用している。現在はUnityへの移行の過渡期なので、過去の資産やエコシステムを活かすためのネイティブプラグインを作りながら移行を進めているとのこと。

　開発環境で特出した部分はないが、Coverityを利用して品質の担保やコードレビューの時間短縮を実施しているそうだ。

　

QRコード決済導入の経緯と支払いまでの流れ

　そして、内容は本題のQRコード決済に関する話題へ移る。今回は、実装と運用、開発プロセスの2項目に分けて説明が行われた。

　QRコード決済には、さまざまな決済ブランドが登場している。その中でも決済方法は、自身のQRコードを表示するタイプ、店舗のQRコードを読み込むタイプの2つに分類される。この違いによって、前者はCPM、後者はMPMと方式が変わってくるそうだ。

　プリントシール機では、MPM決済方式を採用した。MPM方式は、価格情報を動的にQRコードに埋め込むため、支払う側がコードを読み込むだけで店舗が金額の確認をせずに済むというメリットがあるためだ。現在プリントシール機には、LINE PayとPayPayの2種類が実装されている。

　LINE Payを実装したのは2018年。当時は今よりもQRコード決済は普及しておらず、先駆け的な実装となった。LINE Payの開発環境はその時点で整っている状態だったと言う。

　APIの提供やサンドボックス環境など、LINE Payには開発目線でさまざまな利点があったが、中でもテスト用クライアントアプリの不要という点が大きかったそうだ。

　2018年当時はPayPayも登場しておらず、導入検証が行えそうな決済方法はLINE Payのみだったことも大きな要因だ。

　そもそも、なぜQRコード決済をプリントシール機に導入しようと思ったのか。それは、消費税増税まであと1年強というタイミングだったからだ。

　アミューズメント機全体で増税は、インパクトの大きい変化だった。仕様上100円硬貨単位でしか価格設定できず、内税なのでプレイ料金が据え置きの状態ではオペレーターの利益が減ってしまうからだ。

　そこで、QRコード決済を導入することで、1円刻みの設定ができるので増税に合わせた価格設定が可能になり、オペレーターが自由に価格を設定できるという解決策とメリットを生み出したのである。

　加えて、プリントシール機のターゲットである若年ユーザーに対して、支払いでLINEを使用するという点がマッチしていたことが大きい。当時はLINE本体での決済なので、追加のアプリインストールは不要。本人確認も不要でプリペイド利用も可能と、制限の多い学生などを中心に利用を見込めたそうだ。

　PayPayはQRコード決済におけるシェア率を加味しての導入だったとのこと。2021年にはロケテストも実施したという。PayPayを追加導入した結果、LINE PayよりもPayPayの方が高い利用率という傾向が見られた。シチュエーションとしては、カップルで利用する際に男性がPayPayを利用して支払うというシーンが多かったようだ。

　決済の画面下には、キャッシュレスで支払うボタンが用意されている。ボタンを押すとポップアップが表示され、支払う人数を指定できる。続いて決済ブランドを選択し、該当ブランドのQRコードが表示され、それを読み込むことで決済が完了する。

　プリントシール機ならではの実装として、2人でのプレイを意識した実装が行われた。プリントシール機では1回400円の撮影で200円ずつを出し合うという文化があり、QRコード決済でも割り勘を行えるようにした。さまざまなパターンに対応するため、2人がそれぞれ別の決済を利用することも可能にしている。

　片方が決済をした際に、もう片方の残高不足だったという問題が発生することもある。その事態を予測して、支払い画面からボタン1つでキャンセルして前の画面に戻れるような画面設計を行ったとのことだ。

　

さまざまな情報を可視化する管理サイトで決済を効率化

　MPMでは、QRコードを表示させるディスプレイと、決済事業者の決済APIサーバーと通信できるインフラがあれば、QRコード決済を実装可能だ。フリューでは実現にあたり、APIサーバー、管理サイトWebサーバー、データベース、クライアントアプリケーションの4つを開発した。

　フリューでは、ある程度の振舞いの変化をサーバー側で吸収するためにAPIサーバーを新たに立てる選択したという。APIサーバーは、Java Spring Bootで、筐体から呼び出されるAPI群を実装している。

　Javaを選択した理由は、C++、C#に慣れているため、大きな違和感なく設計と実装が行える言語だと考えたからだそうだ。

　管理サイトのWebサーバーでは、筐体の一覧表示、売上の確認ができる管理サイトを作成。このサービスでアカウントを作成してもらい、筐体を登録することでQRコード決済が利用できるようになる。トラブルにより正常決済できない問題が発生した際も、このサイトから返金が可能だ。

　筐体で利用するクライアントアプリ―ケーションは、C#とC++を使い実装しており、ゲーム画面からQRコード決済をしやすくするために作成したモジュールとなっている。ゲーム画面がWPFからUnityへの移行過渡期だったこともあり、両方に対応できる仕様で開発を進めた。

　作成したモジュールは、DDLを2つ、exeが1つ。ゲーム画面から利用するにはC#のDLLを利用し、それ以外からはC++のDLLモジュールを利用する設計だ。DLL側は、呼び出すプロセス空間のメモリー領域になるので、実行モジュールとプロセス間で通信を行い、APIサーバーへアクセスする形を取っている。

　事前に店舗運営者は管理会社から筐体ごとに現金価格とキャッシュレス価格をそれぞれ設定しておく必要がある。筐体は電源が入った起動のタイミングで価格情報を取得する仕組みだ。価格情報をリアルタイムに反映しないのは、ユーザーがプレイするために並んでいた場合に、価格変更の前後のユーザーで金額に違いが出ないようにするためとのこと。

　起動すると操作画面に決済可能なブランドと金額が表示される。この際に、APIサーバーに注文処理のAPI呼び出しを行っている。それを受けたAPIサーバーは、決済事業者のAPI事業者のAPIサーバーに注文依頼を実行する。その後、決済事業者のAPIでURLが返品されてくる。

　そのURLを、今度はAPIサーバーから筐体へ返却。それを筐体でQRコードに変換して表示をしている。もしプレイ中にトラブルエラーが発生した場合は、Webシステムから店舗運営者が返金処理を行える。

　

QRコード決済を導入する際に検討するべき要素とは

　開発時に検討するべきことは、まず前提条件として決済代行を行わないようにすることだ。決済代行はフリューが決済事業者の加盟店となり、決済事業者からの売上を各店舗に分配する方法である。

　しかし、元々QRコード決済が実験的要素もあり、お金の流れを変えるまでの大きなものにしたくはなかったとのこと。この条件をクリアするために、方針としてオペレーターが決済事業者と直接契約して加盟店になってもらうことにした。

　これで、契約やお金の流れはフリューを経由しないようになるが、決済に必要なサーバーはフリューのものを使うという流れになる。

　続いての検討事項は、筐体の管理方法と、通信が不安定な場合の対応だ。筐体の管理は、店舗と加盟店の紐づけを考えなければならない。筐体管理について、前述のWebシステムを構築して行われた。

　そして、加盟店が店舗ではなく企業になることも想定して、企業がトップになり、その下で店舗を管理できるような仕組みを構築。企業アカウントからは、Webシステムにて店舗の一覧の確認・発行・修正・削除が行える。その下には、さらに各筐体との紐づけが必要になるが、そこでどうやって管理システムと連携するのかが課題点となる。

　管理システムから発行する登録コードを入力する仕組みでは、多くの筐体を登録する手間がかかってしまう。そこで、プリントシール機ならではの方法として、メンテナンス画面から筐体の一眼レフカメラを利用してQRコードを読み込む方法を取り入れたそうだ。

　ここで使用するQRコードは、JSON形式でアカウントのIDとランダムな文字列を組み込んだものになっている。ハッシュ値でも代用が可能だ。これを暗号化してQRコードにエンコードしている。

　筐体の置き場所は指定ができないので、ビル群の地下にあるゲームセンターなど、場所によっては通信状況が安定しない場合もある。金銭に関わる部分なので、クレームに繋がらないように細心の注意を払って対応を考えたそうだ。

　対策方法は、QRコードを選択したタイミングで通信ができなければ、筐体側でエラー停止させることなく、コインでのプレイに誘導するというやり方だ。

　しかし、最も問題になるのは、ユーザーがQRコードを読み取った後に通信が切れた場合だ。この場合、サーバーとユーザーのスマートフォンで決済が完結してしまい、筐体で決済状況が取れなくなる。支払いの有無も確認できない。

　そこで、その場合は画面にエラーを表示させて筐体を停止させることに。その後はスタッフオペレーションとして、スタッフがユーザーのスマホの決済情報と筐体のIDを確認するような方式とした。

　検討の結果、筐体の管理方法は自社筐体に特化した管理サイトを構築してサービスを提供すること。通信が不安定な場合は、ワーストケースを想定して、最後には苦肉の策のスタッフオペレーションで解決を行うことで、通信状況の問題には対応できる仕組みを作り上げた。

　管理サイトは決済だけでなく、残りシートの枚数の確認、筐体と決済ごとの売上の確認、値段設定の変更など、あらゆる機能をこのサイトで可能だ。QRコード決済を使っていなくても、店舗はこのサイトは利用できるとのことだ。

　加えて、筐体を遠隔操作できるので、無人店舗には非常に強力なツールとして活躍する可能性を秘めているという。サイトは現在も改良を加えている最中とのこと。

　QRコード決済の実装と運用では、MPMが追加ハードウェアを必要とせず、筐体に追加コストが必要なく、追加コストで実現できるのがメリットとなる。自前で実装することで、割り勘決済など、ユーザーに寄り添った仕様にできる点も大きなメリットになるそうだ。

　

プロジェクトの承認に至るまでとペア開発の効果

　QRコード決済は、エンジニアが提案したボトムアップなプロジェクトだった。田村氏を含め、もう1人のエンジニアと設計、実装、運用検討を行ったとのこと。2人ともエンジニア歴15年以上のベテランコンビでの開発で、他にも社内外からさまざまな人の協力を経てプロジェクトを進めたと言う。

　開発スケジュールは、2018年からゼロベースで調査・開発を開始。2019年にLINE Payの導入を行い、その後PayPayも順次行う予定だったが、コロナ渦の影響で2021年にロケテストというスケジュールになった。結果として、このプロジェクトは少人数かつ短時間で行うことに成功している。

　まずは、開発に至った背景からだ。そもそもの発端は「自分たちの技術で利益を実感できるビジネスを生み出したかった」という想いにある。

　ソフトウェア開発部では「ビジネス感覚を持ったクリエイティブ集団」という指針を掲げており、事業に興味を持つ、自分の仕事が与える影響を説明できる、貪欲に学び続ける、アイデアを発信できる、という4つの意識を念頭に置いてモノづくりに挑むことを重視しているそうだ。

　立ち上げまでの歩みはブレスト、選定、短期間集中実装、プレゼン、承認という流れだ。

　ブレスト、選定では既存事業に近しいものを選ぶことが大切。特に、事業における課題を解決するものがベストだと言う。プリントシール機におけるこのときの課題とは、増税対策であった。他にも、自社の強みを活かせる分野なども選択肢としては問題ないとのことだ。

　次に、1つやることを決めたら短期間でプロトタイプを作り上げていく。作業をスタートさせる方法は、直属の上司を説得して了解を得るか、どこかで時間を作って用意するかの2択になる。

　田村氏は、上司の了解を得て、1週間でサーバーと筐体を使って決済を可能にするプロトタイプを作成したという。その道のりは、何度も壁にぶつかる困難な作業だったそうだ。熱が冷めないうちに、合宿のようにやるなど、何か集中できる環境で行うと効率的に作業を進められるだろうと、経験を元に語った。

　プロトタイプが完成した後は、裁量権をもっている人に数字ベースでプレゼンを行う。ビジネス目線で評価してもらうためにも、数字を出すことは重要な要素なのだ。他にも、課題解決におけるインパクトと、プロトタイプによる実現可能性を見せることも承認のためには欠かせない要素とのこと。

　プロジェクトが発足してからは、MVP（Minimum Viable Product – 顧客が抱える課題を解決できる最低限の状態）と社内レビューの徹底を心がけた。プロジェクト自体のMVPはもちろん、関わる人間の数も小さくして影響を最小限に収めることで、各方面への整合などの手間を無くし、プロジェクトを素早く進行できたとのこと。

　社内レビューを徹底することは、自分たちの活動を公開することに繋がる。会社組織を活用して、その分野に詳しい人に相談することもあった。その甲斐もあり、サーバーの設定やコードレビューなど、事業部を超えた協力を得られたそうだ。

　プロジェクトが成功したポイントをまとめると、事業課題で解決するサービスを考えられたこと。自分たちの技術力で運用までカバーできることを検討したこと。社内組織を活用したこと。この3点が大きく働いたという。

　また、2人組みのペア開発を続けたことも成功の要因の1つだ。ペアで開発を進めることで、互いを補完し合いながら行動できたという。ここでは2つのメリットについて触れられた。

　1つ目のメリットは、開発スピードの速さと品質の担保だ。2人がそれぞれの観点を持ち、影響範囲を検討し、納得して設計と実装を行うので手戻りが発生せずに済む。その結果、高速で機能実装を回すことができた。

　個人で分担すると、1人の担当業務が終了するまでの待ち時間は発生してしまう。ペア開発は常に2人組みで作業することで、その時間を省略することに成功している。

　2つ目は、悩みや課題の共有だ。2人であれば、課題が発生した際に最速で課題の共有が行える。違和感があった際も、原因の究明に素早く移れる。お互いが当事者なので、1人で悩む必要がなくなるという安心感も大きな理由だ。

　結果的に、時間をかけて議論できたり、画期的なアイデアを生み出したりできたと言う。

　他にも、こだわりを持つために残業をしないで、終わらせることが目的にならないようにする。課題への解決策が出たら1日寝かして、翌日に頭をリセットした状態で正しい策なのか見直すなど、2人だからできたプロジェクトとの向き合い方もあったという。

　セミナーは最後のまとめに移る。プロジェクトを立ち上げて進めるにあたり、いろいろなスキルが必要になる。田村氏は、最後に「エンジニアのみなさんは、技術力にもう1つの価値を加えることを意識して欲しい。自信の価値が高まり、よりプロジェクトに貢献できるようになる」と、今回のプロジェクトを通して自ら感じたことを言葉にして、セミナーを終了した。