はじめに

こちらはバイセルテクノロジーズ Advent Calendar 2024 の14日目の記事です。

昨日は望月さんによるフロントエンド新規開発のルーティングライブラリにReact RouterではなくTanStack Routerを採用した話でした。

こんにちは！テクノロジー戦略本部開発1部の中舘です。

現在はバックエンドエンジニアとして、出張訪問買取システム「Visit」の開発・運用しています。

本記事では、前回の記事を執筆した際に行っていた、出張訪問買取における複雑なユースケースを実現するための機能改善について、お話ししたいと思います。

この記事が、要件定義からリリースまで一気通貫で開発に挑戦する際の参考になれば幸いです。

はじめに
課題だったこと
要件定義編
実装編
QA編
リリース編
すべての工程を一人で担当してみて
結果
最後に

課題だったこと

当時大きな課題となっていたことは「予期せぬステータス遷移による業務進行不能バグ」でした。限定的な操作によるバグではあるものの、最も件数の多い問い合わせでした。

根本原因は「ステータスとして、分析用の操作履歴を業務フローに関わるロジックに使用していたこと」でした。

そのため、以下のような通常のフローでは問題なく動作しますが、特殊なフローの際には、業務が進行不能になるバグに陥ることがありました。

例えば、「Bを飛ばしてCに行く」場合、業務フローとしては可能であっても、操作履歴を用いたロジックとしてはA→B→Cの順番以外は許容していませんでした。また、「CからAに戻る」場合も同様で、再度順番どおりに操作する必要があります。

さらに、課題解決が難しかった要因として、外部サービスを含む複数のデータソースをもとにステータスが成り立っていたことが挙げられます。

このように業務への影響はあるものの、複雑なドメイン知識が必要で、かつ頻繁に使われるロジックであるため、着手が難しい課題でした。運用でカバーはできていたものの、今後も継続してカバーすることは難しいと判断し、チームで根本的に解決しようと考えました。

そこで、新卒である自分に、成長機会も兼ねて、時間をかけて要件定義から取り組んでほしいタスクとして任されました。要件定義から取り組むことは初めてだったので、不安はありつつも、挑戦してみたいという意欲が強かったです。

要件定義編

このタスクを任されたときに、「今までデータ分析用の操作履歴をステータスとして使っていたので、操作履歴を使わないように修正してほしい」と言われました。しかし、私は操作履歴をそのまま使い、ロジックを修正するだけで課題を解決できるのではないかと考えました。

そのためにまずは、以下のように疑問点を洗い出し、現状を整理しました。

操作履歴をステータスとして利用することになったのはどんな経緯なのか
現状のステータス遷移と業務フローの関係はどうなっているのか
問い合わせが来ているバグの発生条件はステータスの修正で解決できるのか

開発環境で検証すべきものは手を動かし、経緯などの課題の背景については適宜チームメンバーとのミーティングを行うことで整理しました。

現状を整理したうえで、あるべき姿を実現するための要件について考えました。結論は、ロジックで利用する値として新たにステータスを定義するべきだということです。

実装編

要件定義から行ったおかげで、優先度や影響範囲が分かり、適切な粒度で実装を進めることができました。

まずは必要なロジックを順番に実装していきました。

また、このロジックをAPIとして実装する必要があるかどうかは、あらかじめフロントエンドエンジニアと話し合いました。結論としてはAPIは不要でしたが、こまめにコミュニケーションを取ることで手戻りを最小限に抑えられたと考えています。

ロジックを実装していくうちに、ステータスの種類を増やす必要が出てきました。そのため、要件定義に戻ることになったのですが、結果として、問い合わせが来ていたバグを完全に解消することにつながりました。

今後も同様にステータスを増やしたいケースが考えられると反省し、ステータスを定義する段階で変更しやすいコードを意識しました。今回の場合は、データベースに近い箇所は変更せずに済むようにロジックを組むという方針にしました。

スクラムやアジャイルを採用しているチームだったからこそ、開発によって解像度が上がっていく過程で、よりユーザーに寄り添った要件に修正できているという実感がありました。

そうして一通りバックエンドの実装を終えたときに、「フロントエンドも実装してみなよ」とメンターの方に助言され、フロントエンドの実装にも取り組みました。バックエンドエンジニアとはいえ、フロントエンドのコードも読めるようになるべきだと考えていたので、良い機会だと思いました。

QA編

実装も終わり、次はリリース前のQAになります。 VisitチームにはQAエンジニアが所属しているため、破壊的変更を含む機能開発のQAはQAエンジニアに依頼します。

今回は、新しく定義したステータスに合わせてテストケースの更新を行い、QAエンジニアに共有しました。主に以下の観点でテストケースを更新していました。

問い合わせが来ていた操作方法のバグが解消されているか
既存の業務フローにおいて、デグレが起きていないか

依頼後も複雑な要件をすり合わせていくことで、QAエンジニアと協力して抜け漏れがないようにテストケースを作成しました。

リリース編

無事にQAも終わり、いよいよリリースです。 Visitチームでは、破壊的変更を含む場合は業務終了後にリリースします。

今回の操作履歴からステータスへの修正も破壊的変更となるため、23時からリリース作業を行いました。今までリリース作業をしたことはありましたが、夜中のリリース作業は初めてで、とても緊張したことを覚えています。

ただ、要件定義から妥協せずに実装まで取り組んだことや、チームメンバーと密に会話していたこと、QAも十分に行ったことから、不思議と自信がありました。結果として、インシデントも起こさずに無事リリースできました。

すべての工程を一人で担当してみて

ここまでの工程を踏まえて、学んだことは以下のとおりです。

要件定義は現状の整理から取り組む
手戻りは必ず反省して同じ事象が起きないようにする
開発工程ごとにそれぞれの担当者と会話をする

さまざまな人たちと密にコミュニケーションをとることで、自分ひとりでは見えていなかった要件や新しい視点を得ることができました。自分一人の力では限界があると考えているので、自分でやれることをやり尽くしたら、あとはチームメンバーの力を借りるべきだと考えています。そして、それがチームでより良いプロダクトを開発しているという実感にもつながっています。

また、チームメンバーへのこまめな情報共有については、もっと上手くできそうだと感じています。

要件定義からリリースまで担当すると、どうしても知識が属人化してしまいます。そのため、コードレビューなどがチームメンバーに負担をかけてしまっていたと感じています。

自分がステータス周りで一番詳しい人になったということは、伝えるべき情報があるということです。ドキュメントに残したり、定例で共有することを適宜行うと良いと思いました。

他にも、バックエンドエンジニアとして、専門であるバックエンドの実装速度を上げるために、技術力の向上が必要だと感じました。