【からふるわーくす】PM編漫画09話「データの迷宮、繋がらない片思い」

想定プロジェクト

私はWeb制作会社のPMとして、地域のベーカリーのWebサイトに、
季節限定商品の予約機能を追加するプロジェクトを担当した。

予約者が氏名と個数を入力すると、予約情報をデータベースへ保存するとともに、
店舗へ通知メールを送信する仕組みである。
主要な関係者は、顧客であるベーカリーの店主、当社の営業担当者、
実務担当者及びPMである私であった。

顧客からの依頼は販売開始前日にあり、
翌朝から予約受付を開始するという短納期であった。

設問ア 回答例

私はWeb制作会社のPMとして、既存顧客であるベーカリーのWebサイトに、
季節限定商品の予約機能を追加するプロジェクトを担当した。
利用者が氏名と予約個数をフォームへ入力すると、
予約情報をデータベースへ保存し、店舗のメールアドレスへ通知する仕組みである。
主要な関係者は、ベーカリーの店主、当社の営業担当者、実務担当者及びPMである私であった。

顧客からの依頼は販売開始前日にあり、翌朝から予約受付を開始する必要があった。
このため開発期間が短かった上、作業中に別顧客のWebサイトで障害が発生し、
実務担当者がその復旧にも対応した。
その結果、予約機能が完成したのは22時を過ぎていた。

本来は店舗のメールアドレスを通知先として、
店舗側で受信できるところまで確認する予定であった。
しかし深夜に顧客へ確認を依頼することを避け、
私のメールアドレスを仮の通知先としてテストした。
フォーム送信、データベースへの保存及び私へのメール到着は正常であった。
その後、通知先を店舗の本番用メールアドレスへ変更した。

したがって、この時点で確認できていたのは仮の通知先を使用した場合の動作であり、
本番用アドレスへ変更した後に店舗で通知を受信できるかどうかは未確認であった。

設問イ 回答例

私はPMとして、本来であれば仮の通知先でのテスト結果と、
本番用の通知先での確認を区別して管理すべきであった。
仮の通知先で正常に動作していても、その後に通知先を変更している以上、
変更した部分は新たな確認対象となるからである。
そのため、本番用アドレスへの変更を未確認事項として明示し、
翌朝の予約受付開始前に店舗側で通知メールを受信できることを確認してから、
本番移行を完了とすべきであった。

しかし実際には、仮の通知先でフォーム、データベース及びメール送信が正常に動作したことで安心し、
本番用アドレスへの変更後も一連のテストが完了したものとして扱ってしまった。
その結果、翌朝に予約受付を開始した後、
店舗から予約通知メールが一通も届いていないとの連絡を受けた。

この時点では、通知だけの問題なのか、
予約情報そのものが正常に保存されていないのか判断できなかった。
私は、原因が判明するまで予約を受け付け続けると影響が拡大する可能性があると判断した。
そこで、原因究明より先に影響拡大を防止することを優先し、
店主に予約受付を一時停止して、Webサイト及びSNSで利用者へその旨を告知してもらった。

その間に、私は実務担当者とともに影響範囲と原因の調査を進めた。
まず、予約データがデータベースへ正常に保存されているか、
利用者側の処理が正常に完了しているか、
店舗への通知処理のどこで問題が生じているかを順に確認した。
その結果、予約データは保存されており、
問題は店舗への通知部分に限定されていることが分かった。

さらに設定を確認したところ、
本番用の通知先へ変更した際の入力誤りが原因であることを特定した。
そこで設定を修正するとともに、
既に受け付けた予約情報を顧客へ共有し、業務への影響を回復させた。

ただし、原因を修正したことだけをもって復旧完了とはしなかった。
本番用の設定で再度一連の動作を確認し、
店舗側でも通知を正常に受信できることを確認した。
その結果を店主へ報告した上で、予約受付を再開した。

この対応では、問題発生時に原因究明を最初の目的とするのではなく、
まず影響拡大を防止し、その状態を確保した上で、
影響範囲の確認、原因特定、復旧、本番確認、再開の順に進めることを重視した。
原因が不明な段階でも、被害が広がる可能性に対して実施できる対応はあると判断したためである。

設問ウ 回答例

対応の結果、データベースには受付開始後の予約情報が全て残っていたため、
保存済みの予約を店舗へ共有することができた。
また、本番用メールアドレスを修正して店舗での受信確認を行った後に受付を再開し、
予定していた商品の予約販売を継続できた。
利用者に予約をやり直してもらう必要もなかった。

一方、私は結果だけを見て対応が成功したとは評価しなかった。
今回の直接的な原因はメールアドレスの入力ミスであったが、
それだけを再発防止の対象にすると、
URLや接続先など別の設定変更で同様の問題を起こす可能性があると考えたからである。

私は、本質的な問題は、本番と異なる条件で行ったテストの結果を、
その後に設定を変更した本番状態にまで適用し、
未確認事項を確認済みとして扱ったことにあると評価した。

そこで、予定した確認を実施できなかった場合は、
その項目を未確認事項として明示し、完了扱いにしないこととした。
また、テスト後にメールアドレス、URL、接続先、環境変数などを変更した場合には、
変更箇所を新たな確認対象として扱い、
変更後の状態で必要な動作確認を行うこととした。

特に短納期や突発対応によって当日中に確認できない場合には、
「仮の条件では確認済み」「本番条件では未確認」という状態を区別して残し、
本番公開前に未確認事項を解消する運用とした。

この改善によって、テストを実施したという事実だけで完了と判断するのではなく、
何を、どの条件で確認したのかをPMが把握できるようにした。
私は今回の経験から、確認できなかったこと自体を問題とするのではなく、
未確認であることを見失わず、確認できるまで管理することが重要であると評価した。