はじめに
こんにちは！ BASE BANK で、BASE を利用するショップオーナーさんが簡単に資金調達できるサービス「YELL BANK」の開発を担当している Doarakko です。
今回は BASE BANK が掲げているフルサイクルエンジニアという働き方の中で、YELL BANK の開発チームが実際にどのようなことを行なっているのかいくつか紹介します。
フルサイクルエンジニアとは
これまでソフトウェアライフサイクルの各段階を分業、専門化していた状態から、よりスピーディにプロダクトアウトプットし続けるために一連の段階を価値提供に関わるエンジニア、チームが責任を持ち、実行できるようにしようというスタンスです。
Real World Full Cycle Developers から抜粋させていただきました。
私はフルサイクルエンジニアを、エンジニアリングに軸足を置きつつ、事業に貢献するために必要なことを何でもやるエンジニアと解釈しています。
何でもやるとは言いつつ、プロダクトを形にしてユーザーに届けることがエンジニアの一番の仕事です。 今回は形にすることとは少し離れたところで、フルサイクルエンジニアとして行っていることを紹介します。
実際に行っていること
事業影響の大きい数値の監視とその対応
事業責任者・事業企画・PdM・PMM・アナリスト・オペレーション・デザイナー・エンジニアと、職種ごとに責務は異なります。 見ている数字は基本的にどんどんブレイクダウンしていき、それぞれの領域で事業影響の大きい数値に責任を持つ必要があります。
そこで実際に YELL BANK の開発チームで監視しているものを2つ紹介します。
機械学習の推論結果の監視
YELL BANK ではショップごとの売上を元に資金調達可能な金額を算出しています。 売上が大きければ大きいほど、資金調達可能な金額も大きくなります。 金額の算出には機械学習を使用しています。
また YELL BANK は全てのショップが利用できるわけではありません。 ショップごとに審査を行なっており、その中でも機械学習が使用されています。
資金調達可能な金額はショップオーナーさんの資金繰りの不安を解消し、次の挑戦を支えることができるのかという点、ショップごとの審査結果は利用可能なショップ数に影響を与えるという点で、非常に重要な数値です。
機械学習を用いたシステムが通常のシステムと異なるのは、エラーにはなっていなくても問題が起きているケースがあるということです。
例えば
- アルゴリズムの変更により、金額が意図せず大きく変化している
- データの変化により、審査に通っているショップ数が少なくなっている
機械学習の推論結果は毎日変化するため、バッチでショップごとの推論結果を S3 に保存し、そちらを BigQuery に連携しています。 そこから Looker とそのアラート機能を用いて、一定の変化があると Slack にアラートを飛ばすようにしています。
実際に数値に変化があった際は、アナリストと連携して対応を行なっています。
YELL BANK の支払関連の数値の監視
YELL BANK のビジネスモデル上、ショップオーナーさんが資金調達しただけでは私たちの売上にはなりません。 資金調達後にショップオーナーさんが支払いを完了して初めて、私たちの売上になります。
支払いはショップの商品が売れた（正確には売上が計上される商品が発送された）時に、商品の売上金額を元に YELL BANK への支払金額が決まります。 ショップの売上が少ないときに、なるべく YELL BANK の支払いが負担にならないような仕組みです。
https://yellbank-lp.thebase.com/
YELL BANK の支払い金額は、商品の代金から様々な手数料が差し引かれた後の売上から計算されます。 そのため YELL BANK の支払い処理は、発送や手数料が関連する様々なプロジェクトの影響を受けます。
基本的にはプロジェクトチームと連携しながら対応を行いますが、考慮漏れやデータ量の増加による影響で、YELL BANK の支払いが正常に行えていないことがあります。 支払いに関するいくつかの数値を監視し、異常があった際には修正や他チームとの連携をとって対応を行なっています。
オペレーションチームと協力して運用業務を効率化
BASE BANK のオペレーションチームはショップオーナーさんからの問い合わせ対応だけではなく、利用可否の最終チェックや資金調達後のフォローなど様々な業務を行っています。 ユーザー数の増加に比例して日々の運用業務にかかる工数も大きくなっていました。 そこでオペレーションチームとエンジニアが協力しての、運用業務効率化プロジェクトが始まりました。
始まったきっかけは BASE BANK で月に1回行っている全職種合同の LT 会です。 オペレーションチームのメンバーから日々どのような業務を行っているのか発表があり、その中で日々の運用業務にかかる工数が大きくなっていることを知りました。
運用業務を効率化するためには、まずはエンジニア自身が実際の業務を体験しないとということで、オペレーションチーム主導で運用業務の体験会を開催していただきました。 実際にエンジニアが業務を体験することで、どの作業に負担がかかっているのか、どこがボトルネックになっているのか、オペレーションチームの生の声を聞きながら理解を深めることができました。
体験会後にエンジニアが運用業務の内容を Figjam に整理し、それを元にオペレーションチームと効率化の方針を議論、アウトプットイメージをすり合わせました。
開発がスタートした後も細かい頻度でシステムに触っていただくことで、FB のサイクルを何回も回し、手戻りを抑えながらスピーディーに開発を進めました。 リリース後にはうれしい FB をたくさんいただきました。
その後も追加の効率化案をオペレーションチームから提案していただき、現在も継続して開発を行っています。 オペレーションチームの情報発信をきっかけにエンジニアが形にして始まったこの取り組みを、チームとして今後も継続していければと思います。
AWS のコスト削減
BASE BANK では毎月の AWS の金額の増減をウォッチして、変化があった際には調査・対応を行なっています。 一部ではアラートも設定して、金額の急激な変化にもすぐに気づけるようにしています。
ただそもそもの現在のコストに対して、コスト削減できるところがないかというところは見れていませんでした。 そこで昨年末に、AWS のどのサービスにどれくらいお金がかかっているのかをチームで確認。 金額が大きいものから順にコスト削減できるところがないかを調べていきました。
その中で使用している ElastiCache がオーバースペックであることや、不要なリソースが存在していることがわかりました。 不要なリソースについては削除、Elasticache についてはシステムの数値を監視しながら段階的にスペックを落としていき、最終的には年間約110万円のコスト削減に成功しました。
サービスをグロースして売上を立てるのは変数も多く不確実性も高いですが、インフラコストの削減は（基本的には）自分たちのシステムときちんと向き合えば実現可能です。
AWS のコスト削減については、まだチーム内の知見が少なく、小さな対応しかできていないため、伸びしろがあると考えています。 社内の他チームと知見を共有しながら、引き続きやっていければと思います。
おわりに
今回紹介させていただいたのはあくまで一例で、事業に貢献するためにやれることは他にもたくさんあると思います。
この記事を読まれた方が、自分たちの組織ではエンジニアがこんなことをやっていますということを発信していただけるととてもうれしいです。 （フルサイクルエンジニアを掲げていなくても）
また BASE BANK はこういったことがやり尽くされている組織ではありません。 現在複数の既存事業のグロースと新規事業の立ち上げを行なっており、やれることはたくさん転がっています。 転がっていることに気づいていないこともたくさんあると思います。
少しでも興味を持っていただけたら、気軽にカジュアル面談に来ていただきたいです！
