BIエンジニアのフリーランスがつまずきやすい点と対策

フリーランスのBIエンジニアがつまずきやすいのは、何を作れば完了かがあいまいなまま画面づくりを引き受けること、移行で数字が合わない原因の調査を抱え込むこと、部門ごとに違う指標の定義をそろえないまま作ること、見える範囲の設定の漏れ、早朝の更新対応の扱いです。どれも、作った数字がそのまま会議や判断に使われるBIならではの事情から起きます。

対策の基本は、つまずきの種を契約と参画初期の取り決めで小さくし、現場では定義と変更を記録に残し、数字は検算してから出すことです。この記事では、契約・現場・技術・お金の順に、BIエンジニアならではの場面と対策を整理します。独立前の準備はBIエンジニアがフリーランスになるにはで扱っているので、ここでは「実際に起きやすい場面」に絞ります。

契約でのつまずき

「ダッシュボード作成」の完了の条件が決まっていない

契約書には「ダッシュボードの作成」とだけ書かれ、現場では利用者の意見を聞くたびに画面が作り直される、ということがよく起きます。画面は見た人の数だけ要望が出やすく、完成の線が引かれていないと修正が終わりません。

対策：参画前に、作る画面の範囲、確認してもらう相手、修正を受け付ける回数や期間、完了と判断する人を確かめておきます。フリーランス法では、発注事業者は業務委託をしたとき、給付の内容や報酬の額・支払期日などの取引条件を、書面やメールなどで直ちに明示しなければならないとされています（2026年10月時点、公正取引委員会の特設サイトによる）。明示される事項の詳しい中身はフリーランス法で明示される取引条件をご覧ください。

移行での数字の突き合わせが範囲の外に広がる

既存の帳票をBIツールへ移す案件では、新旧の数字が合わないことがよくあります。原因が元データの不備や、旧帳票の計算の誤りだった場合、その調査は計画にない作業として積み重なります。

対策：突き合わせの範囲（どの帳票の、どの期間の、どの指標か）と、合わなかったときに原因を調べるのは誰かを、参画前に決めておきます。範囲の外の依頼が増えてきたときの扱いは業務範囲が変わったときの記事と追加の依頼の断り方をご覧ください。

社員と同じように指示される

取引先の社員の下に置かれ、勤務時間や作業の手順まで細かく指示されるようになると、準委任の契約と実態がずれてきます。BIの担当は社内の業務部門から直接頼まれごとを受けやすく、この状態に気づきにくい職種です。考え方は偽装請負の記事で解説しています。

現場でのつまずき

部門ごとに違う指標の定義をそろえないまま作る

「売上」が受注日基準か出荷日基準か、「在庫」がいつ時点の数か、といった定義は部門ごとに違うことがあります。そろえないまま画面に並べると、会議で数字の食い違いが表に出て、画面そのものが信用されなくなります。

対策：作り始める前に、部門ごとの定義を並べて示し、どれを使うかを業務側に決めてもらいます。決まった定義は文書にし、画面の中でも確かめられるようにしておきます。BIエンジニアが決めるのではなく、決めてもらう形をとることが大切です。

利用者から直接の依頼が積み上がる

チャットで業務部門の利用者から「この列を足してほしい」「この数字を出してほしい」と直接頼まれるようになると、優先順位があいまいになり、本来の作業が後回しになります。

対策：依頼は取引先の窓口を通して受ける、という決めごとを参画の初期に確かめておきます。直接届いた依頼も、窓口に回してから優先順位を決めてもらいます。連絡の時間帯の考え方は連絡の時間帯の記事で整理しています。

前任者のモデルを読み解かずに手を入れる

引き継いだモデルの構造や計算式の意図を確かめないまま修正すると、ほかの画面の数字まで変わってしまうことがあります。複数の画面が同じモデルを使っている現場ほど、影響は広がります。

対策：最初の数週間で、データの出どころ、モデルの形、どの画面がどのモデルを使っているかを一覧にします。修正する前に、影響を受ける画面を確かめてから手を入れます。

技術でのつまずき

見える範囲の設定が効いていない

部門や担当者ごとに見えるデータを絞ったつもりでも、設定の前提を取り違えると、見せてはいけない数字が見えてしまいます。Microsoft Learnでは、Power BIの行レベルのセキュリティ（RLS）で制限されるのはワークスペースで閲覧者の権限を持つユーザーだけで、管理者・メンバー・共同作成者には適用されないと説明されています（2026年10月時点）。利用者を便宜のためにメンバーとして追加すると、絞り込みが効かなくなります。

対策：閲覧だけの利用者には閲覧者の権限を割り当て、公開の前に実際の利用者の立場で見え方を確かめます。同じページでは、「ロールとしてテスト」機能は動的なRLSの式を自分のIDで評価するため、外部のゲストユーザーに何が表示されるかは実際のゲストユーザーとしてサインインして確かめるよう案内されています。外部に見せる画面では、確認の手順を取引先と決めておきます。

BIツールの中で整形を重ねて重くなる

DWHに集計用のテーブルがないまま、BIツールの中で整形と結合を重ねると、更新に時間がかかり、画面も遅くなります。同じ整形が画面ごとに散らばると、修正のたびに複数の場所を直すことになります。

対策：整形をどこで行うのが適切かを早めに考え、必要ならDWH側にビューや集計用のテーブルを用意してもらう提案をします。基盤側の担当とどう分けるかはデータエンジニアのつまずきやすい点の記事も参考になります。

本番の画面を直接直す

急ぎの修正を頼まれ、本番に公開している画面やモデルを直接書き換えると、誤りがそのまま利用者に届きます。誰がいつ何を変えたかも追えなくなります。

対策：開発用と本番用の場所を分け、変更を確かめてから反映する流れを取引先と決めておきます。変更の内容と理由は短く記録に残します。

アカウントやデータへのアクセスがそろわない

参画しても、取引先のアカウントやライセンス、データへのアクセス権の準備が遅れ、最初の数日を作業できずに過ごすことがあります。個人情報を含むデータは、扱える場所や端末が限られることもあります。

対策：アカウントの発行時期、割り当てられるライセンスの種類、データへのアクセス権の申請の流れを参画前に確かめます。個人情報の扱いは個人情報を扱う業務委託の記事で整理しています。

お金でのつまずき

早朝の更新対応や月末の作業が精算されない

毎朝の更新が失敗したときの再実行や、月末・期末の数字の確定に合わせた作業は、決まった稼働時間の外に出やすい作業です。扱いを決めていないと、報酬に反映されないまま負担だけが増えます。

対策：更新の失敗の通知を誰が受け、何時までに対応するのか、稼働日以外の扱いをどうするかを参画前に決めておきます。稼働は日々記録し、精算幅を超えそうな段階で窓口に伝えます。精算の仕組みは精算幅の記事で解説しています。

導入や移行の区切りで契約が終わる

移行が終わった、社内の担当者に引き継げた、という節目で契約が更新されないことがあります。フリーランス法では、6か月以上の業務委託をしている発注事業者が契約を解除したり更新しなかったりする場合、少なくとも30日前までに予告しなければならないとされています（2026年10月時点、公正取引委員会の特設サイトによる）。

対策：契約期間と、導入や移行の工程の区切りを並べて見ておき、更新の見込みを早めに確かめます。契約期間の考え方は契約期間の記事をご覧ください。

よくある質問

参画してから、聞いていた作業と違うと気づきました。どうすればよいですか？

まずは、何が違うのかを具体的に書き出し、契約で決めた業務範囲と照らし合わせます。そのうえで、紹介を受けたエージェントや取引先の窓口に早めに伝えてください。我慢して続けると、範囲の外の作業が当たり前になり、後から戻しにくくなります。

画面の数字の誤りで損害が出たら、賠償を求められますか？

準委任契約では、成果そのものを約束しているわけではありません。ただし、契約の内容や、作業の進め方に落ち度があったかどうかで判断が変わることがあります。不安がある場合は、契約書の損害賠償の条項を読み、弁護士などの専門家にご相談ください。

業務部門と指標の定義で意見が割れたときは、どうすればよいですか？

それぞれの定義で数字がどう変わるかを並べて示し、どれを使うかは取引先に決めてもらいます。決まった定義と、自分が示した影響は記録に残しておくと、後で経緯を確かめられます。