Java/Spring Boot基幹システムの外注方法｜レガシーJava人材の探し方

Java／Spring Boot で構築した基幹システムを、もう一度動かし直そうとしたとき、多くの中堅企業がまず直面するのは「技術の判断」ではなく「発注できる相手をどう見つけるか」という問題です。10〜20 年前に Struts 1.x や古い Spring Framework で組み上げた業務システムは、いまもなお受発注・在庫・会計連携・顧客管理を回し続けている一方、社内で保守できる Java エンジニアは静かに減っていきます。50 代のベテランが引き継ぎを終える前に退職すれば、コード資産は事実上のブラックボックスになります。

この状況で「外注前提の刷新」を検討しても、検索してヒットするのは「Java／Spring Boot 開発会社 6 選」といった会社紹介型の記事ばかりで、自社が抱える固有事情、たとえば「Struts 資産をどこまで捨てるか」「Java 8 を 17／21 のどこまで一気に上げるか」「大手 SIer の数億円見積は本当に必要か」に踏み込んだ判断軸はなかなか得られません。しかも Java エンジニアの需給ギャップは全国的に深刻で、外注先を探しても「その会社自身も Java 人材を集めきれていない」というリスクが現実にあります。

本記事は、Java／Spring Boot 基幹システムの外注を検討し始めた情シス部門・システム企画部門の担当者を想定し、「どのベンダーが良いか」ではなく「自社の現行資産と目的から、どう外注設計するか」の判断フローを整理します。具体的には、外注前に社内で確定すべき前提の整理、Struts／旧 Spring を延命するか Spring Boot へ移行するかフル刷新するかの三択、大手 SIer・中堅受託・準委任型フリーランス・ニアショア・オフショアという 5 つの調達チャネルの使い分け、そして相見積りで単価と金額に惑わされずに比較するための観点までを、発注者の目線で解きほぐしていきます。

読み終える頃には、「動き出せない」状態から「動き出す準備が整った」状態に変わっているはずです。RFP 作成と最初の相見積り依頼に、明日から着手できるところまで具体化してください。

Java／Spring Boot 基幹システムの外注が増えている背景

まず、いまなぜ Java／Spring Boot の基幹システムを「外注前提」で検討する企業が急増しているのか、その構造要因を押さえておきます。動き出すのは自社だけではありませんし、外注前提の判断は例外ではなく「標準」になりつつあります。

Java エンジニアの需給ギャップと採用難

IT 人材不足は日本全体の課題です。IPA の調査では、DX を推進する人材が「大幅に不足している／やや不足している」と答えた日本企業の割合は 85.1％に達し、米独と比較しても突出して高い水準にあります（IPA「DX 動向 2025」）。この不足感は特定言語に限らない構造問題ですが、Java の基幹系人材はさらに固有の逼迫があります。

• 20 年前後 Java を扱ってきた 40〜50 代エンジニアが定年前後で退出しつつある
• 若手エンジニアの新規参入が Kotlin／Go／Python／TypeScript へ流れがちで、Struts・古い Spring Framework・JSP を扱える人材の供給が細っている
• Java 案件そのものは金融・製造・公共・保険で高止まりしており、需給ギャップがなかなか埋まらない

つまり、「社内で Java 人材を採用して内製する」戦略は多くの企業で現実味を失いつつあります。外注前提の意思決定に切り替えるのは、経営判断としてむしろ合理的です。

Spring Framework／Spring Boot／Java LTS のサポート期限が刷新を後押ししている

もう一つ、無視できないのが OSS 側のサポート期限です。Spring Boot 2.7 系は 2023 年 6 月末に OSS EOL を迎えており、その後は商用サポートのみで維持されています（Spring 公式ブログ）。Spring Boot 3.2 は 2024 年末、3.3 は 2025 年 6 月末に順次 OSS EOL となり、2026 年 7 月時点では 3.5 系までがすでに OSS EOL、最新は 4.1 系という状況です（Spring 公式サポートポリシー）。

Java 本体側も、Oracle Java SE Support Roadmap を確認すると、Java 17 の無償プレミア期間は 2026 年 9 月に終了し、以降は延長サポートかバージョン移行が必要です。Java 21 は少なくとも 8 年、Java 25 も 2028 年まで無償 NFTC が続きます。

つまり、「今のバージョンで運用し続ける」選択肢は年々コストが跳ね上がる構造になっています。バージョンアップの意思決定を先延ばしにするほど、外注時の見積も高くなる傾向がある点は、社内でも早めに共有しておく価値があります。

基幹系を刷新できない「4 つのブラックボックス」

Java 基幹系の刷新が難しい理由は、単に技術が古いからではありません。むしろ「捨てられない周辺資産」の存在が意思決定を止めます。整理すると、次の 4 つがブラックボックス化しがちです。

• コード資産: Struts／JSP／Java 8 で書かれた業務ロジック。ドキュメントが失われ、担当者の退職で挙動の理由が説明できない
• データ資産: Oracle のストアドプロシージャ、複雑なテーブル関連、独自の履歴管理設計
• 帳票・出力資産: JasperReports、OPRO、Excel／CSV マクロ、法定帳票のレイアウト
• 運用ノウハウ: バッチのジョブスケジューラ、監視・障害対応の暗黙知、社内での連絡フロー

これらは新規開発時に「一緒に刷新する」対象となり、外注ベンダーが対応できるかどうかで、案件そのものの成否が変わります。外注先選定の際は「Java／Spring Boot ができる」だけでなく、「この 4 資産まで踏み込めるか」を必ず確認したい観点です。

内製が限界に達し、外注前提での意思決定が主流になっている

以上を踏まえると、「Java 経験者を採用して 2〜3 年かけて内製する」プランは、多くの中堅企業にとって現実的ではなくなっています。代わりに、「一次判断は自社で整理し、開発は外注、保守はハイブリッド」という枠組みが主流になっています。次の章からは、その枠組みの中で発注者が押さえるべき判断ポイントを順に見ていきます。

外注前に発注者側で整理すべき 5 つの前提

外注先の選定に入る前に、社内で確定させておくべき前提が 5 つあります。これらが揺れていると、どんなに優秀なベンダーに相談しても提案が「刺さらない」ものになりがちです。ここは RFP（提案依頼書）の前段の下準備と考えてください。

目的・KPI の定義

まず、今回の刷新（あるいは追加開発）で最優先に置く目的を 1〜2 つに絞ります。よくある目的は次のいずれかです。

• コスト削減: 保守費・ライセンス費・人件費の削減
• 業務効率: 処理速度、業務のペーパーレス化、モバイル対応
• 拡張性: API 化、マイクロサービス化、外部システム連携の容易化
• 法対応・セキュリティ: インボイス・電帳法対応、脆弱性対応、監査ログの整備
• 人材リスク回避: 属人化解消、若手人材が扱える技術構成への切り替え

「全部大事」ではベンダーの提案がぼやけます。優先順位を明示することで、外注先の提案も磨かれます。

現行資産の棚卸し

外注先が最初に知りたい情報は、「今、何が動いているか」です。以下の粒度で棚卸しをしておくと、初回相談から相見積りまでのスピードが桁違いに上がります。

• 言語・フレームワークのバージョン: Java 8 / 11 / 17、Struts 1.x / 2.x、Spring Framework 3.x / 4.x / 5.x、Spring Boot 1.5 / 2.x など
• アプリケーションサーバー: WebSphere、WebLogic、JBoss、Tomcat のバージョン
• DB: Oracle、PostgreSQL、SQL Server のバージョンとストアド／関数の本数
• 帳票: JasperReports、OPRO、Excel マクロなど、何本が稼働しているか
• 連携: 他システムとの API・ファイル連携数と方式（SOAP・REST・ファイル転送）
• バッチ: ジョブスケジューラの種類、夜間バッチの本数と処理時間帯

古い設計書があるなら添付し、なければ「口頭で伝えられる範囲」を箇条書きにまとめるだけでも構いません。

スコープの切り分け

「全部刷新」と「一部だけ手を入れる」では、外注設計がまったく違います。次の 4 パターンから、自社の現実に合うものを選んでおきましょう。

• 全刷新: 現行資産の一部（データ・帳票のみ）を残し、アプリケーションはゼロから作り直す
• 段階移行: モジュール単位で Spring Boot 化・クラウド化を進め、旧システムと並行運用する
• 機能追加: 現行の基盤を維持し、新規要件（帳票追加、API 連携、モバイル対応）のみを追加する
• 保守継続: 積極的な刷新はせず、Java／Spring のバージョン更新・脆弱性対応を中心に延命する

段階移行は柔軟性が高い反面、並行運用期間のコストが積み上がります。全刷新は初期投資が大きい代わりに、長期の運用費が下がりやすい傾向があります。

発注者側の体制と役割

外注前提でも、発注者側にゼロ工数で済むプロジェクトはありません。最低限、次の 3 役は社内で確保する必要があります。

• プロジェクトオーナー: 経営層直下、意思決定の最終責任
• 業務側代表: 現行業務の詳細を語れる担当者。要件定義段階の主役
• 情シス: 技術的な整合性・セキュリティ・既存システム連携の窓口

特に業務側代表が不在のまま情シスだけで進めると、要件が「今動いている機能の再現」で終わってしまい、DX 効果が出にくくなります。

予算・期間の目安と調達方法

最後に、社内での予算感と期限を整理します。細かい金額は、後ほど「費用感の目安と見積り比較の観点」で扱いますが、少なくとも「上限として想定する金額」と「経営が我慢できるプロジェクト期間」は、初回のベンダー相談時までに固めておく方が話が早く進みます。

Struts／旧 Spring 継続か、Spring Boot／クラウドへ刷新するかの判断基準

Java 基幹系の外注設計における最大の分岐点は、「現行資産を延命するか、Spring Boot に移行するか、フル刷新するか」の三択です。ここは本記事の核となる判断ポイントなので、選択肢ごとに条件を整理していきます。

選択肢A: Struts／旧 Spring Framework 継続保守の適用条件

「積極的な刷新はせず、脆弱性対応と最小限の機能追加で延命する」選択肢です。次のような条件に当てはまる企業には、依然として合理的な選択となります。

• 業務の変更頻度が低く、追加要件が年に数件レベル
• システムの残存寿命が 5 年以内で、いずれ別システムに統合される見通し
• 現行の運用ノウハウを持つ社内エンジニアがまだ 2〜3 年は在籍する
• 予算上、大規模刷新のキャッシュアウトが取れない

ただし、Struts 1.x はすでに OSS のセキュリティサポートが打ち切られており、脆弱性対応は自前ないし外注に頼ることになります。Spring Framework も 5.x 系の OSS サポートが 2024 年で終了しており、延命は「商用サポートを買う」あるいは「自社リスクで運用する」いずれかの判断が必要です。延命フェーズを外注する場合は、脆弱性対応の SLA と月次パッチ体制を契約に明記することが重要です。

選択肢B: Spring Boot 3.x／Java 17／21 への移行の判断基準

「現行の業務ロジックはできる限り活かしながら、フレームワークとランタイムを最新化する」選択肢です。次の条件を満たすなら、移行が最有力候補になります。

• 業務ロジックの構造が明確で、大きな業務変更を伴わない
• クラウド化・コンテナ化を含めた運用モダナイズを狙いたい
• 若手エンジニアが扱える技術構成に置き換えて、保守しやすくしたい
• 予算は数千万〜数億円のレンジで確保できる

Spring Boot への移行は、Struts→Spring MVC→Spring Boot のように段階を踏むケースも多く、途中で並行運用期間が発生します。この期間の設計こそが外注先の腕の見せどころで、「移行スクリプト・並行運用の切り替え計画・データ移行の整合性検証」までまとめて提案できるベンダーが望ましいと言えます。

選択肢C: マイクロサービス／クラウドネイティブへのフル刷新

「業務プロセスから見直し、システム構造を根本的に作り替える」選択肢です。次のような場合に選ばれます。

• 現行のモノリスがすでに変更困難な密結合状態にある
• 業務側から「業務プロセス自体を刷新したい」という強い要望がある
• グローバル展開・多角化事業に耐える拡張性を求める
• 経営として数億円規模の投資判断ができ、3 年前後の期間を許容できる

このパターンは「新規開発プロジェクトに近い」ため、外注先も従来の基幹系受託ではなく、クラウドネイティブ経験の豊富なチームやコンサルティング系ファームが候補になります。

Java 周辺資産を捨てるコスト

三択のいずれを選んでも、Java 基幹系には「捨てるかどうかの判断が必要な周辺資産」が付いてきます。代表例は次の 4 つです。

• 帳票エンジン: JasperReports、OPRO 等。Spring Boot 3.x でも継続利用は可能だが、旧バージョンのライセンス・保守契約に注意
• アプリケーションサーバー: WebSphere／WebLogic／JBoss。Spring Boot は内蔵 Tomcat／Jetty／Undertow で動くため、これらを外す判断が必要
• Oracle ストアドプロシージャ: 業務ロジックが DB 側に埋め込まれている場合、アプリ側への引き上げには相応の工数がかかる
• バッチ・ジョブスケジューラ: Job 系フレームワーク（Spring Batch）への統一、あるいは既存スケジューラの継続利用の判断

これらを一度に捨てようとすると刷新コストが跳ね上がるため、「段階移行の中でどう扱うか」を外注先と早期にすり合わせる必要があります。

判断基準を表で整理

三択の判断軸をまとめると、次のようになります。

自社が「B に踏み込むだけの資産棚卸しと予算が取れるか」を、この表で最初に確認してみてください。

Java／Spring Boot 基幹系開発を依頼できる外注先の 5 タイプと Java エンジニアの探し方

前章で技術構成の方向性が見えたら、次はそれを担ってくれる外注先を選びます。「Java 開発会社」と一括りにされがちですが、実際には 5 つのタイプがあり、案件の性質によって向き不向きが大きく異なります。

大手 SIer（数億円規模・全刷新・要件確定型）

日立・NEC・富士通・NTT データ・野村総研といった大手システムインテグレーターは、金融・公共・大規模製造の基幹系案件を長年扱ってきた実績があります。要件確定型のウォーターフォールで大規模プロジェクトを完遂する体制が最大の強みです。

• 強み: 大規模プロジェクトのマネジメント経験、金融・監査対応の実績、Java／Struts／レガシー資産の対応幅
• 弱み: 見積が数億円規模になりやすい、意思決定が遅い、下請け依存が高い場合がある
• 費用感: 全刷新で数億〜十数億円、フェーズ分けても億単位
• 向くフェーズ: 全刷新、業務プロセス再設計を含む大規模改革

中堅受託開発会社（数千万円規模・準委任と請負のハイブリッド）

中堅受託会社は、業種特化（金融、製造、流通など）や技術特化（Java、Spring Boot、クラウド）を打ち出している 100〜500 名規模のベンダーです。ここが「レガシー Java 対応」の主戦場になります。

• 強み: Java／Spring Boot の実装力、業種経験の深さ、大手 SIer より柔軟な提案
• 弱み: 大規模全刷新の完遂経験はまちまち、社内に Struts 経験者がいるかは会社差が大きい
• 費用感: 数千万〜1〜2 億円
• 向くフェーズ: 段階移行、Spring Boot 化、機能追加＋部分刷新

準委任型のフリーランス・小規模チーム（アジャイル・段階移行・スキル特化）

近年、伸びているのが「実力あるフリーランス Java エンジニアと、小規模チームを月単位で確保する」形態です。秋霜堂株式会社が提供する Workee（複業・準委任型のマッチングプラットフォーム）や TechBand（準委任型の開発チーム提供サービス）のようなサービス経由でチームを組成する例も増えています。

• 強み: レガシー Java（Struts、古い Spring）の対応可能な即戦力を柔軟に確保しやすい、段階移行との親和性が高い、開発費が透明
• 弱み: プロジェクトマネジメントは発注者側で担う必要がある、体制の安定性は個人依存が残る
• 費用感: 単価月額 80〜150 万円 × チーム人数 × 期間
• 向くフェーズ: 段階移行、機能追加、Spring Boot 化、内製移管を前提としたフェーズ

「レガシー Java まで扱える即戦力」を短期間で確保する上では、この選択肢の可能性を最初から捨てないことが重要です。フリーランス活用時のリスク管理は、アジャイル外注のリスク管理の観点で整理されているので、あわせて参考にしてください。

ニアショア／オフショアの使い分けとリスク管理

ニアショア（沖縄・北海道・東北・九州などの国内地方拠点）とオフショア（ベトナム、フィリピン、インド、中国などの海外拠点）は、開発コストを圧縮する選択肢です。

• ニアショアの強み: 時差なし、日本語での要件伝達、単価は都内より 20〜30％低い
• ニアショアの弱み: レガシー Java 経験者は地域による、大規模案件のマネジメント経験は限定的
• オフショアの強み: 単価は日本の半分以下、量産型実装フェーズに強い
• オフショアの弱み: 要件伝達の翻訳コスト、時差、レガシー Java 対応は難しい
• 向くフェーズ: 実装フェーズ（要件と設計は国内、実装のみニアショア／オフショア）

基幹系全体を単独で任せるより、「要件・設計は大手 SIer や中堅受託、実装はニアショア／オフショア、レガシー資産対応は準委任型フリーランス」というハイブリッド構成が現実的です。

「Struts など旧世代 Java まで対応できるか」を確認するチェック項目

外注先候補と話す際、次のチェック項目で「本当にレガシー Java まで扱えるか」を確認してください。

• 直近 3 年で Struts 1.x／2.x の保守・移行案件を担当した実績があるか
• Spring Framework 3.x／4.x／5.x から Spring Boot への移行を、要件定義から本番稼働までワンストップで完遂した実績があるか
• Java 8 → 11 / 17 / 21 の移行で、生じたトラブル（モジュール、リフレクション、Nashorn 除去、ライブラリ非互換）の対応事例を語れるか
• Oracle ストアド、JasperReports／OPRO 帳票、WebSphere／WebLogic／JBoss のいずれかで、本番運用の対応実績があるか
• 該当案件で稼働可能なアサイン候補（要員名は不要、経験年数と稼働可能時期）を提示できるか

「Java／Spring Boot ができます」という一般論だけで判断せず、上記の具体的な問いで反応を見ることで、対応能力の実像がかなり見えてきます。

5 タイプの比較表

5 タイプの特徴を、費用・体制・スピード・保守継続性・レガシー Java 対応度で比較すると、次のようになります。

自社の状況に照らして、単独タイプではなく組み合わせで最適解を作るのが、いまの Java 基幹系外注の基本姿勢です。

発注時のチェックポイント（実績・要件定義力・保守体制・契約形態）

外注先候補が絞れたら、次は提案評価の段階です。ここでは、見積提出前後の局面で必ず確認したい 7 項目を挙げます。

Java／Spring Boot の基幹系実績

「Java ができます」ではなく、「業務系（会計・受発注・在庫・生産・顧客管理）」の基幹系実績が問われます。次の粒度で確認してください。

• 業種（自社に近い業種の経験があるか）
• 規模（同等クラスの案件を完遂した数）
• 移行案件（Struts→Spring Boot、Java 8→17／21 の実績）
• 事例の公開範囲（公開できる事例と、口頭ベースでの共有が可能な事例）

要件定義・業務理解のフィット感

Java 基幹系は業務との密結合が深く、要件定義段階で業務側のヒアリング力が試されます。

• 業務側代表との対話能力（技術用語を業務用語に翻訳できるか）
• 業務フロー図・データフロー図・画面遷移図の作成力
• 現行資産を読み取ってのリバースエンジニアリング力

保守・運用フェーズの Java 人員継続性

刷新フェーズが終わっても、Java 基幹系は 10 年前後の運用が続きます。ここで人員が消えると、内製移管もできず外注も切り替えられない、という詰みが起こります。

• 保守フェーズで担当する Java／Spring Boot エンジニアの継続配置方針
• Struts など旧世代 Java の要員継続性
• 若手育成計画と、シニアからの引き継ぎ体制

セキュリティ・監査対応

Java／Spring のセキュリティパッチ対応方針、クラウド化した場合の権限設計、監査ログの整備方針は、契約段階で明示的にすり合わせます。

• Spring／Java の脆弱性情報のウォッチ体制
• クラウド（AWS／Azure／GCP）の権限設計・監査対応の実績
• 個人情報保護法・電子帳簿保存法などの法対応の実務経験

契約形態と業務停止リスクの分担

契約形態の選択は、業務停止リスクの分担方針そのものです。

• 請負契約: 完成責任はベンダー。要件確定型の全刷新に向く
• 準委任契約: 稼働時間ベース。段階移行・要件変動が予測される案件に向く
• ハイブリッド: 要件定義・移行検証は準委任、実装は請負、といった組み合わせ

Java 基幹系はほぼ確実に「途中で要件が変わる」ため、純粋な請負一本ではリスクを吸収しにくいことが多いです。

段階移行・並行運用のプロジェクト計画立案能力

Struts→Spring Boot の段階移行を安全に完遂できるかは、「並行運用フェーズの設計力」で決まります。次の観点でベンダーに提案を求めてください。

• 移行単位の切り分け（モジュール単位、機能単位、データ単位）
• 並行運用期間のデータ整合性検証手順
• ロールバック計画とその判断基準

見積の内訳・追加費用の発生条件

見積書は「合計金額」だけでは判断できません。次を必ず開示してもらいます。

• 単価と工数の内訳（役職別・要員別）
• 外注費・ライセンス費・クラウド費の内訳
• 追加費用が発生する条件（要件変更、期間延長、要員追加）
• 見積の前提となる「発注者側の作業」の範囲

費用感の目安と見積り比較の観点

Java／Spring Boot 基幹系の外注費用は、フェーズと外注先タイプの組み合わせで大きく変わります。ここでは一般的なレンジと、見積を比較する際の視点を整理します。数値はあくまで目安であり、規模・業種・移行難易度で上下します。

延命保守フェーズの目安

Struts／旧 Spring を継続しながら、脆弱性対応と最小限の機能追加を続けるフェーズです。

• 月額運用: 中堅受託で月額 100〜300 万円／準委任型で月額 80〜200 万円／人
• 年額目安: 1,000〜4,000 万円
• 主な費用: 脆弱性パッチ対応、月次障害対応、少量の機能追加

部分移行・機能追加フェーズの目安

現行を残しつつ、モジュール単位で Spring Boot 化する、あるいは新規要件だけを Spring Boot で追加するフェーズです。

• 費用レンジ: 数百万〜数千万円（機能単位で 1,000〜3,000 万円が中心）
• 主な費用: 要件定義、設計、実装、テスト、並行運用

フル刷新フェーズの目安

業務プロセス見直しを含む、大規模な基幹刷新です。

• 費用レンジ: 数千万〜数億円
• 主な費用: 業務要件定義、システム設計、開発、データ移行、並行運用、教育、保守立ち上げ

大手 SIer に一括委託すると数億円〜十数億円、中堅受託と準委任型のハイブリッドで組めば数千万〜1〜2 億円に収まることもあります。

見積の差を生む 4 つの変動要因

同じ「Java 基幹系刷新」でも、見積額が 2〜5 倍の差がつくことは珍しくありません。差を生む主要因は次の 4 つです。

• 規模: 画面数、機能数、業務ロジック本数
• 帳票資産: 何本の帳票を、どのエンジンで、どこまで再現するか
• 連携数: 外部システム・API・ファイル連携の本数と方式
• Java／Spring バージョン差: 8→11 と 8→17／21 では検証工数が異なる

見積を依頼する際は、この 4 変数について「自社の想定」を明示すると、ベンダー間の比較がしやすくなります。

相見積り時の比較観点

金額の総額だけを比べると、実は本質的な違いを見落とします。次の 5 観点で比較してください。

• 単価 × 工数の妥当性: 単価が同じでも工数見積の粒度で総額が変わる
• 要件確度の前提差: 「要件確定済み」と「要件詰めが必要」の前提差は、後の追加費用に直結する
• リスク負担の分担: 業務停止リスク、遅延リスクを誰がどこまで負うか
• 保守フェーズの継続体制: 3 年後・5 年後にこの体制が維持できるか
• 役員／リーダー階層のかかわり: 発注者側の意思決定を、誰が受け止めてくれるか

外注後の内製移管・保守体制の設計

Java／Spring Boot 基幹系は、リリースがゴールではなくスタートです。10〜20 年運用することを見越して、外注に頼りきりにならない体制を初日から設計します。

ドキュメント継承と設計書の作り方

外注先が離脱しても業務が続くよう、次のドキュメントは発注者側でも読める形で残します。

• 業務フロー図とシステム機能の対応表
• データモデル（ER 図）と主要テーブルの説明
• API 仕様（内部・外部）
• 運用手順書（バッチ、障害対応、パッチ適用）

「ソースコードを読めば分かる」で片付けず、業務側の担当者が読める粒度に翻訳したドキュメントを、開発フェーズ内で必ず作成させます。

若手 Java／Spring Boot 人材の育成と外注チームとの並行運用

Java 基幹系の内製移管を進める上で最大のハードルは、「若手 Java 人材が社内にほぼゼロ」という現実です。次のような並行運用モデルが有効です。

• 外注チームに若手をアサインし、ペアプログラミングで実装スキルを吸収
• 保守フェーズは「外注 60〜70％、内製 30〜40％」の共同運用で開始
• 3〜5 年かけて内製比率を上げ、外注は「大規模改修」「セキュリティ対応」に絞り込む

若手を Kotlin／Go／TypeScript の別技術で採用し、Spring Boot を副次的に学ばせるアプローチも取れます。

保守契約の粒度

保守契約は「月額固定」だけでは柔軟性を欠きます。次の 3 つを組み合わせるのが実務的です。

• 月額固定型: 定期パッチ、監視、軽微な問い合わせ対応
• スポット型: 中規模の改修・機能追加を都度発注
• SLA 型: 障害対応、復旧時間の保証

保守フェーズは「初日の設計」で長期コストが決まります。初期の契約段階から、外注比率の推移と内製移管の計画を数値で握っておくことが、10 年運用を成立させる要になります。

まとめ・次の一歩

Java／Spring Boot 基幹システムの外注は、単に「Java 開発会社」を探すのではなく、「自社の現行資産と目的から、どの方向で、どの外注先タイプに、どんな契約形態で任せるか」を判断する意思決定プロセスです。本記事で扱った判断フローを最後に凝縮すると、次の 5 点に集約されます。

• Java エンジニア不足は業界全体の構造問題であり、外注前提の意思決定は例外ではなく標準になっている
• 選択肢は「Struts／旧 Spring 継続」「Spring Boot 移行」「フル刷新」の三択で、資産量・予算・業務変更許容度で決まる
• 外注先は 5 タイプ（大手 SIer／中堅受託／準委任型フリーランス／ニアショア／オフショア）を単独ではなく組み合わせで使う
• 「Struts など旧世代 Java まで扱えるか」は具体的な問いで確認する（「できます」だけで判断しない）
• 見積は合計金額ではなく、単価・工数・前提・リスク分担で比較する

明日から取れる次の一歩は、次の 3 つです。

1. 現行 Java 資産の棚卸し（言語・フレームワーク・帳票・連携・DB・バッチ）
2. 目的・KPI の言語化（コスト削減・業務効率・拡張性・法対応・人材リスクのいずれを最優先か）
3. 複数タイプの外注先への相談（大手 SIer 1〜2 社、中堅受託 2〜3 社、準委任型 1〜2 社に並行で相談）

Java／Spring Boot 基幹系の刷新は数年単位のプロジェクトになりますが、最初の一手は「棚卸しと相談」の 2 つだけで踏み出せます。Java エンジニア不足という制約の中でも、外注チャネルを組み合わせれば必要な体制は組めます。動き出せば、次の景色は必ず見えてきます。