Struts保守からSpring Boot求人へ。移行案件を足場にする手順

「Struts 1.3、Java 1.6、Tomcat 6です。技術欄にはこれしか書けないんですが、Spring Bootの求人に出して大丈夫でしょうか」——職務経歴書の技術欄を読み上げながら、こう切り出す相談者が少なくありません。

私はIT・Web業界を中心に800名以上の転職支援に携わってきましたが、Struts系の保守が長い方の相談は、スキルの量より「求人票の言葉と経歴書の言葉が噛み合っていない」ことで止まっているケースが大半です。今回は、Struts保守を足場にSpring Boot求人へ進むために、新規開発求人で何が見られているのか、移行案件への手の挙げ方、経歴書の書き方、最低限示したい成果物を、実体験を交えてお伝えします。

目次

1. Struts保守の経験はSpring Boot求人でどう読まれるのか
2. Struts 1とStruts 2で読まれ方は少し違う
3. 求人票の語と経歴書の語のズレを知る
4. 実際にあった例（Lさんの場合）
5. 応募先を「移行・リプレイス」に寄せ直す
6. 社内の移行案件に手を挙げるときの動き方
7. 移行案件が社内にない・通らないとき
8. 職務経歴書のBefore/Afterを具体的に書き換える
9. 書かないほうがいい表現
10. Java 8以前から17へ、何が変わったかを一言で語れるようにする
11. Spring Bootで最低限示したい4つの成果物
12. 1. 画面1本の置き換え
13. 2. Bean Validationへの検証の移植
14. 3. MockMvcによるテスト
15. 4. javax.*からjakarta.*への理解
16. 移行案件に一生入れないと分かったときの判断
17. 転職で移行案件を探す場合の現実
18. よくある質問
19. まとめ

Struts保守の経験はSpring Boot求人でどう読まれるのか

先に結論を言うと、Struts保守の経験は「経験にならない」わけではありません。ただし、新規開発の求人と移行・リプレイスの求人とで、同じ経歴が正反対に読まれます。

新規開発の求人では、採用側が確認したいのは「今の書き方でゼロから作れるか」です。経歴書にJava 1.6やStruts 1系しか並んでいないと、書類を見る側は「アノテーションベースの設定、DI、REST APIを知らないまま止まっている人」と推測します。能力の評価というより、材料がないので推測で埋められる、という状況です。

一方、移行・リプレイスの求人では、読まれ方が逆転します。移行する側は「旧システムが何をしているか分かる人」を必ず必要とするからです。仕様書が古く、コードにしか本当の仕様が残っていない現場では、Strutsのアクション、フォームBean、struts-config.xmlの遷移定義を読み解ける人の価値は大きくなります。

なお、Strutsの世界自体も縮小しています。Apache Struts公式のEOLバージョン一覧では、1.xのEOLは2013年4月5日、2.3.xは2019年9月12日と掲載されています。2.5.xは2023年10月30日付で、公式のEOL告知が出ました。告知によると、その後6か月はセキュリティ問題に限ってサポートし、以降は公式には扱われなくなります。EOL版にはプロジェクトからのサポートが一切ない、というのが公式の説明です。

現行の系列は別にありますが、現場に残っているのは古い系列のほうが多い、というのが私の実感です。つまり、古いStruts案件は「今後も増える」のではなく、「いつか移行される前提で残っている」仕事です。この事情は、後で職務経歴書を書くときの追い風になります。

Struts 1とStruts 2で読まれ方は少し違う

同じ「Struts」でも、1系と2系は別物です。1系はActionとActionForm、2系はインターセプタとOGNLという設計で、移行の難しさも違います。経歴書には必ずどちらの系かを書いてください。「Struts」とだけ書くと、採用側は1系前提で古く見積もることが多いです。

私の感覚では、1系の保守はすでにEOLから10年以上経った環境を回してきた経験として、「リスクを抱えたまま運用した判断」を語れる分だけ、移行案件では説得力が出ます。2系は脆弱性対応のパッチ当てを経験している方が多く、そこも書ける材料になります。

求人票の語と経歴書の語のズレを知る

新規開発求人で書類が通らない原因を、私は「能力不足」ではなく「語彙のズレ」と見ています。求人票に並ぶ語と、保守担当者が経歴書に書きがちな語を並べると、次のようになります。

右端の列は、実際にはほとんどの保守担当者が日常的にやっていることです。ところが経歴書に残るのは真ん中の列の一語になってしまい、求人票の語と接続されません。独自フレームワークの保守経験の書き換えについては独自FW保守の職務経歴書の翻訳で段階的に整理しているので、Struts固有の事情だけをこの記事では扱います。

ポイント： 「新しい書き方を知らない」と読まれるのは、知らないからではなく、知っているかどうかを判断する材料が経歴書にないからです。材料を足すには、実務の記述と、自分で動かした小さな成果物の二本立てが必要になります。

実際にあった例（Lさんの場合）

Lさん（41歳・経験16年）は、流通業向けの受発注システムを受託開発する会社で、Struts 1.3とJava 1.6の画面まわりを長く保守してきたバックエンドエンジニアでした。自社オフィス勤務で、客先常駐ではありません。Spring Bootの求人に10社近く応募して書類通過が1社だけ、という状況で相談に来られました。

私が経歴書を見て最初に気づいたのは、「担当業務」欄が「受発注画面の改修、不具合対応」の一行だったことです。Lさんに聞くと、実際には画面の入力チェックをActionFormのvalidateメソッドから共通ルールに寄せたこと、Tomcat 6からの更新が顧客の予算で止まり、影響調査の資料だけは作ったこと、夜間バッチの障害を月数件切り分けていたことが出てきました。どれも経歴書には1文字もありませんでした。

もう一つ分かったのは、応募先の選び方です。応募した10社のうち7社は、求人票の本文に「新規サービスの立ち上げ」「モダンな技術スタック」と書かれた求人でした。Lさんの経歴は、その求人が求めている人物像のちょうど反対側にあります。ここを変えない限り、書類の書き方を整えても通過率は大きくは動きません。

応募先を「移行・リプレイス」に寄せ直す

私が勧めたのは、応募先を「リプレイス」「レガシーからの刷新」「基幹システム移行」と書かれた求人に絞ることでした。必須要件にSpring Boot実務が入っていても、歓迎要件の位置なら通る余地があります。求人票の文言を一つずつ読み、必須と歓迎を分けて仕分けるところまで、Lさんと一緒にやりました。

絞り直した後の応募は5社で、書類通過が2社、そのうち1社から内定が出ました。年収は大きくは動いていません。一人の例なので再現性を保証するものではありませんが、後半で説明する「小さな移行の成果物」を作って面接に持ち込んだことが、一番効いたと見ています。

社内の移行案件に手を挙げるときの動き方

転職の前に、社内に移行案件があるなら、そこに入るのが最も確実な足場です。実務でSpring Bootに触れる、という事実は、独学の成果物より強い材料になります。

ここで注意したいのは、「やりたいです」と言うだけでは動かない、という点です。移行案件は、顧客の予算と体制の都合で決まることが多く、立候補の伝え方次第で通るかどうかが変わります。移行案件に手を挙げる前に確認すべき点はCOBOL・VB6からモダン言語への転向の記事で触れているため、ここでは Strutsの現場で使える動き方に絞ります。

棚卸しを先に出す理由は、移行案件の最初の仕事がまさにそれだからです。上司や顧客が「やりたいが何から手をつけるか分からない」状態のとき、一覧が出てくるだけで案件が現実味を帯びます。棚卸しを先に出した人が、そのまま移行の打ち合わせに呼ばれる側に回りやすいというのが、私の見てきた実感です。

役割を限定して申し出るのも、通りやすくする工夫です。いきなり「Spring Bootで書かせてください」と言うと、実績がない人には任せにくくなります。「現行仕様を一番分かっているので、移行後の動作確認と仕様の説明を担当します」と言えば、リスクを取らせずに案件へ入れます。入ってしまえば、新しい側のコードをレビューする立場で自然にSpring Bootに触れられます。

移行案件が社内にない・通らないとき

Lさんの会社は、実際にはこの案件が社内に存在しませんでした。顧客の予算が出ず、Tomcatの更新すら止まっていたからです。移行案件がない会社にいる場合、案件が生まれるのを待つのは得策ではありません。次の章の「小さな移行」を自分で作って、外の移行案件に持ち込むほうが早いです。

職務経歴書のBefore/Afterを具体的に書き換える

移行案件や新規開発の求人に出す職務経歴書は、技術欄ではなく、プロジェクト概要の書き方で勝負が決まります。LさんのBefore/Afterを、実際の書き方に近い形で示します。

Before

受発注管理システムの保守・改修。Struts 1.3、Java 1.6、Oracle。画面改修、不具合対応を担当。

After

流通業向け受発注管理システム（Struts 1.3／Java 1.6／Tomcat 6／Oracle）の保守・改修を担当。入力画面の検証ロジックをActionFormごとの個別実装から共通ルールに集約し、改修時の修正箇所を減らした。夜間バッチの障害は、ログと実行履歴から原因を切り分け、再発防止の手順を整備。Tomcat更新の影響調査では、依存ライブラリの互換性を整理して判断資料を作成（予算の都合で実施は見送り）。個人学習として、既存画面1本をSpring Bootへ置き換える検証を実施（GitHub公開）。

Afterで加えた要素は3つです。何を変えたか（検証の集約）、どう判断したか（影響調査）、実施できなかったこと（見送りの事実）。特に3つ目は、書くことをためらう方が多いのですが、実施されなかった提案も、判断の材料を作った事実として書けるのが保守担当者の強みです。

書かないほうがいい表現

反対に、「最新技術にも意欲的に取り組みます」「Spring Bootを学習中です」だけの記述は、書類を読む側には判断材料にならず、むしろ薄く見えます。学習中と書くなら、何を作ったかとリポジトリのURLを添える。作っていないなら書かない。この線引きだけで、書類の印象はかなり変わります。

Java 8以前から17へ、何が変わったかを一言で語れるようにする

もう一つ、面接で必ず出る話題があります。「Java 8以前の環境から、今の書き方に何が変わったと理解していますか」という確認です。ここで文法の網羅は求められていません。見られているのは、変化の方向を自分の言葉で説明できるかどうかです。

保守者の方に私が勧めるのは、次の3点に絞って語れるようにすることです。ラムダ式とStream APIで、ループと一時変数だらけの処理がどう書き換わるか。Optionalによるnullの扱いが、旧来のnullチェックの連続とどう違うか。そしてレコードやvar、switch式など、新しいJavaで記述量が減った部分。三つとも、自分が保守してきた実コードの一部を例に出せると、暗記ではなく理解として伝わります。

Spring MVCとSpring Bootの違いも、よく聞かれます。簡単に言えば、Spring MVCはWebアプリの処理の枠組み、Spring Bootはそれを依存関係や設定の自動構成を含めて素早く動かすための土台です。Strutsのstruts-config.xmlやweb.xmlに書いていた設定が、Bootでは規約とapplication.propertiesに寄っていく、と説明すると、保守経験者には通じやすくなります。

Spring Bootで最低限示したい4つの成果物

「ポートフォリオは何を作るか」という質問をよくもらいます。新規サービスをゼロから作る必要はありません。Struts保守者が示すべきなのは、今の業務の延長線上にあるものを、新しい書き方で作り直したものです。具体的には次の4つで、これを1つのリポジトリにまとめるのが現実的です。

1. 画面1本の置き換え

実務のソースは持ち出せないので、架空の業務で構いません。受発注なら「注文の検索、一覧、1件登録」の3画面程度で十分です。大切なのは、Strutsでの処理の流れ（リクエスト、Action、フォームBean、JSP）が、Spring MVC側のどの要素（コントローラ、フォーム、Thymeleafなどのテンプレート）に対応するかを、READMEに表で書くことです。この対応表こそが「分かって移行できる人」の証拠になります。

2. Bean Validationへの検証の移植

ActionFormのvalidateや、validation.xmlで書いていた入力チェックを、Bean Validationのアノテーションに置き換えます。ここは保守者の知識が最も活きる部分で、業務特有の相関チェック（開始日が終了日より後ならエラー、など）を、カスタムバリデータとして実装すると、実務を知っている人の成果物として読まれます。

3. MockMvcによるテスト

Strutsの保守でテストを自動化できていなかった方は多いはずです。だからこそ、MockMvcで「このリクエストを送ると、こう検証エラーになる」というテストを数本書いておくと、一気に新規開発側の人に見えます。テストの本数より、異常系を入れることです。

4. javax.*からjakarta.*への理解

Spring Boot 3.0は、公式のリリースノートでJava 17を最低バージョンとし、依存するAPIをJava EEからJakarta EEへ移行したと説明されています。サーブレットなどのパッケージ名がjavax.*からjakarta.*になるのは、この流れの一部です。古い資料のコードをそのまま写して動かない、という経験をした方は、READMEにその経緯を書いてください。移行案件の現場で最初に当たる壁が、まさにここだからです。この壁にぶつかって解決した記録は、採用側にとって実務の予行演習として読まれます。

なお、ここで書く内容には、お使いのバージョンの公式ドキュメントで確認した事実だけを使ってください。バージョンの要件は変わるため、記憶で書くとREADMEの信頼性が下がります。

移行案件に一生入れないと分かったときの判断

ここまで読んで、「うちの会社は移行をやる気配がない」と感じた方もいるはずです。その場合の判断基準を、私は次のように伝えています。

目安は、自分が棚卸しと提案を出したあとの反応です。一覧を作って上司に提案し、それでも半年たって何も動かないなら、その会社で移行案件に入る可能性は低いと見て構いません。提案を出す前に「どうせ無理」と諦めるのは早計ですが、提案後に反応がないまま時間を使い続けるのは、市場価値の面で損をします。

もう一つ、判断を難しくするのが「Struts案件が今後なくなるのか」という不安です。EOLの事実はあっても、現実には止められない基幹システムが長く残ります。ですから「なくなるから急いで逃げる」のではなく、「残る期間に、移行を語れる人になる」と考えるほうが実態に合います。

転職で移行案件を探す場合の現実

外に出る場合は、リプレイスやマイグレーションを事業としている受託・SIerの案件が受け皿になります。ここで気をつけたいのは、移行案件の中身にも幅があることです。単純な機械変換の後始末だけで、設計に触れられない現場もあります。面談では「移行後の設計判断は誰が行うか」「Spring Bootのコードをレビューする機会はあるか」を必ず聞いてください。これを聞かずに入ると、保守が名前を変えただけの仕事になりかねません。

また、自社開発の新規求人を狙うなら、移行案件を1件挟むのが現実的な順序です。保守から新規開発へ、一足飛びに行く人もいますが、私が支援してきた範囲では、間に移行の実務を挟んだほうが、面接で「実際にどう移したか」を語れる分だけ通りやすくなります。

よくある質問

Struts保守だけで、Spring Boot未経験でも応募できますか。 応募はできます。ただし新規開発の求人は書類で落ちやすいので、移行・リプレイス系の求人を中心に、歓迎要件がSpring Bootになっているものを選んでください。成果物をリポジトリで見せられると、通過率は変わります。

Java保守は経験として評価されないのでしょうか。 評価されます。ただし「保守」の一語では判断材料にならないため、障害調査、仕様確認、影響調査といった担当工程を具体的に書く必要があります。

Spring Bootは独学でどこまでやればいいですか。 実務を代替する必要はありません。上で挙げた4つの成果物を一通り動かし、説明できる状態までで十分です。範囲を広げるより、1つを深く説明できることを優先してください。

Struts案件は今後なくなりますか。 公式にEOLとなったバージョンが多く、新規で採用される技術ではありません。ただし稼働中のシステムは長く残るため、保守の需要が突然なくなるとは考えていません。需要の中心が、保守から移行へ動いていくと見ています。

まとめ

Struts保守の経験は、新規開発の求人では「新しい書き方を知らない」と読まれやすく、移行・リプレイスの求人では「旧システムの仕様を語れる人」として評価されます。同じ経歴が、見る場所によって違う顔をするだけです。

この記事で一番伝えたかったのは、保守の経験を移行の言葉に翻訳して見せる、その一点です。経歴書に判断の経緯を足し、小さな移行の成果物を1本添える。そこまでやれば、Spring Bootの実務が浅くても、移行案件の面接で語れるものが揃います。まずは今週、担当画面の棚卸し一覧を作るところから始めてみてください。