メルマガ連載「ライル島の彼方」 第2回 「開発者に英語が必要な、20の理由」 ～転載（2014/10/29 配信分）
この記事は、メルマガ「デジタル・クリエイターズ」に月1回連載中の記事の転載です。
連載 「ライル島の彼方」 第2回 開発者に英語が必要な、20の理由
前回に引き続き、ザル英語について取り上げる。
アプリ開発は、いきなり実装から始まるわけではない。段取り八分である。アプリの公開手順を理解し、開発言語や開発手法を学んで試し、企画、設計、データ・デザイン、UXデザインなどを行う。
それらの工程では、英語の情報が役立つこともある。機械翻訳に頼ることなく英語を理解できれば、次に揚げるように、なにかと便利ではなかろうか。
【1】リソースが豊富である
新製品やイベントを紹介するニュース記事、技術解説や一般コラムなどのオンライン記事、開発者個人のWebサイトやブログなどには、英語のリソースの方が圧倒的に多い。
【2】仕様書の翻訳を待たなくてよい
開発言語の仕様書（※1）のような分量の多いドキュメントは、ローカライズに時間がかかる。W3Cの標準化仕様書は、勧告となった後に、ようやく翻訳されることがある。一方で、開発環境のバージョンアップはめまぐるしい。環境が変わらないうちに情報を入手するには、英文を直接読むしかない場合もある。
【3】仕様書の図表を活用しやすい
たとえばHTMLの要素・属性の一覧や、DOMのIDL定義などのように、仕様書の中に表やリストの形で掲載されている情報がある。英語に抵抗感さえなければ、こういった翻訳不要の情報を、先行して利用できる。
【4】和書と洋書を併用して学べる
（専門分野によって異なるかもしれないが）国内では、どちらかといえば、入門者向けの書籍が充実している。初心者対象の和書で概要を把握した後に、専門家対象の洋書で細部を確認するのは、技術習得のひとつの方法である。
【5】プレビュー版を試しやすい
Windows 10 Technical Preview が公開された（※2）。既に多くのニュースがネット上を駆け巡っている。
海外ベンダーの製品は、通常、英語版が先行公開される。ダウンロード情報やセットアップ時のメッセージを読みながら試す方が、勘でセットアップするよりも確実だ。
【6】著作権情報を理解しやすい
アプリ開発において、他のプログラマの作った各種サンプルやツール、API、素材などを利用したい場合、使用許諾書や著作権などの情報を、スルーすることはできない。それらのテキストが英語で書かれていても、きちんと理解したうえで利用する必要がある。
【7】サンプルの処理を理解しやすい
海外の開発者が個人的に公開したサンプルコードのコメントは英語であることが多い。コードだけでなく、コメントも読める方が、ロジックを理解しやすい。
【8】開発時の名付けに困らない
クラス名や変数名などに、適切な名前付けをできる。また、分かりやすくインパクトのあるアプリのタイトルを付けることができる。
【9】スペルミスを減らせる
参照先のサブフォルダ名やファイル名にスペルミスがあると、アプリは正しく動作しない。
また、RDBのフィールド名やXMLのタグ名にスペルミスがあると、プログラムが正しくても、目的のデータを処理できないなどのバグが生じることがある。誤ったスペルのスキーマをもとに、大量のデータが蓄積される事態は避けなければならない。
最初から正確につづるには、知っている単語は多い方がよい。
【10】困った時に答えを得やすい
英語圏のサポート情報やフォーラムでの質疑応答を参考にしたり、海外の開発者やベンダーの担当者にメールで問い合わせるには、英文を直接読み書きできる方が、意思疎通をはかりやすい。
【11】技術的解決策を検索しやすい
納期がタイトな開発案件で、急いで解決策を知りたいとき、英語のリソースも検索対象とした方が、答えの見つかる可能性が高くなる。が、メソッド名やプロパティ名などで検索すると、膨大な検索結果が得られてしまい、目的の答えを見つけにくい。絞り込むには、英語で検索キーを的確に指定できるほうがよい。
【12】誤った情報を見分けられる
参考にしたい英語のリソースの中には、開発・実行環境のバージョンが異なるなどの理由により、解説通りの手順では正常に動作しないサンプルもあるだろう。動作環境や概要などの英文を読めば、原因に気付くことができるかもしれない。また、情報を鵜呑みにして適切でない処理を利用してしまうリスクを回避できる。
【13】火元になるリスクを減らせる
翻訳されたニュースやブログ記事の中には、時折、筆者の真意を読み取りにくい微妙な表現がある。原文を読んで確認できれば、早合点や誤解は減り、誤ったツィートを避けられる。
【14】訳文では分かりにくい部分を確認できる
W3Cの標準化仕様を元にした実装の途中で、仕様の詳細を確認するには、原文を直接あたるほうがよい（※3）。いかに優れた翻訳家が訳しても、訳文からは見えてこない部分があるからだ。
「MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY、OPTIONAL」の使い分けや、複数形と単数形の区別も、原文なら一目瞭然だ。
たとえば XPathの仕様書でいえば、nodesとnodeは、明確に使い分けられている（※4）。XMLデータ処理プログラミングにおいては、指定する対象が、複数のノードなのか、それとも複数の中の特定のノードなのか、また、式の評価結果は複数なのか、それとも単一なのか、といったことを意識している方がよいだろう。
【15】初発情報を発信しやすい
新しい仕様が登場した当初は、日本語のリソースはごくわずかである。いちはやく技術を伝えようとすれば、英語のリソースを避けて通ることはできない（※5）。
まだ適切な訳語がない場合は、背景やコンテクストから意味をイメージして、読者の理解を促すような訳語を考える必要がある（※6）
【16】技術者同士の交流の場を拡げやすい
海外エンジニアも参加するコミュニティイベントで交流したり、技術者同士でチャットするには、英語を操れるほうが、友人は増えるだろう。また、海外の開発者とのコラボレーションでは、英文ドキュメントを読み書きできるほうがよいだろう。
【17】ユーザーと意思疎通をはかりやすい
海外ユーザーからの問に答えたり、バージョンアップ要求の内容を理解するには、英語でやり取りできる方がよいだろう。
【18】開発物を宣伝しやすい
宣伝用コピーや行間を読ませる文章を書くスキルがあれば、機械翻訳よりも伝わりやすく表現できるだろう。
動画サイトやSNSで、海外ユーザーに向けて開発物を宣伝できれば、ダウンロード数も期待できるだろう。
【19】海外に自分の技術を発信できる
英語でブログを書いたり、SNSを使いこなせれば、自身のもつ技術を、海外に向けて発信できる。
日本語で考えて表現したものを英語に訳すのではなく、英語で直接考えて表現できると、より発信力が強まるに違いない。
【20】技術以外の多くの情報を得られる
拡がりのある企画を立てるには、専門分野以外の情報もウォッチしているほうがよい。
現在では、「科学・医学・倫理学」と「技術」には、クロスオーバーする部分が増えている。
センサーを使ったアプリ開発についていえば、新たなセンサー素子の研究開発は「科学」であり、センサーと人体のシームレスな接続方法には「医療」が絡み、センサーデバイスがヒトの脳にもたらす影響には「倫理学」が必要になる。
そのうえ「研究」と「開発」もクロスオーバーしている。研究して開発した結果を研究にフィードバックして、ふたたび開発する、といったサイクルもある。
国内の技術情報サイトだけでなく、海外の「科学・医学・倫理学」の「研究」結果の情報を、ウォッチしてみるのもよいのではないだろうか（※7）。
英語に限らず、どのようなスキルでも、持っていないよりは、持っているほうがよい。
ただ、どの程度必要なのか？といえば、それは意見の分かれるところだ。習得すべきスキルは、それぞれの立場や作業内容によって、異なるのだから。、
今はもう、開発者にとって英語は必要なのだろうか？と悩む時期は過ぎ、（筆者も含め）それぞれの作業に応じたスキルを獲得していく段階なのではなかろうか。
※1 たとえば、msdn の VB や C# の仕様書などである。
msdn C# リファレンス
マウスオーバーで原文がポップアップされ、訳文では分かりにくい部分を確認できる。
※2 Windows 10 Technical Preview
マイクロソフトの提供する技術につては、公開されるやいなや、その技術分野の Microsoft MVP が紹介記事を書くので、関心ある分野の MVP のブログや facebook を普段からチェックしておこう。
※3 データ・デザインの地平［39］「その記事は「社会的に」正しいか？」（2014/3/24配信）を参照。
※4 XMLデータ処理に限って言えば、ElementsかElementか、AttributesかAttributeか......挙げればキリがないが、頻発するのは、NodesとNodeである。
例文で説明しよう。「XML Path Language (XPath) 3.0 W3C Recommendation 08 April 2014」中の「3.3.1 Relative Path Expressions」の、Noteから引用する。
Since each step in a path provides context nodes for the following step, in effect, only the last step in a path is allowed to return a sequence of non-nodes.
このように、仕様書原文からは、「a path」「context node」というように、単数か複数かを読み取ることができる。
だからといって、日本語で明確に区別しすぎると、「ひとつの」ステップ、「複数の」コンテキストノード、というように、常に数を意識した表現にせざるをえず、これでは逆に理解を妨げかねない。
そこで筆者は、苦肉の策として、解説文中で複数であることを伝えなければならないときは「ノード群」それ以外を「ノード」と表記するなどして区別していたことがある。ただし、ここでいう「群」とは、あくまで学術用語ではなく、動物の群れをイメージさせる一般用語としての「群」であり、XML入門者向けに限定しての表記である。
※5 拙著「HTMLリファレンス」（1999年刊）の執筆においては、W3CのHTML仕様書の、全要素の全属性についてサンプルを作成して表示確認した。
また、MS-XSLの初発本「XML＋XSLによるWebサイトの構築と活用」（宮坂雅輝共著、筆者はXSLを担当）では、W3CのXSLTワーキングドラフトとMS-XSL（マイクロソフト独自仕様のXSLT）の仕様を突き合わせて確認する必要があった。
XMLマスター資格試験の初発本「XML MASTERテキスト XMLマスター(ベーシック) 」（福内かおり共著、筆者はXSLT・XPath・DOM・Namespace・付録ビデオのシナリオを担当）も、W3C仕様書を読んで書く必要があった。新しい技術をひろめるには、原文を避けてとおることはできない。
※6 仕様書中の言葉の訳語が定まっていない場合は、ことばの意味をイメージさせる日本語をひっぱり出す必要がある。たとえば、XML関連の仕様書に頻発する parse という言葉。現在なら「パース」と訳せばよい。が、XML黎明期にはノンエンジニアの入門者が非常に多く、「パース（構文解析）」という概念自体が知られているとはいえなかった。そうした場合は、比較的知られた言葉に置き換えて伝える必要がある。当時、筆者は、XML木をたどっていくさまを走査線に見立て、「走査」という言葉を使って解説していた。
※7 たとえば、毎日「SCIENTIFIC AMERICAN」の表紙を眺めるだけでも、リアルタイムで科学の今を実感できる。「日経サイエンス」のWebサイトにまとめ記事もある（リンク規約に抵触するおそれがあるためURIは記載しませんから、bingってください）
Windows 10 Technical Preview のプレビュー版が公開されました。
プレビュー版を体験して、意見をフィードバックしよう。
プレビュー版のリスクを正しく理解するために、インストール前に要一読。
「Windows Technical Preview をインストールする前に」