こんにちは、Hです。
先月、生まれて初めてインフルエンザにかかりました。
周りの人の話を聞く限り、とても流行しているように思えたのですが
現場の中ではなんと私一人。。。
健康管理について人一倍気を付けないといけない立場なのですが、、、
鋭意反省中です。
さて、少し前の話なのですが、あるサービスの機能において不具合が発生したことがありました。
その不具合はシステムとしての動きは問題なかったのですが、
サービスの利用に当たって同意する「サービス利用規約」の一文によって不具合となりました。
表向きはとても簡単な改修だったのですが、それなりに影響度の高い不具合になり
同じような轍を踏まないためにも差支えない範囲で記載してみようと思います。
サービスの概要と開発要件
このサービスでは複数の商品を継続積み立てして購入できるサービスでした。
例えば商品A・B・Cといったように複数の商品を取り扱っており、また各商品で購入する金額を設定できるようになっています。
今まではサービスの性質上、「サービス利用規約」に毎年1回同意をいただいており、各商品の設定も再度「有効化」する必要がありました。
しかしながらサービスの利便性向上や上記の背景となっていた制約が取れたことで
今後は1度同意をもらったら、商品の設定を有効化すると同時に翌年以降も
その設定を「有効」にして引き継いでいくという仕様に変えることとなりました。
この「サービス利用規約」なのですが、実はサービスを申し込むときに同意するのではなく
商品の積み立て設定の途中で同意もらう遷移になっていました。
例えば商品Aの積立金額を毎月「10,000円」とした場合に、登録直前の確認画面で同意していない場合は
「サービス利用規約」の同意画面が挟まれるといった動きです。
一度、同意すればほかの商品の設定時には表示されなくなります。
開発側に渡された「開発要件」でも新しい「サービス利用規約」に同意した場合は
設定を有効にして翌年以降も引き継いでほしいという1ページぐらいの資料でした。
その年の秋ごろに「サービス利用規約」を差し替えて、その後ユーザは同意すると
各商品の設定内容も有効となり、今後はユーザが設定を変更しない限りは継続して積み立てされるようになりました。
サービスとしての売上も向上し、システムも安定稼働していて、「万事目出たし」となる予定でしたが
そうは問屋がおろしませんでした。
ここまでの内容だけではどんな不具合が起きたかはわからないと思いますが、
みなさんの今までの経験上でどんなことを仕様として確認すべきだと思いましたか？
どんな不具合が発生したのか？
この開発を終えた翌年、ユーザからサービスに関する問い合わせが入りました。
その内容について仕様検討メンバーとMTGをしたのですが、そのときに「あれ？話がかみ合わないな」と思ったのがきっかけです。
今回の開発案件、開発側である私たちは以下のようにとらえていました。
・「サービス利用規約」に同意したユーザは各商品の設定を「有効化」する。
しかしながら仕様検討メンバーの方は下記のようにとらえていました。
・「サービス利用規約」に同意しても、同意時に設定した商品以外は「有効化」してはいけない。
ただし前年度で同意した場合は各商品の設定を翌年度以降も「有効」にした状態にしてほしい。
最初この話が上がって、関係者集めてどちらが正しい仕様なんだろう？という話になりました。
「サービス利用規約」は商品ごとに同意をもらうわけではなく、サービスで一度もらうのだから
開発側の見解で問題ないのではないか？というのが概ねの意見でした。
しかしながら古い「サービス利用規約」の中に「設定した内容はその年末で無効になる」という一文がありました。
そのためリリースした年に同意したのであれば、各商品の設定を「有効」にして良かったのですが
その翌年で同意した場合は設定した商品しか「有効」にしてはいけなかったのです。
何故ならその前の年で設定内容は「無効」になっているからです。
もし新規開発だったら、どう分析したか？
ではもしこれが改修ではなく、新規開発だとしたらどうしていたでしょうか？
おそらくですが下記のように設定と購入のパターン表を作成して、
仕様の認識齟齬を起こさないようにするのではないでしょうか？
最初から完全なパターン表出なかったとしても、仕様を詰めていく中で今回のケースについても
洗い出しをできたのではないかと思います。
簡単な改修という思い込みが一番の不具合原因
この不具合が出た開発では期間もそれほどない中で、要件をシンプルにするための取り組みもありました。
結果、新しい「サービス利用規約」に同意したら設定を有効にするといった仕様になりました。
そして何より「これならすぐ改修できそうですね」と関係者間で思い込みがされました。
今回はその思い込みが招いた不具合だと思います。
特に我々プロジェクトマネージャはみんなが「簡単だ」と思っているときが
一番のリスクであるということを肝に銘じないといけないですね。
