こんにちは、筑波大学情報学群情報科学類2年の浦川浩介(@azarashi2931)です。LINE広告ネットワークチームで6週間就業型インターンをさせていただきました。

今回はインターン中にぶつかった仕様に関する問題についてお話しします。

背景

私が今回インターンで配属された広告ネットワークチームは、LINEマンガなどのLINEのファミリーアプリやその他のサードパーティアプリへの広告配信基盤を開発・運用する部署です。

広告業界にはデマンドと呼ばれる広告を出稿する業者とサプライと呼ばれる広告をアプリに表示する業者、アドネットワークと呼ばれるこれらの間をつなぐ業者の3者が存在します。アドネットワークはさらに何層かに分けることができ、サプライサイドの業者をまとめるSSP(Supply Side Platform)とデマンドサイドの業者をまとめるDSP(Demand Side Platform)などがあります。LINEの広告ネットワークチームは、このうちSSPに当たるサービスを提供しています。

このチームで開発しているアプリケーションの１つにパブリッシャー向けCMSがあります。ここでいう パブリッシャーとは広告の配信先であるアプリの運営者のことで、先程の区分で言うサプライサイドの業者に当たります。パブリッシャー向けCMSはそのパブリッシャーが広告配信に関する設定や配信の報酬等に関する情報を確認するためのサービスです。 現在はこのパブリッシャー向けCMSのリニューアル作業が進められています。

実際のタスク

私は今回、この新CMSに支払い画面を追加するタスクをアサインされました。 支払い画面とはパブリッシャーの月毎の報酬額を表示するための画面です。支払い情報はデータベースに記録されているので、これをダンプして整形するだけのの簡単な仕事だと私もメンターの方も考えていました。

パブリッシャーに応じて税込・税抜き表示を変更する必要がある

さて、支払い画面にはどうやら金額をできるだけ大きく表示したいという要望があるようです。 そのために、古いCMSでは支払い金額に消費税を上乗せした税込価格を表示していました。 新CMSでも旧CMSとの互換性を取り、金額をなるべく大きく表示するためにも税込で表示する必要がありそうです。

ところで、LINEの広告ネットワークのパブリッシャーの中には海外のパブリッシャーが含まれています。 海外パブリッシャーには日本の消費税は課税されませんが、それぞれの国のなんらかの税が課税される可能性はあります。パブリッシャーの国ごとに税制を調べて国に応じた税務処理を実装するのは非常に困難なので、消費税を税込で表示する対象は日本国内のパブリッシャーに限ることにします。実際、旧CMSでもそのように実装されていました。

ということで、支払い金額を税込で表示すべきパブリッシャーと税抜で表示すべきパブリッシャーの区別が生まれました。

税込・税抜の判定

チームの方に相談したところ、税抜・税込の区別は通貨で行えば良い、とのことでした。 そこでデータベースの上のパブリッシャーに関するデータ構造を見てみると以下の図のようになっていました。パブリッシャーを表すデータを格納するテーブルと支払い先情報を格納するテーブルが存在し、パブリッシャーが支払い先情報を参照するためのIDを保持しています。通貨の情報を持っているのはパブリッシャーではなく支払い先情報の方です。

パブリッシャーと支払い先情報は1:Nの関係になっており、パブリッシャーの通貨を決めたいときどの支払い先の通貨を採用すべきなのかわかりません。仕方がないのでパブリッシャーに対して複数存在する支払い先情報の中の通貨が一致すると仮定して、それをパブリッシャー全体の通貨として扱うよう実装します。これでインターンの最初のタスクは完了です。

他の場所では国ごとに決めている形跡があった

ここで、月締めバッチにも消費税を計算している部分があったのでその実装を見てみました。自分の実装と同じく通貨で税込・税抜を決めていると思っていたのですが、どうやら支払い先に登録された国コードが日本かどうかで税込・税抜を区別しているようでした。国コードとは、支払い先企業の所在地を表現する情報です。この国コードと通貨は違う場合があるので、食い違いが発生すると大元のデータであるバッチで生成された情報とCMSの表示で差が出てしまいます。

他の場所では2

ここで別の実装も出てきました。実は広告ネットワークの中にはパブリッシャーの月の売り上げの速報値を報告するデイリーレポートという機能があり、そこに別の税務処理の実装が存在しています。そこでは支払い先情報の国と通貨の両方を使って判断しているのです。これはどういうことでしょうか？

真の仕様

さて、いよいよ混乱して何もわからない上にチーム内に有識者がいないので営業の方に問い合わせました。すると、税抜・税込の区別は振込先が海外銀行か否かで判定すべき、という回答が返ってきました。 しかしデータベースは支払い先銀行の情報を持っておらず、正確に判定する手段がないので仕方なく国コードや振込通貨を使用して判断していたようです。特に国コードは支払い先銀行の所在地と必ず一致するわけではありませんが、現在のパブリッシャーに関しては一致しているためこれで振り分けて問題ない、と言うわけです。

ではなぜ月締めバッチとデイリーレポートで実装に差があるのでしょうか？実は、ここで使用している国コードは、広告報酬の支払いを実際に行っている（＝正確な情報を持っている）LINEの支払いシステムから広告ネットワークチームのデータベースに手動で入力されたものなのです。そのため国コードが間違っている可能性があります。そこで、デイリーレポートで「消費税分の支払いがあるのにレポートに表示されない」ことを許容して保守的に「国コードが日本」かつ「支払い通貨が日本円」である場合にのみ税込の支払い金額を表示し、一方月締めバッチは海外銀行への支払いが必要なパブリッシャーがまだ少ないことから月締めの際に個別に手動でチェックすることで対処していた、というのが真相のようです。

と言うことで、LINE広告ネットワークのなかでは上の表のような仕様であることがわかりました。支払い画面には月締めバッチのように人間の手が入るタイミングがなく、デイリーレポートのように保守的に表示しても良い場所なので、最終的に支払い画面もデイリーレポートに合わせて実装することになりました。

どうしてこんなことに

どうしてこんなことに…といった感じですが、この背景には広告ネットワークチームの歴史的経緯に要因があります。 実は、この広告ネットワークチームはFIVEという動画広告系のベンチャー企業がLINEに買収・統合されてできたものです。統合作業は短い期間での突貫工事だったため、LINEの支払いシステムと統合しきれていない部分や技術的負債が積もっている部分があります。 その例として、支払い先情報の国コードをLINEの支払いシステムと機械的に同期できていないとか、支払い先銀行の国情報を直接保持できていないといった問題があるのです。 さらに、この統合作業を行った方が既にチームを離れていたことも問題でした。チーム内に有識者がいなかったのはこのためです。

最後に

自分が過去に参加したインターンではある程度仕様が固まった機能の実装を任されることが多かったのですが、今回の曖昧で有識者がチーム内にいない仕様をなんとか発掘する作業は貴重な経験だったと思います。

また技術的な面でも、私が関わった部分で主に使われているScala+Catsは初めて触ったのですが、メンターやチームの方のサポートもあり問題なく仕事を進めることができました。

６週間ありがとうございました。