19年の年末に無事GCPへのリプレイスが完了しており、次に取り掛かったのがBigQueryにデータウェアハウスを作成するプロジェクトです。この時点でONEのレシートの買取枚数は1000万枚を超えており、PostgresSQLでは購入した商品を検索するクエリに時間がかかりすぎるようになってきました。Airflowを利用して、PostgresSQLをマスターデータとして、毎日の差分をBigQueryに同期するようなジョブを実行しています。

BigQueryの良いところ

これにより、Customer Successチームだけでデータの抽出が完結するようになりました。現在、クライアントの要望に対してエンジニアがSQLを書くことはありません。

また、この時期にONEのレシートのOCRをAPI化して、特定のクライアントに公開しています。ここはGoでAPI Gatewayのサービスを作り、内部用のAPIを利用する形を取っています。これが社内で初めてのGoでのプロジェクトになりました。

GoogleのVision APIの精度はとても高いのですが、やはりOCR特有のミスは発生します。例えば、カタカナの カ は [ガがカ力か] のような正規表現でマッチさせています。これらの正規表現は地道に辞書を作り、ミスを潰しています。正規表現 → OCRミスを考慮した正規表現という変換のため、単純な文字列置換ではなく構文解析をして正しい正規表現に変換できるようにしていたりします。

2019年に行っていたのは以下です。

この時期に行ったのは、商品データの抽出について精度を上げることです。商品名、数量、単価を取得する精度を上げるために、ルールベースで取得のロジックを組みました。具体的には、各データの位置関係やPrefix、Suffixを考慮しています。レシートの画像をひたすら目で見て分類をして、30種類以上のレシートのフォーマットに対応しました。一見すると、機械学習でやっていると見られがちですが、まずはルールベースでよくあるフォーマットを対応することで実現しています。

大きなリリースとしては、Zeroという大型商業施設向けの売上管理のサービスをリリースしました。OCRの技術を活かして、今まで書類作業で行っていた売上報告のフローをアプリで簡単に行えるようなサービスです。

技術的にはいくつもの大変なポイントがありました。まずは、OCRについては、求められている精度がONEのレシートの場合と違うことです。テナントごとに（例えば、ユニクロや無印良品など）売上報告に利用していた精算レシートのフォーマットが違い、取得したい項目名称も違います。1テナントあたり10項目以上の読み取りたい項目があり、それら全てが読み取れて初めて人のチェックがいらない売上報告のデータになります。最初はチーム全員で本当にできるかなという心境で、かなりチャレンジングでした。

そこで行ったこととしては、読み取りたい項目名に加えて、取りたい数字の位置情報も事前に教えておく方法です。前のセクションで説明したOCRミスを考慮した正規表現の拡張も組み合わせています。これにより綺麗な写真であれば、項目の読み取り率は95%ほどになることがわかりました。あとは綺麗な写真を撮ってもらえるような地道なUI/UXの改善を2021年にかけて行なっていくことになります。

ONEで利用しているOCRのマイクロサービスもONEに影響がでないような設計に変更して、チューニングをしています。また、下のようにOCRで読み取りした項目を四則演算をして、最終的な売上報告のデータになることもあり、四則演算が柔軟に組めるようなDSLを自作していたりします。

また、テナントの方向けのカメラアプリをReactで開発しました。ユーザーにとってはアプリのインストールのコストを減らし、開発者にとっては両OSのネイティブアプリを作るよりも開発コストを減らすようにしました。もちろんFlutterなどのクロスプラットフォームの選択肢もありましたが、管理画面もReactで作る予定もあり、プロダクト内で同じ技術を採用することにしました。ただ、サーバーサイドは会社全体としてもGoにしていこうとしており、サーバーサイドはGoで書かれています。

2021年はSwift UIでの新しいプロダクトdim.を作ったり、Zeroの管理画面をリリースしたり、TV放映が増えたことでのリクエスト数の急激な増加に耐える対策などをしていっています。詳しくは別の投稿で書いていこうと思います。