JSFのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

JSFのシステム開発は、まず業務と既存資産を整理し、方式を選ぶところから始めます。その後は、設計・開発、テスト、移行、定着の順に進めます。この順で進めると、手戻りを抑えやすくなります。

全体像と費用の目安も、あわせて押さえておくと段取りを組みやすくなります。

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

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

JSFのシステムの全体像

JSFはJavaServer Facesの略称で、現在の正式な仕様名はJakarta Facesです。業務用のWeb画面を作る、サーバーサイドのUIフレームワークです。

JSF単体では業務システムは完成しません。画面はJSF、業務処理はCDIやEnterprise Beans、永続化はJPAと、役割ごとに部品を組み合わせます。たとえば、入力検証にはBean Validation、データベースにはRDBを使うなど、複数の部品でシステムを構成します。

JSFの画面と業務システムを構成する部品

JSFの画面は、FaceletsのテンプレートとUIコンポーネントで構成されます。フォームや検索条件、一覧表などを部品として再利用できます。

• 画面部品：ダイアログ、画面遷移、Ajaxによる部分更新の扱いです。
• 入力処理：値の変換・検証と、エラーメッセージをライフサイクルに組み込めます。
• 業務連携：入力をモデルに反映し、業務メソッドを呼び出してHTMLを返します。

入力項目と業務ルールが多い社内システムでは、この一連の画面処理が役立ちます。

画面状態をサーバーで管理する設計では、セッションサイズ、タイムアウト、同時利用者数の確認が欠かせません。ロードバランサーの配下では、セッションレプリケーションも検討の対象になります。

クラウドへ移す際は、ファイルの保存先も確認しておきます。

複数台構成でのセッション共有や、障害時の再送・二重登録は、PoCで確かめておきます。

画面仕様だけで移行を進めると、後半で構成変更が起きやすくなります。

JavaServer FacesとJakarta Facesの判断材料

新規開発では、Jakarta EE 11対応のJakarta Faces 4.1と、Java 17またはJava 21を候補にします。

アプリケーションサーバー、CDI、JPA、UI部品も、まとめて見ておく必要があります。

Jakarta Faces 4.1は、Java SE 17以上を前提としています。

Eclipse Foundationの配布一覧によると、4.1.2のTCKファイルは2026年3月21日に公開されています（出典: Eclipse Foundation Jakarta Faces TCK配布一覧、2026年）。

この更新を踏まえると、JSF系の技術を一律に停止済みとみなす必要はありません。対応する世代を選んで判断します。

既存環境に、JavaServer Faces 2.xやJava EE 8系の`javax.faces`が残っていないかを見極めます。

Jakarta EE 9以降の`jakarta.faces`へ移行済みかどうかも、確かめておきます。

• UI部品：Mojarra、MyFaces、PrimeFacesなどの利用状況を見ます。
• 実行基盤：WebLogic、JBoss EAP、WildFly、Payaraなどの候補を一覧にします。
• 選定材料：Javaの版、再利用資産、保守担当者、画面変更頻度です。

アップデートできないライブラリを洗い出したうえで、将来のAPI分離の方針も含めて選ぶのが実務的です。

JSFが向く業務と別方式を検討する業務

JSFは、入力項目や権限、業務ルールが多い業務システムと相性がよいです。たとえば、販売・在庫・購買などが対象業務になります。

• 社内業務：申請・承認、顧客・契約管理などの業務。
• 共通画面：社内ポータルや管理者向けの画面。
• 既存資産：Javaの画面とバックエンドを、同じ体制で長く運用しやすい構成です。

既存の認証やDBを引き継げる場合は、全面刷新よりも改修のほうが費用対効果が高くなる可能性があります。

Jakarta EE公式チュートリアルのDuke’s Bookstoreも参考になります。

Faces、CDI、Enterprise Beans、Persistenceを組み合わせた例です（出典: Jakarta EE公式チュートリアル、2026年参照）。

一般消費者向けのスマートフォン画面や、リアルタイム性の高いダッシュボードでは、別方式も検討します。

• 独立更新：画面を頻繁に更新するなら、React・Vue・Angularが候補です。
• API分離：Java REST APIとフロントエンドを分けて作る方式。

判断では、利用者やサーバー側での状態管理を見ます。加えて、SEOや公開APIの要否、内製チームの技術も材料になります。そのうえで、選択肢を比べてJSFを残す判断も、要件整理の成果です。

JSFのシステム開発の進め方と6フェーズ

JSF開発では、業務上の目的と既存資産を整理してから技術構成を決めます。画面より先に業務と資産を押さえる順序が安全です。

6つのフェーズは、要件整理、選定、設計開発、テスト、稼働、定着の順に進みます。

各フェーズに成果物と判断基準を置くと、手戻りを抑えられます。

フェーズ1：業務と現行資産の要件整理

業務課題は、「誰が、いつ、何を入力し、どの状態を経て、何を出力するか」の形に分けて整理します。

• 業務と画面：業務フロー、画面一覧、権限マトリクス、データ項目。
• 処理と連携：承認条件、帳票、バッチ、外部連携を洗い出します。
• 現行環境：JSF版、`javax`か`jakarta`か、Java、サーバー、DB、認証を残しておきます。
• 運用状況：部品、障害履歴、改修頻度、ピーク時の利用者数を押さえます。

要件ごとに「必須・できれば・今回は対象外」を区別し、受入条件を定めます。

検索性能は、「通常時3秒以内、月末ピーク時5秒以内、同時利用者100人で検索結果を表示」のように書けます。

認証・認可、監査ログ、バックアップは、非機能要件に含めます。

復旧目標や個人情報も、非機能要件の中で扱います。

要件定義に全体工期の約25%を配分する考え方もあります。

短縮しすぎると、後工程で仕様が増えます（出典: リサーチノート内の業務システム相場整理、2026年）。

JSFを残すか移行するかの方式選定

要件を踏まえて、現行の維持か移行かを比べます。移行の選択肢は、`javax`から`jakarta`への移行、API分離、Reactなどへの画面単位の移行です。

• 費用と資産：開発費、既存コードの再利用率、移行対象部品を比べます。
• 運用と将来：保守要員、クラウドへの適合性、画面変更の頻度です。
• 制約：停止可能な時間と3〜5年の運用費を、比較表に入れます。

新規開発では、Jakarta Facesの世代とJava 17または21を確認します。

発注側は、Mojarra・MyFaces、PrimeFaces、サーバーのサポート期間も見ておきます。

既存環境では、変換ツールに任せきりにせず、コンパイルや設定、依存部品を調べます。

認証や画面状態など、ほかの要素も対象になります。

PoCでは、入力画面と複雑な一覧を作ります。SSOと外部API連携も、同じPoCで試します。そのうえで、性能・権限・運用を見ます。

共通ルールを先に固める設計・開発

設計では、画面遷移図、項目定義、データモデルを定めます。さらに、権限やエラー処理、APIなど、ほかの領域も決めておきます。

• 責務：画面状態、業務ロジック、データアクセスを切り分けます。
• 共通化：命名規則、例外処理、UI部品、Ajax更新単位の取り決め。
• 状態管理：セッションに置く情報と二重送信の防止方法を、設計書に残します。

開発では、代表画面を先にレビューします。対象には、複雑な検索や明細追加などの画面を含めます。

画面の見た目に加えて、入力検証やトランザクションを確かめます。

監査ログと障害時の復旧も、対象です。

ソースコード、設計書、テストコードなどの引き渡し時期を、早めに合意します。

CI/CDやIaC、ライセンス一覧なども、引き渡しの対象です。

業務・性能・安全性のテスト

テストは、単体から受入までの順に進めます。移行リハーサルや性能試験など、ほかの検証も計画に入れます。

• JSF画面：変換・検証、画面遷移、Ajax更新、セッション切れの動きを見ます。
• 操作と権限：戻る操作や二重送信、権限のないURLへの直接アクセス。
• 外部処理：APIやバッチのタイムアウト、重複送信、相手側の停止が対象です。
• 再実行：途中で失敗した処理からの復旧も検証します。

受入項目には、入力検証、CSRF、XSSといった安全面を含めます。

セッションや権限、監査ログなどの管理も、受入の対象です。

OWASP ASVS 5.0.0は、2025年5月版です（出典: OWASP Application Security Verification Standard 5.0.0、2025年）。

安全なアプリケーションを定義・検証するための要件一覧で、アーキテクトや開発者、テスターが使います。

該当する管理策は、RFPとテスト計画に結び付けておくと、検査の抜けを減らせます。

フェーズ5：稼働での移行と切り戻しの準備

本番データの移行では、手順と時間、件数照合を定めます。文字コードや欠損値、マスタ初期値などの扱いも、事前に決めておきます。

• 切替方式：一度の移行、並行稼働、段階的な利用拡大から選びます。
• 検証：方式ごとの停止時間と確認方法の決定。
• リハーサル：本番に近いデータ量で、複数回行います。

手順書の作成者以外の人でも移行を実行できるよう、準備しておきます。

切り戻しの際に備えて、重大障害の定義と判断者と時刻を決めておきます。

切り戻しの準備には、旧環境とのデータ差分と、利用者への告知も含めます。

クラウドでは、DNSやロードバランサーなどの切替を一覧にします。

セッションやファイル保管、監視通知の切替も含めます。

稼働日の体制には、開発会社や業務責任者、情シスを含めます。セキュリティ担当と問い合わせ窓口も、体制に入れます。

稼働の初週の障害対応を見越して、連絡網を準備しておきます。

利用状況と保守体制の改善による定着

稼働後は、研修だけで終わらせず、月次で利用の様子を追います。確認の対象は、利用率や入力漏れ、差し戻し、障害件数などです。

そのうえで、利用部門のつまずきを把握し、マニュアルや画面メッセージなどを改善します。

• 管理者業務：ユーザー登録や権限変更、ログ確認の引き継ぎ。
• 運用確認：バックアップの確認と、障害の一次切り分けを共有します。
• 保守契約：問い合わせ対応時間、障害の重要度、復旧目標、定期パッチ、脆弱性情報の確認を定めます。
• 更新計画：追加改修の見積方法と、3〜5年後の更新担当者。

特定の担当者だけが運用する状態は避けます。

OSSを使っても、保守が無料になるわけではありません。互換性の検証や古いライブラリの延命には、費用がかかります。

Java、サーバー、UI部品の更新検証と、引き渡す資産を決めておくと、長期の定着につながります。

JSFのシステム開発にかかる費用相場とコストの内訳

JSFだけの公表価格表は、ほとんど見当たりません。そのため、2026年版の国内相場と業務Webシステムの工数による推定を目安にします。なお、これはJSF固有の市場統計ではなく、画面数、業務ルール、移行、連携、非機能要件で変わる目安です。

SIA株式会社の2026年版では、規模別に、小規模が100万〜300万円、中規模が500万〜1,000万円、大規模が1,000万円〜数千万円以上です。この金額は、画面数や業務ルールなどで変わる目安です。

同じ資料の人月単価は、60万〜200万円以上の幅です（出典: SIA株式会社「システム開発の費用・相場 2026年版」、2026年7月）。

規模別の費用と期間の目安

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億円以上の可能性。

この目安は、要件整理からテスト、移行までに加え、クラウド構築や教育、予備費も含めた想定です。画面が少なくても、複雑な承認やAPI連携、帳票、データ品質の不良、厳しい監査要件があれば、費用は上がります。

見積もりを比べるときは、金額に加えて、含む工程と前提条件が同じかを確かめます。

初期費用以外に発生するコスト

初期開発以外にも、費用は発生します。たとえば、クラウドやDB、商用サポート、監視などが挙げられます。

• 環境費：証明書、端末、クラウド、データベースの費用を見込みます。
• 運用費：監視、バックアップ、ログ保管、保守運用を含む費用。
• 支援費：脆弱性診断と教育、商用サポートの費用です。

保守運用費の目安は、初期費用の年15〜25%程度です。ただし、対象時間や監視、障害対応などで変わります。

商用サポートを使わない場合でも、社内の人件費と検証環境は予算に入れておく必要があります。

初期費用が1,500万円なら、保守の目安は年225万〜375万円程度です。これは相場からの試算で、契約額を示すものではありません。

3年のTCOでは、初期費用から将来の更新まで、費用を並べて比べます。運用の引き継ぎやセキュリティ検証が別料金の場合、初期見積もりが安くても総額は変わります。

JSFのシステム開発で見積もりを取る際のポイント

JSF案件の見積もりを比べるには、画面の複雑さや業務ルール、連携、移行などの条件をそろえます。画面数は、その一部として見ます。

RFPや要件メモには、業務目的と対象部門、現行環境を書きます。必須機能や希望時期、予算の考え方、受入条件も記します。

見積依頼前に整理する項目

現行システムは、JSFやJavaのバージョンを記載します。あわせて、サーバー、DB、認証の情報も書いておきます。画面は、機能別に分類します。

• 画面情報：登録、検索、一覧、承認、帳票、管理と項目数を示します。
• 利用条件：明細行や権限、外部連携、ピーク時の利用者数を添えます。
• 移行情報：対象テーブル、件数、保持期間、クレンジング、照合方法の整理。
• 未確定事項：「提案してほしい」と記して、確定事項とは分けます。

見積書は、行ごとに見ます。要件定義や画面・API・バッチ・帳票数、共通部品などが、それぞれ分かれて書かれているかを確かめます。

移行リハーサルや教育、マニュアル、稼働支援、保守なども、見積書に項目として載っているかを見ます。「開発一式」とだけ書かれていると、対象外かどうかが分かりません。

発注側は、成果物や検収条件、追加変更の単価、仕様変更の承認手順も確かめておきます。

開発会社を比較する質問

開発会社には、JSFの版や、Mojarra・MyFaces、PrimeFacesの経験を尋ねます。移行と運用の経験も、あわせて聞きます。

• 技術経験：`javax`から`jakarta`への移行、Java 17・21、サーバー更新の経験。
• 業務対応：SSO、権限、監査ログ、データ移行、性能試験をどう扱うか。
• 運用体制：クラウドの経験があり、提案から保守まで同じ担当者が関わるか。

公開実績の例として、アクロホールディングスには、Java、Linux、DB2、JSFを使ったカード会社向けの基盤があります（出典: アクロホールディングス開発実績、2023年12月掲載）。

これは公開された事例で、2026年の新規導入実績と同じものとは扱えません。そのため、対象の版と現在の保守担当を尋ねます。

障害時の体制や、ソースコードとIaCの引き渡し、担当交代時の引き継ぎ方法も、確かめておきます。

見積書と合わせて確認する契約とリスク分担

要件が未確定のまま全体を固定価格にすると、仕様変更が争点になりやすいです。そのため、工程ごとに契約と検収条件を話し合います。

• 要件整理：準委任や段階契約が候補になります。
• 開発：範囲が確定してからの請負。
• 追加改修：別見積もりと、変更管理の条件を定めます。

IPAのモデル取引・契約書には、第二版やアジャイル版があります（出典: IPA、2025年6月サイト更新）。成果物や協力義務、知的財産、再委託、損害賠償、終了時の引き継ぎを考える際の参考になります。

発注側は、依存部品の脆弱性、Javaやサーバーのサポート終了、クラウド料金、移行品質、担当者の退職に備えておきます。

契約には、脆弱性の確認者やパッチ検証環境、緊急対応費を記載します。コードの権利と、設計書の更新義務も、契約に入れます。

想定外の事態が起きたときも意思決定できる仕組みがあるかを、評価の対象にします。

よくある質問（FAQ）

JSFのシステム開発では、技術の古さ、開発期間、既存資産の扱いについて相談を受けることが多くあります。発注前に判断しやすいよう、結論を先に示し、条件で変わる点を補います。

JSFは古い技術なので新規開発に使わない方がよいですか？

Java・Jakarta EEの人材と長期の保守体制があり、対応する世代を選べるなら、JSFも候補になります。一律に避ける必要はありません。

業務画面の複雑さも判断材料になります。公開画面を独立して更新するなら、ReactなどとJava APIを分ける方式も比べます。

PoCで性能と保守性を確かめてから、決めます。

`javax`のJSFシステムを`jakarta`へ移行できますか？

移行できる可能性はありますが、名前空間を置き換えるだけで終わるとは限りません。

• 互換性：Java版、依存部品、設定、Mojarra・MyFaces、PrimeFacesとの相性。
• 基盤と画面：サーバーや認証、画面状態、テスト資産を調べます。
• 段階移行：大規模なら、API化や認証の共通化を進めたうえで、変更頻度の高い画面から移します。

代表画面でコンパイルから受入まで検証すると、全面移行のリスクを抑えやすくなります。

JSFのシステム開発費はどのように予算化すればよいですか？

画面数に加えて、業務ルールや権限、連携、移行、非機能要件を整理します。そのうえで、業務システムの規模別レンジを起点に予算を組みます。

• 小規模：目安は400万〜1,200万円程度。
• 中規模：目安は1,500万〜5,000万円程度。
• 大規模：目安は5,000万円〜2億円以上。
• 価格性質：JSF固有の公表価格はない点。
• 総額：クラウド、サポート、保守、教育、脆弱性対応、将来の更新を含め、3〜5年のTCOで判断します。

JSFに詳しい開発会社は何を基準に選べばよいですか？

JSFの経験に加えて、業務理解やJava・Jakarta EEの世代、`javax`の移行経験、UI部品、サーバー運用を見ます。

• 対応範囲：クラウド、セキュリティ、データ移行、保守まで、どこまで受けるか。
• 提案の裏付け：対象版、担当者、成果物、テスト方法の比較。
• 運用条件：障害時のSLAと、引き渡し範囲。

公開実績が少ない場合は、PoCと技術面談を選定に加えます。

まとめ：JSFのシステム開発を6フェーズで段階的に進める方法

JSF開発では、技術を選ぶ前に、業務・データ・非機能要件・既存資産を整理します。その結果をもとに、方式を選びます。

各フェーズの成果物と、次へ進む条件を定めておくと、仕様追加や移行トラブルを抑えられます。

6フェーズで確認する開発の要点

要件整理では目的と受入条件、選定では既存資産と保守、設計開発では共通ルールと成果物を確認します。

• テスト：業務・性能・安全性の検証。
• 稼働：移行と切り戻しを準備します。
• 定着：利用状況と保守体制の見直し。

各工程の完了条件と、次へ進む判断者を決めておきます。

見積もり前に残すチェック項目

費用は、画面数や業務ルール、承認、連携などで変わります。相場は、予算を考える起点になります。

• 見積比較：同じRFPをもとに、複数社の工程別費用や3〜5年TCO、契約リスク、資産の引き渡しを比べます。
• 方式判断：既存資産の活用や段階刷新を、PoCと業務への影響を踏まえて決めます。
• 事前資料：JSF・Java・サーバー・DB・認証・UI部品の一覧と、代表的な業務フロー。
• 要件すり合わせ：保守世代、移行範囲、利用者数、受入条件について、開発会社と話し合います。

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

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