用語集
業務でよく使う用語をまとめました。「聞いたことはあるけど説明できない」状態を解消するために活用してください。
業務別：まず押さえたい用語
「自分の業務に関係する用語」から覚えましょう。すべてを一度に覚える必要はありません。
実装（コーディング）がメインの場合
| 優先度 | 用語カテゴリ | 特に重要な用語 |
|---|---|---|
| 最優先 | プログラミング | 変数、関数、引数、戻り値、例外、スタックトレース |
| 最優先 | バージョン管理 | コミット、プッシュ、プル、ブランチ、PR、マージ |
| 最優先 | 開発工程 | 詳細設計、実装、単体テスト |
| 重要 | 環境 | ローカル環境、開発環境、本番環境、ビルド |
| 重要 | テスト | 正常系、異常系、テストケース |
テスト実施がメインの場合
| 優先度 | 用語カテゴリ | 特に重要な用語 |
|---|---|---|
| 最優先 | テスト | テストケース、テスト仕様書、正常系、異常系、境界値 |
| 最優先 | 開発工程 | 単体テスト、結合テスト、システムテスト |
| 重要 | 環境 | 開発環境、ステージング環境、本番環境 |
| 重要 | その他 | バグ、回帰テスト |
設計に関わる場合
| 優先度 | 用語カテゴリ | 特に重要な用語 |
|---|---|---|
| 最優先 | 開発工程 | 要件定義、基本設計、詳細設計 |
| 最優先 | データベース | テーブル、カラム、主キー、外部キー |
| 重要 | WebAPI | API、エンドポイント、リクエスト、レスポンス |
| 重要 | プログラミング | クラス、インスタンス |
Web系（フロント/バック）の場合
| 優先度 | 用語カテゴリ | 特に重要な用語 |
|---|---|---|
| 最優先 | WebAPI | API、JSON、HTTPメソッド、ステータスコード |
| 最優先 | バージョン管理 | Git操作全般、PR |
| 重要 | セキュリティ | 認証、認可、XSS、SQLインジェクション |
| 重要 | インフラ | CI/CD、デプロイ、ログ |
業務システム（Java/C#等）の場合
| 優先度 | 用語カテゴリ | 特に重要な用語 |
|---|---|---|
| 最優先 | データベース | SQL、SELECT、INSERT、UPDATE、DELETE、トランザクション |
| 最優先 | 開発工程 | 詳細設計、単体テスト、結合テスト |
| 重要 | プロジェクト管理 | チケット、ステータス、マイルストーン |
| 重要 | 環境 | 本番環境、ステージング環境 |
インフラ・運用の場合
| 優先度 | 用語カテゴリ | 特に重要な用語 |
|---|---|---|
| 最優先 | インフラ | サーバー、SSH、ログ、アラート |
| 最優先 | 環境 | 開発環境、ステージング環境、本番環境 |
| 重要 | インフラ | CI/CD、デプロイ、監視 |
| 重要 | セキュリティ | 認証、認可 |
この用語集の使い方
重要度の見方
| 重要度 | 意味 | 目安 |
|---|---|---|
| ★★★ | 必須 | 1ヶ月目から毎日のように使う・聞く |
| ★★☆ | 重要 | 3ヶ月以内に理解しておきたい |
| ★☆☆ | 知識 | 聞いたときに「何のことか」分かればOK |
学び方のコツ
- すべてを暗記しようとしない：必要なときに調べられればOK
- 実務で出てきたら深掘り：「今日聞いた用語」を1つずつ理解していく
- 先輩に聞く：「〇〇って何ですか？」は恥ずかしくない質問
用語詳細
| 用語 | 重要度 | 説明 | 補足 |
|---|---|---|---|
| 要件定義 | ★★☆ | 「何を作るか」をお客様と決める工程。機能一覧や業務フローを作成する | 直接参加は少ないが、決まった内容を読んで理解する機会がある |
| 基本設計 | ★★☆ | 画面や機能の「見た目・動き」を決める工程。外部設計とも呼ぶ | 画面設計書を見ながら実装することが多い |
| 詳細設計 | ★★★ | プログラムの「中身の処理」を決める工程。内部設計とも呼ぶ | 詳細設計書を読んで実装するのが1年目の主な仕事 |
| 実装 | ★★★ | 設計書をもとにプログラムを書く工程。コーディングとも呼ぶ | 1年目のメイン業務 |
| 単体テスト（UT） | ★★★ | 作った機能を1つずつテストする工程 | 自分が書いたコードのテストを担当する |
| 結合テスト（IT） | ★★☆ | 複数の機能を組み合わせてテストする工程 | テスト実施や不具合修正で関わる |
| システムテスト（ST） | ★☆☆ | システム全体が要件通りに動くかテストする工程 | 見学程度のことが多い |
| リリース | ★★☆ | 完成したシステムを本番環境に導入すること。デプロイとも呼ぶ | 手順書に沿って作業する、または見学する |
| 保守 | ★☆☆ | リリース後のシステムを維持・改善する作業 | 不具合対応や小さな改修で関わることがある |
| ウォーターフォール | ★★☆ | 要件定義→設計→実装→テストと順番に進める開発手法。大規模・堅い案件で多い | SIer・受託開発で採用されることが多い |
| アジャイル | ★★☆ | 短い期間で「作る→確認→改善」を繰り返す開発手法 | Web系・スタートアップで採用されることが多い |
| スクラム | ★★☆ | アジャイルの代表的な手法。役割・イベント・成果物が決まっている | スプリント、デイリースクラムなどの用語とセットで覚える |
| スプリント | ★★★ | 1〜4週間の開発サイクル。「今スプリント」「次スプリント」のように使う | 「このスプリントで何をやるか」を意識して動く |
| デイリースクラム | ★★★ | 毎日15分程度の短いミーティング。朝会とも呼ぶ | 「昨日やったこと」「今日やること」「困っていること」を報告 |
| バックログ | ★★☆ | やるべきタスクの一覧。優先順位がついている | 「バックログから次のタスクを取る」という形で仕事を進める |
| スプリントレビュー | ★☆☆ | スプリント終了時に成果物を確認する会 | 自分の成果をデモする機会になることも |
| レトロスペクティブ | ★☆☆ | スプリント終了時の振り返り会。「KPT」形式で行うことが多い | チームの改善に意見を出す機会 |
| チケット | ★★★ | タスクや課題を管理する単位。Jira、Redmine、Backlogなどで管理 | 「このチケットお願い」と言われたら、そのタスクを担当する |
| ステータス | ★★★ | チケットの状態（未着手→作業中→レビュー中→完了など） | 作業の進捗に合わせてステータスを更新する |
| マイルストーン | ★★☆ | プロジェクトの重要な節目・目標日 | 「〇〇マイルストーンまでに完了」という期限を意識する |
| WBS | ★☆☆ | 作業を細かく分解した一覧表 | 自分の担当タスクがWBSのどこに該当するか確認する |
| ガントチャート | ★☆☆ | タスクのスケジュールを横棒グラフで表したもの | 全体のスケジュール感を把握するのに使う |
| 変数 | ★★★ | データを入れておく「箱」のようなもの | `userName = "田中"` の `userName` が変数 |
| 関数/メソッド | ★★★ | 処理をまとめたもの。引数を受け取り、結果を返す | `calculateTotal(price, quantity)` のような形 |
| 引数（ひきすう） | ★★★ | 関数に渡す値 | 上の例では `price` と `quantity` が引数 |
| 戻り値/返り値 | ★★★ | 関数が返す結果 | `return total` で返される値 |
| クラス | ★★☆ | データと処理をまとめた「設計図」 | `User` クラスから `user1` インスタンスを作る |
| インスタンス | ★★☆ | クラスから作成した実体（オブジェクト） | `new User()` で作られたもの |
| 配列/リスト | ★★★ | 複数のデータをまとめて扱うもの | `[1, 2, 3]` や `["りんご", "みかん"]` |
| ループ | ★★★ | 処理を繰り返すこと | `for`文、`while`文など |
| 条件分岐 | ★★★ | 条件によって処理を分けること | `if-else`文、`switch`文など |
| 例外（Exception） | ★★★ | プログラム実行中に発生するエラー | エラーログで「Exception」と出たら要注意 |
| スタックトレース | ★★★ | エラーが発生するまでの処理の流れを示したもの | どこでエラーが起きたかを特定するのに使う |
| null/undefined | ★★★ | 「値がない」ことを表す | NullPointerExceptionは最もよくあるエラーの1つ |
| 構文エラー（Syntax Error） | ★★★ | 文法の間違いによるエラー | カッコの閉じ忘れ、セミコロン忘れなど |
| 実行時エラー（Runtime Error） | ★★☆ | 動かしてみて初めて発生するエラー | 0での割り算、存在しないファイルへのアクセスなど |
| リポジトリ | ★★★ | コードを保存・管理する場所 | 「リポジトリをクローンして」→ コードをダウンロードする |
| クローン（clone） | ★★★ | リポジトリをローカルにコピーすること | 新しい案件に入ったら最初にやる作業 |
| コミット（commit） | ★★★ | 変更を記録すること | 「意味のある単位でコミットする」が基本 |
| プッシュ（push） | ★★★ | ローカルの変更をリモートに送ること | コミットしただけでは共有されない。プッシュが必要 |
| プル（pull） | ★★★ | リモートの変更をローカルに取り込むこと | 作業前に「プルして最新化」が習慣 |
| ブランチ | ★★★ | 作業を分岐させること | 「featureブランチを切って作業する」 |
| マージ | ★★★ | ブランチを統合すること | 作業が終わったらmainブランチにマージする |
| コンフリクト | ★★☆ | 同じ箇所を別々に変更して衝突すること | 解消方法を覚えておく必要がある |
| プルリクエスト（PR） | ★★★ | マージを依頼すること。レビューを受ける単位 | 「PR出しました」→ レビューお願いします |
| レビュー | ★★★ | 他の人にコードを確認してもらうこと | PRを出したらレビューを待つ |
| テーブル | ★★★ | データを格納する「表」 | Excelの表をイメージすると分かりやすい |
| レコード/行 | ★★★ | テーブルの1件のデータ | ユーザーテーブルの「1人分のデータ」 |
| カラム/列 | ★★★ | テーブルの項目 | 「名前」「メールアドレス」などの項目 |
| 主キー（Primary Key） | ★★☆ | レコードを一意に識別する列 | ユーザーIDなど。重複しない値 |
| 外部キー（Foreign Key） | ★☆☆ | 他のテーブルを参照する列 | 注文テーブルの「ユーザーID」など |
| SQL | ★★★ | データベースを操作する言語 | SELECT、INSERT、UPDATE、DELETEが基本 |
| クエリ | ★★★ | データベースへの問い合わせ | 「クエリを投げる」= SQLを実行する |
| SELECT | ★★★ | データを取得するSQL | 最もよく使う。まずこれを覚える |
| INSERT | ★★☆ | データを追加するSQL | 新規登録処理で使う |
| UPDATE | ★★☆ | データを更新するSQL | 編集処理で使う。WHERE句を忘れると大事故 |
| DELETE | ★★☆ | データを削除するSQL | WHERE句を忘れると全件削除。要注意 |
| トランザクション | ★★☆ | 複数の操作をまとめて扱う仕組み | 「全部成功」か「全部失敗」かを保証する |
| API | ★★★ | プログラム同士がデータをやり取りする仕組み | 「このAPIを呼び出してデータを取得する」 |
| REST API | ★★☆ | APIの設計スタイルの1つ。HTTPメソッドを使う | GET、POST、PUT、DELETEでCRUD操作 |
| エンドポイント | ★★★ | APIのアクセス先URL | `/api/users/123` のような形式 |
| リクエスト | ★★★ | APIへの要求 | 「こういうデータをください」という依頼 |
| レスポンス | ★★★ | APIからの応答 | 要求に対する返答データ |
| JSON | ★★★ | データ交換フォーマット。`{"name": "田中"}` の形式 | APIのやり取りはほぼJSON形式 |
| HTTPメソッド | ★★☆ | リクエストの種類（GET/POST/PUT/DELETE） | GET=取得、POST=作成、PUT=更新、DELETE=削除 |
| ステータスコード | ★★★ | APIの結果を示す3桁の数字 | 200=成功、400=リクエスト不正、404=見つからない、500=サーバーエラー |
| ヘッダー | ★★☆ | リクエスト/レスポンスの付加情報 | 認証トークンやContent-Typeなど |
| テストケース | ★★★ | 「何を」「どうやって」「どうなればOKか」を記載したもの | テストケースに沿ってテストを実施する |
| テスト仕様書 | ★★★ | テストケースをまとめた文書 | これを見ながらテストを進める |
| 正常系 | ★★★ | 想定通りの入力でのテスト | 「普通に使ったら動くか」を確認 |
| 異常系 | ★★★ | 想定外の入力でのテスト | 「おかしな入力をしたらどうなるか」を確認 |
| 境界値 | ★★☆ | 範囲の境界でのテスト | 「0〜100」なら、-1、0、1、99、100、101をテスト |
| 回帰テスト | ★★☆ | 修正後に他の機能に影響がないか確認するテスト | 「直したら別のところが壊れた」を防ぐ |
| 単体テスト（ユニットテスト） | ★★★ | 関数やメソッド単位のテスト。コードで書くことが多い | 自分のコードにテストを書く |
| 結合テスト | ★★☆ | 複数の機能を組み合わせたテスト | 画面から操作して確認することが多い |
| ローカル環境 | ★★★ | 自分のPCの環境 | 自由に実験できる。壊しても影響なし |
| 開発環境（dev） | ★★★ | 開発チームが共有する環境 | 他の人も使っているので、壊すと迷惑をかける |
| ステージング環境（stg） | ★★☆ | 本番に近い確認用環境 | 本番リリース前の最終確認に使う |
| 本番環境（prod） | ★★★ | 実際にユーザーが使う環境 | **絶対に慎重に**。ミスは許されない |
| IDE | ★★★ | 統合開発環境。Visual Studio、IntelliJなど | エディタ+デバッガ+ビルドツールがセット |
| ビルド | ★★★ | ソースコードを実行可能な形に変換すること | 「ビルドエラー」が出たら動かない |
| デプロイ | ★★☆ | アプリを環境に配置すること | 「開発環境にデプロイする」など |
| 認証（Authentication） | ★★★ | 「あなたは誰か」を確認すること | ログインで「本人確認」をする |
| 認可（Authorization） | ★★★ | 「何ができるか」を制御すること | ログイン後に「この機能を使える権限があるか」を判断 |
| セッション | ★★☆ | ログイン後の状態を維持する仕組み | ログアウトするとセッションが切れる |
| トークン | ★★☆ | 認証情報を表す文字列 | APIアクセス時にヘッダーに付けて送る |
| XSS | ★★☆ | Webページに悪意のあるスクリプトを埋め込む攻撃 | ユーザー入力を画面に表示する際に注意 |
| SQLインジェクション | ★★☆ | SQL文を不正に操作する攻撃 | ユーザー入力をSQLに埋め込む際に注意 |
| CSRF | ★☆☆ | ユーザーになりすまして操作を行う攻撃 | フォーム送信時にトークンで防ぐ |
| サーバー | ★★★ | サービスを提供するコンピュータ | 「サーバーにSSHで接続する」など |
| クラウド | ★★☆ | インターネット経由で利用するコンピュータ資源 | AWS、Azure、GCPなどが代表的 |
| オンプレミス | ★☆☆ | 自社で管理するサーバー環境 | クラウドの対義語として使う |
| コンテナ | ★☆☆ | アプリと依存関係をまとめた実行環境 | Dockerで作る。「コンテナを起動する」 |
| SSH | ★★☆ | サーバーに安全に接続するプロトコル | ターミナルからサーバーに入るときに使う |
| CI（継続的インテグレーション） | ★★☆ | コード変更時に自動でビルド・テストする仕組み | PRを出すと自動でテストが走る |
| CD（継続的デリバリー/デプロイ） | ★★☆ | 自動でリリース可能な状態にする仕組み | mainブランチにマージすると自動デプロイ |
| パイプライン | ★☆☆ | ビルド→テスト→デプロイの自動化フロー | 「パイプラインが失敗した」= ビルドかテストがエラー |
| ログ | ★★★ | システムの動作記録 | エラー調査のとき最初に見る |
| 監視（モニタリング） | ★☆☆ | システムの稼働状況を監視すること | 異常があればアラートが飛ぶ |
| アラート | ★★☆ | 異常を検知して通知すること | 「アラートが鳴った」= 何か問題が起きた |
| 障害対応 | ★★☆ | システムに問題が発生したときの対応 | 1年目は先輩のサポート役から始める |
| バグ | ★★★ | プログラムの不具合 | 「バグを見つけた」「バグを直す」 |
| デバッグ | ★★★ | バグを見つけて修正すること | 開発者の重要なスキル |
| リファクタリング | ★★☆ | 動作を変えずにコードを改善すること | 読みやすく、保守しやすくする |
| レビュー | ★★★ | 他者にコードや成果物を確認してもらうこと | PRレビュー、設計レビューなど |
| 技術的負債 | ★☆☆ | 将来の開発効率を下げるコードや設計 | 「負債を返す」= リファクタリングする |
| PoC | ★☆☆ | 技術検証。実現可能性の確認 | 「まずPoCをやってみよう」 |
| オンボーディング | ★☆☆ | 新メンバーがチームに慣れる過程 | 「オンボーディング資料」など |
1年目のポイント（バージョン管理）：`clone` → `branch作成` → `commit` → `push` → `PR作成` の流れを体で覚える。詳しくは Gitの基礎 を参照。
1年目のポイント（データベース）：UPDATE/DELETEは本番環境で絶対に直接実行しない。必ずテスト環境で確認してから。詳しくは データベースの基礎 を参照。
1年目のポイント（テスト）：「正常系」だけでなく「異常系」「境界値」もテストする習慣をつける。詳しくは テストの進め方 を参照。
用語を覚えるコツ
1. 実務で出てきた用語から覚える
すべてを事前に覚えようとせず、今日聞いた用語を1つずつ理解していきましょう。
2. 先輩に聞く
「〇〇って何ですか？」は恥ずかしい質問ではありません。分からないまま進めるほうが問題です。
3. 自分の言葉で説明してみる
用語を覚えたら、誰かに説明できるか試してみましょう。説明できれば本当に理解しています。
4. 関連する用語をセットで覚える
- Git関連：clone → branch → commit → push → PR → merge
- テスト関連：正常系・異常系・境界値
- 工程関連：設計 → 実装 → テスト → リリース
さらに学びたい人へ
| 分野 | 学ぶべき追加用語 | 学習リソース |
|---|---|---|
| Web系 | DOM、SPA、SSR、Webpack | MDN Web Docs |
| データベース | 正規化、インデックス、JOIN | SQLチュートリアル |
| インフラ | Kubernetes、Terraform、マイクロサービス | 各クラウドのドキュメント |
| セキュリティ | OWASP Top 10、ペネトレーションテスト | OWASP公式サイト |
1年目のポイント：この用語集の「★★★」と「★★☆」を理解していれば十分です。焦らず、着実に語彙を増やしていきましょう。