Power Platformエンジニアのスキルシートの書き方｜面談で評価される実績の見せ方

Power Platformのスキルシートは、作ったものごとに「どの製品で」「データをどこに置き」「どこまでを自分で担ったか」をそろえ、本番への移し方と、作ったものの持ち主をどうしたかまで書くと伝わります。Power Platformは作る敷居が低い分、読み手は「組織の中で長く使える形にできる人か」を見ているからです。

この記事では、Power Platformならではの書き方のポイントを、架空の記入例とあわせて紹介します。全体の構成はスキルシートの書き方の基本、求められるスキルはPower Platformのスキルの記事で解説しています。

「Power Apps経験◯年」だけでは伝わらない

Power Platformの経験者のシートでよく見るのが、スキル一覧に「Power Apps（3年）」「Power Automate（3年）」とだけ書かれた形です。同じ3年でも、部署の申請アプリを一人で作ってきたのか、全社で使うアプリをDataverseで設計してきたのか、環境やデータポリシーを整えてきたのかで、まったく違う経験になります。

読み手が確かめたいのは、次の3つの組み合わせです。

• 製品：Power Apps（キャンバス・モデル駆動型）、Power Automate、Copilot Studio、Power Pagesなど
• データの置き場所：SharePoint、Excel、Dataverse、外部のデータベースなど
• 担った範囲：作成、設計、移送、ガバナンス、社内の作成者の支援のどこまでか

スキル一覧は、この組み合わせが見える形で書くと、読み手が案件の条件と照らし合わせやすくなります。

作ったものと担った範囲を分けて書く

Power Platformの案件では、作る人、設計する人、統制する人で求められる力が違います。プロジェクト欄では、次のように担った範囲を分けて書くことをおすすめします。

• 作成：決まった設計に沿って画面やフローを作った
• 設計：データの置き場所、テーブルの関係、権限、連携の方式を決めた
• 移送と運用：環境を分け、ソリューションで本番に移し、不具合に対応した
• ガバナンス：環境の分け方、データポリシー、作り方のルールを決めた
• 支援：社内の作成者からの質問に答え、作成物をレビューした

一人で全部を担ったなら、その旨を書きます。チームで分担したなら、自分の担当を明記します。

移送と持ち主の考え方を書く

Power Platformのシートで差がつきやすいのが、作ったものを本番にどう移し、誰の持ち物にしたかです。Microsoft LearnのALMの説明では、ソリューションを、アプリやフロー、テーブルなどの部品を環境から環境へ移すための仕組みとしています（2026年10月時点）。

シートには、たとえば次のような書き方ができます。

• 開発・テスト・本番の3つの環境を使い、ソリューションで移送
• 環境変数と接続参照を使い、環境ごとの設定の書き換えをなくした
• フローの所有者を共用のアカウントにし、担当者の異動後も動く形にした
• パイプラインで移送を自動化し、本番への反映を承認制にした

自分の個人用の領域で作って、そのまま使ってもらっていた経験しかない場合は、無理に書き足す必要はありません。その代わり、検証の環境でソリューションによる移送を経験し、学んだこととして書いておくと、面談で話を広げる材料になります。

業務がどう変わったかを書く

Power Platformの案件は、業務の改善が目的です。作ったものの説明だけでなく、業務がどう変わったかを書くと、読み手に価値が伝わります。

• 紙や表計算ソフトで回していた申請を、アプリと承認フローに置き換えた
• 手作業の転記をなくし、入力の間違いが減った
• 担当者しか分からなかった作業を、誰でも状況を確かめられる形にした

数字を書く場合は、社外に出せる範囲で、丸めた形にします。作業時間の削減などは、測り方があいまいなまま大きな数字を書くと、面談で根拠を聞かれて答えにくくなります。

記入例（架空）：判断が伝わる書き方

工程：新規構築（要件の整理〜運用、約6か月）
案件概要：製造業の品質管理部門 不具合の報告と是正の管理。表計算ソフトとメールで回していた報告を置き換え
規模：利用者は数百名規模、3つの工場の担当者が利用
役割：設計と作成の主担当（チーム3名、社内の担当者と共同）
担当内容：Dataverseでの報告・是正のテーブルと権限の設計。モデル駆動型アプリと、現場の入力用のキャンバスアプリの作成。是正の期限を知らせるフローの作成
判断した点：当初はSharePointのリストで作る案だったが、工場ごとに見せる範囲を分ける必要があり、Dataverseのセキュリティロールで管理する形を提案した
移送と運用：開発・テスト・本番の環境を分け、ソリューションで移送。フローの所有者は共用のアカウントにした
成果：報告の状況を部門の誰もが確かめられるようになり、社内の担当者が項目の追加を自分で行えるようになった

これは書き方を示すための架空の例です。業種、規模、判断の内容は、ご自身の経験に置き換えてください。

規模と統制の範囲は丸めた数で示す

Power Platformの案件では、規模によって求められる配慮が変わります。規模の欄には、次のような項目を丸めた数で書きます。

• 利用者の規模（数十名、数百名、数千名など）
• 管理した環境の数や、関わったアプリ・フローの数の桁
• 社内の作成者を支援した場合は、その人数の規模
• 連携した外部システムの数

テナントの名前、環境のURL、ライセンスの契約数などは、社外に出せない情報にあたることがあります。どこまで書いてよいかの考え方はスキルシートに書いてよいこと・いけないことをご覧ください。

認定資格の書き方

資格欄には、正式な名称、試験番号、取得年月を書きます。Power Platformの認定資格は2026年に入れ替わりが続いており、たとえばPower Platform開発者 アソシエイトは、必須の試験がPL-400からAB-400に切り替わりました（2026年10月時点、Microsoft Learnによる）。どちらの試験で取得したかが分かるように、試験番号まで書いておくと誤解がありません。

すでに廃止された資格を持っている場合も、取得した事実として書いてかまいません。ただし、有効期限が切れている場合は「取得年月」と「有効期限」を分けて正確に書きます。資格の数を増やすことより、資格と同じ分野の実務をプロジェクト欄で示すことが評価につながります。

他の経験の書き方

Power Platform以外の経験がある方は、それを別のプロジェクトとして書きつつ、Power Platformの案件に生きる要素を一行添えます。たとえば、業務システムの開発経験は外部連携やデータの設計に、社内の情報システム部門での経験はガバナンスや環境の管理に、それぞれ結びつけて書けます。要約の欄ではPower Platformの経験を上に置き、他の経験は補足の形にすると、応募の軸がぶれません。シートを更新するタイミングはスキルシートの更新の記事で解説しています。

よくある質問

社内の業務改善で作ったアプリしかありません。どう書けばよいですか？

社内の業務改善の経験も、十分な判断材料になります。どの業務を、どのデータの置き場所で、どこまで自分で設計したかを分けて書きます。利用者の声を聞いて直した回数や、運用で困ったことと対処を書くと、現場に寄り添える人として伝わります。

準委任の案件と請負の案件で、書き方は変わりますか？

書き方の型は同じですが、請負の案件では、自分が担った成果物と品質への責任の範囲を明確に書いておくと伝わりやすくなります。契約の形の違いは準委任と請負の違いの記事で解説しています。

Copilot Studioは検証しか経験がありません。書いてもよいですか？

書いてかまいません。ただし、本番で使われたものと検証で作ったものは分けて書きます。どの情報をナレッジに使い、どこで人に引き継ぐ設計にしたかを一言添えると、面談での説明につながります。