得意分野が全く違う
Go＝高速・大規模なバックエンド、Ruby＝WebサービスをすばやくつくるRails、Python＝Webからデータ分析・AIまで幅広い。
00 / First Map
まず押さえる4点
細かい技術を覚える前に、次の4点を頭に入れておく。ここを外すと、後の章をどれだけ読んでも提案がぶれる。
経験ありを分解する
見るべきは年数ではなく、実務か個人学習か、担当工程、フレームワーク、領域。年数は最後に見る補助情報。
言語名だけで合わせない
Python経験あり→AI案件、Ruby経験あり→Rails即戦力、Go経験あり→高負荷API、はいずれも典型的な誤マッチ。
周辺スキルが左右する
DB、SQL、クラウド、Docker、Git、CI/CD、テスト、チーム開発経験が採用可否と単価を大きく左右する。
Figure 01 / 営業が案件をさばく 4 ステップ
01 / Why
この教材の目的
Go / Ruby / Python を扱う案件に対して、新人SES営業が「自分で判断できる」状態になることを目的にする。
営業が判断を間違えなければ、ミスマッチは大幅に減る
エンジニアのように書けるようになる必要はない。案件概要を見て「これは何をする案件か」「どのレベルの人材を求めているか」を読み取り、スキルシートで実務レベルか個人学習かを見分ける。
登録面談では経験の中身を引き出し、候補者のレベル感を △ / ○ / ◎ で大まかに判断する。提案時には「言語名が同じだから出せる」という思い込みを避ける。
営業向け結論
最終的に答えるべき問いは「この人を、どの案件になら自信を持って提案できるか」。言語・領域・工程・周辺スキルから根拠を持って言える状態を目指す。
02 / Overview
Go / Ruby / Python の全体像
3言語を「特徴」「使われやすい案件」「評価されやすい人材」「営業が混同しやすいポイント」の4軸で整理する。
高速・大規模なバックエンド
- Googleが開発した比較的新しい言語。処理が速く動作が軽い
- API、マイクロサービス、クラウドネイティブ、高負荷処理で使われやすい
- API設計、並行処理、Docker / Kubernetes / GCP・AWS経験が評価される
- 経験者の母数が少ないため、実務か学習かで中身の差が大きい
Rails中心のWebサービス
- 日本生まれで読み書きしやすい。Railsとほぼセットで語られる
- Webサービスの新規開発、既存Railsサービスの保守・運用・機能追加で多い
- Rails実務、DB設計、SQL、RSpec、運用改善経験が評価される
- 新規開発経験と保守経験は別物。Rails即戦力かを分けて見る
Webからデータ・AIまで広い
- 文法がシンプルでライブラリが豊富。用途が極めて広い
- Web API、データ分析、AI / 機械学習、業務自動化、バッチ処理で使われる
- Web系、データ系、AI系で必要スキルが別物
- Python経験あり＝AI人材ではない。まず領域を確定させる
Figure 02 / 3言語の主戦場マップ
3言語ざっくり比較
スマホでは表を横にスクロールできます。
| 観点 | Go | Ruby | Python |
|---|---|---|---|
| 強み | 速度・並行処理・大規模 | Web開発の速さ（Rails） | 用途の広さ（Web〜AI） |
| 代表案件 | API・マイクロサービス・基盤 | RailsのWebサービス | Web API・データ分析・AI・自動化 |
| 経験者の数 | 少ない（希少） | 中（既存Railsサービスの保守・追加開発では今も見かける。案件文脈を分けて見る） | 多い（ただし領域がバラバラ） |
| 営業の最大注意点 | 経験の「中身」の差が大きい | 新規か保守かを分ける | まず「領域」を確定する |
03 / Frameworks
代表的なフレームワーク
フレームワークは、言語と領域を絞り込むヒント。案件では「言語＋フレームワーク」のセットで募集されることが多い。
Gin
GoでAPI・Webサーバーを作る定番フレームワークの一つ。軽量で高速。案件概要にGinとあれば、ほぼGoでのAPI／バックエンド開発。
Echo
Ginと並ぶGoの代表的なWeb／APIフレームワーク。現場の好みで採用が分かれる。GinかEchoかの細かい違いは営業が判断する必要はない。
Ruby on Rails
Rubyの事実上の標準。Ruby案件はほぼRailsとセット。RubyとRailsを分けて確認するのが鉄則。
Django
Pythonの全部入りWebフレームワーク。管理画面・認証・DB連携などが揃い、業務システムや大きめのWebサービス向き。
Flask
軽量・シンプルなPython Webフレームワーク。小規模なWebアプリ、API、社内ツールに向く。
FastAPI
近年人気が高いAPI開発向けPythonフレームワーク。データ系・AI系サービスのAPI部分にもよく使われる。
新人向けポイント
- Gin / Echo → Go の API・バックエンド
- Rails → Ruby の Webサービス
- Django / Flask / FastAPI → Python の Web・API。Pythonでもデータ／AIではなくWeb寄りの合図
04 / Keywords
案件でよく出るキーワード
意味を厳密に覚える必要はない。「これが出てきたら何を確認すべきか」が分かればよい。
開発するもの
API開発バックエンドWebサービスマイクロサービス業務システム
処理の性質
高負荷処理バッチ処理データ分析AI / 機械学習業務自動化
基盤・インフラ
クラウドネイティブDockerAWS / GCP / AzureCI/CD
開発の土台
SQLGitテスト
必須 / 尚可の読み分け
案件概要にこれらのキーワードが「必須」で並んでいるか「尚可」で並んでいるかを必ず見分ける。必須は妥協できない条件、尚可は「あれば加点」。この区別を読み違えると、通らない人を強く推したり、通る人を見送ったりする。
05 / Case Patterns
よくある案件パターン
代表的な8パターンを、案件概要で見るポイント／提案しやすい人材／注意すべき人材／面談で確認すべきことの4軸で整理する。
Figure 03 / 「Python経験あり」の正しい読み方
スマホでは表を横にスクロールできます。
| 案件パターン | 案件概要で見る点 | 提案しやすい人材 | 注意すべき人材 | 面談で確認 |
|---|---|---|---|---|
| GoのAPI開発 | Gin / Echo、API設計か既存API改修か、想定トラフィック、GCP/AWS | GoでのAPI実務、API設計・DB・クラウド経験 | 学習レベルの小さなツール、Go未経験の他言語API経験者 | どんなAPIを設計から作ったか、並行処理、DB・クラウドの担当範囲 |
| Goのマイクロサービス | マイクロサービス、Kubernetes、コンテナ、サービス間連携 | 分割構成、Docker / Kubernetes / クラウド経験者 | モノリスのみ、コンテナ未経験 | サービス分割、Kubernetesの担当範囲、他サービス連携・障害対応 |
| Rails新規開発 | 新規開発、0→1、サービス立ち上げ、設計から任されるか | Rails新規開発、DB設計、要件をくみ取る力 | 保守・運用のみ、Rails経験が浅い人 | 新規設計・構築、DB設計、仕様が固まらない状態での動き方 |
| Rails保守 | 保守、運用、機能追加、改修、既存サービスの規模・歴史 | 既存コード改修、テスト、運用経験者 | 新規志向が強すぎる人、Rails実務が浅い人 | 既存コード改修、他人のコード読解、障害対応 |
| Python Web API | Django / Flask / FastAPI、API、バックエンド | Python WebフレームワークでAPI・バックエンド実務、DB・SQL経験 | データ分析・自動化のみ、スクリプトのみ | どのフレームワークで何を作ったか、DB設計、Web開発工程 |
| Pythonデータ分析 | データ分析、集計、可視化、BI、pandas、SQL | データ加工・集計・可視化、SQL、統計基礎 | Web開発だけ、簡単な集計スクリプトだけ | データの種類、分析目的、SQL・加工経験、示唆出し |
| Python自動化・バッチ | 業務自動化、RPA的処理、定期バッチ、データ連携、スクレイピング | 定型業務の自動化・バッチ経験者 | 規模の大きい案件に浅い経験だけで出すケース | 自動化した業務、規模、定期実行・エラー時対応、外部連携 |
| 他言語からの提案 | 言語不問、キャッチアップ前提、他言語経験者歓迎の記載 | 設計力・基礎が固いJava/PHP経験者、学習意欲を実績で示せる人 | 未経験言語の必須案件に確認なしで出すケース | 対象言語の学習状況、制作物、過去の設計・工程経験、キャッチアップ見立て |
06 / Skill Sheet
スキルシートの読み方
Go / Ruby / Python 経験者のスキルシートは、言語名と年数だけ見ると必ず誤判断する。
11観点チェックリスト
- 言語経験年数だけで判断しない
- 実務経験か個人学習かを確認する
- フレームワーク経験を見る
- 担当工程を見る
- API開発経験を見る
- DB設計・SQL経験を見る
- クラウド経験を見る
- Docker / Git / CI/CD 経験を見る
- テスト経験を見る
- チーム開発経験を見る
- 保守運用経験を見る
読み方のコツ
スキルシートは「言語名 → フレームワーク → 工程 → 周辺スキル（DB/クラウド/Docker/CI/CD/テスト） → チーム/保守 → 最後に年数」の順で見る。年数から見ると判断を誤る。
Python 3年 / FastAPI・Django
- 領域
- 業務システムのWeb API開発。データ分析やAIではなくWeb寄り。
- 工程
- API設計、実装、テスト、運用まで担当。要件定義は一部補助。
- 周辺
- PostgreSQL、SQL、AWS、Docker、Git、CI/CDをチーム開発で使用。
- 判定
- Python Web API案件には強い。データ分析案件には別途経験確認が必要。
実務か個人学習か
Goは経験者が少ないため、学習用の小さなツールと本格バックエンドの差が大きい。
Railsと工程
Ruby経験ではなくRails実務を見る。新規開発か保守かで提案先が変わる。
最初に領域を確定
Web、データ分析、AI、業務自動化は別スキルとして読む。
07 / Interview
登録面談で確認すべき質問
面談は、スキルシートに書かれた経験の中身を確かめる場。答えの具体性で実務度を判断する。
共通質問
- 直近の案件で、その言語をどの工程で使ったか
- そのシステムは何をするもので、利用者は誰か
- チーム人数と自身の役割
- DB、SQL、Git、Docker、テストコード、クラウドの経験
Go経験者向け
- API、マイクロサービス、ツール、学習用のどれか
- 設計から担当か、既存改修中心か
- Gin / Echo、goroutine、Docker / Kubernetes / クラウドの担当範囲
- 経験が浅い場合は習得方法と個人制作物
Ruby / Rails経験者向け
- 新規開発と保守・運用のどちらが中心か
- DB・テーブル設計を担当したか
- 既存コード改修、障害対応、RSpecの経験
- サービスを育てる改善・機能追加の経験
Python経験者向け
- Web開発、データ分析、AI、業務自動化のどの領域か
- Web系はフレームワークとAPI内容
- データ系はデータ内容、目的、SQL、分析結果の活用
- AI系はモデル、データ前処理、運用。自動化系は業務規模
スキルチェンジ人材向け
- 得意言語と、そこでの設計・開発経験
- 対象言語をどのくらい学習・実務で触れているか
- 個人制作物、学習成果物、キャッチアップ見立て
- これまでの経験のうち、新しい言語でも活かせる部分
08 / Level
レベル判定 △ / ○ / ◎
△＝弱く読むべき経験、○＝提案しやすい経験、◎＝強く提案できる経験。案件の難易度と照らして使う。
Figure 04 / 回答の深さで見る △ ○ ◎
Go
スマホでは表を横にスクロールできます。
| 判定 | 経験の状態 |
|---|---|
| 個人学習・スクールでGoを触った程度。小さなツールを作っただけで、実務での使用が確認できない。 | |
| 他言語の経験は豊富だが、Goは学習レベル。言語不問・キャッチアップ前提なら検討可。 | |
| GoでAPI・バックエンドを実務開発した経験があり、DB・Gitを実務で使っている。 | |
| Goでの開発に加え、Docker・クラウドの経験を併せ持つ。 | |
| Goでマイクロサービス・高負荷処理を設計から担当。Kubernetes・クラウド・CI/CDまで実務経験がある。 |
Ruby（Rails）
スマホでは表を横にスクロールできます。
| 判定 | 経験の状態 |
|---|---|
| Rubyは触ったがRailsの実務経験が無い／浅い。個人学習中心。 | |
| Railsの保守・運用のみで、設計・新規開発の経験が無い。保守案件なら○寄り。 | |
| Railsで実務開発の経験があり、DB・SQL・Gitを実務で使っている。 | |
| Railsで新規開発または継続的な機能追加を担当。テストも書いている。 | |
| Railsで新規サービスを設計から構築。DB設計・テスト・運用・チーム開発まで一通り経験がある。 |
Python
スマホでは表を横にスクロールできます。
| 判定 | 経験の状態 |
|---|---|
| 業務の片手間で簡単なスクリプト・自動化を書いた程度。領域が曖昧。 | |
| Python学習はしたが、対象案件の領域（Web／データ／AI）の実務経験が無い。 | |
| 対象領域（Web／データ／自動化のいずれか）で実務経験がある。SQL・Gitを使っている。 | |
| Web系ならフレームワークでAPI開発、データ系なら実務での分析・加工経験がある。 | |
| 対象領域で設計から運用まで担当。Web系はAPI設計＋DB＋クラウド、データ／AI系は分析設計＋示唆出し／モデル運用まで経験がある。 |
09 / Mismatch
営業がやりがちなNG提案
現場で実際に起きやすいミスマッチ。どれも「言語名や肩書きだけで判断した」ことが原因。
Figure 05 / 言語名の一致 ≠ 提案可
共通する教訓
NG提案はすべて「言語名・年数・肩書きだけで決めた」ことが原因。提案前に「この経験は、この案件で本当に通用するか？」を一度問い直す。
提案前に止まるチェック
スマホでは表を横にスクロールできます。
| よくあるNG | なぜ危ない | 提案前に確認 |
|---|---|---|
| Python経験ありだけでAI人材と判断 | Pythonの大半はWeb・自動化・データ用途。AI/機械学習は別スキル。 | 機械学習の実務経験、データ前処理、モデル構築・運用。 |
| Ruby経験ありだけでRails即戦力 | RubyとRailsは分けて見る。Rails実務がなければ即戦力にならない。 | Railsの記載、担当工程、DB設計、テスト経験。 |
| Go経験ありだけで高負荷APIへ提案 | Go経験は学習レベルから大規模実務まで幅が広い。 | 実務か、設計か改修か、高負荷・並行処理の経験。 |
| 個人学習のみのGoを即戦力扱い | Goは経験者が少なく、個人学習レベルが混ざりやすい。 | 本番システムでの使用箇所、チーム開発、レビュー経験。 |
| Java / PHP経験者を確認なしにGoへ提案 | 設計力があっても、Go実務必須なら通らない場合がある。 | 言語不問・キャッチアップ前提か、Go学習状況、制作物。 |
| Rails保守だけの人を新規設計へ強く提案 | 保守と新規は別物。設計・0→1の経験が無いとズレる。 | 新規設計、DB設計、本人の志向。 |
| 簡単なPythonスクリプト経験をデータ分析扱い | 「Pythonが書ける」と「データ分析ができる」は別。 | 分析実務、SQL、可視化、示唆出し、統計理解。 |
10 / Practice
案件読解演習
案件と候補者を読んで、提案できるか・できないか、その理由、面談で何を追加確認するかを考える。
Java経験5年、Goは独学半年の候補者
案件概要・必須/尚可
- 自社WebサービスのバックエンドをGoで開発・改修
- Gin使用、GCP上で稼働、アクセス数が多い
- 必須: GoでのAPI開発実務経験 / SQL / Git
- 尚可: GCP / Docker / 高負荷処理
候補者プロフィール
- 30歳。Javaで業務システム5年
- Goは半年前から独学
- 個人で簡単なAPIツールを作成
- 実務でのGo使用経験は無し
問い: この候補者をそのまま強く提案できるか。面談で何を追加確認するか。
回答を見る
提案可否は△。必須のGo API実務を満たしていない。Javaでの設計力は材料になるが、高負荷・安定稼働重視の案件でGo実務未経験はリスクが高い。案件側が他言語経験者・キャッチアップ可か、個人制作物の中身、Javaでの設計・API経験の具体度を確認する。可能ならポテンシャル枠として制作物を添えて打診する。
Rails保守3年、新規設計は少ない候補者
案件概要・必須/尚可
- 稼働中のRails製Webサービス、運用7年
- 保守・機能追加・障害対応
- 必須: Rails実務 / 既存コード改修 / Git
- 尚可: RSpec / AWS
候補者プロフィール
- 28歳。Railsで自社サービス運用・保守3年
- 既存コード改修、バグ修正、小さな機能追加が中心
- 新規の設計経験は少ない
問い: 保守案件として提案できるか。面談で何を確認するか。
回答を見る
提案可否は◎。保守案件としては好相性。必須のRails実務と既存コード改修を満たす。新規設計より、既存コードを読んで安全に直す力が重要な案件と合う。障害対応、テスト、チーム開発の進め方、長期運用サービスへの抵抗感を確認する。
Django経験2年、データ分析は未経験の候補者
案件概要・必須/尚可
- 小売企業の販売データを分析し、売上改善の示唆を出す
- pandas・SQLを多用、レポート・可視化
- 必須: Pythonデータ分析実務 / SQL / 可視化
- 尚可: 統計 / BIツール / クラウド上のデータ基盤
候補者プロフィール
- 26歳。PythonでWeb API開発（Django）2年
- データ分析は業務未経験
- 独学でpandasを少し触ったことがある
問い: Python経験者としてデータ分析案件に提案できるか。提案先をどう考えるか。
回答を見る
提案可否は△〜×。PythonのWeb開発経験は豊富だが、案件が求めるのはデータ分析の実務。同じPythonでも領域が違う。本人がデータ分析方向にキャリアチェンジしたいか、学習状況と成果物を確認する。基本はPython Web API案件でこそ強く提案できる人材として切り替える。
11 / Proposal
提案コメント例
ポイントは、対象言語・フレームワークの実務経験、担当工程と周辺スキル、懸念があれば正直に添えること。
提案時の注意点
- 言語・フレームワーク → 工程 → 周辺スキル → 人物像の順で書く
- 経験していないことは書かない
- 懸念がある場合は、隠さず「キャッチアップ前提でのご提案」と添える
12 / Check
確認テスト
選択式・○×式・記述式・ケース判断を混ぜた確認テスト。各問に回答と解説を付ける。
研修後にできてほしいこと
言語名だけで判断せず、領域・工程・フレームワーク・周辺スキルから提案可否を説明できる状態。
Q1. 「高速・並行処理・大規模なバックエンドやマイクロサービス」で最も使われやすい言語はどれか。
A. Ruby
B. Go
C. Python（データ分析用途）
回答: B. Go。Goは速度・並行処理・大規模処理に強く、API・マイクロサービス・クラウドネイティブ系で使われやすい。
Q2. 「Python経験あり」と書かれていれば、AI / 機械学習案件に提案して問題ない。
回答: ×。Pythonの用途はWeb・自動化・データ・AIと幅広い。AI案件に出すには機械学習の実務経験を別途確認する。
Q3. Ruby案件は、実質的にほとんどが Ruby on Rails 案件である。
回答: ○。RubyはRailsとほぼセットで使われる。ただしRails経験の深さと工程は分けて確認する。
Q4. Go案件のスキルシートで、最も注意して確認すべきなのはどれか。
A. 年数
B. 実務か個人学習か
C. 好きな言語か
回答: B。Goは経験者が少なく、個人学習レベルが混ざりやすい。年数より実務で使ったかの確認が重要。
Q5. 案件概要に「Django」「FastAPI」とある。これはどの領域の案件と読むのが妥当か。
回答: PythonのWeb / API開発。Django・FastAPI・FlaskはPythonのWeb／APIフレームワーク。
Q6. Railsの保守経験しかない人を、新規サービスの設計案件に強く提案するのは適切である。
回答: ×。保守と新規設計は求められる力が違う。設計・0→1の経験を確認する。
Q7. 「Python 3年」とだけ書かれていた。確認すべきことを3つ挙げよ。
回答例: どの領域で使ったか、実務か個人学習かと担当工程、フレームワーク・DB・クラウドなど周辺スキルの有無。年数だけでは判断できない。
Q8. 「GoでのAPI開発実務2年、GCP・Docker経験あり」の候補者を高負荷Go（Gin）API案件に提案できるか。
回答例: 提案できる（○〜◎）。必須のGo API実務を満たし、GCP・Dockerも備える。高負荷経験まであれば◎。面談で並行処理・高負荷経験を確認する。
Q9. 「PythonでWeb API開発（Django）3年。データ分析は未経験」の候補者をデータ分析案件に提案したい営業へどう助言するか。
回答例: 強く出すべきでない。同じPythonでもWeb開発とデータ分析は別領域。Python Web API案件に提案先を切り替えるよう助言する。
Q10. モダンな開発現場で、無い場合に個人学習レベルを疑う材料になりやすいものはどれか。
A. ゲーム開発
B. Git / Docker
C. デザイン
回答: B。GitとDockerはチーム開発の現場でほぼ前提。記載が無い場合は実務経験の薄さを疑う材料になる。
Q11. JavaのベテランをGo案件に提案する際、面談前に営業がやっておくべきことは？
回答例: 案件側が他言語経験者歓迎／キャッチアップ前提かを確認し、候補者のGo学習状況・制作物、Javaでの設計・API経験を整理する。
Q12. 案件概要で「必須スキル」と「尚可スキル」を読み分ける必要はなく、すべて同じ重みで判断してよい。
回答: ×。必須は妥協できない条件、尚可は加点要素。読み違えると通らない人を強く推したり、通る人を見送ったりする。
13 / Summary
まとめ
新人営業が必ず持ち帰るべきポイント。提案前に「この経験は、この案件で本当に通用するか？」を問い直す。
案件概要
Go / Ruby / Python は同じグループに見えて用途が全く違う。案件の領域を最初に読む。
スキルシート
言語名・年数・肩書きだけで判断しない。実務か学習か、工程、フレームワーク、領域を見る。
面談
Pythonは領域を確定。Rubyは新規か保守か。Goは実務か個人学習かを必ず分ける。
提案
DB / SQL / クラウド / Docker / Git / CI/CD / テスト / チーム開発 / 保守が採用可否と単価を左右する。
顧客に送れるコメント例