アーティサンの村上です。
村上 洋輔むらかみ ようすけ
得意領域
営業・プロジェクトマネジメントを担当しております。ご提案からプロジェクト完了まで一貫して対応し、確実な進行とお客様の満足度向上を目指しています！
なぜこの記事を書いたか
昨今、各官公庁の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 実施に追加の費用と時間がかかる。
最後に
官公庁ローコード案件における課題や対策について、私自身が現時点で想定できるベストプラクティスをご紹介させていただきました。
ベンダー側が踏み込む内容ではないかなとも悩みましたが、今後ローコードツールを用いた官公庁様のプロジェクトを成功に導くにはベンダー側も官公庁様特有の事情を理解することで、プロジェクトの成功に近づくのではないかと考えブログを書かせていただきました。
一方で、実際に担当者様とお話させていただくと、スケジュールや予算等の都合により、発注方法や契約方法が制限されてしまうというお話を多くお伺いします。
私自身、行政で働いていた経験もあり、その辺のハードルは身に染みて分かります・・・。
ここまで理想的なことを述べてきましたが、今後ローコードツールを官公庁様により良く普及させていくには、官公庁特有の発注形態やプロセスを十分に理解した上で、ベンダー側も親身に、粘り強く打ち合わせを重ねながら、予算やスケジュールなどの条件を踏まえて発注方法や仕様提案に協力し、最適な提案を行うことで、プロジェクトの成功を支援することが重要だと考えています。
私自身、今後も官公庁様との実績を重ねながら、より良いご提案ができるよう精進し、今後も日々奮闘されている官公庁のご担当者様へ有益な情報を届けられたらと思います。
最後までご覧いただきありがとうございました。