トップ > 【英語】オフショアWEB開発でよく使う英語表現・実際の会話例

【英語】オフショアWEB開発でよく使う英語表現・実際の会話例

2015年6月からベトナム・ホーチミン市にて、オフショア開発(web)のPMとして働いています。 ベトナム人開発者に仕様を伝え、開発を管理し進める仕事です。

コミュニケーション手段は

  • redmineなど文章は全て英語で記載する
  • 対面も、英語で話して伝える
  • 複雑な内容のみ、ベトナム人通訳スタッフ(日本語<->ベトナム語)に伝えてもらう

というスタイルで、可能な限り英語で仕事を進めています。

今回は、Web開発で使う英語を知りたいという人向けに記事を書きます。

  1. 毎日の業務でよく使っている表現を、思いつく限りまとめてみました。
    これらの表現できちんと通じて仕事が進んでいるので、一応実戦的なオフショア開発の英語になると思います。

  2. 開発シーンでの実際の英語のやりとりを書きおこしてみました。
    参考になれば幸いです！

1. 開発でよく使う英語表現

specification

仕様。specとも略される。 システムがどのように作られるべきかを定義、規定したもの

  • spec document 仕様書
  • The specification is complicated(complexed). 仕様が複雑だ。

implement

実装する。 仕様が決まった上で、それに沿って「作り上げる」という意味合い。

  • Please implement this function. この機能を実装してください。
  • Do you understand how to implement? 実装のイメージはついていますか？

design

設計する。designの1単語だけだと設計という意味が伝わらないので、後ろに目的語を付ける

  • design DB scheme DB設計する(直訳だとデータベーススキーマをデザインする)
  • design classes and methods クラスやメソッドの設計をする

architecture も設計という意味だが、それに加え「そのように設計された思想・理念」という意味も含む。設計思想。アーキテクチャ。

execute

実行する。ターミナルで打ち込むコマンド、SQL文、バッチなど何にでも使える。

  • Chef-solo will be executed in the server. chef soloがサーバーで実行される
  • I executed SQL to the production DB. 本番DBに対してSQLを実行しました

wrap

システム(APIなど)が別のシステムの受け口となっている。ラップしている。

  • The API wraps the search engine, so you don't have to understand how the search engine works precisely, you can just concentrate on how you use API.
  • APIが検索エンジンをラップしているので、検索エンジンの細かい挙動について完全に理解する必要はありません、APIを(仕様通りに)使うことに集中してください。

take time

(問題を解決するのに)時間がかかる。

  • I took time to introduce capistrano. capistranoを導入するのに時間がかかりました。

solve

(問題を)解決する

  • I took time to solve the issue(problem). 問題を解決するのに時間がかかりました。

see

システムがDBなどを見ている、そちらに向いている

  • This app sees staging DB, not production DB. このアプリは本番DBではなくステージングDBを向いています。

〜 so that S can V

SがVできるように〜する
この構文はかなり使える。

  • Please fix so that the number of items is displayed correctly. 商品の数が正しく表示されるよう、修正してください。
  • Please update wiki so that every developer can understand the spec of the system. 開発者全員がシステムの仕様を把握できるよう、wikiを更新してください。

work

システムが想定された通りに正しく動く。

  • I deployed to staging environment, but it's not working. Please check.
  • ステージング環境にデプロイしたけど正しく動いていません。確認お願いします。

make sure

(念のため、きちんと)確かめる。
システムのテストのときによく使われる。

  • Please make sure that it works in the staging server. ステージング環境で正しく動くことをきちんと確かめて下さい。

want 人 to V

人にVして欲しい。
この構文もよく使う。
would like (= want) で、マイルドにした言い方になる。

  • I want him to solve this problem. 彼にこの問題を解決して欲しい。
  • I would like you to understand the spec. あなたに、仕様をきちんと理解してほしい。

2. 実録：開発シーンでのやりとり

最後に、開発での実際のやりとりがどんなものなのか、書きたいと思います。

状況

  • ECサイトの管理画面、csvファイルの商品アップロード機能を開発中
  • 商品追加でDBのトランザクションが使われているが、トランザクション中に実行されるクエリが多すぎてテーブルロックがかかり、DBが重いという問題がおきている
  • サーバータイムアウトが発生し、アップロードに失敗する状況
  • その解決方法についてskypeで話し合っている

Aさん(日本人PM)の発言

I think too many queries are executed in one transaction.
I think transaction should be used like this:

BEGIN
only 2 or 3 queries
COMMIT or ROLLBACK

to avoid the lock in DB for a long time but we don't have enough time to fix all...

B-san, please tell me your opinion about this issue.

(和訳)

1つのトランザクションでクエリの実行数が多すぎると思います。
トランザクションはこのように使われるべきだと思います:

BEGIN
2つか3つのクエリ
COMMIT か ROLLBACK

DBで長時間のロックが発生しないようにするためです
でもこれを全部直す時間はないですね...

Bさん、この件について意見を聞かせてください。

Bさん(ベトナム人開発者)の返信

For Big Task vs Server Performance - issue, generally there are 2 approaches:

  1. Split the work into small parts
  2. Put the task into background process, and report the result asynchronously with the call.
  3. Increase hardward configuration (timeout, memory, cpu..) <--- worst case, not use.
大きなタスク vs サーバーパフォーマンスの問題は、概して2つのアプローチがあります:

1. タスクを小さなパーツに分割する
2. タスクをバックグラウンドプロセスとして実行し、終了したら結果を非同期に通知する
3. ハードウェアの設定をあげる(タイムアウト、メモリ、CPUなど) <-- 最悪のケースのみ、使わない

We are thinking on approach 1. Split the work.

a) Split on server:
Like what you said, BEGIN insert 5 products COMMIT
If user insert 100 products, and it failed at product 11, i.e the first 10 products are committed,
we can send back to user the file contain list of 90 products that is not added.
They will update the file and upload those 90 products again.

But this does not solve the 'timeout problem'.
The browser still wait for a long time to see the result, and it will be time out if number of products increase.

我々はアプローチ1をとります。1.タスクを分割する方法です。

方法a) サーバー側で分割する
あなたがさきほど言っていたように、 BEGIN、5つの商品を追加、そしてCOMMITします。
もしユーザーが100商品追加して、11商品目で処理失敗したとき、つまり10商品がコミットされたとき
追加されなかった90商品のリストのファイルをユーザーに送り返せます。
ユーザーはファイルを修正し、再度90商品をアップロードできます。

しかしこの方法では「タイムアウト問題」は解決されません。
ブラウザが結果を長時間待つことは変わりなく、商品数が増えればタイムアウトが起こります。

We need
b) Split on client (browser):
javascript parse the csv file, and split into many parts,

100 products = 20 parts x 5 products.

Javascript will ajax submit each part into server, and get the result instantly for each part.
It will report interactively to user.

For example:
5 products upload successfully
5 products upload failed
5 products upload successfully
5 products upload failed
5 products upload successfully
5 products upload successfully
....

Then finally it let user download the report, will all the failed product, for them to upload again.

我々が必要なのは
方法b) クライアント(ブラウザ)側で分割する です。
JavaScriptでcsvファイルをパースし、多くのパーツに分割します。

100商品 = 20パーツ x 5商品

JavaScriptは各パーツをサーバーへAjaxで送り、各パーツについてすぐに(処理が成功か失敗の)結果を得ます。
結果はすぐにユーザーに通知されます。

例えばこのような表示です:
5商品アップロード成功
5商品アップロード失敗
5商品アップロード成功
5商品アップロード失敗
5商品アップロード成功
5商品アップロード成功
...

最終的にユーザーが失敗した商品をダウンロードできるようにして、再度アップロードできるようにします。

Aさん(日本人PM)からの返信

Plan b) sounds good.
It's also good that we don't have to fix PHP logic of uploading so much.

Would you start implementing in plan b? If you need, you can assign task to me, ○○-san or ○○-san.

方法b) は良さそうですね。
PHP側のアップロードロジックをそんなに修正しなくて済むというのもよいですね。

方法b)で実装を始めてもらえますか?
必要なら、私や○○さん、xxさんにタスクを割り振ってください。

Bさん(ベトナム人開発者)からの返信

Yes, A-san
I'll start implement. I'm preparing the environment

はい、Aさん
実装を開始します。環境の準備をしています。