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

Parcelのシステム開発の発注は、業務要件と技術範囲、契約条件を整理してから、同じ条件で委託先を比べる順に進めます。そうすると、費用や役割のずれを抑えられます。

発注形態の選び方、RFPと契約の準備、費用相場と委託先の比較が、その流れの中心です。

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

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

Parcelのシステム開発を外注する前の全体像

発注では、Parcelに任せる範囲と、別の技術やサービスで構築する範囲を分けておきます。技術名だけをRFPに書くと、業務要件や納品物が曖昧になります。

その状態では見積もりの前提がそろわず、価格だけでは比べられません。技術レイヤーごとに担当と納品物を書いておけば、追加請求や責任の押し付け合いを防ぎやすくなります。

Parcelが担当するフロントエンドのビルド

Parcelは、フロントエンドのコードをブラウザで動く形に整えるビルド基盤です。その処理は、変換、標準機能、出力の最適化、入口と束ねの4つに分かれます。

• ブラウザ用ファイルへの変換：開発中のコードの変換、依存関係の解決、開発用サーバーと本番用ビルドの準備。
• 公式サイトが案内する標準機能：TypeScript・React変換、ホットリロード、画像最適化。
• 出力の最適化：tree shaking、minify、コード分割、コンテンツハッシュも標準機能に含まれます。
• 入口と束ね：HTMLを入口に、JavaScript、TypeScript、JSX、CSS、画像などを束ねる働き。

Parcelは画面表示やビルドの再現性に関わります。一方で、顧客マスタや在庫計算、承認ルートは、Parcelの提供範囲に入りません。認証や監査ログを提供するものでもありません。

Parcel・フロント・バックエンド・運用の発注範囲

見積もりには、Parcelの設定だけでなく、画面設計やReactまたはVueの実装も含めます。さらに、APIやデータベースの構築、認証認可、クラウド環境も対象に入ります。そのほか、テストを含むCI/CD、データ移行、リリース後の保守も対象です。

ただし、Parcelで一部の工程が効率化されても、業務ルールの整理や外部システム連携の工数は、大きく変わらないことがあります。

Parcelのシステム開発に向く発注形態

契約形態は、仕様をどこまで決められるか、変更の見込み、成果物を検査できるかで選びます。Parcelを使うかどうかは、この条件を踏まえて決めます。

• 一括請負：要件と納品物を早期に確定できる開発
• 準委任：要件を検証しながら進める業務
• 段階発注：要件定義、試作、本開発を分ける案件

契約条件や変更時の扱いは方法ごとに異なります。そのため、案件の確かさに合う方法を選びます。

完成したシステムを受け取る一括請負

一括請負では、契約時に仕様と検収条件を明確にし、納期や金額もできるだけ決めておきます。そのうえで、ベンダーは成果物を完成させて納品します。

一括請負は、利用者、画面、権限が固まった小規模な社内ツールや、基本設計後の開発に適しています。APIや対応ブラウザ、テスト条件まで固まっている案件が前提です。

一括請負は予算を立てやすい一方で、契約後の画面追加や業務フローの変更には、変更契約や追加見積もりが発生します。

相談・要件定義・改善を進める準委任

準委任は、成果物の完成だけでなく、業務の遂行そのものに報酬を支払う形態です。要件整理や設計支援、開発支援、プロジェクト管理などが対象になります。

利用部門の要望を確かめる試作や、既存システムの調査、Parcelと他のバンドラーの比較検証に使えます。また、計画を更新しながら進めるアジャイル開発にも適しています。

契約書には、作業時間、体制、報告方法を記載します。さらに、成果物の扱いや未消化分の精算方法も盛り込みます。記載がないと、予算と期待値がずれるおそれがあります。

要件定義・試作・本開発を分ける段階発注

初めてParcelを採用する場合は、要件定義または技術検証を先に行います。本番システム全体を最初から発注せず、契約を段階ごとに分けて進めます。

1. 最初の契約で、利用者と主要画面の整理
2. 次の契約で、React・TypeScript・Parcelによる小さな試作
3. 続く契約で、APIと本番機能の実装

各段階の終了条件と、次の段階へ進まない場合の扱いを決めておきます。そうすると、技術選定の失敗や不要な作り込みを抑えられます。

RFPと要件整理の準備範囲

RFPは、提案依頼先が同じ前提で提案や見積もりを作るための共通資料です。

仕様書は、完璧でなくても依頼できます。業務課題と対象範囲、制約を示せば、ベンダー間で見積もり条件をそろえやすくなります。さらに、優先順位と予算の考え方も示しておきます。

業務と利用者の言語化

業務要件は、利用者、業務フロー、非機能要件の3つの観点で整理します。

• 利用者：誰がいつ何を判断するかを整理し、管理者、現場担当者、承認者、外部ユーザーなどに分けます。
• 業務フロー：現状と導入後の流れを描き、画面数、検索条件、一覧件数を記載します。CSV、通知、承認経路も書きます。権限、監査ログ、移行量も残します。
• 非機能要件：利用者数、同時アクセス数、初期表示、稼働時間を記します。

非機能要件では、ブラウザやスマートフォンの対応と、バックアップや復旧目標を書いておきます。

• 個人情報：扱いの有無を書きます。
• SSO：利用の有無を書きます。
• 診断要否：診断を行うかどうかを書きます。

これらが書かれていれば、Parcelのフロント作業とAPI・DB作業を正しく見積もれます。非機能要件を省くと、性能や権限、監査に関わる改修が後から追加されがちです。

Parcelに関する技術要件と納品物

技術要件には、採用理由と検証項目を含めます。「Parcelを使う」とだけ書くのは避けます。

納品物は、ソースコードに加えて、設計資料や権利関連の資料まで含めて定めます。どの資料をどこまで渡すかを項目ごとに書いておけば、曖昧な納品を避けられます。

• 実行環境：Parcel 2のバージョン、Node.jsのLTS、パッケージマネージャー、lockfileを指定します。
• ビルド条件：ブラウザ対象、SSR・静的生成、`.parcelrc`を明記します。プラグイン、ソースマップ、CIビルド、成果物配置先も示します。
• 技術検証：React Server Components、レガシーブラウザ、モノレポ、Web Worker、オフライン機能を、小さく実証します。
• 設計・運用資料：要件定義書、画面・API仕様書、データ定義を含めます。インフラ構成、操作手順、運用引継ぎ資料も対象にします。
• コード・権利関連：`package.json`、テスト仕様・結果、脆弱性対応方針を含めます。SBOM、ライセンス一覧、バックアップ・復旧手順も入ります。

著作権や第三者ライセンスを確認します。リポジトリの所有者や開発環境へのアクセス権も、契約前に確かめておく必要があります。

提案依頼の条件をそろえた比較

提案依頼先の提案内容は、依頼の渡し方と提案書の形をそろえたうえで比べます。また、確認する観点も各社で同じにします。

• 依頼条件：同じRFP、質問期限、回答形式を渡します。
• 提案書：採用理由と代替案、開発体制を分けてもらいます。工程や前提条件、除外範囲も別に示してもらいます。
• 確認項目：リスク、テスト方針、保守体制、概算費用を確認します。
• Parcelの実績：「Parcel対応可能」だけでなく、Parcel 2の実績や`.parcelrc`の設計経験を尋ねます。
• 移行と担当範囲：既存フロントからの移行経験と、バックエンド・インフラの担当範囲。

契約形態とセキュリティの責任分界

契約書では、誰が何をいつまでに行い、何をもって完了とするかを明確にします。完了の条件は、技術用語とは別に、契約書の文言で具体的に定めます。

IPAの「情報システム・モデル取引・契約書（第二版）」は、請負と準委任、セキュリティなどを整理した資料です。プロジェクトマネジメント義務や発注者の協力義務、複数契約の関係も扱っています。

関連文書は2025年4月8日に更新されています。実際の契約は案件ごとに異なるため、必要に応じて専門家に確認します。

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

契約では、請負と準委任のそれぞれについて、完了条件と変更時の扱いを具体的に定めます。知的財産とOSSの利用条件も決めておきます。

• 請負：検収期間と方法、契約不適合への対応、納期遅延、再委託、損害賠償の範囲を定めます。
• 仕様変更：発注者の承認者と依頼書式を決め、影響を調べたうえで、追加費用と納期に合意してから着手します。
• 準委任：作業時間報告、定例会、成果物の位置付け、途中終了時の精算、担当交代条件を明記します。
• 権利関係：コード、設計書、テストデータ、プラグインの帰属と利用許諾を確認します。納品後の利用範囲や、ライセンス表示・著作権表示の義務も含めます。
• 保守移管：ベンダー汎用部品を含め、継続利用や改修、別会社への引き継ぎが可能かを定めます。

準委任の作業条件を明記しておけば、請負と同じ完成保証を期待するといった誤解を防げます。また、Parcel本体やnpmパッケージには、第三者のOSSライセンスが適用されます。

依存パッケージから個人情報までの責任分界

Parcelのビルド成功は、Webシステムの安全性とは別に確認する必要があります。そのため、発注者、ベンダー、クラウド事業者の責任を分けて決めます。

• アプリ対策：認証・認可、セッション、秘密情報の管理を要件に入れます。SQLインジェクションやXSS、CSRFへの対策も含めます。
• 運用対策：アクセスログ、WAF、バックアップ、脆弱性診断、インシデント対応を定めます。
• 個人情報の取り扱い：扱う場合は、個人情報保護委員会のガイドラインに沿い、アクセス制御や認証、不正アクセス対策、委託先の監督を確認します。
• 依存パッケージ：lockfile、Node.js、Parcelの更新を保守契約に含めます。脆弱性スキャン、SBOMの更新、緊急パッチの連絡時間も含みます。

依存パッケージの脆弱性は、初回納品の後にも見つかります。Parcelは2025年9月のv2.16.0や2026年2月のv2.16.4など更新が続くため、リリース情報を確認して適用の可否を判断できる体制が必要です。

Parcelのシステム開発費用・相場と見積もりの内訳

Parcel本体はオープンソースのため、通常はライセンス購入費がかかりません。ただし、無料になるのはビルドツールのライセンス部分です。

外注では、業務整理やUI/UX、フロントエンドに費用がかかります。さらに、API・DBや認証、クラウドも費用の対象です。テストや移行、教育、保守にも費用がかかります。

Parcelで一部の設定工数を抑えられる可能性はありますが、業務ロジックやデータ連携の費用はなくなりません。

規模別の費用レンジ

公開相場は案件の規模や前提で幅があります（出典: SIA株式会社「システム開発の費用・相場【2026年版】」、2026年7月更新）。次の金額は、各資料が示す一般的な目安です。

• 小規模（SIA）：簡易な業務管理ツールなどは100万〜300万円です。
• 中規模（SIA）：部門横断の業務システムや会員制Webは500万〜1,000万円です。
• 大規模（SIA）：全社基幹システムや大規模Webサービスは1,000万円〜数千万円以上です。
• リサーチノート：PoC・社内ツール（5〜10画面程度）は50万〜200万円、中規模業務Webシステムは200万〜800万円です。
• 本番・高セキュリティ：リサーチノートの目安は800万〜2,000万円程度です。

金額の差は、画面数や利用者数、連携先から生まれます。さらに、データ移行やセキュリティ、テスト範囲も関わります。発注先の体制によっても変わります。

2026年の公開情報では、人月単価も60万〜200万円程度です（出典: SIA株式会社、2026年）。8人月なら単純計算で480万〜1,600万円です。

この計算は、開発者の作業分だけを示したものです。PMや要件定義、デザイン、インフラ、テスト、予備費を含む最終見積もりとは違います。そのため、自社の前提条件をそろえ、特定の金額を相場と断定せずに比べます。

Parcel固有費用と周辺費用の内訳

見積もりでは、初期開発費と継続費を分け、作業範囲ごとの内訳を次のとおり確認します。

• 開発・設計：要件定義や画面・UI、フロント実装を分けます。Parcel設定・プラグイン、API・DB、認証認可も別に示します。
• 検証・移行：CI/CDや単体・結合・E2Eテスト、負荷試験を分けます。脆弱性診断、データ移行、教育、リリース支援も別に示します。
• 別途費用：クラウドやCDN、監視、WAFは開発費に含まれないことがあります。外部SaaS、SSOライセンス、決済手数料も、同様に見ておく必要があります。
• 保守：初期開発費の年15〜20%程度が一般的な目安です。800万円なら年120万〜160万円、月10万〜約13万円です。

保守費は、ParcelやNode.jsの更新、障害対応、監視をどこまで含むかで変わります。問い合わせや追加開発を含めるかどうかも、保守費の差になります。

月の対応時間や受付時間、復旧目標を確認します。更新の責任や追加開発の単価も見ておきます。

委託先の選び方と相見積もりの比較ポイント

委託先は、業務理解から保守までを一体で扱えるかで見ます。具体的には、業務理解と要件定義、フロントエンドとバックエンドを一体で扱えるかを確認します。インフラ、セキュリティ、保守も対象です。Parcelを使えるかどうかは、その判断の一部にすぎず、ツール名の掲載だけで選ぶことはありません。

採用実績が公開されていない場合は、商談でバージョンや構成を質問します。`.parcelrc`の扱い、CI、移行経験なども対象です。

実績の構成と役割

Parcelの利用実績だけでなく、業務領域や構成、担当範囲が自社案件に近いかも確認します。

• 構成経験：React・TypeScriptのSPAやAPI連携、管理画面を確認します。権限、クラウド、CI/CD、既存刷新の経験も見ます。
• 実績の説明：利用者数、画面数、連携先、担当工程、納品後の運用体制を、匿名化したうえで伝えられるかを見ます。
• 技術選定：SSRやReact Server Components、モノレポの扱いを踏まえた代替案を尋ねます。社内標準、レガシーブラウザ、習熟度も含めます。
• 移行性：Parcelの採用・不採用条件と、将来の移行方法を説明できるか確認します。

実績紹介で顧客名や金額を開示できない場合でも、匿名化した情報は比較の手がかりになります。

条件によっては、ViteやWebpackが合理的な場合もあります。採用条件と将来の移行方法を説明できるかは、長期の委託先を評価する材料になります。

同じ条件での相見積もりの比較

相見積もりでは、金額を並べる前に、同じ範囲と条件で比べられているかを確かめます。

• 費用と体制：総額や工程別費用、保守費を並べます。人数・役割、期間、クラウド費も並べます。
• 契約面：前提、除外範囲、追加費用の条件、検収条件をそろえます。
• 提案体制：実装担当者の同席、発注者側の作業、意思決定期限を確認します。
• 判断の進め方：ベンダーが決める論点と期限を示し、発注者と協力して進める提案かを見ます。

A社に負荷試験が含まれ、B社では別費用なら、総額の単純な比較では判断できません。安さが人員不足やテスト省略によるものか、高さが要件定義や移行まで含むためかを確認します。

要件の未確定部分をすべて「発注者確認」とする提案では、発注者の負担や追加費用を見落としがちです。

発注後のリスクと引き継ぎやすさ

外注では、納期や予算に加えて、保守の継続性と技術選定のリスクも評価します。

• 継続性：担当者の退職や再委託先の変更、OSSの脆弱性を考慮します。アカウントの名義、コードの保管、設計書の不足も見ます。
• 管理権限：リポジトリやクラウド、ドメインの管理者を決めます。証明書、CI/CD、監視の管理者も決め、発注者も必要な権限を持ちます。
• Parcelの適合性：標準CIやSSRなどの要件、保守人材の状況によっては、学習や移行のコストが効果を上回る可能性があります。
• 評価軸：保守性、脆弱性対応、採用難易度、別ツールへの移行性も評価表に加えます。

Parcelを避ける条件として、標準CIが別のバンドラー向けである場合、SSRやフレームワーク固有の要件が強い場合、保守できる人材がいない場合があります。

よくある質問

Parcelのシステム開発を発注・外注するときの疑問を、順にまとめます。ライセンスと費用、開発会社の選び方を分けて考えると、提案を比べやすくなります。

Parcelの導入費用は無料ですか？

ParcelはMITライセンスのオープンソースで、通常、本体のライセンス購入費はかかりません。ただし、要件定義や画面開発、API、クラウドには費用がかかります。テストや移行、保守も費用の対象です。

npmパッケージなどの第三者ソフトウェアについても、ライセンス表示と脆弱性対応の責任を確認します。

Parcelの開発は請負と準委任のどちらがよいですか？

完成条件を決められる開発は請負、要件定義や技術検証、継続的な改善は準委任が候補です。

たとえば、要件定義を準委任、本開発を請負、リリース後の改善を準委任とするように、工程ごとに分ける方法もあります。

契約形態の名称だけでなく、契約書の中身も確認します。成果物や作業範囲、報酬、検収、変更管理がその対象です。

Parcelの実績がない会社にも相談できますか？

相談はできます。公開情報だけでParcelの採用実績を断定せず、商談では確認の観点を次のとおり整理します。

• 近い開発経験：React・TypeScript、API・DB、認証、クラウド、CI/CD、移行・保守の経験を確認します。
• 技術選定の説明：Parcelを使う条件と別のバンドラーを選ぶ条件を説明できるか見ます。
• 小規模な検証：納品物と評価基準を決めて技術検証を依頼し、確認後に本開発へ進めばリスクを抑えられます。

まとめ

発注では、Parcelが担うフロントエンドのビルドと、業務システム全体の機能を分けて考えます。RFPには、利用者や業務フロー、画面を書きます。

API、データ、権限も含めます。性能やセキュリティ、納品物も、RFPにまとめます。要件の確かさに合わせて、請負、準委任、段階発注のいずれかを選びます。

相場のレンジと見積条件のそろえ方

費用は、要件定義や業務ロジック、画面の作り込みで大きく変わります。API・DBや認証、テストも影響します。移行、インフラ、保守の範囲によっても変わります。

2026年の公開相場には幅があり、同じ画面数でも、データ連携や監査要件によって金額は変わります。総額だけでなく、工程の内訳や前提、除外範囲、保守も比べます。

委託先には、Parcel 2の対応状況やビルド設定、CIを確認します。脆弱性対応や、ソースコードと設計書の引き渡しも確かめます。

次の一歩：小さなRFPと技術検証

要件が固まっていない場合は、相見積もりを急がず、業務課題と主要画面を整理する要件定義か、Parcelの小さな試作から始めます。

評価基準、成果物、契約終了条件を先に決め、技術と委託先の相性を確かめてから本発注へ進みます。そうすると、納期・費用・保守の不確実性を下げられます。

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

▼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を創業。