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

Herokuのシステム発注は、業務の目的と発注範囲を整理し、RFPで複数社に提案を依頼して、契約と責任分界を合意する流れで進みます。

開発後の移行や運用まで見通しておくと、発注側と委託先の認識のずれを減らせます。発注形態から費用、委託先の選び方、運用までを順に見ていきます。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

Herokuのシステムを外注する前に知っておきたい全体像

Herokuのシステムは、画面やAPIを動かすdynoと、データを保存するHeroku Postgresなどで組み立てます。キャッシュやジョブキューはKey-Value Storeが受け持ち、デプロイはPipelinesで管理します。

発注の際は、対象業務、利用者、データの保存先、必要な稼働水準まで決めておきます。これらを決めずに「Herokuで作る」とだけ伝えても、運用の範囲は特定できません。

PaaSで減る運用と、企業側に残る責任

Herokuを使うと、OSの構築やサーバーの初期設定を作り込む負担が減ります。アプリは、GitやDocker、Heroku CLIからデプロイできます。

一方で、ログイン、多要素認証、ロール別権限は企業側に残ります。入力値の検証と秘密情報の管理、脆弱性の修正も、企業側で受け持つ必要があります。さらに、バックアップと復元テストも必要です。

委託先には、Herokuが担う範囲と、自社または委託先が担う範囲を責任分界表に示してもらいます。

外注と相性がよいプロジェクト

既存CRMとの連携が必要な案件や、短期間の検証が必要な案件では、業務の特性がHerokuに合うかを確認します。

• 業務システム：顧客ポータル、業務API、SaaS、予約・申請システム。
• 独自機能・新規サービス：Salesforceにない画面や、短期間で検証する新規サービス。
• Salesforce連携：Heroku ConnectやAPIで既存CRMと連携し、利用者向けの機能を追加する。

業務データをHeroku Postgresに集約しておくと、Salesforceとの連携にも使えます。

特殊な低遅延要件や巨大なバッチ処理がある案件では、AWS、Azure、オンプレミスも比較します。また、厳格なネットワーク制御が必要な案件や、特定クラウドが必須の案件も、比較の対象になります。

発注側は、業務の価値と非機能要件を整理し、Heroku単体で進めるか、他環境とのハイブリッドにするかを判断します。

Herokuのシステムを発注・外注する進め方

Herokuのプランより先に決めるのは、業務上の目的と発注範囲です。次の順に進めると、要件と見積を同じ前提で検討できます。

1. 現行業務を洗い出し、改善する目的と発注範囲を決めます。
2. 一括請負、準委任・ラボ型、PoCや分割発注のなかから形態を選びます。
3. RFPを作成し、複数社に提案を依頼して、要件と見積を比べます。
4. 契約と責任分界を合意してから、設計・開発に進みます。

一括請負で任せる方法

業務要件が固まっており、納期と予算を管理したい場合は、要件定義からリリースまでを一社に請負で委託できます。また、社内にHerokuや開発の専門家が少なくても進めやすい方法です。

発注側の確認が遅れると、受託会社が仕様を推測で補ってしまうことがあります。そのため、まず成果物と受入条件を契約の前に決めておきます。変更手続きと検収時期も、あわせて決めておく必要があります。

準委任・ラボ型でチームを組む方法

要件を検証しながら作る場合は、エンジニアやプロダクトマネージャーを準委任・ラボ型で受け入れます。毎月の作業時間や体制を調整すると、PoCから本番まで得た学びを開発に反映できます。

発注側には、意思決定者と、優先順位を管理する担当者が必要です。また、Herokuの構成やDB設計を、CI/CDや監視と合わせて自社に残す場合にも、この方法は適しています。

PoCや分割発注でリスクを抑える方法

PoCと分割発注では、検証する範囲と責任分界を先に決めておきます。

• PoCの検証：代表業務のログイン、主要画面、認証、Salesforce連携、Heroku Postgresを確かめ、バックアップ復元と簡易負荷試験も行う。
• 成果物の再利用：設計書、ソースコード、テスト結果を本番でも再利用できる形で契約し、二重投資を避ける。
• 分割発注：フロントエンド、バックエンド、Salesforce、インフラを別会社へ委託する方法。障害時に責任が曖昧になるおそれがある。

分割するときは、API仕様、データ所有者、リリース責任者を一枚の責任分界表にまとめます。また、監視担当と一次受付も、同じ表に加えます。

RFPと要件整理で発注前に決める項目

RFPは、各社の提案と見積を同じ前提で比べるための基準になります。Herokuの構成や運用費も比べられるよう、業務、データ、非機能の各要件と、成果物、体制に分けて書きます。

業務要件と機能要件の切り分け

現場の困りごとは、「何を作るか」より「何を改善するか」の形で書きます。たとえば、営業がExcelとメールで受注情報を転記しているなら、利用者と入力項目、承認者を整理します。さらに、例外処理と完了条件も整理しておきます。

整理した業務は、顧客管理、受注登録、在庫確認といった機能に落とし込みます。請求連携やCSV出力なども、同じように機能として整理します。そのうえで、Must、Should、Couldで優先度を付け、初回に含めない機能も明記します。

要件定義を省くと、開発中の追加要望で費用と納期が膨らみやすくなります。そこで、画面一覧、業務フロー、権限一覧を添えておくと、提案の精度が上がります。データ項目一覧と連携先一覧も、あわせて添えておきます。

非機能要件とHeroku構成の指定

非機能要件は、測定できる条件で指定します。Heroku構成とあわせて、次の項目をRFPに記載します。

• 性能・復旧：目標応答時間、同時利用者数、稼働時間、RTO（復旧目標時間）、RPO（復旧時点目標）。
• データ・利用条件：データ保持期間、バックアップ世代、監査ログ、認証、対応ブラウザ、リージョン。
• Heroku環境：Common Runtime、Private Spaces、Shield Private Spacesの必要性について、提案を求める。
• 構成と費用：dyno数、Web・Workerの分離、Postgresプラン、Key-Value Storeの構成を明記してもらう。

「安全に」「速く」「止まらない」は、測定できる条件に置き換えます。構成を明記すると、初期費用と月額TCOを比べられます。あわせて、ログ保管、監視、ステージングと本番の環境数も含めてもらいます。

RFPで示す成果物と評価方法

納品物と評価方法は、提案を実務の面から比べられるよう、具体的に書きます。

• 設計・開発物：要件定義書、画面・API・DB設計書、ソースコード、Infrastructure as Code、環境変数一覧、CI/CD設定。
• テスト・運用物：テスト仕様書と結果、データ移行スクリプト、運用・障害対応手順書、教育資料、アカウント・権限一覧。
• 評価軸：価格、Heroku実績、Salesforce連携、移行に配点します。負荷試験、セキュリティ、担当者経験、保守体制、提案の具体性にも配点します。
• 実務力の確認：実績件数に加えて、構成図、障害対応例、復元テスト手順、顧客の許可を得た事例を見る。

Heroku開発の契約形態と責任分界の決め方

要件が固まった部分と、検証しながら決める部分とでは、契約を分けて扱います。そうすれば、それぞれのリスクを分けて管理できます。契約には、開発作業に加えて、Heroku利用料、Salesforceや外部APIの契約も含めます。

データの所有権と障害時の連絡経路も決めます。特に、プラットフォーム利用料や外部サービス契約の負担者は、はっきりさせておきます。

請負契約と準委任契約の使い分け

要件の確定度に応じて、請負と準委任を使い分けます。

• 請負契約：成果物を完成させて検収する。要件と受入条件が明確な機能、データ移行、定型画面に適しています。
• 固定価格の注意点：業務ルールが未確定だと、変更のたびに追加見積もりが生じやすいため、変更手続きを決めておく。
• 準委任契約：一定期間の専門人材の作業や、優先順位を変えながら進める開発に適している。作業時間と体制を管理しやすい点も特徴です。
• 成果の管理：完成機能は自動では保証されないため、スプリントの成果、レビュー、意思決定、品質基準を運用に組み込む。

検収・変更・知的財産の条項

検収、変更、知的財産について、契約で決めておく事項を整理します。

• 検収条件：主要業務シナリオ、権限別操作、異常系、連携失敗時の再送、復元テスト、目標応答時間。
• 受入テスト：担当者、テストデータ、期限、指摘の修正方法を合意する。
• 変更管理：要件変更時の追加費用と納期への影響を記録する。
• 権利と引き渡し：ソースコード、DB定義、移行スクリプト、CI/CD設定、Heroku権限の保有者を決めます。自社がコードとデータを取り出せる状態にしておきます。

運用保守とSLAの範囲

保守の範囲とHerokuの運用方針は、契約と保守計画で明確にしておきます。

• 保守作業：問い合わせや軽微な改修、スタック更新、アドオン変更確認を行います。脆弱性対応、監視、障害一次受付も含めます。
• 契約条件：復旧支援やバックアップ復元訓練を含む月額範囲と、別見積もりを分けます。対応・受付時間、初動目標、重大度別の連絡方法も記載します。
• 方針変更への対応：公式は2026年2月に、sustaining engineeringモデルへの移行を発表しています。
• 長期計画：既存の本番利用を直ちに止める内容ではありません。新規の長期案件は、契約、サポート、価格変更、スタック更新、AWSなどへの移行出口を見ます。

sustaining engineeringモデルは、安定性とセキュリティを重視し、信頼性とサポートにも重きを置くとしています。

Herokuのシステム開発費用と月額TCOの相場

費用は、初期開発費、Herokuのdynoやデータサービス利用料、Salesforceなど外部サービス料金に分けて考えます。さらに、監視・ログ・バックアップ費と、リリース後の保守費も加えます。一つの費目だけで安い・高いと判断すると、稼働後に想定外の費用が出ます。

Heroku公式プランから見る実費

2026年8月時点で確認したHeroku公式料金表をもとに、実費の目安と請求条件を整理します。

• dyno料金：Eco 5ドル/月、Basic 7ドル/月、Standard-1X 25ドル/月、Standard-2X 50ドル/月。
• 停止条件：Ecoは一定時間非アクティブだと停止します。そのため、本番を常時稼働させるならBasic以上を検討します。
• Key-Value Store：Miniは月額3ドル、Premium 0は月額15ドルから（出典：Heroku公式料金表、2026年）。
• 円換算例：1ドル150円と仮定すると、Basicは約1,050円、Standard-1Xは約3,750円、Miniは約450円です。
• 月額見積もり：為替、税、契約条件、プロセス数、環境数で実請求は変わります。見積書には、dyno台数、DB容量・接続数、ログ保管期間を含めます。

Heroku Postgresは、プランによって月額数十ドルからです。

開発・導入費の目安

Heroku固有の一律の相場は公開されていません。ここに示すのは、業務システムの一般的な工数と、PaaSでインフラ構築の一部が軽くなる特性をもとにした推定です。

• PoC・社内ツール：100万〜300万円程度。
• 小規模システム・API：300万〜1,000万円程度。
• 中規模ポータル・受発注：1,000万〜3,000万円程度。
• 期間の目安：PoCは1〜2か月、小規模は2〜5か月、中規模は5〜10か月、大規模は10か月以上。
• 期間の変動要因：データ品質、Salesforce連携、権限の複雑さ、移行リハーサル、負荷試験、利用者教育。各フェーズの成果物と完了条件も比較する。

大規模な案件や、規制対応・複雑な基幹連携を伴う案件は、3,000万円〜1億円超となる場合があります（出典：リサーチノート内の業務システム相場整理、2026年）。

保守費と5年単位のTCO

保守費と5年TCOは、Heroku利用料以外の運用費も含めて比べます。

• 保守の範囲：監視、問い合わせ、障害対応、軽微な改修を含みます。セキュリティ更新、復元、リリース支援も範囲に入ります。
• 保守費の目安：一般的な業務システムでは開発費の年10〜20％程度。
• 5年TCO：初期開発費、Heroku実費60か月分、外部SaaS、保守を合算します。追加改修、監査対応、スタック更新、移行・廃止費も含めます。
• 総額の見極め：利用料が小さくても、改修や特定の委託先への依存で総額が上がることがあります。変更しやすさと運用の透明性も比べます。

24時間対応や高いSLA、データ連携の監視が必要な場合は、保守費が上振れします（出典：リサーチノート内の業務システム保守費目安、2026年）。

Herokuの委託先選定と見積比較のポイント

候補チームが業務と運用を理解できるかを、認定や掲載と合わせて確かめます。類似案件の構成や担当者の経験、移行方法を尋ねます。さらに、障害対応、納品物、保守窓口、将来の移行方針も確認します。

実績の構成図と障害対応の確認

実績は、構成や移行・運用の中身まで確認します。

• システム構成：言語、dynoとWorker、Postgres、外部API、Private Spacesの有無。
• 移行・試験：データ移行の件数と負荷試験の方法を、匿名化した構成図で確認する。
• 公式事例：Heroku公式Customer Storyで、構成や開発期間を見る。

Kawasaki Engines事例では、30年以上のデータをHeroku Postgresに集約しました。さらに、Heroku ConnectでSalesforceと同期しています。

別の公式事例では、Private Spaces、Pipelines、Review Appsを使い、4か月未満でアプリを完成させたと説明されています（出典：Heroku公式Customer Story、2026年確認）。

Salesforce連携とセキュリティの提案力

連携方式とセキュリティ環境、担当範囲を、要件に沿って提案できるかを確認します。

• 連携方式：同期要件に応じて適切なサービスを選ぶ。
• 連携時の設計：双方向同期の競合、障害時の再送、個人情報のマスキング、マスタの正、同期遅延・失敗の検知。
• 実行環境：Common Runtime、Private Spaces、Shield Private Spacesの差を要件に沿って説明できるか。
• セキュリティ担当：MFA、SSO、最小権限、秘密情報、TLSの扱いを確認します。ログドレイン、監査ログ、バックアップ、脆弱性対応も含みます。

連携方式は、Heroku Connect、AppLink、Platform Events、REST API、MuleSoftから選びます。判断の基準は、同期方向、リアルタイム性、データ量、API制限です。

Herokuの認証やコンプライアンス資料があっても、自社アプリの権限設定や法令対応まで自動で完了するわけではありません。

見積書の工数・前提・除外項目による比較

工数と前提、対象外の作業を同じ形式で並べ、見積の内容を比べます。

• 作業内訳：要件定義、UI、バックエンド、Salesforce連携、DB、テストごとに工数を示す。移行、インフラ、監視、教育、リリースも作業ごとに並べる。
• 見積条件：各項目の担当人数、期間、工数、単価、前提、対象外作業。総額が同じでも内容を比べられる。
• 除外項目：データクレンジング、マスタ整理、外部サービス契約、負荷試験データ、脆弱性診断。
• 追加確認：App Store・審査、運用監視、夜間障害、Heroku・Salesforce料金。除外が多いと安く見えるため、含む・含まないを同じ書式で並べる。

面談で聞くべき発注先チェック項目

面談では、運用・障害対応・移行性について、具体的な経験と手順を尋ねます。

• 更新検証：Heroku-26への更新をどの手順で検証するか。
• 復旧経験：本番DBのバックアップを実際に復元した経験があるか。
• 連携障害：Salesforce同期停止時に、誰が何分以内に何を確認するか。
• 引き継ぎ・移行：委託先変更時の引き渡し物と、AWSなどへ移る際に現在の設計が障壁になる点。

「Herokuが自動で対応します」とだけ説明する会社には、注意が必要です。一方で、機能とアプリ・データ・業務運用の責任を分け、担当者、手順、復旧時間、証跡を説明できる会社は、認識のずれを減らせます。

発注後の開発・データ移行・運用を成功させる進め方

成否は、設計レビュー、移行、受入テスト、リリース、運用の引き継ぎといった各段階で決まります。発注側は任せきりにせず、業務の正解を決めます。一方、委託先は実現方法と技術リスクを示します。

データ移行の小規模試行と本番化

データの状態を整えたうえで、小規模な移行から本番化まで段階を踏みます。

1. 既存のExcelやCSV、基幹DB、Salesforceに不整合や重複がある場合は、取り込み前にクレンジングの方針を決めます。
2. 項目対応表や必須値、コード変換、重複判定、削除対象、エラー時の扱いを定めてから、少量のサンプルで移行します。
3. 本番前に、所要時間、停止時間、差分取り込み、ロールバック、移行後の件数照合をリハーサルします。

移行スクリプトは、ソースコードと同じようにバージョン管理しておきます。こうすると、誰が実行しても同じ結果になる状態を目指せます。

CI/CD・監視・障害訓練の引き継ぎ

リリース、監視、障害訓練の手順を整え、委託先から運用を引き継ぎます。

• 開発とリリース：Review Apps、Pipelines、CI/CDで、Pull Requestごとに検証する。秘密情報はコードに書かず、環境を分ける。
• 手順書：デプロイ、ロールバック、DBマイグレーションの方法を文書化する。
• 監視：エラー率、応答時間、dyno、DB容量・接続数、キュー滞留、外部連携の失敗を対象とします。
• 訓練と引き継ぎ：月1回などでバックアップ復元と障害連絡を訓練します。委託先が不在でも自社で把握できるよう、権限と手順書を引き継ぎます。

Herokuからの移行出口の設計

長期運用では、サポート期限を管理しつつ、Heroku外へ移るための出口も保ちます。

• Heroku-26：Ubuntu 26.04 LTSベースで、2031年4月末までサポート予定。
• 更新前の検証：スタックとサポート期限を管理します。依存ライブラリ、Buildpack、コンテナ、ネイティブ拡張、監視を確認します。
• 移行しやすい設計：標準PostgreSQL、12-Factor、コンテナ化、外部監視、IaCを採用する。

Heroku-26は2026年5月に一般提供されました（出典：Heroku Dev Center、2026年）。移行に備えて、再現可能なビルドとデータのエクスポート手順も用意します。

Herokuを使い続ける場合でも、委託先の変更やクラウドの見直しができれば、長期のベンダーロックインを抑えられます。

Herokuのシステム発注・外注でよくある質問

発注では、費用のほかに、委託範囲やSalesforce連携、将来の継続利用についても疑問が生じます。よくある質問に答えます。

Herokuのシステム開発は最低いくらから発注できますか？

小規模な検証や社内ツールであれば、開発費100万〜300万円程度が一つの推定の目安になります。

開発費は、画面数や権限、外部連携、データ移行、テスト、運用設計によって変わります。そのため、Heroku月額利用料だけで判断せず、代表業務のPoCで機能と本番化の条件を確かめます。

Herokuに詳しい委託先はどう探せばよいですか？

Heroku公式Consulting PartnerやCustomer Story掲載企業を、候補探しの入口にします。そのうえで、日本語の窓口や国内契約、担当者、Salesforce連携、データ移行も確認します。

さらに、Private Spacesや保守体制も見ます。公式掲載は案件への適合や料金を保証するものではないため、構成図と見積の前提を示してもらい、複数社で比べます。

Salesforceを使っていてもHerokuへ外注できますか？

外注できます。連携方式は、Heroku Connect、AppLink、Platform Events、API、MuleSoftなどから選びます。

連携方式の選び方は、同期方向やリアルタイム性、データ量、API制限に応じて決まります。

障害時の再送や個人情報の扱いも、判断材料になります。また、Salesforceの標準機能を残したまま、独自の顧客ポータルや業務画面をHerokuに追加する構成もあります。

2026年以降もHerokuを新規採用して問題ありませんか？

一律に問題があるとはいえません。Heroku公式は2026年2月、既存の本番利用、価格、請求、コア機能を変えないとしています。さらに、安定性とセキュリティ、信頼性、サポートを重視する方針を示しました。

一方で、新規のEnterprise Account契約は提供されません。長期の新規案件では、契約形態、サポート、価格、将来の移行性をRFPと経営判断に含めます。

まとめ

発注の対象は、業務を改善するシステム全体です。Herokuの設定は、その一部にあたります。要件が固まった部分には請負、検証段階には準委任やPoCを使い分けます。

RFPには、機能、非機能、データ、成果物、保守範囲を具体的に書きます。

発注成功の結論

開発費、Heroku公式の利用料、外部サービス、保守費を分けて、5年間のTCOで比べます。

委託先は、Heroku経験に加えて、Salesforce連携や移行、負荷試験、障害対応、Private Spacesを確認します。

成果物の引き渡しと、将来のAWSなどへの移行出口を説明できる会社を選びます。

発注前に行う準備

現行業務、利用者、データ、外部連携、目標稼働水準を整理して、代表業務を一つ選びます。その内容をRFPにまとめ、複数社に同じ条件で依頼します。

見積の前提や除外項目、月額TCO、保守、移行性を比べることが、発注を成功させる第一歩になります。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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