ID:66221さん

# 概要 複数ある古のバッチをGoでリプレイスを行った。 このプロジェクトは自ら企画・提案をして進めた。具体的にはリプレイスの言語や実行環境等の技術選定や選定理由をまとめて承認をもらってから始まったプロジェクトである。 # 期間 2023/12 ~ 2024/04 # 詳細 ## 役割 開発リーダー - 技術選定〜設計、開発(テストコードも含む)、インフラ構築(AWS SAMやStep Functions、GitHub ActionsによるCI/CDなど) ## 技術 - 言語：Node.js、Go - DB：PostgreSQL - インフラ：AWS Lambda, AWS SAM, AWS Step Functions # 課題とその対策 - #### テストコードや仕様がなく今動いているものが正となっていた 【対策】 - 今後仕様が分からなくならいために書き換え時に仕様書を作成したりユニットテストコードを作成した。なるべくカバレッジを高くするために、モックを有効活用してテストコードの網羅性を高めた。 - #### デプロイが手動 【対策】 - GitHubActionsとAWS Samを利用して自動デプロイのワークフローを導入。そのための自動テストも追加した。 - #### 実行タイミングによるデータ不整合やトランザクションがイマイチで万が一途中でエラーが発生した場合のリカバリがかなり大変といった細かいがエラー時に致命的なところがある 【対策】 - 複数のバッチは依存関係があるため、Step Functionsを利用して依存関係を制御して不整合が必ず起こらないようにした。一度の実行で扱うデータ量を少なくしたり、重複実行しても多重にデータが取り込まれたりしないように工夫をしてリカバリ発生を防いだ。 # 成果 - LambdaとSAMを利用して開発容易性を高めたのと同時にサーバーレスによる耐障害性も高めることができた。 不明瞭だった仕様をハッキリとさせ、データ不整合が起きそうなところを防いだりしたことで安定的な運用ができている。 自ら技術選定・提案してリプレイスをやり切れた経験自体が自分の中で大きな経験となった。

# 概要 自社の下取りサービスに外部企業の注文履歴を連携し、利用できるようにする新サービス開発プロジェクト。 外部企業との連携部分の設計・開発、自社サービスの連携フローの設計・開発を行なった。 自身で設計開発も行いつつ、プロジェクトの開発リーダー兼PMのような役割も担った。 # 期間 2022/10 ~ 2023/11 # 詳細 ## 役割 開発リーダー兼PM - 自社サービスの連携フローの設計及び開発 - 自社の開発チームの定例ファシリテーター - 外部企業との連携周りの仕様策定・定例ファシリテーター ## 技術 - 言語：Node.js - フレームワーク：Express - DB：PostgreSQL ## 方式 - 連携方式：APIで連携 - データは更新・追加・削除がある # 課題とその対策 - #### 下取りサービスへの導線は複数あり、ユーザーが連携に気付かない可能性があった 【対策】 - 連携の入口を1つだけにするのではなく、複数用意してユーザーの目に留まる回数を増やすようにした。 - 連携フローを行うところをモーダルにすることで、そのモーダルを使い回して複数のページで連携をできるようにした。 - #### 連携フローでは複数のチームのAPIや外部企業のAPIを呼び出す必要がありエラーハンドリングが複雑 【対策】 - ユーザーには分かりやすい1種類のエラー文言を表示するようにして、もう一度やり直してもらうボタンも表示することで、連携せずに離脱されるのを防ぐようにした - #### 追加の購入履歴の連携をどうするか・外部企業の負荷が懸念 【対策】 - 一度連携したらユーザーは連携作業を行うことなく自動で連携されるような仕組みにした - 外部企業側のAPI負荷が懸念だったため、呼び出す回数を制御するように1ユーザー1リクエスト/日のように制限を入れて対応した - #### 自社アカウントと外部企業アカウントの連携組合せが変わる可能性がある - 複数アカウントを保持しているユーザーが誤ったアカウントの組み合わせで連携する可能性も考慮して、別アカウントとの連携をしたら、連携している注文履歴も自動で更新されるような仕組みにした - #### 大量に注文履歴がある場合の連携時間の遅延 - 要件として、連携は同期で行わなければならなかったため、一度の連携アイテム数を制御することでレスポンス時間が大幅に遅延することを防いだ - 上限で連携し損ねたアイテムは次の自動連携で連携する仕組みにした # 成果 - 下取りサービスに利用できるアイテム数を増やすことができ、結果的に利用アイテム数、利用者数を増加させることができた

# 概要 現職のサービスである下取り機能のユーザーキャンセルの機能を追加した。 # 期間 2022/12 ~ 2022/03 # 詳細 ## 技術 - バックエンド：PHP - フロントエンド： HTML CSS JavaScript JQuery - フレームワーク：CakePHP2 - DB：MySQL ## 機能 - ユーザーが下取りをキャンセルできる機能 - 決済方法：クレジットカード、コンビニ支払い # 苦労したこと ## 課題とその対策 #### 既にある下取り自動キャンセル機能や、管理画面でのキャンセルと実行が被っても重複させない 【対策】 - 各キャンセル機能の処理の最初に対象アイテムをキャンセルステータスに更新（即時コミット）して、極力重複キャンセルが起こらない仕組みを作成した - 決済執行前に対象アイテムのステータスのバージョンを確認して重複キャンセルが起こらないような楽観的ロックを導入した #### 外部サービスエラー時でも不整合が起きないようにする - クレジット支払いサービス、コンビニ支払いサービス、倉庫のシステムと連携する必要があるため自社DBデータとの不整合が起きないようにしなくてはいけなかった 【対策】 - 外部サービスの連携・決済を先に行い、成功したらDBのデータを追加・更新するようにした - もし外部サービスで失敗した場合は最初に更新したステータスを戻すような実装をした ## 成果 - CS部が受ける問い合わせを40%減/月を達成することができた - ユーザーのUXが向上した

# 概要 現職で参加したプロジェクト。 本人確認書類機能で課題の解決を行うために新規機能開発と既存機能の改修を行った。 課題の解決をしてリスク軽減やユーザビリティ向上につながった。 # 期間 2022/04 ~ 2022/09 # 詳細 ## 技術 - 言語：PHP - フレームワーク：CakePHP2 - DB：MySQL ## 機能 - 保管期間が超過した本人確認書類の削除バッチ開発 - 本人確認書類の不要機能の削除（調査含む） - 本人確認書類周りの機能の既存コードバグ修正・リファクタリング - 本人確認書類管理サイトの新規機能追加 # 苦労したこと ## 課題とその対策 #### 保管期間が超過した本人確認書類の削除の条件が複雑 具体的には、既に登録してある本人確認を再チェックして承認というパターンや前回承認との期間が短ければ自動承認などがあり単純に登録から◯年保管した後に削除とはいかなかった 【対策】 - 複数のテーブルから情報を集め、確実に削除しても問題ないデータだけを抽出するようにした - 法の制約と既存仕様上の制約を一度ドキュメント化し、整理してから設計した #### データベースと実ファイル両方の削除を行う 【対策】 - DBの削除をし同期的に実ファイル削除とした - 実ファイル削除が失敗しても次の日以降で削除されるようにリカバリ不要な設計にした #### 初回実行は対象ファイルが大量にある 【対策】 - 負荷や実行時間を事前に検証して数日に分けて削除ができるようにした #### 本人確認のフローがモノリシックで複雑かつ、チームメンバーで仕様を理解している人が一人もいない 【対策】 - 手探りでコードを読み進めながら仕様をまとめたり、バグを発見していった - 複雑な処理をドキュメント化（シーケンス図やフロー図を含む） - 運用者（本人確認書類の管理者）に実際の運用と現状の課題をヒアリングして解決を行った ## 成果 - 仕様や運用の流れが分かる人になれたので、別案件（サーバーリプレース）などでも蓄積した知識を活かして課題解決できた - 不要な機能の削除・リファクタリングを行ったことで以前よりはコードが見やすくなった