プログラマyasuhoの隠れ家

某ソフトウェア企業に勤務するおじさんプログラマyasuhoです

アメリカで働くことは大賛成だけど、ちょっと考えて欲しいこと

類さんがシリコンバレーでソフトウェアエンジニア職に就くことに関してのエントリーを書いて、それが反響を得ているようなので、その雑感。

海外でエンジニア職に就くことの雑感 – Yoshifumi YAMAGUCHI – Medium

私も短い期間ではあったけどアメリカで働いていたことがあったので、所感など書いてみようかな :)

なお、何十年も前の話なのと、私の観測範囲においてなので、まあ参考程度に読んでいただければ幸いです。

ソフトウェアエンジニアならアメリカに行った方がいいか

という問いに対しては間違いなく行ったほうがいいと答えます。ぼくが言うまでもなく、コンピュータに関する技術は今も昔も多くはアメリカが発祥であり中心で、動きも早いです。日本とは全く違う文化に触れるだけでも、行く価値があると思います。また、アメリカのIT企業の多くはソフトウェア技術者の価値を知っているので、優秀であればとても快適な開発環境が体験できます。最先端でエキサイティングなチャレンジが出来る機会も多いですよ。

もちろん全てがバラ色とは言いません。でもそういったチャレンジが出来るチャンスは人生の中でそれほど多くありません。やりたいという気持ちがあればぜひチャレンジして欲しいな。

ただ、アメリカで長く働くということであれば

ちょっと考えてみて欲しいことがあります。

自分の成果を積極的にアピールしていくバイタリティが必須

アメリカは基本に成果主義であり、自分がしたことの成果は自身でアピールする必要があります。上司が自動的に評価したりはしません。「能ある鷹は爪を隠す」という言葉は忘れましょう。そうしないと「特に成果ないの?じゃあ君はうちとしては要らないね」って話になってしまいます。

あと成果として重要なのは結果です。会社/プロジェクトに対して自分がどんなふうに貢献できたのか、という形でアピールすることが大事。長時間がんばってました!みたいなのはあまり評価されないので注意しましょう。

転職は普通

日本と違ってアメリカでは普通にレイオフされます。長く一つの企業に勤めるより、次々と職場を変わっていく人の方が多いです。逆に言うと、転職については日本よりオープンであり、頻繁に転職したからといって、それがネガティブなイメージになることはありません。

異国の雰囲気に馴染めるか

そしてこれが一番重要なことだと思うのですが、長く暮らしていくにあたり、アメリカの雰囲気に馴染めるかどうか。

ぼくの場合、アメリカに住んでみて、あらためて日本って、なんて住みやすい国なんだろうって思いました。だんだん慣れて来るとは言え、やはり異国の地で暮らすというのはなかなか大変です。東洋人だと露骨にイヤな顔をする人とかもいます。表面的な付き合いをするお友達は多くできるでしょうが、親友を作ることはなかなか難しいです。強烈なホームシックになることもあると思います。

とはいえ、普通に暮らす分にはほとんど問題はありません。「どうしても日本じゃなきゃイヤだ!」って人でない限り、大丈夫でしょう :)

結論としては

アメリカで働くことはぜひやって欲しいけど、長く働くには自分に合うかどうか見極めた方がいいかな、って思います。

現実的な話としては、アメリカの就労ビザを取得するのは簡単な話ではなく、いきなり現地採用はハードルが高いです。まずは日本の外資系企業に就職して出張/転勤というのが現実的でしょうか。

いろいろ大変なことはありますが、得られる経験や知見は非常に大きなものがあります。そういう意味で絶対損はないですよ :)

最初に書かれたコードが最も影響力が大きい

最初に書かれたコードって、すごく影響力大きいよね。

もはやファイルのタイムスタンプを確認するまでもないだろう、と私は思った。おそらくは、このシステムは構築の初期、ある程度はまともに作られていたのだ。しかし、そのまともに作ることのできるプログラマは「消えて」しまった。

あとを引き継いだ彼女は「消えた」プログラマほどの技量はなかった。彼女は「消えた」プログラマが残したフレームワークを理解することもできず、ただ、ソースコードを模倣した。

消えたプログラマの残したものは - megamouthの葬列

興味深いですね。

個人的には

プログラミング経験に関係なく、最初に書かれたコードというのは非常に影響力が大きいものであると感じてます。それはそのソフトウェアの設計思想を決定づけるものであり、脈々と受け継がれていくものだからです。優秀なプログラマであるないに関わらず、多くのプログラマは元の設計思想を尊重し、それに合わせたプログラムを書くもの。それがリライトした方が遥かにいい、ヒドいデザインのものでない限りはね :)

そしてプログラムがヒドいものになっていく原因の多くはこの「最初の設計思想」にあることが多いのです。いわゆる要求事項。このプログラムは誰が何のために使うのか。優先すべき性能はどこにあるのか。そして相反する要求があった時、何を基準に機能を決定するのか。もっと言えば、そもそもそのプログラムは必要なのか!?(笑)

そういった設計思想はコードに反映され、伝承されていきます。設計思想が曖昧なプログラムはその後場当たり的な対応がなされ、そのうち使えなくなって最後は捨てられます。書いてて頭痛くなってきた ^^;

そうならないよう精進しますです、はい。

そういえば

カーゴ・カルトという言葉を初めて知りました。盲目的なコピペコード、うんうん、あるよね、そういうの。反面教師にします :)

残業を減らそうだけじゃ、単なる思考停止じゃない!?

もう30年以上前の話。まだ社会人になって数ヶ月あまり、定時で帰ろうとした私を「ちょっとちょっと」と課長が呼び止めた。何かなと思って行くと「仕事というのは定時になったら帰っていいものではない」と説教された。「?」と思ったが、まだ新人だった私は素直にその日は意味もなく残業。それを見ていた先輩社員も「オレも昔はよく怒られたなあ」と言っていたから「そんなものなのかな」と思ったけど、今そんなことしたらパワハラものですな :)

IT業界に限らず、残業が減らない原因の根幹はこれだと思う

 表面的には「早く帰れ」「効率的に」などと言っていたとしても、本音の部分では違っていたりしますから、そのニュアンスは社員にも伝わり、どんな施策をとったとしても、その徹底度は薄れてしまうでしょう。

「何でもいいから4時に帰れ。できないなら辞めろ」…この命令は正しかった | ダ・ヴィンチニュース

結局のところ、いくら会社が「早く帰れ」と言っても、上司や同僚がいつまでも帰らなかったりすると、早く帰ることに後ろめたさを感じたりするわけです。上司や上の人が「ほらほら、早く帰って」とか言わないと、部下は「自分の評価が下げられたりしないだろうか」と不安になるもの。

根底にあるのは、数十年前の日本企業によくあった残業する人は頑張ってる人っていう価値観が今も企業の上の人に根強くあるということだと思う。残業をすれば企業の支出が増えるので、利益が減ることになる。長時間残業が続くと社員は疲弊し、作業効率が落ちる。結果、納期も伸びて、会社の支出は更に増える。はずなのだが、実際には残業してると怒られるどころか「頑張ってるね」と褒められたりする。

まずは会社の上の人に対する意識改革が必要だと思う。

あと

もう一つは日本企業によくある「みんなで一緒に頑張ろう」の弊害。作業が早く終わった/時間に余裕がある人は他の人の作業を手伝いましょう、ってやつ。

するとどうなるか。効率よく仕事を手早く終わらせる優秀な人に、終わらない人の仕事がまわってくる。いっぱい仕事がまわってくるのに感謝もされず*1、それにより評価は多少良くなったとしても収入アップにつながることは少ない。「こんなに頑張ってるのに、給料が変わらないなんて、どういうこと!?」という不満が募り、会社からは優秀な人からいなくなることになる。

そもそも

なぜ長時間残業が常態化しているのか。理由はそれこそ千差万別なはず。まずは原因を突き止め、それに対して有効な対策は何かを考えることが必要なはず。

たぶん本当の理由は言いにくいことなのだ。「今日は定時間日です。早く帰りましょう」なんて、見たくない事実から目を背けるための言い訳なのだ。

残業を削減するのは手段の一つであって、目的じゃないはず。

最終的には

不満の多くはお金なのです。「自分はこれだけ頑張ってるんだから、それに見合った見返りが欲しい」ってことかと。そこをうまくバランスするしかないんじゃないかな。

*1:必ずしもそうではないが、当然という扱いをされることが多い

世の中の半分ぐらいの人はプログラマになれるそうです

逆に言えば40%もの人にプログラミングの素質があるということで、それはけっこうスゴイことなんじゃないの!?専門性を必要とするソフトウェア以外のエンジニアや芸術家・音楽家なんかはそんなに高くないでしょ!?こりゃもうみんなプログラマになっとけ、って感じなのでは :)

ふたこぶラクダという名前で知られている有名な論文がある。この論文では、60%の人間にプログラミングの素質がないと推定している。

本の虫: 60%の人間はプログラミングの素質がない

ちなみにうちの息子(小学校高学年)にscratch教えたら、他の人のプログラムとかチュートリアルとか見て、あっという間にプログラム作れるようになってました。いいなー。その柔軟な脳みそ欲しい^^;

息子やいろんな人を見てると

プログラムが出来る出来ないの差って興味があるかないかっていうのが出発点になっているような気がしました。ここが最初の分岐点。

で、次のステップは、プログラマにとって重要な「教えなくても勝手に自分で調べたり試したりしてモノにしていける」かどうかで、それはコンピュータを使って自分のやりたいことが明確になっているかどうかなのだと思います。「これを実現したい」->「じゃあどうすればいいか」->「なるほどこうすればいいのか」->「じゃあこれを実現するには」というループが自然にできている人は覚えるのが早いです。

あとは何か分からないことがあった時にアドバイスをくれる人も重要かな。それも答えを教えるんじゃなくてヒントをくれる人がいい。そうすれば理解した喜びを味わえて、学習のモチベーションが上がり、どんどん学んでいけます。

「好きこそ物の上手なれ」とは、昔の人はよく言ったものです。

コンピュータさえあれば

自分の望むものを作ることができて、結果がすぐに分かる。作り直すのに部品屋さんに行く必要もない。何かを作るという点において、コンピュータソフトウェアほどお手軽なものはないと思います。慣れるとパズルゲームのようで、とても楽しい。パズル好きの人はきっと気に入ると思う。

世の中の半分ぐらいの人は素質があるわけですから、あなたもぜひプログラミングを初めてみては!? :)

あなたはなぜプログラマをしているのですか?

子供向けプログラミング講座が大人気らしいですね。私も妻によく「息子にプログラミング教えてよ」と言われます。

でも、こうも言われます。「息子は絶対プログラマにはしない」と。なぜかと聞くと「遅くまで仕事させられるわりには給料が低い。業界自体がブラックだから」だそうです…

「スタートアップならハードワークは当然」「この業界では定時帰宅なんてムリ」…

ワタミの失敗〜「善意の会社」はなぜブラック企業の代名詞になったか(新田 龍) | 現代ビジネス | 講談社(1/2)

妻の認識は大体世間一般の認識と一致しています。IT業界は大方ブラックというのが通説になってますね。ネットで検索すれば多くの「IT業界の悲惨な現状」を目にすることができます。さらに「そんなのはウチに比べれば全然大したことはない」と、不幸自慢大会が始まります(笑)パロディ漫画のネタも枚挙にいとまがありません。

確かにそういった側面があるということは否定しません。下請けであるが故に無茶な仕様変更に対応せざるを得ないケース。大企業であっても見込みの甘さからデスマーチに突入するケース。残念ながらそういったことは少なくありません。

でも

IT企業の全てがそのような状況というわけではありません。バブル経済の時代、私も基本給より残業代の方が多いということもありましたが、現在は長引く不況により、多くの企業は残業代を削減する方向へ向かっています。会社にもよるが、昔のようなムチャな残業は全体としては減っている印象ですね。

加えて近年はフレックスタイム制など、作業時間を比較的自由にできるようになってきました。まだまだこれからではありますが、だんだんとプログラマの価値を企業が認識してくれるようになってきてはいます。

あなたはなぜプログラマをしていますか?

人によって理由は違うと思うけど、多くの人はプログラムを作ることに喜びを感じているから、プログラマをしているのではないですか!?

初めて作ったプログラムが動いた時の喜び。ずっと分からなかった問題の原因が分かった時の爽快感。苦労して作ったソフトウェアがリリースされた時の達成感。そういう気持ちがあるから、プログラマを続けているのではないですか!?

別にウソを言えとは言いません

でも不幸な現状を嘆くだけではなく、できれば前向きな提案もして欲しいのです。プログラミングに興味を持つ若い人たちに、希望を感じさせるようになって欲しいのです。

そして、嬉しいことがあった時は、ぜひその気持ちをシェアして欲しいのです。プログラミングって、こんなに楽しいんだよって :)

転職って、運だと思う

求職者は求人票を見て、この企業に入ったらどんな環境で開発するのか、どんな人達とどんなふうに働くのか…というように「そこで働く自分」をイメージします。情報が少なすぎる求人票では、「どんな会社かわかりにくい」と不安に思われてしまうのです。

なぜエンジニアを採用したい企業が、転職志望者を不安にさせる求人票しか作れないのか? - paiza開発日誌

ほんとこれ。人事の採用担当者と開発者、全然話してないでしょ、って感じの求人情報が多すぎる。エンジニアは採用部署がどんな開発をしてるか、どんな人を求めてるのか、開発環境はどんな感じなのか、ということを知りたいのに、そういう情報が全く書かれてないと、受けてみようかって気もなくなっちゃうよね。言語の経験は何年かとか、TOEICは何点かとかより、どんな業務をしてて、どんなことができる人を求めてる、って書いた方がイメージしやすいと思う。

面接にしても、課題を与えてコーディングさせてみるってところも多いんだけど、あれってどれだけ意味があるんだろうか。技術者なら少し話せばその人のスキルは大体分かるだろうから、むしろ全く知らない分野の担当になったとしたら、どのくらいの期間でどんなふうに技術を学ぶかとか、トラブルシューティングをさせてみて、問題解決のためにどんなアプローチをするかとか、そういうことに時間を使った方がいいと思うんだけどなあ。まあ私は採用担当じゃないけど(笑)

会社が求めてる人が分からない状態で入ってしまうと、お互い不幸にしかならないよ。マッチング大事。

そういう意味で、募集する側としても、どんなことをしたいのか、どんな環境が好きなのかということをアピールすべきだと思う。それも正直に。面接の時だけ猫をかぶって、後から「こんなところだとは思わなかった」ってなるのはイヤだよね。

以前、エンジニアの方々に転職方法について聞いてみたことがありますが、この業界は優秀な方ほど、求人経由ではなく縁故で転職される方が多いです。エンジニアの場合、縁故による転職の割合は他の職種と比べてかなり高くなっています。

ぼくは全然優秀じゃないけど、これまでの転職は全部縁故だった。コネクション大事。

上司やイヤだったとか、会社がブラックだったとか、ネガティブな理由で転職する場合であったとしても、会社の人全てがキライだったわけではないだろうから、前の会社の人とのコネクションは作っておくことをオススメします。将来きっと役に立ちます。

転職って

「運」だと思うのですよ。

会社が社員に期待すること。社員が会社(職場)に期待すること。のマッチングは凄く難しくて、会社に入ってみて初めて分かることも多々ある。しかも外からはなかなか分からない。そこはもう「運」しかないと思う。さらに全てにおいて満足できる職場なんてあり得なくて、最終的にはどこかで妥協点を見つけざるを得ない。

タイミングも重要。「自分にとって理想の職場」が見つかったとしても、その時会社が人材を募集しているかは「運」でしかない。

「運」はいつ降ってくるか分からない

だから、自分が職場に望むこと(望まないこと)を日頃から明確にイメージしておくって大事なことだと思う。そして、それを継続してアピールし、実践し続けることで、だんだんと自分の理想に近づけていけるんじゃないかって、yasuhoは考えてる。

昔X68000というパソコンがあった

じゃあ「すごく良いお店で閉店して欲しくないお店」を閉めさせないようにするにはどうすれば良いのか? 答えは簡単です。ちゃんと通えば良いんです。

「予約の取れない店」が3年で閉店に追い込まれる理由 (cakes) - Yahoo!ニュース

X68000というパソコンがあった。

そのパソコンはCPUからアーキテクチャに至るまで、今までにない全く新しいコンピュータだった。当時としては広大なメモリ空間がフラットに扱えるモトローラMC68000をCPUとして採用し、多くのスクリーンモードを持つ高機能なグラフィックプロセッサを搭載したX68000には、私を含めて多くの人が衝撃を受けた。

X68000 - Wikipedia
X68000は死なず? ~20年の時を超えて筐体復刻の動き~|APPREVIEW

非常に話題性はあったのだが、専用モニター込みで500,000円(!)という、当時のPC-9801 2台分ぐらいの価格で、購入に至った人は多くはなかったと想像している。私はソッコーで予約し、発売日にゲットしましたが :)

そんな状況に加えて

新しいアーキテクチャであったため、ソフトの発売本数も極端に少なく。ゲームソフトが出るたびに何か買ってたような気がする。よく当時のことを振り返って「X68000がなくなってしまわないようにユーザが買い支えていた」という記事を見ることがあるけど、ぼくの感覚ではみんなX68000で動くソフトウェアに飢えていたという感じがある。

そう。ぼくらユーザは、X68000の性能をフルに活かした、未だ見たこともない映像とサウンドに期待してソフトを買っていたんだ。あの美しい画面とサウンドを堪能したい。そんな感じだったと思う。心のどこかで「まあマイナー機種だから、なくなってもしょうがないよね」って、どこか冷めた目で見てた。

そのうち徐々にソフトの販売本数も増えてきて、X68000は黄金期を迎える。PC界がDOS/VWindowsへ移行していく中で、X68000のソフトウェアは徐々に減り始め、それと共にX68000を使うことも少なくなっていった。起動しなくなったとはいえ、本体は今でも実家で眠っている。

どんなにハードウェアやアーキテクチャが優れていても、ソフトウェアがなければどうにもならないという、至極当たり前の昔話。

記事を見て

そんなことを思い出しました。