「これバグでしょ?」 vs. 「それは仕様です!」(後編):失敗しない「外資系」パッケージソフトとの付き合い方(2/3 ページ)
外資系パッケージソフトの導入で失敗しないための方法を解説する本連載。前回に引き続き、いわゆる仕様とバグの問題を取り上げます。この争い、実は製品を購入してしまったあとでは、ユーザー企業が不利になるケースが多いのです。その理由とは?
以前の記事でも触れたように、合法的に取引された製品を、顧客の一方的な都合で返品することはまず無理だと考えていいでしょう。従って、この先もし返品の方向で話が進んだとなれば、メーカー側は本来あるはずの売上が消失し、ユーザー側もプロジェクトにかけたコストや期間、そして返品交渉にかける時間を無駄に消費してしまい(重要な要求は最初に提示する、という教訓は得られるかもしれませんが)、両者にとって不幸な結果となるでしょう。
この会話には、この他にもパッケージソフトウェアを使用する上で問題となる点がいくつもあります。
自社だけの“特別対応”は通らない
まず、自社だけに「制限を外すパッチを提供してもらえないか」と個別対応を要求している点です。このソフトウェアの売上がその1社のみで構成されているような場合でもない限り、そのような要求を受けることはまずあり得ないと考えていいでしょう。
もちろん、ユーザーの要求がメーカー側にとっても製品の魅力を高めることにつながるならば、コストや納期などの要因を踏まえて、その機能が実装されるケースもあります。ただ、それはあくまでメーカー側が自社製品としての責任で判断することであり、ユーザーに委任できる話ではありません。
次に「私はJavaでプログラミングできますから、この部分のソースを私に送ってくださいよ」というくだりです。一部の例外を除き、商用のパッケージソフトウェアのソースコードは非公開なのが通例で、ソフトウェアの動作からソースコードを逆解析することも、契約で禁止されているケースがほんとんどです。
プログラムコードやその処理方式は、開発者の知的財産(IP)であり、特許を出願しているものならば、場合によっては法律に抵触します。日本ではアニメやゲームなど、知的財産に対しての理解が深い国だと思いますが、ソフトウェアのコードもそのようなセンシティブな対象との認識が必要でしょう。
最後は、Aさんの「ソフトウェアへの改善や機能拡張の要求をお受けするための窓口がございまして」に対して、Bさんが「伝えるだけでは意味がない」と考えている点です。これは、実はソフトウェア開発者とユーザーにとって重要な仕組みで、ITILでも「変更管理」として位置付けられています。
変更管理とは、変更要求を受け付けて、その内容を審議し、実際に変更するかどうかをジャッジするプロセスです。重要なのは、要求された全ての変更が行われるわけではないという点です。さまざまな要因から、その要否や優先度を決定し、客観的で妥当性のある結論を導くことで事業活動を最適化することが目的であり、無作為に製品やサービスが変更されることを防ぎます。
このプロセスに参加するには、まず要求を行うことがスタートとなります。それをしなければ何も始まりません。
関連記事
- 「障害の復旧」と「問題解決」を勘違いする人たち
外資系パッケージソフトの導入で失敗しないための方法を解説する本連載。今回からは、ソフトウェア利用の長き道のりである「運用」についてのお話をします。あなたは障害が起こったとき、メーカーへの問い合わせで苦労したことはありませんか? - なぜ、日本の企業は「標準化」ができないのか?
外資系パッケージソフトの導入で失敗しないための方法を解説する本連載。今回は、重要だけれども失敗しやすい「標準化」のお話です。日本のIT運用の現場において、驚くほど進んでいない標準化。その理由はどこにあるのでしょうか。 - 機能比較の「○×表」を信じて大失敗!?
外資系パッケージソフトの導入で失敗しないための方法を解説する本連載。今回紹介するのは製品比較のときに使う「○×表」にまつわる落とし穴。ベンダーもボランティアではなくビジネスである以上、相手の言うことをうのみにするのは避けたいところです。 - そもそも、パッケージソフトとSIを混同してはいけない
読者の皆さんは、パッケージソフトの導入で失敗したことはありませんか? うまく使えばスピード導入につながりますが、一歩間違えるとコストは増えるわ、時間はかかるわで大変なことになります。この連載では、そうならないための注意点やコツを紹介していきます。
Copyright © ITmedia, Inc. All Rights Reserved.