「これバグでしょ?」 vs. 「それは仕様です!」(後編):失敗しない「外資系」パッケージソフトとの付き合い方(3/3 ページ)
外資系パッケージソフトの導入で失敗しないための方法を解説する本連載。前回に引き続き、いわゆる仕様とバグの問題を取り上げます。この争い、実は製品を購入してしまったあとでは、ユーザー企業が不利になるケースが多いのです。その理由とは?
また、ソフトウェアの開発にこのプロセスを適用した場合、それがバグの修正と仕様変更のどちらなのかが重要になります。バグの場合、現状が“あるべき姿”ではないので、審議も比較的通りやすいのですが、仕様変更の場合は、その理由から審議する必要があります。
それが「多数の顧客のうち、1人が要求している」だけでは、十分な理由とはなりません。実施の判断を下すためには、多くの顧客からその要望が出されている、市場のトレンドに合うなど、明確なビジネス上のメリットが必要です。
さらに、仕様変更のインパクトに対する分析も慎重に行う必要があります。変更を行ったことで、別の仕様と干渉するのは望ましくありません。
もちろん、バグ修正の場合でもインパクト分析は行われますが、元来の設計に直す作業であるため、影響範囲は局所的になりやすいです。それが仕様変更となると、機能の依存関係の洗い出しなど、より広範囲な分析が必要になるでしょう。仕様を「変更する」というのは、単に見えているものを変えればいい、という簡単な話ではないのです。
バグか仕様か――永遠に続く戦い
いかがでしょうか。同じ「変更」であっても、それがバグなのか仕様なのかで、結果は大きく異なるのです。これを理解していないと、実現可能性の低い事象に多大な労力を使ってしまい、せっかくのフィードバックの機会を失うことになりかねません。
バグか仕様か、判断が難しいケースもありますが、前編から読んでいただいた方であれば、メーカー側が「仕様です」と言うことに対して、バグだと立証するのは、その設計を知りえないユーザーでは難しいことが分かったのではないかと思います。
それ以外は全て自分の「要求仕様」と割り切るのも近道ですが、メーカーも人ですから、合理的な説明をしているか、バグを「仕様」だと変な言い訳をしていないか(ないと信じたいです)、ユーザー側でも見極める目を持つことは必要だと思います。ソフトウェアに限った話ではありませんが……。
さて、次回はいよいよ最後のテーマ、運用の道のりで必ず出てくる「ソフトウェアのバージョンアップ」の話です。お楽しみに。
関連記事
- 「障害の復旧」と「問題解決」を勘違いする人たち
外資系パッケージソフトの導入で失敗しないための方法を解説する本連載。今回からは、ソフトウェア利用の長き道のりである「運用」についてのお話をします。あなたは障害が起こったとき、メーカーへの問い合わせで苦労したことはありませんか? - なぜ、日本の企業は「標準化」ができないのか?
外資系パッケージソフトの導入で失敗しないための方法を解説する本連載。今回は、重要だけれども失敗しやすい「標準化」のお話です。日本のIT運用の現場において、驚くほど進んでいない標準化。その理由はどこにあるのでしょうか。 - 機能比較の「○×表」を信じて大失敗!?
外資系パッケージソフトの導入で失敗しないための方法を解説する本連載。今回紹介するのは製品比較のときに使う「○×表」にまつわる落とし穴。ベンダーもボランティアではなくビジネスである以上、相手の言うことをうのみにするのは避けたいところです。 - そもそも、パッケージソフトとSIを混同してはいけない
読者の皆さんは、パッケージソフトの導入で失敗したことはありませんか? うまく使えばスピード導入につながりますが、一歩間違えるとコストは増えるわ、時間はかかるわで大変なことになります。この連載では、そうならないための注意点やコツを紹介していきます。
関連リンク
Copyright © ITmedia, Inc. All Rights Reserved.