ID:7172さん

# 概要 中古品の買取業務を支援する社内システム。 すでに稼働していた買取システムが存在していたが、運用コストの増大と周辺システムと連携する為、新しい買取システムを構築中。 新しい買取システムでは以下の機能を提供。 * 買取依頼者（顧客）の登録 * 買取品目の登録 * 買取品目から査定金額の予想と査定ランク付け（新システムのみ） * 他システム連携（新システムのみ） # チーム構成 プロダクトマネージャ: 2名 エンジニア: 6名から8名。FrontendとBackendを含む。 QA: 1名 インフラ: SREチームが担当。ただし、基本的なメンテナンスや監視、ちょっとしたインフラ構成の変更についてはチーム内で実施するのが基本となっている。 # 所属期間 2023/9〜 # 担当 主にBackendでの機能追加、機能改善の担当。 Frontendで人手が足りない時はヘルプでFrontendの実装。 # 使用技術 シンプルなAPIサーバとSPAで構成されたサービルとなります。 * APIサーバとしてGo + ogen(openapi.yamlを元にAPIのI/F生成）+ sqlboiler(ORM) + Do(DI Container) * FrontendはNext.js + TypeScript * APIのスキーマ管理にopenAPI3を使用。このAPI仕様を元にAPIサーバとFrontendのAPIクライアントを生成 * インフラはGCPでインフラ構築にはterraformを使用 * Backendの実行環境はGCPのcloud run、バッチ処理はcloud run job。Fronendはcloud storageから配信 * データベースにはAlloyDB for postgreSQLとcloud sqlのpostgreSQL * CIにはgithub actions、CDにはcloud build * ユーザー認証基盤にauth0 # 主にやったこと * 機能追加 * 他社買取サービスとの連携処理の実装 * 買取依頼のCSVファイルを受取、自社買取サービス向けにデータ変換を実施し、DBへ買取データの登録。 * 買取品目から査定金額の予想と査定ランク・査定時間を予測する機能の実装 * 買取品の種類と点数を元に既に用意されている買取査定金額データベースと顧客属性から買取金額・査定時間を予測し、さらに顧客のランクを決定する機能の追加 * この機能については初めから全てを実装したわけでなく、当初の担当者がチーム事情で変更になった為、ある程度できた状態を引き継いで完成させました。 * 新システム移行作業 * 旧システムから新システムへの移行を機能毎に以下の段階で実施。 * まず新システムに旧システムへリクエストとレスポンスをProxyするだけのAPIを追加。Frontendは新システムのAPIを叩くように改修することでFrontendの向き先を変更 * 次に新システムのAPIを旧システムへのproxyから旧システムの機能を移植したものに置き換え。これでBackend処理の移行 * 最後に新しいDBを用意し、旧システムのDBを移行することで移行を完了させる # 課題と対応 * 構造化ログの導入 * 参画時、アプリケーションログが構造化されていなかった為、バグが発生しても原因の特定に時間がかかっていました。 * そこで構造化ログ出力を提案し、実装。ちょうどGoの標準ライブラリとしてslogが出たばかりでしたのでslogにて構造化ログを出力する実装を行いました。 * APIの高速化 * 一部APIのレスポンスのレイテンシーが低いことが課題になっていました（レスポンスに8秒程度かかっていました） * 低速になっていた原因はデータ取得にあることがわかった為、データキャッシュするライブラリを導入することで解決しました * 当初はredisなどのメモリキャッシュを提案したのですが、インフラコストを可能なかぎり抑えたい、ということでしたのでアプリケーションのメモリ上へキャッシュする方法に変更しました。 * アプリケーションへのアーキテクチャの導入 * 参画時、リクエストを受け取ってからの処理が全て同じ階層で行われており、ユニットテストを追加することができない状態でした * そこでDDDやクリーンアーキテクチャなどを参考にアプリケーションを階層分けを提案し、実施することでユニットテストを導入できるようにしていきました。 * 階層分けし、階層間を粗結合にする為にDIコンテナを導入することで粗結合になるようにしました。 * ただし、階層分けをしたことで定型的なコードを記述することが増えるデメリットも顕在化してきました。 * これを克服する為に既存の構造体定義などからオブジェクトを組み立てるbuilder関数の自動生成ツールなどを作成することで対応しました。

# 概要 複数企業で共同で営業活動する際、見込み顧客（法人）を共有などをできるSaaSです。 すでにPocとして1社への導入が決まっていたが、それ以外はこれから営業していく段階。 その為、まだユーザー数は多くはなく、プロダクトはこれから成長段階という局面で参加しました。 # チーム構成 * エンジニア: 5名〜6名 * 営業件財務: 1名 * プロダクトオーナー: 1名 上記の構成でほぼ全社員という状況でしたので、エンジニアの中で決まった役割などは存在せず、ほぼ全員がFrontend・Backend・インフラを担当していました。 # 所属期間 2022/10〜2023/8までの約10ヶ月間 # 担当 サービスの特性上、企業データベースを作成する必要があった為、有償で購入した企業情報データや公開されている企業情報を修正・整理し、データベースに格納する機能開発を主に行っていました。 同時に収集した企業データのユーザーに可視化する機能についても担当していました。 # 使用技術 シンプルなAPIサーバとSPAで構成されたサービス。 * APIサーバとしてGo + ogen(openapi.yamlを元にAPIのI/Fを生成) + ent(ORM) * フロントエンドはReactとTypeScript * APIのスキーマ管理にはopenAPI(v3) これを元にAPIサーバの生成とFrontendのAPIクライアントを生成 * インフラはAWSでコンテナの実行にはAWS Fargateを使用。インフラ構築にはterraformを使用 * バッチ処理にはAWS Batchを使用 * データベースはAWS RDS上のpostgres * CIとCDはgithub Actions * ユーザー認証基盤にauth0 # 主にやったこと * 機能追加 * 企業データベースの収集用バッチ処理の開発・改善 * 修正した企業データの整形処理とフィルタリング用のバッチ処理の開発・改善 * 企業データのデータベースへの登録バッチ処理の開発・改善 * 登録企業データの可視化機能 * その他、既存バグ改修など # 課題と対応 * 既存のバッチ処理は入り組んだ作りとなっていた為、保守性に課題があった。 * 可能な箇所からユニットテストを追加していった * DBアクセス部分を少しずつリポジトリパターンを導入して分離していった。 * 企業データベースの登録に処理時間(約40分程度)がかかっていた課題があった。 * 登録処理のクエリの見直し（bulk insertやupsertへの変更など）することで20分程度まで短縮 * 企業データを可視化する際、ユーザーが指定した条件に合致した企業情報をSVGの地図データとして色別けした日本地図で可視化したいというプロダクトオーナーからの要望 * reactで利用可能なSVGライブラリの調査・選定を実施 * SVGとして公開されている地図データの調査 * 地図情報と企業データをマッピングする処理を記述することで日本地図として可視化することで解決