韓国人女性プログラマーの思い出（総集編）

これは、 PyLadies Advent Calendar 2018 の８日目の記事です
https://adventar.org/calendars/3116

そういえば、昨年も PyLadies Advent Calendar 2017 に参加したんだった 　https://adventar.org/calendars/2462
今回も Python はあんまり関係なく、女性とプログラマーについて書く。

過去、何度か、前職で韓国人女性プログラマーと一緒に仕事をした話を書いた。
https://nakagami.blog.so-net.ne.jp/2010-06-18
https://nakagami.blog.so-net.ne.jp/2012-05-12
https://nakagami.blog.so-net.ne.jp/2016-09-12

ざっくり言うと、
- オフショア開発がブームになる前に、韓国人や中国人に日本に来てもらってソフトウェア開発をしようというブームがあった
- 韓国では、それに合わせて「日本語とプログラミングを学んで日本で働こう」みたいなブームがあった
- 韓国に「日本語＋プログラミング」の専門学校がたくさんできて、そこで、日本の勤務先の斡旋もしてくれた
- 日本に働き始めると、リーマンショックで仕事がなくなった
ということで、転職を余儀なくされていた。

彼女たちの転職の条件は２つ
- 当面の給料が払われること
- 就労ビザを発行してもらうための会社側の手続きをしてくれること
将来にわたっての職の安定なんて考えてなかったと思う。

会社の規模や信用度によって、ビザの期限は1～3年だったが、そのビザが切れる前に再発行してもらうためには、受け入れ側の会社から提出しなくてはいけない書類があった。
信用も実績もない会社だったので、前回より多くの資料の添付を求められて、それでいて発給されるビザは１年だった。
（そして、現実問題としてアメリカ人と比べて韓国人の就労ビザ発給は難しかった）
会社も、やったことない手続きで大変だったと思うが、日本人なんか転職して来ないんだからしょうがない状況だった。
彼女らはJava とか PHP を書いていたけど、転職で Python を書くことになった。別にプログラミング言語は何でもよかったんだと思う。就労ビザさえ発給されれば。
僕が社会人になった頃の労働基準法では女性の深夜勤務は禁止されていたので、女性が深夜勤務することに抵抗があったが、彼女らはそんなのは気にしてなかった。
きっと、日本に来た時からそんな風に働いてたんだろうなぁ。

その時、結果として本人達にも会社にも良い結果になった。会社の業績はうなぎのぼりで大きくなり彼女らは引き続き日本で働けた。
「プログラマーって性別も国籍も関係なく、本人の努力と能力で未来が切り開ける職業なんだなー」
ってことを強く思った。


結局、東北の震災をきっかけに親に説得されて泣く泣く帰国したり、産休ののち出産して復職することなくやめたりして、あの時の韓国人女性たちは、もう誰もその会社に残ってない。
本人たちには不本意だったと思うが、良い思い出のまま会社を離れてくれて僕にとっては良かった。

情報系多能工

これは、BeProud Advent Calendar 2018 https://adventar.org/calendars/3338 の８日目の記事です。

私が最初に弊社ビープラウドの受託開発案件に参加したときに一番驚いたのは、人員の入れ替えが臨機応変に行われていたことだった。
お客さんの受け入れ態勢ができてないとか、仕様が確定していないというときは、
「じゃ、別の仕事してましょうかね」
ということで別案件をやって、再開できたときには別の人がアサインされることもあるし、間に合ってないときに人が一時的に投入されたりする。

その時点からさかのぼること10年前の受託開発の経験では、最初に３人*３か月＝９人月で契約できたら、３人を３か月拘束して人を入れ替えることはないし、お客さんの都合で納品を伸ばしたい、開発を一時サスペンドしたいという場合も、次の仕事がアサイン済みであることとか、資金繰り（予定した期日の入金が必要）とかで臨機応変に人のアサインを組み替えるとか、納期の延期ができなかった。
年度はもちろんのこと、クォーターごとの売り上げ計画にぶれがあることを嫌ったからだと思う。当時は、バブルの直後ぐらいで、まだその会社も遠い将来の上場を目指していたから、計画と実績がずれるのは許されなかったのかな。

引き合いが来た時の、お客さんへのヒアリングは、元職では課長か部長が、（もう長いこと開発から離れているのに）わかったふうで微妙な要件で契約を決めてくるので、円満に納品するのが苦しい時も多かった。
（元職では、営業という職種がいなかったのがせめてもの救いかな）

ビープラウドでは、開発者がヒアリングすることもあるし、その案件を受注したら別の人が担当することもある。（課長や部長の一存でなく）相談して無理そうなら断ることもある。
思い返してみると、元職では課長の方針・・・という名の趣味に案件が左右されてた。
ビープラウドでは、役員以外の役職はなく、役割も固定されていなくて、僕自身も、コードを書く時もあれば、コードを書かずに要件、仕様から作業を切り出して開発者にチケットを振ったりコードレビューをしたりする時もある。今年は、20年振りくらいに一人開発案件もやった。
最近、 PyQ スタンダードプランをご契約のお客様の質問に、たまに回答している。

これは製造業や建築業で話題の「多能工」だなって思う。

- 資金繰りに余裕がある
- 製造業的な生産計画にこだわらず実利をとる
- 役職や部署による情報格差をなくす (by slack)
- 開発案件が Python (+Django)で標準化されているので、人の入れ替えがしやすい

というあたりが、それを可能にしたポイントなのかなと思う。

僕は、このやりかた、受託開発の会社としては、すごく変わっていると思うんだけど、みんなはあまりそう思ってないのかも。