前回は，ソフトのリリース予定を前倒しできるか否かの交渉で使える英語を紹介しました。今回は，バグ改修を要請する交渉で役に立ちそうなフレーズを拾ってみます。

　一般に，ソフトのリリースは，年2回とか3カ月に1回とかいうように，リリース時期を決めているタイプ（time-based release）と，開発の進捗状況に応じてリリースされるタイプの2通りが主流です。

Our software release is now time-based. This improves predictability. But if the quality of a feature scheduled for that release does not meet our criteria, that feature will be postponed until the following release.

（弊社のソフトウエアは時期を決めてリリースされるようになりました。これによって，いつリリースされるのかという予測がしやすくなります。しかし，機能追加が予定されていても，その品質が合格基準に満たない場合は，その機能追加は次回のリリースまで遅らせることになります）

リリース後のバグ改修要請は簡単ではない

　日本の企業では，ソフトをアップグレードをするための計画保守も容易ではありません。ユーザーとの事前調整やアップグレードのための工事計画をかなり前から始めなければならないため，いつ次のバージョンがリリースされるかを予測できるようになるのは大きなメリットです。

　開発側も開発工程を完了し，QA工程で品質を確認した上でリリースするわけですが，導入側（ユーザー）はサービスインする前に必ず検証を行います。そしてこの検証過程で必ずと言っていいほど，「バグ」が見つかるのです。

　なぜもっと徹底した品質管理をしないのかという憤りを抑えながらも，導入側は開発側に対してバグ報告をすることになります。どのバグも導入側にとってはクリチカルバグですから，展開前にバグフィックスを出してもらい，それを再度検証して･･･と当たり前のように考えます。

　ところが，開発側はいったんリリースするとプロジェクトチームを解散し，そのリソースを他のプロジェクトへ回してしまいますので，リリース後のバグ対応は開発中に見つかったバグとは扱いが異なってきます。顧客から報告を受けたバグは，通常，サポート部隊がまず再現し，開発部隊に改修を要請します。根本原因解析（Root Cause Analysis）はたいてい開発担当が行います。

　開発担当にとっては，新機能やエンハンスが主な業務ですから，バグのRCAは追加作業です。リリース前であればテストエンジニアやQAエンジニアも割り当てられていますが，リリース後は「プロジェクトリソースはもう存在しない」ことをユーザーは改めて認識しておく必要があります。特に開発会社の規模が小さい場合，計画されているプロジェクト（次期リリースのための開発）にRCAを割り込ませることはよほどの理由が必要となるのです。

　バグだと思った異常動作が実は仕様であり，ユーザーの運用環境に依存した問題である場合も少なくありません。異常動作，イベントシーケンス，再現条件は，第三者が読んで正しく理解できるように，明確にできるだけ詳しく説明しましょう。このときの英語力の差が，その後の工程を大きく左右することになります。

　リリースしてしまったソフトに対しては，開発側はバグの排除よりも，そのバグが商用環境にどれだけ影響を与えるかで改修の優先度を決める──これがアメリカ企業の常です。言い換えれば，異常動作の発生確率，発生頻度，サービスへの影響（障害の度合い），運用側での対応措置（workaround）の有無などを基準に，いつパッチを出すかを決めるのです。

　「展開前に報告したバグは全て排除してもらえる」と考えがちな日本企業と，米国企業との間に大きなギャップが発生するのはこの点です。

　「バグはフィックスする。しかしそのフィックスは計画外リリースではなく，次のメンテナンス・リリースに実装する」。開発側はこのような回答を用意してきます。ですからユーザーは，次のメンテナンス・リリースまでの期間，運用での対応によって乗り切れるのか，それともそのバグが残る限り今のバージョンの展開は中止するのか，いずれかを判断しなければなりません。

　もうひとつ，常にメジャーリリースにアップグレードすることを前提としたサポートになっているか，それとも，メジャーリリースの世代をまたいだアップグレードもサポートしているかを，ユーザーは考慮すべきです。後者の場合，何世代またいだバージョンアップをサポートしているかをあらかじめ確認しておくべきでしょう。開発側とユーザー側の思惑の差が大きいバージョンアップに関しては，その詳細を保守契約の中に盛り込んでおくべきです。