データガバナンス案件の単価相場｜データカタログ実務と探し方・参入ルート

データガバナンス案件とは何をする仕事か

結論として、データガバナンスは「データを管理するルールと体制を決める活動」であり、データカタログはそのルールを日々の業務で参照できるようにする実装手段です。両者はセットで案件になります。

条件として、案件が成立するのはDWHやデータレイクがすでに動いている企業です。基盤がない段階でガバナンスだけを先に整えるプロジェクトは、フリーランス向けの公開募集で見る限りでは少数にとどまります。例外は、複数社の統合やシステム刷新にあわせて基盤とガバナンスを同時に作るケースです。

データマネジメントの中でのガバナンスの位置づけ

データマネジメントの知識体系としては、DAMA International がまとめた DMBOK（Data Management Body of Knowledge） が国内でもよく参照されます。DMBOK ではデータ管理を複数の知識領域に分け、データガバナンスをそれらの中心に置く構造をとっています。

案件の現場でこの体系がそのまま使われるわけではありません。ただ、提案や設計の場で「品質」「メタデータ」「セキュリティ」を別々の論点として切り分けて話せると、議論が進みやすくなります。

データカタログとメタデータ管理の関係

データカタログは、社内に散らばるテーブル・カラム・ダッシュボードの情報を1か所に集めた目録です。集める対象がメタデータで、大きく2種類あります。

案件で難しいのは後者です。テクニカルメタデータの自動収集は設定作業で片づきますが、ビジネスメタデータは人に書いてもらう仕組みを設計しないと埋まりません。カタログが「入れたのに使われない」状態になる原因の多くはここにあります。

データ基盤構築案件との違い

データ基盤の構築案件は、パイプラインを組んでデータを流すところが主戦場です。レイヤー別の役割や単価の違いは『データ基盤案件の単価相場｜ETL・DWH・BIレイヤー別の目安とスキル』で整理しています。

対してガバナンス寄りの案件は、すでに流れているデータに意味と制約を与えるフェーズを担当します。実装量は基盤構築より少なく、関係者との調整が増えます。この違いは稼働の中身にも出るため、参画前に確認しておくと齟齬が起きにくくなります。

案件で実際に任される4種類の業務

募集要件を分解すると、おおむね次の4類型に収まります。1案件で全部を任されることは少なく、2つ程度の組み合わせが多い構成です。

カタログ導入・整備の実務

最初に決めるのは対象範囲です。全テーブルを一度にカタログ化しようとすると入力が終わりません。実務では、利用頻度の高いテーブルやダッシュボードから着手し、数十テーブル規模で先に形にするやり方がよく採られます。

接続設定そのものは数日で終わることもあります。時間がかかるのは、指標定義の表記ゆれを利用部門とすり合わせる工程です。「売上」がどの時点の金額を指すのかで部署ごとに認識が違う、といった話が普通に出てきます。

データ品質管理の実務

品質ルールは、NULL率・重複・値域・鮮度あたりから始めるのが定番です。dbt を使っている現場ではテスト機能で実装できるため、既存の変換処理に組み込む形になります。dbt そのものの仕組みは『dbtとは｜データ変換(ELT)の仕組み・使い方・案件単価』を参照してください。

ここでの判断ポイントは、違反を検知したときに止めるのか通知するのかです。止める設計にすると下流のダッシュボードが空になり、業務が混乱します。初期は通知にとどめ、重要テーブルだけ段階的に停止条件を付ける進め方が無難です。

アクセス権限・機密区分の設計

機密区分は3〜4段階に分けるのが扱いやすい粒度です。段階を増やすほど運用負荷が高くなり、形骸化しやすくなります。個人情報を含むデータを扱う場合、社内規程だけでなく法令上の取り扱いも確認が要ります。制度面は個人情報保護委員会の公表資料で確認できます。最終的な区分の決定や運用可否の判断は、企業の法務・情報セキュリティ担当に従います。フリーランスの立場では、方針案を出して確認を仰ぐところまでが役割になるケースが大半です。

なお、権限設計を任される案件では、DWH側の機能をどこまで使うかが論点になります。Snowflake や Databricks のようにプラットフォーム側で権限管理を持つ製品では、カタログツールと役割が重なるためです。各製品の基本は『Snowflakeとは？データクラウドの特徴・BigQueryとの違い・案件動向をフリーランス視点で解説』『Databricksとは｜レイクハウスの仕組み・Snowflakeとの違い・案件単価』でまとめています。

データスチュワード運用の立ち上げ

データスチュワードは、各部門でデータの意味や品質に責任を持つ担当者です。国内企業の導入初期では兼務で置かれることが多く、「片手間でも回る運用」に落とし込めるかが案件の成否を分けます。専任体制を敷く企業もありますが、その場合は社員が担い、フリーランスは立ち上げ支援に回る構図になりやすいです。

月1回の定例で棚卸しをする、新規テーブル作成時にカタログ登録を必須にする、といった軽い仕組みから始める案件が多い印象です。

この章のミニFAQ

Q. データガバナンス案件に分析スキルは必要ですか。

統計や機械学習の知識は必須ではありません。ただし、利用部門が何を見たいのかを理解できないと指標定義の議論についていけないため、BIツールでダッシュボードを読める程度の素養はあった方が進めやすくなります。

Q. ツールを触ったことがなくても応募できますか。

カタログ製品の経験を必須にしない募集もあります。その場合、DWHの権限設計やデータ品質チェックの実装経験が代替として見られるケースが多いです。

単価の目安と、母集団の条件

まず短答を書きます。週4〜5日の準委任で月70〜110万円前後が中心帯です。全社横断の設計や他ベンダーとの調整まで含むポジションでは、月100〜140万円前後で募集されるケースも見られます。

以下の数字の前提を分けて書きます。本記事の単価は、2026年9月時点で主要フリーランスエージェント数社の公開案件ページを横断確認し、データガバナンス・データカタログ・メタデータ管理・データ品質に関連する要件を含む募集を観測ベースで整理した目安です。対象は首都圏・週4〜5日・準委任・実務経験3年以上相当の募集に絞り、同一案件が複数サイトに重複掲載されている分は除いています。

金額はいずれも税別・月額での表示で、精算幅（時間清算の上下限）や出社比率の条件によって手取り感は変わります。この領域は専任の公開募集自体が多くなく、大半はデータ基盤・データエンジニア案件の要件の一部として現れます。そのため母集団は小さく、レンジは幅を持って読んでください。

役割別の単価目安

表の数字は同一企業内での比較ではなく、異なる募集を役割ごとに並べたものです。同じ役割名でも、対象データの範囲や関係部署の数で条件は変わります。

上振れする条件と、その条件を満たせる人の像

月120万円を超える帯で募集されるポジションには、共通しやすい傾向があります。

• 複数事業部にまたがるデータを対象にしている

• 情シス・法務・データ利用部門の三者と直接やり取りする

• カタログ導入だけでなく、運用ルールの策定と定着まで含む

これを任される人の経歴イメージは、データ基盤の構築経験が5年以上あり、社内標準の策定や他部署への説明を担当した経験がある層です。事業会社のデータ基盤チームでリードを経験した人や、SIerでデータ管理基盤の上流を担当していた人が該当しやすくなります。純粋な実装経験だけでこの帯に届くケースは多くありません。

なお、非公開案件については個別条件での提示になるため、上記の公開案件ベースの数字とは別に考えてください。公開されていない募集は、対象範囲や体制が特殊なことを理由に条件が変わることがあります。

自分がどのくらいの単価を狙えるか気になる方は、無料のフリーランスエンジニア単価診断で現在の市場単価の目安を確認できます。単価を体系的に上げる考え方は『【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？』で整理しています。

この章のミニFAQ

Q. データエンジニア案件と比べて単価は高いですか。

役割の範囲次第です。実装中心のポジション同士で比べるとほぼ同水準で、差が出るのは横断設計や合意形成まで担う場合です。データエンジニアの単価感は『データエンジニアの年収は？単価相場からフリーランスの報酬まで解説』にまとめています。

案件で出会いやすいツールと、その立ち位置

結論として、ツールは「DWHに付属するもの」と「独立したカタログ製品」の2系統に分かれます。どちらを使うかは、企業がすでに持っている基盤でほぼ決まります。

案件に入る前の確認として、Purview と Unity Catalog は競合ではなく併用されることがある点は押さえておくとよいでしょう。Databricks を Azure 上で動かしている企業では、両方が配置されている構成に出会います。役割分担としては、Databricks 内の権限・カタログは Unity Catalog、全社横断での資産把握は Purview という切り分けが典型です。どちらを主に触るかは、案件の対象範囲が「Databricks の中」か「全社」かで判断できます。

オープンソース製品を選ぶ案件では、構築だけでなく運用体制まで設計対象に入ることが多くなります。マネージドサービスと比べて工数が読みにくいため、稼働見積もりは慎重に出しておいた方が安全です。

データガバナンス案件の探し方

結論から書くと、エージェントの検索窓に「データガバナンス」と入れるだけでは案件はほとんど出てきません。専任枠の公開募集が少ないためです。

実務的な手順は次のとおりです。

1. 検索は「データ基盤」「DWH」「データエンジニア」で広く引く

2. ヒットした募集の要件欄・業務内容欄を開き、「データカタログ」「メタデータ」「権限設計」「データ品質」「データマネジメント」の語があるものを拾う

3. 面談で「ガバナンス領域の担当範囲がどこまで含まれるか」を直接聞く

この3段階を踏むと、同じ検索時間でも候補が増えます。要件の一部としてガバナンス業務が含まれている案件は、面談時に担当範囲を交渉できる余地があるのも利点です。

エージェント担当者に希望を伝える際は、職種名ではなく担当したい作業名で伝えると精度が上がります。「データガバナンスがやりたい」より「データカタログの導入と権限設計を担当したい」の方が、案件を探す側も要件欄と照合しやすくなります。

参入ルート（現在の立ち位置別）

データエンジニアからの参入

最短ルートです。すでにDWHとパイプラインを触っているなら、現在の案件でデータ品質チェックかカタログ整備を担当範囲に足すところから始められます。dbt のテスト実装や、テーブル定義の棚卸しは着手しやすい入り口です。

職種としての全体像は『データエンジニアとは？仕事内容・年収・将来性をわかりやすく解説』を参照してください。

情シス・社内SEからの参入

権限管理やアカウント統制の経験は、そのまま機密区分・ロール設計に転用できます。不足しがちなのはSQLとDWHの実務です。BigQuery や Snowflake でテーブルを作り、権限を付与し、クエリを書くところまで自力でできる状態を先に作ると、要件に乗りやすくなります。

SIer・コンサルからの参入

上流の設計経験と部門調整の経験は、この領域では強く評価されます。逆に、実装に一度も触れていない場合は「方針は書けるが実装できない」と見られることがあります。カタログ製品を1つ触って、接続とメタデータ収集まで自分で通した経験を作っておくと説得力が変わります。

なお、設計寄りの職種としてはデータアーキテクトが隣接します。役割の違いは『データアーキテクトとは｜仕事内容・年収・データエンジニアとの違い』で整理しています。

この章のミニFAQ

Q. 資格は案件獲得に効きますか。

国内で直結する資格は限られます。IPA は2026年3月31日のプレス発表で、2027年度からの新試験制度に「データマネジメント試験（仮称）」を新設する案を示しています。ただし発表時点では仮称であり、位置づけも主にビジネス部門を想定した、ITパスポート試験の次のステップとされています。フリーランスエンジニアの案件獲得を直接後押しする性質のものとは考えにくいため、資格より実案件での担当実績を優先するのが現実的です。

導入プロジェクトのフェーズと期間感

案件に入るときに稼働の読みを外しやすいのがこの部分です。フェーズごとの目安を置きます。

PoC で選定まで終えても、初期導入で対象範囲が広がって延びるのはよくある展開です。契約時に「どこまでを完了とするか」を成果物ベースで合意しておくと、後半の揉め事が減ります。

定着フェーズは成果が見えにくく、予算が切られやすい区間でもあります。案件を継続したい場合は、カタログの登録率や品質チェックの検知件数など、月次で見せられる指標を早い段階で用意しておくと説明がしやすくなります。

よくある失敗と対策

カタログが形骸化する

最も多い失敗です。ツールを導入して全テーブルを取り込んだものの、ビジネスメタデータが空のまま放置される状態を指します。

対策は範囲を絞ることです。利用頻度の高い数十テーブルに限定して、説明文の記入までやり切る方が、全件取り込んで空欄だらけにするより価値が出ます。入力を依頼する相手も、範囲が狭ければ協力を得やすくなります。

ガバナンスが「禁止ルール集」になる

権限を締めることばかりが進み、利用部門から「データが見られなくなった」と反発が出るパターンです。

対策として、制限と同時に「この条件なら自由に使ってよい」という許可の範囲を明示します。分類を作る目的は使わせないことではなく、安全に使える範囲をはっきりさせることだ、と初期の説明で共有しておくと進めやすくなります。

経営・部門の合意がないまま着手する

情シス単独で進めたカタログ導入は、利用部門の協力が得られず止まりがちです。フリーランスの立場では体制そのものを動かせないため、参画前に「誰がスポンサーで、利用部門の合意が取れているか」を確認しておくのが自衛策になります。

合意が曖昧な案件に入ってしまった場合は、成果を「全社導入」ではなく「特定部署での実績作り」に置き直す提案が有効なことがあります。

案件選定チェックリスト

参画前の面談で確認しておきたい項目をまとめます。この領域特有の論点に絞っています。

7項目のうち、スポンサーと対象範囲の2つは特に確認しておく価値があります。ここが曖昧な案件は、稼働の後半で成果を問われたときに説明が難しくなります。

具体的な募集内容を見たい場合は、フリコンの案件一覧でデータ基盤・DWH関連の要件を確認してみてください。前述のとおり「データガバナンス」の語だけで絞らず、要件欄の記述を読む方が見つかりやすくなります。

まとめ

データガバナンス案件は、ルールを決めてデータカタログに実装し、運用に定着させるまでを担う仕事です。専任募集は少なく、データ基盤案件の要件に含まれる形で出会うのが実情です。

• 業務は「カタログ整備」「データ品質」「権限設計」「スチュワード運用」の4類型に分かれ、実際は2つ程度の組み合わせで任される

• 単価は週4〜5日の準委任で月70〜110万円前後が中心帯。横断設計やリードを含むと月100〜140万円前後の募集も見られる

• 差がつくのはツール習熟より、情シス・利用部門・法務と合意を作った経験

• ツールは既存基盤でほぼ決まる。Databricks 環境なら Unity Catalog、Microsoft 中心なら Purview が候補に挙がりやすい

• 失敗の典型はカタログの形骸化。対象を数十テーブルに絞り、説明文の記入までやり切る方が価値が出る

• 案件探しでは「データガバナンス」単独の検索より、データ基盤・DWH案件の要件欄で「データカタログ」「権限設計」「データ品質」を拾う方が候補が増える

• 参画前にスポンサーの有無と初期対象範囲を確認しておくと、後半の説明責任で困りにくい

次のステップとしては、現在の案件でデータ品質チェックかメタデータ整備を担当範囲に加えられないか、確認してみてください。1案件ぶんの実績があれば、要件に「データカタログ」を含む募集に応募できる状態になります。

参照した一次情報は次のとおりです。

• IPA プレス発表（2026年3月31日）情報処理技術者試験における試験区分体系などの見直し（案）について

• DAMA International – Body of Knowledge（DMBOK）

• 個人情報保護委員会

• Databricks Unity Catalog ドキュメント

• Microsoft Purview ドキュメント