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

BIエンジニアの参画初月は、データの流れ・モデル・更新・権限の現状を棚卸しし、主な指標の定義と利用者をつかみ、小さな改修を一つ検算したうえで届け、月末に改善の見立てを出すところまでを目標にします。最初の1か月で求められるのは、画面をたくさん作ることより、この人に数字を任せて大丈夫だと取引先が判断できる材料を示すことです。

参画前の契約・環境の準備は参画が決まってから開始日までにやること、職種を問わない最初の1週間の進め方は参画初日から最初の1週間でやることで解説しています。この記事では、BIエンジニアならではの初月の動き方に絞ります。

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

この3つを、1週目、2週目、3〜4週目の順に重心を移しながら進めます。

1週目：仕組みを棚卸しする

最初に見るもの

BIの現場では、画面の見た目から入るより、データの流れを後ろからたどるほうが全体をつかみやすくなります。次の順で目を通します。

1. 画面の一覧と利用者：どの画面が、どの部門の、どの会議で使われているか
2. モデルの構成：どの画面がどのモデルを使っているか。共通のモデルか、画面ごとに別々か
3. データソースと整形の場所：DWHのビューを使っているのか、BIツールの中で整形しているのか
4. 更新の設定：更新の時刻と頻度、ゲートウェイの有無、最近の失敗の記録
5. 権限の設定：ワークスペースの役割の割り当て、行単位で見える範囲を絞る設定の有無

読みながら、「この画面だけ別のデータを取り込んでいる」「同じ指標が画面ごとに違う式で書かれている」といった点を書き留めておきます。この段階では直さず、仮説としてためておきます。

権限の割り当ては早めに見ておく

権限の設定は、誤っていても表からは気づきにくい部分です。Microsoft Learnでは、Power BIの行レベルのセキュリティ（RLS）で制限されるのはワークスペースで閲覧者の権限を持つユーザーだけで、管理者・メンバー・共同作成者には適用されないと説明されています（2026年10月時点）。行単位の絞り込みを使っている現場では、閲覧だけのはずの利用者がメンバーとして追加されていないかを見ておくと、後の事故を防げます。気づいた点は、自分で直す前に窓口に伝えます。

2週目：数字の意味と利用者をつかむ

主な指標の定義を集める

利用者が最もよく見る指標を数個選び、それぞれの計算式と、業務上の定義（いつ時点か、何を含み何を除くか）を並べます。定義が文書になっていない現場も多いため、計算式から読み解いたものを窓口や業務側の担当者に確かめてもらいます。

利用者と短く話す

画面を見ている人の声は、資料からは分かりません。業務部門の代表や、よく問い合わせをくれる利用者と、短い時間で話す機会をもらいます。聞くことは次の3つに絞ると、相手の負担になりません。

• この画面で何を決めているか
• 数字が合わない、遅いなど、困っていること
• 本当は見たいのに見られないもの

同じ質問を何人かにすると、部門ごとの見方や定義の違いがはっきりします。その違いが、改善の手がかりになります。

依頼の受け方と変更の流れを確かめる

依頼を誰から受け、誰が優先順位を決めるか、本番への反映を誰の判断で行うかを、窓口と確かめます。開発用と本番用の場所が分かれているか、変更をどう記録しているかも見ておきます。Power BIでは、作業内容をPower BIプロジェクト（PBIP）として保存すると、レポートとセマンティックモデルの定義がテキストファイルのフォルダーとして保存され、Gitでの履歴管理に使えると説明されています。現場がこうした進め方をとっているなら、その流れに沿って作業します。

3〜4週目：小さく届け、見立てを出す

小さな改修を一つ、検算して届ける

依頼の中から、範囲が小さく、利用者がすぐに違いを感じられる改修を一つ選んで届けます。届ける前に、元データや旧帳票と数字を突き合わせ、見える範囲の設定がある画面では利用者の立場で見え方を確かめます。最初の改修で数字の誤りを出さないことが、その後の信頼の土台になります。

改善の見立てをまとめる

1〜3週目で集めた情報をもとに、改善の見立てをまとめます。

• 画面ごとに分かれた取り込みや、重複した計算式など、仕組みの課題
• 定義が部門ごとに違う指標と、決めてもらう必要がある論点
• 更新の失敗や表示の遅さなど、運用の課題
• それぞれの影響と、手を入れる順番の案

見直しは選択肢で出す

モデルの作り直しのような大きな見直しが必要な場合でも、一つの案だけを出すと「前のやり方を否定された」と受け取られやすくなります。小さく直す案と大きく直す案を並べ、それぞれの手間と影響を示したうえで、取引先に選んでもらう形にします。

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

新規導入の案件

まだ画面やモデルがない段階で入る場合は、棚卸しより、最初に作る画面の利用者と指標を業務側と言葉で合わせることが初月の中心になります。月末には、共通のモデルの骨子と、決めきれていない定義の一覧を出せることを目指します。

既存帳票の移行の案件

旧帳票の計算の癖を読み解くことが先です。初月のうちに、移す帳票の一覧と、突き合わせの範囲・方法を窓口と合意しておくと、2か月目以降に原因の調査が膨らむのを防げます。

追加開発の案件

既存のモデルの上で画面を作るため、モデルの構造を正しく読み解くことが先です。新しい指標を足すときは、既存の指標と定義が重ならないかを確かめてから作ります。

運用の案件

更新の失敗の対応と、権限の申請の流れを最初に引き継ぎます。早朝の更新の通知を誰が受け、何時までに対応するのかは、初週のうちに確かめておきます。引き継ぎの受け方は引き継ぎの記事で整理しています。

初月に避けたい動き

範囲の外の依頼が増えてきたときの扱いは業務範囲が変わったときの記事、BIエンジニアがつまずきやすい場面はBIエンジニアのフリーランスがつまずきやすい点と対策で整理しています。

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

1か月が過ぎたら、次の点を自分で振り返ります。

• データの流れと、画面とモデルの対応を説明できるか
• 主な指標の定義を、業務側と同じ言葉で説明できるか
• 届けた改修で、数字の誤りや見える範囲の誤りを出していないか
• 改善の見立てを窓口に伝え、次の1〜2か月の優先順位を合意できたか
• 契約で決めた業務の範囲と、実際に担っている仕事がずれていないか

ずれている点があれば、2か月目の早い段階で窓口と話しておきます。リモート中心の案件での進め方はBIエンジニアのリモート案件の記事でも触れています。

よくある質問

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

画面の一覧と、それぞれが使っているモデル・データソースを一覧にするところから始めるのが近道です。そのうえで、よく使われている画面の利用者に、何を決めるために見ているかを聞いてください。資料がない状態そのものも、改善の見立ての一部として報告に含めておくとよいでしょう。

初週から急ぎの画面の修正を頼まれたら、どうすればよいですか？

範囲が小さければ引き受けてかまいませんが、影響を受けるほかの画面がないかを確かめ、数字を検算してから反映します。急ぎでも本番を直接直さず、決まった流れで反映することを窓口と確かめておくと、後で誤りが見つかったときにも戻しやすくなります。

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

画面やモデルの数が多い現場では、1か月で全体をつかみきれないこともあります。その場合は、分かっていることと分かっていないことを分けて報告し、残りをいつまでに確かめるかの予定を示してください。分からない点を隠したまま見立てを出すより、範囲を区切って示すほうが信頼されます。