1章 はじめに
開発していて、英語のエラーメッセージをとりあえず AI に貼り付けて「解決！動いたからよし！」で済ませていませんか？気付いたら、いつまでも英語に苦手意識を持ったまま…という方も多いはず。
PR のコメントに「LGTM」って書いてあっても「なんか承認されてる気がする」くらいの感覚で流していたり、deprecated の警告を見て「なんか怒られてる？」と思いながら無視していたり…。心当たりがある方もいるんじゃないでしょうか。
この記事では、エンジニアが日々の開発で目にする英語を、場面と例文つきでまとめました。辞書として使うよりも、「あ、この単語ってこういう場面で出てくるやつか」と腑に落ちてもらえるような読み物を目指しています。
今回の基礎編で扱うのは、Git 操作・エラーメッセージ・PR チームコミュニケーションの3カテゴリ、合計18単語です。
一度で覚えようとしなくて大丈夫です。「あの単語なんだっけ？」と思ったときに見返す辞書代わりに使ってもらえると嬉しいです。
各単語の冒頭にある「直訳」は、辞書に基づいた厳密な翻訳ではなく、筆者がニュアンスを汲み取ってまとめたものです。あくまで参考程度に読んでもらえるとありがたいです。
2章 Git 操作まわりの英語
この章では Git の基本的な操作にまつわる英単語を、本当にざっくりと説明しています。
Git そのものの使い方や、GitHub と組み合わせた開発フローについては、近々別の記事で詳しく取り上げる予定です。投稿が完了したらこの記事にもリンクを貼るので、よければ合わせて読んでみてください。
2-1. commit
直訳すると「約束する・確定する」。
Git では、変更をリポジトリに記録する操作のことです。
作業中に「区切りのいいところで保存したい」と思ったときに使います。ファイルを上書き保存するのとは違い、「この時点の状態」をスナップショットとして残すイメージです。
git commit -m "ログイン機能を追加"
コミットメッセージは英語で書くチームも多いですが、日本語でも問題ありません。大事なのは「何をしたか」が一目でわかる内容にすること。fix や add など動詞から始めるのが一般的です。
2-2. merge
直訳すると「合流する・統合する」。
Git では、別々のブランチで進めていた作業を1つにまとめる操作です。
例えば、feature/login ブランチで開発した機能を main ブランチに取り込むときに使います。
git merge feature/login
マージが成功すると、2つのブランチの変更が1つの履歴にまとまります。同じ箇所を別々に編集していた場合は、次の conflict が発生します。
2-3. conflict
直訳すると「衝突・矛盾」。
Git では、マージやリベースのときに同じファイルの同じ箇所を別々に編集していると発生します。
<<<<<<< HEAD
console.log("hello");
=======
console.log("hi");
>>>>>>> feature/greeting
Git が「どっちを採用すればいいかわからない」と手を止めた状態です。
<<<<<<< と >>>>>>> の間を自分で編集して、正しい内容に直してからコミットすることで解消できます。
2-4. rebase
直訳すると「基点を変える」。
Git では、コミット履歴を別のブランチの先頭に移植する操作です。
マージと似ていますが、履歴がきれいに一直線になるのが特徴です。チームによっては「マージよりリベースを使って履歴を整理しよう」というルールを設けていることもあります。
git rebase main
ただし、すでに共有しているブランチでリベースを使うと他の人の履歴と食い違いが生じるので、基本的には自分だけが使っているブランチで使います。
2-5. stash
直訳すると「隠す・こっそりしまう」。
Git では、作業途中の変更を一時的に退避させる操作です。
「急に別のブランチで作業しないといけなくなったけど、今の変更はコミットするほどでもない」というときに便利です。
git stash # 退避する
git stash pop # 退避した変更を戻す
stash はスタック構造になっていて、複数回退避することもできます。ただし積みすぎると何が入っているか分からなくなりがちなので、こまめに pop して使い切るのがおすすめです。
2-6. clone
直訳すると「複製する」。
Git では、リモートリポジトリをまるごとローカルにコピーする操作です。
新しいプロジェクトに参加したときや、自分のPCで初めてそのリポジトリを触るときに使います。
git clone https://github.com/example/repo.git
clone を実行すると、リポジトリの全ファイルとコミット履歴がローカルにコピーされます。GitHub のリポジトリページにある「Code」ボタンから URL をコピーして使うのが一般的です。
各コマンドの詳細や使い方をもっと知りたい場合は、公式ドキュメントも参考にしてみてください。日本語版も用意されています。
3章 エラーメッセージの英語
ターミナルやブラウザの開発者ツールに突然現れる赤い文字、つい身構えてしまいますよね。でも、エラーメッセージは「コンピュータからの困りごと相談」みたいなものです。意味さえわかれば、解決のヒントがほぼ書いてあります。
ここでは、特によく目にする6つを取り上げます。JavaScript のエラーについては MDN が決定版なので、迷ったら参照するのがおすすめです。
3-1. deprecated
直訳すると「非推奨」「廃れた」という意味。
開発の現場では、「将来のバージョンで削除される予定の機能」につけられる警告として登場します。古いライブラリのメソッドや、過去の書き方をそのまま残しているとよく出てきます。
warning: 'componentWillMount' is deprecated and will be removed in a future version.
deprecated の警告が出ても、その瞬間にプログラムが止まるわけではありません。ただし放置していると、ライブラリのアップデートで突然動かなくなる「時限爆弾」になることが多いです。見つけたら、推奨されている代替手段に置き換えておくと安心です。
公式ドキュメントを読むと、「Deprecated since version X.X」のような表記をよく目にします。これは「このバージョン以降は非推奨」という意味で、いつから使わない方がいいかを示しています。
3-2. undefined
直訳すると「定義されていない」。
JavaScript や TypeScript で頻出する値で、「変数は宣言されているけど、まだ何も入っていない状態」や「存在しないプロパティにアクセスした結果」を表します。
let user;
console.log(user); // undefined
const obj = { name: "tanaka" };
console.log(obj.age); // undefined
特によく見るのが Cannot read properties of undefined (reading 'X') というエラー。これは「undefined のものから X を取り出そうとしたよ」という意味で、新人エンジニアなら一度は遭遇する定番です。
オプショナルチェーン（ ?. ）やデフォルト値の指定（ ?? ）で安全にアクセスできるので、合わせて覚えておくと便利です。
3-3. not found
直訳すると「見つかりません」。
Web で最も有名なのは HTTP ステータスコード 404 Not Found でしょう。指定した URL のページやリソースが存在しないときに返ってきます。
それ以外にも、ターミナルで使う場面がたくさんあります。
$ hoge
zsh: command not found: hoge
$ npm start
Error: Cannot find module 'express'
command not found は「そのコマンドが PATH に登録されていない or インストールされていない」、Module not found は「依存パッケージが入っていない」のサインです。npm install や pnpm install を実行し忘れているケースが多いです。
3-4. exception
直訳すると「例外」。
プログラム実行中に発生する「想定外の事態」を指します。ゼロで割り算しようとした、ファイルを開こうとしたら存在しなかった、ネットワークが切れた…といった状況で発生します。
try:
result = 10 / 0
except ZeroDivisionError as e:
print(f"例外をキャッチ: {e}")
例外を try / catch （ Python では try / except ）で囲んで対処することを「例外処理」と呼びます。エラーで落ちる前に「もしダメだったらこうする」と決めておくイメージです。
ちなみに error と exception はよく混同されますが、ざっくり下のような使い分けが一般的です（言語によって厳密な定義は異なります）。
| 用語 | 意味 | 例 |
|---|---|---|
error |
修復できないレベルの致命的な問題 | メモリ不足、スタックオーバーフロー |
exception |
プログラムでハンドリングできる問題 | ゼロ除算、ファイルが見つからない |
3-5. unexpected token
直訳すると「予期しないトークン」。
「予想していなかった記号やキーワードが出てきた」という意味で、構文エラー（ SyntaxError ）の代表格です。
SyntaxError: Unexpected token ')'
このエラーが出たら、ほぼ間違いなくカンマやカッコ、セミコロンの閉じ忘れか、余分な記号です。エラーメッセージに表示されている記号（上の例なら ) ）の周辺をチェックすれば、原因はすぐ見つかります。
ESLint や Prettier などのフォーマッタを導入しておくと、保存した瞬間にこの手のミスを検出してくれるので、unexpected token に悩まされる頻度がぐっと減ります。
3-6. permission denied
直訳すると「権限がありません」。
ファイルやディレクトリ、コマンドの実行に必要な権限がないと出るエラーです。
GitHub に SSH で接続するときに遭遇する人が多いはず。
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.
これは「公開鍵認証で接続しようとしたけど、登録された鍵と一致しないよ」という意味です。SSH 鍵を生成して GitHub に登録し直すと解決します。
その他にも、ファイルに実行権限がない場合は chmod +x ファイル名 で付与する、管理者権限が必要なら sudo を使うなど、UNIX 系 OS の権限まわりの基本知識が役に立ちます。
4章 PR・チームコミュニケーションの英語
GitHub の PR レビューや Slack でのやりとりで、急に出てくる謎の3文字略語…。「みんな当たり前のように使ってるけど自分は意味わかってない」と感じたことがある人も多いはず。
ここで紹介するのは、開発チームのコミュニケーションでほぼ必ず登場する6つです。意味を知っているだけでレビューやチャットの解像度がぐっと上がります。
4-1. LGTM（Looks Good To Me）
直訳すると「私には良さそうに見える」。
PR レビューで「問題なさそう、マージしていいよ」という承認の意思表示として使われます。GitHub の Approve ボタンを押すついでに、コメント欄に LGTM! と書く文化があります。
LGTM! マージしちゃってください
ちなみに、もうちょっと強めに「完璧！」と言いたいときに LGTM 👍 と絵文字を添えたり、 SGTM (Sounds Good To Me) という派生形を使う人もいます。
4-2. WIP（Work In Progress）
直訳すると「作業中」。
「まだ完成してないけど、一旦見せておきたい」「途中経過を共有したい」というときに、PR タイトルの先頭につけて使います。
[WIP] 認証フローのリファクタリング
最近の GitHub には「Draft Pull Request」という公式機能があり、こちらを使うと PR をドラフト状態にできてレビュー依頼前であることが明示できます。WIP プレフィックスより Draft の方を推奨するチームも増えています。
4-3. nit（nitpick）
直訳すると「重箱の隅をつつく・あら探し」。
レビューで「直さなくてもいいけど、一応指摘しておく」レベルの細かい修正提案につけます。
nit: 変数名は camelCase の方が他と揃って読みやすいかも
nit: がついた指摘は「マストで対応する必要はない」というニュアンスを含むので、レビューを受ける側も気軽に流せます。逆に、自分がレビューする側で「重要じゃないけど気になる」ときにこのプレフィックスをつけると、相手にプレッシャーを与えずに伝えられます。
4-4. IMO（In My Opinion）
直訳すると「私の意見では」。
「これは絶対こうすべき」と断定するのではなく、「個人の意見として聞いてください」とトーンを和らげるときに使います。
IMO このロジックは別関数に切り出したほうが読みやすいと思います
似た表現に IMHO (In My Humble Opinion) があります。「謙虚な意見ですが」というさらにソフトな表現で、海外のエンジニアがよく使います。
4-5. FYI（For Your Information）
直訳すると「あなたの情報のために」、つまり「参考までに」。
直接アクションを求めるわけではなく、「知っておいてほしい情報」を共有するときに使います。
FYI このバグ、先月別チームでも発生していたみたいです
（関連 issue のリンク）
Slack やメール、PR コメントなど、あらゆる場面で頻出します。「読んでおいてくれればOK、返事はいらないよ」というニュアンスも含みます。
4-6. TBD（To Be Determined）
直訳すると「これから決定される」、つまり「未定」。
仕様書や設計ドキュメント、タスク管理ツールで「ここはまだ決まってない」と明示するときに使います。
- リリース日: TBD
- 実装方針: TBD（次回ミーティングで議論）
似た表現に TBA (To Be Announced) があります。こちらは「あとで発表する」というニュアンスで、決まってはいるけどまだ公開していないものに使われがちです。
4章で紹介した略語は、海外のエンジニアと働くときにも頻繁に目にします。日本語のチャットでも自然に混ぜて使えるようになると、コミュニケーションのスピードが一段上がります。
5章 おわりに
ここまで読んでいただきありがとうございました。
エンジニアの仕事は、思っているより英語に触れる場面が多いです。エラーメッセージ、ライブラリのドキュメント、海外発のツールのリリースノート、GitHub の Issue やレビュー…。完璧に読めなくても、「なんとなく意味がわかる」状態を作っておくだけで、調査スピードや日々の開発体験が大きく変わります。
最初は知らない単語ばかりでも、繰り返し目にするうちに自然と頭に残っていきます。今回紹介した18単語は、どれも開発の現場で何度も登場するものなので、一度に覚えようとせず、ぜひこの記事をブックマークして、忘れたときに戻ってきてください。