はじめに
知人がAWSのEC2や、Wordpressを構築する業務を請け負っています。
AWSのEC2や、Wordpressの運用保守業務も請け負うことを検討しているようで、
どのような契約形態で請け負うのがよいのか、相談を受けました。
保守サービス契約がよいのでは、と伝えました。
ただ、契約形態について大雑把な理解しかしていなかったので、
いい機会だったので整理してみました。
本ブログは、保守を請け負う側の視点で記載しています。
AWSやWordPressの運用保守業務に最適な契約形態
相手が求めている内容によって契約形態は異なりますが、一般的なAWSやWordpressの運用保守業務であれば、
「保守サービス契約」を選択するのがよいでしょう。
その他の選択肢しては、業務委託契約、請負契約があります。
各契約形態の特徴と注意点を下記に整理しました。
契約形態 | 特徴 | 注意点 |
保守サービス契約 | 継続的な運用保守が必要な場合に最適。トラブル対応、セキュリティアップデート、バックアップ作業などが含まれる。月次の固定報酬が一般的。 | 契約範囲を明確にしておかないと、トラブル対応が過剰になり、追加コストが発生する可能性がある。定期メンテの有無も明確にする。 |
業務委託契約 | 特定の業務や作業範囲を明確にして契約する。長期的な保守が必要な場合や、短期的なプロジェクトに適している。 | 作業範囲や対応範囲があいまいだと、追加作業やトラブル対応が発生しやすい。長期で複雑な保守業務である場合、保守サービス契約への切り替えを検討したほうがよい。 |
請負契約 | 成果物を納品することが主な目的で、システム開発や構築がメインの業務に適している。納品後の保守は契約に含まれていないことが多い。 | 保守業務には向いておらず、トラブル発生時に即時対応が難しい。成果物の納品後、追加の保守サービス契約が必要になることが多い。 |
運用保守業務におけるリスク回避のための契約内容
リスクのある契約例を下記に記載しました。
- 事例
ある企業がシステム保守の業務を請け負い、「業務委託契約」を結びました。契約内容にはシステム監視と定期メンテナンスが含まれていましたが、具体的なトラブル対応の範囲は曖昧でした。クライアント側は、保守契約を結んだため、すべてのトラブルに対応してもらえると期待していました。 - 問題点
予想外に頻繁にシステムトラブルが発生し、クライアントはそのたびに対応を要求しました。契約では緊急対応が含まれていないため、保守業者としては対応を拒否するか、追加の対応料金を請求するしかありませんでしたが、クライアントとの間に摩擦が生じ、最終的には契約の見直しを求められる事態に至りました。 - リスク
契約書で対応範囲が明確でなかったため、トラブル対応が過度に求められ、追加の作業や時間的コストがかかりました。
リスクを回避するために契約内容で意識すべきポイントを下記に記載しました。
- ポイント1:トラブル対応の範囲を明確にする
「緊急対応は1ヶ月に2回まで無料、それ以降は別途料金が発生する」などの対応の回数制限を設ける。また、システム監視や定期メンテナンスの範囲も細かく定義し「定期メンテナンス外の対応は別途見積もり」とする。 - ポイント2:追加作業や料金の設定
追加作業が発生した場合の料金体系を明確に記載し、「作業が月間契約時間を超えた場合の追加料金」や「トラブル発生時の緊急対応のコスト」を具体的に示す。 - ポイント3:ServiceLevelAgreement(SLA)を明確にする
サービス提供者(保守業者)とクライアントとの間で合意される契約の一部で、提供されるサービスの品質や対応時間、範囲、レベルについて明確に定義する。下記に例を記載。
- 通常のトラブル対応
トラブルが発生した際、通常対応の範囲や、何時間以内に対応を開始するかをSLAで定めます(例: 24時間以内に対応開始)。 - 緊急トラブル対応
重大なシステム障害やサービス停止など、優先度の高い緊急トラブルについて、どのように区別するか、そして何時間以内に対応・復旧するかもSLAで規定します(例: 4時間以内に対応開始、8時間以内に復旧)。 - サービスの可用性
システムの稼働率(例: 99.9%のアップタイム)や、ダウンタイムが発生した場合の対応時間もSLAで規定されることが多いです。
- 通常のトラブル対応
運用保守業務では、クライアントからの要求が当初の契約を超えることがよくあります。リスクを回避するためには、契約書でトラブル対応の範囲や料金設定を明確にすることが不可欠です。また、追加対応や緊急対応に対して適切な料金体系を盛り込むことで、保守業務をスムーズに進めることができ、クライアントとの関係も良好に保つことが可能です。
以上です。
コメント