導入
BASEでは、2023年3月頃に「あと払い（Pay ID）」というBNPL（Buy Now Pay Later）のサービス提供を開始しました。BNPLとは、いわゆる後払い決済のことで、今回、BNPLのシステムを一部内製化した上で、世の中にリリースしました。BASEとしては「決済手段を内製化する」ための第一歩であり、ありがたいことに国内の決済業界で、少しばかり話題になりました。
今回は、BNPLという決済システムの開発において、どのような困難があり、どう克服していったのかについて、開発に携わったPay IDチームのエンジニアの視点で書きます。※
なお、このテックブログの読み手として２つのセグメントを想定しています。
- ドメイン知識が複雑なアプリケーションを開発をする人
- 決済システムの仕事に携わる業界の方々
先に結論を書くと、伝えたいことは「ドメイン知識に精通したエンジニアが１人いると、開発スピードが上がるよ」ということです。
ドメイン知識を論点に置いた背景には、大きな時代の流れがあります。
肌感覚として、webシステムの潮流を10年スパンで捉えると、アプリケーションの実装に求められるドメイン知識が、より高度になっていると感じています。特に、2010年代後半以降は、BtoB向けのSaaSが台頭し、結果として開発に求められるドメイン知識が飛躍的に難しくなっているように見えます。このため、実装に携わるエンジニアが複雑なドメインと向き合う話は、今後、徐々に増えていくのかな、とも思っています。
それでは、さっそく、BNPLの開発を紐解き、複雑なドメイン知識との向き合い方を言語化していきます。
※ 執筆者：とあるBackend Engineer
ドメイン知識を蓄積する
開発スピードを早めるために
ドメイン知識と向き合う上で、単に「業務知識を知ろう」という意識だけでは不十分だと思っています。所作としては正しいものの、向かうべき目的が定まっていないため、ゴールが見えない迷宮路を彷徨うことになりかねないからです。
そこで、BNPLの開発にあたっては「コミュニケーションの円滑化」を最終目的に据えました。
業務上のコミュニケーションが円滑化すれば、初期段階の要件定義、中期段階の仕様策定のスピードが早まりますし、思っていた物とは機能が違うという「手戻りの悲劇」を減らすことができます。全ては「開発スピードを早めることに効いてくる」わけです。
この目的設定には、全社的な理由があります。2022年2月の時点で、BASEは上場企業として、プレスリリースを通じて経営方針を発表する中で「BNPLへの参入」を公表していました。すなわち、投資家に向けた約束があり、それは裏切ってはいけないわけです。
[画像]BASE : 2021年12月期 第4四半期決算説明会資料（2022年2月15日公表）
このため、BNPLの開発にあたっても「開発スピード」を早めることは至上命題であり、社内ではリリースターゲットが2023年3月ごろに設定されていました。そして、BNPLのプロジェクトが社内で立ち上がり、実際に私自身が「要件定義」「仕様策定」が関わり始めたのは2022年7月1日のことでした。
すなわち、2022年7月〜2023年3月という「約9ヶ月間」で、BNPLをリリースすることが、必達KPIに設定されたわけです。この期間で決済の内製化を実現するためには、とにかく極限までスピードを速めることが至上命題となりました。
- 2022年2月 ：BNPLへの参入を公表
- 2022年7月 ：BNPLのプロジェクトが本格立ち上がり
- 2023年3月頃：リリースのターゲット目標
つまり、ドメイン知識を獲得して、コミュニケーションを円滑化し、実装スピードを最速化することは、「あったらいいな」ということではなく「何がなんでも、絶対にやらなければならない」ことだったのです。
ドメイン知識をキャッチアップする
私自身は、2022年7月ごろに、BNPLの開発に参画することが決まり、すぐさまドメイン知識のキャッチアップを行いました。
少し調べていくと、BNPLという言葉は流行語的な側面もあり、その本質的な実態は「後払い」に分類されることが見えてきました。そこで、後払いに関するドメイン知識をキャッチアップすべく、下記3つの観点からインプットを行いました。
- 後払いの会計知識
- 後払いの法律知識
- 後払いの業界知識
とはいえ、あまり時間をかけることもできないので、BNPLの開発に参画して、最初の約1ヶ月で集中的にドメイン知識のキャッチアップを行なっています。この間も、PMやデザイナーと一緒に、要件定義・仕様策定を並行で行っており「実装の手を動かさずに考えること」「コミュニケーションをとって要件と仕様を固めること」「ドキュメントを書くこと」が、最初の1〜2ヶ月の仕事の全てでした。
会計知識について
BNPLは「サイクルの長いお金の流れを生み出す」プロダクトであるがゆえに、その前提として、深いお金の知識が必要になります。
単純に「売上が上がった」「利益が出た」「成長率が〜％」という話ではなく、PL（損益計算書）・BS（貸借対照表）・CF（キャッシュフロー計算書）に、それぞれどのような影響を与えるかを、BNPLが提供する各機能ごとに認識する必要があります。
加えて、BASE社内だけではなく、商品を購入したお客様、BNPLの提携パートナー企業様、商品を販売するショップオーナー様に、それぞれ、どのようなお金の流れが発生するのかを理解すると、ここで初めて「お金の流れ」を腹落ちすることになります。（これらの利害関係者様の仕訳も空論で想定しつつ、流れを理解していきます）
すると、BNPLに関わるお金の流れが見えてきて、そのワンサイクルがとてつもなく「息の長い」ものであることが見えてくるわけです。
すなわち、簿記や仕訳といった会計の基礎を理解しつつ、BNPLが、利害関係者様の財務状態にどのような影響を与えるかという理解に努めました。
持論ですが、BNPLは、究極的にBS（貸借対照表）が大事なプロダクトであり、PLだけを見て満足してはいけないと思っています。取引で発生した債権（債務）の最終着地点と、それがもたらす意味について、よく考えなければならないからです。ここまで咀嚼できれば、利害関係者様が何を求めているかがわかるため、コミュニケーションが円滑化してきます。
なお、これは極論なのですが、勘定科目の金額を見ると、その背景にある人や、関係者の想いが見え透くこともあるので、ごく稀に勘定科目に感情移入して想いを馳せることがあります。BNPLに関連する勘定科目は、特に、さまざまな人間ドラマを抱えた科目です。
勘定科目に感情移入できるほどに解像度が高くなれば、会計のドメイン知識としては十分だと思っています。
法律知識について
システム開発と法律というのは、非常に遠い存在であるように見えますが、今後はより一層、非常に密接な関係になってくると予想しています。法律というのは、問題が顕在化し、世論の事情によって、事後的に「制定」されたり「緩和」されたりする制度であり、静的ではなく、動的な存在です。したがって、webシステムが社会に与える影響が大きくなればなるほど、法律が制定されたり、改正されるのは、自然な流れです。
加えて、BNPLは「金融」というジャンルで取り扱われるプロダクトであり、業界ごとの特別法を守る必要があります。
法律の専門家ではないので、詳細な言及は避けますが、一般的な金融・決済領域に絞ってみても、信用販売であれば「割賦販売法（1961年施行）」、前払いであれば「資金決済法（2010年施行）」、お金の貸し借りでは「貸金業法（1983年施行）」や「出資法（1954年制定）」といった具合に、行きすぎた行為を抑止するために、先人の知恵としての法律が存在しています。
そして、改正貸金業法（2006年可決）のように、法律改正によって、業界の趨勢（引当金計上による財務状態の悪化など）に大きな影響を与えることもあります。
つまり、BNPLという「金融プロダクト」を開発するにあたって、法律は避けて通れない道であり、要件定義に強い影響を与えるので、よく理解する必要があると考えています。
業界知識について
BNPLは単なる流行語に過ぎず、その実態は後払いです。商品を決済した後に、支払いを行うという商行為であり、本質的には、ただそれだけのことです。BNPLという言葉に、意味はありません。
にもかかわらず、不思議なことに、この「後払い」という業界では「月賦」「信用販売」「クレジットカード」「後払い」「BNPL」といった具合に、さまざまな呼称が乱立しています。加えて、それぞれの呼称ごとに、業界のトッププレーヤーが個別に存在しており、全てを兼ね備えるような超大企業が存在しません。考えてみれば摩訶不思議なことです。
この不思議さに隠された論点があるような気がしたため、『CardWave（1987年12月創刊）』などの業界雑誌でインプットを図りました。ここでは、最新の雑誌ではなく、その業界雑誌の「創刊号」や、新しい決済手段が出た時の「特集号」を中心に読破していきます。当時の批判、問題点、仮説を検討することで、現在に至るまで、それが解決されたのか、残存したままなのかを検討し、本質的な課題を探っていきます。
そして、後払いという業界の成り立ちを踏まえつつ、各領域のトッププレーヤーが入れ替わってきた変遷と、その要因を、マクロでは経済性（および規制）の観点から、ミクロでは競争優位性の観点から検討し、その一部を、約1万字の社内ドキュメントとしてまとめました。この辺りの話は、特定の本に書かれているわけではないのですが、公開情報を調べれば（業界各社の有価証券報告書を注釈含めて全ページ読むなど）、いろいろなことがわかります。
また、業界内では競争優位性があるとされる「ある機能（ここはセンシティブなので、ぼかしておきます）」が、実は、ほとんど効いてこないのではといった仮説も提唱してみたりと、事業の勘所が何かを日々考えています。
このように、業界知識を通じて、いろいろな仮説をフラグとして立てておくと、事業を執行する人とのコミュニケーションが円滑になると思っています。エンジニアとしても、BNPLという機能価値において、どうやって（技術的に）競争優位性に貢献するのかを考える良いきっかけになりました。
注意すべきは、業界知識というのは、単に「業界の常識」を知るということではないことです。
あくまで、事業における論点、すなわち「競争優位性を決定づけるものは何だったのか？」という論点を探ることに注意を向けています。キーファクターを探り当てて、そこに貴重なリソースを集中すべきと考えているからです。
ドメイン知識の使い所
ここまで「ドメイン知識とは何か」を見てきました。それでは、ドメイン知識があることによって、どのように開発スピードに効いたのでしょうか？
BNPLの開発事例をもとに、3つのフェーズに分けて、明らかにしていきます。
- 要件定義・仕様策定
- 開発チーム組成・詳細設計・実装
- QA・リリース
要件定義・仕様策定
要件の変更を提案する
１つ目のメリットは「要件定義を変更できる」ことです。
BNPLでは、要件定義を開始した直後の2022年8月頃に「発送時におけるショップ様への入金」における要件で、開発の視点から、要件の変更を提案しました。これは何かといえば、従前の要件が「商品の発送後、着荷をもってショップ様が売上金を引き出せること」であったのに対して、「商品の発送を持って、ショップ様が売上金を引き出せる」という代案を提言することにしたのです。
この要件のメリットを一言で言えば「ショップ様のキャッシュフローの改善」です。商品を発送してから着荷には数日かかるのが一般的であることを考えると、発送段階で売上入金ができることは、キャッシュフローにおける入金サイクルを数日早めることを意味します。
もう一つの隠れたメリットは、システム面における複雑性の解消です。発送時点ではなく、着荷時点にイベントを発生させた場合、新たにバッチ処理などの実装が必要になるため、実装の工数が増大します。加えて着荷を考慮すると、キャンセルにかかる処理がかなり複雑になってきます。「発送後〜着荷前におけるキャンセル処理」を考慮して実装を行うと、それなりの工数増大が予想されますし、実装の量が増えれば「バグ」の潜在的なリスクも高まります。
したがって、エンジニアの視点で「メリット・デメリット」をまとめ、会計のドメイン知識を前提に、要件を変更することを提案しました。
そしてPMを通じ、最後は執行役員の判断で要件変更が決まり、このときは、かなり嬉しかったことを覚えています。「着荷」というヘビーな要件の重しが取れたことで、BNPL全体の実装はシンプルになり、リリースへの手応えを感じることができたからです。
要件の優先度を決める
２つ目のメリットは、「優先度を考慮したリスクヘッジ」です。
BNPLでは当初、実装予定だった「A」という重たい機能があり、最初のリリースにおける要件に含まれていました。
しかし、要件定義と仕様策定を進めていき、2022年9月初旬に実装の詳細設計に入った段階で「どうもこれは、かなり重くなりそうな機能」という香りが漂ってきました。この段階で、そのまま実装に入る選択肢としてありましたが、不確実性が高いと判断し、この機能「A」については、実装を遅らせることをPM に相談したのです。
このとき、ドメイン知識があったため、この機能「A」については、BNPLのファーストリリースに存在しなくても成立し得るということを理解できており、これをもとに説得のロジックを組み立てて相談しました。
「・・・と考えたんですが、これって、どうですかね？」
結果としては、この機能については、リリースを遅らせる社内合意を得ました。この動きによって、現実的な開発のスケジュールを立てることができ、不確実性がかなり軽減したのです。BNPLの期日内リリースという動きの中で、間違いなく、一つの大きなブレイクスルーでした。
要件を所与のものと考えるのではなく、機能が実現したいことに対して、事業全体として「MUST・WANT」なのかを切り分けることができていたからこそ、リスクヘッジが実現したと思っています。
議論して仕様を素早く決める
３つ目のメリットは「スピーディーな仕様策定」です。
BNPLでは、要件に基づいて仕様を考える際に、デザイナー、PM、エンジニアが一体となって具体的な方向性を決めていきました。ユーザー様にとっての「メリット・デメリット」、開発面における「不確実性の高さ」を考慮しつつ、最終的な仕様に落とし込む議論をするわけですが、ここでのコミュニケーションのスピードはかなり早かったと感じています。イメージとしては、1回60分のMTGで、1画面の仕様を大方、決めていくような速度感です。
BNPLの開発における仕様面の複雑さの例をあげると、その一つは、購入者様におけるステータスの多さに起因しています。購入から実際にお支払いをするまでのスパンが月をまたぐほど長く、加えて、その間のステータス（請求完了やお支払い済みなど）も目まぐるしく変化することから、あらゆる決済手段の中でも、そのステータスの種別は群を抜いて多い部類に入ります。だからこそ、細かい仕様をスピーディーに決めることによる生産性は高く、前提としてのドメイン知識が活きることころです。
また、仕様策定の段階では、社内はもちろん、社外とも連携するため、提携パートナー様とも頻繁な打ち合わせを行なっています。ここでも、その場、その場でAPIなどの仕様を決めていくため、スピードを出すうえで、ドメイン知識が活きた形になりました。何らかの要望を受けた場合は、心の中に手を当てて、5秒で概算見積もりを出し（自分で実装する前提で出します）、ドメイン知識を前提として、落とし所を探っていきます。
他にも、仕様が固まる段階で、経理チームとの連携が取れた点でも、スピードを発揮しました。会計知識をベースにして、BASEの財務に影響がある実装箇所を共有し、早めのレビューで合意が取れたことで、手戻りリスクを最小化できたかなと思います。
このように、実装の着手前の段階から、ドメイン知識はコミュニケーションを促進しました。実装前の段階で「いかに不確実性を最小化できるか」は、リリースの期日を間に合わせる上で最重要の課題であり、最良の手は打てたかな、と考えています。
チーム組成・設計・実装
実装範囲を明確にする
要件定義と仕様策定が佳境に入った段階で、開発チームの組成を行いました。BNPLは新規実装ですが、すでに稼働している既存コードへの影響箇所が広いため、実装がピークを迎えた12月頃には10名前後が開発（アプリ=iOS/Android、フロントエンド、バックエンドなど）に携わっており、開発のサイクルを効率よく回す必要がありました。
まず、チーム組成の段階で、第一に、ドメイン知識が生きてくるのは「各開発者が実装する範囲」を明確にするという点です。
BNPLの実装にあたっては、ドメイン知識をもとに、ある程度の粒度で領域を切り分けて、それぞれが各範囲の実装を進めるスタイルで遂行することにしました。この時に「どの粒度で範囲を区切るか」という点でドメイン知識が必要になります。
基本的に「実装者数名につき、１つのドメイン」を担当するという分業の方式で、実装を割り振っています。これは、実装する人が「BNPL」という機能の全体像を把握しなくても、その領域の実装を完遂することで、結果としてリリースに間に合うということを意図しました。
もちろん、理想論を言えば、全員が「BNPLの全て」について知った方が良いわけですが、現実的にはタイムロスとなります。何事も選択と集中が大事であり、実装に携わる人が「各担当ドメイン」に集中できる環境を、チーム組成の前提としました。
不確実性を認識する
とはいえ、ドメインに区切った時の落とし穴があります。それは「ドメインに区分しにくい領域」や「異なるドメインをまたぐ範囲」が生じるということです。ここは、実装上、不確実性を帯びることになります。
具体的には、外部パートナー様のAPIを実行する箇所であったり、いろいろなドメインから参照されるテーブルの設計、月1回行う請求の締め処理バッチなどが、BNPLにおける「不確実性の高い領域」に該当しました。これらは、複数のドメインをまたぐため、BNPLの要件と仕様を理解し、さらには、各ドメインを担当する開発者と十分な意思疎通を行う必要があります。この点に関しては、私自身が実装を担当することで、カバーすることにしました。
2022年8月中旬という、チームとして実装に入る直前の段階で、私の方で、大方のテーブル設計を完了し、外部APIの呼び出し口についても、社内専用のライブラリー（SDK）を0から作ることにして、最優先で完了しました（型厳密な実装に仕立てたので、とっても楽しい実装でした）。共通箇所の実装を先に終えてしまうことで、各ドメインの実装を担当した人は、これらの利用に徹することができ、結果として実装の生産性が高まったと思います。
一方で、月1回の請求締め処理の実装だけは、関連する機能への外部依存が相対的に少ないため、実装を遅らせる判断をしました。このように、機能の依存性によっても、優先度を組み替えています。
9月以降は、開発チームのスケジュール管理、仕様のドキュメント化、実装レビュー（BNPLのバックエンド実装については、簡易的ながらも全てに目を通します）、社内・社外とのコミュニケーションを都度行いつつ、不確実性の高いタスクを巻き取るように動きました。
この手の開発では、必ず「予想外」のことがあるため、自らの実働は70%を目安としつつ、常に30%の余力を設けることで、いざという時に備える形で時間配分を設定しました。余力があれば、ひたすらに各種ドキュメントを書き、仕様や開発Tipsの属人化をできるだけ避けることに、時間を投下した形です。
実装の優先順位を決める
そして、実装が佳境に入った段階で、ドメイン知識が生きてくるのは「各機能の実装の優先順位」を明確にするという点です。
2022年12月頃にBNPLの実装は佳境を迎え、自身を含めて10名前後のエンジニアが実装を着々と推し進める状態になりました。ここで問題になるのが、本当にリリース予定日に間に合うかということです。この頃は、かなり不安だったのも事実で、なかなかに胃が痛い日々（比喩表現）でした。
[画像] 実装が佳境に入った時のガント
このフェーズでは、チーム内の実装の進捗把握を、徹底するようにしていました。
ここで重要なのは「ある機能を実装するのに何日かかるか」を把握することではなく、「実装を進める上で、不確実性はどの程度あるか」「機能間の依存関係に変更が生じ得るか」ということを、常に（毎日）コミュニケーションを取るということです。その上で、実装の不確実性が高そうであれば、担当する機能の優先順を組み替えてみたり、それでも難しそうであれば、私の方で実装（もしくはミニマムのペアプロ）を行ったり、頻繁に実装のMTGを入れたり、ということをしていました。
そして、この時も優先度の問題が出てくるので、その場合はドメイン知識と照らし合わせて、どの程度、温度感の高い機能なのかで判断をしています。例えば、エラー処理１つをとっても、頻出度が低いと想定されるならば、実装の後半に持っていくなどの工夫をし、実装順を組み替えることで不確実性を極小化していくわけです。特に、不確実性の高い機能の実装と向き合う場合は、その想定工数を「楽観ケース」「通常ケース」「悲観ケース」に分けた上で、各シナリオの影響変数を考え、現実的な対策を考えていきます。
結果論として、実装は、ほぼ無事にスケジュール通りに完了しました。開発が佳境だった時期でも、多忙を極めたというわけではなく、比較的、余裕を持って進められたと思います。
今思えば、さまざまなケースを考慮し、優先度を元に着手順を組み換えながら進めており、いずれもドメイン知識が拠り所になっていたな、と思います。
QA・リリース
不測の変更に備える
BNPLでは、2023年1月ごろまでに大方の実装を完了し、本格的なQAに着手しました。ここまでくると不確実性はかなり小さくなっており、いかにQAの精度を高め、リリース時のリスクを最小化するかという観点が重要となります。
この終盤フェーズにおいては、ドメイン知識については、ほぼ役目を終えたと言えますが、それでも大小の仕様変更は発生するもので、その都度、対策を練っていく必要があります。
実は、BNPLでは、本番環境へのリリース直前（数週間前）に、重大な仕様変更が発生しました。その機能はぼかしますが、かなり大きな変更で、どう足掻いても避けることが難しいものでした。ビジネス側を担当する方が「顔を真っ青にするほどの変更」だったと言っても、言い過ぎではないレベルの変更だったわけです。実際に関係者が一同に集まったMTGは、それは、とてもすごい空気感だったのを鮮明に覚えています。
とはいうものの、開発面において、その変更に対応する上で要した時間は、数日程度であり、重大なリリースの遅延をもたらすものではありませんでした。MTG後すぐに、バックエンドおよびアプリエンジニアで緊急MTGを行なって、PMとデザイナーを交えて変更方針を決定し、対応にめどを立てたからです。当時のSlackを見ると、下記のような時系列でした。
- 13:45 仕様変更の噂がたつ
- 14:00 緊急会議で仕様変更が正式決定
- 15:00 PM、デザイナー、エンジニアで対策MTGを実施して、対策案を練る
- 15:42 デザインの変更対応が完了（Figmaへ反映）
- 15:52 API仕様書の変更対応が完了（OpenAPIの修正）
- この後、数日で実装とQAを行い、対応完了
このあたりは、細かい技術的な話になるのですが、実装の初期段階で、その機能について「将来、このようになるよね」と話した上でOpenAPIでAPI仕様書を作成し、バックエンド側の内部実装で疎結合なクラス設計にしており、意外なことに「こうなるタイミングが早くやってきた」ため、結果として、迅速な対応が可能になったわけです。ここでも、あるべき姿から逆算して仕様を策定したことや、ドメインに対応したクラス設計が功を奏しており、ドメイン知識が生きた形となりました。
とはいえ、リリース直前の要件変更なので、冷静に今思えば、とても綱渡りだったと思います。
その後、2023年3月頃に無事にリリースを行い、初めてコンビニでPay IDアプリを使って、BNPLの代金を支払えた時は、嬉しかったのをよく覚えています。リリース直後、BNPLの購入トラフィックをプロダクトチームのみんなで集まって監視した時は、達成感がありましたし、その日のことは走馬灯のように記憶が蘇ってきます。
幸いにも、現在に至るまで、BNPLへは大量のアクセスがある中で、重大な障害なく安定稼働しています。もちろん、幸運にもうまくいったのは、ドメイン知識以外にも、さまざまな要因が重なっていますし、何よりもプロジェクトに携ったチームの力だと思っています。
0.1%の改善を積み重ねる
BNPLを世の中に送り出すことができ、なんとかスタート地点に立った感があります。とはいえ、本番はこれからで、追加機能をどんどん出していき、ABテストで試行錯誤を繰り返し、安定稼働を続け、最後は、購入者様やショップオーナー様に喜ばれてこそ、事業が成り立ちます。
そのためにも、ドメイン知識を活かして、チームの生産性を高めていくことが、課せられた仕事だと思っています。いまは、重要なKPIを24時間ごとにSlackへBotで流し、0.1%単位の変化を見逃さないようにして、BNPLに関わるチーム全員で仮説検証を行っています。実装面ではスピーディーに改善を行うべく、多頻度でデプロイを繰り返しています。
そして、何よりもPay IDチームとしては、BASE社全体における粗利率の改善に貢献したいですし、個人的には「投下資本利益率（ROIC）※」を意識して、末長くBASEを応援してくれる方々の期待に応えたいと思っています。
※ ROIC : 個人的に好きな経営指標にすぎず、BASEが掲げる経営目標とは一切関係ありません
最後にいつもの宣伝です。まだまだ、やりたいことに対して、プロダクトチームの人手が足りない状態です。良いプロダクトを一緒に作っていけたら嬉しいです！
