重大クレームが大満足に変わるまで(1)

この記事は約2分で読めます。
記事内に広告が含まれています。

サポートエンジニアという役職は臨機応変に立ち振る舞うことが求められ、さらに状況によって対応を変えていかなければならないので、マニュアルのようなものは存在しません。また、サポート対応はシステムの場合ですとその企業の根幹機密に触れることもあるので、文章として発表しづらいという実情もあります。とはいえ、やはりある程度テンプレートになる対応というのは存在していますし、各職種に様々な技術論経験談がある中でサポートエンジニアにはそうしたことがほとんど存在していないことから表現に気をつけながらまとめておくということも大事だと思っておりました。

そこで今回から数回にわたって、私が経験した重大クレームの実例を書ける範囲で順番に書いていきます。何かの参考になれば幸いです。

その案件はある大きなシステムの一部分を勤務先で担当しており、その部分は全体を見てもかなり肝となる部分です。開発時点から全体的に仕様の詰めが甘く、いくつも決まっていない内容が存在していました。決まっていない仕様については、開発を止める、あるいは誓約や条件を文章で交換しておくべきでしたが、プロジェクトマネジャーの仕事がずさんで、なあなあのまま進めてしまっている状況でした。プログラマ側も当然のことながら仕様が決まっていないので適当な条件のもとにプログラムを組むわけですが、プログラムの構文ミスが多々存在していて、社内の検証環境では問題がなくても何か問題が発生したときに致命的なエラーが発生して、システム自体が止まる可能性を内包した状況でした。

こういう状況ですからリリース直前くらいから上手く動作しないという状況が発生し、その対応に追われることになります。この時点で抜本的に体制を見直していればよかったのですが、出てきた問題だけを修正していくという泥縄状態です。当然、一箇所修正するとほかで問題が起こったときに予期しないエラーで止まるということの繰り返しが発生しました。それでも通常通りならば大丈夫ということでそのシステムはとりあえずリリースされます。

(続く)

タイトルとURLをコピーしました