結論:メンテナンス契約は、スコープを契約書で明示・依頼をタスク化・緊急度 3 段階・月次レポートで対価可視化・半年ごとに見直し、の 5 点で運営する。長期関係の信頼の積み上げに直結する。

「先月のメンテナンス、結局何やったんでしたっけ?」

月額メンテナンス契約の請求書を発行するタイミングで、こういう確認が社内で起きるなら、メンテナンス運営の可視化が足りていません。

納品後の運用は、案件本体ほど派手な作業がない分、ぼんやり流していくと「お互いに何が提供されているか分からない関係」になりがちです。月額の対価が見えないと、クライアントは「払っている価値があるのか」と感じ、制作側は「無料で対応しすぎている」と感じる。両方にとって悪い関係性です。

この記事は、納品後のメンテナンス契約を、タスク管理ツールで構造的に運営する方法を解説します。

メンテナンス契約が曖昧になる構造

メンテナンス契約が曖昧になるのは、3 つの構造的な原因があります。

1 つ目は、スコープが契約書で明確化されていない。「サイトの保守」とだけ書かれていて、何を含み何を含まないかが具体的でない。結果、「ついで」の依頼が無限に発生する。

2 つ目は、依頼の受付がメール・電話・口頭の混在。窓口が分散しているので、月末に「今月何をやったか」を集計するときに、漏れと重複が出る。

3 つ目は、月額の対価が見えない。クライアントから見ても、制作側から見ても、月額に対して何が提供されたかが具体的に分からない。これが請求の正当性への自信を弱めます。

これらは契約とツールの両面で解決します。

スコープを契約書で明示する

メンテナンス契約に含む作業と、別料金になる作業を、契約書に項目として明示します。

含む作業の例:

  • バグ修正(既存機能の不具合対応)
  • 軽微なコンテンツ更新(テキストの差し替え、画像の差し替え 1 枚程度)
  • セキュリティアップデート(CMS・ライブラリ・サーバー)
  • 定期監視(稼働状況、エラー監視)
  • 月次レポート(アクセス・エラー・対応内容のまとめ)

別料金になる作業の例:

  • 新機能の追加開発
  • デザインの大幅な変更
  • ページの新規追加
  • 大規模なコンテンツ追加(10 ページ以上の文章作成など)
  • サーバー移設・インフラ変更

このスコープが明確だと、依頼が来たときに「これは契約内」「これは別途見積もり」と即判断できます。曖昧にしておくと、「ついで」が積み重なって、契約の利益率が知らないうちに削れていきます。

依頼をタスクとして受ける

メンテナンス依頼がメール・Slack・電話のどこから来ても、すべてタスク管理ツールに「タスク」として受け直します。

タスク作成時に記録する情報:

  • 依頼内容
  • 依頼日時
  • 依頼者(クライアント側担当者)
  • 緊急度(後述)
  • 契約内 / 契約外の判定
  • 想定工数

「契約内」のタスクは通常通り対応、「契約外」のタスクは追加見積もりを案内します。判定をタスクに記録しておくことで、後から「あの作業、追加見積もりすべきだったかも」を確認できます。

依頼の入り口がタスク管理ツールに統一されると、月末に「今月の対応一覧」が自動的に出来上がります。集計の労力がほぼゼロになります。

緊急度を 3 段階に分ける

すべての依頼を「すぐ対応」モードで受けると、計画的な作業時間が破壊されます。緊急度を 3 段階に分けて、それぞれの応答時間を契約で合意します。

緊急(2 時間以内対応):

  • サイトが完全に表示されない
  • ログインができない
  • 決済ができない(EC の場合)

通常(1 営業日対応):

  • 一部機能が動作しない
  • 表示崩れ(一部ブラウザのみなど)
  • 軽微なテキスト修正

軽微(週次まとめて対応):

  • 文言の改善提案
  • 画像の差し替え(緊急性のない)
  • 微細なデザイン調整

依頼が来たときに、まず緊急度を判定する。緊急度のラベルをタスクに付けることで、「いまどの優先度で動かすか」が制作チーム内で共有されます。

緊急依頼が想定より多い場合、メンテナンス契約の単価を見直すサインです。月の緊急対応が 5 件以上ある契約なら、専用窓口を維持するコストを契約に反映すべきです。

月額の対価を可視化する

タスク管理ツールに「2026年X月のメンテナンス」というグループを月次で作り、その月に対応したタスクを全部その中に登録します。

月末に、そのグループのタスク一覧をクライアントに共有または PDF レポート化します。

月次レポートの例:

2026 年 5 月のメンテナンス対応:

【契約内対応】
- バグ修正:3 件(フォーム送信エラー、画像表示崩れ等)
- コンテンツ更新:5 件(ニュース欄、お知らせの差し替え)
- セキュリティアップデート:CMS 2 件、サーバーパッチ 1 件
- 定期監視:稼働率 99.8%(エラー検知 2 件、自動復旧済み)

【別途見積もり対応】
- 新ページの追加(5/15 別見積もり提示済み)

合計:契約内 11 件、別途見積もり 1 件

これを毎月続けることで、メンテナンス契約の対価が「具体的な仕事のリスト」として可視化されます。クライアントは「払っている価値がある」と納得できる。制作側は「これだけの仕事をしている」を自信を持って提示できる。

「ついで」の追加依頼に対処する

メンテナンス対応中によくあるパターンが、「ついでにこれもお願いできますか」という追加依頼です。

この瞬間に判定するのが重要です。契約内なら対応する、契約外なら追加見積もりを案内する。タスクに「契約内 / 契約外」のラベルを付けてから着手する習慣にすると、「無意識に契約外作業を無料でやってしまう」現象が減ります。

「契約外ですが、今回は対応します」と判断するケースもあります。その場合も、その判断をタスクに記録します。「対応したが契約外作業、サービス対応 1 件」と書いておく。これを月末レポートで「サービス対応:1 件」として明示すると、クライアントにも「本来は別料金の作業を含めている」という認識が共有されます。

半年ごとの契約見直し

メンテナンス契約は、半年ごとに見直すリズムを契約に組み込みます。

見直し時に確認する項目:

  • 想定より作業が多かった項目(単価アップの根拠)
  • ほとんど発生しなかった項目(スコープから外して値下げ提案も可能)
  • 緊急対応の頻度
  • クライアントの満足度

タスク管理ツールに半年分の対応履歴が蓄積されているので、見直しの議論が「印象論」ではなく「データ」で進められます。「過去 6 ヶ月の緊急対応は 3 件で、いずれも 3 時間以内に解決しています」のように、具体的な実績を提示できる。

これがあると、契約交渉が制作側にもクライアント側にも納得感のある議論になります。

メンテナンス契約は、信頼関係の長期投資

最後に観点として、メンテナンス契約は、案件本体より「関係の長さ」が大きい契約です。

3 ヶ月の制作案件は終わったら関係が薄れる可能性がありますが、メンテナンス契約は数年単位で続きます。この長期関係の積み上げが、次の大きな案件の発注、追加プロジェクトの相談、紹介などに繋がります。

毎月の対応を可視化し、信頼の積み上げを目に見える形にしておくことが、長期投資としてのメンテナンス契約の本当の価値です。

関連記事

公開前チェックの仕組み化は 公開前チェックリストの仕組み化:制作会社の品質保証、プロジェクト完了時の整理は プロジェクトが終わるときの「綺麗な閉じ方」5 ステップ を参照してください。

クライアントとの共有運用全体の設計は クライアントに進捗を見せる仕組みの作り方、外部メンバーとの仕事を回す全体像は 外部メンバーとのチームタスク管理 完全ガイド にまとめています。

Paqut で、メンテナンス契約を運営する

この記事で書いた契約運営は、Paqut なら 3 ステップで回り始めます。

  1. 「2026 年 X 月のメンテナンス」というグループを月次で作る
  2. 依頼をタスクとして受け、「契約内 / 契約外」をコメントで明記
  3. 月末にグループ全タスクを集計し、クライアントに月次レポートとして共有

3 分で立ち上がります。

いま試す → https://app.paqut.net/