このニュースを聞いて、サラリーマン時代を思い出すとともに、開発に携わった社員を気の毒に感じてしまいました。
トラブルが発生して散々なスタートとなり、Ranpaも顧客としてはセブンペイを使いたくないと思いますが、リリースさせた社員の気持ちを考えれば悲しくなります。
想像するに・・・
コンビニ決済の仕組みを詳しく理解できていませんが、恐らく1年以上前から開発してきたとは思いますので、終了により今までの努力が無駄になったということでしょう。
Pay PayやLINE Payなどよりも遅れてスタートされたものの、企画段階であれば同じぐらいに開始されていると思います。
Pay PayやLINE Payのリリース後、セブンイレブンの社内では少しでも早くリリースせよというプレッシャーのかかる状況であったことが想像できます。
プレッシャーのかかる中で社員は厳しいスケジュールをこなし、何とか7月にリリースさせたというところでしょうか。
RanpaはIT担当者ではありませんでしたが、仕組みを作るには各関係部門がプロジェクトにアサインされ参加することになるため、このようなシステム開発を何度も経験してきました。
開発が進んでくると・・・
大まかな要件を決める段階は楽しいものですが、具体化・詳細化してくると色々な問題が出てきます。
例えば、○○の仕様としてコンプラ的に問題ないのか・・・や、複雑化しすぎるのでパターンを絞ったが営業側は納得するのか・・・や、○○すると□□に影響するが、□□の改修はスコープ外だ・・・など。
そうして、コンプラ確認はどの部門がするのか・・・や、営業側への説明はどの部門がするのか・・や、別途予算の稟議はどの部門がするのか・・・といった部門間の仕事の押し付け合いになります。
プロジェクトは部門を横断しているので、それぞれの部門に関係がありますが、「ウチはあまり関係がないので、他のどこかの部門でやってください・・・」といった具合になりがちです。
スケジュールが押す中で、関係者間の人間関係は険悪となり、嫌な思いをするものでした。
要件確認やテストについても
開発する要件やテスト結果などを承認すれば部門側の責任になりますが、スケジュールが厳しくなるとそれらをチェックする時間がどんどん短くなり、休日出勤や残業して穴埋めすることになります。
テストをしていると、要件の漏れや、認識相違が無数に出てきて、「この状態でリリースは無理かもしれない・・・」という感じになってきます。
スケジュールを遅延させることになれば、予算超過となるだけではなく、各方面に影響するので気が重くなるものでした。
100％完全なものとしてのリリース
規模の大きな開発案件の場合、正直なところ100％完全と自信を持ってリリース日を迎えたことはありません。
本番稼動の日は、「今までやれるだけはやった・・・、恐らく細かい障害は発生するだろうが、大きなものだけは出てこないでくれ・・・・」という気持ちで出社していました。
リリース日の昼ぐらいになって大きな問題を聞かなければ、何とか上手く行ったか・・・と感じる時です。
今までの努力が・・・
流石にリリースさせたものが取りやめになった経験は無いのですが、長期に渡って努力してきた末に、問題が起きて終了させるというのは想像以上に辛いことだと思います。
社内ではプロジェクト関係者は戦犯扱いになっているのではないでしょうか。
問題が起こってからは、連日夜遅くまで関係部門を呼んで対応会議をしているはずですが、関係部門は「お前らのせいで夜遅くや休日まで働くことになっているんだぞ・・・」という雰囲気になっていると思います。
その会議ではプロジェクト責任者が連日サンドバック状態になっているでしょう。
本来の障害対応だけでも忙しいのに、関係部門への報告資料を作成する時間も上乗せされます。
また、終了するといっても終了させるための移行プロジェクトを立ち上げる必要があるでしょう。
戦犯扱いなのに、終了させるためのハードルの高い仕事が続ているのだと思います。
セブンペイに関しては、サラリーマン時代に似たような経験をしてきたので、このプロジェクトに関わった人達を本当に気の毒に感じてしまいます。
