認証・決済APIの移行を無事完了しました(Yahoo! ID連携v2移行)

エキサイトの菅間です。 普段は、電話占い・お悩み相談室・恋ラボなどのToC向け課金プラットフォームの開発を行っています。

今回、Yahoo! ID連携 v1のクローズに伴うv2への移行を担当し、認証・決済に関するAPIのエンドポイントの移行を無事に完了したので振り返りをしたいと思います。

プロジェクトの背景

Yahoo!版電話占いはYahoo! ID連携を使ってログイン機能、コイン購入機能を実装しています。 今回は、Yahoo! ID連携 v1のクローズに伴うv2への移行を担当しました。

プロジェクトの概要は下記の通りです。

  • プロジェクト期間:2021年11月 ~ 2022年2月
  • プロジェクトのゴール:問題を発生させずプロジェクトの移行を完了させる。

プロジェクトは、自分1名で主導して行いました。 全体の進捗はマネージャーと企画の方に相談、コードレビューや相談は事業部の開発メンバーに相談しながら進めました。

移行の対象

  • Yahoo! ID連携 v2への移行
    • エンドポイントの切り替え
      • 認証
      • 決済
  • APIのレスポンスの変更とそれに伴う改修

移行の結果

  • Yahoo! Wallet API移行:1月に移行完了
  • Yahoo! ID連携v2移行:2月に移行完了

結論としては、本記事執筆時点ではトラブルが発生することなく、運用ができています。 また、不要なファイルも900ファイル以上削除することができました。

プロジェクトの移行が完了したので、振り返り・反省を行っていきたいと思います。

良かった点

まずはプロジェクトの良かった点を振り返りたいと思います。

  • 問題が発生することがなく、プロジェクトを移行できた。
  • リファクタリングを進めることができた。
  • 認証・認可・OAuth2.0周りに関してキャッチアップできた。

問題が発生することがなく、プロジェクトを移行できた。

プロジェクトのゴールである「問題を発生させずプロジェクトの移行を完了させる。」ことが達成できたのが1番良かったです。

無事に移行を完了させるために下記点を意識しました。

タスクの管理

以下理由でプロジェクト管理にスプレッドシートを活用しました。

  • 企画の人にも進捗を共有する。
  • 社内の別プロジェクトでも使われているため導入コストが軽い・ある程度最適化されたテンプレートが存在する
  • 無料
  • その日からすぐ使える

スケジュール管理

タスクを細分化して、それぞれに期限を設けるのですが、「アラートを出すタイミング」は意識をしました。 スケジュールの進捗が遅れた場合は、都度上長へ相談・共有を行いました。

今回のプロジェクトでは、Yahoo社から配布されるSDKのリリースが遅れた関係もあり、当初の期限では厳しくなりました。 その際もいち早く上長に相談し、先方とスケジュール調整に入ることができました。

リスク管理

スケジュールに間に合いそうにない場合の解決策としてメンバーの増員が考えられます。 仮にそのような状況になった場合に、素早くプロジェクトの概要を掴んでもらうためにGoogle Driveにドキュメントの一元管理・整備を行いました。

また、Pull Requestを事業部の幅広いメンバーにお願いし、何となくプロジェクトを知ってもらえるようにしました。
(レビューしてくださったみなさんありがとうございます。)

リファクタリングを進めることができた。

今回の移行対象のリポジトリには2つのサービスが同居していました。 1つはサービス終了済みなため、サービスは動いていないが、コードは残っている状態でした。

検索でヒットする、初見の人が困惑するなど開発者体験が良くないため、今回の移行に伴いほぼ全て削除しました。

認証・認可・OAuth2.0周りに関してキャッチアップできた。

プロジェクトというより個人的な良かった点なのですが、認証認可に関しての改修経験を積むことができました。

qiita.com

反省点

次に、プロジェクトの反省点を振り返りしたいと思います。

  • スケジュールの不確実性を明らかにすることにもっと着手すべきだった。
  • プロジェクト初期に客観的なフィードバックを経験者である先輩にもっと早くもらうべきだった。

スケジュールの不確実性を明らかにすることにもっと着手すべきだった。

プロジェクトの初期は、わからないことがたくさんあります。
どれくらい時間がかかるのか、見積もりが問題がないのか?など解像度が低い状態です。

今回は、サービスの開発やSEO系のタスクも並行して行なっており、プロジェクト初期に初速を出すことができませんでした。
初速が出せないリスクとして、何かあったときの対応が後手に回ってしまいます。

そのため、上長と既存のタスクの調整をし、初速を出すことに注力すべきでした。
次回からは、プロジェクトのタスクを網羅する、鍵となりそうなタスクを仕分けする、ざっと見積もりをする時間を確保する動きをしたいと思います。

プロジェクト初期に客観的なフィードバックを経験者である先輩にもっと早くもらうべきだった。

社内には様々なプロジェクトをこなしてきた先輩がいるので、もっと早い段階で巻き込むことができたら、よりスムーズに進めることができたと思います。

プロジェクトの振り返り

1人プロジェクトでしたが、事業部の先輩とプロジェクトの振り返りを行いました。 客観的にフィードバックを以下のようにいただきました。

良かった点

当事者意識を持ってプロジェクトの移行を完遂した。

  • 先方の担当者とメールのやり取りを率先して行った。
  • 古いソースコードの削除やリファクタリングなどを主体的に行った。
  • 関連する箇所のドキュメントの更新を行なっていた。

また、以下のようなフィードバックを総会でいただきました。

YahooSDKバージョンアップにおいて開発による実装だけで無く、当事者意識でyahoo担当者と密に連絡を取りバージョンアップ完了不具合も無く、うやむやになっていた連携部分の仕様が整備されました

.

自ら能動的に動き、施策にも細かく丁寧に向き合っている姿勢が素晴らしく、Yahooのv2移行について、先方との調整も含めてスピード感をもって対応しています

プロジェクトの進め方が良かった。

  • 計画書、テスト項目、タイムテーブルなどの資料を作成・共有し、緻密にスケジュール管理ができていた。
  • 様々な人にレビューをお願いすることによって、プロジェクトを知ってもらい、巻き込むことができていた。リスク管理として良かった。

カンファレンスへの登壇や既存の運用系も積極的に行なっていた。

  • 移行のプロジェクトだけではなく、それ以外のタスクも行なっていた姿勢が良かった。

tech.excite.co.jp

改善点

プロジェクトの初速が出ておらず、初期はプロジェクトが不透明だった。

「1人でやれらないといけないことだが、もっと周りの人を頼っても良い」とのことでした。

目的はプロジェクトを無事に完了させることなので、目的意識が大事ですね。

概ね、先ほどの反省点で出た内容を振り返りました。

最後に

そんなエキサイトではフロントエンジニア、バックエンドエンジニア、アプリエンジニアを随時募集しております。

www.wantedly.com