運用保守契約の重要性
これまで,システム設計・開発業務委託契約に比べて,システム運用・保守業務委託契約については,注目されることが少なかったように思います。
それは,通常は,開発を担当したベンダが運用・保守も引き続いて受託することが多く,ベンダの選定作業があまり真剣に行われていなかったことも理由のひとつかもしれません。
しかし,運用・保守業務委託契約の期間は,5年,10年にわたり,開発に比べて長くなります。
支払われる業務委託料も,総額で見れば,開発を上回るかもしれません。
また,開発途中でトラブルが生じて中断・延期したとしても,ユーザのビジネスは継続することが可能であるのに対し,運用・保守でのトラブルによってシステムが停止してしまうと,
ビジネスが停止し,ユーザから莫大な額の損害賠償を請求されるということも考えられます。
したがって,運用・保守業務委託契約の締結にあたっては,開発の場合以上に注意して行わなければならないといっても過言ではありません。
ポイント1 運用・保守でのトラブルは,ビジネスを止めてしまうおそれがあり,開発以上に契約に注意しなければならない
では,運用・保守業務委託契約を締結する場合に,どこに注意すべきでしょうか。ここでは,もっとも重要な「対象業務範囲を特定する」「サービスレベルを規定する」という2点についてみていきます。
1. 対象業務範囲を特定する
運用や保守というのは多義的な用語です。
バッチ処理の動作監視,障害復旧作業,ユーザに対するヘルプデスク業務,ウィルス除去などのセキュリティ業務,バックアップの実施やメディアの管理,処理性能の監視と改善など,いろいろな業務が含まれます。
ユーザからの改善要望に対してアプリケーションを開発する業務も含まれていることがあります。
そこで,
受託する業務に何が含まれるのか,ということを確定しなければなりません。
よく見られるケースとしては,エンジニアとして誰をアサインするか,何人アサインするかという合意はあっても,彼らが何をするのかという合意があいまいなことがあります。
ユーザからみれば,優秀なエンジニアが確保できればそれで安心できるかもしれませんが,委託する業務が明らかでないと,後になってから作業範囲について争いが生じる危険があります。
複数のベンダに運用・保守業務が委託される場合,ベンダ間の境界も明確にしておかなければ,トラブルが生じた場合の責任範囲も不明確になってしまいます。
契約書を作成する際には,たとえば,
| 第1条 ユーザは,ベンダに対し,運用・保守業務として,別紙1の作業内容に記載された業務(以下,「本件業務」といいます。)の提供を委託し,ベンダはこれを受託した。 |
などと書き,別紙1として,サービス内容の一覧を添付する方法が考えられます。さらに,各サービスについて,具体的な作業内容を記載する必要があるでしょう。
ポイント2 運用・保守と一口に言っても,対象となる作業はいろいろあり,ユーザとベンダとの間で作業範囲の意識あわせをしなければならない
2. サービスレベルを規定する
次に,1で定めた各サービスにつき,ベンダはどの程度のサービスレベル(例えば,ハードウェア故障時の平均復旧時間など)を保証するのかを定めなければなりません。
保証が難しい場合には,努力目標を設定するという方法もあります。
サービスレベルについて定めた企業間の合意をSLA(Service Level Agreement)と呼び,通常は運用・保守業務委託契約書に添付します。SLAには,1で定めた各サービスにつき,保証項目や,その測定条件・方法,目標値,保証値,対象となるシステム・機器などを記載します。
SLAも表題は「契約」となっていなくても,双方の合意が文書化されたものであれば,法的な拘束力が生じるため,SLAで定めた基準を満たさなかった場合には,損害賠償や契約の解除という事態も生じえます。
SLAを定めることで,ベンダは「何をしなければならないか」が明らかになり,
ユーザから過剰な要求をされるという危険が減ります。ユーザからみてもベンダの作業品質を客観的に評価できるという利点があります。
ポイント3 SLAを導入することで,サービス品質に対する要求の「見える化」が実現できる
具体的な項目を洗い出すにあたっては,JEITA(社団法人 電子情報技術産業協会)の作成した「民間向けITシステムのSLAガイドライン第三版」(日経BP社,2006)などを参考にするとよいでしょう。