はじめに
こんにちは！ラクスル事業部Paymentチームの勝又、沼崎です。 私達のチームはラクスルの決済基盤システムを開発・運用しています。
「働く人をラクにするためのプロダクト開発」を目標に日々課題と向き合っています。 今回は課題解決に向けて意識している「高解像度」「仕組み化」「情報共有」の重要性について、決済オペレーション改善の取り組みを例に紹介させていただきます。
まずは小さくはじめてみる
手作業やMVP(Minimum Viable Product)のシステムに対して、イケてない・非効率だという考えを持つ人がいるかも知れません。
しかし重要なのは事業のフェーズによって、考え方が変わるのでは？という事です。 Phase1ではできるだけ小さく・早く非連続を作り、「0→1」を生み出していく。 そしてPhaseNで一定の流入増の兆しが見えた時、ここで事業のキャパシティについて見直しを図ります。
「0→1」で生み出した価値をより多くの人に利用していただき、世の中に大きなインパクトを与えていくために「1→100」への拡張をおこなう必要があります。
ただ、「0→1」を「1→100」にしていくことは、簡単ではありません。 ここで重要になるのは高い解像度で課題設定をし、技術や仕組み化によって課題解決へ導くことです。
今回Paymentチームでは「1→100」への取り組みとして、事業の拡張性を担保する為に、決済オペレーションのシステム化を行いました。
決済オペレーションの課題
課題を見つめるところからはじめる
「0→1」の検証が完了しサービスを「1→100」へと利用拡大していく中、決済オペレーションで一番の課題になったのが、 私達が提供させて頂いている決済手段の一つ「ラクスル請求書払い」に関する主要オペレーションのキャパシティ不足でした。 ※ラクスル請求書払いについてはこちら
オペレーション向けの内製システムは提供されているものの、開発当時の想定と異なるユースケースが増えていたり、 一部スプレッドシートを利用したり等、サービスを運用していく中でオペレーションが複雑化していました。 その結果、サービス運用におけるオペレーターの負担が大きくなり、キャパシティ拡張の阻害要因となっていました。
そこで複雑化したオペレーションをシステム化することを検討しました。 システム自体は比較的新しくシンプルな作りの為、システムロジック的な難しさはあまりありませんでしたが、 複雑化したオペレーションをシステムに落とし込むため必要となるドメイン知識的な難しさがありました。
ラクスルスタイル 「Reality (高解像度)」「System (技術・仕組み化)」「Transparency (情報共有)」
ラクスルでは「仕組みを変えれば、世界はもっと良くなる」というビジョンの元、4つの行動指針を定めています。 ※詳しくはこちら
その中にReality、System、Transparencyという指針があります。
- 現場の状況を実際に自分の目で見て、経験・把握した情報に基づく課題設定をするReality
- 高度な技術や仕組み化によって、課題解決に導いていくSystem
- 情報の非対称性が存在しない環境を構築し、情報共有の透明性を確保するTransparency
ラクスルではこれらの行動指針に従い、産業の改革に向き合っています。
決済オペレーションの改善
積極的な情報共有で解像度を高める
オペレーションのシステム化に際して、ドメイン知識的な難しさへ立ち向かうために解像度を高めることを徹底しました。 実際どのように画面を操作するか、オペレーターにその場で実演していただいたり、オペレーションフローの整理や具体的な画面イメージの擦り合わせを行っていきました。
会話量を意識し、オペレーターと開発チーム間で認識のズレが発生しないよう積極的な情報共有を推進しました。 職種を超えたコミュニケーションをおこなうことで、エンジニアが現場にDeepDiveして解像度を高めることができました。
その結果、オペレーションのあるべき姿、本当にやりたいオペレーションフローはどんなものかをしっかりと定義することができました。
解像度を高めていく中で見えてきた事
内製システムではかゆいところに手が届かず、1回の作業で複数画面を利用していたり、一部スプレッドシートで進行管理や作業チェックをしている箇所がありました。 これによりオペレーションフローが複雑になり、オンボーディングの難しさや、オペレーションミスによる手戻り等の課題が見えてきました。
定期的な成果物確認とリリース
設計や開発段階では、オペレーターと開発チーム間で週1定例MTGを設定し、週毎に成果物のレビューを実施しました。 ここでも情報共有を繰り返すことで、高い解像度を維持しながら開発を進めることができました。
その結果、仕様検討不足による開発終盤の大幅な手戻りや致命的なバグなくスケジュール通りのリリースができました。
仕組み化を実現するエンジニアリングの工夫
リスク最小化を意識したリリース
Paymentシステムがミッションクリティカルなシステムであることから、リリースによるリスクを最小限にすることを意識しました。 特に以下2つのポイントを意識してビッグバンリリースを避けることで、リリース後は大きな障害なく運用を迎えることができました。
- リリースは常にロールバック可能な状態にし、ロールバックしづらいものはなるべく切り出す
- リリースの単位をなるべく小さくするため、DBスキーマの更新や過去データのマイグレーションなど、運用影響のない箇所は先行してリリースする
従来オペレーションシステムとの並行運用および段階的移行
リリース日を境に突然新規画面でのオペレーションしかできないようになってしまうと、オペレーターの移行コストやミスによる手戻り等のリスクが高くなってしまいます。 また、新規画面で何か想定外の事象があったときにオペレーションが止まってしまう可能性もあります。 こういったリスクを避けて段階的に移行するため、従来のオペレーション画面は残しつつ、新規画面も並行して運用できるようにしました。
従来画面と新規画面でページは分かれますが、各画面における処理の整合性を保つため、内部のコア仕様が同一となるよう実装しました。 この際、単純に従来システムのコードを流用するのではなく、既存のクラスやモジュールを拡張し共通化することで開発コストを抑えました。
これらの取り組みを通して、該当の主要オペレーション作業時間を約1/2以下に削減することができました！
おわりに
今回の記事では開発チームとオペレーターが協力して実現したオペレーション改善の事例を元に、課題解決に必要な「高解像度」「仕組み化」「情報共有」の重要性を紹介させていただきました。
ラクスルでは様々な職種がワンチームで密に連携を取ることで、お互いに信頼関係を築きながら高い解像度で課題に向き合っています。
今後も様々な方々との信頼関係を広げながら、「働く人をラクにするためのプロダクト開発」に取り組んでいきます！
皆さんも私達と一緒に産業を改革して社会を変えていきませんか？
