Spinach Forest

March, 2022

/ 移行活動 - ドメインなど   / 読書活動 - Information Dashboard Design Ch 2, Ch 3.   / 読書活動 - The Food Lab   / 誤読活動 - Polaris: a system for query, analysis, and visualization of multidimensional relational databases   / 移行活動、読書活動   / 週例活動 - 図鑑探し   / 移行活動 - From Hugo To WP.com   / はじめに   / Moving   / 継続可能な趣味にむけて   / Untiled Braindump   / WSL2   / 「ハイブリッド勤務」にむけて   / Too Obvious To Innovate   / ... 

移行活動 - ドメインなど

|

さてちょっと時間あるから WP に金払ってドメインの設定でもするか・・・。

「法蓮草の森」は完全に思いつきの名前すぎ、あとから変えたい気もするので、ドメインはもうちょっと agnostic なかんじにしたい。しかし notes.dodgson.org は使ってしまっている。records.dodgson.org とか? notes と何が違うのかという話はあるが、違いはなくて名前の衝突を避けたいだけです。logs とかでもいいけど、log ってかんじでもないからなー。

"Domain Connection" という機能が $13 だけど paid plan ならフリーだよー、とか書いてるので、むしろ domain connection だけ売ってくれと思って調べたが、それを買うことはできないらしい・・・なんだそりゃ別に personal plan でいいんだけどさ・・・。

とか試行錯誤していたら間違えてこのブログをアップグレードするかわりに新しいブログを買ってしまった!ギャー!しかしあっさり refund できたのでよかった。この refund のしやすさは評価する。

そして Personal Plan を refund してわかったことだが、もし Personal Plan で custom domain を使っていた場合、Personal Plan をやめて Free Plan に戻っても custom domain は使いつけられるらしい。それが $13/year の Domain Connection 機能。つまりこの "plan" にアクセスするには有償プランを購入のうえ refund すればよい。Audible の退会フローでだけアクセスできる格安プランみたいなもんだな。まあこのブログをちゃんとやってるうちはふつうに金払いますよ潰れてほしくないからね・・・。Misreading Chat を完全終了する日が来たら Domain Connection に切り替えていい気はする。

はー無事金払い終了。Domain の upsell が激しすぎてかなり UX を損ねているのが残念。でも consumer 向け有料サービスというのはこうなってしまうよなあ。世の中うまい話はないのである。まあトータルのお買い得度を考えるとこのくらいの annoyance はいいです。

読書活動 - Information Dashboard Design Ch 2, Ch 3.

|

朝起きて顔洗ってコーヒー淹れて着替えて 4:37.

Chapter 2: Thirteen Common Mistakes In Dashboard Design

  • Exceeding the Boundaries of a Single Screen.
    まあこれはわかりやすいね。なお画面を分けるのも、drill down は別にしてやめとけという主張。
  • Supplying Inadequate Context for the Data
    比較すべき数字が含まれていない(平均、目標など)。良い悪いだけでなく、どのくらい良い・悪いのかがわからないとだめ。
  • Displaying Excessive Detail o Precision
    逆に細かすぎる、みたいなの。ビジュアルが伴わない場合はなおさらそうだよな。というか table はイマイチな気がするな。自分の dashboard もちょっと table を混ぜちゃってるけど、あれは細部として切り離したほうがよさげ。
  • Expressing Measures Indirectly
    伝えたいことが伝わらない指標を使っている。例では予実の時系列チャートを挙げており、予実の額自体をプロットするのをダメとしている。かわりに予算を定数とし、予算に対する実際の出費の % をプロットしたほうが良いとしている。予算超過しているかどうかがわかりやすいから。なるほど。なお仕事ではもっとあからさまにダメな indirect measure が問題になったことがある。それは直したけど、他にもこういうのありそう。"Indirect" という語彙があると指標を殺したいときの説得には役立つげ。
  • Choosing Inappropriate Display Media
    Bar chart はやめておけ、まして 3D は最悪だ。あと二種類くらいダメなチャートが乗っており、かつ後の章でも詳しくやるらしい。仕事、社内ベータユーザの OS ビルドの分布を pie chart で出しちゃってるけど、だめかな・・・。エントリが多いと bar chart はかさばるのだよなあ・・・。後の章に期待。
  • Introducing Meaningless Variety
    無意味に使う chart の種類を増やすのはやめなさい、boring とか気にしないで consistency 大事にしなさい、という話。
  • Using Poorly Designed Display Media
    単一のチャートのダメさについて、いくつか例を示しながら議論している。詳しくは Show Me thee Numbers という別の本を読んでねとのこと。はい
  • Encoding Quantitative Data Inaccurately
    グラフはゼロベースにしろよなとか。はい。
  • Arranging Information Poorly
    重要な数字は prominent に、注意すべき数字は stand out させ、比較すべきものは隣に置く。
  • Highlighting Important Information Ineffectively or Not at All
    後の章で詳しくやるよ。
  • Cluttering the Display with Visual Effects
    謎の装飾はやめろ、みたいなの。これは自分にはさすがに関係ないが, vendor がつくる昔ながらの dashboard ではたしかによくあったかもしれない。例示される screenshot が厳しい。
  • Misusing or Overusing Color
    無駄に関心を引く色を使っちゃうとか。こういうの dashboarding tool がデフォルトの palette をまともにしてくれればいいんだけど、なんか無駄に赤とか入れてくるよな・・・。その点モダンなチャーティングライブラリはえらい。
  • Designing an Unattractive Visual Display
    過剰な装飾はダメとはいえ ugly すぎるののも困るから aesthetics も気にしような、あとの章で教えてやるかんな、という話。はい。

今や自明なものもあるし、なるほどというものもあるし、よくわからんから後の章に期待というものもある。コンテクストの不足、情報の過剰、Arrangement の工夫、一画面に収める、とかはできてないときもあるので次からはちゃんとやりましょう自分。

Chapter 3: Assessing What's Needed

  • 要件定義ちゃんとしような、という章。
  • Begin With a Definition
    "It is an information display that will keep them aware of what's going on in their specific realm of concerns". EDA とかのツールじゃないからね、という話。
  • Focus on the Goals, Not on the Means
    エンドユーザからの fancy にして欲しいという要望は無視し、彼らの必要とするものを作ってあげなさいね、という話。はいはい。
  • Get into People's Heads
    Dashboard を読む人のメンタルモデルに沿って画面をデザインしてあげようね、読み手のメンタルモデルをインタビューするときはホワイトボードに図を描いてもらって、いろいろ質問しながら図に矢印とかを書き足してもらおうね、初心者はそもそもメンタルモデルがないときもあるから育ててあげようね。という話。
  • 最後は余計なお世話というか出過ぎた主張だと思うが、Dashboard はさておきメンタルモデルや問題意識の共有というのは必要で、しかし自分はしばしばさぼりがちである。PM とかこういうの話し合うの好きで、話が長くなって仕事が進まないのでイヤだなーといつも思っているが、数字を中心とした design doc 的なものを書いてそれを dashboard という形で実装する、というフローは必要なのだろうなあ。business objective の定義みたいな。まあ business ってほどじゃない性能上の指標なんだけど。
  • Ask the Right Questions
    • Dashboard の更新頻度は?
    • 誰が読むの?
    • 何をモニタするの? なんの目的で?
    • どういう疑問にこたえたいの?
    • Dashboard をみてどんなアクションをとりたいの?
    • 具体的に表示したい項目は? それぞれ何がわかるの? 詳細が必要なのサマリが必要なの?
    • 目的のために一番重要なのはそのうちどの数字なの?
    • どういう logical grouping があるの? 各数字はどの group なの?
    • どの数字とどの数字を比べたいの? 互いにコンテクストを提供できる数字たちはどれ?
  • このリストは comprehensive ではないといってるが、良いリストだね。耳が痛い。Dashboard design doc があるとしたらこういう質問には答えてしかるべきだな。作ってみないとわからないものもありそうだけど。
  • Identify Information that Really Matters
    上の質問リストに出てきた数字のうち、実際に性能に影響を与えるものだけを dashboard に含めなさい。人々は実際には使わない数字を念のためと入れたがるけど、空間や関心を無駄遣いするのでやめなさい。入れたがり屋さんには「あんたその数字をみてどう行動するわけ?」と聞きなさい。そうですねー。EDA してた名残でなんとなく入れちゃうチャートとか、割とあるよね。
  • Identify Useful context for Measures
    それぞれの数字を読むにあたって役立つ context が何か identify しなさい。たとえば "targets, standards, measures of the norm, or the past data." - "Compared to What?" - これ全くその通りだけど一方で内製の dashboarding tool はチャートにこういう情報を埋め込む支援が全くない、というか不可能。Altair も支援といえるものはないけど、コードを書けば任意の線を埋め込めるのでなんとかなる。むしろ dashboarding tool 側ではなくそいつの参照する SQL の側にこういう指標を埋め込んで、可視化用のデータを生成を生成すべきなのだろうな。

短いがなかなか有用な章だった。読書はここまで。

読書活動 - The Food Lab

|

The Food Lab: Better Home Cooking Through Science

夜は眠くてやる気なくても読める本を寝る前にちょっとだけ読むことが多い。その記録もつけてみる試み。

Chapter 2: Soups, Stews, and the Science of Stock

  • Collagen/Gelatin は connective tissue である。legs, wing, back and skin に豊富。
  • Meat only stock -> flavor. Bone only stock -> body. Carcasses -> Both
  • carcasses は food processor で砕いたのちに simmer する。Flavor が短時間 (45min) でよく出る。Gelatin は摘出されないがそれは市販の gelatin を足せばよい。

誤読活動 - Polaris: a system for query, analysis, and visualization of multidimensional relational databases

Stolte: Polaris: A system for query, analysis, and… - Google Scholar

久々に出社し、タダで使えるプリンタがあるのを思い出したので星空日記で積み残していた Tableau の元となった論文を読む。

  • RDB に入っているデータを引っこ抜いてチャートを描く GUI を作りましたよ。Grammar of Graphics にインスパイヤされた可視化を GUI でチョイチョイと作れますよ。指定された可視化仕様に基づき SQL をつくって RDB から引っこ抜いてきますよ。
  • という内容で、完成されている。Tableau... はさわったことないけど社内のダッシュボードツール(Data Studio を武骨にしたようなもの)はこれをしょぼくしたものという風情。2002 年でこの完成度。そりゃ Tableau 流行るわけだわ。
  • データや代数のモデルを RDB/SQL に寄せてあるのが GoG との違いだと書いてあるが、20 年後に振り返ると成功している。もちろん ggplot2 路線にはそっちなりの良さもあるんだけど、GUI で画面を作るに際して UI の操作を通じて結果の可視化を軸に SQL を組み立てるアイデアがエレガントかつ正しいバランスをヒットしていて見事。
  • このあと WU とかから出てきた研究でここまで「やるな!」感がある論文は星空日記では発見できなかった。つまり一族の親分たる Patrick Hanrahan はすごかったね。

しかしその後の Tableau の発展はアカデミアに還元されることはなかったのだった・・・と書こうと思ったら Tableau Research というのがあり、論文わりと面白そうじゃないですか。タイトルで選んで記録:

可視化は自分の関心が高まってるせいもあってどの論文も面白そうでよい。

あと Polaris の被引用リストを見ていたら The Grammar Of Graphics の論文バージョン 2012 を発見したので、書籍 Grammar Of Graphics じゃなくてこっちを読もうかな。

移行活動、読書活動

|

夢。仕事帰り、広尾の築四十年家賃七万円のアパート、屋外の小汚い共用洗濯機で隣人と雑談しつつ服を洗いながら、そろそろ親も年だし実家の近くに引っ越して、家賃ももうちょっと金かけて小ぎれいなところに住むかなどと考える。その汚い洗濯機を使うなコインランドリーにしておけ!と動揺して目が覚める。隣人との雑談がなぜか英語である。そしてあのアパート、洗濯機は自分で持ち込んだ気がするな。

さてブログを公開しないと。

一目にさらすのが憚られるエントリをドラフトに戻し、ドラフトのうち今みると別に公開してもいいかと思えるものを公開に切り替え、気づいた範囲でタイポを直し、git commit -u && git push. Netflity の設定が死んでいなければ公開されることでしょう。Netlify にしてあるよね?なんかいろいろ mess なのだよな・・・と Netflity の dashboard を見たところ、ファイル名不正とかで失敗していた。修正。

はい、無事公開されました。よかったね: steps to phantasien

というわけで code-server を動かしていた VM も停止。

はーこれで "steps to phantasien" というブログも終了。この名前はもはや四半世紀くらい使っているはずだな・・・と Web Archive を確認すると・・・。あった中二病が痛すぎてリンクをするのに躊躇するが、この URL を思い出すのに一分くらいかかったので記憶から消え去る前に記録しておく。それにしても 20 世紀からブログ(という名前ではなかったが)書いてるとかすごくね?お前が東村山で書いてるそのウェブサイトは 23 年後に Mountain View で終わるぞ。黒歴史になりそうなとこは消しとけ、と教えてあげたい。


さて活動記録をつけるにあたりやりたいことや読みたい本を整理するとか Notion を再セットアップするとかをやりたい気もするが、そういうメタ活動に時間を使いすぎるのもアンチパターン感があるので、適当に積読から一冊選んで読み始めます。

Information Dashboard Design: The Effective Visual Communication of Data - 仕事で dashboard を作る機会が増えたものの、それらの dashboard が良いとは思えない(良し悪しの判断すらできない)という足元の覚束なさから買ったまま積んでいた本。

Chapter 1: Clarifying The Vision

  • 世の中の dashboard のダメさ。物理的な "dashboard" の skeuomorphism はゴミという話。へー昔はそういう dashboards がいろいろあったのだねー・・・。
  • Vendor が製品を fancy にみせるためにつけた pre-defined な dashboard のダメさ。へー(同上)。
  • 歴史。90 年代に OLAP や BI がもてはやされ始め、ゼロ年代初頭に Enron のスキャンダルがあってビジネスにおける監視の重要性が見直され花開いたという話。それとは別に工場とかの機器が電子化・ネットワーク化されて画面がつき、その監視のためにエンジニアが考えたゴミのような監視 UI がつくようになった。はあ。
  • Dashboard とは何か:

A dashboard is a visual display of the most important information needed to achieve one or more objectives, consolidated and arranged on a single screen so the information can be monitored at a glance.

P.26

  • スクロールが必要なものはもはや "a dashboard" ではない。一目みてわからないから。
  • Dashboard は用途に応じてカスタマイズするのが大前提である。つまりインフラチームとかが作ってくれているお決まりの可視化ツールは、カスタマイズの支援の程度によってはゴミ化する可能性がある。
  • Dashboard は以下のものではない:

- A display that is used for data exploration and analysis
- A portal
- A scorecard
- A report that people use to look up specific facts

p.30

  • なるほど...
    • EDA を混ぜがち、というは自分の感じていたすわりの悪さを説明している。
    • Portal を混ぜがち(なせいでちゃんとした Portal がない) という問題も同じ。
    • Scorecard は一緒なのでは、と思ったが、そっちには決まったやり方というのがあるらしい。

  • Dashboard は "Situation Awareness" を高める。つまり alert が発生する前からなんとなく全体の状況を把握するのを助ける。のでいざ alert が発生しても慌てなくて済む。
  • Situation Awareness を update する -> 注意の必要なものがあるか判断する -> あれば詳しく見て、対処の必要性を判断する -> 対処するならする。
  • Dashboard は "need to leverage people's visual capabilities" ということで次章につづく。

今日はここまで。読書は椅子に座ってやるよりタンスとかの上に本を置いてストレッチとかしながら読むほうが眠くらななくてよいね。

週例活動 - 図鑑探し

|

今日は weekly review という名の雑用の日です。Weekly Review のテンプレを Notion に移行しなければ・・・とおもったがそういうことをしてると作業が進まないので何はともあれ家計簿でもやりますわ。はい。

ところで WP.com は xxx.wordpress.com の XXX が選べなくなって、いよいよ実質上有料といった風情。別にいいけど、時代だねえ変えられた。日本のブログサービスは滅茶滅茶いろいろあって、よく続いてるよなあ。ブログ大国といってよいのではないか。一方日本語で「ブログ」で検索して出てきたサービス紹介のブログ記事は Medium は載ってないし(まあそれはいい) WP の紹介は間違ってるしで、ブログというものの現状をよく表している気がする。

Disnesy+, 1-2 本みればだいたい元が取れるが、最近ほんとにスクリーンを見な過ぎてこれですら元が取れていない・・・。

Todoist に「日本語のサイエンスっぽい本を探す」(子向け)というタスク。自然科学ね。図鑑だとモノは列挙されているがいまいち説明がないのでは…というような話をしていたのだった。しかし図鑑いまいち説が事実なのかをまず確かめようではないか。図鑑に迷ったら!図鑑最新情報&おすすめ100選! | 絵本ナビスタイル とか見る限りでは事実な気がする。

「植物」というカテゴリに絞った時点で図鑑になってしまう?もっと生物の読みものとかで探すほうがいいのではないか。それとは別に図鑑もあっていいと思うけど、日本語だと日本の植物の図鑑になってしまうのがなあ。それ生えてねーっつーの(言いがかり)。植物図鑑は英語でよくないですかね・・・。

といったところで 1-2 冊リストに追加のち時間切れ。書店にアクセスできない厳しさ。

移行活動 - From Hugo To WP.com

|

というわけで Blog を Hugo から WP に移行中。移行といっても仕切り直しなので特にコンテンツの移動とかはなし。かわりにドラフトという名目で公開をさぼり続けている Hugo のブログを公開する作業をします。

今はドラフトの repo を公開用からフォークして書いている。理論上これをマージすればよい。ということでやってくぞ。しかし Ubuntu から Windows に来て以来なにも開発的な設定をしていないので、それも並行してやらねばならず、だるい。

作業予定 (TODO: Notion に移動する)

  • anemone.dodgson.org にドラフトをマージして中身を確認
  • anemone.dodgson.org を公開 (push)
  • ドラフトを書くのに使っていた code-server の VM を停止。(削除はいずれやる。)

WSL に Hugo が入ってない(入ってるわけない。)いれます。

マージは no conflict で成功。最後の終了のアナウンスを書き、眠いのは今日はここまで。明日は push をします。

リンク記録

はじめに

長いことブログというものを表立って書いていなかった。なにもインターネットに存在感がないのは寂しいのでまた書いてみる。

人々に言いたいことは今のところ特にないので、かわりにしばらくは自分が余暇の時間にやっている読んだり書いたりの活動を記録していこうと思う。森田が報告・連絡・相談するので法蓮草の森。連絡と相談はたぶんしないけど、語呂優先です。

Moving

Hugo を使ったこのブログ、2015 から更新しているようなしていないような状態のまま使っているけれど、 そろそろ引退させようとおもい作業をしている。

ブログとかを書いていると虚栄心などで気が散り精神衛生を損ねたりするという理由でブログの公開を年一回にしたのが 2016 年。 その後、子ができて忙しくなったりで段々と公開するのがめんどくさくなり、そもそも書くのもめんどくさくなり、書くこともなくなり、読む人もいなくなり、と荒廃が進んで今日に至っている。

友人向けに管をまく雑談はぼちぼち書いており、そういうのはパスワードで保護されたドラフトサイトでだけ公開し、ドラフトのままにしている。 そのほか自分にだけ読める braindump や走り書きなども少しあり、そういうのは draft サイトにすら表示されない特殊な状態で、localhost のプレビューでのみ読めるようになっている。

公開にあたってドラフトのうち衆目にさらしてもよさそうなものを cherrypick しようとしたが、ほとんどない。 愚痴とか気の迷いの謎の活動とかが多くてあまりにしょうもない。このブログ最後の更新は、ほんとに何も読むべきものはない。 まあ家事子守疫病とかで忙しいかったのだよね。他人のためになんか文章を書くとか、そんな余裕はゼロ。

なおこのブログを閉じるのは別にブログというものをやめたいというわけではなく、 むしろ今後はふつうにリアルタイムでどうでもいい日記的なのをどこかのブログに書こうかなと思っている。 この anemone.dodgson.org を終了するのは、単に区切り目というだけ。

時が流れ、加齢とライフステージの変化にともない虚栄心とかがなくなったのでリアルタイムにブログを書くくらいは問題ない、 というのはうそで、最近はガチで他人に自慢できる要素が自分の人生から消え去ったので虚栄しようがなくなった。 自分がぼんくらおっさんであることを隠す意欲すらないので、逆に息抜き・社交として日記とかを書く気が起きたかんじ。

行先の URL はまだ決まってないので、きまったらまたここに書きます。

継続可能な趣味にむけて

今年は出世を通じた給料アップを目指して真面目に働いてみるかと課外活動を中断していたが、あまり良いアイデアでない感触がある。 そもそも出世を目指すのがいいアイデアなのかという話はあるがそれはさておき、 課外活動がないと仕事がイヤだったり辛かったり家族にトラブルや緊張があったりするときに心の拠り所がなくて、しんどい。 そういうしんどさがあると自分の元気が失われて仕事も家庭も捗らず、悪循環になる。 そして仕事のイヤなことは(出世を目指すと特に)色々あり、家庭も大きな問題はともかく細かい心配は事欠かない。

W/L バランスのジャーゴンで「仕事をデタッチする」という言葉があるけど、 仕事をデタッチするには残業とかをしないだけでなく、関心等の知的資源をより能動的に他のものに注ぎ込まないといけない。 でないと業務外の時間でも仕事(や家庭)の問題をぼんやり考えて気が休まらないし、 本来は生産的に使える早朝に布団から起きるのが憂鬱で無駄に寝たりしてしまう。 要するに早起きしてやりたいくらいの楽しみがあるとよい。それがない人生はしんどい。

そもそも課外活動を中断したのは、その時間を仕事に使って生産性を高めたり出世対策をしようとおもっていたからだった。 そういうの、しなくていいのだろうか。というと、いいかどうかはわからないが、今は期待したほどできていない。やる気が起きない。 それに、もし課外活動の時間を使わないとできない出世なら、しないほうが良い気がする。持続可能性がない。 出世した後は従来どおりかそれ以上の成果を期待される以上、出世後もその手の残業相当は必要になる。一時的にがんばれば済むものではない。 しかし出世をすると仕事のイヤさや大変さは確実に増すので、 デタッチして気力を取り戻す時間の必要性も増す。この二つは両立できない。 だから業務時間内の仕事でたどり着ける給料が、自分にとっては身の丈なのである。 残業は強靭な心身を持った人間にだけ許される特権的行為で、その力は自分にはない。ここ 1-2 年の実験の結論。

そもそも辛かったりイヤだったりする仕事はやらないほうがいいのではという話はあるが、 自分はあまり楽しい仕事への期待が薄い。今の会社でそんなに楽しく働いてた期間、 まして情熱的にぜんぶ突っ込んで働くような勢いがあった時期なんて、ない気がするのだよね。 楽しかったはずの入社後数年も、日記みるとなんでか知らんけど憂鬱っぽい。 その後も楽しい仕事をもとめて数年ごとにチームを点々としてるけど、結局そんなに楽しく情熱的に働けたことがない。

どうせ楽しくないなら、かわりにイヤさを乗り越え給料アップできるか試してみよう。年初にそう考えた。 やってみた結論が「やっぱ出世より仕事楽しいほうがいいな」となる可能性は高いし、 しょうじき現状は既に挫けかかっているわけだが、まあ一回くらい試してみてもいいでしょ。

今までキャリアを前に進めるための時間だと思っていた課外活動を、 楽しいことをしてネガティブな感情を切り離す時間と捉える。 “Work Hard, Play Hard” なんて使い古されたクリシェだけど、自分にとっては新しい。


課外活動で何をするか。

課外活動中断期間中、やる気が出ないのでなんだかんだで YT を見たりアニメを見たりした。 こういうのは時間はつぶれるしその瞬間は一定程度楽しいのだが、デタッチされる感じがしない。 自分はこういうメディア消費に没入する訓練が足りてない気がする。アニオタ力が低い。

それよりは、従来は「キャリアを前に進める」という名目でやっていた勉強だとか、 オープンソースだとか、そういうやつのほうが(ものにもよるが)没入できる。 今までは仕事の足しになることを重視していたので選択肢が限られたが、 楽しさを求めるならもっと素朴に「かっこいい」「楽しそう」みたいな動機でいろいろやってみればよいかもしれない。 もちろん仕事の足しになるものでも楽しめるならやればよい。

これは去年の頭に考えていた話と似ている

そういう個人の活動のほかに、インターネット芸人活動も楽しいので、やりたいね。主に Podcast. Misreading Chat は論文を読む満足感も含めて楽しさの達成にはすごく成功していたので、そのうち再開したい。 他の podcast はどうかというと・・・まあ特にアイデアもないし、まずは Misreading Chat だな。 ただ頻度を上げすぎると day job や家庭の責務を損なうことが過去の経験からわかっているので、 ペースは緩めで行く。

インターネット芸人活動としてブログはどうかというと、書くのは楽しかった時期もあるのでなにかしらやりたい気はしている。 友達にだけ書いて送る今のスタイルはそろそろ終わりにしたいと思っていたので、いい機会だと思う。

事実上の非公開ソーシャルメディア代替品であるこのブログ、 結果として仕事や家族の愚痴みたいなのや、謎の気の迷い活動の braindump ばかりになっている。 そういうの、溜飲は下がるが楽しくはないのだよ。 だから最初から公開で書くブログでは仕事の愚痴、というか仕事の話はぜんぶパス。デタッチしたいわけだから。 あと自分の意見や主張を披露するみたいなのもなるべくパス。楽しくない。

それよりは勉強したりコードを書いたりした話を書く方が楽しいんじゃないか。 去年 DuckDB にパッチを書いていた時は、コードを書くのも楽しかったけど、 同時に書いていた日記 にも楽しさがあった。 code-server 移行日記Altair 研究日記 も、 DuckDB ほどではないにせよある種の楽しさはあった気がする。 こういう作業記録をブログにするのがいいんじゃないか。読む人がどれだけいるのかはわからないけど、 書く行為と活動がシームレスで Morrita Notes で挑戦した “tech blogging” の大変さはない。仕事や家族の愚痴みたいな暗さもない。 他人はともかく自分で読みなおすのは楽しいし、勉強や作業の動機付けにもなるかもしれない。炎上とかする要素もないので安心。

というわけで、まずは

  • 勉強やオープンソースなどの個人活動
  • Podcast (Misreading Chat)
  • これら日々の課外活動の記録を中心としたブログ

を自分の課外活動の軸にしようではないか。なんかいっぱいあるけど、 一度にいっぱいはできないので無理ないペースでぼちぼちやるかんじ。


去年は 毎月プロジェクトを決めてやるという方針でがんばろうとしたが、 あまりうまくいかなかった。月という区切りと関心の区切りを一致させるのが難しい。 仕事だと外圧があるのでこういう time boxing をしてもある程度は規律で関心の向きを切り替えられるが、 楽しさ重視なら連弾の作業/プロジェクト日記をつけて飽きたり区切りがよくなったらおわり、くらいでいいんじゃなかろうか。

ブログはどこでつけるか。

このブログは、いまいち。過去の暗さを引きずって辛気臭いし、作業日記を串刺しスクロールで眺めることができない。 今は一つのページに書き足すことでスクロール問題を回避しているけど、人が読むブログとしてはいまいち。 カテゴリなりタグなりで検索できる、普通のブログのほうが良い。 あと static site generator はセットアップにしろ編集にしろ若干面倒が多いので、WP.com あたりで済ませたい。 もう hugo を設定する気力がない。WP.com 遅いけど、メモ取りツールとしての期待はないから我慢できるでしょうたぶん。

この楽しい前向きな課外活動ブログとは別に、Fragments を含む愚痴を書き捨てる場所は一応残しておきたい。 特に箇条書きの Fragments は自分にとって Twitter 代替の脊髄反射破棄施設なのでないとまずい。 ただお友達に冷やかしていただき、脊髄反射を成仏させられればよい。Notion あたりに書けばいいでしょう。

ランダムな技術メモを置く場所がなくなるが、現状すでにこのブログのメモとしての役割はあまり活用できていないので、気に病むこともない。 数も多くないだろうから、とりあえず @kyanny’s blog を見習ってブログに混ぜておけばいいのではないか。 公開できないものは Notion に置く。

この code-server は…店じまいかなあ。頑張って設定したので勿体ないけど、居場所がなくなってしまうね。 いまのところサーバ代も WP.com + Notion Persnal Plan より高いし。

最初の課外活動は、このコンテンツを anemone.dodgson.org に公開することとしよう。

Untiled Braindump

今年は真面目に働いて出世を目指すという挑戦をしてみようと思い、趣味活動を止めて仕事に注力してみたが・・・無理げ。

なお仕事に注力といっても別に残業するわけではない。 ただ課外活動が楽しいと本業のアテンションを奪いがちなので、ガツっとした趣味活動は控えることにしていた。 仕事に関係する本を読むとか、やる気がないときは YouTube 見るとか、そのくらいにしておく取り決め。

だけど、出世を目指すのも課外活動をとめて仕事の生産性を高めるのもうまく機能しなかった。


無理さの一つ目として、まず出世について考えれば考えるほど仕事が楽しくなくなる。 他のチームとのパートナーシップを頑張ってなんかするとか、自分は性能担当という立場柄自然とそういう仕事が増えがちなのだが、 そういうのはマジで楽しくない。自分のコードで問題を解決するんじゃなくて、問題を見つけて直してもらうわけ。 問題を見つける作業自体はそれなりに面白味があるけれど、それを人にたのむとか、もうね。 しかもパートナーというのは部下とかじゃないから全然やってくれないわけ。 そういうのつつく仕事とかさ、楽しいわけがない。

チーム内での initiative を found/lead するとかも、アイデアがないではないけど別にやりたくない。管理業務が増えるだけじゃん。 プロセスを整備して、参加を説得して、それを回すとか、尊い仕事なのは否定しないけど、やりたくない仕事をやるからこそ尊いという面があるわけだけど、やりたくない。

出世のためにこういうのを一時的に、たとえば一年とか頑張って、結果として何か良い立場になれるならいいんだけど、 むしろそういう仕事が多い身分になってしまう。全然うれしくない。やる気が起きない。 金を稼げる可能性があるのは素晴らしいが、そのためにやりたくない仕事を我慢しつづける、というアイデアは受け入れがたい。精神力予算を捻出できない。

そういうリーダーシップな身分になって、部下は持たないまでも色々なミーティングに呼ばれるようになり、 部下はもたないまでも様々な workstream を通じてチームメンバーを指導啓蒙するようになり、 そんな中で自分は何を学べるのか。いやリーダーシップスキルとか学べるんだろうけど、そんなの別にいらないよ・・・ むしろクラウドとかモダーン言語とか触らせてくれよ・・・。

しかも管理職と違い、出世はキャンセルできないのである。管理職は IC に戻れるが、リーダーはヒラに戻れない。 なんでだよ。もしやる気出せなくて生産性低下とかした日にはクビになっちゃうじゃん。リスクが高すぎる。 他のチームに移るにもリーダーシップレベルにあった仕事を選ばなくてはいけなくなり、そんな期待値を meet できるはずがない。 だからリーダーシップになってからチームを移る人は少ない。

このイヤさ、無理さは出世チャレンジを始める前から予期していたが、予想が外れる淡い期待があった。 が、今のところその期待は微塵も満たされていない。むしろ目を凝らした結果イヤさの解像度が上がってしまい、 積極的にやりたくなくなってしまった。

はー・・・。 まあ、器が足りてないのだろうなあ。もっと圧倒的コーディング力があれば、その実力を理由に出世できるわけで、 引き続き実力を発揮しつづければよい。しかし自分の場合はテクニカルな実力不足をリーダー税で埋め合わせないといけない。 前にも書いたなこれ。

そして今のチームにいてもその実力が上がる気がしない。 自分に期待されているのは窓口業務であり、すごいコードでチームをリードすることではないから。 なんか遅いといわれたら遅い原因を調べて、遅さの原因をつくった人に文句を言って、直すのを手伝ってあげる。 毎年この繰り返し。

ここ二年くらいは COVID だの WFH だので慌ただしく、仕事をこなすだけで精神的に精一杯だった。 年末年始にようやく気持ちを立て直し、金欲しさに仕事をがんばろうと年初に決意をしたが、 いざ取り組んでみると先の暗さが際立った。


無理さの二つ目として、課外活動ゼロはしんどい。仕事がつまんないとき(つまり大部分の時間)、人生に楽しいことがない。 ただ楽しいだけでもだめで、アニメ見るとか YT 見るとか、そういうのだけだと満たされないことがわかった。 なにか勉強するでもオープンソースするでも論文読むでもいいけど、前に進んでいる気分になれる要素が欲しい。 それがないと、自分の中の水がどんどん枯れていく感じがする。

理想的には仕事がそういう「前に進む感じ」に繋がればいいんだけど、残念ながらあまりそれはない。 SQL 書くとかは楽しいし学ぶことはあるけど、付け焼刃の域を出ない。成果を出すのを優先すると何かを学ぶのに時間を使えない。 明らかに足りてない手持ちの駒だけでゲームしてるこのかんじ、しんどい。

皮肉なことだが、仕事は自分の不足、勉強すべきものを教えてくれはする。 たとえば自分は Linux のスケジューラに詳しくなりたいし, EDA や統計を含むデータサイエンスはちゃんと勉強したいし, MediaPipe とか On-device ML 周辺のスタックも勉強したい. モニタリングもできるようになりたいし, Data Warehouse の基礎もやりたい.

でもこういうのは「今」必要なのであって、仕事は自分が勉強するのを待ってくれない。 問題は次々にやってきて、それを表面的な知識でなんとなくやりすごしていく。

客観的に言って、自分はこういう「やるべき勉強」をやればいいはずだが、 どうにもやる気が起きない。やる気がないというと御幣があるかもしれないが、とにかく実施できてない。 動機がどうこうより、単に元気がないせいなかんじがする。日々が楽しくないと元気でないじゃん。

結果として趣味性の高い余暇活動も、仕事の勉強もしておらず、停滞感と枯渇感だけがある。


この二つの厳しさ、つまり仕事の積極的なやりたくなさと、余暇活動の不在の二つが重なり、 しんどい。生産性もゼロ。

打ち手はいくつか考えられる:

  • 自分を説得して仕事のやる気を出す。
    • なんとか今のチームで出世を目指す。チームの景気のようなファクターもあわせ、出世が今までで一番近いのは事実なので。ただなんともいえない無理筋感がある。
    • 見切りをつけて楽しそうな仕事をできるチームを探して移る。まあ楽しい仕事があればいいんですけどねえ。
  • 仕事は諦めてほっておき、課外活動をがんばる。これはだいたい去年のはじめに考えたのと同じことである。 気分としてはしっくりくるが、金を稼ぐ可能性を破棄していいのか悩ましい。むしろ下がりかねない。

けどまあ、出世を通じて金を稼ぐのは自分には無理そうというのがこの 2-3 カ月の結論ではないのか。 あまりに残念すぎる結論なせいで、なかなか受け入れることはできないけれど。

ただ仕事をほっておくかどうかはさておき、業務時間を超え課外活動を犠牲にして仕事を頑張ることができないのは残業チャレンジの失敗からも確かだろう。 精神衛生の保護という観点からも、業務時間外で仕事について考えるのはやめた方がよい気がする。

つまり、自分は課外趣味活動を再開したほうがよい。 余暇は楽しいし、仕事にまつわる憂鬱な考え事を遠ざけてくれるから。 これは今日の結論としてよさそうである。


では仕事はどうするかというと、

  • 今のチームで出世を目指して頑張る・・・のはナシ。
  • 今のチームで現状維持くらいのかんじでやる。
  • 今のチームで違うことをやる。
  • 違うチームに行く。

まず現状維持がどうかというと、楽しくはない。これは仕事がもともとそんあに楽しい性質のものではないせいでもあるし、マネージャとか PM とかの関与が増えた結果以前より楽しくなくなった面もある。ただ出世しないと決めれば期待値は下げられるので、少しは気が楽になる可能性はある。

パフォーマンスからは手を引いて、もうちょっと違うことをやらせてもらう。いまいち現実味を感じないね正直。結局なんらかの性能問題が発生し続けることはわかりきっており、そういう火が視界に入る中で無視して違うことをやるとか無理でしょ。チーム内での人間関係が大幅にひずんでしまう。問題児になってしまう。

違うチームにいく。今のチームで積み上げたカルマは消え去るので、出世の見込みは完全に消える、のみならず、一時的には給料が下がる。仕事は、少なくとも一年くらいは何かしらの学びを期待できる。

書き出すと違うチームに行くのが良いように思えるが、なんとなく不安と名残惜しさがある。性能対策いろいろストレスあるけど、この成長チームに 5 年近くいるおかげでチームの中での立ち位置もあるし、組織も比較的よく理解している。そういう組織経験に伴うラクさはある。このラクさは、仕事本体の大変さとは直行している。仕事も、面白くないことも多いが少なくとも評価はされており、立場の無さからくる不安は薄い。製品もそれなりに成功していて、景気の悪さからくる空気の淀みが少ない。これは勤務先のような成熟大企業では割と珍しい。

つまり今の身分はミクロには悪いがマクロには良い。このミクロな悪さをなんとかできないものかと思っている。一方でこのミクロとマクロのギャップはブラウザの仕事をしていた時と似た既視感がある。チームや製品ががよくても、自分の仕事がつまらなかったらそれはつまらないのだよ、多分。


アプリの性能改善にはそれなりにフロンティアがあると感じているのも、迷いに繋がっている。自分たちのやっている仕事はある面で SRE 的な性格を持っている。つまりクライアントサイドでありながら、生きたソフトウェアを相手にしている。Site じゃなくてアプリなので App Reliability Engineering みたいな。カメラのようなクライアントサイドの複雑さが集積したアプリを、現代のテクノロジの力で「安定稼働」させる。クリーンでテスタブルなコードを書けばみんなハッピーでしょ、みたいな 20 年同じことを言ってるアジャイル勢とは違う、より現代的なソフトウェア開発の視座を手に入れつつある、しかも分散システムじゃなくクライアントサイドという特殊性から立ち上がるユニークさもある。それを追求したいという気持ちがある。

が、それを追求しようとしてやることが他人の遅さを探して問い詰めたり、関係各位の合意をとって API を開けてもらうような仕事なのだとしたら、というか現状そうなわけだが、うれしくない。テクノロジのフロンティアを開拓できるかもしれないという理想上の期待と、目の前にある現実にギャップがありすぎる。ここにも既視感がある。つまり App Reliability Engineering なんてのは自分の妄想の産物にすぎず、現実は終わりなき firefighting なのだよ、みたいな。ブラウザ仕事の最後の頃、こういう幻に振り回された苦い記憶がよみがえる。

隣のチームは、レイテンシという自分の守備範囲以外でこの Reliability Engineering 業をかなり見事にやり遂げている。 一方でそのためのがんばりはプロセスの整備やチームの立ち上げをはじめ自分の苦手分野のものが中心で、あまりできる気がしないし、積極的にやりたい気持ちも湧いてこない。 覚悟が足りないといってもよい。自分の TLM がそういうのをうまくやってくれるといいんだけれど、残念ながら期待できない。難しい問題なので文句をいう気もない。

自分が今のチームでやる意義のある仕事があるとしたら、この App Reliability Engineering というファンタジーを現実のものにする leap of faith を実行に移すことなのだろうね。 それがうまくいけば出世もできるし、うまくいったということは何らかの解決をしたということで、そこには学びもあることでしょう。 一方で、そんな難しくて大変で苦手なことに挑戦すんの?という疑問もある。organizational change とか、自分には何の強みもない分野じゃん。 こういうのうまくいった体験談は survivor bias でかっこよく見えるけど、下手したら burn out していまうし、そうでなくても他の仕事の可能性を犠牲にしている。機会損失がありうる。

もっといえば、具体的に何をすればいいのか全然わからない。そして具体的な道筋を figure out するまでの数年間、今のしんどい火消し仕事が続く。何も figure out できないかもしれない。

やるべきことがあるのにしんどくて逃げてしまった記憶は新卒で入った会社にさかのぼる。 あのときは仕事だけでなく若気による鬱思考などもあってがんばり切れなかったし、 あの会社はどのみち成功しなかったので逃げ出した判断は結果としては悪くなかったが、 やるべきことをできなかった名残惜しさはなかなか消えなかった。そのあとの自分のキャリアも別にぱっとしなかった。

今はそれよりはずっと見込みのある状況で、つまり自分の実力とやる気がボトルネックで、製品自体はそれなりに見込みがある、気もする。


ただ翌朝になって考えてみると、excitement より nervousness が勝っている感はある。 excitement の絶対量はこれまでの仕事より大きいが、コミットメントに伴う nervousness も大きい。 仮にこれを成し遂げたところで、自分を待っているのは at best で給料は多いが責任も多い立場。 そしてそんな成功があるとは限らない。そしたら中途半端な責任と増えない給料だけが残ることになる。そして一年以上の時間が失われる。 それは worth なのか。


たぶん、課外活動の時間、趣味の時間は、は自分にとっては safety net のようなものなのでないか。心の拠り所というか。 趣味に時間をとられすぎて仕事がおろそかになる、仕事は適当にやって趣味だけやるのは雇用をリスクにさらすのでダメだが、 仕事を頑張るからと趣味の時間を失うのも、精神衛生をリスクにさらすのでよくない。

以前は課外活動をキャリアを前に進めるための時間ととらえていたが、今の自分にとっては役割が変わった。 課外活動は仕事や家庭といった潜在的なストレス減から自分の心を守るために必要なものとなった。 課外活動、趣味に没頭して頭をストレスから切り離すことで、健やかな心を守ることができる。 なにか退屈だったりやりたくないことがあるときに、前向きに頭を使えることがある。 今の自分にはそえが重要。だから課外活動を途切れさせてはならない。 常に楽しい、頭を使える活動があるように積極的に計画などをしたほうが良い。

とはいえ課外活動が大変すぎると、いくら楽しいとはいえ自分の obligation である仕事や家庭に悪影響がでてしまう。 そういう過剰な課外活動は sustainable でない。途切れさせないよう気を遣うと同時に、大変すぎないよう throttle する必要がある。

逆にいうと、こういう心の拠り所があれば仕事が仕事が大変だったりイヤだったりしても頑張れるんじゃないかな。 幸い仕事の残業とかで課外活動の時間が奪われてしまう危険はそんなにないので、こうしたバランスを保つには割となんとかなる気がする。


というわけで、

  • 継続可能な課外活動の開発に業務外の時間を使いつつ、
  • 仕事は Reliability 路線の開拓を目指して業務時間の中でがんばる。ダメそうならまた考える。

あたりが next steps ということでいいんじゃないかな。

WSL2

WSL2 のビデオを見る。

  • Hyper-V based な VM らしい。ただしかなり para よりで、Microsoft が改造したカーネルが必要。
  • ということは、WSL2 用の Ubuntu とかは Microsoft と Canonical が協力してこの専用カーネルを同梱した特製 Ubuntu を作ってくれているということである。Vanilla Ubuntu ではない。Cloud 向けの distro images と似たような感じか。
  • カーネルが upstream じゃないのがどのくらい不安か考える。主要な不安: WSL は新しい Ubuntu のバージョンとかにきちんと追従できるのか。
    • Ubuntu にしたって vanilla kernel じゃなくて多少はパッチが当たっているわけだが backport が基本で、vanilla kernel を入れても動く。だから Ubuntu は別に MS patch に更なる変更をする必要はない。
    • Android とかは、最近は upstream を重視しているとはいえかなり激しくパッチが当たっている。Vanilla kernel は動かない。一方で Android は Ubuntu とかの distro を動かす必要はないので、kernel のバージョンが遅れ気味なのはそれほど致命的ではない。
    • つまり Ubuntu あるバージョンが新しめの kernel を必要としているとき, Microsoft が彼らの fork をきちんと rebase する、かつ Canonical と協力してそれを WSL2 向けにパッケージしてくれると、はじめて WSL2 で新しい Ubuntu が使える。どのくらい delay があるだろうね。半年くらいかな。22.04 を見ればわかることでしょう。
  • そのほかの不安: GUI 対応
    • Video subsystem は仮想化していないので、画面がない。
    • かわりに X/Wayland server を実装する的な方向らしい。これはいばらの道っぽい感じもするが、一方で GUI で使いたいものなんてそんなにないような気もする。Android Studio とかの IDE くらいか。なので、GUI が無いなら無いで諦めはつくかな。
  • Crostini と比べてみる。
    • WSL2 の体験は Crostini よりはだいぶ良いが、それは terminal がよくできてるとかブラウザ外での UX が Windows の方がこなれている(当然)からだと思う。
    • Crostini は WSL より para 度が低い、より普通の VM である。 Crostini は LXC という業界標準技術で VM の中にコンテナを作っている。LXC が何なのかよくわからないが、これで動く OS のイメージは canonical が host しているものが使えるらしい。official image ではないとはいえ、Microsoft 改造 distro ほど乖離してはいなそうだし、そもそも VM ベンダに依存していないのがよい。
    • 一方で性能は WSL2 の方が出そうな雰囲気。これは para の力とみることもできるし、VM 基盤 (Hyper-V vs Crostini) のやる気の違いともいえる. Crostini とかね、趣味 プロジェクトにしか見えないじゃん…
  • つまり WSL2 は vanilla VM と比べると para の力で性能や体験をチューンしつつ para の弱点はカネの力でなんとかしようとしている。

ただ ps とか top とかしてみると普通の Ubuntu と全然違うよね。プロセスが 10 個くらいしかない。daemon 類が完全に不在。このおかげで “shell を抜けた瞬間に VM を終了する” という “lightweight vm” が実現できているわけだが、一方でこんなにプロセスなくていいの? という疑問はある。たとえば SSH とかできないよね。自動化との相性は悪い。あと普通の Ubuntu (Cllient/Server) からの乖離はカーネルだけでなく、割とでかそうだな。


WSL2 でできないことはなにか:

  • 新しい/マイナーな distro を入れて遊ぶ. まあ、過去の実績からして杞憂だね. Ubuntu の LTS しか使ってない.
  • カーネルいじってあそぶ. これも杞憂系だが、やるにしても WSL の外でやる方がよいだろうね…
  • daemon 的に headless でなにかを動かす (ex. code-server, jupyter notebook). これができないのは微妙ではあるが…ただ Jupyter 動かないとかは考えづらいので、試してみた方がよさそうだな。

将来 WSL2 / Windows を使いたくなくなるシナリオはどんなものか:

  • Microsoft が再び世界征服を果たし, WSL のやる気を失う. これはなさそうだな. 別に現状でも desktop/laptop のシェア的には世界征服済なわけで.
  • Chrome へのいやがらせが加速して使い物にならなくなる. これはかすかに不安を感じるが, Edge を使いましょうということで. 仕事の Chromebook とアカウントが乖離するのは便だが.
  • 上にあげたような何らかの limitation に遭遇する. これはなんだかんだで一番心配, ただこれを解決しようとおもったらおそらく Mac でもだめで, Linux laptop 一択になってしまうねえ.
  • そういえば Rebuild.fm に出るときは Mac が必要だが… まあもう呼ばれることもないでしょう.

といった点を踏まえ、自分は WSL2 にどこまで魂をゆだねていいのだろうか。つまり次に買う laptop は Linux が動くものにすべきなのか Macbook がいいのか Windows-only か。

  • Linux laptop は…もういやだな、という気持ちがある。
    • 選択肢が少なすぎる.
    • 周辺機器が基本的には動かない。Podcast 撮るとか不安。
    • バッテリーが持たない.
    • GPU もへぼい.
    • GUI は大体もっさりである.
    • アプリも全然ないし, あっても出来が悪い.
    • とはいえコードを書くには最強.
  • Macbook もなあ…
    • M1 以降, 気軽に使える VM (VirtualBox) がなくなってしまった. Parallels みたいに有償でゴツイのしかない.
    • コマンドライン環境は, あるにはあるが Linux ではない微妙さがある. Docker とかめんどくさそう. ARM 故のめんどくささが重なる.
      • しかもバージョンを重ねるごとに締め付けが厳しくなっているように見える.
      • 一方でファイルシステムは GUI の世界とネイティブにつながってるので便利ではある.
    • バッテリーの持ちと性能は圧倒的に良さそう.
    • デバイスの選択肢はそんなにないが、その選択肢は世界で一番売れてるラインナップなので問題なし.
  • Windows は…
    • WSL2 は Linux でよい. 手軽な VM のない Mac に比べるとだいぶマシな雰囲気.
    • デバイスの選択肢がいろいろある.
    • 動作は, ビルドとかは Mac より遅いかもしれないが体感できる UI の速さは問題を感じない. (vs. Linux のなんでももっさりな GUI)
    • WSL2 の外でのコマンドラインは自分のリテラシ的に論外. PowerShell とか覚える気にならないし, ネイティブに Unix 系ツールがない.
      • これは日常のプログラミングを不自由にしそうだが、どうかな? そういうのは WSL2 の中でやればよい気もする.

結局のところ、自分はそんなに家でコード書かないし、Linux べったりに暮らしていないのだよね。 課外活動でコードを書く friction を最小化するために Linux laptop を使っているが、それを生かせていない。 一方で Linux laptop の不自由さは毎日被害を被っている。

などを踏まえ Linux laptop はやめて、かつ自分の中二病を発揮するなら Mac もナシで、次は Windows だな、という気分。 まあ laptop を買うというような大きな決断をする前に手持ちの laptop に Windows をインストールの上いろいろやってみて大丈夫さを確認するのがよいのだろうな.


ついでに WSL2 / Hyper-V の論文とかどっかにないかなと思い軽く探したけど見当たらず。残念。

「ハイブリッド勤務」にむけて

来月から出勤が確定した。一方で月曜と金曜は家から働けるらしい。 出社はしなくていいならしたくないので月金は自宅勤務にしたいが、家と会社の両方に環境を作るのが億劫。

いま自宅では Cloud の Linux と Chromebox の組み合わせがメインで、たまに Chromebook でキッチンとかからテキストを書いたりしている。 これまでの出勤ではその Chromebook を持参の上モニタを繋いで Cloud の Linux workstation と併用していたが、これは毎日だとイマイチ。 デバイスをぶら下げるのに hub が必要だし、ミーティングとかでモニタを外すとウィンドウのレイアウトが崩壊してしまうから。

会社には COVID 前から使っていた Linux のでかい workstation がある。仕事中はこいつをメインにして、 家からはこの workstation にリモートで入るというオプションもある。 ただ謎のセキュリティの制限によりリモートとローカルの両方から使うのは色々とバーが設けられており、だいぶやりづらい。

といった様々な組み合わせを列挙して pros/cons を検討しようではないか。

  • Chromebox+CloudLinux(+Chromebok) at Home, CloudLinux+Chromebook at Office
    • Pros: 会社でもブラウザ環境を Chrome OS にできる (vs. Linux のかったるさ)
    • Cons: Chromebook のポートの少なさ, モニタを着脱した際のウィンドウレイアウト崩壊のかったるさ, 外部モニタにつないだ際のぎこちなさ
  • Chromebox+CloudLinux(+Chromebok) at Home, Linux Workstation (+Chromebook) at Office
    • Pros: 勝手知ったる親しみやすさ
    • Cons: Home/Office 環境の乖離. shell の履歴や手元の WIP commits (Android) を持ち越せない.
  • Chromebox+Remote Linux Workstation(+Chromebook) at Home, Linux Workstation (+Chromebook) at Office
    • Pros: Office/Home ともに比較的親しみ深い構成
    • Cons: セキュリティによる Remote/Local 同時利用制限が不便 (IDE Windows などは殺されてしまう)

金の力で会社用 Chromebox を購入すると

  • Chromebox1+CloudLinux(or Linux Workstation)(+Chromebook) at Home, Chromebox2+CloudLinux(or Linux Workstation)(+Chromebook) a Office

という構成になり最強なのだが, 自腹は遠慮願いたいなあ。それなりに速い Chromebox が欲しいけど、高いからね。$900 くらいする…

Linux Workstation を手放して Chromebox と交換するという手もあるらしいが

  • 手元で動く Linux がなくなってしまうのはデバイスのデバッグなどで若干不安
  • そもそもハードウェアサポート部門は Return-To-Office の対応に追われておりこの手の手続は停止中らしい

といった理由で今はできない。といった点を鑑みるに:

  • Chromebox+Remote Linux Workstation(+Chromebook) at Home, Linux Workstation (+Chromebook) at Office

が無難なのだろうな。会社でも手元を ChromeOS にするほうが Linux より色々と面倒が少ないんだけど、まあ贅沢は言うまいよ。 そもそも自宅の Chromebox だって COVID のドサクサで買ってもらったものだしなあ。

しかし ChromeOS と Linux を行ったり来たりするのはかったるいなー…

  • Chromebox+CloudLinux(+Chromebok) at Home, CluodLinux+Chromebook at Office

あるいは

  • Chromebox+Remote Linux Workstation(+Chromebok) at Home, Remote Linux Workstation+Chromebook at Office

にしつつ, 会社で Chromebook を使うときは laptop ではなく external keyboard を使うのはどうか。 それにあわせてキーボードとマウスを挿す USB hub を買い、会社においておく。Hub とケーブルは持ち歩かない。


ついでに、家には laptop を持ち帰らず会社においておく…と思ったが podcast とかこれがないと撮れないね。 そういう趣味的活動に使える Linux じゃない私物 laptop が必要だな・・・まあしばらくは持ち歩きます。はい。


そしてミーティングには laptop を持っていかない!これだ!いやだめだなさすがに・・・。 でもミーティングは自席から出るのはどうか。1:1 はさておき、 参加者が remote なミーティングは自分は会議室行くひつようないじゃん? 臨席の人々には迷惑だが、オフィス復帰後は極度の会議室不足が予測されるので 自席からのミーティング参加は cultural norm になるんじゃないかな・・・だめ? リモートの人と会議室から話すのマジ意味ないよね。 とにかく laptop の持ち運びは最小限にしたい所存。

あとはゴミのようなどうでもいい Chromebook を一台なんとかして入手する、という路線もありうるが・・・ しかるべき場所にいけば転がってるんだろうけど、思い当たる節はないのであった。


というわけで USB Hub を購入。

そのほか security key が mess だったのを整理し、 通勤随伴電話機の台数も限定し、よしよし。 というか電話機は家じゃなくて会社においておくほうが邪魔じゃなくていいな。 次回持っていこう。


などといいつつ段ボールを物色していたら XPS 13 が出てきた! こいつに Windows を入れれば 家の podcast 問題等は解決し laptop 持ち歩きの必要はなくなるんじゃないか? あとで Windows のライセンスでも買おうかな。 $200 もするけど laptop 買うよりは安い。

などとばたばたしつつ、次回出社は明後日木曜日です。はあ。

Too Obvious To Innovate

今の仕事はやることがいくらでもあり、むしろ自分のスループットが全然足りておらず、総体としてそれはいいことだと思っている。やることと言っても必ずしもバグ直すみたいのばかりでもなく(バグも無限にあるが)、たとえば Kotlin 移行とかね。そういう感じ。まあ Kotlin 移行はリストの4番目くらいなのでできる気はしないけど。(さすがに他の誰かが先にやると思う。)

仕事がたくさんあると感じられるのは、それがデスマでない限り良い兆候である。仕事、特定の製品とか、の課題と、ある程度の解決への道筋を、自分が理解できているシグナルだから。

これは必ずしも自明でない。たとえば自分が下っ端すぎたり上司が micromanage だったりすると、自分の問題意識とは無関係に仕事が降ってきて、それは「やること」というより「やらされること」がいっぱいある状態といえる。そういうのは、自分の勤務先ではあんましない気がする(あるが、だいたいみんな逃げ出してしまう)。

勤務先で伝統的によくあるのは、製品が成熟しすぎていてほんとに何もすることがないケース。細かいバグ直しくらいしかない、みたいな。今は知らないが、自分がいたころのブラウザとかは、割とそんな感じだった。すると人々は頑張ってやることを考える。純朴だった頃の自分はその過剰さがイノベーションの鍵だと思っていたし、今でも一定程度そうだと思うが、実際には要らない機能や複雑なデザインを生み出す悪影響もあったと思う。

まあ組織としての良し悪しはさておき、自分にはそういう成熟・資源過剰状態は向いてなかったね。イノベーティブなプロジェクトを生み出せる力がなかったから。下手にイノベろうとして負債を生み出したり、人のイノベに乗っかろうとして痛い目を見たりした。

今の仕事は特にがんばってイノベる必要がなく、それどうみてもダメですよね直さないと、みたいのが色々ある、のみならず次々出てくる。これは(しばらくするとボスも気づいてなんとかしろと言ってきたりするので)ウンザリな面もあるが、無理してイノベらず明らかな課題を解くだけで成果になるのは良い。優先度だけ気を付ければ良い。

明らかにやるべきこと、すなわち明らかなダメさが沢山ある製品大丈夫なの、という不安はある。ただすくなくとも product-market fit みたいのは心配しなくていいわけで(そりゃスマホのカメラいるでしょ、みたいな)、あとは競合をなんとかすればよい。

競合は心配だしそんなに楽観もしていないけれど少しは希望が持てるのは、結局はリサーチ部門の神成果のおかげなのだろうな。彼らが無茶で過剰なイノベをして、それをなんとかエンドユーザの手に届けるのを手伝うのがアプリチーム。そういう役割分担。自分が誰かのイノベに乗っかっていることに変わりはない。ただそれが自分個人の小細工でなく組織のデザインである点が異なる。

あとはイノベの質だな。実際だめなイノベも沢山やってきて、そういう連中の相手はウンザリ。が、今のところはなんとかイノベ黒字に見える。エラそうだな自分。

自らイノベを生み出す厳しさに向き合わなくていいのか?向き合えたほうがいいんだろうけど、成熟製品の中で歪んだイノベに関わるのは嫌だし、すると会社を辞めた方が良いのではという話になり、それは諦めている。

この諦めを受け入れるなら、今の「他人のイノベの組織的なお手伝い」という立場はそんなに悪くないのだろう。そして将来チームを選ぶ際はイノベが黒字っぽいチーム、製品が良いといえる。これは「上手く行ってる製品」とほぼ同義な気もするが…。

同じ諦めの眼差しで、成熟製品部門にいた昔の自分のぱっとしなさを振り返る。あれは自分でイノベろうとしてうまく行かなかった挑戦と失敗の帰結であって、責めるようなものじゃ無いかもしれない。事後的に見れば無茶だったとわかるが、当時はそういうのもアリという空気があったのよ、てね。