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

JSFのシステムを発注・外注するなら、JSFの経験年数だけでなく、既存資産の調査、要件整理、契約上の責任分界、保守体制まで含めて委託先を選ぶことが成功の近道です。

JSFはJavaServer Facesを指すことが多く、現在の仕様名はJakarta Facesです。画面だけを作る案件に見えても、Java、アプリケーションサーバー、データベース、認証、バッチ、帳票、運用監視まで関係するため、発注前の整理が不十分だと見積もりの追加や納期遅延につながります。この記事では、JSFのシステムを新規開発・改修・移行する企業に向けて、発注形態の選び方、RFPと要件のまとめ方、契約形態、費用相場、委託先の比較方法を順番に解説します。

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

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

JSFのシステム開発を外注するときは、「JSFで画面を作れる会社」を探すだけでは不十分です。どの資産を残し、どの機能を作り替え、どこまでを委託先に任せるかを先に決めることで、提案内容と見積もりを同じ条件で比較できます。

JSFは旧称のJavaServer Facesとして知られている画面フレームワークで、現在はJakarta Server Faces、通称Jakarta Facesとして標準化されています。Jakarta Faces 4.1はJakarta EE 11向けの仕様で、UIコンポーネント、状態管理、イベント処理、入力検証、ページ遷移、国際化、アクセシビリティなどを定義し、Java SE 17以上を最低要件としています（出典: Eclipse Foundation「Jakarta Faces 4.1」、2026年確認）。

ただし、既存案件ではJava EE 8以前のjavax系API、Jakarta EE 9以降のjakarta系API、MojarraやApache MyFaces、PrimeFacesなどのコンポーネントライブラリが混在している場合があります。発注書に「JSF対応」とだけ書くと、対応するバージョンや実装が食い違うため、javax・jakartaの別、Javaのバージョン、サーバー製品、UI部品の世代を明記する必要があります。

依頼内容は大きく、新しい業務システムを作る新規開発、既存画面や業務ルールを改修する保守開発、古いJSFを別のJava・Jakarta EE基盤へ移すモダナイゼーションの三つに分かれます。新規開発では業務フローと画面要件を中心に整理しますが、保守ではソースコードや設計書の欠落、移行では依存ライブラリやデータ互換性の確認が重要になります。

たとえば、既存JSFを残したままクラウドへ移す場合は、ステートフルなセッション、ファイルアップロード、セッションレプリケーション、ログの保存、障害時の復旧手順を先に検証します。画面の刷新を目的にReactなどへ段階移行する場合は、API化、認証の共通化、データの責任範囲を決めてから画面単位の優先順位を付けます。公開事例として、2023年12月22日掲載のクレジットカード会社向けアプリサービス基盤では、Java、Linux、DB2、JSFの組み合わせが紹介されています（出典: アクロホールディングス開発実績、2023年）。

JSFのシステム発注形態はどれを選ぶべきですか？

結論から言うと、業務要件と成果物を固められる案件は請負型、仕様を調整しながら進める案件や既存システムの調査は準委任型、社内に業務責任者や技術者がいる案件は部分委託が向いています。すべての工程を一つの契約に押し込むのではなく、調査・要件定義・開発・保守で適した形を組み合わせることが現実的です。

要件、納品物、検収条件、納期をある程度確定できる場合は、要件定義から設計、実装、テスト、リリースまでを請負で委託しやすくなります。社内の担当者が少なくても進めやすく、責任の所在を整理しやすい点がメリットです。一方で、発注時点の要件が曖昧なまま請負契約を結ぶと、仕様変更のたびに追加見積もりが発生し、発注者と受託者の双方が疲弊しやすくなります。

JSF案件で請負を選ぶ場合は、画面一覧だけでなく、入力チェック、権限、承認経路、帳票、外部連携、エラー時の処理、性能目標まで成果物の範囲に含めます。特に「管理画面一式」のような表現は、画面数や例外パターンをめぐる認識違いが起きるため避ける必要があります。

既存JSFの調査、段階的な改修、画面を見ながらの要件調整では、稼働時間や体制に対して対価を支払う準委任型が適しています。発注者側にプロダクトオーナーや業務責任者がいて、優先順位を毎月または毎スプリントで決められることが前提です。受託者に完成品の結果だけを求めるのではなく、調査結果、設計書、コード、テスト記録などの作業成果を定義します。

準委任型では、月の稼働幅、担当者のスキル、会議時間、レビューの責任、欠勤時の交代、作業報告の方法を契約に定めます。「何でも対応できる時間」とすると、優先順位の低い作業が増えたり、保守と新規開発が混ざったりするため、バックログやチケットを単位に管理することが有効です。

業務知識を持つ社員がいる場合は、業務フローや受入判断を社内で担い、JSFの移行調査、共通部品、性能試験、セキュリティ診断、クラウド構築など専門性の高い部分を外注する方法があります。知識が社内に残りやすく、将来の保守会社変更にも備えやすい一方、社内担当者の時間を確保できなければ意思決定が遅れます。

部分委託を選ぶときは、システム全体の責任者を一人決め、ソースコード、リポジトリ、設計書、CI/CD設定、クラウドアカウントの管理者を明確にします。複数社に分ける場合も、API仕様、テスト環境、障害窓口、リリース手順を共通化しなければ、委託先同士の調整費用が増えるため注意が必要です。

RFPと要件整理はどこまで準備してから依頼しますか？

RFPは提案依頼書のことで、依頼の背景、目的、対象業務、求める機能、制約、スケジュール、予算の考え方、提案してほしい内容を委託候補へ同じ条件で伝える文書です。完璧な仕様書である必要はありませんが、「何を解決したいか」と「何を比較するか」が伝わる状態まで整理すると、見積もりの精度と提案の質が上がります。

既存システムの発注では、最初にJSFのバージョン、Javaのバージョン、javax・jakartaの別、MojarraまたはMyFaces、PrimeFacesなどのUI部品、アプリケーションサーバー、DB、認証方式、外部API、バッチ、帳票、監視方法を一覧にします。ソースコードがあっても、ビルド手順や本番設定が欠けていると再現できないため、リポジトリ、設定ファイル、秘密情報の保管場所、テストデータの作り方も確認します。

移行を含む場合は、利用頻度が高い画面、改修が多い画面、障害が多い画面、業務停止の影響が大きい画面を分けて記録します。全面移行を前提にせず、現行維持、javaxからjakartaへの移行、JSF画面を残したAPI分離、Reactなどへの段階移行を比較できるようにすると、技術選択が目的化しにくくなります。

機能要件には、利用者の種類、画面、検索条件、登録・更新・削除、承認経路、権限、通知、帳票、外部連携、データ移行を記載します。画面数だけでなく、入力チェックの数、業務ルールの分岐、同時編集、取消や差戻しといった例外処理も示すと、JSF特有の画面状態やバリデーションの設計を比較しやすくなります。

非機能要件には、利用者数、ピーク時の同時接続、応答時間、稼働時間、バックアップ、復旧目標、ログ保存期間、監査、アクセシビリティ、脆弱性対応、運用窓口を含めます。認証だけでなく、CSRF、XSS、セッション管理、権限分離、依存ライブラリの更新を受入条件に含める際は、OWASP Application Security Verification Standard 5.0.0を確認項目の土台にできます（出典: OWASP ASVS、2025年5月公開）。

RFPには、提案書の構成、見積もりの内訳、想定体制、工程、前提条件、除外事項、保守範囲、納品物、発注者に必要な作業、質問期限を指定します。JSF案件では、対象のJava・Jakarta EE世代、候補サーバー、UIコンポーネント、クラウドやコンテナの前提を候補会社から説明させると、単に「対応可能」と書いた提案を見分けやすくなります。

不確実性が高いときは、本開発の前に代表的な入力画面、複雑な一覧、認証、外部API連携の四つを小さなPoCで検証します。判定基準は、画面応答、状態保存、権限、テスト自動化、ログ、コンテナ起動、障害時の復旧など、後から変更しにくい技術条件にします。PoCの費用、成果物、失敗時の扱いも先に合意すると、無償提案の範囲が不明確になるリスクを減らせます。

JSF開発の契約形態と責任分界はどう決めますか？

契約形態は、作るものを約束する請負と、業務を遂行することを約束する準委任を使い分けます。契約名だけで判断せず、どの工程で何を成果物とし、誰が意思決定し、仕様変更や障害が起きたときにどの手順で費用と納期を見直すかを文書化することが大切です。

要件定義の前に現行調査が必要なら、調査・企画は準委任、要件と成果物が固まった設計・実装は請負、リリース後の監視や改修は準委任という分け方が考えられます。反対に、要件が変わり続けるのに全工程を請負にすると、変更管理が膨らみやすくなります。段階ごとに契約を分ける場合は、前工程の成果物を次工程の入力にする関係を明記します。

IPAの「情報システム・モデル取引・契約書」には、ユーザー企業とITベンダーの役割を整理する契約書やチェックリストが用意されています。2025年6月にはサイト構成が見直され、アジャイル開発版では2025年4月更新の外部委託モデル契約も公開されています（出典: IPA「情報システム・モデル取引・契約書」、2025年）。自社の法務・情報システム部門で内容を確認し、案件の実情に合わせて修正します。

成果物は、ソースコード、実行可能ファイル、画面設計書、業務・データ設計書、API仕様、テスト仕様書と結果、移行手順、運用手順、監視設定、インフラ定義、教育資料まで分解して記載します。検収では、正常系の画面が表示されるだけでなく、入力エラー、権限不足、二重送信、タイムアウト、外部連携失敗、ロールバックなどの受入条件を定めます。

第三者ライブラリのライセンス、OSSの脆弱性対応、既存コードの著作権、開発成果物の利用範囲、再委託の可否、保守会社を変更するときの引継ぎも契約に含めます。ソースコードを受け取るだけでは再現できないことがあるため、ビルド環境、依存関係、テストデータ、CI/CD設定を含む引渡しを条件にすることが重要です。

業務システムでは、開発中に現場から要望が出たり、法令や社内ルールが変わったりします。変更要求を受け付ける窓口、影響調査の期限、見積もりを出す単位、承認者、納期の再設定方法を決めておくと、口頭の追加依頼がプロジェクト全体を圧迫する事態を避けられます。

保守契約では、問い合わせ対応、障害対応、脆弱性パッチの検証、Java・サーバー・UI部品のバージョンアップ、バックアップ確認、月次報告、追加開発を分けます。24時間対応が必要か、営業時間内でよいか、重大障害の一次応答時間と復旧目標は何かを明記し、保守費だけで比較しないようにします。

JSFのシステム発注費用・相場はいくらですか？

JSFだけを切り出した公表価格表はほとんどないため、以下は一般的な業務Webシステムの相場と、JSFの画面・連携・移行要件を組み合わせた概算レンジです。画面数、業務ルール、ユーザー数、外部連携、既存データ、非機能要件で大きく変わるため、特定の金額を断定せず、前提条件付きの予算枠として使います。

小規模は、1部門向けのCRUD、ログイン、検索・一覧、簡易帳票、外部連携が0〜1本程度で、5〜10人月、2〜5か月、初期開発費は400万〜1,200万円程度が一つの目安です。中規模は複数部門、承認ワークフロー、権限、帳票、API・バッチ、データ移行を含み、15〜35人月、5〜10か月、1,500万〜5,000万円程度の幅になります。

大規模は全社基幹、複数拠点、大量データ、SSO、監査ログ、多数のシステム連携まで含み、50〜120人月、10〜24か月、5,000万円〜2億円以上になる可能性があります。これはJSF固有の市場統計ではなく、業務システムの工数と要件を基にした推定です。SIA株式会社の2026年版相場でも、小規模100万〜300万円、中規模500万〜1,000万円、大規模1,000万円〜数千万円以上、人月単価60万〜200万円程度という広いレンジが示されています（出典: SIA株式会社「システム開発の費用・相場 2026年版」、2026年7月）。

見積書は、現行調査・要件定義、画面設計、共通部品、業務ロジック、API・バッチ、データ移行、インフラ、単体・結合・総合テスト、受入支援、教育、リリース、予備費に分けて確認します。JSFでは、画面数が同じでも入力項目やバリデーション、状態管理、承認の分岐が増えるとテスト工数が膨らむため、単純な画面枚数比較だけでは判断できません。

費用の大部分は人件費ですが、クラウド、アプリケーションサーバーの商用サポート、データベース、監視、バックアップ、脆弱性診断、開発環境、移行用の一時環境も発生します。OSSを使う場合でも、パッチ検証や古いライブラリの延命、障害時の問い合わせ先が必要になるため、ライセンス費がないことと運用費が安いことを同一視しないようにします。

リサーチノートでは、保守運用費を初期費用の年15〜25％程度とする目安が示されていますが、これはJSF固有の統計ではなく、運用範囲を含めた参考値です。監視が営業時間内か24時間か、脆弱性対応を含むか、問い合わせ件数に上限があるか、追加開発を別契約にするかで金額は変わります。

初期費用だけでなく、3〜5年の保守、クラウド、サーバーサポート、ライブラリの更新、再教育、データ移行の追加リハーサルまでを合算して比較します。初期見積もりが安くても、ソースコードやIaCが引き渡されず、特定の会社にしか保守を頼めない場合は、将来の交代コストが高くなる可能性があります。

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

委託先は、JSFのキーワードを営業資料に載せているかではなく、業務理解とJava・Jakarta EEの技術力を同じプロジェクトで発揮できるかを確認します。公開情報だけでは現在の対応世代や担当者の実務経験までは判断できないため、提案時の質問、PoC、設計レビュー、保守体制を組み合わせて見極めます。

候補会社には、対象案件と同じJSFまたはJakarta Facesのバージョン、Java 17・21への対応、Mojarra・MyFaces・PrimeFacesの経験、WebLogic・JBoss EAP・Payaraなどのサーバー、SSO、監査ログ、性能試験、データ移行、脆弱性対応の実績を質問します。過去事例は会社名や規模だけでなく、担当範囲、稼働後の保守年数、障害時の体制、現在も対応可能な技術世代まで確認します。

大手SIerは大規模なPMや複数ベンダー管理に強い一方、費用や意思決定の階層が増える場合があります。中小の開発会社は柔軟な体制を組みやすい一方、特定の担当者への依存や交代時の引継ぎを確認する必要があります。実行基盤の製品ベンダーと開発会社を混同せず、設計・実装・運用の責任を誰が担うかを提案書に書いてもらいます。

相見積もりを取るときは、同じRFP、同じ画面一覧、同じデータ移行条件、同じ非機能要件を渡します。そのうえで、要件定義、設計、開発、テスト、移行、教育、保守を工程別に並べ、工数、単価、体制、期間、前提、除外事項を比較します。「開発一式」が安い会社は、移行や受入支援が除外されているだけかもしれないため、安さよりも含まれる成果物を確認します。

見積もりの差が大きいときは、画面数の数え方、レビュー回数、テストデータ作成、外部APIの責任範囲、クラウド構築、PM費、予備費の扱いを聞きます。候補会社に「この条件なら何がリスクか」「費用を抑えるなら何を削るか」「削ってはいけない品質項目は何か」を説明してもらうと、プロジェクトへの理解度も確認できます。

提案書が優れていても、実際に参加する技術者やプロジェクトマネージャーが別の人では評価が変わります。契約前に、責任者、リードエンジニア、インフラ担当、テスト担当、保守担当の氏名または役割、稼働率、交代時の手順を確認します。可能であれば、代表画面の設計レビューやPoCに本番担当者にも参加してもらいます。

また、保守の引継ぎ可能性も選定基準に含めます。ソースコード、設計書、テスト、インフラ定義、アカウント権限、障害履歴を定期的に発注者側へ戻せる会社であれば、将来の内製化や別会社への交代を検討しやすくなります。委託先を決めることは、開発費を決めるだけでなく、数年間の運用能力を買うことでもあります。

JSFのシステム外注で起きやすい失敗と対策

JSF案件の失敗は、技術選定そのものよりも、古い資産の状態や業務ルールが見えないまま発注することから生じやすいです。発注前にリスクを仮説として書き出し、PoC、契約、テスト、引継ぎのどこで検証するかを決めておくと、問題が発生してから慌てずに済みます。

既存システムでは、仕様書と実装が一致しない、担当者しか知らない設定がある、テスト環境で本番障害を再現できないといった問題が起こります。いきなり全面改修を始めず、ソースコード、依存関係、DB、ログ、ジョブ、外部連携を調査する工程を置き、調査の成果物と残課題を受け取ります。

javaxからjakartaへの移行では、パッケージ名の変更だけでなく、アプリケーションサーバー、ライブラリ、設定、認証、テスト、運用手順の互換性を確認します。Jakarta Faces 4.1ではフル状態保存が非推奨になっているため、状態保存方式やセッションサイズを本番相当の条件で検証し、単純な置換作業として見積もらないことが大切です（出典: Eclipse Foundation「Jakarta Faces 4.1」、2026年確認）。

JSFは画面状態を扱うため、クラウドへ移行して負荷分散する際に、セッションの保持方法が論点になります。セッションレプリケーションを使うのか、スティッキーセッションにするのか、状態を外部化できるのかを決め、同時利用者数、ファイルアップロード、タイムアウト、再ログイン、片系障害を試験します。

クラウド事業者の責任範囲と開発会社の責任範囲も整理します。ネットワークやマネージドDBをクラウド側が担っても、アプリケーションのログ設計、バックアップの復元確認、秘密情報の更新、脆弱性対応、障害時の連絡手順は発注者と開発会社の責任になる場合があります。

JSFの経験者が少ないことだけを問題にするのではなく、特定の担当者がいなくても保守できる仕組みを契約と運用に組み込みます。コードレビュー、設計レビュー、定期的なナレッジ共有、運用手順の更新、障害後の振り返りを行い、リポジトリやドキュメントを発注者がいつでも確認できる状態にします。

委託先を交代する可能性がある場合は、半年後に別会社がビルドできるか、テストを実行できるか、クラウド環境を再現できるかを確認します。納品時だけに引継ぎを集中させず、設計・開発中から成果物を共有してもらうことで、最後に大量の未整理資料を受け取るリスクを抑えられます。

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

ここでは、発注前に特に多い質問へ、JSFの技術世代と業務システムの委託実務を踏まえて回答します。個別案件の費用や契約条件は、既存資産と求める品質によって変わるため、回答は判断の軸としてご利用ください。

新規開発できるかどうかは、JSFという名称だけで決まりません。既存のJava資産や入力中心の業務画面を活かしたい場合は候補になりますが、公開サービスやリアルタイム性の高い画面では、ReactなどのフロントエンドとJavaのREST APIを組み合わせる方が適する場合もあります。2026年時点ではJakarta Faces 4.1が公開され、4.1.2のTCKファイルも2026年3月21日に配布されていますが、採用時は対応する実装・サーバー・保守体制を確認します。

依頼できますが、最初から確定見積もりを求めるのではなく、現行調査や要件定義の見積もり、または概算レンジを依頼する方法が安全です。利用目的、対象業務、利用者数、画面の例、既存システムの有無、希望時期、予算の考え方を伝え、何が未確定なのかを提案書に書いてもらいます。調査後に本開発の見積もりを更新する前提を契約にも残します。

現行のバージョン、Java、javax・jakartaの別、UIコンポーネント、アプリケーションサーバー、DB、認証、外部連携、移行対象は、分かる範囲で具体的に書きます。新規開発で技術選択に余地がある場合は、JSFを必須と断定せず、業務要件と非機能要件を示したうえで、JSF・Jakarta Faces・別のUI構成を比較提案してもらう方法もあります。技術名よりも、採用理由、将来の更新、保守体制、費用への影響を説明してもらうことが大切です。

費用を抑える基本は、必要な業務価値を優先順位付けし、標準機能や既存資産を活かし、要件定義とテストを省かないことです。画面を減らすだけでは、Excelや手作業が残って運用費が増える場合があります。代表的な画面と連携でPoCを行い、利用頻度の低い機能を後回しにし、見積もりの前提と除外事項を明確にします。

まとめ

JSFのシステムを発注・外注するときは、JSFの経験があるかだけで委託先を決めず、既存資産の状態、業務要件、非機能要件、契約、保守までを一つの計画として整理します。請負、準委任、部分委託を工程ごとに使い分け、RFPでは技術条件と成果物を明確にし、相見積もりでは金額だけでなく工数・前提・除外事項をそろえて比較します。

発注前は、JSF・Jakarta FacesとJavaの世代、画面・業務・連携・データ移行の範囲、性能・セキュリティ・復旧要件、契約形態、成果物、検収、変更管理、保守窓口、ソースコードとインフラ定義の引渡しを確認します。候補会社には同じRFPを渡し、担当者の体制、PoCの進め方、リスクと代替案まで比較します。

まだ要件が固まっていない場合は、いきなり開発一式を発注するのではなく、既存システムの棚卸しと業務ヒアリングから始めます。現状の課題、残したい資産、変えたい業務、希望時期、利用者、予算の幅を整理してRFPのたたき台を作り、複数社へ同じ条件で相談すると、JSFを残すのか、Jakarta Facesへ移行するのか、別の画面構成へ段階移行するのかを納得感のある形で判断できます。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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