単なる「プログラマ」でありたいと願っていたが、その夢が破れつつあると感じる。今の自分はモバイル・プログラマである。今から他のものになるのはだいぶ大変。

気のせいかもしれないが、世の中からも単なる「プログラマ」は姿を消しつつあるように見える。だいたいもうちょっと限定がついている。Frontend engineer, backend engineer, SRE, data scientist とか、いわゆるインターネット企業の中だけでもこれだけある。自分が学生だった 15-20 年前にこうした細分化はなかった気がする。もちろんゲームとエンタープライズのような業種の壁はあったけれど、それ以上は細分化していなかったような。

自分の視野が狭かっただけで、昔からそれなりに色々あった可能性はある。逆に、自分と同年代の知り合いにもたとえばガラケー向け組み込みから現代的なモバイル、ウェブ、今はクラウドバックエンドと河岸を変え続けている人もいる。だから職能の細分化にしろ分野の壁にしろ必ずしも一般化できる普遍的なものではない、かもしれない。

と前置きした上で、細分化が実際におきているとしたらそれはなぜだろう。情報産業が成熟したからと考えるのが自然に思える。成熟に伴い給料は上がり世間から認知もされた。それと引き換えに専門化を求められた。

成熟の程度は産業の中でもばらつきがある。自分は大企業勤務なので細分化はより顕著に感じる。ここには自分がどうやってもたどり着けない専門家がたくさんいる。一方で比較的成熟の浅い、若くて小さい企業ではより広い職能が求められる。産業全体の成熟と産業の内側での spectrum を区別するのは自分には難しい。

特に細分化は進んでいないとしたら自分の感じているものはなんだろう。たぶん老化、よくいえば成熟、なのかもしれない。一人前に給料をもらうための期待値が昔より高くなった、これが成熟。一人前であるための能力を新たに獲得するのが難しくなった。これが老化。期待値が高いのは obligation のためでもあるから、人生の都合という面もある。

産業全体としての職能の細分化と自分の立場を区別するのもやはり難しいし、区別することに大きな意義も感じない。自分の前に職能の壁があるのはどのみち事実だから。

有り余る能力があれば、あるいは経済的な自由度が高ければ、職能を超えて「無印のプログラマ」、ジェネラリストでいることができる。自分にはそれがない。

専門家になるというアイデアを受け入れることはできないのか。自分は既に一度ウェブブラウザの専門家になるのに失敗し痛手を受けている。そして専門にしようと期待していた Android を好きになれず、再び失敗している。専門家のなりそこないである自分という事実を認めたくないから無印のプログラマというファンタジーに逃げ込もうとしている面はある。

ただ純粋な逃避でもないと思う。テクノロジは移り変わる。時代にあわせて自分の専門を切り替えていかないとやがて行き詰まる恐れがある。無印のプログラマは、素朴なジェネラリスト信仰ではなく専門を乗り換えられる実力への aspiration でもある。

そう考えると、職能の壁と感じているものは時代の流れの速さに過ぎず、自分の不安は時代から取り残される恐怖なのだろうか。そんな気がしてきた。職能の細分化とかいうのは年寄りの愚痴だったか。腑に落ちた。

そのむかし、テレビドラマなどにでてくる「サラリーマン」たちの仕事がなんなのか長らく謎だった。上司が「やっておいてね」とデスクの上にドーンと置いていく紙束とか。紙束を「やる」とは何なのか。

しかし自分が日頃電子的にやっている作業が仮に紙ベースだと考えるとだいぶ腑に落ちる: メールを読む/書く。バグをたらい回す。コードレビュー。Design doc.

上司や TPM につつかれるバグのトリアージとか、まさにドーンと置いて行かれた電子紙の束。

一方で自分はバグをたらい回すとか design doc とかいまのチームに来るまでそんなにやっていなかったので、これらが本質的な仕事とも思わない - 組織の bureaucracy に過ぎない。つまりむかし目にした fictional なサラリーマンたちは紙束という形の官僚的重みにもがいていたのだな。

それらサラリーマンの仕事がなんだったのかはわからないままだが、それはある意味 by design なのだろう。様々なホワイトカラーの仕事があるなかで大多数の共感できる「仕事」がオーバーヘッドなペーパーワークだった。

という事実に気づき、ますますペーパーワークが嫌いになった。やだやだ。

自分は Twitter や Facebook などのソーシャルメディアが好きではないが、これらが発明した良いアイデアには目を向けたほうが良いと最近は心を改めた。

Twitter の良さ: 文章は可能なら短い方が良いと示したこと。そして短い文章を映えさせるためにコンテンツ本体以外の装飾を取り払ったこと。

Twitter 以前は、文章は長い方がエラかった。これは単純化しすぎた主張だが、長い文章を書いたり読んだりする方が偉い風潮は少なくとも一部にはあった。今やオンラインでそういう立場を取る人はマイノリティになった。これは Twitter だけの功績ではないかもしれないけれど、果たした役割は大きいと思う。

長い文章はしばしば読むよりも書くほうがラクなので、短い文章は書き手の負担が大きい。コンテンツが希少な時代は書き手に権威があったので長文を書き散らすことができたが、コンテンツ過剰な現代は書き手がエラそうにせずがんばって短い文章を書くのは正しい。

ブログなど Twitter 以前のメディアで短い文章が輝くのは難しかった。それはタイトルやら広告やらコメントやらメタデータやら、コンテンツのまわりの装飾が邪魔だったからだと思う。Twitter はそれを取り払い、かつ複数の tweet をタイムラインという単位にパッケージすることで一つ一つの短い文章を読む敷居を下げた。

短さの強制やコンテンツの混合には明らかな欠点もある。けれど短さの価値をシステムやデザインの力で示したのは偉い。

Facebook の良さ: 子供の写真を家族や友達にシェアする簡単な方法を作ったこと。

Twitter と違って自分は Facebook にサービス特有の良さを見出していない。でも数あるソーシャルメディアの中でちゃんと人を集めて動き続けたのはエラかった。知り合いのオンライン至上主義者の中には子供写真のシェアを毛嫌いする人もいるし、行き過ぎを嘆く人もいる。けれど自分はそこにしか FB の価値を感じていない。

GitHub の良さ。

GitHub は "ソーシャル・コーディング" によってオープンソースの敷居を下げ人気を博したが、ソーシャル部分の行き過ぎによる弊害は出始めているし、ソーシャルメディアと同じく問題への反発は少しずつ目立ち始めるだろう。

がそれはさておき GitHub にはソーシャルとは直接関係ないコードホスティングやバグトラッカーとしての出来の良さもあり、その美点は讃えたい。

ひとつめはコードブラウザ上で README.md を index.html として表示するようにしたこと。これによってソフトウェア開発における documentation の問題の半分くらいは解決したんじゃないか。

２つめは issue tracker や commit message で Markdown を使えるようにしたこと。バグレポートはともかく issue tracker でタスク管理をしようと思うと計画なり設計なりを書き出して議論したくなるが、GitHub でない世界すなわち職場ではいちいち Google Docs とかに書く羽目になる。

Issue にしろ comit log にしろ README にしろ、主題の近くに文書を置ける効能は大きい。Github 独自の Markdown 拡張にある checkbox などを見るにつけ、Living document としてのこうしたテキスト群の力をわかってるなと感心する。

ある製品の発明したアイデアを製品自体から切り離して考えると、そうした製品の外でもアイデアを再現できるかもしれない。自分の fragments は Twitter のもつ短文的な良さをブログに持ってこれないかという試みだし、仕事でもディレクトリ単位で README を書いたり bug tracker の文章部分を詳しく書いたり書き換えてアップデートしたり GitHub ぽく振る舞うことで Google Docs への依存を減らそうとしている。こういう「移植作業」は滑稽だけれど、なにも無いよりは良い。

ベンチマークの自動化ばかりやっていたら、そろそろリリースも近いことだし自動化は適当に切り上げて速くしろという指令を受ける。

自分が見ているレイテンシの指標のうち重要とされてているものは２つある。A, B と呼ぼう。ベンチマーク自動化で B の計測が自分の持ち物になったのが先々週くらい。去年はもっぱら A ばかり見て B は無視していたら、案の定値は悪い。

Android Q からようやく Systrace の Trace#beginAsyncSection() がアプリからも使えるようになったので、とりあえずこれらの指標を annotate してみると、指標 B の遅さは明らかに何かが間違っている。コードを睨んでつついて原因を特定、修正を試作してあるべき速さになることがわかったので真面目に書き直してレビューにだす。ここまでで一日。こんなにさっくり直るひどい性能バグを放置しといてすまなかった・・・と反省。

このエピソードからわかる、知っておくべき性能改善の常識ふたつ:

ひとつめ。なにもしてない指標は遅い。指標 B は重要といいつつ自分に限らず誰も何もしていなかった。結果としてあっさり直る数百ミリ秒の遅延がたぶん一年くらいは放置されていた。「気をつけてコードを書く」ではコードは速くならない。速くするには時間と労力をかけて測って睨んでつきとめないとダメだし、遅くしないためには労力をかけて計測を自動化し監視しないとだめ。あたりまえ。

逆にいうとなにもしていない指標を速くするのは簡単である。なぜなら自明な遅さが放置されているから。組織が十分にボンクラなら、計測のインフラを作らず誰かが遅くしたコードを定期的に直し続けるだけで雇用を維持できる。しかし幸い自分の勤務先はそこまで無力ではないのだった。

ふたつめ。可視化は重要である。Trace#beginAsyncSection() は要するにスレッドやコールスタックをまたいだ区間を Systrace 上でマークするための API。同じものは昔から Chrome にあるし、 Android platform の中にもある。しかしなぜかアプリからは使えるようになっていなかった。同じ指標をログに書き出して Systrace と照らし合わせれば理論上は同じ情報量があるし、実際自分はそうやって指標を睨んできた。が、これが正しく可視化されると暗闇に突然明かりがついたような解像度をもち見逃していた問題が次々と明らかになる。

たぶん自分は Q 以前もなんとかして Systrace に out of band の指標をつっこんで可視化する方法を用意すべきだった。しかしそうしたツールの改善に労を割かなかった。よくなかったね。目先のプレッシャーがありすぎるせいなわけだが・・・。

なお Chrome にあって Android にない重要な可視化はもう一つある。それは IPC の呼び出しを追跡できる flow event. Android の Binder なんて Chrome IPC よりよっぽどヘビーに使われているし複雑、しかも Systrace は既に必要な情報は全部もっている。にもかかわらず可視化されていないのはひどい話なのだが、Android がひどいという事実に特に驚きはない・・・と書いていてさすがに自分が見逃してるだけな気もしてきた。あとで探し直そう・・・。

追記

入っていた！がバグだらけで使い物にならん。Sigh... OS 側がトラックしやすい annotation をつけておいてやればいいのだが、そうなってないせいで guess work が発生してダメなのだろう。やれやれ。

文章を公開する方法を見直し、以下のような感じにしようと考えている。

• 長めの手紙と、短い断片に分ける。
• 長めの手紙は、それなりに読めるものを、ある程度丁寧に書く。長めといっても、別にすごく長く書きたいわけではない。あまりにゴミなものは書かないというだけで。
• 短い断片は、日付ごとの箇条書きを一週間単位でまとめる。これは要するに tweet まとめみたいなもの。読み物としての価値はあまりなさそうだが、友人などに「生きてますよ」という役にはたてばいいかないいかな、くらい。

これらを書き溜め、なんらかの形でまとめて公開する。たぶん年末に、HTML 生成ツールみたいのでコンパイルしてどこかにアップロードするかんじ。それとは別に、一部の友達などには草稿をメールで送りつける。形態としてはいわゆる newsletter みたいだけれど、どちらかというとほんとにただの手紙というか letter というほうが気分としては近い。

なぜこんなめんどくさいことをするのか。Blog と Twitter でもやればいいのではという指摘はもっともだけれども、自分はインターネット中毒をこじらせてしまいひと目のあるところにリアルタイムで書いたものを公開すると精神衛生を損ねてしまう。一方でやはりインターネット中毒をこじらせてしまったので書いたものをオンラインに置かないのはそれはそれで落ち着かない。

折衷案として、二年くらい日々なんとなく書き溜めたプライベートなブログを年に一回公開する、ということをしていた (2016, 2017.) この方法は悪くなかったが、一方でいくつか問題もあった。

• 若干さびしい。ブログというものが本来もっていた会話としての性質が失われて、完全に独り言になってしまった。
• どうせ読まれないという気楽さから、文章がどんどん雑になっていった。発言が乱暴になるという意味ではく、単に読みにくいとか、無駄に長いとか。文章を読み書きするのが好きな身として、日本語が乱暴になってしまうのはやや悲しい。
• 一方で、誰かに読まれるという圧力から考えていることを単に箇条書きでダンプする書き方はできず、本来は掃き出しておきたい half baked な考え事が頭の中に滞りがちでストレスになった。

世の中的には、会話は雑に Twitter でやり、丁寧な文章は Blog に書き、考え事のダンプは Evernote などノートアプリにやるのが定石だとは思う。ただ自分は色々なものをこじらせた結果これらができないので、やや定番から外れた方法をとっている。他人に勧めはしないにせよ悪い方法というほどでもない、という話を書きかけたけれど不毛なのでやめます。

いま仕事はベンチマークの自動化をやっているのだが、リリースが近づくにつれ自動化は誰か得意な人にまかせて速くするのもやってくれよ、というプレッシャーをかけられている。むー。

自動化のインフラを作ってくれた人はたしかに自分より自動化は得意だと思うけれども、ベンチマーク書くのは自分にやらせてほしいのだよなあ。これはチームにとっての利点と自己都合、それぞれ別の動機がある。

チームにとっての利点は、要するに自分の方が良いベンチマークを書けるというか、結局速くする仕事をやるのは自分なのだからユーザである自分の都合を完全に理解している人間すなわち自分が書く方が的をいたものができる、というもの。同僚信用してないの、といわれると言葉をにごしたくなるが、自分の要望や優先度のコミュニケーションコストとか高いのだよ。そしてベンチマークの実装は単純仕事だけでもなく探索的な側面もあり、つまりベンチマークを書く中で高速化のアイデアを思いついたり、逆に問題点を発見したり、自明でない箇所の測定をする方法を見出したりするのですよ。

自己都合としては、性能の専門家を目指すにあたり自分は良いベンチマークを書けるようになりたいから、訓練したいのだよね。安定したベンチマークはどうしたら書けるのか。トラブルシュートのコツ。現実的かつ安定した負荷のかけ方などなど、ベンチマーク書くの全然自明じゃないじゃん。それができたら専門家として一段レベルアップできると思うのだよね。バグレポート付属の systrace という断片的な情報を元にカンで直すのではなく、ちゃんと再現できる環境を作って、測定して、それを速くする。そうありたいでしょ？

それを締め切りがあるからとかいってできることだけやれみたいな圧力をかけられるのはほんといや。おっさんの成長にも配慮してくれ！定時で帰るからって差別すんな！

この話にはいくつかの含意がある。すなわち

• 疎な締め切りはクソである（今年度百回目につき新しい情報なし）
• 自己都合の仕事についてはやっぱちょっと時間外労働したほうがいいのでは（いやです）
• プレッシャーをうけても適度にしらばっくれるのが大切である

まあ基本的には自分の仕事が遅いせいなので、何らかの形で責任は果たします・・・。

追記 (2019-12-01)

その後性能インフラチームはでかくなり、仕事を横取りするのもどうかと身を引いて高速化業に専念した。しかし結果といてずっと気になっていた指標をベンチマークに追加できず、当然のように regress したのだった。

定期的にフルフレームのセンサーがついたカメラが欲しいなーとインターネットを眺めて時間を無駄にしている。ここ一年くらい、大手カメラ会社がフルフレームのミラーレスを発売しはじめてまた欲しいなーという気持ちが高まるような高まらないような感じである。

自分はスマホというミラーレスな世界を基準にカメラのテクノロジを学んでおり、その目から見ると DSLR というは割と謎な存在である。というか、DSLR の存在はいいとしてミラーレスより DSLR の方が良い、という主張がいまいちよくわからなかった。

DSLR はビューファインダーが光学なのがユーザから見たミラーレスとの大きな違いの一つである。DSLR をありがたがるとはつまり光学ビューファインダー (OVF) が好き、という話だと解釈できる。

でもさー。いくら OVF が鮮明だろうが、記録される画像はセンサー経由なわけじゃん？そんならセンサー経由の画像を見て撮影した方がよくね？露出とか、センサーの感度も影響あるよね？

まあ電子ビューファインダ(EVF) はダイナミックレンジが少ないから・・・みたいな主張はありうる。でもセンサーも肉眼（の体感）よりダイナミックレンジないよね？トーンマップが挟まるとしてもやはりセンサーの限界みたいなものを撮影時に確認しておく方がよいのでは？

もう一つの主張としては EVF は遅い、というのがある。スマホだとふつうに 30fps は出るのでいまいちこの感覚はわからない。ハードウェア頑張れという話ではなかろうか。それに暗いところで撮影するならシャッター時間のレイテンシがあるから、どのみち遅いのでは・・・と思ってしまう。

更にいまどきすべての DSLR には液晶がついている。みんな画面みてとらないの？というと VF の方がいいという気持ちは理解できるし自分も VF 好きだけれども、一方で可動画面を使って撮影する場面などではいよいよ OVF 意味ない。もうわざわざ鏡いれてまで OVF つけなくていいじゃん？大変じゃん？

まあおそらくこういった現実があるからこそ各社ミラーレスを発売したのだろうけれど、なぜ 2019 年までかかったのかはだいぶ謎。現実的な解像度フレームレートで EVF を表示するというのは、よっぽど大変なのことなのだろうか。大変だということなのだろうなあ。

しかし自分が使っている Panasonic のマイクロフォーサーズのミラーレスとか先祖は 2010 年くらいからあるはずで、これは他のカメラ会社もだいたい同じ。つまりテクノロジーは持っていたわけじゃん。大きなセンサーサイズが EVF に与える影響もそんなに大きいとは考えにくい。各種画像処理はダウンサンプルしたあとにやればいいはずだし、筐体がでかくなるぶんバッテリーを含めたハードウェアの性能には余裕があるはずだから。やはり Sony 以外のフルフレームのミラーレスが去年までなかったのは謎だよなあ。

企業には文化的なしがらみというものがあり、それが原因であるという説も見かける。会社員としてそれは理解できないではない。ただアナログからデジタルへの移行ならともかく、デジタル化が済んでるならどうかんがえても OVF より EVF の方が自然じゃね？と思ってしまう。

というわけで DSLR の存在は割と謎。特に大手三社の異常な足並みそろえっぷりが不気味。談合では、みたいな疑惑をもちたくなる。それともなんらかの共通要素技術ボトルネックみたいのがあるのだろうか。Android スマホにおける Qualcomm みたいな・・・。

といいつつちょっと前まではレンズもいっぱいあるし相対的に安いし DSLR 買ってもいいかもな、と思っていたが、あるとき OVF はホワイトバランスとかやってくれない？ということに気がついて思いとどまった。あぶなかった。みんなミラーレスがんばってくれ。

編集時に再生速度をあげて時間短縮できる、という話を聴いたので Audacity  でもできるか調べる。で、できる。"Play-At-Speed" という機能があるのでそれで再生速度を速くし、かつ "Play-At-Speed" に適当なキーボード・ショートカットを割り振れば良い。

• audacity - How do I change the playback speed without changing the tempo? - Sound Design Stack Exchange
• Keyboard Preferences - Audacity Manual

Fitbit Versa Lite を買った。安い Smart Watch としてではなく、高価な Pomodoro Timer として。

• Pomodoro としては、まあまあ。振動に気づかず期限を無視することがしばしばある。
• バッテリーは、こんなもたなくてよくね？というくらい保つ。まあ徐々に劣化するだろうから、長い分には良い。
• 万歩計機能はあってもなくても良いが、帰宅時に一万歩達成！とか表示されるのはちょっと楽しい。Exercise detecdtion も、まあそこそこ良い。個人的に fitness tracking はあまり興味がないのでキラー機能といかんじではないけれど。
• 心拍数がわかるのは面白い。有用性はない。
• Apple Watch にもあるような、一時間に一回歩けといってくる機能。Pomodoro との組み合わせで割と良い。休憩のタイミングでちょっとあるくか、みたいな気分になる。
• 自動画面点灯の反応が鈍い。そして画面の更新もワンテンポ遅く、一瞬消灯前の時刻が見えたりする。時計としてはいまいち。ここは Android Wear 時計の Always On に一日の長を感じる。
• アプリは全然ないと言って良いが、Pomodoro はあるのでそれが全て。
• スマホとの同期、たとえば notification の表示は使ってない。いらない。

といったかんじで買ってよかった。レビューを見る限りではだいぶ壊れやすいっぽいので、二年持てば上出来、一年持てば期待値としては達成かなあ。改善してほしいところは多いので、使い続ける限り次のモデルも買いそう。

自分用に Pomodoro アプリを書きたいのだけれど、エミュレータが Linux と Mac OS 用しかない！そりゃそうか。古い Laptop に Windows を入れようかな・・・。

継続的ベンチマークが２つめのリグレッションをキャッチした。この調子でいけば余裕でもと取れるな。

今回の反省は OS の挙動変更によりテストが壊れていたのを数日放置したこと。その数日の間にリグレッションがおき、その bisect で死ぬ思いをした・・・。ベンチマークも reliability 重要。

via Backstage Blog - Release Quality and Mobile Trains - SoundCloud Developers

SoundCloud は bi-weekly か。書いてあることは普通だし自分たちもできてしかるべきだができてない、というものかしさよ。リリース担当を当番制にしてるのはえらい。しかし branch point を code freeze と呼ぶのはどうなのかね。code を freeze しなくてよいというのが train model のいいところだと思うのだけれど。

まあしかしそれはコード氷河期を生きたものだけが気にしていることであって、train 当然世代的にはちょっとクールな言葉くらいな勢いなのかもしれない。freeze  だけに。

帰省で二週間近い休暇をとったその三ヶ月後くらい、また二週間の休みをとって親戚に合うためスイス旅行。年の前半ですでに一ヶ月の休暇をとることになる。いざ予定を決めてみると胃が痛い。

有給は足りているので制度的な問題はまったくない。金がかかるのはやや厳しいが、それは事前にわかっていた。

一方で一ヶ月休むと仕事は一ヶ月分遅れる。締め切りは変わらないので、自分の仕事の成果はフルで働いた場合に比べ 1/12 減る。実際にはリリース後の 3-4 ヶ月くらいというのはなんだかよくわからない間に過ぎてしまうので、成果の減少は 1/9 から 1/8 すなわち 15% くらい。この影響をよく考えていなかった。今の評価を給料が下がらないギリギリラインだと思っている自分としては、成果が減ってまた評価減および減俸が近づくことに恐怖がある。

成果主義が機能している（と従業員である自分に感じさせている）という意味で、これは組織の意図が働いている証左といえる。それはおそらく良いことである。会社にきてりゃ成果はどうでもいい世界と比べラクではないが、組織の長期的な存続への期待値は高まる。

一方、リリース後の三ヶ月がなんとなく失われてしまうという性質、もっといえば重要なリリースが年に一回で、しかも動かせない事実は休暇の取りやすさを損ねており、こいつはなにかと本当に恨めしい。締め切りがキツくて休めないとかブラック企業じゃん。（休むわけだが。）一ヶ月休んだら純粋に仕事が一ヶ月遅れるだけ、すなわち自分のやっている機能の出荷なりインフラの改善が一ヶ月ズレるだけならどれだけ気がラクがわからない。

これはフェアな苦情ではない。年次リリースのある組織では、本来はリリース後のなんとなく過ぎてしまう三ヶ月くらいの間に休暇をとることが期待されている。実際、どのどうでもいい期間がクリスマス/正月に重なるよう日取りが決められている。一方で、自分の旅行は人間関係的な都合からしかるべき時期にいかねばならず、それはクリスマスではない。これを不運とみるとか組織の不条理と見るか。

まあ不運と思っておくほうがヘイトが溜まらないというものだな。来年からは年末年始に休み取りたい。が、一方で冬の日本に帰省するとか寒いしインフルは怖いしでまったくやりたくない。こんなところに思わぬ外国人税。

年次リリースのある組織でも、実績のあるベテランは容赦なく夏に休暇をとったりする。実績ゆえ、ちょっと休んだくらいで自分の評価が揺るがないことを知っているからだ。別の言い方をすれば、こうしたベテランたちは成果が評定に反映されていない（振り切っている）。これはダメなんじゃないか。

・・・これは言いがかりだな。制度に定められた休暇をとると給料が下がりそうと感じてる自分の身の上の方が問題な気がする。

ベテランたちに羨ましさと一抹の苛立ちを感じてしまうこの状態は、一歩さがると結局は年次リリースの歪みなのだろう。この歪みは受け入れなければいけないと言い聞かせ続けているのだけれど、一旦シームレスなリリースの世界で暮らしてしまうとなかなか締め切りのある世界に戻れない。

家族の期待値がシームレス側にとどまっているのがなお辛い。長期休暇の取得とは不自由なものという暗黙の合意があれば気はラクだろう。ただそれが人として望ましい状態なのかはわからないな。というか、有給とったら給料さがりそうという心理的安全ゼロな状態が望ましいはずがない。ただその出処を組織に問うのか自分の覚悟の無さに問うのか、というか組織に問うても仕方ないので自分には締め切り厳しい世界で働く覚悟が足りてない、ということなのだろうなあ。しかしそんな覚悟なんてないにきまってんじゃんよ・・・。

まあしかし休むのである。評定および給料がさがりませんように。

追記

これは若干 exaggeration で、去年は病欠で有給を使えなかった + 今年はなんかしらんがいつもより仕事が忙しい、の組み合わせによるプレッシャーな気がする。この忙しさが永続化しないことを祈るばかり。

04:39

ひきつづきコード読みつつノート。今日録音だというのに全然準備できてなくてやばいな・・・。

05:16

MN, しばらくブログのインスタンスをわけてつけてみたが存在を忘れがちでうまくいかなかったので元どおり一つのブログインスタンスに全部いれる方法に変更。留守番期間は生活習慣乱れにより大して朝の活動はできなかったので、事実上欠番はほとんどないです。

xgboost のコード読み。

妻子帰宅。

今回は前回以上に生活のリズムを維持できず、遅寝遅起きにシフトしてしまった。それに加え労働時間を伸ばしてしまった。結果として個人プロジェクトははかどらなかった。

ブログの EC2 脱却ができたのと、花見ドライブができたのはよかった。考え事をする時間もそこそこ取れた。

家で個人プロジェクトをやる、という方向だとどうしても loneliness や boredom にやられがちなので、次回移行は人と遊んだり出かけたりする方向で home alone 期間を楽しむようにしたい。まあ遊び相手なんてそんなにいないんだけど、たとえば勉強会みたいのに顔をだしてみるとか、そういうのでもよい。

家族がいる方が賑やかでいいなと思ってしまう。「しまう」というのも語弊があるけれども、もうひとりぐらしをエンジョイできる精神性は失われ、家族持ちとしての適応が進んだ。去年もそんなことを書いた気がするが、その傾向は強まっている。あたりまえだし、悪いことだとはおもわないけれどね。

一年ぶりくらい・・・もっとか・・・に服を買う。着てるものがだいぶボロボロになってきているが、書い直すヒマがなかった。

服を買う行為は苦痛ではないにせよ別に有意義にも感じない、というか、妻子とモールとかだとだと若干苦痛。いまのところ体型も維持できている(30-30, M)から試着も必要ない。そして自分は GAP 以外で服を買う気もあまりない・・・つまり GAP と決めておけば考えなくて済むので・・・次からはオンラインの GAP で買おう。

店舗に行ってわかったことは、一番安いやつは全体的にツルツルしていて安っぽいということであった。オンラインで買う時もそういうグレードのやつは避ければよかろう。

Bad Blood: Secrets and Lies in a Silicon Valley Startup

ドライブのお供に聴いた。話は面白かったが Theranos のやばさは想像の範囲を超えていた。Enron と戦えるのでは・・・。序盤からひどさに溢れているのでああひどい会社の話なのだ・・・と聴いているとひどさがどんどん加速していく底抜けの疾走感。ドライブしながら何度も「ええーひどいまじかーおーい」などと口走ってしまった。このひどさで $9B valuation, 社員 800 人まででかくなれるのか。恐怖。

Uber の Susan Fowler 事件以来おもっていたこととして、議決権の強い株と弱い株、ある株ない株というアイデアは目論見はわかるが結果としては良くなかったなと思う。もうだしちゃった株はともかく今後は規制されてもやむなしではないか。  WSJ に「そういう株は買わなければいい」という記事があったけれど、みんながやってしまったら選択肢ないからね。Uber は利益がなく上場もしてなかったから大口投資家による圧力が機能したけど、これでもし IPO 後かつ profitable だったら創業者セクハラ社長を追放できなかったかもしれないよ? 本人が議決権を握っているわけだから。Theranos の投資家もちゃんと議決できる株もってたら社長の気分で board をクビにしたりもできなかったかもしれないし。（これがまさに FB だという見方もある。あの人たちは fraud はしていないと思うので言いがかりな気もするが。）

もうひとつ、個人的には "Fake It Till You Make It" という態度はもう scam 枠でいいなと思う。

たとえば自分が fake してる会社に騙されて転職しちゃったりしたらキャリアが ruin されちゃうじゃん。なので雇われプログラマとして fake なやつらに甘い顔をしないのは大事なことに思える。できてないものをできてないと言った上で夢を語るのは構わないけれど。

だたアメリカは scammer と entrepreneur の境目がすごくぼんやりしているのでこの意見が主流になることはないだろう。

そして若い visionary が意図せず fake をしてしまうことはあるだろうなとも思う。大きな夢があって、現実と夢の距離を無邪気に何桁も読み違えている。無知と楽観の力で本人は簡単だと信じている。だから自信満々にビジョンを語れる。騙しているわけじゃない。自分もむかしそんな人を見たことがある。もしかしたら Elizabeth Holmes も最初は単なる無邪気な visionary だったのかもしれない。

まあでも専門家の意見を求めるかわりに専門でない投資家を選んで金を集めたというから、やはり scammer だったのだろうな。そういえば scammer-entrepreneur もあったことあるなむかし。サイコパス力が低かったせいか筒抜けだったが・・・。

自分が会社なりプロジェクトなりを評価する必要があるときは、ビジョンとかよりコードなり製品なり tangible な observation に基づいて判断を下したいものです。夢のない話で、われながらシリコンバレー向いてないなと思うものなり。

Amazon.com: Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs (9780525536222)

OKR, 世間ではどういうものという話になってるんだろうな、という興味から読んだ。

この本は OKR の威力を過大評価している気がする。自分は OKR はそんなにたいしたものではないと思っているが、一方でその大したことなさが良さだとも思う。

会社に入ってはじめて OKR というものを知った時、プロジェクトマネジメントとかこんな雑でいいんかいな、と思ったのを思っている。世間では inception deck だのなんだのがもてはやされていた頃である。たぶん、世の中には OKR よりすごくでかっこいい目標管理/ビジョン制定の方法論は色々ある。一方そういうのを機能されるのはたぶんすごく大変で、できずにくじけることも多いのではないか。

OKR にはそういう大仰な難しさはあまりない。目標 (O) とその実現手段(KR)を箇条書きにして、四半期に一回見直しましょうね。組織のツリーにあわせて O や KR を breakdown しましょうね。なるべく定量的かつ客観的にわかる目標にしましょうね。以上。みたいなかんじ。

目標は単なる箇条書きだし、チェックも四半期に一回。しかも stretch とかいって達成できないのが前提になっているゴールも多い。定量的というけれど、製品開発だと "機能 A を ship する" みたいな KR になることもしばしばある。目標の雑さゆえ、あとちょっとで ship できそうだから 0.7 くらいにしときますか・・・など評価もしゃきっとしないことがある。雑。

雑さゆえ、いまいちな OKR を運用することはいくらでも可能である。目標設定を雑にもできるし、評価を雑にもできる。なので OKR というプロセスの強制力によって色々なことがみるみるよくなる、みたいなことはおきない。

この雑さには２つの含意がある。

含意そのいちは、仮に OKR の運用がいまいちであっても被害が大きくないこと。OKR のよくあるいまいちさは 1. 定量的/客観的でない 2. 野心的でない 3. まとはずれである だとおもう（本のなかでもそんな話をしている。）一歩さがると, 1 と 2 はプロセスが形骸化しているということで、3 はゴールがよくないということ。

形骸化したプロセスは迷惑な存在だが、OKR はその雑さゆえに形骸化しても被害がすくない、四半期に一回くらい、やれやれ・・・みたいな気分になるだけ。給料への影響もない。これがすごい厳密に定義された官僚的なプロセスだったら、そしてプロセスというのは厳密に定義されがちだが、つらいだろうと思う。官僚的で形骸化してる。いやすぎる。

含意そのには、強制力はないが nudge にはなっているということ。四半期に一回くらい自分の仕事の目標を考え人目につくところに書き出してみるのは、経験的にまあまあ意味がある。この仕事って結局なんなんだっけ、みたいのを見直すことになるから。

OKR は top-down で voluntary なので、組織の木の下の方にいくとやっていないところもある。たとえば今のチームはやってない。でも本をよんだら OKR してもいいんじゃないかという気がしてきた。組織図を２つか３つのぼるとやってる。年に一回大きなリリースをする世界とは相性が悪いのではないかとも思うが、Intel みたいなハードウェアの会社だってやってたわけだから理由としては弱いかな。そしてチームはともかく個人でやってる人は割と少ない印象。まあ部門によるのかもしれない。自分はずっと周縁的なチームなのでわからん。ガチ勢はどうやってるのだろうね。

自分のチームがやってないせいもあり、自分は勤務先の OKR をそんなに良く機能しているとは思っていなかった。ただ本を読んで、機能している部分もあると見直した。

まず、ちゃんとトップダウンにやっている。おおむね上の方ほどちゃんとやっている。O はともかく KR はだいたいが定量的である。スコアも公開されている。あの部門ちゃんとしてるなだとか、勢いあるなとか、いまいちなことやってるなとか、でかいこと言ってたけど全然できなかったのね・・・とか色々わかる。自分のような下々が（たとえば本を読んで）よし自分のチームだけでも OKR やるぞ！とかいってボトムアップにやって組織の壁にぶつかる・・・みたいなのがこの手のプロセスにありがちなことなので、上のほうがやっているのは良い。

透明性。OKR は基本的に公開されている。公開されないドキュメントに書いてるだけのダメなチームとかもあるが、少なくとも上のほうはちゃんと見える。（株価に響くようなデリケートな情報は伏せ字になっているが、それは妥当だと思う。）これがそんなに自明じゃないのは本で指摘されるまで気にもしなかったけど、たしかに経営者とか上の方の目標とかがポエム以外で communicate されていた会社で働いたことなかったな。まあ、このくらいは透明度あってもいいんではないかと思う。

給料と連動していない。こんな雑なものに連動されたら困るわと思ういっぽう、最初に働いた２つの会社はそういえば完全に形骸化してる目標管理を口実に給料を決められてムカついた記憶がある。当然 stretch goal みたいのを持つ気はまったく起こらず、従ってあれらが従業員（自分）を empower するとは一ミリも思えなかった。勤務先の OKR はそういう性質はなく単に背筋を伸ばすツールなので、ちょっとめんどくさいけどやれと言われればやる気にはなる。というか今となってはむしろチームでちゃんとやってほしいな、とすら思う。

勤務先の OKR に感じる不満は組織の下の方への浸透度が低くやってない人が多いせいで組織全体の透明性などが達成できていないこと、当事者としてもいまいち継続するための動機づけが弱いことで、OKR そのものの aspirational な性格は今の所損なわれていない気がする。

みんなやればいいのにと思う一方、全社員が OKR を強制されている会社というのもそれはそれで嫌な予感がある。なにかをやらされるのは官僚化や形骸化につながるから。他のよい枠組みに乗っているならそれはそれでいいだろうし、組織の方向性、成果や責任みたいのがはっきりしないのだとしたらそれは組織の練度が足りないということで、きっと OKR を押し付けてもうまくいかないよね。良くも悪くもそんなに強い力はない気がする。

そういえば、どういう目標を持つのが良いかという話はあまり詳しくされない。一方で The North Star などのジャーゴンがとびかうあたりに The Lean Startup くらい読んでるよねという空気もあった。

前回のつづき。EC2 のインスタンスを殺すぞ！

やったこと:

• S3 にホストしていたものを CloudFront で HTTPS にした。
  • おおむねマニュアルどおりだったが、".../" に ".../index.html" を serve する S3 の機能がなぜか HTTPS 越しでは動かない。が、オフィシャルな workaround で乗り切れた。Lambda@Edge とかいう目新しいものにデビューしてしまったぜ。コピペだが。
  • HTTPS 化にあたりハードコードされていた HTTP の URL を HTTPS に直した。Middleman, Hugo は動いたが Octopress は動かなかったので、コンテンツをひっこぬいて書き換えた。ファイルは GitHub にバックアップ。
  • Amazon や Flickr などにリンクしている HTTP 画像はもう直しきれないので mixed content になってしまうけれど諦め。実際は Flickr も Amazon も HTTPS 対応してるだろうから書き換えればいいのだけれど気力切れ。
• 自作の雑な Go のサーバで serve しているのをやめて GAE に移行。ただこいつはサーブはしないでリダイレクトするだけ。この移動の結果いくつかのサイト内でのリンクが死んでしまったが、実害はほぼないと思われるものだけなので見逃してもらう。それにしても Flask で GAE ラクすぎてサイコーだわ。
• サーバ殺しても大丈夫かな・・・と DNS の設定を眺めていたら、なんと自作の Wikiがホストされ、まだ生きていた。人生にまよっていたころに書いたWikiだな・・・。コンテンツのバックアップはないっぽい。大して書いてなさそうだから消しちまうか・・・とおもったがいちおう SSH してコンテンツを確認すると・・・引っ越し前後の日記が入ってるじゃねーか！というわけでいちおうバックアップしておく。これで消せる。
• といったところでサーバ停止。2012/12/28 に作られたインスタンスだそうです。おつかれさまでした。ホストしてきたものとしては、ブログ、自作Wiki, gisted.in, hasb.ug, wkb.ug, くらいかな。データとりだし忘れとかあると困るのでまだ terminate はしないでおく、次回 bill 見直しの時でも消します。

喉に刺さった魚の骨的にきになっていた問題だった。片付いてよかった。

実は AWS に払っている額が結構ある、という事実から目をそらしていたが心に余裕のある今ちょうど bill が届いたので内訳をみてちまちまと削ったら $5/month くらいあっさり削れた。やれやれ。しかし謎の、というかブログをホストしている EC2 instance が高い。Reserve してないからか・・・昔した形跡があるが、とっくに expire していた。えらい無駄遣いしてしまったな。とありえず一年くらい延命処置。

昔はいくつか細かいサービスを立てていたから意味があったが、今やブログのホスティングだけをしている EC2 に金を払うのあほくさい。しかもじっさい static file を proxy いているだけで、一重に昔の URL の互換性を保つためだけだという・・・というか Go でコードをかいてみたかったからだけという・・・。もうこのコードは捨てて managed で金かからない方向にしたいなあ。

オプションを考える。

• 検索エンジンを信じ古いリンクには死んでもらう。リンクは 404 になる。ドメインは残して、たとえば dodgson.org/ とかにアクセスされたら今のブログにリダイレクトするような HTML を静的にホストする。いちばんラク。
• Managed にコードをホストする
  • ドメインに応じてスタティックなファイルにリダイレクトする。リンクは切れるが 404 にはならない。
  • 全ての古い URL に同じ HTML を返し、JS でリダイレクトする。ブラウザからのアクセスならリンクは切れない。クローラはさようなら。モダンクローラなら大丈夫な気もする。
  • URL に応じて静的なファイルにリダイレクトする。リンクは切れない。正規表現とかのマッチングをテストするのがかったるい。
  • URL に応じてプロキシする（現状のつくり。部分的にリダイレクトもしているが・・・）GAE にすれば HTTPS にできるかも、という利点はある（がなんらかの HTTP の inclusion が消しきれず労に合わない可能性も感じる。）
  • Managed なサーバにコンテンツもつっこむ。プロキシよりはラクそう。なんとなく。更新のたびに push するのはアホくさいが、どうせそんなに更新しないし良いのでは、という気もする。

Managed なコードを動かすとしたらどこに置くか。

• GAE. 使い方もしっててるし一番ラク。
• AWS Lambda. せっかくだから使ってみる。しかしまたメンテできないゴミを増やしてしまうだけな気もする・・・。
• Firebase. せっかくだから使ってみるつながり。Firebase はお近づきになっておいて損はなさそうだし、Lambda よりはちょっとラクそう。

・・・とか考えたけど GAE を使いサーバサイドでリダイレクトするのが仁義（リンク維持）を果たせる範囲では未知の要素が少なくて一番ラクそうだな・・・。

現状のコード（ひどすぎ）から仕様を読み解くと

• リダイレクトの必要なドメイン:
  • dodgson.org, www.dodgson.org: tDidary フォーマットの URL を bn.dodgson.org の静的な URL に書き換えてリダイレクトする。"/" は現行のブログに飛ばす。
  • steps.dodgosn.org - ドメインだけ変え blog.dodgson.org にリダイレクト。おなじく "/" は現行のブログに飛ばす。
  • stepped.dogson.org - よくわからんが dodgson.org と同じ扱いで良さそうな雰囲気。
• すべてのドメインの RSS っぽい URL: 現行のブログの feed に飛ばす。
• 知らない URL -> 現行のブログに飛ばす。

これくらいかな。なんか行けそうな気がしてきたぞ・・・。

それとは直行した話としていいかげん HTTPS にしたいのだが・・・

• ssl - HTTPS for Amazon S3 static website - Stack Overflow
• amazon web services - https on S3 WITHOUT cloudfront possible? - Stack Overflow

Cloudfront 使ってないのだよなー・・・。Free tier もあるっぽいことだし、おとなしくつかて HTTPS にしろということなのだろうね。

まず静的コンテンツを HTTPS にうつして、それからリダイレクタを書くかなあ。一日仕事休んでばーっと片付けたい・・・。

検索会社にどうやって入社したか、みたいな話を東京の人たちがおおっぴらに書いている。黙っていても人が集まらないところに求人力の低下を感じてしまうが、まあ時の流れだよなと思う。

そして「みんな東大生とか京大生とかばっかりで励みにならない」みたいな感想を見かける。書き手の意図はともかく雇用者的には東大生とか京大生と戦える（バトルするという意味ではなく互角にやれる）人を採用したいだろうから by design だと思う一方、自分はもっと格下の私大（明治大学、しかも理系）卒なので励みにはなるかもしれない。大学院までいったけど、私大の内側の大学院なんてなんもなしでいけるからね。

東大生とか京大生ばっかりな事実には若干肩身の狭さはあったが、学閥みたいのが形成されるほどの歴史もないしオフィスの権力もないので実害はなかった。いっぱいいすぎて有り難みがないせいかもしれない。肩身の狭さという意味ではどちらかというと TopCoder やら ICFP のコンテストの話に参加できない方で肩身が狭かった記憶がある。これも年一回とかなのでどうということもないけれど。

そして今はもはや MIT とか Stanford とか IIT がゴロゴロしてる職場に転勤してしまったため東大とか京大とか相対的にどうでもよくなった。ごめんゴロゴロは言いすぎた。ぽつぽついるくらい。そして MIT も Stanford もほとんど空想上の存在なので肩身の狭さを感じようがない。ホグワーツみたいなもん。

十年前の自分は学歴および実績とは無関係に自分は良いプログラマだと信じていた一方、検索なんて機械学習とかバリバリ使う数学仕事で自分にはやることないでしょ PRML 買ってみたけど一ミリもわからなかったし・・・とか思っていたため、無視して次の世代の新興企業に行くからいいもんね、みたいな謎の sour grapes fantasy を心の片隅に抱えて生きていた。（次の世代の新興企業が軒並み機械学習で数学バリバリになるとは想像しなかったのだろうか。）

ヒマと虚栄心にまかせ書いていたブログのおかげでインターネットでは一定程度知名度があったので、そのつながりで refer してくれた人がいた。このときは転職の直後だったためもあり丁重にお断りした。

その二年後くらいに思いつきでもうちょっと古い別の外資系企業の日本支社の求人に応募したが、色々あって途中で辞退した。なんとなく決まりそうな雰囲気だったのを諸事情から断ることに決めてがっかりしていたところに同じ人から再び refer してもらい、しかも興味のあった WebKit の仕事だというので喜んで応募した。次の世代の新興企業はどうした、みたいな話はあるが、WebKit ならすくなくとも数学できなくてもだいじょうぶそうじゃん。（だいじょうぶだった。）

インタビューの準備は、リクルータに topcoder やっとけといわれたのでちょっとやった。実際の competition 参加は厳しそうだったので、かわりに過去問を 10 問か 20 問くらい解いた気がする。うわ苦手だな・・・とおもったが、なにしろ絶賛デスマ中で毎日帰りが遅かったためできることは限られていた。ダメならダメで仕方ないと思っていたし、試験勉強をがんばるメンタリティを持っていなかった。

待てど暮せど面接の日程の連絡が来ないので「そういえばカバーレターとかいうの付け忘れたし書類選考で落ちちゃった？そんなら教えて」と問い合わせたところ「もうちょっとかかる」みたいな返事がきて、そのあと面接してまた待たされて、なぜかもう一ラウンド面接して、また待って、ようやく連絡もらって入社、というかんじだった。（面接官の人選に不備があったため部分的にやり直しになったとあとで聞いた。）

しかし正直なところ入れるかどうかは情報としてあまり重要でない気がする。応募してみればわかることだから。（この話はだいぶ前に書いた。）応募するとなんだかんだで 1-3 ヶ月くらいは心の平安を犠牲にするわけだが、まあそのくらい。でもそれよりは、入社して後悔しないかの方が重要じゃん。

自分は WebKit の仕事はすごい入れ込んでいたが、仮にこれが検索なり地図なりの仕事だったらどうだったか。まったくわからない。どんな仕事か全然知らないから。今にしてみれば一回くらいやっとくんだったと思うけれど、時すでに遅し。それに全く専門性のない分野なので、やらせてもらえたかもわからないな。

東西ホグワーツ勢はさすがにエリートだけあって優秀なのでそういうのと一緒に働くのどうなの、という点については、一定程度まともにコードが書ければ何かは仕事があるので真面目に働いている限りクビになる的な心配はない。ただ自分の出世力は相対的には低いと思う。出世はしたほうがエラい（当たり前というか文字通りというか）的な空気はあるし、それまで零細 small pond で big fish をしていた自分がここでは雑魚キャラである事実に慣れるまでにはちょっと時間がかかった。

いまは逆に自分が雑魚キャラでない状態を想像するのが難しい。根拠のない自信を失ったのは大企業の対価かもしれないし、単に加齢かもしれない。あと真面目に働くのにもまあまあ大変さを感じる。エリート力不足と言わざるを得ない。

妻子のいない間に普段はできないドライブでもしたいなあと思いつつぼんやりインターネットを眺めていたら、今年は Super Bloom だ、というニュースを見かける。ニュースの中心は Socal だったが、うちの近所はどうなのだろう・・・とニュースをみるともう一ヶ月くらいかかるらしい。桜前線みたいなもの。しかしいくつかのページを眺めていると南に五時間位走った Carrizo Plain National Monument でも咲いているらしいという。道は難しくなさそうだし、気合をいれたドライブにはちょうどいい距離だと思い、おもむろに現場近く（といっても一時間くらい離れている）のモーテルを予約して出かける。

完全な思いつきなので特に手際はよくなく、家を出たのが土曜17時。途中晩飯のハンバーガーをたべるなどしたのち宿についたのが22時半。フロントで「花を見に来たの？」ときかれたので、ライバルは多そうというか道は混みそうだと気を引き締める。アラームをセットして翌朝6時半に起床、軽くストレッチをしたのち近所のスーパーで朝飯、おやつ、水を買って現地に向かう。途中停車して写真をとったりしたのち目的地についたのが八時半くらい。まあ目的地といっても Google Map が公園をあらわすランダムな場所にたてたピンというだけで、何もないんだけど。しばらくブラブラして写真とったりしたあと、ダラダラ帰宅。帰ってきたのは日曜 15 時くらい。

自然を満喫できたのはよかったけど、さすがに疲れた。翌日月曜、会社にきたはいいが頭の芯のあたりに疲労感があって集中できず、休憩がてらこれを書いている。自分の体力および運転技能だと2日続けて 4-5 時間ドライブは厳しいと学ぶ。妻子を乗せているときより単位時間あたりではずっとラクだけれども、一方で運転を交代する相手もいないわけで。

とはいえたまになら悪くない娯楽。また home alone の機会があったらやってもいいかな。