技術情報ブログ
Power Platform
2026.02.04

ローコードツール(Power Platform)を活用した官公庁での発注形態について:元自治体職員(地方公務員)が官公庁におけるローコードツールを活用したシステム開発の発注・契約方法について考えてみた

ローコードツール(Power Platform)を活用した官公庁での発注形態について:元自治体職員(地方公務員)が官公庁におけるローコードツールを活用したシステム開発の発注・契約方法について考えてみた
村上洋輔

アーティサンの村上です。

なぜこの記事を書いたか

昨今、各官公庁のDXが加速する中で、Power Platform をはじめとするローコードツールが注目されています。おかげさまで、弊社でも官公庁から Power Platform によるアプリ開発や、SharePoint によるポータルサイト構築のご相談をいただく機会が増えています。

打ち合わせを重ねる中で、仕様書作成や受託後の各フェーズにおいて、官公庁案件特有の「ローコード開発の難しさ」があると感じています。

これは、ローコードが官公庁に普及し始めてきたタイミングにおいて、「官公庁の発注・契約の仕組み」と「ローコードツール(ノーコード含む)の特性」が十分にマッチしていないことに起因する、これまでにない悩みや課題なのではないかと考えています。

本記事は、今後ローコードツールを活用した案件を発注される担当者様の一助となることを願い、ローコード開発案件を発注する際の観点を整理したものです。私自身の現時点でのベストプラクティスであり(正直、まだ正解は見えていません…)。皆さまからのご意見もいただきながら、官公庁のDXにおいてローコードツールがより良く浸透していくために、考え続けていければと思います。

 

ローコードツールの特性

ローコードツールの特性

Power Platform に代表されるローコードツールには、以下のような特徴があります。以下、ローコードツール=Power Platform として記載します。

メリット

  • 短期間で開発可能


    従来のフルスクラッチと異なり、UI パーツ(コントロール)やフローを直感的に組み合わせることで、簡易的なものであれば数日〜数週間でアプリの構築が可能です。

  • コストを抑えられる


    市民開発も可能なため、人件費や開発外注費の抑制が期待できます。

  • 業務部門主導の内製化


    小さな改善(変更・追加等)であれば情報システム部門や現場が内製で対応でき、運用の柔軟性が向上します。

デメリット

  • 万能ではない


    外部連携(API など)、複雑な画面制御、パフォーマンス要件などに制約があります。

  • ライセンス設計の重要性


    ユーザー単位のライセンス体系のため、ユーザー数が多い大規模展開ではランニングコストが増大する可能性があります。

  • プラットフォーム依存


    Microsoft 環境に最適化されているため、既存システムとの連携が難しい場合があります。

特に課題となるのは、上記の「万能ではない」という点です。身近な例でいうと、「注文住宅(自由設計)」ではなく「規格住宅」に近いとイメージすると分かりやすいかもしれません。ある程度は間取りや内装の色などは決められるけど、自由度は高くないといった所でしょうか。

 

現行の官公庁の「発注形態」とマッチしないと考える理由

現行の官公庁の「発注形態」とマッチしないと考える理由

官公庁における開発案件の多くは、一般(または指名)競争入札(価格競争)により発注されています。ローコード開発における価格競争の問題は、受託ベンダーの技術力やナレッジが評価軸に十分に反映されにくい点にあると考えております。

例えば建築工事であれば、各工種に於いて、国の基準もあり、設計図・仕様書があることで受注した建設会社の技術力に依存せず一定の品質が担保されることで、完成物に大きな差は生じにくいでしょう(手抜き工事は別として)。

更に、建築工事においては「最低制限価格」を設け、品質の低下を防いでいるケースもあると思います。

一方、ローコードは登場からまだ 10 年にも満たず、ベンダーによる開発力の差が比較的大きいと感じています。一定の制約のあるローコード開発に於いて、発注者の思い描いた仕様を満たすには、技術力、ナレッジ、提案力、ヒアリング力、デザイン力など、総合的な力が求められます。これらが不足すると、契約後に「仕様を満たせない」、「想定したデザインと違う」といった問題が生じやすくなると考えます。

 

現行の「契約形態」とマッチしないと考える理由

現行の「契約形態」とマッチしないと考える理由

官公庁における開発案件の多くは、請負契約に基づきます。簡単に言えば、あらかじめ定めた仕様書どおりの完成物を納品することを前提とする契約と認識しております。

この契約形態と、ローコードの開発スピードを活かした「アジャイル的な柔軟さ」は性質が相反すると考えます。請負契約で締結した場合、ローコードの制約によって仕様を満たせないときは「変更契約」などの手続きが必要になります。

とはいえ、仕様書作成時点でローコードの制約を加味した詳細な内容を担当者様が作成するのは大変な労力がかかります…。制約事項を検証していれば、その時点である程度アプリができあがってしまっていると思います。

一方、民間の IT 業界では 準委任契約を採用し、ローコード開発の強みである「アジャイル的な柔軟さ」を活用する例が一般的です。準委任契約であれば当初の仕様に縛られることなく、柔軟な仕様変更を行うことで開発スピードも向上し、より使いやすいアプリの開発が期待されます。

官公庁でも「草刈り業務」「除雪業務」などの業務委託では「単価契約」により作業時間に応じて支払う形が取られることがあると思いますが、システム開発ではまだ馴染みが薄いのが現状ではないでしょうか。

参考として、東京都は準委任契約を基本としたアジャイル型開発のプレイブックを策定しています。今後は、ローコードのメリットを享受するために、準委任契約でシステム開発を行う官公庁が増えていくかもしれません。

東京都「アジャイル型開発プレイブック」

 

現状の発注・契約形態で想定される問題

現状の発注・契約形態で想定される問題

現状の発注・契約形態とマッチしていないことから想定される具体的な問題例です。

  • 仕様書に基づき発注したが、ローコードツールの制約で実現できず、プロジェクトが頓挫した

  • 軽微な仕様変更でも成果物責任を果たせないため「契約変更」となり、担当者の契約事務負担が増加した

  • 仕様(機能・非機能要件等)とローコードツールの制約によるフィージビリティ(できる/できない)の検証に時間を要し、調整が多発。履行期間の延長に伴い「変更契約」が必要となった

特に官公庁では契約変更に正当な理由書や手続きが必要で、予算執行や監査上の制約も大きいと想定されます。発注側の担当者の負担が増大しやすい点に留意が必要と考えます。

 

現時点でのベストプラクティス

現時点でのベストプラクティス

1. 発注形態(一般競争入札)への対応

一般競争入札は、公平性・透明性の観点から広く採用されています。しかしローコード開発では、価格だけでなくベンダーの技術力や提案内容を適切に評価する必要があると考えております。

課題

価格競争に偏重し、技術力や提案力のあるベンダーを選定できない可能性。

対策

  • Best:総合評価型一般競争入札方式または公募型プロポーザル方式の採用


    メリット

    • 提案書でデザイン力、Power Platform の知見、業務理解、課題解決アプローチなどを詳細に評価できる

    • 要件定義段階からベンダーのノウハウを活用し、最適なソリューションの構築につながる

    デメリット
    入札準備に時間と労力がかかる。価格以外の要素を重視するため、価格が高止まりする可能性がある。評価基準によっては適切なベンダーを選定できない可能性がある(コスト・クオリティともに低下)。

  • Better:一般競争入札だが、入札参加資格要件の設定と、資格の有無を判断する「適合証明書」の提出


    メリット
    価格競争原理が働きやすく、コスト抑制が期待できる。一定水準以上の技術力を持つベンダーを選定できる。

    デメリット
    資格や実績といった定量評価に偏り、創造性や柔軟な提案を評価しづらい。新規参入ベンダーの機会を狭める恐れがある。

 

2. 契約形態への対応

Power Platform 開発では、発注段階で仕様が確定しきらない場合や、開発途中に仕様変更が発生することがあります。柔軟に対応できる契約方式の選択が重要と考えております。

課題

成果物ありきの契約では、仕様変更に柔軟に対応できず、ローコードの良さを活かせない。または仕様を満たせずプロジェクトがとん挫してしまう可能性がある。

対策

  • Best:準委任契約(成果完成型 or 履行割合型)の採用


    メリット
    仕様変更に柔軟に対応できる。開発状況に応じて契約内容を見直せる。ベンダーのノウハウを最大限活用できる。

    デメリット
    成果完成型では、成果物の品質が契約内容に左右されるため、詳細な仕様が必要になることがある(官公庁では完成の定義付けが難しい)。作業時間型では費用が青天井になるリスクがある。

    使い分け(参考):

    • 成果完成型:成果物の内容(画面や機能など)が明確に定義できる場合に適する

    • 作業時間型:要件が流動的で、アジャイル的な進め方をする場合に適する

  • Better:PoC(Proof of Concept)フェーズの導入


    メリット
    ローコードの制約下でのフィージビリティ(実現可能性)を検証できる。開発フェーズ発注前の早期段階で課題を発見し、リスクを軽減できる。開発規模や費用の見積もり精度が高まる。

    デメリット
    PoC 実施に追加の費用と時間がかかる。

 

官公庁ローコード案件における課題や対策について、私自身が現時点で想定できるベストプラクティスをご紹介させていただきました。

最後に

官公庁ローコード案件における課題や対策について、私自身が現時点で想定できるベストプラクティスをご紹介させていただきました。

ベンダー側が踏み込む内容ではないかなとも悩みましたが、今後ローコードツールを用いた官公庁様のプロジェクトを成功に導くにはベンダー側も官公庁様特有の事情を理解することで、プロジェクトの成功に近づくのではないかと考えブログを書かせていただきました。

一方で、実際に担当者様とお話させていただくと、スケジュールや予算等の都合により、発注方法や契約方法が制限されてしまうというお話を多くお伺いします。

私自身、行政で働いていた経験もあり、その辺のハードルは身に染みて分かります・・・。

ここまで理想的なことを述べてきましたが、今後ローコードツールを官公庁様により良く普及させていくには、官公庁特有の発注形態やプロセスを十分に理解した上で、ベンダー側も親身に、粘り強く打ち合わせを重ねながら、予算やスケジュールなどの条件を踏まえて発注方法や仕様提案に協力し、最適な提案を行うことで、プロジェクトの成功を支援することが重要だと考えています。

私自身、今後も官公庁様との実績を重ねながら、より良いご提案ができるよう精進し、今後も日々奮闘されている官公庁のご担当者様へ有益な情報を届けられたらと思います。

最後までご覧いただきありがとうございました。

Power Platform(SharePoint・Power Apps・Power Automate)に関する営業活動や設計、開発などを担当:小刀稱知哉

村上洋輔

🖊村上洋輔さんのブログ一覧はこちら

岩手県在住

13年半程の地方自治体職員を経てIT業界へ飛び込みました!

趣味はキャンプ⛺、釣り🐟、家庭菜園🥬、サッカー⚽・・・アウトドアが好きです!

Power Platformに関する業務を担当しております!

非エンジニアの方々、地方の企業様、地方自治体様へもPower Platformの良さが伝わる活動ができればと考えております!

Microsoftクラウド関連

シェアする
記事カテゴリ
最新記事
2026.02.04

ローコードツール(Power Platform)を活用した官公庁での発注形態について:元自治体職員(地方公務員)が官公庁におけるローコードツールを活用したシステム開発の発注・契約方法について考えてみた

2026.01.28

Power Apps:自由を手に入れよう!カスタムコンポーネントを構築してみる【実装編】

2026.01.21

Power Apps:PCFって何?カスタムコンポーネントを構築してみる【環境構築編】

2026.01.14

【2026年1月更新】Power Automate 初心者 ~ 中級者 向けロードマップ

2026.01.07

【2026年1月更新】Power Apps の実践的なノウハウ まとめ

AccessCSSBreakpointObserver承認動的リスト検索個人列退職ギャラリーDevOpsCalendarモデル駆動型データフローフルリモートワークPowerAutomateブランドセンター感想フォルダ構成設定アクセシビリティPCFInfoPathxUnitメディアクエリリマインドcollectionMicrosoft 365グループユーザー列所有者を変更スクロールMicrosoft 365Teamsセキュリティロールrecycle binアーティサンX-SP Designテーマ作成チームサイトMicrosoft Learn Docsアジャイル開発Wordテンプレート環境構築MatTable.Net Core 3.1スマホSetコレクションセキュリティグループSharePoint Online異動コンテナ簡易在庫管理ローコード開発ビジネスルールアクセス許可Artisanスライドショーデザイン拡張コミュニケーションサイトカスタムコネクタ準委任契約業務自動化カスタムコンポーネントAngular MaterialVSCodePCForAll複数の添付ファイル送信元リストLoopショートカットキー時間外非エンジニアDataverseSharePoint Framework転職Slide showMicrosoft365サイトの種類OpenAPI請負契約効率化Power Platform CLIデータ構造.Net Core Test ExplorerレスポンシブUpdateContext承認フローメールの送信非表示Microsoftshortcut key通知体験談JavaScriptSPFx主キー比較移行要件定義MCPサーバー総合評価型入札資料作成開発手順モデル駆動型アプリSortByColumns関数Dataverse for TeamsDynamics 365ロードマップform差出人アプリdesignconcat関数ファイル勉強表示サンプルCopilot Studio社内ポータル多言語化サイト構成FAQエージェントデジタルトランスフォーメーション初心者向け拡張機能Power AppsTypeScriptitem関数入門技術エクスポートインスタントクラウドフロー[市民開発者JSON文字制限フィルター クエリ内製化切替samplePowerAppsグループウェアMUI権限設計AIチャットボットプロポーザル方式ハウツービルドPower PlatformHTMLGoogle Maps初心者Itインポート自動化したクラウドフロー構築デザインフロー実行ドキュメント ライブラリ市民開発登録者X-SPNFCタグエンゲージメントMultilingualデータ移行実運用官公庁システム画像挿入プロジェクト作成SharePointEF CoreMarker Clusterer中級者DXカスタマイズ委任自動化したクラウド フロー運用開発環境filter query管理システム列StyleDLPポリシー地方自治体MLJSON書式保守性デジタル化推進複数レコードPCFギャラリーExcelマイグレーションRANK()関数キャンバスアプリノウハウcomponentVBAフローの種類選択肢列環境sortガバナンス登録日StudioTestCopilot Studiot共有リンクテンプレート化DX推進テーマカラーPDF変換業務システムPower AutomateFramework CoreDynamics 365 SalesDatePicker情報技術ダイアログエラーインスタント クラウド フロー参照列本番環境ソートerror notification更新者AICanvas自治体DXレポート化サイト複製作り方ダークモード資料自動作成キャンバスアプリ 違いC#Attribute directivesMicrosoft TranslatorDropdownメッセージIDコンポーネントエクセルスケジュール済みクラウド フローChatGPTライセンスmultiple itemエラー通知更新日生成系AITest Studio生成AI自治体APIPnP PowerShellページ承認Formulasプロパティフロー設計Power Apps 導入attributeO/Rマッパーマーカークラスタリングライブラリviewメールdialogerrorレスポンシブ レイアウトOpenAI環境構築手順複数項目削除変更Copilotテスト事例HTTP リクエストカスタムスクリプトドキュメント管理カラーセットテンプレート活用Power Apps 比較validationazure sql databasetailwindcssビューfirst()関数Tips復元responsive layoutオープンAIpipelineシェアポイントフォルダ外部DBlicenseテストスタジオ活用ワーケーション業務効率化IT管理カラーユニバーサルデザイン自動化事例モデル駆動型 とはローコードCase式マルチテナントアクセス制限nest新機能restoreデータ行の制限チャットGPTCI/CD便利機能ゴミ箱連携添付ファイルコントロール使い方サイトブランド化名古屋ファイル保存申請システムアプリデザインNode.jsシステム構築AngularHTTP Requestドロップダウンメニューノーコード入れ子変数Power BI引き継ぎgalleryパイプラインカレンダー完全削除接続ファイルサイズ基本知識フォントカスタマイズ体験記エンティティワークフロー自動化UI/UXVisual Studio Code
PageTop
ページトップに戻る