サーバーエンジニアのフリーランスがつまずきやすい点と対策

フリーランスのサーバーエンジニアがつまずきやすいのは、夜間作業や待機の扱いが決まらないまま始まること、現場の作業申請の手順を外れること、バックアップと切り戻しの確認が足りないまま本番に臨むこと、作業ミスの責任の範囲を読んでいないことです。どれも、会社員なら社内の決まりや上司が受け止めてくれた部分を、外部の立場で一人で抱えることから起きます。

この記事では、契約・現場・技術・お金の4つの面に分けて、サーバーエンジニアに起きやすい場面と対策を整理します。参画直後の動き方はサーバーエンジニアの参画初月にやることで扱っています。

契約でのつまずき

夜間作業や待機が「あるかもしれない」のまま始まる

サーバーの案件では、メンテナンス時間帯の作業、パッチ適用の夜間作業、障害時の呼び出しがついてくることがあります。面談で「たまにあります」と聞いただけで契約し、参画してから月に何度も夜間作業が入る、待機中の扱いが決まっていない、といったずれが起きがちです。

対策：契約前に、夜間・休日の作業の頻度の見込み、待機の有無、それぞれが報酬や精算の対象になるかを確かめ、書面に書いてもらいます。休日作業と待機の考え方は休日作業の記事と待機の報酬の記事で整理しています。

作業の範囲がサーバーの外へ広がる

サーバーの担当として入ったのに、ネットワーク機器の設定、アプリケーションのリリース作業、利用者からの問い合わせ対応まで頼まれるようになることがあります。一つひとつは小さくても、積み重なると本来の作業の時間がなくなります。

対策：契約の業務範囲に「どのサーバー群の、どの工程か」を書いておきます。範囲外の依頼が続くときは、引き受ける前に担当者と範囲と稼働の扱いを話し合います。考え方は業務範囲が変わるときをご覧ください。

作業ミスの責任がどこまで及ぶか読んでいない

サーバーの作業は、設定の誤りやコマンドの打ち間違いで、サービスを止めたりデータを失ったりするおそれがあります。準委任契約でも、契約書に損害賠償の条項があり、上限の定めがないこともあります。

対策：契約前に損害賠償の条項を読み、上限の有無を確かめます。賠償責任保険を検討する方法もあります。考え方は損害賠償の責任の記事で解説しています。

常駐先で社員と同じように扱われる

常駐の運用案件では、発注側の社員から直接、作業の順番や勤務時間を細かく指示されることがあります。契約の形と実態がずれると、いわゆる偽装請負の問題につながることがあります。

対策：契約の形（準委任か派遣か）と、指示を受ける窓口を確かめておきます。詳しくは偽装請負の記事をご覧ください。

現場でのつまずき

作業申請の手順を外れてしまう

サーバーの現場には、本番作業の申請、承認、作業時間帯の決まり、作業後の報告といった変更管理の手順があります。前の現場の感覚で「小さな変更だから」と申請せずに設定を変え、問題がなくても信頼を落とすことがあります。

対策：参画直後に、申請が要る作業の範囲、承認者、申請の締め切りを確かめ、一枚にまとめておきます。迷ったら申請する側に倒すのが安全です。

権限の申請が通るまで動けない

外部の立場では、本番環境の権限や踏み台へのアクセス、データセンターへの入館の手続きに時間がかかることがあります。その間に何もできず、「立ち上がりが遅い」と見られてしまうことがあります。

対策：権限が揃うまでの間にできること（設計書・手順書・監視の画面を読む、構成を図にまとめる）を先に決めておきます。権限の申請状況は、担当者と日付を決めて確かめます。

アプリ担当やベンダーとの境目があいまいになる

障害が起きたとき、OSの問題か、ミドルウェアの問題か、アプリケーションの問題かで担当が分かれます。境目が決まっていないと、切り分けの途中で調査が止まったり、自分の範囲外まで抱え込んだりします。

対策：参画の初期に、OS・ミドルウェア・アプリケーション・ハードウェア保守のそれぞれの担当と、問い合わせの窓口を確かめておきます。

悪い知らせを抱え込む

作業が予定どおりに進まない、手順書と実機の設定が違う、といった問題を、自分で解決してから報告しようとして抱え込むと、発覚したときの影響が大きくなります。

対策：問題に気づいた時点で、分かっていることと分かっていないことを分けて早めに伝えます。報告の形は稼働報告の記事も参考になります。

技術でのつまずき

バックアップと切り戻しを確かめないまま本番に臨む

パッチ適用や設定変更、移行の切り替えで、バックアップが取れていると思い込んで作業し、戻せないことに後から気づく場面があります。取れていても、戻す手順を試していなければ、いざというときに使えないこともあります。

対策：本番作業の前に、バックアップやスナップショットの取得と、戻す手順、切り戻しを判断する条件と時刻を決めておきます。可能なら検証環境で一度戻してみます。

本番と検証を取り違える

似た名前のサーバーが並ぶ環境では、検証のつもりで本番のサーバーで作業してしまう事故が起きます。複数の端末の画面を同時に開いているときに起きやすくなります。

対策：作業の前にホスト名を確かめる手順を入れる、本番と検証でプロンプトの表示を変えるなど、取り違えを防ぐ工夫を現場の決まりの範囲で取り入れます。

手順書と実機の設定が違う

長く運用されてきたサーバーでは、前任者が手順書に残さずに変えた設定や、独自のスクリプトが残っていることがあります。手順書どおりに作業して、思わぬ影響が出ることがあります。

対策：作業の前に、手順書の内容と実機の設定（サービスの状態、定期実行の処理、設定ファイル）を照らし合わせます。違いを見つけたら、作業を進める前に担当者に伝えます。

パッチやバージョンアップの影響を読み切れない

OSやミドルウェアの更新は、アプリケーションの動作や他のサーバーとの連携に影響することがあります。影響の確認をアプリ担当任せにすると、問題が起きたときに切り分けが遅れます。

対策：更新の内容と影響しそうな範囲を一覧にし、アプリ担当と確認の分担を決めてから適用します。新しい技術への合わせ方はサーバーエンジニアに求められるスキルで整理しています。

お金でのつまずき

夜間作業と障害対応で稼働が精算の幅を超える

障害対応や移行の追い込みで稼働が膨らみ、契約の精算の幅を超えても、超過分の扱いが決まっていないことがあります。精算の仕組みは精算幅の記事をご覧ください。

対策：稼働が膨らみそうな時期は、早めに見込みを担当者に伝え、超過の扱いを確かめておきます。

作業が延期・中止になった分が報酬にならない

切り替えの作業が直前で延期になり、待機していた時間や準備の時間の扱いがあいまいになることがあります。

対策：作業の延期・中止のときの扱いを、契約や作業の計画の段階で確かめておきます。

切り替えの区切りで契約が終わる

更改や移行の案件は、切り替えが終わると契約も終わることが多く、次の案件探しが遅れると空白ができます。契約期間の考え方は契約期間の記事で整理しています。

対策：切り替えの1〜2か月前から、次の案件の情報を集め始めます。

よくある質問

作業ミスでサービスを止めてしまいました。まず何をすればよいですか？

まず、現場の担当者にすぐ伝え、何をした結果どうなったかを事実のまま報告します。自分の判断だけで元に戻す作業を続けると、影響が広がることがあります。復旧の手順は現場の決まりに沿って進め、落ち着いた後に、原因と再発を防ぐ手順をまとめます。賠償の扱いが気になる場合は、契約書を確かめたうえで、必要に応じて専門家にご相談ください。

参画してから、聞いていたより夜間作業が多いと気づきました。

まず、実際の夜間作業の回数と時間を記録し、契約や示された条件と比べます。そのうえで、担当者やエージェントに、今後の頻度の見込みと報酬・精算の扱いを確かめます。条件と合わない状態が続く場合は、契約の更新の前に見直しを申し出ることも選択肢です。

手順書がほとんどない現場では、どう作業すればよいですか？

最初は、作業の前に実機の状態を確かめ、何をしたかを細かく記録しながら進めます。記録はそのまま手順書の下書きになります。手順書づくりが業務範囲に入っていない場合は、時間の使い方を担当者と相談してから進めると、稼働の扱いで揉めにくくなります。