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

データベースエンジニアの参画初月は、構成とバックアップの実態をつかむこと、本番を操作するときの決まりを確かめること、月末に現状の見立てと優先して直す点を出して合意を取ることの3つをゴールにするのが基本です。初月から大きな変更を流すより、「この人に本番を預けても大丈夫だ」と思ってもらう土台を作る期間と考えてください。

この記事では、初月のゴール、週ごとの進め方、案件の型による重心の違い、避けたい動き、月末の振り返りを整理します。参画前の準備の全般は参画前の準備の記事、職種を問わない初期の動き方は参画初期の記事で扱っているので、ここではデータベースならではの点に絞ります。

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

この3つは、案件の型が運用でも移行でも共通です。重心の置き方は後で触れます。

1週目：資料と実物から現状を集める

最初に読む資料

1週目は、手を動かす前に読むことが中心です。データベースの案件では、次の資料を先に頼んでおくと進めやすくなります。

• 構成図：サーバーやインスタンスの数、レプリケーションの向き、接続するアプリの一覧
• バックアップの方式と保持期間：取り方、保管場所、最後に復旧を試した記録
• ジョブの一覧：夜間のバッチ、統計情報の更新、バックアップの時間帯
• 過去の障害の記録：どんな症状で、何が原因で、どう戻したか
• 変更の手順と承認の流れ：本番に変更を流すときの申請や承認の方法

資料は「書かれた当時の意図」として読み、実物の設定値やジョブの定義と食い違う点があれば、その場でメモしておきます。資料が少ない現場では、前任者からの引き継ぎで何を聞くかが大切です。考え方は引き継ぎの記事で整理しています。

関係者と短く話す

1週目のうちに、発注側の窓口、アプリの担当者、インフラの担当者と短く話しておきます。聞きたいのは、「今いちばん困っていること」「触ってほしくないところ」「過去に揉めた変更」の3つです。データベースは周りのシステムとつながっているため、誰に何を確かめればよいかを早くつかむことが、後の判断の速さにつながります。

権限と端末を確かめる

本番に入れるのか、参照だけか、作業用の端末や接続の経路は何かを確かめます。付与された権限が作業に対して広すぎる場合は、そのまま使わず、必要な範囲を発注側と確かめておくと安心です。

2週目：操作の決まりを固め、小さな作業で型を合わせる

本番作業の流れを一枚にまとめる

承認者、作業できる時間帯、手順書の形式、作業後の報告先、緊急時の連絡先と口頭の了承の扱いを一枚にまとめ、発注側の窓口に確かめてもらいます。夜間作業や呼び出しがある案件では、その時間の扱いが契約どおりかもここで確かめておきます。

小さな作業で現場の型に合わせる

統計情報の確認、権限の棚卸し、軽い設定の確認など、影響の小さい作業を手順書つきで一つ流してみます。手順書の書き方、レビューの受け方、作業記録の残し方を現場の型に合わせる練習になり、発注側にとっても自分の進め方を知る機会になります。

性能と容量の「平常時」を記録する

主な処理の所要時間、待機の傾向、データ量の増え方、ディスクの使用量など、平常時の数値を記録しておきます。平常時を知らないと、何かが起きたときに「いつもと違う」と言えません。

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

現状の見立てをまとめる

集めた情報から、危うい点を整理します。データベースの案件で挙がりやすいのは、次のような点です。

• 復旧の手順が試されていない、または所要時間が分からない
• 構成図と実物が違い、切り替えの手順が成り立たない
• 遅い処理が特定の時間帯に集中している
• 製品の版のサポート期限が近い
• 権限が広く付与されたままの利用者がいる

優先順位は「失うものの大きさ」で付ける

直したい点が多く見つかっても、全部を一度に提案すると、発注側は判断しにくくなります。データを失う、業務が止まる、といった影響の大きいものを先にし、それぞれに「放っておくと何が起きるか」「直すのにかかる手間」をそえて、選択肢として出します。

次の1〜2か月の作業計画を引く

合意した優先順位をもとに、次の1〜2か月の作業と、作業の時間帯、必要な承認をまとめます。復旧の訓練を計画に入れておくと、自分の見立てが正しいかを確かめる機会にもなります。

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

運用・保守の案件

重心は、ジョブとバックアップの実態をつかみ、障害時に自分が何をするかを決めておくことです。過去の障害の記録を読み、同じ症状が出たときの初動を手順にしておくと、初月のうちに呼び出しがあっても落ち着いて動けます。

性能改善の案件

重心は、「遅い」と言われている処理を特定し、平常時と比べてどこが違うかを事実で示すことです。初月に改善の案を急いで流すより、原因の見立てと確かめ方について、アプリの担当者と合意を取るところまで進めるほうが、後の議論が早くなります。

移行・版上げの案件

重心は、移行元の実態（使っている機能、接続元、ジョブ）を洗い出し、移行先との違いを一覧にすることです。切り替えの日付が決まっている場合は、戻す判断の基準と期限を誰と決めるかを、初月のうちに確かめておきます。案件の型ごとの仕事の中身はデータベースエンジニアの案件の仕事内容で整理しています。

初月に避けたい動き

• 承認を経ずに本番を操作する：善意の小さな修正でも、後で「誰の判断か」が問われます
• 前の現場のやり方を早く持ち込む：命名規則やバックアップの方式は、現場の経緯を知ってから提案します
• 本番データを手元に取り出す：調査は統計情報やマスキングされたデータで進めます。考え方は個人情報を扱う業務委託の記事をご覧ください
• 頼まれた作業を範囲を確かめずに広げる：アプリの改修やOSの設定など、契約の範囲外の依頼は、引き受ける前に確かめます。考え方は業務範囲が変わったときの記事をご覧ください
• 分からない挙動を推測で埋める：慣れない製品の作法は、公式のドキュメントと検証環境で確かめてから手順に入れます

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

月末には、次の点を振り返り、発注側の窓口と短く話す時間を取ることをおすすめします。

1. 構成とバックアップの一覧に、まだ確かめていない部分が残っていないか
2. 本番作業の流れは、実際に流した作業で問題なく回ったか
3. 見立てと優先順位に、発注側と食い違いがないか
4. 担っている作業が、契約の業務範囲と合っているか
5. 夜間作業や呼び出しの稼働が、想定と比べてどうだったか

4と5で食い違いがあれば、早めにエージェントや発注側に相談するほうが、後から話すより調整しやすくなります。

よくある質問

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

バックアップの方式と、最後に復旧を試した記録の確認から始めることをおすすめします。データを戻せるかどうかが分からない状態は、ほかのどの問題より影響が大きいためです。そのうえで、ジョブの一覧と接続元を実物の設定から洗い出し、構成の一覧を自分で作っていきます。

参画初月から大きな変更を求められたら、どうすればよいですか？

断る必要はありませんが、手順書、確かめる指標、戻す条件と手順を先に示し、承認を得てから進めてください。環境を知らないことによる見落としが心配な点は、検証環境での確認や、作業の分割を提案するのが現実的です。

1か月たっても全体像がつかめません。どうすればよいですか？

つかめている部分と、つかめていない部分を分けて一覧にし、発注側の窓口と共有してください。つかめていない部分ごとに、誰に聞けばよいか、どの資料や設定を見ればよいかを決めると、次の1か月で埋める計画になります。参画後につまずきやすい場面はデータベースエンジニアのつまずきやすい点と対策で整理しています。