JSFの発注は、既存資産の調査、要件と責任範囲の整理、委託先の比較を順に進めると、追加見積もりや納期遅延を抑えやすくなります。
発注形態、RFPと契約、費用相場、委託先選定の順で説明します。全体像は、JSFのシステム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・JSFのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
JSFのシステムを発注・外注する前に知っておきたい全体像
JSFの発注では、残す資産、作り替える機能、委託先に任せる範囲を先に決めておきます。条件をそろえておくと、提案と見積もりを比べやすくなります。
JSFとJakarta Facesの違い
JSFはJavaServer Facesの旧称で、現在はJakarta Server Faces、通称Jakarta Facesとして標準化されています。Jakarta Faces 4.1はJakarta EE 11向けの仕様で、Java SE 17以上を最低要件としています（出典: Eclipse Foundation「Jakarta Faces 4.1」、2026年確認）。
この仕様では、UIコンポーネント、状態管理、イベント処理を中心に定義しています。入力検証、ページ遷移、国際化、アクセシビリティなども、同じ仕様に含まれます。JSFの技術条件は、軸ごとに分けて書き出します。
- APIの世代：javax系かjakarta系か
- 実装と部品：Mojarra、Apache MyFaces、PrimeFacesなど
- 実行環境：Javaのバージョンとサーバー製品
既存案件では、これらの世代が混在することもあります。そのため「JSF対応」とだけ書くと認識がずれやすく、発注書には各条件を明記しておきます。
新規開発・保守・移行による依頼内容の違い
依頼内容は、新規開発、既存機能の保守開発、古いJSFを別のJava・Jakarta EE基盤へ移す移行のどれに当たるかで変わります。
- 新規開発：業務フローと画面要件の整理
- 保守開発：ソースコードや設計書の欠落の洗い出し
- 移行：依存ライブラリとデータ互換性の確認
JSFを残してクラウドへ移す場合は、ステートフルなセッションとファイルアップロードを先に検証します。そのほか、セッションレプリケーション、ログ保存、障害復旧も検証の対象です。
Reactなどへ段階的に移す場合は、先にAPI化、認証の共通化、データの責任範囲を決めます。そのうえで、画面ごとの優先順位を付けます。
開発実績の例として、2023年12月22日掲載のクレジットカード会社向けアプリサービス基盤では、Java、Linux、DB2、JSFの組み合わせが紹介されています（出典: アクロホールディングス開発実績、2023年）。
JSFのシステム発注形態の選び方
業務要件と成果物が固まった案件は請負が候補になり、仕様の調整や調査が中心の案件は準委任が候補になります。社内に責任者や技術者がいる場合は、部分委託を検討します。業務の性質は工程によって違うため、工程ごとに契約を組み合わせて考えます。
開発全体を請負で委託するケース
要件、納品物、検収条件、納期をある程度決められる場合は、請負が向いています。請負では、要件定義から設計、実装、テスト、リリースまでを委託できます。社内の担当者が少なくても進めやすく、責任の所在も整理できます。
契約書には、成果物の範囲と連携・品質の条件を具体的に書いておきます。
- 成果物の範囲：画面、入力チェック、権限、承認経路
- 連携と品質：帳票、外部連携、エラー処理、性能目標
要件が曖昧なまま契約すると、仕様変更のたびに追加見積もりが発生し、双方が疲弊しがちです。「管理画面一式」のような書き方では、画面数や例外の範囲がずれるため、具体化が必要です。
準委任やラボ型でチームを確保するケース
既存JSFの調査や段階的な改修、画面を見ながらの要件調整には、稼働時間や体制に対して対価を払う準委任型が適しています。
- 発注者の役割：プロダクトオーナーや業務責任者の配置
- 作業成果：調査結果、設計書、コード、テスト記録の定義
この形は、発注者側が毎月または毎スプリントで優先順位を決められることが前提になります。そのうえで、完成品だけでなく作業成果を契約に記します。
稼働時間は、月の稼働幅とスキルを決めたうえで、会議時間やレビュー責任も定めます。欠勤時の交代と作業報告の方法も、契約に書いておきます。
稼働時間を「何でも対応できる時間」としてしまうと、優先順位の低い作業が増え、保守と新規開発も混ざりやすくなります。そのため、バックログやチケット単位で管理します。
内製と部分委託を組み合わせるケース
業務知識を持つ社員がいる場合は、業務フローや受入判断を社内で担い、専門性の高い作業を外注できます。
- 委託候補：JSF移行調査、共通部品、性能試験
- 専門作業：セキュリティ診断、クラウド構築
社内に知識を残せるため、将来の保守会社の変更にも備えられます。一方で、社内担当者の時間を確保できなければ、意思決定が遅れます。
システム全体の責任者は一人決めておきます。ソースコードやリポジトリ、クラウドアカウントの管理者を明確にし、設計書とCI/CD設定についても管理者を決めます。
複数社へ分ける場合は、API仕様とテスト環境を各社でそろえます。障害窓口とリリース手順も同じ形にしておかないと、委託先どうしの調整費用が増えます。
RFPと要件整理の準備範囲
RFPは提案依頼書で、候補会社へ同じ条件を伝えるための文書です。依頼の背景と目的、対象業務、制約を中心に、予定や予算の考え方、提案事項も含めて書きます。
完璧な仕様書でなくても、「何を解決したいか」「何を比較するか」が整理されていれば、見積もりの精度と提案の質が上がります。
既存JSF資産の洗い出しと技術条件の統一
既存システムでは、JSFとJavaのバージョンやjavax・jakartaの別を一覧にします。あわせて、MojarraやMyFaces、PrimeFacesなどのUI部品も記録します。
- 実行環境：アプリケーションサーバー、DB、認証方式
- 周辺機能：外部API、バッチ、帳票、監視方法
ソースがあっても、ビルド手順や本番設定が欠けると再現できません。そのため、リポジトリと設定ファイルの所在を確認します。秘密情報の保管場所やテストデータの作り方も、加えて確かめます。
移行時は、画面ごとに利用頻度と改修頻度を記録します。障害の頻度や業務停止の影響が大きい画面も、分けて記録します。
現行維持やjavaxからjakartaへの移行を比べられるようにします。JSF画面を残したAPI分離、Reactなどへの段階移行も、同じ条件で並べます。全面移行を前提にしなければ、技術選択が目的化するのを防げます。
業務要件と非機能要件の書き分け
業務要件と非機能要件は分けて、それぞれに必要な条件をRFPに記載します。
- 機能要件：利用者、画面、検索条件、登録・更新・削除、承認経路、権限、通知、帳票、外部連携、データ移行
- 非機能要件：利用者数、ピーク時の同時接続、応答時間、稼働時間、バックアップ、復旧目標、ログ保存期間、監査、アクセシビリティ、脆弱性対応、運用窓口
画面数に加えて、例外処理も示します。入力チェックや業務ルールの分岐、同時編集、取消、差戻しが該当します。そうすると、JSFの画面状態やバリデーション設計を各社で比べやすくなります。
認証に加えて、CSRFやXSSへの対策、セッション管理を受入条件に含めます。権限分離や依存ライブラリ更新も、受入条件に入れます。
受入条件の確認には、OWASP Application Security Verification Standard 5.0.0を参照できます（出典: OWASP ASVS、2025年5月公開）。
RFPの提案条件とPoCの判定基準
RFPでは、提案書の構成や見積内訳、体制、工程を指定します。前提や除外事項、保守範囲、納品物、発注者の作業、質問期限も、あわせて示します。
JSF案件では、Java・Jakarta EEの世代と候補サーバーを、提案側に説明してもらいます。UI部品やクラウド、コンテナの前提も、同じように求めます。そうすると、「対応可能」とだけ書かれた提案を見分けられます。
不確実性が高い場合は、代表的な入力画面や複雑な一覧、認証、外部API連携を、小さなPoCで先に検証します。
- 画面と状態：応答、状態保存、権限
- 運用と品質：自動テスト、ログ、コンテナ起動、障害復旧
後から変えにくい技術条件を、PoCの判定基準にします。あわせて、PoCの費用や成果物、失敗時の扱いを合意し、無償提案の範囲を明確にします。
JSF開発の契約形態と責任分界
請負は作るものを約束する契約で、準委任は業務の遂行を約束する契約です。契約名だけで判断せず、工程ごとの成果物と意思決定者、仕様変更や障害時の費用・納期の見直し方を文書にします。
請負と準委任の工程ごとの使い分け
調査や開発の確定度に応じて契約形態を選び、工程どうしの成果物はつないでおきます。
- 準委任：現行調査・企画、リリース後の監視や改修
- 請負：要件と成果物が固まった設計・実装
- 工程を分ける場合：前工程の成果物を次工程の入力にすると明記
要件が変わり続ける案件を全工程請負にすると、変更管理の手間が膨らみがちです。
IPAの「情報システム・モデル取引・契約書」には、ユーザー企業とITベンダーの役割を整理した契約書やチェックリストがあります。2025年6月にサイト構成が見直され、アジャイル開発版では2025年4月更新の外部委託モデル契約も公開されています（出典: IPA「情報システム・モデル取引・契約書」、2025年）。
契約書は、法務・情報システム部門で確認したうえで、案件に合わせて修正します。
成果物・検収・知的財産の範囲
成果物、検収、知的財産、引継ぎの対象は、契約で具体的に定めます。
- 成果物：ソースコード、実行ファイル、画面・業務・データ設計書、API仕様、テスト仕様と結果、移行・運用手順、監視設定、インフラ定義、教育資料
- 検収：正常系の画面表示だけでなく、入力エラー、権限不足、二重送信、タイムアウト、外部連携失敗、ロールバックの受入条件
- 契約範囲：第三者ライブラリのライセンス、OSS脆弱性、著作権、成果物利用、再委託、保守会社変更時の引継ぎ
コードだけでは再現できないこともあります。そのため、ビルド環境や依存関係の情報を、テストデータやCI/CD設定とあわせて引渡しの条件に含めます。
仕様変更と保守の窓口
開発中には現場から要望が出たり、法令や社内ルールが変わったりします。そのため、契約には変更と保守の取り決めを残しておきます。
- 変更管理：窓口、影響調査の期限、見積単位、承認者、納期の再設定方法と、口頭依頼による圧迫の回避
- 保守範囲：問い合わせや障害対応、パッチ検証、Java・サーバー・UI部品の更新、バックアップ、月次報告と追加開発の区分
- 対応条件：24時間対応か営業時間内か、重大障害の一次応答時間と復旧目標
- 費用比較：保守費だけで比べないこと
JSFのシステム発注費用・相場の目安
JSF単体の公表価格表はほとんどありません。そのため、ここに示すのは、一般的な業務Webシステムの相場に、JSFの画面・連携・移行要件を加味した概算です。
費用は、画面数や業務ルール、ユーザー数、外部連携、既存データ、非機能要件などの前提条件で変わります。特定の金額ではなく、前提条件付きの予算枠として使います。
規模別の初期開発費の目安
規模ごとの工数、期間、初期開発費の目安は次のとおりです。各金額はJSF固有の統計ではなく、業務システムの工数と要件を基にした推定です。
- 小規模：5〜10人月、2〜5か月、400万〜1,200万円程度
- 中規模：15〜35人月、5〜10か月、1,500万〜5,000万円程度
- 大規模：50〜120人月、10〜24か月、5,000万円〜2億円以上の可能性
- 参考人月単価：60万〜200万円程度（出典: SIA株式会社「システム開発の費用・相場 2026年版」、2026年7月）
小規模は、1部門向けのCRUDやログイン、検索・一覧、簡易帳票、外部連携0〜1本程度の範囲です。中規模は、複数部門の承認ワークフローや権限、帳票、API・バッチ、データ移行を含みます。大規模は、全社基幹や複数拠点、大量データ、SSO、監査ログ、多数の連携まで含みます。
自社推定とは別に、SIA資料では、小規模100万〜300万円、中規模500万〜1,000万円、大規模1,000万円〜数千万円以上の相場例が示されています。
見積もりの工程別・要素別の内訳
見積書は、開発工程、検証と導入、実行・運用環境の費用を分けて見ます。
- 開発：調査・要件定義、画面設計、共通部品、業務ロジック、API・バッチ、データ移行、インフラ
- 検証と導入：単体・結合・総合テスト、受入支援、教育、リリース、予備費
- 環境：クラウド、商用サーバーサポート、DB、監視、バックアップ、脆弱性診断、開発環境、移行用の一時環境
- OSS運用：パッチ検証、古いライブラリの延命、障害時の問い合わせ先
画面数が同じでも、入力項目や検証、状態管理、承認分岐が増えると、テストの工数が膨らみます。また、費用の大部分は人件費です。
なお、OSSはライセンス費がかからないことと、運用費が安いことが同じとは限りません。
保守・クラウドを含む総額の比較
総額を比べるときは、保守運用費の目安と対象期間をそろえます。
- 保守の目安：初期費用の年15〜25％程度。JSF固有の統計ではなく参考値
- 金額の条件：監視時間、脆弱性対応、問い合わせ件数の上限、追加開発の契約方法
- 比較期間：初期費用に加え、3〜5年分の保守、クラウド、サーバー支援、更新、再教育、移行リハーサル
- 交代費用：コードやIaCが引き渡されず特定会社に依存すると、将来高くなる可能性
JSFの委託先選定と見積比較で見るべきポイント
JSFの掲載実績だけでなく、業務理解とJava・Jakarta EEの技術力を同じ案件で発揮できるかを見ます。担当者の経験や対応世代は、公開情報から判断しにくいため、提案、PoC、設計レビュー、保守体制を確認します。
技術・移行・運用の確認項目
候補会社の比較は、技術世代、実績、体制、責任分界の四つの観点で行います。
- 技術世代：JSF・Jakarta Faces、Java、UI部品、サーバー
- 実績：移行、性能、データ、セキュリティ、保守の経験
- 体制：会社規模に応じたPM力、柔軟性、担当者の交代と引継ぎ
- 責任分界：基盤製品と開発の設計・実装・運用担当
案件と同じJSF・Jakarta Facesの版や、Java 17・21への対応を尋ねます。Mojarra・MyFaces・PrimeFacesや、WebLogic・JBoss EAP・Payaraなどの経験も確認します。
SSO、監査ログ、性能試験、データ移行、脆弱性対応の実績も確かめます。過去事例では、担当範囲や保守年数、障害体制、対応可能な技術世代も聞いておきます。
大手SIerは大規模PMや複数ベンダー管理に強い反面、費用や意思決定階層が増える場合があります。中小会社は柔軟な体制を組みやすいものの、担当者への依存や交代時の引継ぎを確かめます。
実行基盤の製品ベンダーと開発会社を分けたうえで、設計、実装、運用それぞれの責任者を提案書に明記してもらいます。
相見積もりの前提条件のそろえ方
各社へ渡す条件と、見積もりの比較項目をそろえておきます。
- 共通条件：RFP、画面一覧、データ移行、非機能要件
- 比較項目：工程ごとの工数、単価、体制、期間、前提、除外事項
- 差の確認：画面数、レビュー、テストデータ、外部API、クラウド、PM費と予備費
- 提案内容：条件上のリスク、削減案、削るべきでない品質項目
「開発一式」は安く見えても、移行や受入支援が除外されている場合があります。
提案の説明を聞くと、各社がプロジェクトをどこまで理解しているかを判断できます。
最終選定の担当者と保守の継続性
契約前には、実際に参加する担当者と、成果物を引き継げるかを確認します。
- 担当者：責任者、リード、インフラ・テスト・保守担当の役割と稼働率
- 継続性：交代手順と、成果物を発注者へ定期共有できる体制
提案書に載った人と、実際に参加する技術者やPMが異なると、評価も変わります。可能であれば、代表画面の設計レビューやPoCに、本番の担当者も参加してもらいます。
定期的に共有してもらう成果物は、ソースコード、設計書、テスト、インフラ定義、アカウント権限、障害履歴です。定期共有があれば、将来の内製化や別会社への交代を検討しやすくなります。
委託先の選定は、数年間の運用能力を見極めることでもあります。
JSFのシステム外注で起きやすい失敗と対策
失敗は、技術選定そのものより、古い資産や業務ルールが見えないまま発注することで起こりやすくなります。そのため、リスクを仮説として挙げ、PoC、契約、テスト、引継ぎのどこで確かめるかを決めておきます。
古いJSF資産を新規開発と同じ前提で扱わない進め方
古いJSF資産の状態と移行時の互換性を調べ、改修範囲を決めます。
- 現行資産：仕様書と実装、属人設定、テスト環境の再現性の調査
- 調査対象：ソース、依存関係、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日に配布されています。採用の際は、実装、サーバー、保守体制を確かめます。
要件が固まっていなくても見積もりを依頼できますか？
依頼はできますが、最初から確定見積もりを求めず、現行調査や要件定義の見積もり、または概算レンジを頼む方法が安全です。
利用目的や対象業務、利用者数、既存システムの有無を伝えます。画面例や希望時期、予算の考え方も示し、未確定の事項は提案書に記してもらいます。
調査後に本開発の見積もりを更新する前提も、契約に残します。
RFPにはJSFの技術名をどこまで書けばよいですか？
分かる範囲で、現行バージョンや、Java・javax・jakartaの別を具体的に記します。UI部品やサーバー、DB、認証、外部連携、移行対象も、書き添えます。
新規開発で技術選択に余地があるなら、JSFを必須と断定せず、業務・非機能要件を示します。そのうえで、JSFやJakarta Facesのほか、別の画面構成も比較提案してもらう方法があります。
採用理由や将来の更新、保守体制、費用への影響は、説明してもらうことが大切です。
JSFのシステム開発費を安くするにはどうすればよいですか？
必要な業務価値に優先順位を付け、標準機能や既存資産を活かします。ただし、要件定義とテストは省かないことが基本です。
画面を減らしても、Excelや手作業が残り、運用費が増える場合があります。そこで、代表画面と連携でPoCを行い、利用頻度の低い機能は後回しにします。あわせて、見積もりの前提と除外事項を明確にします。
まとめ
JSFの発注では、経験年数だけで委託先を決めず、資産、業務・非機能要件、契約、保守を一つの計画にまとめます。
請負、準委任、部分委託は工程ごとに使い分けます。RFPの技術条件と成果物を明確にし、見積もりは工数や前提、除外事項をそろえて比べます。
発注前に確認する項目
発注前には、JSF・Jakarta FacesとJavaの世代、画面・業務・連携・データ移行の範囲を確かめます。
性能やセキュリティ、復旧要件を確かめたうえで、契約形態や成果物、検収、変更管理、保守窓口も決めておきます。コードとインフラ定義の引渡しも、確認に含めます。
候補会社には同じRFPを渡し、担当者の体制、PoCの進め方、リスク、代替案を比較します。
最初の一歩は現状調査とRFPのたたき台
要件が固まっていなければ、開発一式ではなく現状調査から発注準備を始めます。
- 既存システムを洗い出し、業務担当者にヒアリングします。
- 課題、残す資産、変える業務、希望時期、利用者、予算幅を整理し、RFPのたたき台を作ります。
- 複数社へ同じ条件で相談し、JSFを残すか、Jakarta Facesへ移すか、別の画面構成へ段階移行するかを判断します。
▼全体ガイドの記事
・JSFのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。