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

データエンジニアの参画初月は、データの流れの地図を作ること、権限と作業の決まりを確かめること、小さな改善を一つ本番に出すことの3つをゴールにすると、現場で信頼を得やすくなります。大きな作り直しを提案するのは、地図ができて、関係者と話せるようになってからで遅くありません。

この記事では、初月のゴール、週ごとの進め方、案件の型による重心の違い、避けたい動き、月末の振り返りを整理します。参画初日から1週間の一般的な動き方は参画初日から最初の1週間でやることで扱っているので、ここではデータエンジニアならではの進め方に絞ります。

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

3つ目の「小さな改善」は、成果を急ぐためではありません。現場の手順で一度変更を出してみると、レビュー、検証、本番への反映のどこで時間がかかるかが分かるからです。2か月目以降の見積もりの精度が上がります。

1週目：データの流れと決まりを集める

最初に読むもの

• 構成の図と処理の一覧：取り込み元、処理の動く時刻、置き場所、届け先
• 処理のコードと設定：どこで管理され、誰がレビューし、どう本番に出るか
• データの定義書やカタログ：主な指標の定義と、決めた人
• 障害の記録：最近の失敗、原因、直し方。繰り返し起きている失敗はないか
• 権限とデータの扱いの決まり：個人データの範囲、作業してよい環境、持ち出しの禁止事項

資料が足りない現場も多くあります。足りない部分は「まだ分からないこと」として一覧にしておき、2週目の話で埋めます。

権限は「必要な範囲」から始める

初日から広い権限を求めるより、まずは開発用の環境と、読むだけの権限で始めるほうが安全です。本番データに触れる必要が出たら、その理由と範囲を添えて申請します。個人データの扱いの考え方は業務で個人情報を扱うときの記事、在宅の作業環境は自宅で働くときの情報セキュリティをご覧ください。

2週目：関係者と話し、地図を埋める

データの両端にいる人と話す

データエンジニアの仕事は、上流と下流の両方に相手がいます。

• 上流：取り込み元のシステムの担当者。改修の予定をどう知らされるか、データの癖は何か
• 下流：分析担当、業務部門、データを使う仕組みの担当者。何に使い、どの時刻までに、どの鮮度で必要か
• 窓口：発注側でデータ基盤を預かる人。優先順位と、決めてもらう相手

一人15〜30分ほどでも、「困っていること」と「変えてほしくないこと」を聞くと、地図の空白が埋まります。

処理を一度、自分で動かしてみる

開発用の環境で、主な処理を一度動かしてみます。どこで時間がかかるか、失敗したときにどう知らされるか、やり直すとどうなるかを、資料ではなく手で確かめます。前任者からの引き継ぎがある場合は、このときに疑問点をまとめて聞くと効率的です。

夜間の失敗の扱いを確かめる

夜間の処理が失敗したとき、誰が気づき、誰が、いつまでに対応するのかを確かめます。自分が対応する範囲がある場合は、時間外の連絡の扱いも窓口と言葉で合わせておきます。

3〜4週目：小さな改善を出し、次の計画を合わせる

影響の小さい改善を一つ選ぶ

たとえば次のような変更です。

• 取り込みの件数や空の値を検査する項目を一つ足す
• 失敗したときの通知の文面を、原因が分かる形に直す
• 何度流しても結果が同じになるよう、一つの処理を直す
• よく聞かれる定義を、定義書に書き足す

現場の手順に沿って、レビューを受け、検証し、本番に出すところまでをやり切ります。

気づいた課題は選択肢で出す

地図を作るうちに、「この処理は失敗が多い」「この表は誰も使っていない」「費用がかかりすぎている」といった課題が見えてきます。直し方を一つに決めて提案するより、影響、手間、急ぐ理由を添えた選択肢で出すと、発注側が判断しやすくなります。

次の1〜2か月の計画を合わせる

月末までに、任されている作業と、見つけた課題を並べ、次の1〜2か月で何をどの順に進めるかを窓口と合わせます。契約の業務範囲を超える課題は、範囲の確認とあわせて相談します。考え方は業務範囲が変わったときの記事をご覧ください。

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

既存基盤の運用・改善の案件

障害の記録と、繰り返し起きている失敗の把握が重心です。初月から大きく作り直すより、通知と検査を整えて「止まったときにすぐ分かる」状態に近づけることを優先します。

基幹システムからの移行の案件

移行元のデータの癖と、移行後の突き合わせの方法を決めることが重心です。件数、合計値、代表的な明細をどの単位で比べるかを、初月のうちに関係者と合わせておくと、後半の検証が楽になります。

新しい基盤の立ち上げの案件

決まっていることと、これから決めることの切り分けが重心です。層の分け方、命名、権限の切り方など、あとから変えにくいものを優先して合意を取ります。自分の判断で決めてしまわず、決めてもらう相手を確かめてください。

初月に避けたい動き

• 地図ができる前に、作り直しを提案する：前任者や社員の判断には、見えていない理由があることが多くあります
• 本番データを手元に持ち出す：原因を調べたい場合も、決められた環境の中で確かめます
• 定義を自分で決める：急ぎの依頼でも、仮の条件と理由を添えて確認を求めます
• 一人で数字のずれを調べ続ける：分かった範囲で早めに窓口と共有します
• 手順を飛ばして本番に出す：小さな変更でも、現場のレビューと検証の手順に沿います

つまずきやすい点と対策はデータエンジニアのつまずきやすい点で詳しく整理しています。

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

月末に次の点を振り返り、窓口との定例などで短く共有すると、2か月目の動きが合わせやすくなります。

1. 主なデータの流れを、1枚の図で説明できるか
2. 触れてよいデータと、作業の決まりを把握できたか
3. 現場の手順で、変更を一度本番に出せたか
4. 上流と下流の担当者と、連絡の経路ができたか
5. 見つけた課題と、次の1〜2か月の計画を合わせられたか

できていない項目は、理由と次の手を添えて伝えれば十分です。

よくある質問

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

処理の一覧と動く時刻、失敗の記録から読み始め、入力と出力をつなげて地図を作ります。分からない部分は「まだ分からないこと」として一覧にし、上流と下流の担当者に聞いて埋めていきます。引き継ぎの考え方は引き継ぎの進め方の記事も参考になります。

参画初月から大きな作り直しを求められたら、どうすればよいですか？

すぐに引き受けて方針を決めるより、まず現状の地図と、作り直しで影響を受ける処理や利用者を整理し、選択肢として示すのが安全です。急ぐ理由がある場合も、決めてもらう相手と範囲を確かめてから進めてください。

リモートの案件で、関係者と話す機会が少ないです。どうすればよいですか？

窓口に、上流と下流の担当者を紹介してもらい、短い打ち合わせを入れてもらうよう相談します。チャットで質問するときは、何を確かめたいか、急ぐかどうかを一文で添えると返事をもらいやすくなります。リモートでの進め方はデータエンジニアのリモート案件の記事をご覧ください。