« July 2014 | Main | September 2014 »

手続き型プログラミングっぽいメソッド名

先日出題したクイズを補足説明します。

<問1>Javaプログラミングで「顧客情報のステータスをアクティブにする」メソッドメソッド名称を決める際、英語としての可読性がよい選択肢を1つ選びなさい。

(a) doActive()
(b) setActive()
(c) changeActive()
(d) activate()

結果を見る

クリック得票数は少ないものの、答えはほぼ均等に分散しています。

以下、答えのヒントを解説します。


票を伸ばした選択肢(c) changeActive() について。

学校英語の常識だと「顧客情報のステータスをアクティブにする」の日本人的な英訳は以下のような感じでしょう。

- to change status to active.(冠詞などは無視)


すると、あえて動詞 change を使うなら、changeStatus() がより適切なような気がします。この場合は引数に「アクティブ」を指定する仕様となるので、さらに英語らしさを重視するなら、前置詞 to を付与するとよいでしょう。

changeStatusTo( ACTIVE ); # こんな感じで


選択肢(b) setActive() についても考え方は同様です。


念のため、ここから、オフショア開発に関連する話題にも一応触れておきます。さもないと、本誌は単なる英語学習のメルマガだと誤解されそうなので。


選択肢(d) activate() の主語は、「顧客情報」だとみなせます。すると、いわゆる無生物主語構文(S+V型)であり、如何にも英語的な表現だと言えます。

この発想は典型的な「オブジェクト指向」です。


一方、選択肢(b)や(c)は、英語としては特に問題ありませんが、何となく日本人が発想しがちな表現です。

選択肢(b)や(c)の発想は、前後の文脈にも強く依存しますが、いわゆる「手続き型」プログラミングでありがちな関数のI/F仕様です。


ここでオフショア開発プロジェクトでありがちな場面を想定します。

・海外オフショア委託先の技術者
= 学生時代から Java言語&オブジェクト指向しか知らない

・日本で設計しオフショア委託先にコーディング依頼する技術者
= 入社後にCやVBでプログラミングを学んだ。Javaが主流となった現在も、いまだに手続き型の発想で設計しがち


もし、過去の習慣が身体に染み付いた日本人が changeStatusTo( ACTIVE ) を手続き型プログラミングの発想で設計したなら・・・。

このような設計に不本意ながら従わされるオフショア開発委託先の外国人SEは「また Javaで不自然な設計が強要された。これだから日本人は・・・」と陰口を叩いているかもしれません。

こんな話は、まず表沙汰になりませんが、念のため、以下の事情を知っておくとよいでしょう。

・中国オフショア委託先の若い外SEは「日本人の技術力は低い」と心底、信じている(他国の事情については断言できませんが、恐らく、似た感覚だと思います)

・中国オフショア委託先から、日本人による不適切な設計に対して、頻繁に改善提案がなされるものの、大人の事情により、的を射た提案であっても却下されることが多い(全体が手続き型プログラミングの発想で設計されているため、部分最適化しても意味なし。よって提案が却下される結果に)


こんな裏事情も含めて、四択問題の正解や詳細については、来週の第50回オフショア開発勉強会にて解説します。乞うご期待。

■ 問いかけ

<問1>選択肢(b) setActive() を英語らしさを重視して書き換えなさい。もちろん、仕様は「顧客情報のステータスをアクティブにする」である。

<問2>オブジェクト指向系のプログラミング言語なのに、いかにも手続き型っぽい設計やコーディングをしてくるのは?

日本>オフショア委託先(日本が多い、という意味)
日本<オフショア委託先
日本≒オフショア委託先(どちらもよくある)
日本≒オフショア委託先(どちらも少ない)
個人差が大きいので国や地域は関係ない

結果を見る

締切:2014年09月06日18時00分
協力:クリックアンケート http://clickenquete.com/

| | Comments (1)

getData()のコアイメージ

先日の出題を再掲します。

<問1>Javaプログラミングで、出力用データを生成するメソッド名称を決める際、英語としての可読性がよい選択肢を1つ選びなさ い。

(a) createOutputData()
(b) makeOutputData()
(c) どちらも可読性はよい、大差なし

結果を見る

このアンケートに対して、読者からコメントが届きました。

↑の答えは(a)でしょうけど、ファイル等にはきだすのではなく、ただメモリ上に値をもらう場合は、 Get とかもシンプルで良いかと。結局は英語うんぬんよりも、「マイクロソフトとかGoogleとかはどうしているのか」に寄る事も多いですね。(日本人/オフショア経験豊富)


ご意見ありがとうございます。他にも、英語が苦手な日本人SEが犯しがちな英語報告の失敗例も紹介してもらいました。

ファイル等にはきだすのではなく、ただメモリ上に値をもらう場合のメソッド名称として getOutputData() でもいいのではないか、とのご意見について、英単語のコアイメージの観点から補足説明します。


まず、英単語 get のコアイメージについて。

get のコアイメージは「状態変化」です。
決して「取る(ゲットする)」ではありません。

すなわち、get を使う局面では、前提条件として「以前の状態」と「変化後の状態」の二つの要素が暗黙のうちに想定されます。


もし、出力用データを新規生成するメソッド名称を決める際、特に「新規性」に強調するなら get よりも create を使った方がよりイメージが伝わります。

- createOutputData() ... 普通に新規データ生成の印象


一方、重要なアルゴリズムによって「既存データが変換」されて出力用データが生成される際には、make を使うとそれっぽい印象が醸し出せます。

make のコアイメージより「ある原材料に人が手を加えてデータ生成した」印象が強調されます。

- makeOutputData() ... データがわざわざ「作られた」感アリ


一方、getOutputData() を使うと、空っぽの状態だったメモリ空間に、所定の出力用データが移されてメモリ空間が満たされた状態に変化した印象が強調されます。

- getOutputData() ... 何らかの変化? → 普通は取得という!


だからこそ、getOutputData() は「データ生成」よりも「データ取得」の役割がピッタリ当てはまります。英単語 get のコアイメージは「取る(ゲットする)」ではなく「状態変化」だと覚えましょう。


■ 問いかけ

今日も、以下のクイズに挑戦

【課題】あなたは、設計書の指示にしたがって Java 言語でプログラミングします。メソッドや変数を英語で適切に命名しなさい。

<問1>あるルーチン内で、一時的に利用された後すぐに破棄される儚い運命のデータを生成して作業用メモリに保管するメソッドに相応しい名称(例えば、並べ替えアルゴリズムで作業用データを一時的に取得したい場合)

(a) getData()
(b) holdData()
(c) openData()
(d) keepData()


あなたの直感を信じて「これだ!」と思う選択肢をクリックしまし
ょう。結果は後日集計されて、今後のオフショア大學講座に反映さ
れます。ご協力のほど、よろしくお願いいたします。

結果を見る

締切:2014年09月05日18時00分
協力:クリックアンケート http://clickenquete.com/

| | Comments (2)

インターネット接続料金を参照するメソッド

【課題】あなたは、設計書の指示にしたがって Java 言語でプログラミングします。メソッドや変数を英語で適切に命名しなさい。


<問>Javaプログラミングで、最新のインターネット接続料金を参照するメソッド名を決める際、英語としての可読性がよい選択肢を1つ選びなさい。

(a) fee()
(b) cost()
(c) price()
(d) charge()

あなたの直感を信じて「これだ!」と思う選択肢をクリックしましょう。結果は後日集計されて、今後のオフショア大學講座に反映されます。ご協力のほど、よろしくお願いいたします。

結果を見る

締切:2014年09月04日18時00分
協力:クリックアンケート http://clickenquete.com/

| | Comments (1)

お客様IDを格納する変数名

【課題】あなたは、設計書の指示にしたがって Java 言語でプログラミングします。メソッドや変数を英語で適切に命名しなさい。


<問1>Javaプログラミングで、お客様IDを格納する変数名を決める際、英語としての可読性がよい選択肢を1つ選びなさい。

(a) guestID
(b) clientID
(c) visitorID
(d) customerID

あなたの直感を信じて「これだ!」と思う選択肢をクリックしましょう。結果は後日集計されて、今後のオフショア大學講座に反映されます。ご協力のほど、よろしくお願いいたします。

結果を見る

締切:2014年09月04日18時00分
協力:クリックアンケート http://clickenquete.com/

| | Comments (0)

メソッドや変数を英語で適切に命名(アクティブにするメソッド/証拠の配列)

今日も、以下のクイズに挑戦しましょう。

以下の問1と問2、それぞれ英語として可読性がよい選択肢を選びなさい。もし可能なら、他選択肢の問題点を具体的に指摘しなさい。


<問1>「顧客情報のステータスをアクティブにする」メソッド

(a) doActive()
(b) setActive()
(c) changeActive()
(d) activate()

○結果を見る


<問2>デバッグの証拠となる情報を保存する配列(変数名)

(a) evidence
(b) evidences
(c) evidenceInfo

結果を見る


答えは来週のオフショア開発勉強会にて発表します。お楽しみに。

第50回オフショア開発勉強会(9月1日)
・オフショア開発「あるある」四択問題(Part 2)
・オフショア開発クイズ(四択問題)の妥当性検証

| | Comments (0)

メソッドや変数を英語で適切に命名

グローバル英語に関連する軽い挑戦課題をお届けします。


【課題】あなたは、設計書にしたがって Java 言語でプログラミングします。指示にしたがい、メソッドや変数を英語で適切に命名しなさい。


まずは例をご覧ください。


【例】データを取得するメソッド名称を決める際、英語の可読性がよい方の名称を選びなさい。

(a) getData()
(b) takeData()


正解:(a)

手元の電子辞書(連語辞典)によると、dataと相性がいい動詞は、get, acquire, capture, obtain, collect など。

一方、"take"と"data"は、何となく相性がよくない印象です。

例えば、"take data" はデータを集める[gather]とも認識されます。

具体的には、「両手を広げてデータをかき集める」ような動作が頭に思い浮かびます。文脈があるため、(b)でも正しく通じると思いますが、やはり(a)の可読性が一枚上手です。

ちなみに、take による以下の用法もお馴染みかと。

take data to XXX (XXXにデータを送る)


■ 問いかけ

では、以下のクイズに挑戦しましょう。

以下の問1と問2、それぞれ可読性がよい選択肢を選びなさい。同時に、もし可能なら、他の選択肢の問題点を具体的に指摘しなさい。


<問1>出力用データを生成するメソッド名称を決める際、英語としての可読性がよい選択肢を1つ選びなさい。

(a) createOutputData()
(b) makeOutputData()
(c) どちらも可読性はよい、大差なし

結果を見る

締切:2014年09月02日18時00分
協力:クリックアンケート http://clickenquete.com/

<問2>存在を確認するメソッド名称を決める際、英語としての可読性がよい選択肢を1つ選びなさい。戻り値は boolean。

(a) isExist()
(b) hasExisted()
(c) exists()

結果を見る

締切:2014年09月02日18時00分
協力:クリックアンケート http://clickenquete.com/

| | Comments (2)

「なる」は使用禁止

今日は、日本語の「なる」は微妙なニュアンスが伝わりにくいため、できるだけ使わないほうがよいと主張します。背景や事例に興味のない人は、以下の説明を飛ばして、いきなり後半の「問いかけ」にお進みください。

参考過去記事 例文「レビュー指摘数が100件になる」


日本語の「なる」は、主語のない文章でよく用いられて、状況があたかも自然的・自発的に変化したような雰囲気を醸し出します。主体者が明確な動詞「する」の代わりに、「なる」がよく用いられます。


・このたび中国に転勤することになりまして・・・
(このたび私は中国に転勤しますので・・・)

・脱法ドラッグの名称が「危険ドラッグ」になりました・・・
(新名称「危険ドラッグ」に変更しますので・・・)

・(中国納品物へ)仕様エラーになっているようですが
(仕様エラーですが・・・)

・お買い上げは合計1,080円になります。
(1,080円です)


通訳の専門教育を受けていないブリッジSEが、このような「なる」に出くわすと、微妙なニュアンスをうまく翻訳できないことが少なくありません。

なぜなら、上記の四例の「なる」は、いずれも主語/主体をわざとぼかして、状況が自然に「そうなっている」ことを示唆するために使われているからです。

ただし、「なる」を含む上記の例文は全て正しい日本語です。ですから、日本人同士の会話では、これからも安心して使い続けられます。誤解なきよう、お願い致します。


余談ですが、「なる」には尊敬の意味も含まれます。

例「上様のおなり」

→上様の如き高貴の存在は、決して主体的意志によって「来る」のではなく、あたかも果実が実るように忽然と「なる」べきだ。


以上から、日本独特の文化と言葉遣いの留意点が推測できます。

・日本語は、「なる」を使って、動作の主体をわざとぼかし、あたかも状況が自然にそう「なった」と暗示する傾向がある。
・「なる」を使うと、関係者の立場や感情を隠せる
・「なる」を使うと、話し手と聞き手の対立が避けられる
・「なる」を使うと、丁寧さや尊敬のニュアンスを醸しだせる


さて、ここからが、異文化コミュニケーションに役立つ話につながります。いささか常識の部類に属する知識かもしれませんが、ご了承ください。

・英語は、話し手と聞き手は互いの背景を知らない前提
・日本語は、関係者はみなムラ社会に属し文脈を共有している前提

・英語では、I と you を明確に区別する習慣
・日本語では、あえて主語/主体をぼかして状況描写する習慣

・英語では、話し手の主体的な意志を表明する傾向
・日本語では、個人の意志より、状況の自然変化を示す傾向


例えば、冒頭の「このたび中国に転勤することになりまして」をオフショア大學英語講師に英訳させたら、当然のように主語 I を用いました。元の日本語には「私」に相当する言葉は全くありません。


オフショア大學講師は、更にこう補足説明しました。

もし「このたび中国に転勤することになりまして・・・」をより自然な英語に訳すなら、発言者と聞き手の関係を明確化して、発言者の意志や感情を表現したいところ。

例えば、送別会の挨拶であれば、「皆さん大変お世話になった」とか「今夜の送別会に深く感謝する」とか。

あるいは、同期との飲み会で愚痴をこぼす場面なら、「中国に飛ばされて悔しい」とか「あの上司から離れられてせいせいする」など。


ところが、日本語では、あえて自分の意志や背景情報を隠したまま、あたかも運命で定められたように「中国転勤になった」と表現します。聞き手が話し手の心情を察するべきであり、余計な詮索は野暮だ、と考えるのが模範的な日本人ビジネスパーソンの態度ではないでしょうか。


繰り返しますが、日本人同士の会話なら「このたび転勤することになりまして・・・」で十分に会話が成立します。話し手と聞き手は背景情報が十分に共有されている前提なので、あえて「私」の意志や心情を詳しく描写する必要はありません。

もし、日本人が「私」と「あなた」を明確に区別し、「あなた」に向かって「私」の背景をわざわざ話したら、余計な衝突を招く恐れがあります。


以上の観点から日本語と英語は次のように対比できます。

・日本語=モノローグ言語
・英語=ダイアローグ言語


ここで、モノローグ言語とは、対話においてほとんど聞き手を想定しない極めて独自のあり方を示す言語だと定義します。モノローグは一人芝居の意味でも使われます。


日本語の「なる」は、日本語がまさにモノローグ言語であることを示す有力な証拠の1つです。

そうであるがゆえに「なる」は危険です。もし、オフショア開発で「なる」を多用すれば、対話者の外国人に正確な意図が伝わらない恐れがあります。もしかしたら、全く通じないよりも危険な状況かもしれません。

よって、オフショア開発プロジェクトの仕様説明や進捗確認など厳密さが要求される局面では、日本語「なる」をできるだけ使わない方が望ましいでしょう。

最後に、危ない「なる」の例を3つ紹介します。


【危ない「なる」】

レビュー指摘数が100件になった
・先日検討したGUI設計ですが、このように修正となりました
・知識移転の教育費用はオフショア側のご負担になりますが


■ 問いかけ

以下の「ある」が危ない理由を説明しなさい。

<問1>先日検討したGUI設計ですが、このように修正となりました
<問2>知識移転の教育費用はオフショア側のご負担になりますが


以下を微妙なニュアンスを保ったまま英訳しなさい。

<問3>仕様エラーになっているようですが
<問4>先日検討したGUI設計ですが、このように修正となりました

| | Comments (0)

オノマトペを外国語訳する一工夫

大和言葉の一部は、外国語に直訳できません。日本語のオノマトペは、そのほとんどが外国語に直訳できないでしょう。直接原因は言葉の壁ですが、根本原因は明らかに「文化の違い」です。

さらに、大和言葉ではないものの、日本独自の慣用表現も外国語に直訳できません。例えば、「下心がある」や「腹案がある」など。

オフショア大學では、オノマトペや日本的な慣用表現を「正しい日本語」だと認めた上で、外国語に翻訳しやすい別の日本語表現に書き換える訓練方法を提唱します。

この作業を「中間日本語に書き換える」と表現します。


・さっとすませる → 手早く、粒度を荒く、でも網羅的に
・すむ → 修正されたモジュールを単体試験対象に追加する
・下心 → ◯◯◯な意図


このように、いかにも日本的な表現を中間日本語に書き換えるには、行間に隠れた背景=前提条件を的確に言葉で書き表さないといけません。

例えば、前出のオノマトペ「さっと」には、3つの隠された背景があります。もし、作業指示で「さっと」が用いられたら、3つの評価基準が隠されている、と頭の中で即時変換するとよいでしょう。

1)速度
2)粒度
3)網羅性


この3つの評価基準は、状況によって全く異なります。通常、上長から「さっと」と言われたら、(1)対応速度を優先しがちです。ところが、対応箇所に偏りがあると(3)網羅性が犠牲になり、下記事例のように作業指示を満たさない恐れがあります。


●「さっと」が通じない会話例

上司「会議前に机をさっと拭いておいてください」
部下「はーい」

・・・さっとひと拭き

上司「コラ!残った水滴で配布資料が濡れてしまったぞ!」
部下「私は、言われたとおり、さっと拭きました」

上司「机にアイスコーヒーの水滴が残っているから、それを拭いて資料が濡れないようにする。そんなことも気づかないのか!」
部下「すいません」

なお、今日の内容は下記文献をヒントに構成しました。

荒木博之(1994)、日本語が見えると英語も見える、中公新書

■ 問いかけ

<問1>大和言葉「すむ」に対応する漢字を複数挙げなさい。
<問2>大和言葉「すむ」のコアイメージを調べなさい。
<問3>「みる」「とる」「やる」のコアイメージを調べなさい。
<問4>日本的慣用表現「下心」を中間日本語に書き換えて、さらに英訳しなさい。

以下は、大和言葉やオノマトペを語る意義(うんちく)です。興味ないは、読み飛ばしてもらって構いません。


オフショア開発で使われる日本語の会話や文章は、外国人技術者に伝わりにくくて、いつも苦労します。

その原因は以下のように分類されます。

1.そもそも日本語として不適切だから
2.日本語としては適切だが、外国語に翻訳しにくい


2.は更に細かく分類されます。

2-1.言い回しや文章全体が高コンテクストだから
2-2.単語や短い文節レベルで、既に外国語に翻訳しにくいから


2-2.を更に細かく分解します。

2-2-1.業界用語、専門用語、社内や内輪で使う略語
2-2-2.カタカナ外来語の乱用
2-2-3.日本独特の概念を表す言葉


2-2-3.を最後まで分解すると、こうなります。

2-2-3-1.オノマトペ
2-2-3-2.オノマトペ以外の大和言葉
2-2-3-3.それ以外の日本独自の慣用表現

※それなりに知恵を絞って分解したつもりですが、言語学的見地から不適切だ/間違い、などの指摘があるかもしれません。


さて、ここで言葉を定義します。

大和言葉とは、古くから日本列島で用いられる日本固有の言葉です。要するに漢語と外来語をを除いた大半の言葉です。2-2-3.では、外国人には理解しにくい日本独特の概念を表す大和言葉に着目します。

オノマトペとは、擬音語と擬態語を総称するフランス語由来の外来語です。日本語では擬声語(ぎせいご)と言いますが、本誌では語学教育でお馴染みの「オノマトペ」の方を使います。


オフショア開発未経験者が、外国人技術者とのコミュニケーションで生じる「言葉の壁」や「文化の違い」を手っ取り早く体験するには、平仮名で表記される大和言葉と漢字の対応関係を考察するとよいでしょう。


例えば、大和言葉の「とる」「みる」を考察。

・「とる」に相当する漢字は? → 取/摂/採/捕/執/撮
・「みる」に相当する漢字は? → 見/観/診/視/看


このように、一つの大和言葉に複数の漢字が対応します。一体なぜでしょうか。

実は、大和言葉「とる」や「みる」には、それぞれ漢語で表現できる微妙な違いを包含する1つの意味がある、と考えられるからです。

オフショア大學では、「とる」「みる」が持つ言葉の根源的意味をコアイメージと呼んでます。コアイメージは、大和言葉だけではなく全ての言葉に備わっています。日本語だけではなく、英語や中国語にもコアイメージは存在します。


[PR] 詳細はオフショア開発実践セミナーにて

・外国人技術者に向けた文書作成とQ&A連絡の技法
・オフショア開発でよくある失敗事例とその対策
・英語に翻訳しやすく外国人に伝わりやすい日本語


過去、受験英語に真面目に取り組んだ人は、日本と英語で一対一対応しない単語をいくつか知っているでしょう。これまでにも、オフショア開発で使われる以下の事例を紹介しました。

・管理
・責任
・評価


同様に、日本語と中国語で意味が一対一対応しない同形異義語についても、たくさん紹介しました。

・愛人
・大丈夫
・曖昧
・問題

参考:現場で最も誤解を生みやすい同形異義語

| | Comments (0)

ソフトウェア技術者の価値基準6段階

今日はお盆休み気分が抜けないので軽い話題で肩慣らし。

来週から、オフショア大學事務局を運営する関連会社で、大学3年生を対象にインターンシップ・プログラムを実施します。具体的には、ソフトウェア業界をまるで知らない学生らにスタッフのカバン持ちをさせながら、社会人の空気を感じてもらいます。

私はオフショア大學を代表して、学生の就活に役立つ社内講座を受け持ちます。講座では、学生の関心が高い項目に絞り込み、かつ、ネットや書籍では得られない現場の生の感覚を学生にお届けします。


●日本人ソフトウェア技術者の価値

とりあえずインターンシップに挑戦したものの、ソフトウェア業界の実態を全く知らない学生に向けて、ソフトウェア技術者として目指すべき段階的な成熟度(目標設定)について紹介します。

以下は、単純な技術力ではなく「価値」を基準に目標設定しました。あくまでも本誌発行人の独断と偏見ですが、国内外の若いソフトウェア技術者が目指すべきキャリア指針となると確信します。

(1) 生産性が高い人
(2) バグの少ないソフトウェアを作る人
(3) 使いやすいソフトウェアを作る人(親切I/F・優れた保守性)
(4) お金を稼ぐビジネスモデルをITで構築する人
(5) 大勢が好んで再利用するソフトウェア部品を作る人
(6) ITを利用した新しい儲かるビジネスモデルを構築する人

※数字があがれば上がるほど価値が高いことを示します。

レベル0

上記のレベル1の価値さえ満たさないソフトウェア技術者は、将来オフショア開発によって代替されるか、オフショア委託先と同程度の給与水準に甘んじます。いわゆる「平凡な技術者」です。

レベル1

ソフトウェア技術者として価値が生まれるのはレベル1からです。

レベル2

多くの会社で、オフショア委託先の20代技術者に要求するのがレベル2の成熟度でしょう。平均以上の生産性を保った上で高品質を実現すること。ここでは、高品質=「バグが少ない」と定義します。

レベル3

なお、レベル2とレベル3の間には越えられない壁があります。日本語能力検定N3とN2の格差がちょうどそんな感じです。一般に、使いやすいソフトウェアを作る技術者は、ドキュメント作成能力にも長けます。

残念ながら、中国オフショア委託先で優秀だと称されるSEの大半はレベル3の壁に阻まれます。実際には、将来レベル3を目指せる有望な若手SEは大勢いますが、彼らが現場で3-4年経験を積むと、途端に技術者としてのキャリアから逸れて、BOSS(管理者)として出世の階段を駆け上がるキャリアに路線変更します。すると、技術者としての成熟度はレベル2に停滞したまま、年齢を重ねることになります。

レベル4

レベル4は、優秀な経営コンサルタントとての能力を併せ持つSEはです。レベル3から成長した技術指向のSEもいれば、レベル2から一気に才能を開花させるビジネス指向のSEもいます。残念ながら、SI企業で請負開発プロジェクトに参画するだけでは、このレベルに到達できないでしょう。

レベル5

レベル5は、ソフトウェア技術者としての最高峰です。世界中で使われるフリーソフト/シェアウェアの作者、OSS 界隈で大活躍する職人。あるいは、小規模であっても、社内で標準的に活用される Frameworkを作成し、保守サービスする縁の下の力持ちなどが相当します。レベル4を経由せずレベル5に到達する技術者もいます。

レベル6

最後のレベル6は、ソフトウェア技術者というよりも優れた起業家に相当する高業績者の成熟度です。誰もが目指せる領域ではありませんが、参考までに定義します。


■ 問いかけ

<問1>グローバルで活躍するソフトウェア技術者として最低限、満たすべき成熟度はレベル1-6のどれか? とりあえず、英語はできる前提とします。

(1) 生産性が高い人
(2) バグの少ないソフトウェアを作る人
(3) 使いやすいソフトウェアを作る人
(4) お金を稼ぐビジネスモデルをITで構築する人
(5) 大勢が好んで再利用するソフトウェア部品を作る人
(6) ITを利用した新しい儲かるビジネスモデルを構築する人

その他

結果を見る

締切:2014年08月24日18時00分
協力:クリックアンケート http://clickenquete.com/
.

<問2>あなたの組織でも、日本人のインターンシップ学生を受け入れることになりました。一人の学生が「上記レベル1の成熟度すら自分は怪しい」とSE就職に自信を失いかけているとします。あなたは、先輩社会人として、どう声をかけますか。

| | Comments (0)

例文「レビュー指摘数が100件になる」

今日は外国語に翻訳しづらい日本語、特にオフショア開発でよくみかける例文と改善例を紹介します。


(1) レビュー指摘数が100件になる

(2) 昨今、厳しい為替変動があったが、親会社との話し合いの中で条件面で合意しなかった。

(3) 人材育成計画と品質向上がどう関連するのか曖昧なのですが、先日の私の提案を考慮するといいかな、と思ったのですが、決して反対しているわけではありません。基本路線はいいと思います。


【改善提案】

(1) 「なる」を状況に応じて具体的な動詞で言い換える

- 到達した
- 超えた
- 目標と一致した


■ 問いかけ

<問1>例文(1)を具体的な動詞で言い換えて、発言者の気持ちなどもうまく表現しなさい。

<問2>例文(2)の改善案を提示しなさい。

<問3>例文(3)の改善案を提示しなさい。

※答えは実践セミナーにて

英語に翻訳しやすく外国人に伝わりやすい日本語
(Global English に基づく効果的な外国人との交流技法)

| | Comments (0)

同意の強さが異なる英語表現

先週金曜日(8/1)、オフショア大學主催のグローバル英語&日本語教育が開催されました。主任講師とアシスタントを含めて総勢10名で盛り上がりました。

受講者アンケート結果では「英単語のコアイメージ」の着眼点が斬新だったとのご意見が目立ちました。

※参考過去記事:言葉の根源的意味(コア)/きれい≠漂亮

今日は、英語初学者が誤解しがちな英語表現の例を1つ紹介します。


■ 問いかけ

<問1>下記英語表現の同意の強さをそれぞれ%で定義しなさい。
(100%=完全同意、 0%=不同意)

  (a) We are fine.
  (b) I understand.
  (c) It sounds good.


<問2>上記英語表現の同意の強さを、強い順番に並べ替えなさい。

a > b > c (aが強い同意、bは中程度、cは弱い同意)
a > c > b
b > a > c
c > a > b
a≒b≒c
それ以外(コメントボードに答えを書く)

結果を見る

締切:2014年08月11日18時00分
協力:クリックアンケート http://clickenquete.com/

| | Comments (0)

« July 2014 | Main | September 2014 »