舎路(シアトル)日記

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

Q3 をふりかえる

Sep 30, 2018

Rust

英語ブログのほうは、Rust についてだけ書くことに決めてみた。

そのほかにも、rust-lang/rust に細々とした修正を送ったり (いまのところ8コミット)、RustConf のために8月にポートランドに行ってみたり、Seattle Rust Meetup にも何度か参加してみたり、Rust に割いた時間は多かった。

日本語ブログ

日本語ブログはテーマらしいテーマもなく書いている。

二つ目の記事がすごく読まれたのは良かった。

「あの人は言葉づかいは乱暴だけど根はいいひとで」「厳しさのなかにも優しさが」みたいな人物像は日本に限らないことだとは思うんだけど、この乱暴さや厳しさとかって別に必要ない、可能ならば取り除けるに越したことはないのでは、と最近は思う。

もっというと、私は 2ch 世代というか、直接的でともすれば乱暴なコミュニケーションを、新しくて効率的なものと思っていたきらいがある。そういうのは平成で終わりにしたい。

仕事

キャリアについて少し自覚的になれたことと、社内カンファレンスに参加したり講演の動画を見たり、といった時間を意識的にとれたのは良かった。

ミーティングで中断されがちなせいか、今日はこれだけしか出来てないのか、と思うような日が多いのは良くなかった。AWS 側の大物である Colm MacCárthaigh さんが

Unpopular opinion: to really make it as a senior/lead engineer, you have to get good at soaking up interruptions, only managing or minimizing them for others not yourself. You just have to adapt to working productively in smaller time slices and handling context switches. Tough!

なんて Twitter に書いていたのは、私がいまそれを心配するのは杞憂かもしれないけど、どんどん偉くなって時間を細切れにしていくのが目指すところなのかというと、それはちょっと違うよなという気持ちになった。 ‏

育児

妻と離れることを子が非常に嫌がるので、最近 (といってもここ数日) は寝かしつけを代わったりしている。母親なしで父親と過ごす時間を増やすことが、母離れの助けになるらしい。

Q4 にむけて

Q2 に書いていたポモドーロタイマーはまだ毎日使えるようになっていないので、これは完成させたい。

こういう中途半端なものは他にもいくつかあったと思うので、なにかを新しくはじめるよりは、色々を終わらせていく四半期にしていきたい。

キャリア近況

Sep 28, 2018

30代も折り返しに差し掛かりつつあるせいか、自分のキャリアというか、いままでと、これからの仕事について考えることが時折ある。

グローバル志向の先にあった平均化

日本にいた頃の私のキャリアには、ぼんやりとだけど、グローバル志向という軸があった。これは、ミクシィの社員として Facebook や Twitter といったアメリカ生まれのサービスが日本を席巻していくのをみていた、苦い思い出からきているのだと思う。

「日本人はインターネットに実名をのせたりはしないのですよ」「自分の近況を随一報告するなんて暇人しかやらないのでは」みたいな予測がどんどん裏切られていくのは『山椒魚戦争』みたいでちょっとコミカルですらあり、それ以来、私は日本人の特殊さというのを信じきれずにいる。

一方で、世界中から人々が集まって作ってるソフトウェアに、東京で日本語を話す人々が集まって作っているソフトウェアが勝つ理由もないなあという諦念もあった。数の論理。目玉の数さえ十分あれば、どんなバグも深刻ではない。同時期に普及しつつあったスマートフォンもその悲観を後押しした。

今になって思うとこれはだいぶ単純な世界観で、当時の私は視野が狭かった。ミクシィはその後モンストで復活するし、メルカリや LINE は日本を主な市場として成功している。製品が成功しなくても会社が成功することはあるし、会社が成功しなくても個人が成功することもある。もちろんその逆もある。

それでも、当時の (やや正確さに欠ける) 現状認識は危機感に、危機感は行動につながって、英語を勉強して、アマゾンジャパンに転職したりしていた。

外資企業を渡り歩く人々はそれなりにいる。日本以外をすべて「外資」とくくるのも乱暴なはなしだけど、投資銀行からアマゾンにきたり、アマゾンからグーグルに行ったり、そういうキャリアはそこまで珍しくもない。日本のスタートアップに入る人々はちょっと珍しくて、経歴から「元グーグル」という肩書がなかなか外れなかったりする。

日本にいたら次の転職はそれで乗り切れたかもしれないけれど、私は結局シアトルにまで引越してしまった。アメリカに来て現地の人々に紛れてみると、私のキャリアはとりたてグローバルといえるものでもないことに気づく。みんな英語はできるし、アメリカ以外の国で教育を受けたり、働いたりしたことのある人は珍しくない。

私は平均的になってしまった。

専門性とその軸

シアトルに来てから4年、何回かチームを移ったりもしたけれど、こうして振り返るとあんまり軸といえるものがない。社内でよく使われがちな技術スタックには詳しくなったし、よく質問したり調べたりしたとは思うけれど、得意を作るよりは苦手を減らす期間になっていたように思う。まわりの評判は悪くないし、all rounder として評価されることもある。でも、このままで良いのかというと不安がある。

そういったわけで、最近は “The Passionate Programmer” を読みながら、今後の方向性なんてものを考えたりしている。昔に “My Job Went to India” というタイトルだった頃に読んだ記憶があるけれど、久しぶりに読んでみると良いことが書いてある。

This book isn’t about struggling to maintain the level of mediocrity required not to get fired. It’s about being awesome.

かっこいいし、かくありたい。

morrita さんは以前に “Soft Skills” との対比を指摘していたけれど、一方で二つに共通する部分もある。自分の専門性を意識して作ること、というのはその一つだ。私はこれがまだ出来ていない。

私は他人の作ったスタックに過剰に肩入れして、インターネットで我田引水の議論を繰り広げる人々があまり好きではなくて、それを専門性をはっきりさせないことや、仕事で好きな言語を使わないことの、言い訳にしていたきらいがある。「製品の成功こそが重要であって、言語は重要でない」と言ってみせるのはかっこいいし、我田引水をする必要はないけれど、過剰な肩入れのリスクはリターンでもって報われることもある、という認識が薄かった。

最近 Rust の話をしたり、それがらみのイベントに行ったりしているのは、言語自体が好みというのもあるけれど、専門性をちゃんと作って、自分を周りから差別化しないと、という意識もちょっとある。

専門性はプログラミング言語に限らない。例えば、プロダクトマネージャーと組んでアプリケーションを作る仕事と、時系列データベースがメモリからディスクに書き出すのをどうこうするような低レベルな仕事のどちらを選ぶかという軸もあるし、国際化やアクセシビリティみたいな分野のうちどこを選ぶかという軸もある。交通や決済といった業界も軸になるだろう。

もちろん全てが出来たら素晴らしいけれど、それは無理そうなので、だんだん意識的に仕事を選ぶようにしたいなと思う。

エンジニアを育てるはなしが、たぶん以下の Takuto Kihira さんの tweet をきっかけに盛り上がっていた。

昨日の飲みで、某CTOが「エンジニアを育てるって言うけど、紀平さん誰かに育てられました?自分で育ったでしょ?だからエンジニアに対しては、頑張れ、としか言いようがないと思うんですよね」って話をしていて、まあ確かにそうだと思った。自分はしかし親に環境を用意してもらったな。本とかPCとか。

私の立場は、Dai MIKURUBE さんの tweet に近い。

エンジニアの成長について「自分は自力で育った」「今まで見てきた人は誰かに育てられたというより自力で育ってきてた」は観察としてたぶん真なんだけど、「だからこれからもそれでいい」は明確に偽だと思うんだよなー。それって各種の職人業が次々廃れてるのと同じことを再現するだけのような気がする

私自身も大学で情報工学を学ぶまえに多少はプログラミングができたほうなので、独学で「育った」傾向があるんだけど、後続の人々も同じパスを通るべきかといわれると、そうとは思わない。

性格や環境が私と似通った人だったら、同じパスを通ってもいいとは思う。本やインターネットから情報を集めて色々試すのは私にとっては楽しいことだったし、それをする時間的な余裕もあった。自分でやったんだという自負が自信につながっている部分もある。

ただ、世の中には自分とは違った性格や環境で、かつエンジニアを目指しているひとも沢山いるはずで、そういう人々には他のパスのほうが適しているかもしれない。いまの教育やコミュニティのありかたが、ある種の人々、たとえば女性を、不必要にフィルタリングしてしまっている可能性はあると思う。

Increasing Rust’s Reach

最近みて感心したのは、Rust というプログラミング言語の人々がやっている Increasing Rust’s Reach というプログラムだ。

This program matches Rust team members from all parts of the project with individuals who are underrepresented in Rust’s community and the tech industry for a partnership of three (3) months, from mid-May to mid-August. Each partnership agrees to a commitment of 3–5 hours per week working on a Rust Project.

ここでは、Rust チームのメンバーと、Rust コミュニティであまりみかけない (underrepresented な) 人々とをつないで、定期的なミーティングの機会や、カンファレンスへの渡航費の支援なんかを行っている。

“underrepresented” というのは明確には定義されていないけれど、今年の参加者 をみると、ジェンダー・人種・国籍あたりが考慮されているのだろうと思う。

Rust は比較的新しいプログラミング言語で、コミュニティを広げるまえに、言語やライブラリに対してやることがあるだろうという意見もあるかもしれない。ただ、コミュニティが大きくなっていくことは、結果として言語やライブラリに対して良いフィードバックがあるはずで、どちらも同時にやる必要がある (コミュニティについて働きかけるのは、余力ができてからやることではない) というのが今風の考えかたなんだと思う。

Recurse Center の Social Rules

もう少し草の根で、個人でも注意できるようなものには、Recurse Center の Social Rules がある。

Recurse Center はプログラミングができる人むけに、より学ぶための場を提供している施設ないしプログラムで、以前は Hacker School という名前だった。実際になにが行われているかについては、ニューヨークのエンジニアコミュニティについて。Hacker Schoolでプログラミング修行中 がわかりやすい。

Recurse Center の Social Rules は4つの禁止事項からなっている。

  • No well-actually’s (それは実は…で話を遮らない)
  • No feigning surprise (知らないんですか! と驚いたふりをしない)
  • No backseat driving (会話に突然割り込まない)
  • No subtle -isms (お母さんでも使える、みたいな微妙な差別をしない)

ここで禁止されているコミュニケーションのいくつかは、もしかすると、コミュニティによっては許容されているかもしれない。どこからがだめなのか、という線引きの難しさについては Recurse Center も自覚的で、Social Rules の冒頭には

One thing that often confuses people about the social rules is that we expect people to break them from time to time. This means they’re different and totally separate from our code of conduct.

という但し書きがある。

私も、勉強会なんかで、発表している人の話を突然さえぎって間違いを指摘する人がいても「勉強会は相互に学びあう場であるし、間違いを指摘されるのは別に恥ずかしいことではない」「モヒカン族から手斧が飛んできた」とかなんとか許容してしまっていたように思う。

あるコミュニティのなかでのコミュニケーション様式は、最終的には個々のコミュニティが決めるべきものだけれど、ある種の振る舞いを「あり」としたときに、それを苦手とする人々を遠ざけてしまう可能性であるとか、それと引き換えに何を得ているのか、といったことは立ち止まって考えてみてもいいと思う。

まとめ

エンジニアを「育てる」話を枕に、コミュニティのありかたを変えようとする、Increasing Rust’s Reach と Recurse Center の Social Rules を紹介しました。

後者については、自分が過去にできていたかというと大分あやしいけれど、最近は気をつけるようになりました。自分自身は、率直に物事を指摘する、勢いのある若手のつもりでいても、在籍年数を重ねるうちに、同じ振る舞いが想像以上に威圧的にとられてしまうこともあるので、みなさん注意しましょう。

すこし前に、Manning Publications から「こういう企画の持ち込みがあったんだけど、どう思う?」というメールをもらって、アンケートに答えるという機会があった。

Manning はアメリカの技術系出版社で、日本で翻訳書が出るときには、オライリージャパンをはじめ色々な出版社からでること、その際に表紙も変えられてしまうことも相まっていまひとつ存在感がないかもしれないけれど、jQuery の John Resig 自らが著者に名を連ねる Secrets of the JavaScript Ninja や、Keras の François Chollet が書いた Deep Learning with Python、ちょっと毛色が変わったところでは、higepon さんオススメの Soft Skills まで、手広くやっている。

技術系書籍の編集者の k16 さんは、英語圏のIT系技術書ブランドについての雑感

しかし現在は、この記事でも一押しの No Starch Press はじめ、やはり中堅どころの Manning Publications など、現時点で創業20年前後を迎えている中小の出版社のほうがむしろ精力的に面白い書籍を生み出している印象があります。

Manning を「中堅どころ」と形容している。

Write for Us

Manning のサイトには Write for Us というページがあり、Manning から本を出すまでのプロセスが詳細に説明されている。特に面白いのが最初に著者が提出しなくてはいけない企画の提案書で、そこには

  1. Tell us about yourself.
  2. Tell us about the book’s topic.
  3. Tell us about the book you plan to write.
  4. Q&A
  5. Tell us about your readers.
  6. Tell us about the competition.
  7. Book size and illustrations
  8. Contact information
  9. Schedule
  10. Table of Contents

という10個の項目について細かく質問がある。例えば Tell us about the book’s topic なら

  • What is the technology or idea that you’re writing about?
  • Why is it important now?
  • In a couple sentences, tell us roughly how it works or what makes it different from its alternatives?

Tell us about your readers なら

Your book will teach your readers how to accomplish the objectives you’ve established for the book. It’s critical to be clear about the minimum qualifications you’re assuming of your reader and what you’ll need to teach them.

こういった感じ。マッハ新書のような自費出版が話題をあつめる2018年には、すこし慎重すぎるような感じも否めないけれど、これで選別した企画にさらに編集者がついて質を担保するのが、インターネットで無料の情報が得られる時代に、出版社が担うべき役割だとも思う。

この提案書を送ると、Manning と外部の人々からのフィードバックが著者に送られる。

After we have had a chance to review your submission, we will send you feedback, both from us and from outside experts. As a rule, you can expect to revise your proposal several times during the discussions.

冒頭でふれた私が答えたアンケートは、おそらく、この “outside experts” からのフィードバックとして扱われるのだと思う。

まとめ

Manning というアメリカの技術系出版社についてと、その出版社が公開している企画提案書について紹介しました。

ちなみに、提案書を送ったあとの流れについてもシステマチックに流れが決まっていて、読んでみるとなかなか感心します。日本の出版社でも同じようなプロセスは決められているんだろうけど、私はそういうものを目にする立場にないので新鮮でした。

こういう質問を自問自答してみるのは、例えば自分でブログや YouTube チャンネルをはじめて、そのリーチを伸ばしたいときにも役に立つんじゃないかと思う。そこまでかっちりしたくないですかそうですか。

追記

萩原正人さんが、著者として Manning のプロセスをみた、海外で技術書をゼロから執筆・出版する方法 を書かれています。

Q2 をふりかえる

Jul 7, 2018

自分のソフトウェアを作る

4月のあたまに Swift でポモドーロタイマーを書きはじめた。最近はあまり進展がなく、毎日使えるレベルにも達していないけれど、これは Q3 も継続して完成させたい。仕事で Swift プログラマになりたいわけではないけれど、Mac はまだ数年は使うと思うので、自分のための小さなソフトウェアくらいは自分で書けるようになっておきたい。

仕事にできるといいなと思えるものだと、最近は Rust を勉強している。The Rust Programming Language は読みやすいけど、実際に書いてみるとよくコンパイラに怒られる。

rust-native-tls にプルリクエストも出してみた。

Rust に期待していることについては、またあとで書く。

読んだもの

論文ひとつ、育児書ひとつ、自己啓発書を2冊読んだ。片付けとかミニマリストの本も読んだけど、ここにはまだ書けていない。

寝かしつけについては、しばらく起きる時間を固定して、寝る時間とそれにいたる様子 (どのくらい寝たかとか) を日記につけていて、これは現状を客観視するのに役立った。最近さぼっているので、また再開したい。

仕事

仕事は難しい。将来を見据えつつも作り込み過ぎない、というのが上手くできずにいる。

社内にある 3D プリンタの使い方講座から、もうちょっと日々の仕事に関係のあるセキュリティがらみのものまで、いくつかトレーニングをうけたのはよかった。社内イベントの多さは大企業で働らくことの利点だと思うので、もっと積極的に参加するようにしたい。

久しぶりにインタビューもした。東京にいたころにも少しはしたけれど、シアトルにきてからさぼっていた。

そのほか

ここらへんは blog.8-p.info をちょっとリニューアルしたときの副産物、だったと思う。

書けていないこと

Q3 にむけて

Q3 の終わりには達成度が計測できるように、簡単なものでいいので具体的な行動も考えてみた。

  • ポモドーロタイマーを完成させる: 毎週に一時間程度は時間をかけるようにする。
  • Rust の勉強を継続: これも、毎週に一時間程度は時間をかけるようにする。しばらくは “The Rust Programming Language” を読むだけでいい。
  • 育児: 子供の起床/就寝時刻を記録する。
  • 仕事: 毎月に最低一時間は、社内リソースを使ってなにかを学ぶようにする。

ブログも本当はもうちょっと書きたいけれど、しばらくはここらへんを優先したい。