気が利かないベンダーに激怒

8月に入社以来担当している新基幹システムの再構築プロジェクトについて、総合テストを迎えるところまできました。

総合テストを行うにあたり、現行システムからマスタやトランザクションデータを先日移行しました。

特に移行時のデータ不整合エラーも無く、すんなり移行ができたかなと安堵した矢先、移行されたデータを抜粋して検証してみて愕然としました
現行システムと新システムで、トランザクションデータに紐づく請求先コードや契約先コードが全く違うことが判明したのです。

すぐに私はベンダーSEと状況を確認しました。
今回の移行の方法として、ベンダー指定のEXCELシートをもとに、当社でトランザクションデータと請求先・契約先の紐付けを行い、そのシートを入力としてデータが移行されました。
しかし、当社で作成したEXCELシート上の紐付きに誤りがあり、マスタに存在しない請求先・契約先コードが指定されているデータがありました。
そして、マスタに存在しないデータについては、移行プログラムで自動的に別のマスタに紐付けられる仕様になっており、結果として請求先・契約先の送付先住所などが全く違う状態となっていました。

勝手に別のコードに紐付けられ、そのことに気付かないまま本番を迎えた場合、現場に大混乱が起きることは明白です。
私は「マスタに無いコードなのに、なぜ事前の整合性チェックでエラーにしないのか?」と問い詰めました。

ベンダーの回答としては、下記の通りでした。
 ・移行時は、コードがマスタにあるかどうかに関わらずとりえあず取り込む。
 ・移行プログラムで勝手に別のコードに紐付けたデータについては、後で一覧を当社に提供する。
 ・当社でその一覧を確認し、必要に応じて画面から請求先・契約先コードを修正してもらう。

もうね、ハァ!?って感じです。(怒)

一体何のための整合性チェックなのでしょう?
もちろん、入力になったEXCELシートを作成したのは当社ですので、当社に非が無いというつもりはさらさらありません。
ベンダーに渡す前に、もっと入念に確認しなかった当社も悪いのです。

しかし、所詮は人間が作るもの。
完璧に作成できることを前提にされても困ります。

そもそも画面で修正しろって・・・3000件近くあるんですが。(汗)
1件ずつしか更新できない画面構成ですので、データを呼び出してはコードを直して更新!を3000回やれってことですか?
※大して性能も良くないので、最速で操作しても1分間に2件が限界です。

そのベンダーは地方の会社ですので、移行作業のためだけに約1週間東京に滞在して作業をしてくれました。
それは有り難いことなのですが、拠点が地方であるが故に、移行時にエラーとしてその解消に手間取ると、下手すると地方に帰れなくなってしまう恐れがあります。
想像ですが、それを避けるために「とりあえずデータは取り込んどけ!」ってな感じの作りにしたのかもしれません。

仕方が無いので、パッケージ製品ではありますが、トランザクションテーブルのコードを直接一括更新するしかないかと考えました。
DBはOracleで、どのテーブルでどんな情報が管理されているか、おおよそは当たりがついていました。
自分で一括更新用のスクリプトを作成しましたが、念の為、データパッチ実施前にバックアップを取り、かつベンダーにこのテーブルのこの項目を更新するが問題無いか?と確認しました。

ところが・・・テーブルの直接更新は控えてくれとの回答がきました。(あくまで画面から更新してほしいとのこと)
んなことは解っとるわ、ハゲ。(怒)

誰が好き好んで、パッケージのテーブルを直接更新したいなんて言うかっての。
あんたらが何もやってくれないから、こっちで何とかしようとしてるんでしょうが。

それならと、下記の代替案を提示しました。
 ①当社でどのデータのコードをどの値に更新してほしいかを一覧として渡す。
 ②それをもとに一括更新用のスクリプトを作ってほしい。
 ③作ったスクリプトをメールで送ってもらい、パッチの実施を当社で行う。

これなら、地方だろうが関係無く、更新スクリプトもベンダー側が作るから問題無いはず。
ところが・・・「スクリプトの開発が必要なため、費用が発生します。」ときました。

もう、課長と2人で唖然としてしまいました。
スクリプトの開発て・・・私がEXCELの式を使って5分ぐらいでできた作業を、「開発」と言いますか。
(一覧があれば、UPDATE文なんてすぐ作れるじゃないの)

何度も言いますが、あんたらが何もやってくれないから、こっちが色々と対策を考えてるんでしょうが。
本来は、ベンダーであるあなた達が提案してくるべきですよ。

まぁでも、単価も安い地方の会社ですから、「安かろう悪かろう」なのかもしれません。
また、当社の属する業界の特徴として、流通業界や製造業界と異なりパッケージ製品が成熟しておらず、かつ寡占状態なことも要員なのだと思います。

スポンサーリンク


私がベンダーSEとして働いていた頃は流通業界のお客様ばかりでしたが、今回のような対応をとると一発で信頼を失ったでしょう。
むしろ、今回のようにユーザーが作成した資料が間違っていたとしても、「なぜ気付いてくれなかったのか」「常識で考えれば分かるだろう」とお叱りを受けることもありました。
このため、私はいかにお客様が気付いていないミスに気付けるかを常に意識し、手戻りを少なくして信頼を得るようにしてきました。
(私以外にも、流通系のベンダーSEは全体的にそういう意識が高かったように思います。)

これまでがそんな環境で仕事してきましたから、今回のベンダーの対応に非常に憤りを感じました。
ただ、経験上、ベンダーと不仲になって得することは何も無いので、とりあえず私が頑張って3000件を画面で更新することにしました。
(明日から今週一杯かかると思います。。。)

しかし、こんな形でのカルチャーショックがあるとは、ちょっと予想外でした。
これも、当社が安い製品・ベンダーを選定し、かつ無理な値引きをしているからかもしれませんが。

恐らく今後もちょくちょくいざこざがあるかもしれませんが、ベンダーにはあまり期待せずに折衝するようにしようと思います。
(その方がストレスが溜まらない気がしますので)

コメントの投稿

非公開コメント

プロフィール

Author:たみおと
36歳にして社内SEに転職しました。
ベンダーSE・社内SEどちらの方が記事を読んでも、ご参考になる体験談をUPしていきたいと思っていますので、宜しくお願い致します。

ブログランキング
よろしければ、ポチっと一押しお願いします。m(__)m

ブログランキング・にほんブログ村へ
カテゴリ
よく読まれている記事
最新記事
おすすめ書籍
[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

なぜ、システム開発は必ずモメるのか? [ 細川義洋 ]
価格:2160円(税込、送料無料) (2016/11/7時点)



[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

絵で見てわかる RPAの仕組み (絵で見てわかる) [ 西村 泰洋 ]
価格:2786円(税込、送料無料) (2018/7/30時点)



月別アーカイブ
検索フォーム
リンク