「これバグでしょ?」 vs. 「それは仕様です!」(前編):失敗しない「外資系」パッケージソフトとの付き合い方(1/2 ページ)
外資系パッケージソフトの導入で失敗しないための方法を解説する本連載。読者の皆さんも、一度は「それは仕様です」という悪しき“魔法”の言葉を聞いたことはありますよね。ともすれば、トラブルに発展しがちなこの状況はなぜ生まれるのでしょうか。
「バグのないプログラムは存在しないが、デバッグの不可能なプログラムもまた存在しない。違うか?」
このせりふは、とあるSF映画の冒頭の一節です。アニメが好きな方ならピンと来るかもしれませんね。今回取り上げるのはソフトウェアのバグについての話です。
この言葉は、ストーリー上の重要なテーマを暗示しているのですが、ソフトウェアが自分の思い通りに動かなかったとき、それがバグなのか、それとも仕様なのかという問題は、いつもユーザーが(そしてメーカーも)頭を悩ませる問題です。皆さんも次のような状況で困ったことはありませんか?
失敗事例14:ユーザーはバグだと思っているが、メーカーは「仕様」の一点張り
ソフトウェアのサポート窓口 A:はい、こちらはXXソフトウェアのサポート窓口です。ご用件をお聞かせいただけますか。
ソフトウェアの運用担当者 B:先日連絡した、xxの実行間隔が5分より短く設定しても、それより短くならない件ですが、原因は分かりましたか?
A:はい、さきほど開発元より回答がありまして、5分より短くできないのは仕様とのことです。
B:それは困ります。どうしても間隔を1分にしないと、うちの会社がお客さまに提供するサービスとの整合性が取れないのです。1分で設定したときも特にエラーにはなりませんし、入力した値で動作しないのはバグではないのですか?
A:いえ、ソフトウェアのコードを確認したのですが、5分以下には設定できないよう、制御されていました。ただ、確かに5分以下の時間が入力可能なのは誤解を招くと思いますので、今後のバージョンで入力制限を検討するとのことです。
B:いや、私がお願いしたいのはそういうことではなく、1分で指定できるようにしてほしいのです。その制御を外すだけでできそうじゃないですか。それに、ユーザーガイドのどこにも、そんな制限があるなんて書いてないし、バグとしか思えないのですが。
A:恐れながら、本ソフトウェアの設計上、5分以下の間隔での動作は想定されておらず、製品コンセプトからも外れた使い方となってしまいます。マニュアルについては不親切な点があったことをおわびいたしますが、コンセプトガイドの方では、本製品はそのような短い間隔での処理にそぐわない旨を記載しております。ご了承いただけませんでしょうか。
B:なるほど、そちらの言い分は分かりました。それでは……
今回の例は、多少ユーザー側に分がある内容でしたが、このようなグレーな話はいくらでもあります。「できないなんて聞いてない」「できるなんて言ってない」と終わりのない“水掛け論”になってしまうケースも少なくありません。
ユーザー側は実現してほしい機能(5分以下に設定できるようにしてほしい)を明確に伝えているし、修正箇所も特定できています。メーカー側はなぜこれを「仕様」だとして、さらにユーザーの意図にそぐわない修正を加えようとしているのでしょうか。
関連記事
- 「障害の復旧」と「問題解決」を勘違いする人たち
外資系パッケージソフトの導入で失敗しないための方法を解説する本連載。今回からは、ソフトウェア利用の長き道のりである「運用」についてのお話をします。あなたは障害が起こったとき、メーカーへの問い合わせで苦労したことはありませんか? - なぜ、日本の企業は「標準化」ができないのか?
外資系パッケージソフトの導入で失敗しないための方法を解説する本連載。今回は、重要だけれども失敗しやすい「標準化」のお話です。日本のIT運用の現場において、驚くほど進んでいない標準化。その理由はどこにあるのでしょうか。 - 機能比較の「○×表」を信じて大失敗!?
外資系パッケージソフトの導入で失敗しないための方法を解説する本連載。今回紹介するのは製品比較のときに使う「○×表」にまつわる落とし穴。ベンダーもボランティアではなくビジネスである以上、相手の言うことをうのみにするのは避けたいところです。 - そもそも、パッケージソフトとSIを混同してはいけない
読者の皆さんは、パッケージソフトの導入で失敗したことはありませんか? うまく使えばスピード導入につながりますが、一歩間違えるとコストは増えるわ、時間はかかるわで大変なことになります。この連載では、そうならないための注意点やコツを紹介していきます。
Copyright © ITmedia, Inc. All Rights Reserved.