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

JSFのシステム開発は、既存のJava資産と業務ルールを活かしながら、画面・データ・認証・運用を一体で設計する進め方が重要です。新規開発ではJakarta Facesの世代、既存システムでは`javax.*`と`jakarta.*`の互換性を最初に確認し、要件整理から定着までを段階的に進めることが失敗を防ぐ基本です。

本記事では、JSFのシステムを作る、改修する、クラウドへ移行する場合の流れを、要件整理・選定・設計開発・テスト・稼働・定着の6フェーズに分けて解説します。費用相場、見積書の読み方、発注前のチェック項目、Reactなどへの段階移行を含め、社内で意思決定や開発会社との打ち合わせに使える基準を具体的に整理します。

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

JSFのシステムとは何ですか？全体像を理解します

JSFはJavaServer Facesの略称で、現在の正式な仕様名はJakarta Facesです。業務Web画面を作るサーバーサイドのUIフレームワークであり、JSF単体を導入すれば業務システムが完成するわけではありません。画面をJSF、業務処理をCDIやEnterprise Beans、データ永続化をJPA、入力検証をBean Validation、データベースをRDBというように組み合わせて、ひとつの業務システムに仕上げます。

JSFの画面はFaceletsのテンプレートとUIコンポーネントで構成されます。入力フォーム、検索条件、一覧表、ダイアログ、画面遷移、Ajaxによる部分更新などを再利用しやすく、入力値の変換・検証・エラーメッセージも画面のライフサイクルに組み込めます。入力を受け取って終わりではなく、入力値を適用し、検証し、モデルへ反映し、業務メソッドを呼び出してHTMLを返す流れを設計できる点が、入力項目と業務ルールの多い社内システムに向く理由です。

ただし、画面の状態をサーバー側で管理する設計では、セッションサイズ、タイムアウト、同時利用者数、ロードバランサー配下でのセッションレプリケーションを考える必要があります。クラウド化する場合は、ファイルアップロードの保存先、複数台構成でのセッション共有、障害時の再送や二重登録もPoCで確認します。画面仕様だけを見てクラウドへ移すと、開発後半で構成を変更する事態になりやすいです。

新規開発なら、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`へ移行済みなのかを棚卸しします。MojarraとMyFaces、PrimeFacesなどのUI部品、WebLogic・JBoss EAP・WildFly・Payaraなどの実行基盤、Javaのバージョンを一覧にし、アップデートできないライブラリを先に洗い出します。技術名の新旧ではなく、既存資産の再利用価値、保守担当者の確保、画面の変更頻度、将来のAPI分離方針で選ぶことが実務的です。

JSFは、販売・在庫・購買、申請・承認、顧客・契約管理、社内ポータル、管理者向け画面のように、入力項目や権限、業務ルールが多いシステムと相性がよいです。Javaのバックエンドと画面を同じ開発体制で長期運用でき、既存の認証やデータベースを引き継げる場合は、全面刷新よりも改修の費用対効果が高くなる可能性があります。公式チュートリアルのDuke’s Bookstoreでも、Faces、CDI、Enterprise Beans、Persistenceを組み合わせた構成が示されています（出典: Jakarta EE公式チュートリアル、2026年参照）。

一方、一般消費者向けスマートフォン画面、リアルタイム性の高いダッシュボード、フロントエンドを独立チームで頻繁に更新するサービスでは、React・Vue・AngularとJava REST APIを分離する方式が適する場合もあります。JSFを採用する前に、利用者が社内中心か、画面の状態をサーバーで管理する必要があるか、SEOや公開APIが必要か、将来の内製チームがどの技術を扱えるかを確認します。選択肢を比較してJSFを残す判断そのものが、要件整理の成果になります。

JSFのシステム開発の進め方を6フェーズで解説します

JSF開発は、画面を先に作り始めるのではなく、業務上の目的と既存資産を整理してから、技術構成を決める順番が安全です。ここでは、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズを基本の流れとします。各フェーズで成果物と判断基準を置くと、次工程へ進んだ後の手戻りを小さくできます。

最初に、システムで解決したい業務課題を「誰が、いつ、何を入力し、どの状態を経て、何を出力するか」に分解します。画面一覧だけでなく、業務フロー、権限マトリクス、データ項目、承認条件、帳票、バッチ、外部連携、ピーク時の利用者数を整理します。現行JSFがある場合は、バージョン、`javax`または`jakarta`、Java、アプリケーションサーバー、DB、認証、コンポーネントライブラリ、障害履歴、改修頻度も棚卸しします。

チェックの基準は、要件ごとに「必須・できれば・今回は対象外」を区別できているかです。たとえば「検索を高速にする」ではなく、「通常時3秒以内、月末ピーク時5秒以内、同時利用者100人で検索結果を表示する」のように受入条件へ落とします。認証・認可、監査ログ、バックアップ、復旧目標、個人情報の取扱いも非機能要件に含めます。要件定義に全体工期の約25%を配分する考え方もあり、ここを短縮しすぎると後工程の仕様追加につながります（出典: リサーチノート内の業務システム相場整理、2026年）。

要件が見えたら、JSFを現行維持する、`javax`から`jakarta`へ移行する、JSF画面を残してAPIや周辺機能を分離する、画面単位でReactなどへ段階移行する、という選択肢を比較します。比較表には、開発費だけでなく、既存コードの再利用率、移行対象ライブラリ、将来の保守要員、クラウド適合性、画面変更の頻度、停止できる時間、3〜5年の運用費を含めます。

新規開発の選定では、Jakarta Facesの世代、Java 17または21、Mojarra・MyFaces、PrimeFacesなどの部品、アプリケーションサーバーのサポート期間を一式で確認します。既存システムの選定では、変換ツールだけに頼らず、コンパイル、設定ファイル、依存ライブラリ、認証、画面状態、帳票、バッチを移行対象として洗い出します。代表的な入力画面、複雑な一覧、SSO、外部API連携の4点を小さなPoCで作り、性能・権限・運用を確認できれば、方式選定の精度が上がります。

設計では、画面遷移図、画面項目定義、データモデル、権限設計、エラー処理、API仕様、バッチ、帳票、ログ設計を作成します。JSFの画面ごとにBeanを自由に増やすのではなく、画面状態の責務、業務ロジックの責務、データアクセスの責務を分け、命名規則と例外処理を共通化します。再利用する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とテスト計画に紐づけると、検査の抜けを減らせます。

稼働前には、本番データの移行手順、所要時間、件数照合、文字コード、欠損値、権限、マスタの初期値を確認します。旧システムを止めて一度だけ移行するのか、並行稼働するのか、段階的に利用部門を広げるのかを決め、各方式の業務停止時間と検証方法を比較します。移行リハーサルは本番に近いデータ量で複数回行い、手順書の作成者以外でも実行できる状態にします。

切り戻し条件は、重大障害の定義、判断者、判断時刻、旧システムへ戻した場合のデータ差分、利用者への告知方法まで具体化します。クラウドの場合は、DNSやロードバランサー、セッション、ファイル保管、監視通知の切替を一覧化します。稼働日は開発会社だけでなく、業務責任者、情シス、セキュリティ担当、問い合わせ窓口を含む体制を組み、初週の障害対応を見越した連絡網を準備します。

稼働後の定着では、操作研修を一度実施して終わりにせず、利用率、入力漏れ、差し戻し、問い合わせ件数、処理時間、障害件数を月次で確認します。利用部門ごとのつまずきを把握し、マニュアル、画面メッセージ、権限、業務フローを改善します。管理者には、ユーザー登録、権限変更、ログ確認、バックアップ確認、障害一次切り分けを引き継ぎ、特定の担当者しか運用できない状態を避けます。

保守契約では、問い合わせ対応時間、障害の重要度、復旧目標、定期パッチ、脆弱性情報の確認、Java・アプリケーションサーバー・UI部品のアップデート検証、追加改修の見積方法を決めます。OSSを利用しても保守が無料になるわけではなく、互換性検証や古いライブラリの延命に費用が発生します。3〜5年後に誰が更新し、どの資産を引き渡すかまで決めることが、JSFシステムの長期定着につながります。

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億円以上になる可能性があります。

このレンジは、JSFの画面開発だけではなく、要件整理、共通部品、業務ロジック、テスト、移行、クラウド構築、教育、予備費を含めて考える場合の目安です。画面数が少なくても、複雑な承認条件、外部API、帳票、既存データの品質不良、厳しい監査要件があれば費用は上がります。見積もりを比較するときは金額の大小よりも、含まれる工程と前提条件が同じかを確認します。

初期開発費のほかに、クラウド利用料、データベース、アプリケーションサーバーの商用サポート、監視、バックアップ、ログ保管、脆弱性診断、証明書、端末、教育、保守運用が発生します。初期費用に対する保守運用費は年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に強い」という説明だけで判断せず、同じ構成の担当者が提案・設計・保守に関わるかを確認します。

公開事例として、アクロホールディングスにはクレジットカード会社向けアプリサービス基盤開発が掲載され、技術欄にJava、Linux、DB2、JSFが記載されています（出典: アクロホールディングス開発実績、2023年12月掲載）。ただし、これは公開されている直接的な事例であり、2026年の新規導入実績と同一視しないことが大切です。提案会社には、対象バージョン、現在の保守担当、障害時の体制、ソースコードとIaCの引き渡し、担当者交代時の引き継ぎ方法を質問します。

要件が固まっていない段階で開発全体を固定価格にすると、仕様変更の扱いが争点になりやすいです。要件整理は準委任や段階契約、開発は確定した範囲を請負、追加改修は別見積もりというように、工程ごとに適した契約と検収条件を話し合います。IPAの「情報システム・モデル取引・契約書」には第二版やアジャイル版が公開されているため、成果物、協力義務、変更管理、知的財産、再委託、損害賠償、終了時の引き継ぎを検討する際の参考になります（出典: IPA、2025年6月サイト更新）。

特に注意したいのは、依存ライブラリの脆弱性、Javaやサーバーのサポート終了、クラウド料金の増加、データ移行の品質、担当者退職です。契約書に、脆弱性情報を誰が確認するか、パッチをどの環境で検証するか、緊急対応の料金、ソースコードの権利と利用範囲、設計書の更新義務を記載します。見積もりの安さだけでなく、想定外が起きたときに意思決定できる仕組みがあるかを評価します。

よくある質問（FAQ）

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

一律に使わないと判断する必要はありません。既存のJava・Jakarta EE人材、業務画面の複雑さ、長期保守体制があり、Jakarta Faces 4.1など対応世代を選べるなら候補になります。一方、公開サービスのフロントエンドを独立更新したい場合は、ReactなどとJava APIを分離する方式も比較し、PoCで性能と保守性を確認してから決めます。

移行できる可能性はありますが、名前空間の置換だけで完了するとは限りません。Javaのバージョン、依存ライブラリ、設定ファイル、Mojarra・MyFacesやPrimeFaces、アプリケーションサーバー、認証、画面状態、テスト資産を確認し、代表画面でコンパイルから受入まで検証します。大規模システムでは、API化や認証共通化を先に行い、変更頻度の高い画面から段階移行する方が、全面移行のリスクを抑えやすいです。

まず画面数だけでなく、業務ルール、権限、連携、データ移行、非機能要件を整理し、類似する業務システムの規模別レンジを予算の起点にします。目安は小規模400万〜1,200万円程度、中規模1,500万〜5,000万円程度、大規模5,000万円〜2億円以上ですが、JSF固有の公表価格ではありません。初期費用に加えて、クラウド、サポート、保守、教育、脆弱性対応、将来の更新を含む3〜5年のTCOで判断します。

JSFの利用経験だけでなく、業務理解、Java・Jakarta EEの対応世代、`javax`から`jakarta`への移行、UI部品、アプリケーションサーバー、クラウド、セキュリティ、データ移行、保守まで確認します。提案書の実績を鵜呑みにせず、対象バージョン、担当者、成果物、テスト方法、障害時のSLA、引き渡し範囲を質問票で比較します。公開実績が少ない場合は、PoCと技術面談を選定プロセスに入れると判断しやすいです。

まとめ：JSFのシステムは6フェーズで段階的に進めます

JSFのシステム開発は、技術選定から始めるのではなく、要件整理で業務・データ・非機能・現行資産を可視化し、その結果をもとに方式を選ぶことが基本です。要件整理、選定、設計開発、テスト、稼働、定着の各フェーズで、成果物と次へ進む条件を決めると、仕様追加や移行トラブルを抑えられます。

要件整理では目的と受入条件、選定では既存資産と将来の保守、設計開発では共通ルールと成果物、テストでは業務・性能・安全性、稼働では移行と切り戻し、定着では利用状況と保守体制を確認します。各工程の完了条件を曖昧にせず、次工程へ進む判断者を決めることが重要です。

費用はJSFの技術名だけでは決まらず、画面数、業務ルール、承認、連携、移行、セキュリティ、運用体制で変わります。相場レンジは予算の起点として使い、複数社に同じRFPを渡し、工程別の見積もり、3〜5年のTCO、契約上のリスク分担、ソースコードと運用資産の引き渡しまで比較します。既存資産を活かすか、API化や画面単位の段階刷新を行うかも、PoCと業務影響を踏まえて判断します。

まずは現行のJSF・Java・サーバー・DB・認証・UI部品の一覧と、代表的な業務フローをまとめます。その資料をもとに、必要な保守世代、移行範囲、利用者数、受入条件を開発会社とすり合わせることが、長く使えるシステムへの第一歩です。

▼全体ガイドの記事
・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を創業。