舎路(シアトル)日記

シアトルで働く日本人プログラマの日記です。

「アメリカの働き方は最高! それに比べて日本は……」本当かどうか聞いてみた というのが面白かった一方、自分の実感とは違う部分もあったので書いてみる。

国単位で働き方を語る難しさについて

国、という大きな単位で働き方を語るのは難しい。会社の規模や業種によっても違いがあるし、その当時の景気や、その人の立場、住んでいる場所によっても見てきた景色は違うだろうと思う。

元の記事の最後に

※今回の記事はあくまでお二人が経験した範囲内のお話です

とあるのと同様に、これも自分が経験・見聞きした範囲の話です。

解雇

いまのところ、同僚が突然消えたりといった憂き目にあっているのをみたことはない。一方で、これは会社の景気の良い時期を体験しているだけ、という自覚はある。テック業界だと、例えば Twitter の2015年のレイオフはよく知られている。

Twitterでレイオフも体験したNY在住エンジニアが語る「波瀾万丈な人生」を楽しむ方法

2015年10月、全従業員の8%にあたる336人がレイオフされました。さまざまなチームが対象となり、僕のいたチームは数人を除いて全員がレイオフの対象となったのです。

ただ、日本でも労働組合のないような会社で、景気があんまりよくないと、配置転換による指名解雇もどきをするという話を見聞きしたことはある。

いきなり研修部屋へ ミクシィ不可解人事

それまで取り組んでいた業務を強制的に中断させられ、いきなりカスタマーサポートのトレーニングを強いられる──。これは、退職勧奨のための、いわゆる「追い出し部屋」ではないのか。

ドワンゴは大量退職に関する印象操作をやめろ

最後は総務部を追い出し部屋にしたことです。やめさせたい人間をグループウェアから登録解除し、総務部という名前を持った統合思念体に統一し、PCも共有で1台しか与えない。昨日までエンジニアをしていた人間がスーツを着て社内を歩いて備品の補充をする。そんなことが許されていました。

なので「日本の雇用が守られている」といっても、この程度のことは雇用者側から見るとアリなんだよ、というのは書いておきたい。

残業

日本でも少し前にホワイトカラーエクザンプションに関する議論があったけれど、アメリカでは Fair Labor Standards Act に Computer Employee Exemption というのがあって、一定以上の給与をもらっているプログラマは、すでに残業代規制の対象外になっている。残念。

定時という概念が希薄で、タイムカードとか押さなくて良いのは気楽ではある。

教えて育てる

これが、個人的に一番ギャップを感じたところだった。私の周りの人々は mentorship というのが好きだし、求人サイトを “mentor” で検索すれば

Ability to mentor team members as well as build relationships with business and technical leadership

みたいなことが募集要項に入っていることも多々ある。ただこれも、企業の文化であるとか、インターンを雇うくらいの余裕がある規模とか、そういったものに左右されるのかもしれない。

フェアネスと合理性

フェア、というのはアメリカの人々には大事な概念らしいのだけど、日本人の私にはその重さが今ひとつわからなくて、あんまり日常では使わないようにしている。”it is an unfair comparison” というより、”it is not apples-to-apples” くらいにしておいた方が波風が立たなそうな気がする、けど思い込みかもしれない。

セーフティーネットがないのを「合理的」と呼んでいいのか、というのは議論があるところで、例えば、最近人気のある Alexandria Ocasio-Cortez 下院議員は、深夜番組のインタビューで「最低賃金を引き上げるのは経済的にもプラスの効果がある」という話をしていた。彼女はそもそも、社会として医療保険を提供することや、労働組合の重要性を訴える Democratic Socialists of America に所属していて、民主社会主義派を名乗るくらいなので、政策も左側に傾いている。

そういう主張がそれなりの支持を集めているのは、私は良いことだと思っているけれど、もしかすると政治の二極化が進んでいるだけと見る人もいるかもしれない。

Code Ownership and Software Quality: A Replication Study を読んだ。マイクロソフトのコードベースを対象に、オーナーシップと品質との相関を調べた論文。先行する研究として

の二つがあり、この論文はそれらをうけて、1) マイクロソフトのコードベースを対象に 2) バイナリよりも小さい粒度 (ファイルやディレクトリ) で、その相関を調べている。結論からいうと、オーナーシップと品質にはやっぱり負の相関があったらしい。

ソフトウェアないしコンポーネントのオーナーシップというのは、ひとえには決めづらい。論文では

  • ownership: もっともコミットした数が多い人が、全コミットのうちに占める割合
  • minors: コミット数が50%未満の人の数
  • minimals: コミット数が20%未満の人の数
  • contributors: コミットした人の数
  • avgownership: ownership のディレクトリごとの平均
  • manager3: コミットした人々のユニークな Level 3 マネージャーの数

などなど色々なメトリクスでもって、なんとかオーナーシップの強さ、というのを求めて、それとファイルやディレクトリごとのバグの数とを比較するべく、ランク相関 (Spearman 相関) を求めている。ちなみに Level 3 というのは

For Microsoft, we can infer that managers represent at level 3 company divisions, at level 4 broader product teams, and at level 5 smaller sub teams within product teams.

部長、くらいのところなんでしょうか。

企業からの論文で、かつバグについての話だというのに、Office, Office 365, Exchange, Windows なんてフラッグシップな製品について実名をあげて論じて、さらに

With Office, we could see that there are two types of weak ownerships: intentional weak ownership, which was due to the aforementioned reasons, and unintentional ownership.

こういう不都合なこともちゃんと書くのは、なかなかえらいなあと思う。

Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications を読んだ。

従来よく計測されがちな

  • Page View
  • Uptime
  • Latency
  • Seven-day Active Users
  • Earnings

あたりは、ユーザーエクスペリエンスの観点からいうと低レベル or 求めているものに対して直接的ではない。ページビューが上がったのは、ユーザーに好まれているからか、混乱するのであちこちクリックされているからなのか、わからない。

そこで著者らは

  • Happiness: このプロダクトが好きですか、みたいな主観的指標。サーベイなどで取得する。
  • Engagement: あるユーザーが何ページ巡ったかや、単位時間あたりの写真アップロード数など。
  • Adoption: 新規ユーザー数
  • Retention: ユーザーの継続率
  • Task Success: ユーザーがタスクを完了するまでにかかった時間や、それまでにみたユーザー向けエラーの量など。

などを測るといいよ、と提案する。

大学との共同研究ではなく、著者らはすべて Google の人々なので、これら一つ一つに「例えば Gmail では」みたいな事例がはいっていて、そこは面白い。一方で、新手法を提案する論文なら出てくるような、同じタスクを一般的な手法と提案手法とでやってみて、これとこれは相関していて、みたいな議論は一切なく、有用性に関しての議論が「Google で使われてます!」だけなのは、ちょっと物足りない。

後半では、ゴール (達成したいこと), シグナル (それが達成できたかを示すなにか) があって、最後にメトリクス (時系列にプロットできるような指標) があるんですよ、という話もしている。

Rust のパーサコンビネーターの一つ、nom についての論文である、Writing parsers like it is 2017 を読んだ。著者らが「2017年らしく」と設定する基準は

  • C/C++ ではなく安全な言語を使うこと
  • 手書きの parser ではなく parser combinator を使うこと

正直そこまで目新しくはない。

どちらかというと、Rust + nom が実現する C/C++ との親和性とパフォーマンスでもって、既存のアプリケーションの一部を置き換えられることを示すべく、VLC の FLV パーサーや、Suricata という IDS (Intrusion Detection System - 侵入検知システム) の TLS パーサーを、実際に Rust で書き直してみせているのが見所かと思う。

いまどきのパーサーがどうあるべきかについては、IntelliJ の Rust プラグインや、Rust コンパイラをあえて使わない Language Server の Rust Analyzer の開発で知られる、Aleksey Kladov がブログに書いていた、Modern Parser Generator が「IDE のことをちゃんと考える」という視点を持ち込んでいて新鮮だった。

運転むずかしい

Jan 17, 2019

アメリカでも街の方に住んでいるのをいいことに、車の運転から逃げつづけてきたけれど、さすがに観念して自動車学校に通っている。

筆記試験は去年にクリアして、今週は会社に行く前に自動車学校に通っていた。正直いって、車を運転するのは難しい。みんなよくできるなと感心する。当初の予定では5回の講習をうけたあとに実技試験を受けるつもりで予約を入れていたんだけど、どうにも無理そうなので試験は一度キャンセルすることにした。同じ教習所でまた追加で5回レッスンをうけるか、他の教習所でうけるか、何か他のことをするかは考え中。

一方で、車を運転して今日で3日目、時間にしてまだ3時間にも満たないわけで、あまり悲観的にならないほうがいいだろうとも思う。「プログラミングを初めて3時間たつんですが、全く上達しなくて、私は才能がないんでしょうか?」なんて相談されたら困るだろう。

そんなことを自分に言い聞かせながら、しばらくは練習を続ける予定。