タイトルの通りです！ めっちゃ嬉しかったので、忘れないうちに記録を残しておきます。
概要
先日、UFJさん主催で「Fintech Challenge 2016 Bring Your Own Bank !」が行われました。
詳細は上記ページを見ていただくとして簡単に説明すると、 UFJさんの方で銀行APIを提供してくださるので、それの面白い使い方をみんなで考えようというものです。
ちなみに、提供されたAPIはざっくりこんな感じです。
- 認証API
- 振込API
- 口座情報API
- 支店情報API
- 振込パターンAPI
（他にも、協賛企業からたくさんの3rd party APIの説明を頂きました。詳細は上記ページへ。）
作ったもの
中小企業向けに、小口現金の管理をデジタル化するアプリを作りました。 「Petty Pay」と言います。
チームメンバー
今回は5人＋αでの参加でした。 それぞれの得意分野や担当はこんな感じ。
- リーダー： Mock作成/プレゼン発表/調整
- コンサル： プレゼン原案/設計/UI/iOS（iBeacon）/Demo動画編集
- 長老： 問題提起/プレゼン原案
- デザイナ： デザイン/UI（当日は急遽欠席）
- 助っ人： iOS統括/UI（Dさんの代役でAさんが連れてきてくれた）
- 自分： サーバーサイド/設計/iOS（API連携）
参加決定時の市場調査
まず今回のハッカソンの概要を聞いた僕の感想としては、
「銀行API、これだけじゃ面白いこと出来ない気がする。。 だってクレジットカードや個人間送金システムとかもう既にたくさんあるし。。」
という印象でした。
Suicaやクレジットカード・キャッシュカードすら持ち歩かなくても良い世界になるといいな、くらいの想像はありましたが、そんなの誰でも考えつくし、既にLine PayやMessenger Paymentも出ていたし、ハッカソン期間中にPay with google(Hands Free)なんかもリリースされていました。
参加を決めた当初は、「どうやってこれらより便利なものを作ろうか？」ということを悩んでいました。
問題発見と解決方法の草案
そんな中、長老から「中小企業は未だに小口現金を扱っていて、管理がものすごく面倒である」という問題点を挙げて頂きました。 これが出た時点で6割くらい勝ってたと思います。本当にありがとうございます！
そこから、具体的にどんな点が煩雑なのか、どうすれば解決できそうかを考え、設計を詰めていきました。
大まかに列挙すると、
- 中小企業（に限らないが）は、利用料が高い・管理が面倒などのため社員全員がコーポレートカードを持っているわけではない。
- しかし法人での小口の支払いは多くある（宅配便の代引きなど）ため、現金を会社に置いておく必要がある。
- 他にも、交通費や外出時の突然の出費などで、個人が立て替えて、後で領収書を提出するケースは多い。
- これらは現状の管理方法では、申請が面倒・申告漏れ・不正利用・事後承認が下りず自腹、などの問題が出てくる。
（実際、ハッカソンに参加されていた方に聞いたところ、「溜めていた分をまとめて申請したら、会社のPLに影響するほどの額で怒られた、、」といった生々しい事例を聞いたりしました。）
この問題に対しての僕らは、全てをデジタルで管理することで解決しようという方針で進み始めました。
デジタル化することで、
- 与信管理も細かく設定できる
- 承認や建て替えの手続きもリアルタイムに行える
- わざわざ領収書を提出する必要もなくなる。
- 銀行APIを使えば、クレジットすら必要なくなり、みんなで一つの法人口座を管理できる。
など、みんながハッピーになりそうな気がしていました。
しかし、この時点ではまだまだ詰めが甘かった！
解決方法のブラッシュアップ
当初、管理者が嬉しい点にばかりフォーカスしていて、「全ての決済をQRコード経由でやれば簡単にデジタル化できるよね」となどと話していましたが、
デザイナさんから、 「そんなUIではユーザーは使ってくれない。使ってくれなければやっぱり煩雑な管理は解決できない！」 との指摘を頂きました。この時点で8割くらい勝ったでしょうか笑。本当にありがとうございます！（２回目）
そこで次は、「いかに決済をシンプルに行えるか」を考えることにしました。
僕らが考えた理想のフローとしては、
- 受け取り側が品目と金額を入力する（バーコードなどを読み取るでも可）。
- 受け取り側が支払い側に内容を通知する。
- 支払い側が内容を確認して承諾する。
以上です。現金を使わなければ、Line PayやHands Freeよろしく、3秒もあれば取引完了すると考えました。
Line Payと違うのは、友達同士でなくても決済ができること。Hands freeと違うのは法人の管理者向けのソリューションであることです。
実現方法と設計
次に、どうやったらこれが実現できるかを考えます。 コンサルさんがiBeaconの提案とその仕組みの説明をしてくれました。 実現方法は以下のとおりです。
- 事前にアプリ側で固有のUUIDを設定しておきます。
- 受け取り側が明細を入力したら、サーバーに内容が保存され、その取引にIDが付与されます。
- 受け取り側がそのIDをiBeaconのmajor/minor信号を使ってAdvertise（発信）します。
- 支払い側は、先ほどのUUIDをsubscribeしていて、受け取り側の電波を受信します。
- 支払い側は受け取った取引IDをサーバーに問い合わせて、詳細を知ります。
- 取引内容に問題がなければ承認のアクションを取ります。
- サーバーに承認リクエストが飛び、裏側で銀行APIを用いて振込が完了します。
- サーバーは受け取り側へ、振込が完了したことを通知します。
こうすることで、必要最小限の手間で取引が完了します。
（本筋と逸れますが、承認のアクションは、ネタ感を出すためにボタンタップでなく端末を振って「チャリーン」と音をならす、ということにしました笑）
実装
ここから実装に移ります。 今回は2日しかないので、デモで見せる部分（支払い）に注力しました。 iBeaconなどを使う必要があることから、iOSアプリを作りました。
- iBeaconの発信/受信
- push通知と支払い詳細ページへのジャンプ
- 銀行APIのOAuth認証（APIを叩くのに必要）
- 端末を振った際の音出しと振込APIの実行
- サーバーサイドでの取引完了通知と、iOS側でのそれの受信
- 取引後に残高が減っていることを確認する口座API
ここでは、リーダーが急遽呼んだ助っ人さんがiOSに非常に詳しい方で、色々教えて頂きながら楽しく開発することが出来ました。 彼が居なかったら実装間に合ってなかったと思います。本当にありがとうございます！（３回目）
ちなみに、今回の成果物は以下のGithubリポジトリに置いてあります。 Swift/Scalaと今風の実装になってるかと思います。 （サーバー側は手を抜いたのでロクな処理書いてないけど）
https://github.com/TechResidence/byob2016
成果発表
発表に向けて、リーダーさんは画面デザインを作ってくれ、コンサルさんはDemo用の動画編集をしてくれ、長老はプレゼン原稿を考えてくれました。 おかげで僕と助っ人さんは開発に専念することが出来ました。本当にありがとうございます！（４回目）
デモ動画（Petty Pay導入前/後の違いを表したもの）も良い出来でしたし、リーダーのプレゼンもバッチリでした！ デモが見たい方は個別にお問い合わせ下さい。
まとめ
以上の経緯で、無事優勝することができました。 本当にチームに恵まれて楽しむことができました。
（言わなかったけど）技術的な課題
ちなみに、今回の設計はかなり穴があります。
まずは、iBeaconで固有のUUIDに対してadvertiseすると、アプリを入れている近くに入る人全員が通知を受け取ってしまうこと。 人の分を支払ってくれるお人好しはいないでしょうが、どんな取引をしてるのかがバレてしまうし、何より通知がウザい。 一応、iBeaconの発信/受信範囲を調整することで対応できるとは思ってますが、Bumpみたいな微妙さが残ります。
また、iBeaconのmajor/minorで取引IDを表現すると書きましたが、これらはそれぞれ16ビット分しか表現できません。両方合わせても４Byte分で、とても取引IDを扱うには小さいです。 これについては、新しい近距離通信用のプロトコルを作成しないと難しいのではと思っています。