OLTA TECH BLOG

テクノロジーと好奇心で事業を成長させる

TECH BLOG

データサイエンティストがウェブ開発に取り組んだ話(前編)

こんにちは、OLTA (オルタ) プロダクトグループの北川です。OLTAでデータサイエンティストとして与信モデル開発やデータ分析、データ基盤周りの開発を担当しています。2021年には、人生初のウェブアプリ開発も行いました。

まだ比較的新しい職種のデータサイエンティストという領域において、何を意図してウェブ開発をしようと思ったか、その効果や感想など、データサイエンティストのキャリアパスの参考になれば幸いです。

ウェブ開発に取り組もうと思ったきっかけ

OLTA入社直後に私がモデル開発に着手したときにはデータ分析基盤は整備されておらず、データレイクにあらゆるリソースからのデータが蓄積されていくという状態でした。そのため、どのデータがどこで取られたかなどのメタ情報が一元的に管理されておらず、そのデータに関係しそうな人を捕まえてに業務フローやその変遷をヒアリングする、ということが定常的に発生していました。

前職は大手金融機関でモデル開発をしていた(詳細はこちら)のですが、扱っていたデータは情報ベンダーや大規模なデータメンテナンスチームにより品質が担保されたもので、データにバグがある前提はほぼ考慮する必要がありませんでした。一方、OLTAは自前のアプリとオペレーションを経由する中で生成されるデータであり、アプリのバグやオペレーションミスによりデータにバグ発生しうる環境である点が大きく異なると気が付きました。

データメンテナンスチームを抱えるフェーズではないことを踏まえると、今後もアプリやオペレーションの変更がある度にデータにバグがでる可能性は排除できないという課題が残されました。

解決したかった課題

OLTAのファクタリング事業はビジネスフローが複雑な上、常にオペレーションの改善PDCAが高速に回っている状況でした。アプリの改修もそれに併せて実施されます。とりわけ審査業務(請求書の買取判断を下すフェーズ)周りは非常に複雑で、扱うデータの性質から機密性が高く業務フローを把握しているメンバーは制限されていました。

与信モデルのリリースの際には、本番環境下のモデル推定値の出力をモデル構築時の出力に対して完全再現する必要があり、そのためにはどこでどのデータが取得されているか、を高解像度で理解する必要がありました。これをアプリ側のウェブエンジニアとコミュニケーションするコストが非常に高くなっていました。また、モデル計算にバグがあると間違った与信スコアで買取判断することとなるためインシデントにも直結するセンシティブな開発です。

この課題をどうやったら解決できるかを考えたところ、自分がウェブ開発に挑戦してみるのはありではないか、と考えるようになりました。そもそもウェブ開発をやってみたい、という興味もありました。目標はバックエンド側の業務フローロジック変更とアプリからデータレイクへ転送する仕組みの理解、と設定しました。

アプリからBQの流れ(開発前)

はじめてのウェブ開発

前提としてウェブアプリ開発はほぼ初見でしたが前職でトレーディングアプリなどデスクトップアプリ開発自体は経験がありました。ので、基本的なプログラミングの作法は理解していましたが、DjangoフレームワークやらVueやらDOMやらDockerやらK8sやらウェブ開発周りの知識は全くの素人でした。共同開発の経験もほとんどなかったのでスクラム開発やコード管理(GitHubすら使ったことなかった)にも初めて触れました。

まずはウェブ開発環境の理解と構築から着手しました。OLTAのウェブアプリはGCP上に構築されているため、コンテナやGCP周りの技術書を読み(*注1)仕組みを理解しました。あとはオンボーディング資料に沿ってコンテナビルドやプロジェクトのconfigの設定など手を動かして覚えました(環境構築は結構面倒でビルド成功するまでに数日かかりました)。

次に審査業務フローの要件整理と仕様書の作成をしました。こちらは業務ドメイン知識も元々ありモデル開発の要件定義の応用で行えました。そしてバックエンドの業務ロジック実装ですが、手元でコンテナを立ち上げてすぐに挙動が確認できるのがゲーム感覚でとにかく楽しかったです。いい感じに脳内の報酬系が刺激されてフロー状態に入っている感じでした。

あとは単体テストの実装と開発環境での動作確認をしました。モデル開発や分析系は個人もしくは少数チームで実装することが多く、汎用的な形でテストを書くことが少なかったので最初は慣れなかったですが、テストコードの意義や開発環境-本番環境運用などの概念を理解したらとても腑に落ちてスムーズに進みました。よくウェブエンジニアが口にしていたデプロイフローに時間がかかってストレス、という話もこういうことかと肌で感じました。

最後にレビューを経て本番環境へのリリースをしました。初めてなので緊張もありましたがウェブエンジニアの方にバディでついてもらい大きなトラブル無くリリース完了。デプロイフローやGitHubソースコードのバージョン管理など失敗を防ぐ仕組みがよく出来てるな、と目から鱗が落ちることの連続でした。本番での動作確認を経てチケットクローズして、初のウェブアプリ開発は終わりました。

後編へ続く)

(*注1) 会社にあったこの辺の本を斜め読み。

https://www.amazon.co.jp/dp/B08WHZ55W9/

https://www.amazon.co.jp/dp/B09DP1BR35/

https://www.amazon.co.jp/dp/B08NWQ7J5Q/