チケットはクローズされました。しかし、ユーザーは依然として支払いができませんでした。

バックエンドは200ステータスコードを返しました。 モバイルアプリはエラーを表示しました。 ユーザーは「支払う」を3回タップしました。 アカウントからは3回引き落とされました。注文は1件のみ完了しました。その結果、残高が不足しています。 ログには失敗は一件も記録されていません。

すべてのエンジニアは自分の仕事を果たしました。しかし、誰も問題を解決していません。

チームが失敗するのは、コードが悪いからではなく、間違った作業を実行しているからであることがよくあります。完璧に動作するシステムをリリースしても、それが最悪な体験を生み出してしまう可能性があるのです。

ジュニアエンジニアはチケット単位で考えます。 チケットが割り当てられる。 コードが書かれる。 テストに合格する。 PRがマージされる。 チケットがクローズされる。

成長するにつれて、この考え方は足かせとなります。チケットをクローズするエンジニアは「役に立つ」存在ですが、「これは本当にビジネス上の問題を解決しているか？」と問いかけるエンジニアは「不可欠な」存在です。

決済フローを例に考えてみましょう。 バックエンドエンジニアはエンドポイントを構築します。それは決済を処理し、正しいコードを返します。テストカバレッジは100%。チケットはクローズ。 モバイルエンジニアは画面を構築します。それはエンドポイントを呼び出し、レスポンスを表示します。スムーズなUI。チケットはクローズ。

誰も責任を負わなかった問題：決済が行われた後、モバイルアプリが確認を受け取る前にネットワークが切断されたらどうなるでしょうか？

バックエンドは成功を示します。モバイルアプリは失敗を示します。ユーザーは再試行し、二重に課金されてしまいます。

解決策は、単なるバックエンドやモバイルの修正ではありません。「べき等性キー（idempotency keys）」が必要です。モバイルアプリは試行ごとに一意のキーを生成しなければなりません。バックエンドはそのキーを使用して、再試行によって二重課金が発生しないようにしなければなりません。

この解決策は、エンジニア同士がネットワーク切断時のユーザー体験について話し合って初めて実現します。

ハードウェアでも同じことが起こります。 ハードウェアエンジニアはファームウェアをリリースします。 モバイルエンジニアはアプリをリリースします。 バックエンドエンジニアはAPIをリリースします。 各パーツは動作し、各テストもパスします。

しかし、ユーザーがボタンを押してからライトが点灯するまで11秒かかります。レイテンシはコンポーネント間の「隙間」に潜んでいるのです。エンドツーエンドの速度に対して責任を持つエンジニアは一人もいませんでした。

真の信頼性はコンポーネントの特性ではなく、システムの特性です。

これを解決するには、働き方を変える必要があります。

職種はあなたのスキルを表すものであり、責任の範囲を限定するものではありません。

バックエンドエンジニアであれば、ユーザーが確実に決済を行えることに責任があります。モバイルエンジニアであれば、ユーザーの信頼を勝ち取ることに対して責任があります。

チケットをクローズするのは最低限の基準に過ぎません。ユーザーにどのような結果をもたらすか（アウトカム）まで責任を持つことこそが、目指すべき究極の姿です。

出典: https://dev.to/walosha/your-ticket-was-closed-the-user-still-couldnt-pay-14di