サーバーエンジニアの参画初月にやること｜現場で信頼される進め方

サーバーエンジニアの参画初月は、構成と設計書・手順書の実態をつかみ、作業申請と権限の流れを覚え、月末に「現状の見立て」と「次の作業の計画」を出して合意を取るところまでを目標にします。最初の1か月で求められるのは、多くの作業をこなすことより、このエンジニアに本番のサーバーを任せて大丈夫だと発注側が判断できる材料を示すことです。

この記事では、初月のゴール、週ごとの進め方、案件の型による重心の違い、避けたい動き、月末の振り返りを整理します。参画前の準備は参画前の準備で扱っています。

初月のゴールを3つに分ける

初月のゴールは、次の3つに分けて考えると進めやすくなります。

1週目：資料と実機から構成をつかむ

最初に読む資料

最初の1週間は、作業より読むことに時間を使います。読む順番の目安は次のとおりです。

1. システム構成図とサーバーの一覧：台数、役割、物理・仮想・クラウドの別、OSの版
2. 設計書・パラメータシート：OSやミドルウェアの設定値、命名規則
3. 運用手順書：日次・月次の作業、障害時の連絡の流れ
4. 直近の障害の記録と変更の記録：何が起きやすいか、最近何を変えたか
5. 監視の画面とバックアップの設定：何を監視していて、何をどこまで取っているか

実機は「見るだけ」から始める

権限が付与されたら、まず設定を変えずに状態を確かめます。資料に書かれた設定と実機の設定、動いているサービス、定期実行の処理を照らし合わせ、違いを書き留めておきます。長く運用されてきた環境では、資料に残っていない設定が見つかることがよくあります。

権限の付与に時間がかかる現場では、資料を読み進め、分からない点を質問の一覧にまとめておくと、権限が揃ったときにすぐ動けます。

関係者と短く話す

サーバーの担当は、多くの人と接点があります。最初の週に、次の人と短く話しておくと後が楽になります。

• 発注側の担当者（作業の優先順位と、困っていること）
• 前任者や同じチームのメンバー（資料に残っていない注意点）
• ネットワーク、アプリケーション、ハードウェア保守の担当（境目と問い合わせの窓口）

2週目：作業の決まりを覚え、小さな作業をこなす

作業申請と承認の流れを一枚にまとめる

本番作業の申請の方法、承認者、締め切り、作業できる時間帯、作業後の報告の形を確かめ、一枚にまとめます。申請の要らない作業の範囲も確かめておきます。分からないときは、申請する側に倒すのが安全です。

最初の作業は小さく、記録を厚く

最初に任される作業は、アカウントの追加、ログの確認、定例のパッチ適用の補助など、小さなものが多くなります。小さな作業ほど、作業の前に確かめたこと、実行したコマンドや操作、結果、戻し方を記録しておきます。記録の丁寧さが、そのまま「本番を任せられるか」の判断材料になります。

報告の形を合わせる

日次や週次の報告の形式、障害時の第一報の出し方を、現場の決まりに合わせます。報告の書き方は稼働報告の記事も参考になります。

3〜4週目：見立てを出し、次の作業に合意を取る

現状の見立てをまとめる

3週目以降は、それまでに集めた情報を整理し、現状の見立てをまとめます。たとえば次のような観点です。

• サポート期限が近いOSやミドルウェアはないか
• バックアップは取れているか、戻す手順は試されているか
• 手順書と実機の設定に違いはないか
• 手作業で繰り返している作業はないか
• 監視の抜けや、鳴りすぎているアラートはないか

指摘は選択肢と一緒に出す

気になる点を挙げるだけだと、批判に聞こえることがあります。「この状態だと、こういうことが起きるおそれがある」「対応するなら、案Aと案Bがある」と、影響と選択肢をあわせて出すと受け止めてもらいやすくなります。

次の1〜2か月の作業を計画する

見立てをもとに、次の1〜2か月で手を付ける作業を、発注側の優先順位に合わせて並べます。自分の業務範囲を超える作業が含まれる場合は、範囲の扱いを確かめてから進めます。考え方は業務範囲が変わるときをご覧ください。

案件の型によって初月の重心は変わる

運用・保守の案件

日々の作業と障害時の連絡の流れを早く覚えることが中心になります。夜間作業や待機の当番がある場合は、初月のうちに一度、経験者と一緒に担当させてもらえるかを相談すると安心です。

更改・移行の案件

移行元のサーバーの調査が中心になります。資料に残っていない設定や、他のサーバーとの連携を洗い出し、移行の計画に反映させます。切り替えの日程が決まっている場合は、そこから逆算して、リハーサルまでに何を終えるかを初月のうちに決めておきます。

構築・自動化の案件

設計書の内容と、構成をコードで管理する仕組み（リポジトリ、レビューの流れ、反映の手順）を覚えることが中心になります。最初の変更は小さなものにし、レビューの受け方と反映の流れを一度通しておくと、その後の作業が速くなります。リモートでの進め方はサーバーエンジニアのリモート案件の記事で整理しています。

リモート中心の案件

踏み台やリモート接続の手順、接続が切れたときの連絡先を最初に確かめます。画面越しでは現地の状況がつかみにくいため、データセンターでの作業が必要になったときに誰が対応するのか、作業を頼むときの手続きは何かを初月のうちに押さえておくと、障害時に慌てずに済みます。

初月に避けたい動き

• 申請せずに本番の設定を変える：小さな変更でも、決まりを外れると信頼を落とします
• 手順書を読まずに前の現場のやり方で作業する：現場ごとに命名規則や作業の流れは違います
• 見つけた問題をすぐに直そうとする：影響を確かめずに直すと、別の問題を起こすことがあります。まずは報告します
• 前任者の設定を否定する：その設定にした理由があることも多く、理由を聞いてから判断します
• 分からないことを抱え込む：質問はまとめて、決まった時間に聞くと相手の負担も減ります

1か月の終わりに振り返ること

月末には、次の点を振り返り、担当者と短く共有します。

1. 構成の一覧や図は、実機の状態と合っているか
2. 作業申請と報告の流れを、迷わずにこなせるようになったか
3. 見立てと次の作業計画について、発注側と合意できたか
4. 契約の業務範囲と、実際に頼まれている作業にずれはないか
5. 夜間作業や待機の実績は、契約で決めた扱いと合っているか
6. 次の月に任されたい作業と、そのために足りない権限や知識は何か

4と5でずれが見つかったときは、早めに担当者やエージェントに伝えておくと、契約の更新のときに条件を見直しやすくなります。

よくある質問

構成図と実際のサーバーの状態が大きく違います。どうすればよいですか？

違いを見つけたら、まず一覧にして担当者に報告します。自分の判断で資料を書き換えたり、設定を直したりする前に、どちらが正しい状態かを確かめることが大切です。資料の更新が業務範囲に入るかもあわせて確かめておくと、その後の作業が進めやすくなります。

参画早々に障害が起きました。どこまで動けばよいですか？

まだ構成や決まりを把握しきれていない時期は、現場の担当者の指示に沿って、頼まれた調査や作業を一つずつ丁寧に進めることを優先します。分かったことは事実のまま早めに伝えます。障害の記録と対応の流れは、そのまま構成を理解する材料にもなるため、落ち着いてから振り返っておくと役に立ちます。

前任者からの引き継ぎがほとんどありません。何から始めればよいですか？

まず、サーバーの一覧と監視の画面、バックアップの設定、定期実行の処理を確かめ、何が動いているかを把握するところから始めます。分からない点は一覧にして、発注側の担当者にまとめて確かめます。引き継ぎの考え方は引き継ぎの記事で整理しています。