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

フリーランスのPower Platformエンジニアがつまずきやすいのは、作ったものの所有者と接続を誰のアカウントにするか、データポリシーとの衝突、利用部門の要望の膨らみ、納めた後の問い合わせ対応がいつの間にか無償になることです。どれも、Power Platformが「誰でもすぐ作れる」製品であるために、作る前の取り決めが後回しになりやすいことから起きます。

対策の基本は、作り始める前に、置き場所・持ち主・範囲の3つを言葉にして合意しておくことです。この記事では、契約・現場・技術・お金の順に、Power Platformならではの場面と対策を整理します。契約で確かめる項目の一覧はPower Platformの案件の選び方で扱っているので、ここでは「実際に起きやすい場面」に絞ります。

契約でのつまずき

「アプリ作成」の範囲があいまいなまま始まる

契約書には「Power Appsによる業務アプリの作成」とだけ書かれ、現場では、フローの作成、Dataverseの設計、社内の作成者への説明会まで期待されていた、という食い違いは起きやすい場面です。Power Platformは製品同士がつながっているため、一つ作ると隣の作業も自然に頼まれます。

対策：参画前に、担う成果物（アプリ、フロー、テーブルの設計、操作の手引きなど）と、担わないもの（社内の作成者が作ったものの保守、ライセンスの手配など）を言葉で確かめておきます。範囲の外の依頼が来たときの扱いは業務範囲が変わったときの記事と追加の依頼の断り方をご覧ください。

請負なのに「使いながら直す」進め方になる

Power Platformの作り方は、試作を見せて直す流れが向いています。ところが契約が請負で、完成の基準が決まっていないと、直しが終わらず検収が延びることがあります。逆に準委任なのに「完成させてほしい」と求められることもあります。

対策：契約の形と進め方が合っているかを、署名の前に確かめます。違いは準委任と請負の違いの記事で解説しています。請負なら完成の基準と直しの回数、準委任なら稼働の上限と報告の形を決めておきます。

指揮命令の形が社員と変わらなくなる

社内の作成者と同じ席で、利用部門の担当者から直接細かな作業を指示されるうちに、準委任の契約と実態がずれてくることがあります。考え方は偽装請負の記事で解説しています。

現場でのつまずき

利用部門の要望がどんどん膨らむ

試作を見せると、利用部門から「この項目も」「この帳票も」と要望が出てきます。一つひとつは小さくても、積み重なると最初に決めた期間に収まらなくなります。

対策：要望は、その場で受けずに一覧に積み、優先度を発注側の責任者に決めてもらいます。「最初の版で入れるもの」と「次の版以降」を分けて見せると、相手も判断しやすくなります。

社内の作成者との境目があいまいになる

市民開発が進んでいる組織では、社内の作成者が作ったフローを「ついでに見てほしい」と頼まれることがあります。引き受けると、自分が作っていないものの不具合まで責任を持つ形になりがちです。

対策：社内の作成者への支援を業務に含めるか、含めるならどこまでか（質問への回答のみ、レビューまで、直すまで）を先に決めておきます。

情報システム部門と利用部門の間で板挟みになる

利用部門は早く作りたい、情報システム部門は統制を守りたい、という立場の違いはよくあります。外部のエンジニアは、その間で「どちらの言うことを聞けばよいか」に迷いやすくなります。

対策：参画の初期に、環境の使い方や接続の可否を最終的に決めるのは誰かを確かめておきます。最初の1か月の進め方はPower Platformエンジニアの参画初月にやることで整理しています。

技術でのつまずき

作ったものと接続が自分のアカウントにひもづく

自分のアカウントでアプリやフローを作り、接続も自分の資格情報で張ったまま本番で動かすと、契約が終わってアカウントが止まった時点で動かなくなるおそれがあります。データポリシーの説明でも、接続は保存された資格情報を表し、アプリやフローのある環境に格納されるとされています（2026年10月時点、Microsoft Learn）。

対策：本番で動かすものの所有者と接続を、発注側のどのアカウントにするかを、作り始める前に決めます。離任の前には、所有者の移し替えと接続の張り替えを引き継ぎの項目に入れておきます。引き継ぎの進め方は引き継ぎの記事をご覧ください。

既定の環境で作り始めてしまう

Microsoft Learnでは、既定の環境はテナントごとに自動で作られ、ライセンスを持つすべてのユーザーに作成者の役割があり、実験や軽い試用を目的とした環境と説明されています。バックアップの保証がないため、本番の仕事には使わないよう案内されています（2026年10月時点）。手軽だからと既定の環境で作り始めると、後で移すときに手間が増えます。

対策：開発・テスト・本番の環境を分け、ソリューションに入れて作ることを最初に提案します。ALMの説明では、ソリューションはコンポーネントを環境から環境へ配布する仕組みで、ALMに参加するすべての環境にDataverseのデータベースが必要とされています（2026年10月時点）。環境がまだ分かれていない現場では、自分で決めずに発注側と方針を合わせます。

データポリシーの変更で、作ったものが止まる

データポリシーは、管理者がコネクタの使い方を制御する仕組みです。Microsoft Learnによると、ポリシーを変更すると、違反するアプリやフローは操作できない状態にされ、ブロックされたコネクタの接続は無効になります。変更が行き渡るまでの時間は多くの場合1時間以内、極端な場合で24時間とされています（2026年10月時点）。作った後にポリシーが変わり、本番のフローが止まることがあります。

対策：作り始める前に、使うコネクタがポリシー上どう扱われているかを管理者に確かめます。ポリシーの変更予定があれば、事前に知らせてもらえるよう窓口と話しておきます。

非推奨の機能の上に作ってしまう

Power Platformは、機能の入れ替わりが多い製品です。たとえば、Dataverse for Teamsの環境は2026年11月15日から新しく作れなくなり、Dataverseに上げていない環境は2027年9月15日に一時停止、2027年10月30日に廃止と案内されています（2026年10月時点、Microsoft Learn）。

対策：作る前に、使う機能が「予定されている重要な変更」の一覧に入っていないかを確かめます。すでに非推奨の機能で動いているものを引き継いだ場合は、移行の要否を発注側に早めに伝えます。

お金でのつまずき

納めた後の問い合わせ対応が無償になる

アプリを納めた後も、利用者から「動かない」「使い方が分からない」という連絡が個人宛てに届き続けることがあります。契約が終わった後に対応すると、報酬のない作業が積み上がります。

対策：契約の終わりに、問い合わせの窓口を発注側の誰に移すかを決めておきます。保守を続けるなら、別の契約として範囲と報酬を決めます。

稼働が精算幅を超えても伝えない

要望の膨らみや不具合の調査で、稼働が精算幅を超えることがあります。超えた分の扱いを決めていないと、報酬に反映されないまま負担だけが増えます。

対策：稼働を日々記録し、超えそうな段階で窓口に伝えます。精算の仕組みは精算幅の記事で解説しています。

フェーズの区切りで契約が終わる

立ち上げの案件では、最初の版を出したところで契約が終わることがあります。フリーランス法では、6か月以上続く業務委託を解除したり更新しなかったりする場合、発注側は原則として少なくとも30日前までに予告することになっています（2026年10月時点、公正取引委員会の案内による）。

対策：契約期間とプロジェクトの区切りを並べて見ておき、更新の見込みを早めに確かめます。考え方は契約期間の記事をご覧ください。

よくある質問

利用部門から直接頼まれた小さな修正は、引き受けてもよいですか？

小さくても、契約の範囲に入っているかを先に考えてください。範囲に入っていても、優先度を決める人が別にいる場合は、その人に伝えてから着手するほうが後のもめごとを防げます。範囲の外なら、窓口を通して扱いを決めてもらいます。

前任者のアカウントで動いているフローを引き継ぎました。どうすればよいですか？

まず、どのアプリやフローが誰の所有で、どの接続を使っているかを一覧にします。そのうえで、所有者の移し替えと接続の張り替えの計画を発注側と決めます。前任者のアカウントが止まると動かなくなるおそれがあるため、早めに伝えることをおすすめします。

作ったアプリに不具合が見つかったら、契約終了後も直す必要がありますか？

契約の内容によります。請負なら、契約不適合の責任の期間や範囲が契約書に書かれていることがあります。準委任なら、契約の終わった後の対応は別の契約で決めるのが一般的です。判断に迷う場合は、契約書の条項を読み、必要に応じて弁護士などの専門家にご相談ください。