こんにちは！ファイナンシャルサービス本部エンジニアのrkun (あーるくん) です！
2024年9月20日に開催されたPIXIV DEV MEETUP 2024のメインセッションにて「自社電子マネー「pixivcoban」をつくるためにやってきたこと」というタイトルで登壇しました。
今回はその内容について、重要な部分を中心に、pixivcobanの要件定義からリリースまでどのように取り組んできたかをふりかえっていきたいと思います！
pixivcobanについて
まず、pixivcobanというサービスについてご紹介します。
pixivcobanは、2024年4月にリリースされたピクシブの一部サービスで利用できるプリペイド式の電子マネーです。
事前にコバン (有償)をpixivcobanにチャージすることで、BOOTHやpixivFANBOXでのお支払いができ、その履歴も確認できます。
また、様々なキャンペーンに応じてコバン (無償)を受け取ることもでき、それをお支払いに利用することも可能です。
私は新卒としてピクシブに入社した1年目からこのpixivcoban開発プロジェクトでフルコミットできるエンジニアとして関わっており、リリースまでいろいろな意思決定や開発をチームで協力して行ってきました。
要件定義
まず新たにサービスを作る際、多くの場合初めに行うのが要件定義かと思います。
pixivcobanは、サービスの性質から以下の2つの特性を持っていると考えています。
- ユーザーの資産や会社を守る
- ユーザーやpixivcobanを導入するプロダクトに便利に使ってもらう
これら2つの特性それぞれについて開発しやすいよう、前者を守りの要件、後者を攻めの機能として要件定義や開発手法を少し変えることにしました。
守りの要件では、ウォーターフォール開発手法のように確実に要件定義・基本設計を行い、攻めの機能では実際にデザインや実装をしながら仕様をブラッシュアップしていくというアジャイル的な開発を行いました。
それに合わせ、それぞれを重点的に検討するタイミングをずらして以下のような開発スケジュールで開発を進めていくことになりました。
基本設計
守りの要件の要件定義がある程度終わってきたタイミングで、基本設計に入り始めました。
コア部分
まずはチームで「コア部分」と呼んでいたユーザーの取引履歴を記録する部分のデータ構造の検討です。この部分は、電子マネーのサービスとして最も重要な部分なので、「コア部分検討会」という会議体を作成し念入りに検討しました。
rkunがデータ構造について草案を作り、それをテックリードや事業部長、社外エンジニアリングアドバイザーの方を集めた検討会で議論し、そのフィードバックをもとにまた草案を改良したり作り直してまた議論...という流れを計6回ほど行って決定しました。
MTGの中で多くの草案を議論してきましたが、最終的には
- 台帳構造
- 取得/消費紐づけ構造
の2案に絞られ後者を採用することになりました。それぞれの案についても簡単にご紹介します。
１つ目の台帳構造というのは、以下のように ledger という一つのテーブルに対して取得・消費どちらの履歴も挿入していく構造です。
この構造であればテーブル1つで実現できますし、取引の処理もシンプルなものとなります。しかし、一度の消費においてその元となる取得や、それぞれの取得から減算した金額を辿ることが難しいというデメリットもあります。
対する取得/消費紐づけ構造は、 gains、gain_losses、losses という3つのテーブルを用意し、取得の履歴は gains 、消費の履歴は losses に記録し、消費のうちどの取得からいくら減算したかの情報を中間テーブルとなる gain_losses に記録していくものになります。
こちらの場合は必要なテーブルが多くなり、取引の処理についても消費の場合は2テーブルに複数のレコードを記録する必要があるなど複雑になってしまいます。しかし、後から消費についてどの取得からいくら減算したかという情報を gain_losses テーブルを元に簡単に辿ることができます。
例えばこの図の場合は1000を消費していますが、1つ目の1000のgainから残っている700を減算、２つ目の2000から300を減算することで実現しています。挿入するのは赤枠になっているもので、消費を表す1000のレコードをlossesへ、それぞれのgainから700、300を減算することを示す2レコードをgain_lossesへ挿入しています。
pixivcobanでは、前述した守りの要件のうちの一つである会計要件にて「決済手段×利用先サービスごとのコバン利用金額」を報告する必要があったり、万が一取引の整合性が崩れた場合にも後者であればレコードの関係性を精査することで用意に原因を調査できるというメリットもあったため、後者を採用することになりました。
デメリットである複雑な取引処理については、コードベース上で取引処理を行う実装を一箇所に共通化してユースケースごとに取引処理を書かないようなルールを設けることで、不具合の発生を抑えることとしました。
インフラ
pixivcobanのインフラ構成については、ピクシブで多く採用されており実績のあるオンプレミスではなく、あえてクラウドインフラを利用することとしました。
理由として、開発・運用コストを抑えるためにサーバーレスのサービスを積極的に利用したかったことや、オンプレミスと比べ圧倒的に調達のリードタイムが少ないことなどがありました。
また、インフラ構成の設計にあたってはGoogle CloudさんのTAPプログラムに参加させていただき、Google Cloudのエンジニアの方々とインフラ構成の検討を行いました。
当初想定していた期間に比べて圧倒的に短く、Google Cloudのエンジニアの方々に要件や周辺システムの仕様などを共有しながら相談に乗っていただくことができたため、今後の運用も見据えたよい技術選定ができたと思います！
実装
実際にサービスを開発していくにあたり、実装メンバーとしてフル稼働できる社員エンジニアはrkunのみで、残り4名のメンバーは業務委託エンジニアというチーム体制になりました。（現在は社員メンバーも増えて体制も変わっています）
バックグラウンドのそれぞれ違うメンバーが同時に一つのプロダクトを0から開発する上で、各メンバーが完全に自由に開発してコードベースの統一感がなくなりメンテナンスが難しくなることを防ぐためにコードベースを作り始める前に普遍的な部分の詳細設計を打ち合わせて明文化しておくこととしました。
また、コードレビューに関しても開発初期については私がすべて担当するようにし、使用する関数などをある程度揃えつつ柔軟にメンバーと相談しながら開発を進めていきました。
開発フローの課題
前述のような体制でpixivcobanの開発はスタートしましたが、開発を進める中で少しずつ課題が浮き彫りになってきました。ここからはその課題と、とった対策について紹介していきます。
まず、メンバー間での詳細設計についての深い議論が難しいという課題がありました。
特に開発初期の段階では、毎日30分行っている進捗確認定例やGitLab上のMRコメントでのコミュニケーションだけでは詳細設計や実装について相談する時間が十分に取れませんでした。そのため、ある程度実装が進み1度目のMRレビュー依頼の段階で根本的な設計の問題に気づいて大きく手戻りしてしまうというケースもありました。
そこで、ペアプロ・モブプロを積極的に行うことにしました。
定例や非同期での議論が難しいと感じたら、別途ミーティングを設けて画面共有でコードを見ながら相談するようにします。実際にコードを見ながら相談することで深い議論ができ今後の方針を決められるので、そこからまた担当者に実装を進めてもらうというフローにしました。
ただ、当時のチームメンバーは私も含めてモブプロに不慣れだったという問題があったため、モブプロガイドラインという資料を作成しました。この資料には、モブプロの目的や各役割の説明、進め方などを記載して、モブプロに悩んだときに参照できる資料として運用しました。
次の課題は、コードベースの課題をチームで共有できていないことでした。
開発を始める前に詳細な設計を行ったとはいえ、ゼロから作っているサービスなのでどうしてもコードベースの課題が出てきてしまいます。当時の体制では、その課題をチームで共有し共通認識を持つ仕組みがなく、そのためコードを改善するアクションも十分に取ることができていませんでした。
そこで、エンジニアが実装の課題について相談するための定例MTGを用意し、チームで課題について共通認識をもち対応を議論できる仕組みを用意しました。
この定例MTGでは、各課題について議論した後のNEXT ACTIONが必ず決められるようなNotionテンプレートを用意しました。NEXT ACTIONには
- 改善が必要であればタスク化
- issueに積んでおき余裕ができたら対応
- 改善不要であれば何もしない
の選択肢を用意して、「議論の時間を取っただけで実際の改善に繋がらない」現象を防いでいます。
このように、だんだんと浮き彫りになってくる課題に対して対策を行いながらpixivcobanの開発を進めていきました。
テストについて
開発も (決して順調ではなかったですが...)どうにか終盤にさしかかり、リリース前にはしっかりとテストを行いました。
まず社内でテストに協力してくれる有志を募り、本番環境のpixivcobanを用いて実際にコバン購入、BOOTHやFANBOXでのコバン利用フローを実施してもらいました。その結果見つかった不具合やユーザー体験上の改善点などのフィードバックを受け、改善を行いました。
画像はその際にサンプルとしてBOOTHに用意したpixivcobanノベルティのメガネ拭きです。
また、想定する決済リクエストに耐えられるかどうかを検査するための負荷試験についても社員を募って実施しました。全員でGoogle Meetに参加した状態で一斉に操作を行ってもらい、エラーやデータの不整合がないかについて念入りに確認しました。
他にも、ユーザーの資産を預かるサービスとして、第三者に脆弱性診断やサービス全体を対象としたシナリオテストを依頼し、問題を修正してリリースに備えました。
リリース
そして2024年4月、pixivcobanを無事にリリースすることができました。
もちろんリリースした後、今も新機能開発や多くのキャンペーン施策を行いユーザーに価値を届けるべく邁進しています！
PIXIV DEV MEETUP 2024に登壇した感想
これだけ大きな会場で大勢の方に向けて、また20分という長時間の登壇をするのは初めてで不安だったのですが、登壇の後チームメンバーや他の社員からも「よかったよ！」と言っていただき、またAsk the Speakerやpixivcoban廊下ブースにてたくさんのゲストの方にも声をかけていただきお話することができました！
特に、我々と同じように自社でポイントシステムを開発・運営されている方など普段お話する機会のなかったゲストの方々ともお話ができたこともあり、とても価値のある挑戦だったと感じています。
これを機に、今後も積極的に登壇や情報発信に取り組んでいこうと思っています！
最後に
pixivcobanはこのようにまだ生まれたばかりのサービスです。これからも、より大きな価値をより速くユーザーに届けるために新機能開発や開発フローの改善に鋭意取り組んでいきます！
なお、pixivcobanの開発運用を我々と一緒に取り組んでいただける方も募集しています。
pixivcobanの未来を一緒に作っていきませんか！！
