OutSystemsのシステム開発の発注/外注/依頼/委託方法について

OutSystemsのシステム開発を発注・外注するなら、ライセンス費だけでなく、業務整理、要件定義、既存システム連携、データ移行、テスト、運用保守までを分けて見積もり、契約と出口条件を先に決めることが重要です。

本記事では、OutSystemsのシステムを依頼・委託するときの発注形態の選び方、RFPの作り方、要件整理、契約形態、費用相場、委託先の選定、見積書の比較方法を順番に解説します。O11とODCの選択や、ローコード開発で起こりやすいベンダーロックインも含め、初回相談から本番稼働後までの判断材料を整理します。

▼全体ガイドの記事
・OutSystemsのシステム開発の完全ガイド

OutSystemsのシステムを外注する全体像

OutSystemsは、Webやモバイルの業務アプリケーションを短期間で開発しやすいローコードプラットフォームです。ただし、開発画面を早く作れることと、業務システムの導入が短期間で終わることは同じではありません。外注では、プラットフォームの設定よりも、業務ルールの整理、既存データとの整合、利用部門の合意形成、品質保証に多くの判断が必要です。

最初に「OutSystemsで何を作るか」ではなく、「どの業務をどう変えるか」を決めます。たとえば、紙やExcelで行っている申請をオンライン化する、営業担当者が外出先から登録できるようにする、基幹データを使った在庫確認を実現する、といった業務上の目的です。対象部門、利用者数、処理件数、削減したい時間、法令や監査上の条件まで言葉にすると、委託先から同じ前提で提案を受けられます。

OutSystems公式のトヨタ事例では、従来型開発と比べて約30％の工数削減、2023年10月時点でトヨタグループ23社の利用、トヨタ自動車で70以上のプロジェクト活用が紹介されています（出典: OutSystems公式「Toyota’s 10-year low-code journey」、2023年掲載）。ただし、これは特定企業の導入事例であり、すべての案件で同じ効果が出るという意味ではありません。効果を説明する際は、画面製造の短縮だけでなく、業務標準化や再利用部品の蓄積まで含めて自社の指標を置くことが大切です。

発注時点で、OutSystems 11（O11）を使うのか、OutSystems Developer Cloud（ODC）を使うのか、既存O11とODCを組み合わせるのかを候補にします。既存のO11資産、社内の運用体制、自社管理が必要なデータ、クラウド利用方針を重視するならO11が候補になります。クラウドネイティブな開発や新しいAI機能、環境運用の簡素化を重視するならODCが候補になります。

2026年には、ODCのリージョン可視化、O11とODCのデータ連携、Private Gatewayによる閉域接続、既存O11アプリとODCアプリのシングルサインオンなど、共存を前提にした機能更新が公式に発表されています（出典: OutSystems公式「Product Releases and Updates」、2026年7月）。したがって、最初から全面移行を前提にせず、既存基幹をO11側に残し、申請画面やモバイル、AI活用部分をODC側で追加する構成も比較できます。委託先には、選択理由、移行時の制約、3年後の運用費を同じ見積書で提示してもらいます。

OutSystemsの発注形態はどのように選びますか？

結論として、初めてOutSystemsを導入する企業は、企画・PoC・本番開発・保守までを一括で丸投げするより、責任範囲を分けた段階発注が適しています。一方、社内に業務知識とIT人材があり、将来の内製化を進めたい企業は、委託先に開発を依頼しながら社内メンバーを同じチームに入れる混成型が向いています。案件の成熟度、社内の意思決定速度、運用を担う人材を基準に選びます。

一括委託型は、要件定義から設計、開発、テスト、リリース、保守までを主契約先に依頼する方式です。社内にOutSystemsの経験者が少なく、複数の外部会社を管理する余力がない場合は、窓口を一本化しやすい点がメリットです。発注時には、主契約先がライセンス販売、開発、インフラ、運用のどこまで責任を負うのか、再委託先の作業を誰が検収するのかを明記します。

ただし、一括委託では社内に設計判断が残りにくく、契約終了後に別会社へ移管しづらい場合があります。アプリケーション資産、設計書、データモデル、API仕様、環境設定、テスト結果、運用手順を成果物として定義し、引き渡し時期と形式を契約書に入れます。委託先の資格者数だけでなく、実際に何人が自社案件へ参加するかを確認することも重要です。

混成型では、委託先が要件整理や設計、難易度の高い連携を支援し、社内メンバーが業務判断、画面確認、テスト、運用設計を担います。OutSystemsの操作方法を教えるだけではなく、命名規則、共通部品、レビュー基準、リリース手順、障害対応を社内の標準として残してもらうことがポイントです。CoE（Center of Excellence）を設置する場合も、会議体だけでなく、誰が品質と優先順位を決めるのかを定義します。

契約では、委託先の稼働時間だけでなく、社内メンバーへのレビュー回数、ハンズオン、設計書の共同作成、リリース判定への参加を成果に含めます。将来の開発を自社へ戻す可能性があるなら、半年後や1年後の役割移管を前提に、月次で知識移転の達成度を確認します。単価が安い会社でも、移管に必要な説明が別料金になると総費用が増えるため、最初から比較対象にします。

要件が固まっていない場合は、1〜2か月程度のPoCを発注し、代表的な1業務で実現性を確認してから本開発へ進みます。PoCでは画面が動くかだけでなく、既存認証、基幹API、データ移行、権限、監査ログ、ピーク時の性能、エラー通知まで確認します。合否基準を「画面を作れた」ではなく、「1秒あたり何件の処理ができる」「権限テストを何ケース通過する」のように数値化します。

PoCを本開発の営業デモで終わらせないため、成果物の再利用範囲も決めます。データモデル、共通部品、API接続、テストデータ、検証結果、未解決課題を本開発へ引き継ぐ条件を依頼書に書きます。PoC後に中止する場合の費用と、別の委託先へ引き継ぐ場合のデータ返却も契約前に確認します。

RFPと要件整理はどこまで準備すればよいですか？

RFPは完成した仕様書でなくても構いませんが、比較に必要な前提を揃える資料です。委託先ごとに前提が違うと、安い見積もりが機能を含んでいないだけなのか、高い見積もりが移行や保守を含んでいるのか判断できません。まず現行業務と目指す状態を整理し、必須要件と将来要件を分けます。

RFPには、対象部門、業務の開始条件、担当者、承認者、入力項目、検索条件、帳票、通知、締め処理、例外処理を記載します。通常ケースだけではなく、返品、取消、差し戻し、権限変更、データ欠損、通信障害のときに何をするかまで確認します。利用者は社内だけか、顧客や取引先も含むか、同時利用のピーク人数は何人かを分けて書きます。

既存システム連携では、システム名、接続方式、データ項目、連携頻度、データ量、処理の締め時刻、障害時の再送方法を示します。SAPや基幹DB、Active Directory、SaaS、ファイル連携がある場合、連携先の担当会社と接続テストの責任者も明確にします。OutSystemsの開発費だけを尋ねるのではなく、データクレンジング、マスタ統合、API改修の費用を別行で提示してもらいます。

業務システムでは、画面と機能だけでなく、可用性、性能、バックアップ、障害復旧、監視、ログ、脆弱性対応をRFPに入れます。たとえば、営業時間中の稼働率、検索の応答時間、同時利用者数、障害時の復旧目標（RTO）、許容できるデータ損失（RPO）、ログの保存期間を決めます。数値が難しい場合も、現行システムの実績値やピーク時の処理件数を渡すと、委託先が見積もりやすくなります。

個人データを扱う場合は、認証、権限分離、暗号化、操作ログ、委託先のアクセス、バックアップ、削除、再委託を要件にします。個人情報保護委員会のガイドラインでは、委託先の選定、契約の締結、取扱状況の把握を含む適切な監督が示されています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、確認日2026年8月）。ODCでは、2026年に公式のリージョン可視化機能も更新されているため、データの保存・処理場所、サブプロセッサ、バックアップ先を契約前に確認します。

必須機能、できれば欲しい機能、将来検討する機能を分け、受入条件を機能ごとに記載します。申請が登録できるという表現だけでなく、必須入力、承認経路、差し戻し、通知、履歴表示がどこまでできれば合格かを決めます。委託先には、標準機能、共通部品、追加開発、外部製品で実現する項目を分類してもらいます。

RFPの最後には、提案書の形式、見積もりの内訳、想定体制、スケジュール、前提条件、除外事項、質問期限、デモやPoCの有無を記載します。予算上限を伝える場合は、予算内に収めるために何を削るのかも提案してもらいます。これにより、価格だけを下げてテストや移行を削る提案を見分けやすくなります。

OutSystemsのシステム発注からリリースまでの進め方

発注後は、要件を一度決めて終わりにするのではなく、優先順位を管理しながら短いサイクルで確認します。OutSystemsは画面を見ながら業務部門と会話しやすい一方、確認のたびに要望を無制限に追加すると、ローコードの速さが相殺されます。変更の影響、納期、費用、テスト範囲を毎回確認する運営が必要です。

企画フェーズでは、利用部門、情報システム部門、経営側、委託先が同じ業務フローを見ながら、対象範囲と優先順位を決めます。業務部門は「こうしたい」という要望を出し、情報システム部門は認証、データ、運用、既存契約の制約を確認します。委託先には、要望をそのまま機能化するのではなく、標準化や廃止を含めた代替案を提示してもらいます。

要件定義の完了条件は、画面一覧を作ったことではありません。対象業務、データの責任者、権限、連携先、受入条件、未決事項、変更の管理方法が合意されている状態です。未決事項を残す場合は、決定期限、決定者、決まらなかった場合の暫定仕様を議事録に残します。

設計・開発では、画面、データモデル、権限、API、エラー処理、ログ、バッチ、帳票を順に確認します。OutSystemsでは共通部品を再利用できるため、ボタンや入力部品だけでなく、認証、権限チェック、監査ログ、通知、外部連携のエラー処理も標準化すると品質を揃えやすくなります。共通部品の変更が既存アプリへ与える影響を確認するレビュー担当者も必要です。

AI支援や自動生成機能を利用する場合も、生成結果をそのまま本番へ反映しません。権限、入力値検証、個人データの扱い、例外処理、ログ、テストを人間がレビューします。2026年のOutSystems公式更新ではAIエージェントやAI開発支援との連携が進んでいますが、機能の新しさは自社の法令遵守やセキュリティを保証するものではありません。RFPにAI利用の範囲、入力データ、承認者、監査証跡を入れます。

テストは、単体、結合、システム、受入の区分を決め、正常系だけでなく権限エラー、重複登録、タイムアウト、途中切断、再送、取消、データ不整合を含めます。性能試験では、通常時とピーク時の同時利用者数、検索対象件数、外部APIの応答遅延を再現します。発見した不具合の重要度、修正期限、再テストの責任者を管理表で追跡します。

データ移行は、項目の対応表、不要データの扱い、名寄せ、日付やコードの変換、移行リハーサル、件数照合、業務部門の確認まで含めます。移行後に旧システムへ戻す条件と、並行稼働の期間も決めます。リリース前には、バックアップからの復旧、監視通知、問い合わせ窓口、障害時の連絡網、運用手順を実際に試し、教育を終えた利用者が本番で迷わない状態を作ります。

OutSystemsのシステム開発で選ぶ契約形態と契約条項

契約形態は、要件の確定度と委託先に期待する責任で選びます。すべてを請負契約にすれば安心というわけではなく、要件変更が多い段階で固定範囲を無理に確定すると、変更契約や品質低下を招きます。企画、PoC、本開発、保守で契約を分けると、各段階の成果と判断が明確になります。

請負契約は、合意した成果物を完成させ、発注者が検収する形に向いています。画面一覧、機能、連携、移行、テスト、マニュアルなど、何を納めれば完成なのかを契約書や個別仕様書に落とします。納期だけを固定し、受入条件が曖昧な契約は避けます。要件変更の定義、追加費用の算定方法、変更を承認する人も定めます。

OutSystemsでは、開発途中に実画面を見て要望が変わることがあります。変更が軽微か、仕様変更か、別機能かを判定するルールを設け、影響範囲と納期を合意してから着手します。受入後に見つかった不具合の無償修正期間、瑕疵対応の範囲、第三者製部品の制約も確認します。

準委任契約は、一定期間の作業や専門的な支援を依頼する形で、要件や優先順位が変わりやすいアジャイル開発に適しています。委託先は合意した時間や体制で作業し、発注者はバックログの優先順位や受入を担います。作業内容、稼働時間、成果の確認方法、欠員時の交代、会議体、報告物を明確にします。

準委任では、発注者が委託先の個々の担当者へ直接指揮命令しないよう、窓口と役割を整理します。開発責任者、プロダクトオーナー、業務部門、品質管理者の権限を分け、仕様変更や優先順位変更をチームのルールで扱います。人月単価が低く見えても、会議、調査、移行、テスト、運用引き継ぎが別扱いなら総額で比較します。

契約前に、OutSystemsのライセンス契約と開発委託契約の責任分界を確認します。アプリケーション、カスタム部品、設計書、テスト成果物、ソース相当の資産、環境設定、API仕様の権利と利用範囲を整理します。共通部品や第三者コンポーネントのライセンス、改変・翻案の可否、契約終了後の利用条件も曖昧にしません。

再委託がある場合は、会社名や作業範囲、国外拠点、個人データへのアクセス、委託先の監査方法を確認します。契約終了時には、データを標準形式で返却する期限、バックアップを含む削除証明、別ベンダーへの引き継ぎ協力、運用アカウントの返却、未処理の脆弱性や障害の引き継ぎを定めます。出口戦略を後回しにすると、委託先を変えたいときに再開発費が発生しやすくなります。

OutSystemsのシステム開発費用相場とコストの内訳

OutSystemsの費用は、ライセンス、開発・導入支援、クラウドやインフラ、データ移行、教育、運用保守に分けて考えます。国内ライセンスは、エディション、Application Objects（AO）、内部・外部ユーザー、環境数、サポート、追加オプションなどで変わる個別見積もりです。電通総研のライセンスガイドブックも、2025年6月1日時点の情報として、基本パッケージとODC、Enterprise、追加ランタイム、HA、DR、Private Gateway、Sentryなどを分けて確認する構成を示しています（出典: 電通総研「OutSystemsライセンスガイドブック」、2025年6月1日時点）。

以下は、業務システム全般の相場とOutSystemsの製造工数が削減される可能性をもとにした、企画段階の推定です。国内の正式なOutSystemsライセンス価格や個別ベンダーの確定見積もりではありません。要件定義、連携、移行、テスト、教育、運用設計を含む範囲で上下するため、予算の初期検討に使い、最終判断はRFPに基づく複数社見積もりで行います。

PoCやスターター規模は100万〜500万円程度、申請・営業支援・在庫管理などの部門アプリは500万〜1,500万円程度、複数部門でマスタ、権限、外部API、データ移行まで含む場合は1,500万〜5,000万円程度、全社刷新やレガシー移行、複数アプリ、HA・DRを含む場合は5,000万〜2億円以上が企画用の目安です。期間は、PoCが1〜2か月、部門アプリが3〜6か月、複数部門が6〜12か月、全社刷新が12〜24か月以上となるケースがあります。

相場の出典は、リサーチノート「OutSystemsのシステム」に記載された業務システム全般の費用整理と、OutSystemsの工数削減可能性を組み合わせた企画用推定です（出典: リサーチノート「OutSystemsのシステム」および業務システム全般の相場整理、2026年）。OutSystems公式のトヨタ事例では約30％の工数削減が紹介されていますが、要件整理、データ移行、性能試験、ライセンス、利用部門の教育まで同じ割合で削減できるわけではありません。特に基幹連携と移行データの品質は、ローコードの採用だけでは自動的に安くなりません。

ライセンスの見積もりでは、O11またはODCのエディション、AO容量、内部ユーザー、外部ユーザー、開発・検証・本番の環境数、追加本番環境、サポート、HA・DR、Private Gateway、AppShield、Sentry、ログ連携を項目別にします。顧客向けアプリでは外部ユーザーのピーク、社内アプリでは利用者の増加、将来のアプリ数を確認します。ユーザー数だけでなく、アプリケーション規模と環境数が増えたときの料金変動を質問します。

運用費には、監視、バックアップ、障害対応、脆弱性対応、OS・ミドルウェア更新、問い合わせ、軽微改修、リリース支援、教育を含めます。一般的な業務システムの保守・運用は初期開発費の年15〜25％程度、または月15万〜80万円程度を企画時に置くことがありますが、これはOutSystems固有の価格ではありません。24時間365日対応、厳しいSLA、複数環境、データ連携を含む場合は別途増えるため、月額の範囲を作業時間と対応時間で分けます。

見積比較では、初期開発費だけでなく、ライセンス、クラウド、保守、追加改修、教育、データ移行、終了時の移管までを3年分で並べます。1年目に安くても、2年目以降の追加AO、ユーザー増加、環境追加、サポート、監視が高ければ総額は逆転します。逆に、初期費用が高い提案でも、共通部品や内製化支援によって将来の改修費を抑えられる場合があります。

正式な国内ライセンス価格を公開情報だけで断定することはできません。海外の公開価格表にはエディションや環境、AO、ユーザー、サポートを分けた例がありますが、国、時点、契約条件、為替が異なるため、日本の見積もりとは比較できません。電通総研の2025年ライセンスガイドブックやOutSystems公式の契約・サポート情報を確認し、販売元または認定パートナーから自社条件の見積もりを取ります。

委託先の選定と見積比較で見るべきポイント

委託先は、OutSystemsの資格者数やパートナーランクだけで決めません。同じ業界・規模の本番実績、O11とODCの経験、既存基幹との連携、データ移行、性能試験、セキュリティ、運用保守、内製化の支援実績を確認します。提案の華やかさより、発注者が質問したときに前提とリスクを具体的に説明できるかを重視します。

候補会社には、同業界・同程度の利用者数・同じ連携方式の事例を質問します。公開事例の有無だけでなく、開発期間、チーム人数、担当範囲、移行件数、稼働後の保守体制、発注者側が担った作業を聞きます。事例を開示できない場合も、匿名化した課題と検証結果、プロジェクトの役割分担を説明できる会社なら比較材料になります。

パートナーランクも参考になります。2026年の電通総研の発表では、OutSystemsの新パートナー制度でPlatinumが国内3社のみと説明されています（出典: 電通総研「2年連続でOutSystemsの最上位パートナーランク『Platinum』に認定」、2026年4月）。ただし、最上位ランクでも自社案件に参加する担当者が必ずしも同じとは限りません。提案時には、資格者の総数ではなく、プロジェクトマネージャー、アーキテクト、開発者、QA、運用担当の氏名または役割、稼働予定、交代条件を確認します。

見積書は、要件定義、UX・画面設計、OutSystems設定、カスタム開発、共通部品、外部API、基幹側改修、データ移行、テスト、性能試験、脆弱性診断、教育、リリース、保守に分けます。ライセンス、AO、ユーザー、環境、サポート、クラウド費用は開発費と別行にします。各行に数量、単位、人月、単価、期間、含む作業、除外事項を書いてもらうと、単価だけでなく作業量を比較できます。

比較表では、A社が要件定義を含むのに対しB社が別見積もりになっていないか、A社が移行リハーサルを2回含むのに対しB社が本番移行1回だけになっていないかを確認します。前提条件が「発注者がデータを整備する」「発注者がAPIを用意する」「受入テストは発注者が行う」となっている場合、社内工数も費用として見積もります。

「OutSystemsなら短納期・低コスト」とだけ説明し、移行やテストの課題を語らない提案には注意します。質問すべきなのは、要件が増えた場合の納期と費用、性能が不足した場合の追加対策、外部APIが遅い場合の設計、標準部品の制約、O11からODCへ移行する場合の作業、障害発生時の責任分界です。リスクを隠さず、回避策と予備費を示す会社の方が本番運用まで任せやすくなります。

最低限、契約終了時のアプリ資産とデータの返却、別会社への保守移管、脆弱性発見時の対応、再委託、ライセンス更新、サポート終了時の選択肢を確認します。ローコードでは、見た目の画面だけでなく、内部ロジック、共通部品、データモデル、環境設定、リリース履歴が運用の資産です。引き継げないものがあるなら、採用理由と代替策を意思決定記録に残します。

よくある質問（FAQ）

ここでは、OutSystemsのシステムを発注・外注するときに多い質問へ回答します。費用や期間は要件で変わるため、FAQの数字は固定価格ではなく、RFPを作る前の判断材料としてご確認ください。

企画用の目安では、PoCが100万〜500万円程度、部門アプリが500万〜1,500万円程度、複数部門システムが1,500万〜5,000万円程度、全社刷新が5,000万〜2億円以上です。これは開発・導入支援費の推定であり、国内ライセンス、クラウド、移行、教育、保守は要件に応じて別途見積もります。正式な金額は、AO、ユーザー、環境、連携、データ量、SLAを示して複数社へ依頼してください。

初期導入では、要件整理、連携、セキュリティ、データ移行を経験者へ外注し、社内メンバーが業務判断とレビューに参加する混成型が現実的です。社内に十分な開発・運用体制があり、標準部品や品質管理を維持できるなら内製化の比率を高められます。完全な内製か完全な外注かの二択ではなく、企画、難しい連携、本番運用など工程ごとに分担を決めます。

既存O11資産や自社管理、既存運用との整合を重視する場合はO11を、クラウド運用や新規アプリ、AI機能を重視する場合はODCを候補にします。既存の基幹領域をO11に残し、新規のフロントやAI活用をODCで作るハイブリッドも選べます。委託先には、データ所在地、Private Gateway、認証、移行、将来のライセンスと運用費を含む比較提案を求めます。

資格者数は技術基盤を確認する材料ですが、自社案件に参加する体制や業務知識、移行・テスト・保守の範囲までは分かりません。実績の対象業界、利用者数、O11・ODCの経験、実際の担当者、品質管理、内製化、契約終了時の移管条件を確認します。見積書の前提と除外事項を質問し、リスクを具体的に説明できる会社を選びます。

まとめ

OutSystemsのシステムを発注・外注するときは、ローコードによる開発速度だけでなく、業務成果、O11・ODCの選択、既存システム連携、データ移行、性能、権限、監査、教育、保守、出口戦略を一つの計画として整理します。

発注形態は、一括委託、混成型、PoCからの段階発注を社内体制に合わせて選びます。RFPでは現行業務と例外処理、利用者、連携、非機能要件、受入条件を揃え、見積もりは開発費・ライセンス・運用費・移行費を分けて3年分で比較します。契約書には、成果物、変更管理、再委託、知的財産、データ返却、脆弱性対応、別会社への移管条件を明記します。

委託先を選ぶときは、資格者数や価格だけで判断せず、自社の業界・規模・連携方式に近い本番実績と、実際に参加する体制を確認します。複数社へ同じ前提で相談し、PoCや見積比較を通じて、OutSystemsのシステムを導入後も使い続けられる発注先を選ぶことが成功につながります。

▼全体ガイドの記事
・OutSystemsのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。