PowerAppsの案件にフリーランス（業務委託）として参画した初日、共有されたアプリの一覧を開くと、作成者の欄に情シスではない部署の人の名前が並んでいます。最初の打ち合わせで「この申請アプリ、項目を1つ足していただけますか」と頼まれ、作った本人に聞かずに直してよいのか、返事に迷います。最初の数週間で見られているのは、直す腕前より先に、そのアプリを誰が持っているかを読み取る姿勢だと、この記事は考えます。PowerAppsの参画初期は、直す前に作り手を確かめます。

1. 最初の数週間に見られていること

作り手と持ち主が別にいる現場

業務部門の人が自分たちの仕事のためにアプリを作る現場では、アプリを作った人と、そのデータの置き場所や運用を持つ人が別々にいることがあります。外から入るエンジニアは、その間に立つ形で参画します。ここから先は資料に書かれた事実ではなく、書き手の見立てです。

この見立てが外れる現場もあります。作り手が情シスの人である参画先や、運用まで業務部門が持っている参画先もあるからです。そのため、最初に確かめる対象は特定の部署ではなく、アプリごとの「誰がどこまで持っているか」です。

冒頭の「項目を1つ足していただけますか」という依頼も、頼んだ人がアプリの作り手なのか、使う側なのかで返事が変わります。作り手なら、足したい理由と使い方を聞けば済みます。使う側なら、作り手に連絡を取る経路を先に教わる流れになります。

数週間を4つの段階に分けて進める

参画後の数週間は、書き手の見立てでは次の4つの段階に分けると進めやすくなります。まず人を確かめ、次に渡された権限を確かめ、その後で小さな修正を約束し、最後に引き継げる形を残す順番です。

図の作成：Remogu編集部。書き手の見立てを整理したもので、統計データではありません

1段階目は、アプリの作り手と、データや運用の持ち主を聞き出す作業です。2段階目では、渡されたIDで何ができるのか、そのIDをいつまで使うのかを管理する人に確かめます。3段階目で初めて、頼まれた修正の範囲と日付を、頼んだ人と合意します。

4段階目は、手順を残して返すものを返す場面です。ここを最初から意識して参画すると、数週間後の引き継ぎが「何を返すのか」の話から始まらずに済みます。次の節では、この1段階目に出てくる「市民開発」という言葉を資料で確かめます。

2. 業務部門が作るアプリを指す市民開発

資料での市民開発の説明

香川大学の情報部情報システム課によるポスター資料は、市民開発を、非情報人材である事業部門がローコード・ノーコードプラットフォームなどを用いてシステム開発をおこなう活動と説明しています¹。参画先で業務部門の人がアプリを作っている状況は、この説明に近い場面です。

ただし、この資料にPowerAppsの名前は出てきません。ここで確かめているのは、業務部門が自分でシステムを作る活動が「市民開発」と呼ばれているという、言葉の意味だけです。香川大学がどのツールを使っているかは、資料からは分かりません。

取組状況の報告の件数

同じ資料は、香川大学のDX推進研究センターが依頼したデジタルONEアンバサダーによる取組状況の報告が、2025年度に92件、2022〜2025年度の合計で324件あったとしています¹。92件は2025年度の分で、324件は2022〜2025年度の合計です。

数えられているのは、報告の件数です。作られたアプリの本数や、いま動いているアプリの数ではありません。さらに、これは1つの大学の事例で、企業一般の数字として読むことはできません。

資料から読み取れる項目

次の表は、香川大学の資料にある市民開発の説明と、取組状況の報告について、誰が報告し、誰が依頼したかを並べたものです。件数は報告の数であり、アプリの本数とは別のものとして読みます。

項目	資料の内容
市民開発の説明	非情報人材である事業部門が、ローコード・ノーコードプラットフォームなどを用いてシステム開発をおこなう活動
取組状況を報告した人	デジタルONEアンバサダー
報告を依頼した組織	DX推進研究センター
2025年度の報告	92件
2022〜2025年度の合計	324件（報告の件数であり、アプリの本数ではありません）

この表を参画先に当てはめるなら、確かめたいのは「作る側」「報告や依頼を受ける側」がそれぞれ誰かという点です。香川大学の仕組みがそのまま参画先にあるわけではないので、あくまで聞き方の手がかりとして使います。

3. 作る人・運用を持つ人・外から入る人の立ち位置

資料が示すフュージョン開発の3つの役割

香川大学の資料のフュージョン開発の図は、プロ開発者・ITプロフェッショナル・市民開発者という3つの役割を示しています¹。このうちITプロフェッショナルは、「システムの運用・保守・セキュリティなどライフサイクル管理を担当する情報技術の専門家」と説明されています¹。

アプリを作る人と、運用や保守やセキュリティを持つ人を別の役割として描いている点が、この図の読みどころです。冒頭の場面でいえば、作成者の欄に並ぶ名前は市民開発者の側、データや権限を管理する人はITプロフェッショナルの側に当たります。

外から入るエンジニアの立ち位置

資料が示しているのは役割の区分です。フリーランスのエンジニアがどの役割に当たるかは、資料には書かれていません。ITプロフェッショナルの役割をフリーランスが担うとは、資料は言っていません。

図の作成：Remogu編集部。役割の区分は香川大学の資料のフュージョン開発の図をもとに整理し、点線の位置づけは書き手の見立てです

書き手の見立てでは、外から入るエンジニアの立ち位置は、頼まれる仕事によって変わります。アプリの機能を直す依頼ならプロ開発者に近く、データの置き場所や変更の手順に触れる依頼なら、運用を持つ人の領域に入ります。

そのため、修正を頼まれたら、運用を持つ人にも話を通す必要があるかを最初に聞いておく価値があります。作り手に聞いて終わりにせず、データを管理する人の了解が要る変更かどうかまで確かめる、というのが見立ての中身です。

4. 広げる段階で支える、業務を知る人

香川大学のスーパーバイザー

香川大学は、各部門の業務に精通した課長職等の管理職をスーパーバイザーとして任命し、内製開発したシステムの全学展開や、運用にのせるための規則改正などを支えているとしています¹。これは香川大学の体制の説明です。

参画先に同じ役職があるとは限りません。資料から言えるのは、内製開発したシステムを広げる段階や運用にのせる段階で、業務に精通した人が支える仕組みを置いている大学がある、という点までです。

参画初期に確かめる相手

書き手の見立てでは、作り手の手を離れて別の部署に広がるアプリには、業務を知る支え手がいる場合があります。こうした支え手の有無は、頼まれた修正が一部門のものか、ほかの部署にも広がるのかを見分ける手がかりになります。

次の表は、参画初期に話を聞く相手と、その相手に聞く内容を3つに分けたものです。香川大学の資料の体制を参画先に求めるのではなく、聞く相手が誰かを見つけるための整理として使います。

確かめる相手	聞くこと
アプリの作り手	何のために作ったか
業務を知る支え手	ほかの部署へ広げる予定と、規則の変更の有無
運用を持つ人	データの置き場所と、変更の手順

3つの相手が同じ人のこともあります。その場合は、1人に3つの質問をまとめて聞く形で構いません。反対に、相手が見つからない項目があれば、その項目を誰に聞けばよいのかを聞き返すところから始めます。

では、渡された開発用のIDと権限は、どのように受け取ればよいのでしょうか。

5. 開発用IDと権限は、返し方まで決めて受け取る

自治体ガイドラインの例文にある流れ

総務省の「地方公共団体における情報セキュリティポリシーに関するガイドライン」は、地方公共団体が自らのポリシーを定める際の参考として示されたものです。ここで読むのは、その例文に書かれた開発用IDの扱いです。民間の案件の参画先に当てはまる決まりではなく、受託者の義務として書かれた箇所でもありません。

例文では、情報システム管理者がシステム開発の責任者及び作業者を特定し、システム開発のための規則を確立する、と定めています²。作業する人を誰にするのかを、管理する側が先に特定する流れです。主体は地方公共団体の情報システム管理者です。

続けて例文は、情報システム管理者が責任者及び作業者の使うIDを管理し、開発完了後に開発用IDを削除する、と定めています²。IDの管理から削除までが、同じ管理者の役割として並んでいます。削除の時期は、開発が終わったあとです。

もう1つ、例文には定期的な確認の定めもあります。統括情報セキュリティ責任者及び情報システム管理者は、主体から対象に対する不要なアクセス権限が付与されていないか、定期的に確認しなければならないとされています²。開発の途中でも、不要な権限が残っていないかを見直す流れです。

図の作成：Remogu編集部。総務省ガイドラインの例文にある管理者の役割を、流れの形に並べ直したものです。並べ方は編集部の整理です

民間の案件で確かめたい点

ここからは、書き手の見立てです。民間の案件でも、開発用のIDを誰が管理し、いつ誰が削除するのかを確かめる価値があります。例文の主体は自治体の管理者ですが、渡されたIDにも持ち主がいて、いつかは使い終わる点は、参画先が民間でも変わらないからです。

ただし、開発用IDの削除は、例文では開発完了後の話です。参画して間もない時期に決めておけるのは、削除そのものではなく、誰がいつ削除するのかという段取りまでです。渡されたIDの期限があるのか、削除は参画先の誰が行うのか、といった質問が、最初の数週間の範囲に収まります。

権限の範囲を細かく決める話は、別の記事で詳しく扱っています。セキュリティ権限の範囲の決め方と合わせて読むと、渡された権限のうち何を使い、何を返すのかを整理しやすくなります。

では、こうした確認事項を、最初の数週間のうちにどう並べておけばよいのでしょうか。

6. 最初の数週間で確かめることの一覧

人とデータの持ち主

これまでの節で出てきた確認事項は、書き手の見立てで6つにまとまります。アプリの作り手と持ち主、データの置き場所、共有の範囲、開発用IDの期限と削除する人、変更を承認する人、作り手への連絡の経路です。どれも、参画した最初の週から数週間のあいだに、少しずつ聞いていけます。

確かめること	聞き方の例
アプリの作り手と持ち主	このアプリを作ったのは誰か、データや運用を持つのは誰か
データの置き場所	アプリが読み書きするデータは、どこにあるのか
共有の範囲	このアプリを使える人は、どの範囲までか
開発用IDの期限と削除する人	渡されたIDはいつまで使うのか、削除は誰がいつ行うのか
変更を承認する人	修正の内容を了承するのは誰か
作り手への連絡の経路	作り手に聞きたいとき、どの手段で連絡するのか

この6つは、資料から導いた決まりではなく、聞き忘れを減らすための書き手の整理です。参画先によっては、すでに文書で渡されている項目もあります。その場合は、文書の内容と実際の運用が合っているかを、担当の人に聞き返す形で足ります。

聞く順番と一人目の立場

聞く順番は、人から先に、データと権限はその次に、という流れが取り組みやすくなります。作り手と持ち主が分かれば、データの置き場所や共有の範囲は、その人たちに聞けるからです。IDの期限と承認する人は、頼まれる修正が見えてから聞いても間に合います。

外部の人が一人目として入る現場では、聞く相手を自分で探すところから始まることもあります。内製化の途中で外部エンジニアが最初の1人になる場面の考え方は、内製化支援で一人目の外部エンジニアになるときの記事で整理しています。

では、6つを確かめたあと、信頼はどのように積み上がっていくのでしょうか。

7. 小さな約束を守って信頼を積む

直す範囲を先に合意する

書き手の見立てでは、参画初期の信頼は、大きな成果より小さな約束の積み重ねで決まります。作り手を確かめ、直す範囲を合意し、約束した日に小さく出し、手順を残して返す。この順番を守ると、頼んだ側は、次の依頼もこの人に任せられると判断しやすくなります。

冒頭の「項目を1つ足していただけますか」にも、この順番が使えます。まず依頼した人に、そのアプリの作り手かどうかを聞きます。次に、項目を足す範囲と日付を合意します。データの置き場所に触れる変更なら、運用を持つ人にも話を通すところまでを、約束に含めます。

図の作成：Remogu編集部。書き手の見立てを順番に並べたもので、統計データではありません

手順を残して返す

最後の段の「手順を残して返す」は、修正の内容と、触ったデータや権限を、次に見る人が追える形で残すことです。作り手に返すのか、運用を持つ人に返すのかは、最初に聞いた「持ち主」の答えで決まります。ここで返し方が決まっていれば、数週間後の引き継ぎで慌てずに済みます。

VBAなどで作られた業務の道具を別の形へ移す場面でも、同じ順番が使えます。移行先の選び方は、VBAの移行先の選び方の記事で扱っています。作り手と持ち主を聞くところから始める点は、PowerAppsの現場と変わりません。

Remogu（株式会社LASSIC運営）は、リモートワーク案件特化のエンジニアマッチングで、案件の90%以上がフルリモート可能です。業務部門と情シスのあいだに立つ参画では、最初の数週間の動き方が、その後の任され方を決めます。PowerAppsの参画初期は、直す前に作り手を確かめます。

8. よくある質問

「PowerApps」と「Power Apps」はどちらの表記で書けばよいですか

製品名は「Power Apps」と間をあけて書かれることがあります。一方で、検索では「PowerApps」と続けて書かれることが多く、この記事は検索で使われる表記に合わせました。職務経歴書などに書くときは、参画先の資料で使われている表記にそろえると、誤解が生まれにくくなります。

業務部門の人が作ったアプリを直すときに気をつけることは何ですか

書き手の見立てでは、触る前に、作り手に何のために作ったアプリなのかを聞き、直す範囲を合意してから手を入れます。作り手に聞かずに直すと、使っている人の手順が変わる場合があります。データの置き場所や変更の手順に関わる直し方なら、運用を持つ人の了承も取ります。

参画初期に渡された権限が不足しているときはどうすればよいですか

書き手の見立てでは、必要な理由と使う期間を添えて、権限を管理する人に頼みます。総務省ガイドラインの例文は、開発用IDを管理する役割と、開発完了後に削除する役割を、情報システム管理者に置いています²。民間の案件でも、使い終わったら返す前提を最初から共有しておくと、頼まれた側も判断しやすくなります。

権限の追加は、頼まれた修正の範囲に必要な分だけにします。範囲が広がりそうなときは、先に承認する人へ相談します。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 香川大学「香川大学デジタルONEアンバサダー」（2026年8月・2026年10月確認）
＊2 総務省「地方公共団体における情報セキュリティポリシーに関するガイドライン」（2025年3月28日・2026年10月確認）