まず前提として、私は今まで 2 つのアメリカ系会社で働いたけど、どちらも「働きやすい会社ランキング」みたいので 1 位、2 位に入るようなホワイト企業です。こういう会社は、大抵 diversity を重視してるし、社員の教育レベルも高いので、英語が下手というだけでマイナスになることは（少なくとも目に見える範囲では）ありません。まぁ、そうではないブラック企業に英語が苦手な日本人が入社することは考えにくいので、これはそれほど無謀な前提ではないでしょう。
あ、あとソフトウェアエンジニアであることが前提です。英語が苦手な人がアメリカで弁護士として働くのは無理でしょう（どうだか知りませんが）。
英語が苦手でも働ける
これについては、2 つの理由が考えられます。
- コードが共通語になる
- 結果を出していくうちにコミュニケーションコストが下がる
1 つめは当たり前ですが、ソフトウェアエンジニアの成果物はソフトウェアであって、ドキュメントではないので、コミットメッセージの文法が間違って（よくある）ても、デザインドキュメントの文章がこなれてなく（よくある）ても、それだけで問題になることはありません。
もう 1 つは、仕事で結果を出していると、「この分野については彼が凄く詳しい」「彼にレビューしてもらうと有意義なコメントをしてくれる」と思われて、質問・相談される機会が増えます。相手は明確に知りたいことがあるから耳を傾けてくれるし、こちらは自分の得意分野を話せばいいし、これは楽です。
ものすごく主観的ですが、エンジニアの能力を
α × [技術力] + (1 - α) × [コミュニケーション力]
で測れるとすると、α = 0.8 かなという感じです。0.5 では絶対ないし、0.95 でもないです。両極端のケースを 2 つとも見たことがありますが、どちらもうまくいきませんでした。英語が苦手だと偉くなるのは難しい
「偉くなる」をきちんと定義すると「job level が上がる」ということです。Engineer 1 とか Junior Analyst などから始まって、上の方には Principal Engineer とか Fellow などがあります。Job level が上がることによって、
- ディスカッションが増える
- 仕事を delegate しないといけない
- 全然知らない人と話す機会が増える
ということが変わります。自分の経験上は。
まず、ソフトウェアの設計や方向性がそもそも正しいのか、目的に合致してるのかということを議論する機会が増えます。この時点ではコードは無いし、ドキュメントはあるとしても凄く大雑把なので、口頭での議論になります。あと、「明らかに間違ってる」とか「もっと効率良く書ける」ことを指摘するのに比べて、「こっちのデザインの方が良いんだ。なぜなら、将来的にこの方向に拡張する可能性が高いから」という議論は、客観的に確実な正解がないぶん、難しいです。
次に、今まで自分がやっていたことを junior developer に任せて、自分は別の仕事をすることになります。が、自分の経験的には、英語が苦手だと delegation を避けたくなります。
例えば、自分でやれば 2 時間で終わる仕事があり、delegate するとなると最初の説明と、その後のサポートに 1 時間かかりそう（でも英語が流暢なら 15 分かも）。となると「じゃあ自分でやるか」と考えてしまいがちですが、これを続けていると、いつまでも同じ仕事をすることになってしまいます。だいたい、2 時間で終わる仕事というのは、その後のサポートとかを考えると、トータルで費やす時間は 2 時間どころじゃないものです。そうすると、本来自分がやるべき仕事のための時間が無くなってしまって良くないです。
そして関わる人の範囲が広がります。最初の頃は、自分のチームとマネージャーと、担当のプロダクトの人を話してれば良くて、みんなが自分のことを知ってるので話しやすいです。これが徐々に、隣のチーム、全然知らないチーム、大きなプロジェクトのプロジェクトマネージャーと、セキュリティの話をセキュリティ担当者と、予算の話をキャパシティチームと、製品の適合性について買収予定の会社の人と、などなど、自分の土俵外の話を、全然知らない人と話す機会が増えます。
ということで、「英語力の不足を技術力で補う」ことがだんだん難しくなる（ように私は思う）という話でした。これもチャレンジだと割り切って、楽しめれば良いと思います。
あと、「英語が苦手」な人は「英語が下手」なんだけど、「英語が下手」でも「英語が苦手」とは限らなくて、稀に「下手だけどちゃんとコミュニケーション取れてる」人がいますよね。そういう人はいいなーと思います、ホントに。
0 件のコメント:
コメントを投稿