サーバー・インフラ構築の修正を何回まで受けるか｜先に決めておく

2026年4月4日

朝比奈蒼

この記事のポイント

✓サーバー・インフラ構築の修正対応を
✓着手前にどこまで決めておくべきかを整理しました
✓回数ではなく期間と範囲で区切る方法

サーバー・インフラ構築の修正対応で消耗する人は、たいてい同じ場所でつまずいています。納品したあとに「ここも直してほしい」が延々と続き、どこまでが契約の範囲でどこからが追加作業なのか、途中から誰にも説明できなくなる。結論から言うと、この問題は交渉力ではなく設計で解決します。着手前に「完了とは何か」と「修正とは何か」を決めておけば、後から数える必要がなくなるからです。

この記事では、すでに案件を受けている立場で、修正対応の範囲を事前に取り決める実務を扱います。回数で縛る方法の限界、期間と範囲で区切る考え方、見積書と契約書への書き方、そして実際に修正の依頼が来たときの切り分け手順まで、順番に整理します。

インフラの「修正」は3種類に分かれる

まず、修正という言葉が指しているものを分解します。ここを分けずに「修正は3回まで」と決めても機能しません。中身が違うものを同じ数字で数えることになるからです。

種類1: 不具合の修正

構築した環境が、合意した要件どおりに動いていない状態です。設定漏れ、パラメータの誤り、手順の抜け、依存関係の考慮不足。これらは構築側の責任範囲であり、無償で直すのが原則です。

不具合かどうかの判定は、「合意した要件と照らして動いているか」で決まります。要件書やテスト項目が存在しない案件では、この判定ができません。だから、資料を先に作ることが修正対応の管理そのものになります。

種類2: 仕様の解釈違い

要件には書かれているが、双方の理解が食い違っていた場合です。「冗長化する」という一文を、片方はアクティブスタンバイと理解し、もう片方は負荷分散と理解していた。こういうことが実際に起きます。

この種類が最も揉めます。どちらの責任とも言い切れず、話し合いで着地点を決めることになる。事前に防ぐには、要件を文章ではなく構成図と設定値の一覧で確認することです。図と数値には解釈の幅がありません。

種類3: 追加・変更の要望

要件になかったものを、後から求められる場合です。監視項目の追加、バックアップ世代の変更、別リージョンへの複製、アクセス制御の細分化。運用のイメージが固まるにつれて出てくる、自然な要望でもあります。

これは修正ではなく新しい作業です。別途の見積もりとして扱うのが正しく、そう扱えるかどうかが案件の採算を決めます。断るという意味ではありません。追加として受けるという意味です。

回数で縛るのが難しい理由

「修正は2回まで」という取り決めは、デザインや文章の仕事では機能します。インフラでは、そのままでは機能しません。理由が2つあります。

「1回」の定義が曖昧だと数えられない

デザインなら、修正指示の一覧をまとめて受け取り、直して戻す。この往復が1回です。インフラの場合、指摘は運用テストの過程で断続的に出ます。今日1件、明日3件、来週2件。これを1回と数えるのか、6回と数えるのか。定義がなければ数えられません。

さらに、1件あたりの作業量の差が大きい。ログの出力先を変えるだけの指摘と、ネットワーク構成をやり直す指摘が、同じ「1件」として並びます。回数で管理すると、軽い指摘を数に含めるのが惜しくなり、かえって処理が滞ります。

作業の性質が「連続している」

インフラの構築は、設計、構築、テスト、移行、運用引き渡しと工程が連続します。どこまでが構築でどこからが運用かの線が引きにくい。修正の受付が終わったつもりでも、運用が始まってから設定変更の依頼が来ます。

この連続性は、インフラの仕事の本質でもあります。構築と運用を分けずに一気通貫で見るという考え方は、業界側でも当たり前のものとして語られています。

株式会社エヌアイデイは、50年以上にわたりシステムインテグレーター（SIer）として金融機関や航空会社、自治体、各種メーカーなどさまざまな業種のお客様のITインフラの導入にまつわる業務を担ってまいりました。ITプロフェショナルとしてインフラ構築のみならず、インフラの安定稼働を見据えた企画、要件定義・設計から、開発・構築、24時間365日の監視・運用・保守まで、一気通貫のサポートが可能です。出典: dx.nid.co.jp

一気通貫で受けられる体制があるなら、それは強みです。ただし、個人や少人数で受ける場合、構築の契約に運用の作業が無償で流れ込んでくると採算が崩れます。どこで契約を区切るかを、着手前に決めておく必要があります。

回数の代わりに使う3つの区切り方

回数だけに頼らず、複数の軸を組み合わせて範囲を決めます。実務で使いやすいのは次の3つです。

期間で区切る

「本番稼働の開始日から30日間は、要件どおりに動作しない事象について無償で対応する」という形です。期間で区切ると、件数を数える必要がなくなり、双方にとって管理が簡単になります。

期間の長さは、システムの性質で決めます。月次のバッチ処理があるなら、少なくとも1か月は回してみないと分かりません。四半期の処理があるなら、その部分だけ期間を延ばすという設計もできます。

対象範囲で区切る

「本件の対象は、要件定義書に記載された構成の範囲とする」と明記します。そのうえで、対象外を具体的に列挙します。アプリケーションの不具合、既存システム側の設定、クライアント側の端末やネットワーク、サードパーティのサービス障害。

範囲外を書いておくことの効果は大きい。インフラの案件では、原因がどこにあるか分からない状態で「サーバーが原因では」と連絡が来ることが頻繁にあります。切り分けの作業自体が労力なので、切り分けをどこまで担当するかも書いておきます。

分類で区切る

前述の3種類を契約書に書き、それぞれの扱いを決めます。不具合は無償、解釈違いは協議、追加変更は別途見積もり。この3行があるだけで、依頼が来たときの会話がまったく変わります。

「これは追加ですか」と聞かれたとき、契約書の分類を参照して答えられる。判断の根拠が個人の裁量ではなく文書にあると、相手も納得しやすくなります。取引条件を文書として整える基礎は、ビジネス文書検定が扱う範囲と重なっており、契約書や見積書の書き方を体系的に学び直す入口になります。

着手前に決めておく6つの項目

具体的に、何を決めておけばよいのかを列挙します。この6つが埋まっていれば、修正対応で揉める確率はかなり下がります。

項目1: 完了の定義

何をもって構築完了とするかを書きます。テスト項目の一覧を作り、その全項目が合格した時点を完了とするのが最も明確です。「正常に動作すること」という書き方は、完了の定義になりません。

テスト項目には、合格条件を数値で書きます。応答が返ること、ではなく、指定の条件下で応答が返ること。フェイルオーバーが動作すること、ではなく、指定の手順で切り替わり、指定の時間内に復旧すること。数値があると、判定に主観が入りません。

項目2: 修正の受付期間

完了の判定日から何日間、修正を受け付けるかを決めます。この期間内は不具合の修正を無償で行い、期間が過ぎたものは保守の契約か個別の見積もりで対応する、という区切りです。

期間の起点も明記します。「納品日」なのか「検収完了日」なのか「本番稼働開始日」なのか。この3つはずれることがあり、起点が曖昧だと期間そのものが曖昧になります。

項目3: 無償で直す範囲

無償の対象は、構築側の作業に起因する不具合に限る、と書きます。そのうえで、対象外の例を挙げます。要件変更に伴う設定変更、第三者による変更に起因する不具合、対象外システムの障害、環境の外部要因。

ここで重要なのは、無償の範囲を狭くすることではありません。範囲が明確であることです。範囲が明確なら、範囲内の対応は気持ちよくできます。曖昧なまま無償で受け続けると、どこかで限界が来て、関係が悪化します。

項目4: 数え方の単位

回数を決める場合は、単位を定義します。「修正依頼は一覧としてまとめて提出し、その一覧への対応を1回とする」という書き方が使いやすい。個別に随時受け付ける形にすると、際限がなくなります。

また、「対応後の再テストで発見された、同一箇所の不具合は回数に含めない」といった但し書きも入れておきます。直した箇所が直っていない場合まで回数を消費するのは、双方にとって不合理です。

項目5: 追加作業の見積もりの出し方

追加作業が発生したときの流れを決めます。依頼を受けてから何営業日以内に見積もりを出すか、見積もりの承認は誰が行うか、承認前に着手しないことを合意しておくか。この3点です。

承認前に着手しない、という一文は必ず入れます。善意で先に手を付けると、後から「頼んでいない」「無償だと思っていた」という話になります。着手の合図を明確にしておくことが、自分を守ります。

項目6: 連絡と作業の窓口

依頼を出せる人を限定します。複数の担当者から別々に依頼が来ると、優先順位も範囲も管理できません。窓口を1人に決め、その人を通した依頼だけを正式なものとして扱う。

作業の時間帯も決めます。本番環境への変更をいつ行うか、緊急時の連絡手段は何か、深夜や休日の対応が必要かどうか。ここを決めていないと、想定していない時間帯の対応が当然のように発生します。インフラの仕事の全体像や求められる対応範囲は、サーバー・インフラ構築・保守のお仕事で仕事内容ごとに整理されています。

見積書と契約書への書き方

決めた内容を、実際の文書に落とします。長い条文は必要ありません。

見積書に添える書き方の例

見積書の備考欄に、次のような形で書きます。「本見積りに含まれる作業は、別紙要件一覧に記載の構成の設計、構築、テストまでとします。検収完了日から30日以内に発見された、要件一覧との不一致については無償で対応します。要件一覧に記載のない機能の追加、構成の変更、および第三者による変更に起因する事象への対応は、別途お見積りとなります。」

この程度の分量で、必要なことは書けます。長くすると読まれません。読まれない条件は、書いていないのと同じです。

検収の条項

契約書では、検収の手続きを定めます。納品後、何営業日以内に検収を行うか。期間内に通知がない場合は検収完了とみなすか。不合格の場合、理由を書面で示すこと。この3点を書いておくと、検収が宙に浮いたまま修正だけが続く状況を防げます。

検収が完了しないまま運用が始まってしまう案件は珍しくありません。「動いているのだから完了でよいはず」と考えず、書面で完了の確認を取ります。ここが曖昧だと、修正の受付期間の起点も決まりません。

契約不適合責任の期間

成果物が契約の内容に適合しない場合の責任について、期間を定めます。法律上の原則と、契約で定める期間は分けて考えます。個別の案件で適切な期間をどう設定するかは、システムの性質と、相手との関係によって変わります。

※契約条項の具体的な文言や、法的な効力の判断が必要な場合は、弁護士など専門家に相談してください。この記事は実務上の整理であり、個別の契約への助言ではありません。

着手前にそろえる3つの資料

取り決めを機能させるには、参照できる資料が必要です。「要件どおりか」を判定する対象がないと、分類そのものができません。

資料1: 要件の一覧

やること、やらないこと、前提条件を箇条書きにします。文章ではなく一覧にするのは、後から1行ずつ照合するためです。段落で書かれた要件は、照合に使えません。

前提条件の記載を忘れないようにします。既存のネットワーク構成が変わらないこと、指定のOSバージョンが提供されること、必要な権限が付与されること。前提が崩れた場合の扱いも一行添えておくと安心です。

資料2: 構成図と設定値の一覧

構成図は、解釈違いを防ぐ最強の道具です。文章で「冗長化」と書くより、図に構成を描いたほうが早く、正確に伝わります。

設定値の一覧も同様です。インスタンスの種別、ストレージの容量、ネットワークの範囲、ファイアウォールの規則、バックアップの保持期間、監視の閾値。数値で書かれたものは、後から「そんなつもりではなかった」と言われにくい。

資料3: テスト項目と合格条件

構築が終わったことを証明する資料です。項目ごとに、手順、期待する結果、判定を書きます。相手にも同じ表を見てもらい、合格の判断を一緒に行います。

この表があると、検収がスムーズに終わります。「なんとなく動いている」ではなく「全項目が合格した」という状態で区切れるからです。そして、この表に載っていない事象が後から出てきた場合、それは追加作業だという説明が自然にできます。

引き渡しのときにやること

構築が終わっても、引き渡しの仕方が雑だと修正依頼が増えます。運用側が困った瞬間に、構築側へ連絡が来る構造になるからです。

手順書とドキュメント

構成図、設定値の一覧、起動と停止の手順、バックアップとリストアの手順、障害時の一次対応。これらを文書として渡します。渡した文書の一覧も残します。

運用が自力でできる状態を作ることは、自分の負荷を下げる投資です。手順書が薄いと、些細な操作のたびに問い合わせが来ます。それは無償の作業として積み上がっていきます。

運用への引き継ぎ

構築の担当者と運用の担当者が別の組織であることは珍しくありません。この場合、引き継ぎの場を設けるかどうかで、その後の問い合わせ量が変わります。

テストに問題がなければ、実際にITインフラの運用を開始します。なお、ITインフラ構築担当者と運用担当者が異なる場合がありますので、運用担当者を構築時点からプロジェクトに参画させるなど、運用習熟期間の設定を含め運用開始をスムーズにおこなうための取り組みが必要になります。出典: dx.nid.co.jp

構築の段階から運用担当者に入ってもらう。この一手間が、引き渡し後の修正依頼を減らします。個人で受ける案件でも、テストの段階で運用側に同席してもらうよう提案する価値があります。

監視の取り決め

監視を誰が行うか、アラートが誰に飛ぶか、一次対応を誰がするか。これを決めずに引き渡すと、障害のたびに連絡が来ます。構築の契約に監視が含まれないなら、その旨を明記して引き渡します。

インフラの求人票を見ると、構築と運用の両方に関わる要件が並ぶことがよくあります。

【必須】・Windowsサーバー環境での開発経験・PowerShellおよびWindowsバッチでのスクリプト開発経験・Veeamを用いたバックアップ経験または理解・設計書や手順書などのドキュメント作成経験・関係者との円滑なコミュニケーション能力出典: infra-itengineer.com

注目したいのは、ドキュメント作成経験とコミュニケーション能力が必須要件に並んでいる点です。技術的に構築できることと、その内容を文書にして引き継げることは別の能力として扱われています。修正対応の範囲を管理するのも、この後者の能力の一部です。

修正の依頼が来たときの手順

事前の取り決めがあっても、実際に依頼が来たときの動き方は決めておく必要があります。3ステップで処理します。

手順1: 事象の切り分け

まず、何が起きているかを確認します。いつから、どの操作で、どのような症状が出るか。エラーメッセージ、ログ、発生の再現性。これらを揃えないまま作業に入ると、原因ではない箇所を触ることになります。

切り分けの過程は記録に残します。この記録が、後から分類を説明するときの根拠になります。「調べたところ、原因はアプリケーション側の設定でした」と言うには、調べた過程が残っていることが必要です。

手順2: 分類の合意

切り分けが終わったら、3種類のどれに当たるかを相手と合意します。合意なしに「これは追加作業です」と通知すると、対立の構図になります。事実を示して、判断を一緒に行う形にします。

合意はテキストで残します。チャットの1行でも構いません。「今回の事象は要件一覧のNo.12に該当するため、無償対応の範囲として作業します」という記録があると、後から数え直す必要がなくなります。

手順3: 対応と記録

作業したら、内容を記録します。日時、対象、変更内容、確認結果。この記録は、次に似た事象が起きたときの資料になり、追加作業の見積もりを出すときの根拠にもなります。

記録の形式は簡素で構いません。続かない形式にすると、結局残らない。1件1行のスプレッドシートで十分です。

揉めやすい場面と対処

現場でよく起きる3つの場面と、対処の型を挙げます。

「動かない」だけの連絡が来る

症状の説明がないまま「動かない」とだけ連絡が来ることがあります。ここで慌てて調査に入ると、対象外の問題に時間を使うことになります。

決まった質問を返す形にします。いつから、どの画面や操作で、どんなメッセージが出るか、直前に何か変更したか。この4つを聞く定型文を用意しておくと、毎回考えずに済みます。

本番環境で勝手に変更されていた

引き渡した環境に、別の担当者が変更を加えていて、それが原因で動かなくなっている。インフラの案件で最もよくある事象のひとつです。

対処は、変更の記録を確認することです。そのうえで、対象外の事象であることを説明し、対応するなら別途の作業として扱います。同時に、今後の変更手順を取り決めます。責めるのではなく、手順を作るほうに話を持っていくのが実務的です。

要件になかった機能を求められる

「常識的にこれくらいは入っていると思った」という主張が出ることがあります。ここで感情的に返すと関係が壊れます。要件一覧を一緒に確認し、記載がないことを事実として示したうえで、追加として見積もる提案をします。

このとき、断るのではなく選択肢を出すのがポイントです。今回の予算内で入れるなら別の項目を削る、次のフェーズで対応する、簡易版で対応する。選べる形にすると、相手も判断しやすくなります。海外の取引先と仕事をする場合、この種の合意形成の作法はさらに重要になります。契約と作業範囲を明文化する文化については、Upworkの使い方ガイド｜日本人フリーランスが海外案件を取る方法で扱われている進め方が参考になります。

クラウドとオンプレミスで修正の性質が変わる

同じインフラ構築でも、環境によって修正対応の出方が違います。取り決めを作るときは、この違いを踏まえておくと精度が上がります。

クラウドは変更が容易な分、要望が増える

クラウド環境では、インスタンスの種別変更もストレージの拡張も、コンソールの操作で完結します。物理的な制約がないため、依頼側から見ると「ちょっと変えるだけ」に見える。実際には、構成の変更が監視やバックアップ、権限設計に波及するので、作業は見た目より広がります。

対策は、変更の影響範囲を可視化しておくことです。構成要素の依存関係を図に描いておき、「この項目を変えると、ここまで見直しが必要になります」と示せる状態にします。作業の重さが伝われば、依頼側も優先順位を考えるようになります。

もうひとつ、コストへの影響も説明の材料になります。構成を変えると課金が変わる。これは依頼側にとって直接の関心事であり、安易な変更要望を抑える効果があります。

オンプレミスは物理の制約が期限を決める

一方、オンプレミス環境では機器の調達、設置、配線、電源やラックの制約が絡みます。後から「やっぱりこの構成で」と言われても、物理的に応じられないことがあります。

この場合、修正の受付期間を決める以前に、変更を受け付けられる期限を工程表に明記します。「機器の発注後は構成変更に応じられません」「ラック搭載後の配置変更は別作業です」といった記載です。物理の制約は説明しやすく、相手も納得しやすい。工程表の中に期限として書き込んでおくのが最も効きます。

見積もりの段階で修正対応の工数を織り込む

範囲を決めることと並んで重要なのが、修正対応にかかる時間を最初から見積もりに入れておくことです。ゼロで見積もると、必ず持ち出しになります。

バッファをどこに置くか

工程ごとに薄くバッファを乗せるより、テストと修正対応の工程として独立させたほうが説明しやすくなります。「テストと不具合対応」という行が見積書にあれば、その工程で何が起きるかを依頼側も想像できます。

バッファを隠して見積もると、削られたときに何が減ったのか説明できません。独立した行にしておけば、「この工程を削ると、不具合対応は別途のご請求になります」と伝えられます。項目として見えていることが、交渉の材料になります。

工数ではなく工程で調整する

予算が合わないときに、作業時間を削って帳尻を合わせるのは危険です。テストが薄くなり、結果として修正対応が増えます。削るなら、工程そのものを外します。

たとえば、監視の設定を対象外にする、手順書を簡易版にする、移行のリハーサルを1回にする。何を外したかを明記しておけば、後からその部分の依頼が来たときに追加として扱えます。時間を削るのではなく、範囲を削る。この考え方が、結果的に品質と採算の両方を守ります。

市場を見てきた運営者の視点からの考察

在宅の仕事と業務委託の市場を20年見てきた立場から言えば、修正対応で疲弊する人と、そうでない人の差は、技術力ではなく着手前の30分の使い方にあります。要件一覧とテスト項目を先に作った案件は、揉めません。作らなかった案件は、ほぼ確実に揉めます。この差は職種を問わず一貫しています。

運営者として見てきた限りでは、長く同じ相手から依頼を受け続けているエンジニアほど、範囲の線引きが明確です。無償で何でも引き受ける人が重宝されるわけではありません。何がどこまでかを最初に示してくれる人のほうが、依頼側にとって計画が立てやすく、結果として継続します。曖昧なまま抱え込むのは、親切のようでいて、相手の計画性を奪う行為でもあります。

もう一点、報酬の受け取り方についても触れておきます。仲介の手数料が差し引かれる経路では、依頼側が支払う金額と受け手が受け取る金額に差が生まれます。同じ予算でも、中間のマージンが乗らない直接取引なら、依頼側はより多くの作業を頼めて、受け手の手取りは厚くなる。手数料0%で直接つながる仕組みの価値は、金額の大小ではなく手取りの質にあります。修正対応の範囲を明確にすることは、この手取りを守る作業でもあります。

技術の裏付けを整理しておきたい場合、ネットワークの基礎を体系的に扱うCCNA（シスコ技術者認定）の学習範囲は、要件定義や切り分けの精度に直結します。また、報酬の決まり方を職種横断で眺めておくと自分の位置づけが掴みやすく、ソフトウェア作成者の年収・単価相場のデータが参考になります。インフラの周辺で仕事の幅を広げたい場合は、AI・マーケティング・セキュリティのお仕事で隣接分野の仕事内容が整理されています。

修正を何回まで受けるかという問いへの答えは、「回数では決めない」です。完了の定義、受付期間、対象範囲、分類。この4つを着手前に決めておけば、何回であっても対応は破綻しません。逆にこれを決めずに回数だけを取り決めても、数え方をめぐって別の争いが起きるだけです。

よくある質問

Q. 修正対応の回数は契約書に書くべきですか？

回数だけを書いても機能しません。インフラの案件では指摘が断続的に出るうえ、1件あたりの作業量の差が大きいためです。回数を書く場合は「修正依頼は一覧としてまとめて提出し、その一覧への対応を1回とする」のように単位を定義します。あわせて、完了の定義、受付期間、対象範囲、修正の分類を書いておくほうが実効性があります。

Q. 無償で直す範囲はどこまでにすべきですか？

構築側の作業に起因し、合意した要件と一致していない事象までが原則です。要件変更に伴う設定変更、第三者による変更が原因の不具合、対象外システムの障害は範囲外として明記します。重要なのは範囲を狭くすることではなく、明確であることです。範囲が曖昧なまま無償で受け続けると、どこかで限界が来て関係が悪化します。