この施策が、事業の国際化に正味どれだけ貢献するか知らないけど、技術者としてはちょっと興味深い。例えば、システム開発プロジェクトへの英語の導入を想像してみたくなるが、ちょっと思案してみると、まんざら不毛なアイデアでもなさそうな予感。期待したいのは、国際化なんかじゃなくて、システム開発を合理化したいという、それだけなんだけど。
まあ、進捗会議やら朝会やらでの英会話は無理っぽい。「日本人は読み書きはできるが会話は苦手」なんて言われてもいる程だし、とりあえず読み書きのみの英語化にとどめて良いと思う。
話を簡単にするために、自社で販売するパッケージ製品の開発や、英語でコミュニケートできるクライアントのための開発を想定して、クライアント組織の言語はとりあえず考えなくて良い事にすると以下のような感じだろうか。
☆ まずユースケースの英語化。これが最も効き目の大きなところだと思う。
そもそもオブジェクト指向においては、要件定義に現れて来るドメインの語彙が、そのまま 名詞 ⇒クラス名、動詞 ⇒メソッド名という形でソースコードに直接的に投影されるという事が重要で、同時に開発者が留意すべき点でもあったはず。プログラム中の識別子の語句と、ユースケース／ドメインモデルの語句が同一である事が、内部品質（≒保守性≒生産性）にも大きく貢献していたのだと思う。
ところが日本のプロジェクトでは、日本語の上流成果物から英語ベースのソースコードに至る過程のあちこちで、脳内和英変換でエネルギーを浪費させながら作業する羽目になる。あまりに常態化しているのでなかなか反省されにくいが、洋書に載っているような演習やケーススタディ、つまりユースケースにもソースコードにも共に英語を使っているものと比較すると、明らかな不経済だと分かる。
やはりまずは英文ユースケースが欲しい。投入すべき労力も大きそうだが、得られる見返りも大きいと思う。
☆ で次に、ユースケースが英語化できたら、ソースコードに至るまでの中間的なドキュメントも、やはり英語化。まあユースケースが英語になった時点で、後続の成果物の英語化も大分楽になってるはず。ハードルは低いと思う。
JavaDoc 等のいわゆるヘッダコメントも英語で記述。当然ながら、識別子に用いられるコトバと、その説明に用いられるコトバは統一されている方が、別々の言語からとった語をそれぞれに適用するよりも合理的と思われる。
ソースコメントについては、昨今の流儀では「コメントを書いている暇があったら、コメント無しでも読みやすいコードを書くよう工夫すべし」とされているが、英語を意識して開発できるようになれば、各ステートメントが英文ライクな構造に、自然とフツーに近づいていくはず。まあ、どうしてもコメントを書くなら英語で書くべきだろう。
☆ その他の英語化対象としては、WBS、スケジュール表といったところか。
Trac のチケットや wikiも英語化によるメリットがありそう。
＝＝＝＝
てか、そもそも普段使っているプログラミング言語のキーワードや API の識別子のほとんど全てが、英語話者が何百年も前から使っている人間の言葉だったりする。それに文法の面でも、大抵のオブジェクト指向言語では、なんとなく英語構文の語順を意識している節がある。
（SVO と subject.verb(object) みたいな）
こういう事を考えると、なんだか全面的に英語で開発するというのがプログラミング本来の姿なのではという気さえしてくる。
なんていろいろと書いたが、現実のIT業界では「会話はできないけど読み書きはできる」という前提からして、まず怪しかったりする。そこそこ読み書きできる開発メンバを集めるだけでも、実は大変かもしれない。
0 件のコメント:
コメントを投稿