リリース判定基準・保守の体制と契約は明確になっているか
開発プロセスでは保守の体制と保守契約の状況も確認する
この記事では、リリース判定でのプロセス品質の判定のためにグータラ親父が確認していた７つの項目のうち、保守の体制と保守契約の状況 について紹介しています。他の6項目（開発計画の立案、ソフトウエアの設計、実装テスト計画の立案、懸案やリスクの管理、ベースライン管理、ゲートプロセスの実施状況）については、前の記事や後の記事で紹介していますのでそちらをご覧ください。
６．保守の体制と保守契約の状況
ここまでの記事見てきたソフト開発プロセスは、ソフトをリリースする時までの管理プロセスの重要な部分です。ソフトをリリースしてそれで終わりならこれだけで良いのですが、ソフトをリリースすると通常はそのソフトに対する保守が発生します。
ソフトの保守とは、もう少し言葉を足すと出荷したソフトに対する保守サービスの提供です。具体的には、バグ修正を行ったソフトのリリースと機能追加を行ったソフトのリリースの２つが、ソフトの保守サービスです。保守サービスの提供は、無償の場合もあれば有償の場合もあります。
そして、ソフトを市場にリリースする時には、どんな内容の保守サービスをどの程度の期間に渡って、有償か無償のどちらで市場に提供するのか、という保守サービスの概要が決まっている必要があります。
これが決まっていないままリリースすると、ソフトを受け取ったユーザは、そのソフトを安心して使えないですね。機能改善の保守サービスが無いのはまあ諦めも付きますが、、バグ修正版のソフトのリリースが無いというのは、ユーザとしては困りものです。
保守サービスの提供もソフトの品質の大切な一部分
保守サービスの提供はソフトそのものの提供と一体化した大切なものです。 ですので、ソフトのリリース判定の時には、ソフトの保守サービスが具体的に計画されているかどうかという事も、確認しておく必要があります。ソフトそのものの品質では無いのですが、そのソフトのライフサイクルに対する品質の１項目として保守サービスの品質を確認する、と考えると判り易いかもしれません。
では、保守サービスの品質とはどんな項目をどんな観点で確認すれば良いでしょうか？ グータラ親父は以下のよう項目について、リリースの時点で決まっている内容を確認して、保守サービスの品質を判定していました。
- 保守サービスの定義
- 不具合発生時の責任分界点
- 不具合発生時の一次対応と二次方法
- 顧客との保守契約の有無
- 社内と開発委託先の保守体制の維持計画
保守サービスの定義
まずは市場にどんな保守サービスを提供するのかが、明確になっている必要があります。 不具合修正版ソフトの提供、機能改善版ソフトの提供、不具合発生時の一次切り分けの実施や技術協力など、どんな保守サービスを提供するのかは、ソフトリリースと一体で決まっているはずです。
決まっている保守サービス内容が、何等かの書類として明示され、会社として承認されているか、その内容は客先と合意されているか？ という点がまず第一に確認する必要のある項目です。
不具合発生時の責任分界点
次に、市場で不具合が発生した場合には、責任分界点が明確になっている事が必要です。保守サービスのうちの不具合対応は、自社のソフトに不具合があった時には対応する必要がありますが、他社のソフトの不具合だった場合には、自社では対応できませんん。
自社のソフト単独で動作しているのなら、責任分界点を考える必要は無いのですが、他社の製品やソフトと連携して動作している場合には、何等かのインターフェースを介して連携しているでしょうから、そのインターフェースを境にして、自社と他社の責任分界点が存在します。
そして、市場で不具合が発生した時には、不具合の原因がその責任分界点の自社側にあるのか他社側にあるのかを客観的に判断する手段が必要になります。 リリース判定会議の時点では、責任分界点が明確で、責任分界点のどちら側なのかを判断する方法が明確になっているか、という点を注意して確認します。
不具合発生時の一次対応と二次対応
市場で不具合が発生した場合には、まずはユーザからの不具合申告や相談を受け付ける一次対応が発生します。 次に不具合が自社に原因があると判明したら、必要に応じて不具合原因の調査や不具合の修正、修正効果の確認等の二次対応が発生します。
この、一次対応を二次対応をどの部門がどんな方法で実施するのか？ が具体的に決まっているかどうかを、リリース判定会議の時点で確認します。
顧客との保守契約の有無
ソフト保守サービスは、有償サービスとして提供される場合が多くその場合には保守契約書が客先と取り交わされます。ある程度販売が継続している製品や市場なら既存の製品で利用している保守契約が見本として存在するので、ソフトのリリース時に保守契約書がまだ無いという事態は起きないと思います。
しかし、初めての製品リリースだったり、初めての市場への製品のリリースだった場合など、社内での保守契約書の準備が間に合っていない場合もあり得ます。そのような事態になっていないか、もし保守契約書がまだ確定していないのならいつ頃までに確定するのか？ という事を、リリース審査の時点え確認しておきます。
社内と開発委託先の保守体制の維持計画
最後の確認項目は保守体制の維持計画がちゃんと出来ているかという点です。維持計画とは要するに、保守サービスを提供するために必要な機材と人員を確保するための予算計画の事です。
保守サービスとして、不具修正版のソフトの提供を行わないのなら、必要な保守用機材は故障した製品の代替品を提供するための代替品の在庫だけです。それ以外に必要になるのは、在庫品を保管する倉庫の費用や代替品の輸送費とそれらを管理する人件費程度です。
しかし、保守サービスとして不具合修正版のソフトの提供を行うのなら、不具合原因を調査するために不具合の状況を再現する環境、不具合箇所のソフトを修正するソフト開発環境と、これらの調査・不具合改修版ソフトの作成を実行するソフトエンジニアが必要となり、エンジニアの人件費も必要になります。
保守サービスを提供する期間は、これらの保守サービスを提供するために必要な費用を何等かの方法で捻出する必要があるのですが、費用の捻出計画はありますか？ という観点の確認がリリース時に必要です。