Laravel の月額保守で「含まれること・含まれないこと」を決める

結論から書くと、Laravel の月額保守で最初に決めるべきなのは、金額より 作業の境界 です。特に、(1) 定期的な更新をどこまで含めるか、(2) 何を「不具合」と呼ぶか、(3) 月の作業量の上限と超えた分の扱い、(4) バージョンアップを含めるか、の4つが決まっていないと、後で「それは保守に入っていると思っていた」という食い違いが起きます。

保守の依頼そのものが断られやすい理由と、依頼の出し方は「「保守だけお願いしたい」が断られる理由と、受けてもらえる依頼の出し方」で説明しました。この記事では、引き受けてもらえる段階まで進んだ後、契約の中身をどう決めるかを扱います。

Laravel の保守で定期的に発生する作業

範囲を決める前に、何が定期的に発生するのかを押さえておきます。Laravel の場合、公式に周期が決まっている作業があります。

Laravel 公式のリリースノートによると、メジャーバージョンは毎年（第1四半期ごろ）、マイナーとパッチのリリースは最短で毎週出ることがあります。マイナーとパッチには互換性を壊す変更を含めない方針です。また、各リリースのバグ修正は18か月、セキュリティ修正は2年です。

ここから、保守の作業は大きく2種類に分かれます。

• 周期的で、作業量が読めるもの: パッチやマイナーの更新、composer audit による既知の脆弱性の確認、ログの確認、バックアップの確認
• 時期は分かるが、作業量が大きいもの: メジャーバージョンの更新、PHP の更新

前者は月額に含めやすく、後者は別の案件として見積もるほうが、依頼する側にとっても費用の見通しが立ちます。サポートの期限は前もって分かるので、「期限の何か月前に計画を出す」ことを保守の作業に含めておくと、更新が先送りになるのを防げます。

含める作業と別見積にする作業の分け方

次の表は、分け方の一例です。「月額の時間内」は、月額に含む作業時間の範囲で対応し、超えた分を別に扱う区分です。

サーバー、ドメイン、SSL 証明書の管理を誰が行うかも決めます。契約の名義が依頼する側にあるなら、保守する側は「更新日の確認と連絡」までを持つ、といった分け方もあります。

「不具合」と「仕様の変更」の境界を決める

揉めやすいのはここです。基本は、合意した仕様のとおりに動かないものが不具合、仕様そのものを変えるものが変更 です。ただ、古いシステムでは仕様書が無いこともあるので、何を基準にするかを先に決めておく必要があります。

現実的なのは、保守を始めた時点の動作を基準にする ことです。保守の前に調査を行い、構成と主な機能の動き、分かっているリスクを記録しておけば、それが基準になります。

あわせて、次のケースの扱いも決めておきます。

• 保守を始める前からあった不具合: 後で見つかることがあります。原因の調査までは保守の範囲、修正は都度見積、のように決めます。
• 外部の要因による不具合: 連携先の API の仕様変更や、サーバー提供元の設定の変更などです。システム側の不具合ではないので、変更として扱うと決めておくと、後で揉めにくくなります。
• 利用者の操作による問題: データの誤登録の修正などです。問い合わせ対応の時間内か、別作業かを決めます。

どちらに当たるか迷うものは、作業に入る前に「これは変更として扱います」と区分を伝え、合意してから進めます。作業の後で区分を決めると、費用の話がこじれやすくなります。

月の作業量と対応の条件を決める

月額の保守は、作業時間の上限と、対応の速さの約束で中身が決まります。

• 作業時間の上限: 月に何時間までを月額に含めるか。使わなかった時間を翌月に繰り越すか。超えた分の単価。
• 受付と対応の時間: 営業日の何時から何時までか。夜間や休日の扱い。
• 緊急の定義: 「システムが止まり、業務ができない」など、緊急として扱う条件を具体的に書きます。緊急でないものは、翌営業日以降の対応で足りる場合もあります。
• 連絡の方法: メール、チャット、電話のどれで受け付けるか。依頼の記録を残す場所。
• 月次の報告: 実施した作業、更新したパッケージ、見つかった脆弱性、次に期限を迎えるバージョン。

決めた内容は、契約書や仕様書の別紙に、作業の一覧として書いておきます。数字は案件ごとに決めるので、ここでは○としています。

【保守の範囲（例）】
1. 月額に含む作業
   ・Laravel と依存パッケージのパッチ・マイナー更新と動作確認（月○回）
   ・既知の脆弱性の確認と報告（月○回）
   ・エラーログとバックアップの確認
   ・障害時の一次対応（受付時間内）
2. 月額の作業時間（月○時間まで）で対応する作業
   ・問い合わせへの回答、小さな改修
   ・超える場合は事前に見積を出し、承認を得てから対応する
3. 別見積とする作業
   ・Laravel のメジャー更新、PHP の更新、機能の追加
   ・保守を始める前からあった不具合の修正
4. 対象外
   ・網羅的な脆弱性診断、侵入テスト

このように書いておくと、依頼のたびに「これは保守の範囲か」を確認する手間が減ります。新しい種類の依頼が出てきたら、その都度この一覧に追加します。

報告に「次に期限を迎えるバージョン」を入れておくと、メジャー更新の予算を前もって確保しやすくなります。Laravel のメジャー更新の進め方は「Laravel バージョンアップの手順と、実際に詰まるポイント」にまとめています。

契約の前に揃えておくもの

範囲と条件のほかに、次のものを契約の前に揃えます。

• 現状の調査結果: 保守の基準になります。h-system でも、保守だけのご相談を、まず調査から始めて、その後に継続の保守につながった例があります。
• アカウントと権限: 本番サーバー、リポジトリ、エラーの通知先、外部サービスの管理画面。誰が何の権限を持つかを一覧にします。
• 本番への反映の手順: 誰が、どの手順で反映するか。反映の前に依頼する側の承認を挟むか。
• 終了するときの扱い: ソースコード、アカウント、資料の引渡しの方法。

保守運用を含む契約の考え方は、IPA の情報システム・モデル取引・契約書が参考になります。個別の判断が必要な場合は、法律の専門家に相談してください。

h-system でできること

h-system では、他社や前任者が作った Laravel のシステムの保守を、開発者本人がお引き受けしています。いきなり月額の保守を始めるのではなく、まず現状を調査し、その結果をもとに、月額に含める作業と別見積にする作業、対応の時間と条件をご相談のうえで決めます。一人で対応しているため即時の対応はお約束していませんが、対応できる範囲は事前にはっきりお伝えします。初回のご相談と概算のお見積りは無料で、詳細な調査は有償です。範囲と費用は着手前にご案内します。