Dataverse の所有者を個人にするな — 主語のない言語が要請する、チーム所有 + 担当者の設計

「このレコード、誰のだっけ」が日本企業で必ず起きる

Power Platform で業務システムを作るとき、私が最初に決めるのは Owner の設計方針です。ここを間違えると、半年後に必ず詰みます。

Dataverse の標準は、レコード作成者がそのレコードの Owner になります。海外発のプラットフォームなら自然な発想です。英語は主語がないと伝達できない言語なので、「This is my record.」と所有関係を必ず明示する。Owner が個人に紐づく設計は、この言語構造と整合的です。

ですが日本語は違います。日本語は主語がなくても通じる言語です。「あの件どうなった」で業務が回る世界では、Owner を個人に紐づける必然性そのものが薄い。そして日本企業の現場で Dataverse を標準のまま運用すると、半年から1年で破綻します。退職、異動、組織再編。Owner として設定されたユーザーが、いつの間にか「そのレコードの責任者」ではなくなっている。なのに権限だけは残り続けている。

「このレコード、誰のだっけ」が会議室で繰り返される。誰も明確に答えられない。Dataverse の Owner 列を見ても、退職者の名前が並んでいる。私はこの光景を何度も見てきました。

主語のある言語、主語のない言語

なぜ日本企業でだけこの問題が顕在化するのか。私はここに、言語の構造の違いがあると考えています。

英語では、文に主語が必須です。「This is my record.」「Whose task is this?」「She owns this account.」。所有関係を表現するときに、誰が所有しているかを必ず明示する文法構造になっている。

日本語はそうではありません。「あの件どうなった」「これお願いします」「明日までに出しといて」。主語を省略しても会話が成立する。誰がやるか、誰が持っているかは、文脈で察する。

これは単なる言語の癖ではなく、業務上の所有感覚そのものに影響していると思っています。英語圏では「I」と「You」と「She」の関係で仕事が回るから、システム上も個人帰属が自然に表現される。日本語圏では「うちのチーム」「あの部署」「営業のほう」で仕事が回るから、個人を特定するより組織単位で扱う方が自然です。

Dataverse の Owner は、前者の言語と業務文化を前提に設計されています。

日本企業は、組織で仕事を持つ

もう少し踏み込みます。日本企業の業務は、組織が仕事を持ち、人はそのとき担当しているだけ、という構造が一般的です。

担当者が変わっても、業務は組織に残り続ける。前任者から後任者へ引き継ぐとき、引き継がれるのは「業務そのもの」であって「個人の所有物」ではない。むしろ「個人の所有物として扱う」と引き継ぎが揉める。

海外は逆で、人と職務がセットになっている。「This is John’s territory.」と言えば、John が異動すれば territory ごと移る。個人帰属が前提で組織が組まれている。

日本では、職務が組織にあります。組織から離れた個人がレコードを持ち続けるという状態は、業務文化的にも不自然です。「私の仕事」ではなく「うちの部署の仕事」だからです。

Dataverse の Owner を個人にすると、この感覚と真っ向からぶつかります。

異動が、所有者概念を完全に破壊する

退職は、まだ機械的に対処できます。退職者の Owner レコードを一括移管する運用を組めば、痛みはあれど解決はする。

ですが異動は違います。これが本当に厄介です。

異動が起きると何が起きるか。人はそこにいるのに、役割が変わっている。

営業1課から経理部に異動した A さんを考えてみます。A さんは Dataverse 上、営業案件レコードの Owner です。異動先の経理部では、もう営業案件には触らないはずです。なのに Owner として権限を持ち続けている。

逆もあります。経理から営業に異動してきた B さんは、まだ営業案件レコードの Owner ではない。でも今日から営業案件を回す必要がある。誰かが手動で B さんに権限を付けないと仕事が始まらない。

これを全レコード × 全異動者で回すのが、運用担当の悪夢です。役割が変わったから所有も変えるべきなのに、Dataverse の Owner は「人」に紐づいているから、人の役割が変わっても自動で追従しない。

所有者の概念が完全に崩壊します。「持っている人」と「責任を持つべき役割」が乖離する。

日本企業は異動が頻繁に起きます。3年ローテーション、組織再編、子会社化、出向。海外のように人と職務が固定で動かない前提では設計できません。

Dataverse の Owner 仕組みおさらい

ここで Dataverse の Owner の仕組みを整理しておきます。

Dataverse の Owner 列は、レコードあたり1つ。User 所有か Team 所有かの二択です。テーブル定義時に「ユーザーまたはチーム所有」か「組織所有」かを選び、組織所有を選ぶとそもそも Owner 概念がなくなり全社共有になります。

セキュリティロールは Owner と密接に連動します。「自分が所有するレコード」「自分のチームが所有するレコード」「事業部内のレコード」「組織全体のレコード」というアクセス階層がロール定義に組み込まれている。

この設計は明らかに、個人が仕事を持ち、その個人がチームに所属し、チームが事業部に所属する、というツリー構造を前提にしています。所有は個人がデフォルト、チーム所有は例外、という思想が透けて見えます。

この思想は、英語圏の業務文化を素直に反映している。間違ってはいません。ですが、日本企業の業務感覚とは合いません。

Microsoft の見落とし — 「作成者の所属チームを Owner にする」が標準にない

ここが Dataverse の重要な落ち度だと、私は思っています。

「レコードを作成した人の所属チームを、自動で Owner に設定する」という機能が、Dataverse の標準UIにありません。

これがあれば、日本企業の業務感覚にだいぶ近づきます。レコードを作るのは個人だが、所有はその個人の所属チームへ自動的に紐づく。担当者が異動しても、チームに残ったレコードはチームが管理し続けられる。

ですが標準にはない。やりたければ Power Automate でトリガを組むか、Plugin で実装するしかない。テーブルを作るたびに、誰かが自前で同じロジックを書く羽目になります。

これは Microsoft が、日本企業特有の組織所有文化を考慮できていない証拠だと思っています。海外発プラットフォームの文化的盲点が、ここに露呈しています。

私が現場で採用している設計パターン

ではどうするか。私は現場でこのパターンを採用しています。

Owner = 部署別チーム（固定運用、個人にしない）
担当者 = カスタムルックアップ列（systemuser テーブルへの参照）
担当者は変更可、Owner は原則不変

これにより、

異動者が出ても、Owner は変わらない（チームのまま）
担当者を付け替えるだけで業務継続できる
退職時は、退職者を担当者にしていたレコードの担当者列を更新するだけ
セキュリティ境界が組織単位で安定し、ロール設計がブレない
「このレコード、誰のだっけ」が「担当者列を見れば一発」になる

組織変更があったときも、影響範囲がチーム単位で予測できます。個人 Owner だと、全レコードを走査して「この人 Owner どうしよう」を毎回検討する必要がありますが、チーム所有なら「この部署が無くなるからこのレコード群はあの部署に移す」という単位で扱えます。

担当者カスタム列の名前は、業務領域に合わせて決めればよいです。「営業担当」「主担当」「窓口」「PIC」など。1つの列にするか、主担当・副担当に分けるかは、業務の複雑度次第です。

実装の最小構成

Power Automate で組む場合の最小構成は、

トリガ: Dataverse 「行が追加されたとき」（対象テーブル指定）
アクション: 作成者の所属チームを取得（GetUserTeams API or systemuser テーブルから引く）
アクション: Dataverse 「行を更新する」で Owner 列にチームを設定

Plugin で組む場合は、PreCreate or PostCreate イベントで同じことをやります。フローよりトランザクション保証が強く、権限不足のリスクも避けられます。本格運用なら Plugin 推奨です。

カスタム担当者列の運用上の注意点として、

ビュー・フィルタで多用するなら、検索可能列にしてインデックスを効かせる（このあたりの設計を怠るとビューが重くなります。詳しくはモデル駆動アプリが重い・ビューが遅い問題の切り分けと改善で扱いました）
担当者列が空のレコードを残さない運用ルール（必須化、または既定値設定）
担当者を変更する操作を、フォーム上から1クリックでできるようにする（業務UXとして重要）

このあたりは Phase が進んだ後の運用設計の話なので、初期実装では Owner = チーム、担当者列の追加、Power Automate の自動設定、までを揃えれば十分です。

海外発の道具を、日本の業務感覚で使う

Dataverse は強力なプラットフォームです。ロール、アクセス制御、リレーション、自動化、どれも完成度が高い。だからこそ、その設計思想を理解した上で、日本の業務文化に合う使い方を組み立てる必要があります。

標準のまま、海外お手本通りに使うと、日本企業では必ずどこかで詰みます。個人 Owner が異動と退職で崩壊する、というのはその典型例です。

ですが Dataverse を捨てる必要はありません。Owner はチーム、担当者は別列。たったこれだけのパターンで、異動にも退職にも組織再編にも耐えられる業務システムが組めます。

海外発の道具と、日本の業務現場との隙間。ここを埋めるのが、スルガクラフトの仕事です。