レインボー・シックスのシックスは、なぜ指揮官を意味するのか、そのわけ

f:id:habitmaker:20160920081615p:plain

トム・クランシーの小説をベースにした、戦術×FPSというジャンルのゲーム、レインボー・シックス

シリーズ最新作のSiegeが発売されています。

多国籍の特殊部隊である、レインボー(Rainbow、虹)という組織。 レインボー・シックス(Rainbow Six)は、「レインボーの指揮官」という意味になります。

なぜシックス(six、6)が指揮官という意味なのか、調べてみました。

こちらに解答がありました。

http://www.urbandictionary.com/define.php?term=six&defid=419799

six
In military terms, six refers to either the commanding officer in a particular group, since the commander is usually "in the rear" or at the 6-o'clock position compared to the other members of the group. Or it can mean behind you (your 6-o'clock).
1) Bravo-Two, this is Bravo-Six, over? 
2) Check your six!


6
軍事用語において、6は特定の集団の指揮をとる将校を指す、なぜなら指揮官は普通は「背後」におり、つまりチーム内の仲間と比べて6時の方向に位置するからである。もしくは、単に人の背後を指す。(あなたの6時の方向。)
1) ブラボー2へ、こちらブラボー6(指揮官)である、どうぞ。
2) 背後を確かめろ!

なるほど、指揮官は大抵、背後から指示を出すので、背後=6時の方向でシックスなんですねー。

watch your six!で「背後に気をつけろ!」という意味になります。かっこいい表現なので覚えておこう。

ベトナムの社員旅行に参加して感じた、ベトナム人の「素直さ」

ベトナムホーチミン市にあるオフショア開発ラボが参加する、合同の社員旅行に行ってきました。

行き先はベトナムの中部のダラット。 軽井沢のような冷涼な気候でした。

チームビルディングというアクティビティがありました。
100人以上の参加者で

  • 列を作ってダンス
  • バナナボートに人を乗せて、ボールを網の中に入れたら成功
  • 水風船を二人で投げて、キャッチできたら成功
  • 二人三脚
  • カラフルな豆をお皿に貼り付けて、その美しさを競う

のような運動会のような競技を行いました。

もし日本の会社でこのような会をやったら、

  • 「なんでこんな子供みたいなことをやらされるんだ」
  • 「意味が分からない」

のような意見が出て、しらけて誰も真面目にやらないと思います。

しかしベトナム人の社員の人たちは、全力で参加して、本当に楽しそうに上記のような競技を行っていました。

この姿勢はとても衝撃的でした。

用意された環境・ネタに対して、その裏などを考えず、素直に乗っかって楽しむ。

この気質は、日本人の姿勢と対照的に感じました。

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

f:id:yonotown:20151003180341j:plain

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さん
実装を開始します。環境の準備をしています。

ベトナムドン→日本円にすると?【ベトナム出張1日目・食べ物写真あり】

ベトナム出張1日目。

土曜日からスタートで休日ということで、先輩にレタントンを中心にいろいろと案内していただきました。

いろんなものを買いましたが、ベトナムの通貨のドンが日本円でいくらなのかは、まだすぐに分かりません。覚える意味でも書きたいとおもいます。

対応表

現在の為替では、1円 = 175ドン

Left align Right align
5,000ドン 28円
10,000(1万)ドン 57円
20,000(2万)ドン 114円
50,000(5万)ドン 285円
100,000(10万)ドン 571円
500,000(50万)ドン 2857円
1000,000(100万)ドン 5,714円
2000,000(200万)ドン 11,428円

ゼロを3つ取って、5.5を掛けるという覚え方が分かりやすいようです!

朝食で食べたフォー 25,000ドン = 142円

さっぱりしてて、めちゃ美味しかったです。

f:id:yonotown:20150531013254j:plain

スーパーで買ったヤクルト2本 7,200ドン = 41円

あのちっこいプラスチックの入れ物のやつです。日本だと1本80円くらい?

cafe beneのアイスカフェラテ 70,000ドン = 400円

飲んだ後しか撮ってなかった。。こんなに高い価格設定は、ベトナムでは珍しいそうです。外資のカフェだから?

f:id:yonotown:20150531013532j:plain f:id:yonotown:20150531013545j:plain

LGのPCモニター 3,900,000(390万)ドン = 22,285円

f:id:yonotown:20150531014429j:plain

超有名ピザ屋 4P's 700,000(70万)ドン = 4,000円

最高でした。2人分でこの値段、安い。

f:id:yonotown:20150531015914j:plain f:id:yonotown:20150531015931j:plain f:id:yonotown:20150531020300j:plain f:id:yonotown:20150531020328j:plain