「これはバグではなく仕様です」はネタではなく実際よくある話

パッケージシステムだろうとフルスクラッチのシステムだろうと、不具合と言ってもよいであろうバグが、”仕様”としてまかり通っていることは、日常業務においてもよくある話です。業界内ではある種のギャグのように使われるかもしれませんが、実際にこのような場面は往々にして存在するのです。

お客様が納得すればよし

なぜ本来であればバグとして対応しなければならない不具合が”仕様”としてまかり通っているのかと言うと、システムの納品時にはお客様によって検収が行われるのですが、そこでお客様に納得していただければ丸く収まってしまうからです。極端な言い方をすれば、軽微な不具合を含んでいたとしても「お客様が納得すればよし」ということです。

ただし納品時の検収基準に「〇〇万件のデータ処理が〇〇秒以内で実行しないといけない」といったように、明確な数値で基準が設けられていれば、いくら仕様だと突っぱねたとしても、その数値をクリアしていないとお客様も納得することはありません。

また本来返ってくるべき結果とは違う結果になってしまう計算ミスや、お客様の運用がストップしてしまうなどの重大事故につながる不具合も、もちろんですが仕様として通すことはできません。

仕様として押し通せるのは、あくまでお客様の使い勝手に関わるところ、ということを覚えておいてください。

お客様を納得させるにも代替案は必要不可欠

ただ「これはバグではなく仕様です」と言うだけでは、お客様に納得してもらうのは難しいでしょう。お客様も馬鹿ではありませんので、少しでも使い勝手が良くなるよう、改善をお願いするのは当たり前です。それに無理やり仕様として押し通せたとしても、お客様との関係性も悪化してしまうので気をつけましょう。

仕様として納得いただくには、やはり代替案のようなものを提示しなければなりません。

「ここの機能は少々使い勝手が悪くなっているので、代わりにこの機能を使用して対応しましょう」といったように説明します。業務に支障をきたすような不具合は別ですが、軽微な不具合であれば、お客様との確固たる信頼関係が築かれていれば、たいていは納得いただけるはずです。

いつかは対応することも忘れずに

バグを仕様に置き換えてしまったとしても、お客様の立場からしたら、使い勝手が悪くなっていることには変わりません。SEとしては「手が空いたタイミングで対応します」というように、しっかりとフォローを行いましょう。あくまでバグは懸案事項であり、いつかは対応しなければならないということは忘れてはいけません。

ですが実際には、その対応がいつまで経っても行われず、結局バグが仕様のまま残ってしまうことは多いのですが・・このようにして、バグのような仕様が何年も放置されるという状況が生まれるのでしょう。

制御系や組込み系では通らない

これまでご説明してきたことは、業務系システムで起きる話で、制御系や組込み系では「これは仕様です」は通らないでしょう。

制御系や組込み系は”使い勝手”という概念は業務系に比べて薄く、しっかりと事前の要件を満たすことが求められます。もし不具合などがあれば「これは仕様です」なんて言える余地はなく、商品として世に出回っていれば、数万もの商品がリコールということにもなりかねません。

そのため、業務系システムを構築するエンジニアと、制御系システムを構築するエンジニアでは、若干求められるスキルのようなものが異なってきます。これらのことは「制御・組込み系エンジニアに必要なもの、業務系エンジニアに必要なもの」にてご説明しておりますので、気になる方はどうぞ。

 

おわりに

本来であれば「これはバグではなく仕様です」なんて言葉は言ってはいけませんし、言うことのないように緻密なシステム構築をしなければなりません。ですが開発スケジュールに余裕がなくなってくると、SEとしてはついついバグを”仕様”としたくなるものです。

しかしバグを”仕様”として放置してよいということではなく、軽微なバグだとしても、必ず懸案に挙げていつかは対応するようにしましょう。（多くの現場で対応できていないのが実情ですが・・）