静的型付け・オブジェクト指向
大規模開発で品質を保ちやすい言語。クラス、継承、interface、例外処理などの基礎理解はJava面談で聞かれやすいです。
01 / Why
この技術を営業が知る意味
Javaは「Java経験あり」だけでは判断できません。案件概要のJavaが、Spring Boot新規開発なのか、Struts保守なのか、基幹システム刷新なのかで、提案できる人材は変わります。
新人はここだけ先に押さえる
Java提案は、経験年数だけで判断しない
必ず、Spring Boot実務、担当工程、DB/API/テスト経験、業務領域、レガシー移行・クラウド経験を確認します。 「Java 3年」でも、テスト中心なのか、設計からWeb/APIを担当したのかで提案先は変わります。
営業が見るべき中心は、言語名ではなく現場で任される役割
Javaは金融、保険、官公庁、EC、物流、社内基幹など幅広い領域で使われます。 新人営業はまず「Javaができるか」ではなく、「どのJava現場で、どの工程を、どの技術セットで担当してきたか」を確認します。
営業向けの結論
Java提案では、言語経験年数よりも、Spring経験、業務系経験、DB/API/テスト経験、クラウドや移行経験の一致度を補足できるかが重要です。
02 / Overview
Javaの概要を営業実務に接続する
元資料の技術基礎は、案件概要の単語を理解するための地図です。細かい実装を覚えるより、キーワードの意味と確認観点を押さえます。
JVMで動く
JDK、JRE、GC、メモリ管理という単語が出ます。運用や性能改善案件では、単なる実装経験より深い理解が評価されます。
Spring / Spring Boot
現在のJava案件で最重要。Spring Boot、Spring MVC、Spring Data JPA、Spring Securityは案件概要で頻出です。
DB・テスト・クラウド
SQL、JUnit、Git、Docker、AWS/Azureなどとセットで評価されます。Java単体より「業務アプリを作れるか」を見ます。
JavaとJavaScriptは別物
名前は似ていますが、案件では基本的に別スキルとして扱います。Java経験者をJavaScript案件へ、JavaScript経験者をJava案件へ、経験名だけで提案しないでください。
サーバーサイド・業務システム寄り
Spring BootのWeb/API、金融・基幹システム、Android、バッチなどで出やすい技術です。
Web画面・フロントエンド寄り
React/Vueなどの画面開発、Node.jsのサーバーサイドで出やすい技術です。
技術キーワードを営業の確認観点へ変換する
表の右列を、そのまま登録面談の深掘り質問に変換します。
| 技術基礎 | 意味 | 営業が確認すること |
|---|---|---|
| Java 8 / 11 / 17 / 21 / 25 | 主要LTS版。現場ごとに採用バージョンが違う。Java 26は現行リリースだが非LTS | 直近で使ったバージョン、バージョンアップ経験、古いJavaへの抵抗感、LTS/非LTSの採用理由 |
| オブジェクト指向 | クラス設計や役割分担の考え方 | 詳細設計以上を任せられるか、interfaceや継承を説明できるか |
| MVC | Webアプリの基本構造 | Controller、Service、Repository、View/APIのどこを担当したか |
| Spring Boot | Java Web/API開発の標準 | 新規構築か改修か、REST API、DB連携、認証、テストまで経験したか |
| JUnit / Mockito | Javaの単体テスト標準 | テストコードを書いたか、カバレッジや品質管理の経験があるか |
| AWS / Azure | クラウド上でJavaアプリを動かす基盤 | EC2、ECS、RDS、App Serviceなど、どこまで触ったか |
03 / Job Ticket
SES案件での使われ方と案件概要キーワード
Java案件は「業務システムの開発・保守」「Spring BootのWeb/API開発」「レガシー移行」「クラウド化」に大きく分かれます。
言語・バージョン
JavaJava 8Java 11Java 17Java 21Java 25JDKJVM
フレームワーク
SpringSpring BootSpring MVCSpring Data JPASpring SecurityStrutsSeasar2
開発・品質
REST APISQLJUnitMockitoGitMavenGradleDockerCI/CD
領域・基盤
金融保険官公庁基幹システムAWSAzureマイクロサービスSAPSalesforce
まず見る
案件概要は、必須条件を分解して読む
「Java経験◯年以上」を見たら、工程、フレームワーク、DB/API/バッチ、テスト、業務領域、クラウド、役割まで分解します。分解できると、スキルシートで探す根拠が明確になります。
金融系Webシステム刷新 Java/Spring Boot開発
- 概要
- 既存の金融系WebシステムをJava 17 / Spring Boot構成へ刷新。既存仕様を確認しながら、業務APIと管理画面を段階的に移行する案件。
- 工程
- 基本設計、詳細設計、製造、単体/結合テスト
- 環境
- Java 17、Spring Boot、Spring Data JPA、PostgreSQL、AWS、Git、JUnit
- 作業
- REST API実装、DB連携、既存機能の影響調査、JUnitでの単体テスト、レビュー指摘対応
- 必須
- Java開発3年以上、Spring Boot実務、REST API、SQL、設計経験
- 尚可
- AWS、マイクロサービス、性能改善、レガシー移行、金融業務知識
- 確認
- Java経験年数だけでなく、設計経験、Spring Boot側の担当範囲、DB/API/テストまで一貫して説明できるかを見る。
まず工程を見る
「製造のみ」か「設計から」かでレベルが変わります。Java3年でも設計未経験なら基本設計案件には補足が必要です。
Spring Bootの実務深度を見る
研修・個人開発では弱いです。業務API、DB連携、認証、テスト、障害対応まであると提案しやすくなります。
レガシーかモダンかを見る
Struts保守とSpring Boot新規開発は別物です。移行案件なら、旧FW理解と新FW経験の両方が強みになります。
Java案件の職種・役割分類
年数より「どの役割を任されていたか」を見ます。役割が分かると、案件概要の工程条件と照合しやすくなります。
| 役割 | 主な担当 | 営業が確認すること |
|---|---|---|
| PG | 詳細設計、製造、単体テスト中心 | 実装した機能、テストコード有無、指示待ちか自走か |
| SE | 基本設計、詳細設計、実装、テスト、レビュー | 設計書作成、顧客レビュー、仕様調整、レビュー対応 |
| リーダー / サブリーダー | 進捗管理、レビュー、若手フォロー、顧客調整 | 管理人数、レビュー範囲、課題管理、顧客との会話量 |
| 保守運用 | 改修、障害調査、問い合わせ対応、既存仕様調査 | 調査の深さ、ログ確認、暫定対応、本番影響の理解 |
| 移行要員 | Struts / Seasar2などからSpring Bootへの移行、既存解析、テスト | 旧FW解析だけか、Spring Boot側の設計・実装もしたか |
Spring Boot案件とStruts / Seasar2保守案件の違い
| 観点 | Spring Boot | Struts / Seasar2 | 営業の補足 |
|---|---|---|---|
| 案件の出方 | 比較的新しいWeb/API開発、刷新、新規開発 | 古い業務システムの保守、改修、既存解析、移行 | 同じJavaでも求められる経験が違うと捉える |
| 一緒に出やすい単語 | REST API、クラウド、JUnit、CI/CD、Spring Security | 既存仕様調査、画面改修、障害対応、移行、影響調査 | 案件概要の周辺語で現場の性質を読む |
| 提案時の注意 | Spring Boot実務、DB/API/テスト経験を具体化 | 保守力、解析力、移行経験を具体化 | Struts経験者をSpring Boot案件へ出す時は、移行経験やSpring Boot側の担当有無を補足する |
04 / Domain
代表的な案件領域
Javaはエンタープライズ領域に強く、長期・大規模・安定案件が多いです。領域ごとの見方を持つと、提案時の補足が具体的になります。
金融・保険
勘定系、決済、保険契約、審査、顧客管理など。品質、セキュリティ、テスト、ドキュメントが重視されます。
官公庁・公共
大規模・長期・ウォーターフォールが多い領域。設計書、結合テスト、手順遵守、報告の丁寧さが評価されます。
EC・Webサービス
Spring Boot、REST API、クラウド、性能改善の経験が刺さりやすい領域。スピードと改善経験も見られます。
基幹・業務システム
販売管理、在庫、会計、人事、物流など。業務理解、SQL、バッチ、外部連携、保守運用経験が強みになります。
Java × バッチ開発も見落とさない
Java案件はWeb画面やAPIだけではありません。基幹・金融・物流・会計・販売管理では、バッチ経験が評価されることがあります。
決まった時間や条件で、まとめて処理を実行する仕組みです。
夜間処理、請求処理、データ連携、CSV取込、在庫更新、帳票作成など。
バッチ、夜間処理、データ連携、Spring Batch、ジョブ、帳票、CSV。
「画面開発か、APIか、バッチか」「Spring Batch経験はあるか」を確認します。
関連領域もJava営業では見逃さない
| 領域 | 元資料のポイント | 営業での見方 |
|---|---|---|
| Android | かつてJavaが公式言語。現在はKotlin推奨 | Java経験だけでAndroid案件に出さない。Android SDK、Kotlin、アプリ開発工程を確認 |
| ビッグデータ | Hadoop / Sparkのエコシステム | Javaだけでなく、データ処理、分散処理、Scala/Python、クラウド基盤経験を確認 |
| Salesforce | ApexはJava風の言語 | Java経験者が移行しやすいが、Salesforce標準機能、Apex、LWC経験の有無を見る |
| SAP | ERP領域。ABAPやS/4HANA移行 | Java経験だけでSAP案件に出さない。SAPモジュール、ABAP、業務知識を確認 |
05 / Skill Sheet
スキルシートの読み方
Javaのスキルシートは、技術名の羅列より「どの工程で、どの役割を、どの成果物まで担当したか」を読みます。
強く読める記載
- 基本設計から結合テストまで一貫して担当
- Spring BootでREST API、DB連携、認証、テストコードを実装
- JUnit / Mockitoで単体テスト、CIで自動テストを運用
- StrutsからSpring Bootへの移行で設計・実装を担当
- AWS上のJavaアプリでRDS、ECS、CloudWatchなどを使用
追加確認が必要な記載
- Java経験あり、詳細不明
- Spring学習済み、実務有無不明
- 改修担当、担当範囲や規模不明
- テスト担当、製造経験があるか不明
- クラウド経験あり、画面操作だけか設計・構築か不明
新人はここだけ先に押さえる
スキルシートは、担当工程と担当範囲で読む
「Java」「Spring Boot」と書いてあっても、画面だけ、APIだけ、バッチだけ、テストだけの可能性があります。どの機能で、どの工程を、どこまで自分で判断したかを確認します。
記載
Java / Spring Boot / PostgreSQL
弱い読み方
JavaとSpring Bootができる人
営業の読み方
どの層を担当したか。Controller、Service、Repository、SQL、テストまで触ったかを見る。
面談で聞く
「担当APIの概要、DB設計への関与、テストコード作成有無、障害時の対応」を確認する。
スキルシートで見るべき項目
「まず見る」は必須条件との一致、「追加で聞く」は提案コメントの根拠になります。
| 見る項目 | チェック観点 | 提案時の補足材料 |
|---|---|---|
| 工程 | 要件定義、基本設計、詳細設計、製造、テスト、保守 | 「詳細設計以降を一貫」「基本設計から顧客レビュー経験」など |
| FW | Spring Boot、Spring、Struts、Seasar2 | 「Spring Boot実務」「レガシーFWからの移行経験」など |
| DB | Oracle、PostgreSQL、MySQL、SQL、JPA、MyBatis | 「SQL実装・性能改善」「DB設計レビュー参加」など |
| 品質 | JUnit、Mockito、SonarQube、レビュー、CI/CD | 「単体テストコード作成」「レビュー指摘対応」など |
| 役割 | メンバー、サブリーダー、PL、レビュー担当 | 「若手フォロー」「レビュー」「タスク管理」など |
06 / Interview
登録面談で聞くこと
面談では暗記クイズではなく、スキルシートの記載が実務経験として説明できるかを確認します。
基礎を確認する質問
- Javaで直近使ったバージョンは何ですか。Java 8 / 11 / 17 / 21 / 25の違いや、LTS版を使う理由で意識したことはありますか。
- オブジェクト指向のカプセル化、継承、ポリモーフィズムを実務例で説明できますか。
- interfaceとabstract classの違いを、現場での使い分けとして説明できますか。
- List / Set / Mapはどのように使い分けましたか。
- 例外処理で気をつけたこと、ログ出力やエラー通知の経験はありますか。
Spring Boot経験を確認する質問
- 担当したAPIや画面の概要を、業務内容から説明してください。
- Controller、Service、Repositoryのうち、どこを担当しましたか。
- Spring BootとSpring Frameworkの違いをどう理解していますか。
- DB連携はJPA、MyBatis、JdbcTemplateのどれを使いましたか。
- 認証・認可、トランザクション管理、バリデーションの実装経験はありますか。
品質・テストを確認する質問
- JUnitやMockitoでどのようなテストを書きましたか。
- 単体テスト、結合テスト、E2Eテストのどこを担当しましたか。
- レビューでよく指摘されたこと、逆にレビューした経験はありますか。
- SonarQube、Checkstyle、SpotBugsなどの静的解析を使いましたか。
- 障害や不具合が出たとき、原因調査をどのように進めましたか。
案件適合を確認する質問
- 金融・保険・官公庁など、業務知識が必要な現場経験はありますか。
- Struts、Seasar2などレガシーJavaの保守や移行経験はありますか。
- AWSやAzure上でJavaアプリを動かした経験はありますか。
- リーダー、レビュー、若手フォロー、顧客折衝の経験はありますか。
- 次の案件で避けたい環境、希望する工程、単価より優先したい条件はありますか。
面談で深掘りできたら強い
「経験ありますか」ではなく、担当した機能と判断を聞く
「どの機能で、どの工程で、何を自分で判断しましたか」と聞けると、スキルシートの言葉が実務経験なのか、補助作業なのかが見えます。
深掘りの型
「経験ありますか」で止めずに、「どの機能で、どの工程で、どの判断を自分でしましたか」まで聞く。
提案に使う型
「Spring Boot経験あり」ではなく、「REST APIの設計・実装・JUnitまで一貫して担当」と書く。
07 / Level
レベル感の見極めと △ / ○ / ◎ 判定例
Javaのレベルは年数だけでは測れません。設計、Spring Bootの深さ、テスト、障害対応、周辺技術の説明力で見ます。
製造・単体テスト中心
Java基本文法、SQL、簡単な改修ができる。設計やSpring Bootの深い説明はまだ弱い。
提案しやすい案件製造、テスト、保守改修、詳細設計補助。
設計から実装まで担当
Spring BootでAPIや画面を作り、DB連携、JUnit、レビュー対応まで説明できる。
提案しやすい案件詳細設計以降、基本設計補助、Web/API開発。
設計・改善・リードができる
アーキテクチャ、性能改善、マイクロサービス、クラウド、移行設計、レビューを任せられる。
提案しやすい案件基本設計、技術リード、移行、クラウド化、性能改善。
追加で聞く
年数とレベルは一致しない
Java経験が長くても、テスト中心なら初級寄りです。経験年数が短くても、Spring Bootで設計、API、DB、JUnit、レビューまで説明できる人は中級以上として見られることがあります。
Judge
この回答なら △ / ○ / ◎
新人営業が面談で使える判定例です。回答の具体性と自走度を見ます。
| 質問 | 弱い回答 | 提案可能な回答 | 強く推せる回答 |
|---|---|---|---|
| Spring Bootで何を担当しましたか | 改修を少ししました。詳しい部分はリーダーが見ていました。 | REST APIのController、Service、Repositoryを実装し、SQLと単体テストも担当しました。 | API設計から実装、トランザクション、例外設計、JUnit/Mockito、レビュー対応まで担当しました。 |
| Javaのオブジェクト指向を説明できますか | クラスや継承のことです。 | カプセル化、継承、多態性を説明でき、業務ロジックをクラスに分けて実装しました。 | interfaceで実装差分を吸収し、DIで疎結合にした設計意図まで説明できます。 |
| テスト経験はありますか | 単体テスト項目書に沿って実施しました。 | JUnitでService層の単体テストを書き、Mockitoで外部依存をモック化しました。 | テスト観点作成、JUnit/Mockito、カバレッジ確認、CIでの自動実行まで経験しています。 |
| レガシー移行経験はありますか | 古いシステムの保守はありました。 | Struts画面の改修とSpring Boot側APIの一部実装を担当しました。 | Strutsの既存仕様調査、移行設計、Spring Boot化、移行後テストまで担当しました。 |
| AWS経験はありますか | 現場でAWSを使っていたと思います。 | EC2上のJavaアプリ、RDS、S3の利用経験があり、ログ確認も行いました。 | ECS/RDS/CloudWatch構成で運用し、デプロイ、障害調査、性能確認まで関与しました。 |
08 / Mismatch
営業がミスりやすい提案
Javaは案件数が多いため、雑に当てるとミスマッチも増えます。よくある失敗を先に知っておきます。
新人営業がやりがちなミス
| ミス | なぜ危ないか | 確認・補足すること |
|---|---|---|
| Java経験年数だけで提案する | 製造のみ、テストのみ、古いFWのみの可能性がある | 工程、Spring Boot実務、担当機能、設計経験を確認 |
| Spring学習済みをSpring Boot実務と同等に扱う | 業務API、DB連携、テスト、障害対応の経験が不足しやすい | 個人開発か実務か、チーム開発か、担当範囲を確認 |
| Struts保守経験をモダンJava案件にそのまま出す | Spring Boot、REST API、クラウドの経験が不足する可能性 | 移行経験やSpring側の担当有無を補足 |
| Android Javaを業務Javaと同じに見る | Web/API、Spring、DB、サーバーサイド経験とは別領域 | サーバーサイドJava経験の有無を確認 |
| AWS経験ありを過大評価する | ログ閲覧だけ、環境利用だけの可能性がある | EC2/ECS/RDSなど具体サービスと担当作業を確認 |
| 資格だけで即戦力扱いする | 資格は基礎力の証明で、実務設計力とは別 | 資格を補足材料にし、実務経験とセットで提案 |
まず見る → 追加で聞く → 提案に書く
Java人材を提案するまでの判断フロー
迷ったらこの順番で確認します。経験年数から入るのではなく、案件条件を分解して、根拠を探し、不足を面談で埋めます。
案件概要を見る
Javaだけで判断せず、Spring Boot、Struts、DB、API、バッチ、クラウド、テストを拾う。
必須条件を分解
工程、役割、技術、業務領域、尚可条件に分けて、足りない条件を見える化する。
根拠を探す
スキルシートから、担当機能、成果物、レビュー、テスト、障害対応の記載を探す。
面談で確認
不足条件や曖昧な経験を、実務例・担当工程・自分で判断した範囲まで聞く。
提案に書く
案件条件に対して、合う根拠と不足条件の補足を短く具体的に書く。
09 / Proposal
提案時の注意点と提案コメント例
Java提案では、案件概要の不安を先回りして埋めるコメントが効きます。経験の根拠を短く具体的に書きます。
提案時の注意点
- 「Java経験◯年」だけで終わらせず、Spring Boot、工程、担当機能を補足する。
- レガシー経験は弱みではなく、移行・保守・既存解析の強みに変換する。
- クラウドやテスト経験は、使ったサービス名・ツール名・担当作業まで書く。
- 不足条件がある場合は、近い経験とキャッチアップ根拠を明記する。
- 業務領域が合う場合は、金融、保険、公共、基幹などを前に出す。
提案コメントに使える表現
案件条件に対して、経験の根拠を補足する
「Java経験あり」ではなく、「Spring BootでREST APIの詳細設計から実装、JUnitまで担当」のように、案件概要の条件に対応する言葉で書きます。
10 / Check
確認テスト
研修後に、案件概要・スキルシート・面談・提案の判断軸が残っているかを確認します。
1. Java案件で「Java経験3年」以外に必ず確認したいことは？
回答観点: 工程、Spring Boot実務、担当機能、DB/API/テスト経験、業務領域、クラウドや移行経験。
2. Spring Boot案件で、スキルシートから読みたい担当範囲は？
回答観点: Controller、Service、Repository、DB連携、REST API、認証、テストコード、レビュー対応。
3. Struts経験者をSpring Boot案件に提案する時の注意点は？
回答観点: Struts保守だけでは不足。Spring Boot実務、移行経験、REST API、キャッチアップ根拠を補足する。
4. JUnit / Mockito経験はなぜ提案で有利になる？
回答観点: 品質を担保する実務経験として見られる。単体テスト設計、モック化、CI、自動テストまであると強い。
5. AWS経験ありと聞いたら、追加で何を聞く？
回答観点: 使ったサービス名、担当作業、設計/構築/運用/ログ確認/障害調査のどこまで関与したか。
6. Java × Salesforce / SAP案件でミスりやすい点は？
回答観点: Javaと似た知識が活きる場合はあるが、SalesforceはApex/LWC、SAPはABAPや業務モジュール経験が必要。
7. JavaとJavaScriptを混同しないために、提案前に何を確認する？
回答観点: Javaはサーバーサイド・業務システム寄り、JavaScriptはフロントエンド・Node.js寄り。案件で求める言語と実務経験が一致しているか確認する。
8. Java案件で「画面/API/バッチ」のどれを担当したか聞く理由は？
回答観点: 同じJavaでも担当範囲が違うため。画面、REST API、バッチ、DB連携、テストのどこまで経験したかで提案先が変わる。
9. Spring Boot案件とStruts保守案件の違いは？
回答観点: Spring Bootは比較的新しいWeb/API開発で出やすく、Strutsは古い業務システムの保守・既存解析・移行で出やすい。
10. 案件概要にSpring Batchと出た時、何を聞く？
回答観点: バッチ処理の内容、夜間処理やデータ連携の経験、Spring Batch実務、ジョブ設計、エラー時の再実行やログ確認経験。
11 / Summary
まとめ
Java営業の精度は、技術名を覚えることではなく、案件概要の条件をスキルシートと面談で検証し、提案コメントで根拠を添えることで上がります。
案件概要
Java、Spring Boot、工程、業務領域、DB、テスト、クラウド、移行の条件を見る。
スキルシート
年数より、担当工程、担当層、成果物、レビュー、テスト、障害対応の具体性を見る。
登録面談
「経験あり」で止めず、どの機能で何を判断したかまで深掘りする。
提案
不足条件は近い経験で補足し、案件側が安心できる根拠を短く書く。
提案コメント例