サーバーエンジニアのフリーランス案件の仕事内容｜案件の種類と働き方

サーバーエンジニアのフリーランス案件の仕事は、サーバーの構成を決め、設定して動かし、止めずに更新し続けることです。ただし、設計書を書く立場か、手順書どおりに構築する立場か、運用の現場で障害に備える立場かで、1日の過ごし方も、関わる相手も、手元に残る成果物も大きく変わります。

この記事では、サーバーの案件を5つの種類に分け、それぞれの1日と1か月の流れ、関わる相手、成果物を整理します。独立の目安はサーバーエンジニアがフリーランスになるには、求められるスキルはサーバーエンジニアのスキルの記事で扱っているので、ここでは「参画したら実際に何をしているか」に絞ります。

仕事の中身は「工程」と「サーバーの置き場所」で決まる

サーバーの案件は、同じ「サーバーエンジニア募集」でも中身がかなり違います。違いを生むのは主に次の2つです。

• 工程：設計、構築・更改、移行、運用・保守、自動化や運用改善のどこを担うか
• 置き場所：自社のデータセンターやサーバールームの物理サーバーか、仮想化基盤の上のサーバーか、クラウドか

この2つを掛け合わせると、フリーランスのサーバー案件はおおむね次の5種類に分けられます。

以下では、それぞれの1日と1か月の流れを典型的な例として紹介します。時間の配分は案件ごとに違うため、目安として読んでください。

設計の案件

1日の流れ（例）

午前は、発注元の基盤担当やアプリ担当と打ち合わせ、必要な台数、性能、可用性、バックアップの方針などを聞き取ります。午後は、聞き取った内容をもとに基本設計書やパラメータシートを書き進めます。ネットワークやストレージの担当と、IPアドレスやディスクの割り当てをすり合わせる時間もあります。夕方は、レビューで受けた指摘を直し、未決の事項を課題表に残します。

設計の案件では、手を動かす時間より、決めることを並べ、決めた理由を文書に残す時間が長くなります。

1か月の流れ（例）

• 月初：前月に決まらなかった事項を洗い出し、誰がいつ決めるかを課題表で整理する
• 毎週：基盤の定例会議で設計の進み具合と課題を報告する。アプリやネットワークの担当とも週次で論点をそろえる
• 月の半ば：基本設計や詳細設計のレビューを受け、指摘を反映する
• 月末：設計書を確定させ、構築の工程に渡す準備をする

成果物

基本設計書、詳細設計書、パラメータシート、サーバー構成図、性能や容量の見積もりの資料、課題表などです。設計の案件では、後から構築する人が迷わない粒度で書けているかが評価の中心になります。

構築・更改の案件

1日の流れ（例）

朝は、当日の作業予定と前日の試験結果を確認します。午前中は、パラメータシートをもとにOSやミドルウェアを設定し、構築の記録を残します。午後は試験項目に沿って動作を確かめ、結果をエビデンスとして保存します。物理サーバーを扱う案件では、データセンターに出向いてラックへの搭載や配線の確認に立ち会う日もあります。

OSのサポート期限に合わせた更改の案件では、既存のサーバーの設定を読み解き、新しい版で同じ動きを再現する作業が中心になります。

1か月の流れ（例）

• 月初：構築の対象と順番を確認し、手順書を準備する
• 前半：検証環境で構築し、手順書の誤りを直す
• 後半：本番環境で構築し、試験の結果を取りまとめる
• 月末：構築の結果を報告し、次の工程や運用への引き継ぎの資料をつくる

成果物

構築手順書、試験仕様書と試験結果、作業の記録、設定値の一覧、運用への引き継ぎ資料などです。同じ手順を別の人が実行しても同じ結果になるか、という再現性が問われます。

移行の案件

参画直後の数週間

移行の案件では、最初に今のサーバーで何が動いているかを調べることから始まります。動いているサービス、他のサーバーとの通信、定期的に動く処理、使っている証明書やライセンスなどを洗い出し、移行の対象と順番を決めます。古いサーバーは資料が残っていないことも多く、設定ファイルやログを読みながら依存関係を確かめる作業で1日が埋まることもあります。

切り替えに向けて

対象が決まったら、移行の方式を選び、リハーサルを重ねます。データの移し方、切り替えにかかる時間、問題が出たときに元に戻す手順を確かめ、業務部門と停止できる時間帯をすり合わせます。切り替えの当日は、夜間や休日に作業することが多く、その前後は稼働が増えやすくなります。

成果物

現行調査の結果、移行計画書、移行手順書と切り戻し手順書、リハーサルの記録、切り替え当日のタイムチャート、移行後の確認結果などです。移行の案件では、元に戻す手順まで用意できているかが信頼につながります。

運用・保守の案件

1日の流れ（例）

朝は、夜間の監視の通知とバッチ処理の結果を確認し、異常があれば原因を追います。日中は、ユーザーの追加や権限の変更、ディスクの拡張などの定型の依頼に対応します。月に一度程度のパッチ適用や、計画停止の作業も運用の仕事です。障害が起きたときは、ログやリソースの状況から原因を切り分け、影響の範囲を報告し、恒久的な対策を検討します。

運用の案件はシフトや待機の当番が入ることがあり、通常の作業と、いつ来るか分からない障害への備えの両方を抱える働き方になります。

1か月の流れ（例）

• 毎日：監視の確認、依頼への対応、作業の記録
• 毎週：運用の定例会議で障害と依頼の状況を報告する
• 月に一度程度：パッチ適用やバックアップの戻しの試験などの定期作業
• 月末：稼働の状況や障害の件数をまとめた月次の報告をつくる

成果物

運用手順書、障害報告書、作業の記録、月次の報告資料、手順の改善の提案などです。障害報告書では、何が起き、何を確かめ、何を変えたかを、後から読む人に分かるように書けるかが見られます。

自動化・運用改善の案件

運用の手作業を減らすことを目的にした案件です。構築や設定の変更を、Ansibleなどの構成管理の道具でコードにしたり、定型作業をスクリプトにしたりします。

最初の数週間は、どの作業にどれだけ時間がかかっているかを運用チームから聞き取り、効果の大きいところから対象を選びます。その後は、コードを書き、検証環境で試し、運用チームに使い方を渡すまでを繰り返します。成果物は、構成管理のコード、使い方の手順書、変更前後の比較の資料などです。

自動化の案件は、コードを書いて終わりではなく、運用チームが使い続けられる形で渡すことまでが仕事に含まれます。この方向の仕事の広がりはSREの仕事内容も参考になります。

どの案件にも共通する仕事

種類が違っても、次の仕事はほぼすべてのサーバー案件にあります。

1. 作業の記録：いつ、何を、どの手順で変えたかを残す
2. 変更の申請と承認：本番環境に手を入れる前に、影響と戻し方を示して承認を取る
3. 報告：障害や遅れは、事実・影響・次の対応をそろえて早めに上げる
4. 引き継ぎ：自分がいなくても作業が回るように、手順と判断の理由を文書にする

フリーランスならではの仕事として、自分の稼働の記録もあります。夜間の切り替えや障害の対応で稼働が月ごとに振れやすいため、作業の時間を日々つけておく必要があります。精算の仕組みは精算幅の記事をご覧ください。

関わる相手と働く場所

サーバーの仕事は、ほかの担当とのすり合わせで成り立っています。

働く場所は工程で変わります。設計書や手順書の作成、踏み台を通した構築や運用はリモートで進められる案件がある一方、物理サーバーの搭載や部品の交換、持ち出しできない本番環境での作業は現地が前提です。詳しくはサーバーエンジニアのリモート案件の記事をご覧ください。クラウドの上でサーバーを扱う働き方はAWSエンジニアの仕事内容、通信の側から見た仕事はネットワークエンジニアの仕事内容で扱っています。

よくある質問

サーバーエンジニアのフリーランス案件は、夜間作業が多いですか？

工程によります。移行の切り替えや計画停止を伴う作業は、業務への影響を避けるため夜間や休日に行うことが多くなります。設計や手順書の作成が中心の案件では、日中の作業がほとんどです。夜間作業の頻度と扱いは、参画前に確かめておきましょう。

運用・保守の案件から、構築や設計の案件に移れますか？

移れます。運用の中で手順書を自分で書いた経験、障害の原因を突き止めて対策を入れた経験、パッチ適用の計画を立てた経験などは、構築の案件で評価される材料になります。経験の書き方はサーバーエンジニアのスキルシートの記事で解説しています。

参画して最初の1か月は何をすることが多いですか？

既存の構成と手順書の読み込み、作業の申請と承認の流れの確認、踏み台や権限の準備から始めるのが一般的です。初月の進め方はサーバーエンジニアの参画初月にやることで解説します。