ID:66221さん

# 概要 自社の下取りサービスに外部企業の注文履歴を連携し、利用できるようにする新サービス開発プロジェクト。 外部企業との連携部分の設計・開発、自社サービスの連携フローの設計・開発を行なった。 自身で設計開発も行いつつ、プロジェクトの開発リーダー兼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の削除をし同期的に実ファイル削除とした - 実ファイル削除が失敗しても次の日以降で削除されるようにリカバリ不要な設計にした #### 初回実行は対象ファイルが大量にある 【対策】 - 負荷や実行時間を事前に検証して数日に分けて削除ができるようにした #### 本人確認のフローがモノリシックで複雑かつ、チームメンバーで仕様を理解している人が一人もいない 【対策】 - 手探りでコードを読み進めながら仕様をまとめたり、バグを発見していった - 複雑な処理をドキュメント化（シーケンス図やフロー図を含む） - 運用者（本人確認書類の管理者）に実際の運用と現状の課題をヒアリングして解決を行った ## 成果 - 仕様や運用の流れが分かる人になれたので、別案件（サーバーリプレース）などでも蓄積した知識を活かして課題解決できた - 不要な機能の削除・リファクタリングを行ったことで以前よりはコードが見やすくなった

# 概要 AWS オートスケーリング周りの自動化を行った。 # 期間 2022/02 ~ 2022/04 # 詳細 ## 技術 - Auto Scaling - lambda - 起動設定 - SSM - EventBridge - S3 ## 機能 - オートスケーリング時にインスタンスが立ち上がり、各種設定やGitから最新のソースを持ってくる部分の自動化 - 作成されたAMIのオートスケーリング設定への自動反映 - インスタンス終了時にログをS3に自動で転送する機能開発 # 与えた影響 - 障害が発生した際に自動化ができていなかったために修正に丸一日程かけていたが全て自動化できた - インスタンス終了時にログ転送機能を開発したことで障害発生時の調査が確実になった - 機能開発前はEC2が動かなくなりCloudWatchにもログが転送されなくなるといった事象に頭を悩ませていた

# 概要 日常のアラートや問い合わせの対応 # 期間 2021/11 ~ # 詳細 ## 技術 - CakePHP - Laravel - Express - MySQL ## 内容 CakePHPで構築されたモノリシックなサイトや、Laravelで開発されたバッチ、Expressで開発されたマイクロサービスなどの日常的に発生するアラートやカスタマーサポートからの問い合わせの8割を主体的に対応することを入社から1年間継続している。 アラートは：15件/月 問い合わせ：20件/月 対応内容は以下のようなものが多い - バグ修正 - 暫定対応としてのクエリ実行 - 恒久対応の設計・開発 - SQLチューニング # 成果 - 高速でドメイン知識の獲得ができた - 対応で得たドメイン知識を案件やプロジェクト遂行時に役立て、循環させている - 他のチームメンバーが対応しなくていい状況を作ることで、主要業務に集中できる環境作りをした - 新人のサポートや対応巻き取りをすることができている

# 概要 新卒で入社した時計メーカーで参加したプロジェクト。時計の部品管理システムの刷新が行われ、toBのお客様に修理部品を提供するサイトとのデータ連携を担当。 データ連携バッチを約15本程、要件定義ー設計ー開発ーテストーリリースー運用まで行った。 # 期間 2020/08 ~ 2021/08 # 詳細 ## 技術 - 言語：Python - DB：PostgreSQL ## 方式 - 連携方式：CSVファイルでSFTP連携 - データは更新・追加・削除がある # 苦労したこと - 刷新した部品管理システム（新部品コード）と修理部品提供サイト（旧部品コード）でコード体系が異なっていた - 連携時に部品コードを変換するのではなく受け取り元で変換するようにした - 修理部品提供サイトの刷新があった際に新コードを受け取れるようにした - 大量のデータの更新・追加があった（バッチを毎時動かしても数万件の連携が行われる） - バルクインサートやPostgresのアップサートの使用、インデックスを作成して処理速度向上を図った # 成果 - 将来的に修理部品提供サイトもリプレースしてコード体系を揃えることを見据えて、抽出はシンプルに（加工せず）、受け取り側で加工するとしたことで、修理部品提供サイトリプレースでの工数削減が見込める