英語から開発しよう、そのアプリ。 - 職業プログラマの休日出勤

私は、WebアプリでもiOSアプリでもその他のものでも、何かしらUI(User Interface)を伴うアプリケーションを開発するときはまず英語バージョンを先に作るようにしています。

自分は、先に英語で開発してる。文字数が多くなる言語で開発するのが正義！　本当はドイツ語で開発したいけど、それほどのドイツ語のスキルが無い。 #関モバ
— 自宅適合者 T.Motooka (@t_motooka) 2016年1月27日

これは昨年1月に関モバに参加したときの発言です。

この記事では、次のようなことを述べています。

英語版から開発すると、どんな幸せなことが起きるのか？
どんな状況のときは、英語版を作らない方が良いのか？
和文英訳力を鍛える方法

また、この記事のタイトルは美しい川柳になっています。575です。

英語版から開発する効用の例示

それでは、英語版を先に開発することでどのような効果があるのか、例を示していくことにしましょう。

効用例その１：画面レイアウト

冒頭のtweetでも述べていますが、一般的に、同じ内容のことを書こうとした時には日本語よりも英語の方が文字数が多くなりますし、画面レイアウトを考える上では幅を取ることが問題になります。日本語の文字数や文字幅のことしか考慮せずにボタンの幅などを決めていると、英語にした瞬間に死にます。
初めから英語で開発していればそんなことは無く、日本語に翻訳しても問題が発生することはほとんどありません。
文字数という意味ではドイツ語の方が長くなる傾向にあるので、この観点では、冒頭のtweetのように英語よりもドイツ語の方が適した言語であると言えます。しかし、ドイツ語の単位を落としまくった私のような人間にはそれは難しいです。

効用例その２：仕様レビュー

この文章を読んでいる人たちの大半は、日本語を母語としていることでしょうし、思考を日本語で練っているでしょう。
ですから、仕様を文書に書き起こしている場合であっても脳内に展開している場合であっても、英語版のアプリを作る際には、必ず英訳という過程を経ます。その時、私たちは普段発揮しない力を発揮するのです。そう、原文の日本語をよく読むのです。その作業は知らないうちに実施しています。そうすると何が起きるかというと、そもそもの日本語のおかしな点に気付くことができるのです。
窓際に座ってる給料泥棒なオッサン（失礼！）何人かに浅く仕様のレビューをしてもらうよりも、開発する少数の人間が深いところまで仕様を読み込んだ方が、誤ったものを開発してしまうリスクは低くなるでしょう。

効用例その３：命名

開発する上では、モジュールの名前、クラス名、変数名、関数名などを命名しなければなりません。日本語そのものやローマ字を使うというのも手段のうちではありますが、英語で命名するチームも数多くあることでしょう。こうした命名をする際に、アプリケーションの画面が英語で設計されていれば、命名が楽になります。
あるところでは、プログラミング作業の大半は命名である、といったことが言われることもあります。命名が楽だったらプログラミングも楽になります。

効用まとめ

３つの例を挙げましたが、これらに共通して言えるのは「手戻り防止」です。画面レイアウトでミスってたら手戻り、仕様がミスってたら致命的な手戻り、命名でミスってたら余分なリファクタリングが必要になります。
数年前に至高のウォーターフォール型開発という記事で述べた通り、アジャイル型開発というものは手戻りを極限まで減らすことが狙いの一つになっています。手戻りを防ぐことができれば、幸せな開発ができますね。

英語版を作らない方が良いものの例示

英語版から作った方が良いという話は、すべての環境に当てはまるわけではありません。そういった例も紹介しておきましょう。

作らない例その１：処理対象が日本語only

そもそも多言語対応する予定の無いアプリケーションであれば、英語版から作るという意義は低いです。効用のうち仕様レビューと命名についてメリットがあると思うかもしれませんが、例えば「貸倒引当金」という語を英語に訳した時に得られるメリットは何でしょうか？
グーグル先生によれば Allowance for bad debts だそうですが、画面上の「貸倒引当金」が Allowance for bad debts になっていたところで、仕様のミスに気付くことは無さそうですし、クラス名や変数名などの命名も日本語またはローマ字等になっていた方がメンテナンス性は高そうです。
無理して英語にしても良いことはありません。

作らない例その２：責任範囲

責任範囲が、発注主や上司等が出した仕様通りに開発することであり、かつ、仕様の誤りについて責任を負うことが無いのであれば、英語版から開発するよりも日本語版を先に開発した方が良いでしょう。
そのような環境ではきっと英訳も仕様の一部として出てきているはず（はず！）ですから英訳の正しさについて責任を負う必要も無いですし、画面レイアウトや論理的な矛盾など仕様に変なところがあってもそのまま作ることが仕事なので、そのまま作ったら良いと思います。

この記事が対象にしているのは、良いアプリを効率的に作り、そしてそのアプリをさらに良いものへと化けさせていくチーム、です。

英訳力を鍛えるには？

ここまで、英語版から作ったときの効用や、適用してはいけない事例などを紹介しました。ぜひ皆さんにも英語版から作るということに挑戦して欲しいのですが、難しいと思っている方も多いかもしれません。
基本的な文法、和英辞典や英和辞典の使い方、よく使う言い回し、最低限これらのことさえ知っていれば、美しいかどうかは置いておいて、意味の通じる英文を書くことは可能です。文法知識に関して言えば、高校１年生レベルのものがあれば、もはや十分なのです。
そうとはわかっていても、多くの方が英訳は難しいと思っていることでしょう。

それは何故か？

よくある原因の一つに、和文英訳する際の日本語の言い回しが整理整頓されていないから、というものが挙げられます。
この記事の「仕様レビュー」の項で述べたように、和文英訳の作業の過程では大なり小なり、原文の日本語の意味を解析しなければなりません。その工程を経ずして英訳しようとしても、イケてないコンサルの作った資料が見た目綺麗でも意味を成していないのと同じように、見た目が英語になるだけで意味を成さないのです。

私は、和文英訳の力を鍛えるための近道は、簡単に英訳できるレベルまで和文を読み砕いていくことだと確信しています。

この方向性で和文を読み砕く訓練として適切なものを思い浮かべてみましたが、真っ先に思いついたのは京大入試の和文英訳問題です。
数年前に出題形式が変わったそうですが、それまでは長年、英語の長文の中に下線が引いてあって「下線部を和訳しなさい」という問題と、「次の和文を英訳しなさい」という問題ばかりが出題されていたそうです。この和文英訳問題の和文をいくつか読んだことがありますが（何年前の話だろう…）、いかにも日本語らしい言い回しが数多く埋め込まれていました。日本語を分析する上では京大入試の和文英訳問題の過去問に挑戦すると良いのではないでしょうか。

過去問以外にも、こんな本も参考になるかもしれませんね。