「これバグでしょ？」 vs. 「それは仕様です！」（後編）：失敗しない「外資系」パッケージソフトとの付き合い方（2/3 ページ）

[吉丸新一郎（日本ヒューレット・パッカード），ITmedia]

　以前の記事でも触れたように、合法的に取引された製品を、顧客の一方的な都合で返品することはまず無理だと考えていいでしょう。従って、この先もし返品の方向で話が進んだとなれば、メーカー側は本来あるはずの売上が消失し、ユーザー側もプロジェクトにかけたコストや期間、そして返品交渉にかける時間を無駄に消費してしまい（重要な要求は最初に提示する、という教訓は得られるかもしれませんが）、両者にとって不幸な結果となるでしょう。

　この会話には、この他にもパッケージソフトウェアを使用する上で問題となる点がいくつもあります。

自社だけの“特別対応”は通らない

　まず、自社だけに「制限を外すパッチを提供してもらえないか」と個別対応を要求している点です。このソフトウェアの売上がその1社のみで構成されているような場合でもない限り、そのような要求を受けることはまずあり得ないと考えていいでしょう。

　もちろん、ユーザーの要求がメーカー側にとっても製品の魅力を高めることにつながるならば、コストや納期などの要因を踏まえて、その機能が実装されるケースもあります。ただ、それはあくまでメーカー側が自社製品としての責任で判断することであり、ユーザーに委任できる話ではありません。

　次に「私はJavaでプログラミングできますから、この部分のソースを私に送ってくださいよ」というくだりです。一部の例外を除き、商用のパッケージソフトウェアのソースコードは非公開なのが通例で、ソフトウェアの動作からソースコードを逆解析することも、契約で禁止されているケースがほんとんどです。

　プログラムコードやその処理方式は、開発者の知的財産（IP）であり、特許を出願しているものならば、場合によっては法律に抵触します。日本ではアニメやゲームなど、知的財産に対しての理解が深い国だと思いますが、ソフトウェアのコードもそのようなセンシティブな対象との認識が必要でしょう。

　最後は、Aさんの「ソフトウェアへの改善や機能拡張の要求をお受けするための窓口がございまして」に対して、Bさんが「伝えるだけでは意味がない」と考えている点です。これは、実はソフトウェア開発者とユーザーにとって重要な仕組みで、ITILでも「変更管理」として位置付けられています。

ITILにおける「変更管理」の流れのイメージ

　変更管理とは、変更要求を受け付けて、その内容を審議し、実際に変更するかどうかをジャッジするプロセスです。重要なのは、要求された全ての変更が行われるわけではないという点です。さまざまな要因から、その要否や優先度を決定し、客観的で妥当性のある結論を導くことで事業活動を最適化することが目的であり、無作為に製品やサービスが変更されることを防ぎます。

　このプロセスに参加するには、まず要求を行うことがスタートとなります。それをしなければ何も始まりません。