アプリ開発の英語語彙｜MVP・User Story・Sprint をマスター
最終更新: 2026-05-24
目次
本記事はアフィリエイト広告を含みます。
「Let's groom the backlog before sprint planning.」「This is a P0 bug.」── 外資系・グローバルチームのアプリ開発現場で日常的に飛び交う英語語彙を、プロダクト・Agile プロセス・実装・QA・リリースの 5 場面に整理します。エンジニア・PM・デザイナーが英語環境で生き残るための実戦語彙集です。
プロダクト定義の英語：MVP / User Story / Persona
新規アプリ開発の初期段階で頻出する語彙です。要件定義・仕様策定の会議で迷わないために押さえます。
プロダクト初期の中核語彙
- MVP (Minimum Viable Product) — 検証可能な最小機能セット。「とりあえず出して反応を見る」段階の製品
- Prototype — 動作する試作。コードが入っているとは限らない
- PoC (Proof of Concept) — 技術的に実現可能か確認するための試作
- Feature — 機能。日本語の「機能」とほぼ同義
- Requirement — 要件。Functional / Non-functional に分かれる
- Spec / Specification — 仕様書。PRD と近い意味
- PRD (Product Requirements Document) — プロダクト要件書
- Persona — 想定ユーザー像
- Use case — ユーザーが製品を使う具体的なシナリオ
User Story の書き方
User Story は As a [persona], I want [action], so that [benefit]. の型で書きます。
- As a busy parent, I want to save grocery items to a list, so that I can reorder them with one tap.
- As a finance manager, I want to export reports as CSV, so that I can share them with stakeholders.
会話例
- Let's scope the MVP down to the core flow.（MVP の範囲をコアフローに絞ろう）
- This feature doesn't have a clear user story yet.（この機能はまだ User Story が固まっていない）
Agile / Scrum プロセスの英語：Sprint / Backlog / Stand-up
Scrum / Agile で運営されるチームでは、儀式 (ceremonies) の名称と意味を共通言語として共有します。
Agile / Scrum の主要語彙
- Agile — 反復的な開発手法の総称
- Scrum — Agile の代表的フレームワーク
- Sprint — 2 週間程度の反復単位
- Sprint planning — スプリント開始時の計画会議
- Sprint review — スプリント末のデモ・成果確認
- Retrospective / Retro — 振り返り会議
- Daily stand-up — 毎日の短時間進捗共有
- Backlog — 未着手のタスク一覧
- Backlog grooming / Refinement — Backlog の整理・優先度付け
- Story point — 作業量の相対見積もり単位
- Velocity — チームのスプリントごとの平均消化量
- Epic — 複数 Story にまたがる大粒度の仕事
- Ticket / Issue — Jira / Linear などのタスク単位
Stand-up での 3 つの定型質問
- What did you do yesterday?（昨日やったこと）
- What are you doing today?（今日やること）
- Any blockers?（ブロッカーはありますか）
会話例
- I'm blocked on the API spec from the backend team.（バックエンドの API 仕様待ちで止まっています）
- Let's move this ticket to next sprint.（このチケットは次のスプリントに回そう）
- Our velocity has been dropping for three sprints.（直近 3 スプリントは velocity が落ちている）
実装・コードレビューの英語：Pull Request / Merge / Refactor
エンジニアが GitHub / GitLab 上で日常的に使う語彙です。コードレビューの場面では英語表現の的確さがレビュー速度を左右します。
Git / GitHub の基本語彙
- Repository / Repo — リポジトリ
- Branch — ブランチ
- Commit — コミット
- Pull Request / PR — 変更提案。GitLab では Merge Request (MR)
- Merge — ブランチ統合
- Rebase — ブランチ起点の付け替え
- Conflict — マージ衝突
- Revert — 変更を取り消し
- Cherry-pick — 特定コミットだけ別ブランチに取り込む
コードレビューで使う頻出表現
- LGTM (Looks Good To Me) — レビュー OK
- Nit / Nitpick — 些細な指摘。必須対応ではない
- Blocking comment — マージを止めるべき指摘
- Refactor — リファクタリング
- Edge case — 境界値ケース
- Code smell — 問題の兆候があるコード
- Tech debt (Technical Debt) — 技術的負債
レビューコメントの定型
- Could we extract this into a helper function?（ヘルパー関数に切り出せますか）
- Nit: typo in the variable name.（細かい点：変数名にタイポ）
- What happens if user input is empty?（ユーザー入力が空の場合はどうなる？）
- This looks good overall, but I'd love a unit test for the new logic.（全体は良いが、新ロジックの単体テストが欲しい）
QA・バグ管理の英語：Bug Triage / Severity / Reproducibility
テスト・QA フェーズで頻出する語彙です。バグの優先度付け会議 (bug triage) で評価軸を共有するために必須です。
バグの基本属性
- Bug — 不具合
- Defect — 仕様からのズレ。Bug よりフォーマルな表現
- Issue — 不具合を含む課題全般
- Severity — 深刻度。S1 / S2 / S3 や Critical / High / Medium / Low
- Priority — 対応優先度。P0 / P1 / P2 など。Severity と独立
- Reproducibility — 再現性。Always / Sometimes / Rare
- Repro steps — 再現手順
- Expected behavior — 期待される動作
- Actual behavior — 実際の動作
Bug triage の流れ
- Triage — 優先度付け会議
- Won't fix — 修正しない判断
- Cannot reproduce — 再現できない
- Duplicate — 既存チケットと重複
- By design — 仕様通り。バグではない
- Workaround — 暫定回避策
- Root cause — 根本原因
- RCA (Root Cause Analysis) — 根本原因分析
会話例
- This is a P0 — we need to ship a fix today.（これは P0、今日中に修正リリース必須）
- I can't repro this on iOS.（iOS で再現できない）
- Let's mark this as won't fix for now.（一旦 Won't fix にしよう）
- We need a workaround until the fix lands.（修正が入るまでの回避策が必要）
リリース・運用の英語：Release / Rollback / Hotfix
リリースとその後の運用で使う語彙です。本番障害時の即応にも直結する重要セットです。
リリース手段の語彙
- Release — リリース
- Deploy / Deployment — デプロイ
- Rollout — 段階展開
- Canary release — 一部ユーザーへの先行リリース
- Feature flag — 機能切替フラグ
- A/B test — 2 つの実装を比較するテスト
- Dogfooding — 自社プロダクトの社内利用
- Beta release — ベータ公開
- GA (General Availability) — 一般公開リリース
障害対応の語彙
- Incident — 障害
- Outage — サービス停止
- Downtime — 停止時間
- SLA (Service Level Agreement) — サービス品質保証
- SLO / SLI — サービス品質目標 / 指標
- Hotfix — 緊急修正リリース
- Rollback — 直前バージョンへの戻し
- Postmortem — 障害後の振り返り報告
- On-call — オンコール当番
- Pager / Page — オンコール呼び出し
会話例
- We're rolling out the new feature to 5% of users.（新機能を 5% にロールアウト中）
- Let's roll back to the previous version.（前バージョンに戻そう）
- Who's on-call this weekend?（今週末のオンコール担当は？）
- We need a postmortem by end of week.（週末までに postmortem が必要）
ロール別の語彙：Engineer / PM / Designer
役割ごとに頻出する語彙が異なります。チームメンバーの肩書きを正確に理解すると、誰に何を相談すべきか判断が早くなります。
エンジニア系
- Frontend / Backend / Full-stack engineer — フロント / バックエンド / 両方
- Mobile engineer (iOS / Android) — モバイル担当
- DevOps / SRE (Site Reliability Engineer) — インフラ・運用信頼性
- QA engineer / SDET (Software Development Engineer in Test) — テスト自動化担当
- Tech lead — 技術リード
- Staff / Principal engineer — シニアエンジニアの上位ランク
- EM (Engineering Manager) — エンジニアのピープルマネジメント
プロダクト・デザイン系
- PM (Product Manager) — プロダクトマネージャー
- TPM (Technical Program Manager) — 技術寄りの進行管理
- Designer / UX designer / UI designer — デザイナー
- Product designer — UX + UI を兼ねるデザイナー
- UX researcher — ユーザー調査担当
- Product analyst / Data analyst — データ分析担当
ロール間で使う頻出表現
- Can you take a look at this design and flag any technical concerns?（このデザインを見て技術的懸念を教えて）
- I need PM input on the priority of these two features.（この 2 機能の優先度に PM の意見が欲しい）
- Let's loop in the designer before we ship this.（リリース前にデザイナーを巻き込もう）
使い分けと注意点
1. Bug と Issue の使い分け
"Bug" は実装上の不具合を指す狭い語、"Issue" はバグを含む課題全般を指す広い語です。GitHub の Issue は機能要望もタスクも含むため、"This is a bug" と "This is an issue" は意味が違います。
2. Severity と Priority は独立
Severity (深刻度) は影響の大きさ、Priority (優先度) は対応順序です。「Severity は High だが Priority は Low」も成立します。両者をごっちゃにすると triage 会議で混乱します。
3. Deploy / Release / Rollout の違い
Deploy は「サーバーにコードを置く」行為、Release は「ユーザーに機能を見せる」イベント、Rollout は「段階的にユーザーへ公開する」プロセスです。Feature flag を使うと deploy ≠ release が可能になります。
4. ジャーゴンを多用しない
"Synergy" "Pivot" "Disrupt" など、聞こえはよくても中身が薄い表現は避けます。ビジネス英語ジャーゴン用語集を参照し、具体的な動詞・名詞に置き換える習慣をつけると、コミュニケーションが洗練されます。
アプリ開発英語を実戦投入するための練習プラン
ステップ1：5 場面の語彙を分けて暗記
プロダクト定義 → Agile → 実装 → QA → リリースの順で 5 場面に分けて語彙を覚えます。VocabUpのスワイプ学習で略語と意味の対応を反復し、咄嗟に出る状態を作ります。
ステップ2：Speaking Instant で会話パターンを定着
「I'm blocked on ...」「Let's roll back to ...」「Could we extract this into ...」などの定型句は、考えずに出る必要があります。Speaking Instantの business カテゴリで瞬間英作文を反復すると、本物の Stand-up で詰まらなくなります。
ステップ3：ListenUp で会議スピードに耳を慣らす
外資系の Stand-up は早口かつ略語連発です。ListenUpで英語の早口・音変化・省略に耳を慣らしておくと、リアル会議での聞き逃しが減ります。
ステップ4：オンライン英会話でロールプレイ
講師に「Let's roleplay a sprint planning meeting. You're the PM, I'm an engineer」と頼むのが最も実戦的です。受け放題プランや 5〜10 分の短時間レッスンに対応したサービスなら、平日朝の Stand-up 前にウォームアップとして使えます。
アプリ開発英語を毎日のレッスンで実戦投入
Sprint planning や code review の英語は、語彙を覚えるだけでは本番で動かせません。受け放題プランで毎日 5〜10 分、講師相手に「stand-up ロールプレイ」「PR レビューの説明」を反復すると、本物の会議でも自然に発話できるようになります。
まずは 7 日間の無料体験で、エンジニアの実務に近いロールプレイレッスンを試してみるのがおすすめです。
本記事はアフィリエイト広告を含みます。