WYDKYDK が読めたよ！ ﾜｰｲヾ(´ρ`)ﾉ゛ﾜｰｲ

Alistair Cockburn の本に出てくる変な綴りの言葉。意味は分かるけどなんて発音するのか、ずっと分からなかったけど、何の気に無しにググってたら見付けた。

なんかソフトウェア開発とは全然関係ない、オレゴン州の自治会か何かの議事録らしき文書だけど、WYDKYDK ("wid-kee-dik")とある。カタカナにするとウィドキーディクみたいな感じだろうか。

綴りが珍しいのは略語だからで、もとはこんな文。

What you don't know you don't know

簡単な英語だけど、構文が分からない人が意外と多い。順を追って見てみると、

You don't know it.
あなたはそれを知らない

↓

What you don't know.
あなたが知らないもの

↓

You don't know you don't know it.
あなたはそれを知らないという事を知らない

↓

What you don't know you don't know.
あなたが知らないという事を知らないもの

といった感じで、入れ子になってたりして、プログラマには親和性が高い気がするんだが。

ところで、現場ではこの WYDKYDK への認識が足りない人が、例えば WBS を作ったり作らせたりすると、困った事になる。

「これだけ詳細化したんだから、見積りは正確なはずだ」なんて思考様式なんだけど、そもそも認識されていない事を詳細化しようもないし、予測に組み込みようもない。

正解は、何らかの形で現実に実行してみて「知らない事」を「知らなかった事」に変えていく事なんだけど、下手な人はこの当たり前の事ができず、日程にバッファを組み込むといった程度の、稚拙な手に走ってしまう。 まあ現場ごとの文化とか、プロジェクトごとの事情とかもあるけどね。

技術者と英語：「読める」だけで嬉しい三つの事

TOEIC 800点前後というと、レベルBに当たる。

TOEIC が提示している相関表の説明によると、「どんな状況でも適切なコミュニケーションができる素地を備えている」、「日常会話は完全理解」、「業務上も支障なし」とされている。

なんて言っても、実は「話す」「書く」が未経験でも「聴く」「読む」がソコソコできれば、割と取れる点数だったりする。自分もだいぶ前に 800を越えたが、恥ずかしながら全然喋った事なんかない。

つうか話す相手も機会も今のところ一切無いし、従って興味も沸かず努力のしようもないんだけど、ソフトウェア開発技術者としては、「読める」だけで結構役に立つ事がある。

以下の３つ。

◆ 英語でググれる
言うまでもなくインターネットは日本語情報より英語情報の方が圧倒的に多いし、技術情報は特に英語圏発のものが時間的にも先行している事が多い。

英語が読めると、Google の search settings で、English を設定しておいても別に問題ないから、情報量の少ない日本語サイトを避けて効率的に検索できる。

技術系BBSでのディスカッションやトラブルシューティングでも、海外の方が盛んで検索にもヒットしやすい。


◆ 技術系の洋書が読める
最近は、少しだけ改善したようだけど、一昔前の邦訳書は、かなり読みにくいものが多かった。APIリファレンス的なものはまだマシな方だけど、ちょっとユーモアを交えた語り口になったり、思想的に難解な話になったりすると、途端に日本語がおかしくなる。

邦訳書の日本語に対する文句は至る所で聞くけど、最初から原書にしておけば、無駄なイライラをせずにすむ。つうか、無駄な変換レイヤーが無いという点で情報処理の視点からもある意味合理的なわけで、技術者ならなおさら原書を選択すべき。


◆ ソースコードが英語に見えてくる
意外と意識されていない事が多いが、ほとんどの高級プログラミング言語は英語ベースだったりする。

まず単語の面で、言語のキーワードにおいても、各種 API の識別子においても、そのほとんどは英語の語彙、つまり何百年も前からアングロサクソンが日常のコミュニケーションの中で使ってきた言葉で構成されている。

また文法の面でも、意識的にか無意識的にか知らないけど、メソッド呼び出しの文が、「subject.verb(object)」みたいな感じで、だいたい英語の語順に従うようになっていたりする。

なので、上手に書いたプログラムは自然言語としての英語に近くなり、下手なコメントやダイアグラムなんかよりも、書き手の意図を読者に、より効率的、より直截に伝える高い表現力を持つ事ができる。

英語が「読める」ようになるだけでも、人間同士が意思疎通するコトバという観点から見たプログラムの良し悪しがより分かるようになり、ソースの読み書き両面に良い効用が出てくる。

====

ちなみに、逆に英語が全然読めない人の場合、英文としての表現力さえ備えるに至った良質なコードを前にしても、解読を要する意味不明な記号の羅列か、もしかすると ASCII アート的な図形にしか見えていないのでは、と疑わしくなる場面がよくある。

こういう人達って、「ソースを読む」ではなく「ソースを解析する」という言い回しを好む。「ソースが言葉である」なんて事は脳内ですら成立したためしがないから、「読める」コードなんか自分でも書ける訳もなく、必然的に無駄なコメントだらけの残念なコードを書いてしまうことになる。

Test Double の「Double」とは

プログラマにとって「double」と言えば、まず第一に倍精度浮動小数点数のことだろうけど、Test Double の「double」はどうか。

昨今の開発で、まともにテスト駆動が成立するレベルのテストコード、つまり TestSmell が一定以下に抑制された DeveloperTest を書いていくためには、かなり多くの場面で Test Double パターンが必要になる。今日びのプログラマにとっては、Stub、Mock、Fake、Spy 等を含む Test Double と言われる一群のテストパターンを自在に使いこなす事は、必須技術の一つと言えるんじゃないかと思う。

個人的な話になるが、実は自分は、この Double の意味を知らないまま、長い間「Test Double」という言葉を使っていた。深く考える訳でもなく、何となく「Test」を動詞、「Double」を副詞と認識して「二重にテストする」なんて意味かなと思っていたが、TestDouble が意味する手法と一致しなくて、ずっと気持ち悪かった。

ある時、何気なくネットの辞書を引いてみたら、ちゃんと答えがあった。

Weblio の英和辞書ではこんな感じ

【名詞】3.b【映画】
代役，替え玉 〔for〕.

英英辞書の OALD ではこんな感じ

NOUN PERSON/THING [countable] 
 an actor who replaces another actor in a film/movie 
 to do dangerous or other special things

まず、Double を副詞と考えていたのが、そもそも間違いで、本当は映画用語の名詞。Double が副詞でないということは「Test」は動詞ではありえず、したがって「Test Double」で名詞+名詞の複合名詞、つまり「テストの替え玉」という意味になる。

やっぱ辞書はこまめに引かないといかんな。

※OALD は 非英語ネイティブ向けの英英辞書としては、かなり良い感じ。ネット版だけじゃなく、リアルの辞書もよくできてる。

プロジェクトの英語化

楽天で英語が社内公用語になったらしい。[→この記事]

この施策が、事業の国際化に正味どれだけ貢献するか知らないけど、技術者としてはちょっと興味深い。例えば、システム開発プロジェクトへの英語の導入を想像してみたくなるが、ちょっと思案してみると、まんざら不毛なアイデアでもなさそうな予感。期待したいのは、国際化なんかじゃなくて、システム開発を合理化したいという、それだけなんだけど。

まあ、進捗会議やら朝会やらでの英会話は無理っぽい。「日本人は読み書きはできるが会話は苦手」なんて言われてもいる程だし、とりあえず読み書きのみの英語化にとどめて良いと思う。


話を簡単にするために、自社で販売するパッケージ製品の開発や、英語でコミュニケートできるクライアントのための開発を想定して、クライアント組織の言語はとりあえず考えなくて良い事にすると以下のような感じだろうか。

☆ まずユースケースの英語化。これが最も効き目の大きなところだと思う。

そもそもオブジェクト指向においては、要件定義に現れて来るドメインの語彙が、そのまま 名詞 ⇒クラス名、動詞 ⇒メソッド名という形でソースコードに直接的に投影されるという事が重要で、同時に開発者が留意すべき点でもあったはず。プログラム中の識別子の語句と、ユースケース／ドメインモデルの語句が同一である事が、内部品質（≒保守性≒生産性）にも大きく貢献していたのだと思う。

ところが日本のプロジェクトでは、日本語の上流成果物から英語ベースのソースコードに至る過程のあちこちで、脳内和英変換でエネルギーを浪費させながら作業する羽目になる。あまりに常態化しているのでなかなか反省されにくいが、洋書に載っているような演習やケーススタディ、つまりユースケースにもソースコードにも共に英語を使っているものと比較すると、明らかな不経済だと分かる。

やはりまずは英文ユースケースが欲しい。投入すべき労力も大きそうだが、得られる見返りも大きいと思う。

☆ で次に、ユースケースが英語化できたら、ソースコードに至るまでの中間的なドキュメントも、やはり英語化。まあユースケースが英語になった時点で、後続の成果物の英語化も大分楽になってるはず。ハードルは低いと思う。

JavaDoc 等のいわゆるヘッダコメントも英語で記述。当然ながら、識別子に用いられるコトバと、その説明に用いられるコトバは統一されている方が、別々の言語からとった語をそれぞれに適用するよりも合理的と思われる。

ソースコメントについては、昨今の流儀では「コメントを書いている暇があったら、コメント無しでも読みやすいコードを書くよう工夫すべし」とされているが、英語を意識して開発できるようになれば、各ステートメントが英文ライクな構造に、自然とフツーに近づいていくはず。まあ、どうしてもコメントを書くなら英語で書くべきだろう。

☆ その他の英語化対象としては、WBS、スケジュール表といったところか。
Trac のチケットや wikiも英語化によるメリットがありそう。

＝＝＝＝
てか、そもそも普段使っているプログラミング言語のキーワードや API の識別子のほとんど全てが、英語話者が何百年も前から使っている人間の言葉だったりする。それに文法の面でも、大抵のオブジェクト指向言語では、なんとなく英語構文の語順を意識している節がある。

（SVO と subject.verb(object) みたいな）

こういう事を考えると、なんだか全面的に英語で開発するというのがプログラミング本来の姿なのではという気さえしてくる。

なんていろいろと書いたが、現実のIT業界では「会話はできないけど読み書きはできる」という前提からして、まず怪しかったりする。そこそこ読み書きできる開発メンバを集めるだけでも、実は大変かもしれない。

ear, war の読み方

Java の仕事をしていると、WAR(Web ARrchive) をワーと発音する人をみかける。また、EAR（Enterprise ARchive） をアーなんて発音する人も多い。ちょっと気になるので調べてみた。

まずは Youtube で 英語圏の人たちがどう発音しているか観察してみる。ejb だとか Tomcat だとかで検索すると、いろんなのがヒットする。例えば、以下のビデオでは、01分43秒のところで、次のように話しているのが聞き取れる。

http://www.youtube.com/watch?v=wIKdM-d7FiA

We go on a little bit about packaging our application. This is EAR, WAR and JAR files.

普通の英単語と同じように WAR ⇒ /wɔr/、EAR ⇒ /ɪər/、JAR ⇒ /dʒɑr/って言ってる（記号はここ参照）。「war」は、「戦争」という意味でも 「Web Archive」というい意味でも、発音については/wɔr/ で同じらしい。まあ極めて自然。

さて改めて、日本語による WAR の発音を考えてみると、結局「WAR」という英字スペルにマッピングするカタカナの配列を新たに発明するのではなく、普通の英単語「war」、あるいは発音記号 /wɔr/ で表される音列を表すときに、われわれ日本人がこれまでどんなカタカナの組み合わせを使ってきたかを考えてみれば良いのだと思う。

というか、･･･うーん、どうかんがえても「ウォー」以外ないのではなかろうか。「war」で考えても /wɔr/ で考えても「ワー」は無いわ。いや普段から「スター・ワーズ」とか、「ワン・ツー・スリー・ファー」とかいった感じで喋ってる人なら問題ないかもしれないけど。

あと warning を ワーニングって言う人も多いけど、これはある意味 war を「ワー」って言う以上になんか悲しい。WAR は Web Archive の略称でもあるから別の読みがあっても不思議じゃないけど、warning はどこから見ても普通の単語だし。まあ普段から「ハート・ワーミング・ストーリー」とか「ワーミング・アップ」なんて感じで喋ってる人なら、ある意味、一貫性があるけどさ。

ear も同じことで、イアーとイヤーで迷うなら分かるけど、何故「アー」なのか不思議。なんか earth とか heart あたりからインスパイアされたりしてるんだろうか。

ちなみに、false をファルス（男根の意味）と読むのも恥ずかしい。人前で喋るのを生業とする人たちにとって、彼らが「噛んだ」とき、単にいくつかの音節を発音し損ねるだけじゃなく、別の言葉として成立してしまうような噛み方をしてしまうのが最悪だというけど、それにも通じるパターンだ。いや、気付いていないという点で、それ以上かも。