古いバージョンのブラウザーを使用しています。MSN を最適にご利用いただくために、サポートされているバージョンをご使用ください。

「これバグでしょ?」 vs. 「それは仕様です!」(後編)

ITmedia エンタープライズ のロゴ ITmedia エンタープライズ 2017/04/04
「これバグでしょ?」 vs. 「それは仕様です!」(後編): 今回も前回に引き続き、ソフトウェアの仕様とバグをめぐるメーカーとユーザーの攻防をご紹介します © ITmedia エンタープライズ 提供 今回も前回に引き続き、ソフトウェアの仕様とバグをめぐるメーカーとユーザーの攻防をご紹介します

 「それは仕様です」

 ITシステムの導入に携わっていれば、この言葉を聞いたことがある人は多いのではないでしょうか。今回も前回に引き続き、ソフトウェアの仕様とバグをめぐるメーカーとユーザーの攻防をご紹介します。

 前編では、ソフトウェアのサポート窓口Aさんとユーザー企業の運用担当者Bさんが、ソフトウェアの動作について、それがバグなのか仕様なのかとやりとりをしていましたが、メーカー側であるAさんはそのソフトウェアの仕様を説明し、Bさんはその内容を受け入れました……が、一転Bさんが攻勢に出始めます。

●失敗事例15:「修正パッチをいただけませんか?」

ソフトウェアの運用担当者 B:……なるほど。5分以内に設定できないのは仕様との言い分は分かりました。それでは、弊社だけにその制限を外すパッチを提供してもらえませんか。なにか動作上不具合があっても私が責任を持ちますから。

ソフトウェアのサポート窓口 A:残念ながら、当社は個別のお客さま向けのパッチを提供するサービスを行っておりません。ご要望に沿えず申し訳ございません。

B:このソフトウェアのプログラミング言語はJavaですよね? 私はJavaでプログラミングできますから、この部分のソースを私に送ってくださいよ。そしたら私がパッチを作りますから。

A:申し訳ありません、製品のソースコードは公開できないことになっております。

B:分かりました。もともとそういう動作を期待して買ったのですが、出来ないのであれば返品を検討せざるを得ません。別途購買より交渉させていただきます。

A:お待ちください。ご要望に沿えないことは大変申し訳なく存じますが、そのようなソフトウェアへの改善や、機能拡張の要求をお受けする窓口がございまして、そちらをご案内させていただきます。

B:そんな窓口があるんですか。そちらに連絡すると、どれくらい待てば解決してくれるのですか。

A:いえ、そちらの窓口はあくまでお客さまの要望を受け付ける窓口でして、それが実現されるかの確証はなく、それは弊社のソフトウェア開発部門で決定されます。

B:伝えるだけで、それが実現されるか分からないのでは意味がありません。やはり返品を検討せざるを得ないようです。

A:(困ったな。。)承知いたしました。それでは、弊社営業より早急に連絡させますので、そちらをお待ちください。

 読んでいて「融通の利かないメーカーだなぁ」と思われたかもしれません。Bさんも要求を言い出した手前、引けない状況になってしまったのだと思われますが、私の経験上、俯瞰的な視点で冷静に話を重ねれば、今回のような、製品のごく一部の機能が原因で、本当に返品されるステージまで話を進むことはまずありません。

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

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

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

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

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

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

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

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

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

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

 また、ソフトウェアの開発にこのプロセスを適用した場合、それがバグの修正と仕様変更のどちらなのかが重要になります。バグの場合、現状が“あるべき姿”でないので、審議も比較的通りやすいですが、仕様変更の場合は、その理由から審議する必要があります。

 それが「多数の顧客のうち、1人が要求している」だけでは、十分な理由とはなりません。実施の判断を下すためには、多くの顧客からその要望が出されている、市場のトレンドに合うなど、明確なビジネス上のメリットが必要です。

 さらに、仕様変更のインパクトに対する分析も慎重に行う必要があります。変更を行ったことで、別の仕様と干渉するのは望ましくありません。

 もちろん、バグ修正の場合でもインパクト分析は行われますが、元来の設計に直す作業であるため、影響範囲は局所的になりやすいです。それが仕様変更となると、機能の依存関係の洗い出しなど、より広範囲な分析が必要になるでしょう。仕様を「変更する」というのは、単に見えているものを変えればいい、という簡単な話ではないのです。

●バグか仕様か――永遠に続く戦い

 いかがでしょうか。同じ「変更」であっても、それがバグなのか仕様なのかで、結果は大きく異なるのです。これを理解していないと、実現可能性の低い事象に多大な労力を使ってしまったり、せっかくのフィードバックの機会を失うことになりかねません。

 バグか仕様か、判断が難しいケースもありますが、前編から読んでいただいた方であれば、メーカー側が「仕様です」と言うことに対して、バグだと立証するのは、その設計を知りえないユーザーでは難しいことが分かったのではないかと思います。

 それ以外は全て自分の「要求仕様」と割り切るのも近道ですが、メーカーも人ですから、合理的な説明をしているか、バグを「仕様」だと変な言い訳をしていないか(ないと信じたいです)、ユーザー側でも見極める目を持つことは必要だと思います。ソフトウェアに限った話ではありませんが……。

 さて、次回はいよいよ最後のテーマ、運用の道のりで必ず出てくる「ソフトウェアのバージョンアップ」の話です。お楽しみに。

ITmedia エンタープライズの関連記事

image beaconimage beaconimage beacon