翻訳を学んだ私が、フロントエンドエンジニアになるまで

私は「エンジニアになろう」と決めて勉強を始めたわけではありません。大学で翻訳を学び、大阪でカスタマーサポートの仕事に就き、マーケティングに移りました。そこでチームにツールが必要になって仕事でコードを書くようになり、続けているうちに、コードを書くこと自体が仕事になっていました。

プログラミングスクールに通って転職した話に比べると地味ですが、実はこちらの方がよくある道で、真似もしやすいと思っています。

ここまでの経緯

2012年から2015年まで、ブエノスアイレスの大学で文芸・専門翻訳を専攻し、その後の1年間はブエノスアイレス大学の語学センターで日本語を教えていました。麻雀の解説記事を翻訳したり、オンライン麻雀「天鳳」の英語版に関わったりもしていましたが、どれもコードを書く仕事ではありません（せいぜい、自分の麻雀の成績を集計する小さなPythonスクリプトを書いたくらいです）。

2016年に大阪へ移り、2017年に、日本の商品を海外へ届ける越境ECサービスのZenMarketにカスタマーサポートとして入社しました。あまりそうは言われませんが、カスタマーサポートはエンジニアの学校としてかなり優秀です。実際のユーザーが製品のどこでつまずくのかを毎日見ることになり、何がいつ起きたのかを正確に言葉にする練習にもなるからです。

2018年にマーケティングに移り、2019年からはマーケティングディレクターとして、多国籍のチームで12市場向けの多言語マーケティングを統括し、広告運用も担当していました。コードが仕事の一部になったのは、この頃です。チームにツールが必要だったので、JavaScript、Node.js、Google Apps Scriptで社内向けのマーケティングツールを作り、それ以外はZapierで自動化しました。

その後、ReactとTypeScriptを学びました。スクリプトを書くのとは、また別のスキルです。スクリプトは動けば十分ですが、コンポーネントは次にそのコードを開いた人が読んで分かるものでなければいけません。2021年5月にシナジーマーケティングにフロントエンドエンジニアとして入社し、企業向けCRM・マーケティングSaaSの本番UIをReact（Next.js）、TypeScript、Angularで開発していました（リリースはGitLab CI/CDです）。同じ年のうちにVercelへ移り、それからはずっとカスタマーサクセスの仕事をしています。今もコードは書いていて、その話は別の記事にまとめました。

最初は自分のチームのためのツールから

練習台として一番いいのは社内ツールだと思います。理由は地味で、ユーザーがいるからです。チュートリアルで作ったアプリは壊れても誰も困りませんが、週次レポートを作るスクリプトが止まれば、その日の朝に誰かが言いに来ます。エラー処理も、想定外のデータへの対応も、使い方のメモ（せめて「このボタンを押してください」というコメント）も、必要に迫られて身につきます。チームに「毎週手作業でやっていることは何ですか」と聞いて、一番地味な答えを選び、それを作ってください。

チームがGoogleスプレッドシートで仕事をしているなら、最初のツールはこのくらい小さくて構いません。言語ごとに列が分かれた原稿シートを読んで、翻訳が抜けている言語を書き出すだけのスクリプトです。

// Google Apps Script。「Copy」シートの列：key, en, ja, es, missing
const LANGS = ["en", "ja", "es"]

function flagMissingTranslations() {
  const sheet = SpreadsheetApp.getActive().getSheetByName("Copy")
  const [header, ...rows] = sheet.getDataRange().getValues()
  if (rows.length === 0) return

  const cols = LANGS.map((lang) => header.indexOf(lang))
  const out = header.indexOf("missing") + 1 // getRange は1始まり

  const result = rows.map((row) => [
    LANGS.filter((_, i) => String(row[cols[i]]).trim() === "").join(", "),
  ])

  // 1セルずつではなく、列ごとまとめて1回で書き込む
  sheet.getRange(2, out, result.length, 1).setValues(result)
}

20行ほどですが、データの読み込み、ループ、そして1セルずつではなくまとめて書き込むこと（Apps Scriptで誰もが最初に学ぶ、パフォーマンスの基本です）が一通り入っています。そして何より、来週の月曜にはチームの誰かが使ってくれます。

翻訳の経験がエンジニアの仕事に役立つ理由

エンジニアの経歴に「翻訳専攻」とあると、何か説明が必要な部分に見えるかもしれません。でも私は、むしろ逆だと思っています。

正確さ

英文の契約書では、「shall」と「may」で義務の重さが変わります。日本語として自然に読めても、そこを曖昧にした訳は誤訳です。翻訳者は用語集を作って、同じ用語には必ず同じ訳語を当てます。これはコードの命名とまったく同じです。デザインでは「会員」、APIではcustomer、画面では「ユーザー」と呼び方がばらばらだと、いつか誰かがそれを別物だと思って（あるいは別物なのに同じだと思って）バグを生みます。

文脈

翻訳で最初に教わるのは、文脈のない文は訳せない、ということです。「よろしくお願いします」には決まった英訳がありません。誰が誰に、どんな場面で言うかで変わります。フロントエンドにも同じ問題があります。翻訳ファイルに「Open」とだけ書いてあれば、翻訳者はそれがボタン（開く）なのか、お店の状態（営業中）なのかを推測するしかありません。翻訳をやったことのあるエンジニアは、そこに一言メモを残します。ローカライズについては別の記事で詳しく書いています。

曖昧さ

原文が二通りに読めるとき、翻訳者が取れる手はいくつかあります。片方を選んで注記する、クライアントに確認する、両方の意味が残る訳を探す（これはめったにうまくいきません）。やってはいけないのは、黙って片方を選ぶことです。「注文日を表示する」というチケットも同じ問題を抱えています。どのタイムゾーンでの日付なのか、書かれていないからです。二通りの解釈を書き出して、作る前に確認する。手間はほとんどかからないのに、手戻りが何日分も減ります。

仕様書を読む力

専門翻訳で扱うのは、契約書やマニュアル、技術文書です。第1条の定義が第12条の意味を決めるような文書なので、最初の一文を訳す前に全体を読む癖がつきます。APIリファレンスやRFC、仕様書の読み方もまったく同じです。手を動かす前に一度通して読み、疑問点を書き出しておきます。

日本でキャリアチェンジしたい人へ

見せる

チュートリアルを写経しただけのポートフォリオから伝わるのは、手順通りに作れるということだけです。同僚5人が毎日使っているツールが1つあれば、課題を見つけて形にし、壊れても直して動かし続けられる人だと伝わります。ただ、社内ツールは社外の人から見えません。ダミーデータで作り直してGitHubに置き、どんな課題を解決して誰が使っていたのかをREADMEに書いて、採用担当者がクリックして触れる場所にデプロイしましょう。長い説明文より、スクリーンショットと2分ほどの画面録画の方がよく伝わります。会社の実データは載せないでください。

履歴書と職務経歴書

日本の会社が求める書類は、たいてい2つです。学歴・職歴・資格を決まった形式で書く履歴書は、アピールの余地があまりありません。キャリアチェンジで差がつくのは、形式が自由な職務経歴書の方です。2つの書き方は、コピーして使える骨組みも含めて日本で働くことについての記事にまとめました。ここでは、キャリアチェンジの人に向けたポイントだけ書きます。

技術に関わる仕事を先に書きましょう。エンジニア以外の職歴でも、自分で作ったツールは「プロジェクト」として書きます。課題、使った技術、誰が使っていたか。言語・フレームワーク・ツールのスキル欄を作り、習熟度は正直に書いて、GitHubのリポジトリ、デモのURL、自分のサイトへのリンクを載せます。

前職を隠さないでください。サポートやマーケティング、翻訳の経験は、コードしか書いてこなかった候補者にはない業務知識です。それで何ができるのかを書きましょう。

そして、求人票の「実務経験」の一言で諦めないこと。同僚が業務で頼っていたツールは、肩書きがエンジニアでなくても、コードを書いた実務経験です。具体的に書いて、判断は読む側に任せましょう。