No Purpose

If I must say, it's for me.

2025年

あけましておめでとうございます！(2025年の分)

2025年簡単にまとめておく。

千葉県に引っ越した(3月)

次男が保育園入園(4月)

妻が育休から復職(5月)

この頃、次男がなかなか保育園で一日過ごせず、ちょうど転職活動もしていて大変だった。

市内で再度引っ越し(6月)

この転居によって真の新居へ。 3月の引っ越しは「保育園に入園するために、この自治体で4月を迎えるため」というものだったのだ...。

退職(8月)

新型コロナウィルス初感染(8月)

万博へ(9月)

Ubie入社(10月)

Oasisのライブに行った(10月)

家族揃ってインフルエンザ感染(11月)

静岡大井川鐵道へ(12月)

まとめ

2026年も楽しく過ごそう！良いお年を！

2024年自分キュレーション

1月

highwide.hatenablog.com

sizu.me

2月

offers.connpass.com

speakerdeck.com

sizu.me

3月

highwide.hatenablog.com

sizu.me

4月

www.instagram.com

5月

www.instagram.com

6月

7月

8月

gihyo.jp

blog.studysapuri.jp

www.instagram.com

9月

10月

www.instagram.com

11月

www.instagram.com

12月

blog.studysapuri.jp

Web開発者たる自分が「プロダクトマネージャーのしごと」を読んでみて

www.oreilly.co.jp

読み終えた瞬間の熱い気持ちのまま感想文書こうって思ってたのになかなか書けないままだいぶ時間がかかってしまった😇

この本を手に取ったモチベーション

僕はプロダクトマネージャーではないが、良きプロダクトマネージャーの仕事については興味を持っていた。 以下のような理由による。

PdM不在のプロダクトプラットフォーム開発の立場から

業務ではプロダクトプラットフォームチームに在籍している。"Platform as Product"*1の考え方で業務に臨む一方で、PdMという専門職がチームに置かれているわけではないので、開発チームがプロダクトマネジメントを主に行っている。どのようなプロダクトプラットフォームを目指すべきかという検討にあたって、もう少しプロダクトマネジメント的な方法論を学んだ方がいいだろうか、ということを考えていた。

(各社が、プロダクトプラットフォームにおけるプロダクトマネジメントをどうやってるかは興味がある)

うちの会社では「TPM」と呼ぶけど、何が違うの？

プロダクトプラットフォームチーム所属以前は、プロダクト機能開発に携わっていたが、そこでプロダクトをマネジメントするロールは、会社における役職名として「TPM」(Technical Product Manager)と呼ばれていた。そういえば、「PdM」という言葉を日本でよく聞くようになるまで、前職ではそれらのロールは「ディレクター」と呼ばれていたことも思い出した。 こういったロールの呼ばれ方の違いは、プロダクトマネジメントという広範な業務においてどのような違いを持つのか、もう少し理解したかった。

自分って、プロダクトマネジメント方面にも意識を向けられる開発者なのかも？

プロダクトの方向性に関心を持ち、他者を巻き込み積極的に要件/仕様を詰めていく...という自身の動き方を評価してもらえることが、これまでの業務で少なくない。そういった自分の動き方を「プロダクトマネジメントもカバーする」と表現して良いのならば、自分は比較的プロダクトマネジメントも得意なソフトウェアエンジニアなのかもしれない。(とか言ってて、それは言いすぎだろという気持ちが強くある)

余談ではあるけれど、そんなロールを指して「プロダクトエンジニア」と呼ぶのかもしれないと思いつつ、あんまりこの呼ばれ方は好きではないかも。「技術」と「プロダクト」を二項対立とみなして、トレードオフスライダーを「プロダクト」に寄せている人...という印象を与えることを恐れているのかもしれない。(ただし、そういった先入観で「プロダクトエンジニア」の呼ばれ方を忌避するのは、「プロダクトエンジニア」ロールへの風評被害かもしれない)

この本のエッセンス...あるいは"原液"

読み終えてまず思い浮かべたのは、「カルピスは薄めた方がうまい」という最近聞いた言い回し。僕はこちらのツイートで知った。

では、この本の「原液」は、というと

  • あらゆることよりもプロダクトのアウトカムにフォーカスしろ
  • そのためにプロダクトマネージャーは何でもする必要がある

...と、僕は読み取った。

そう書けば、「何を当たり前のことを」と思うかもしれない。だからこそ「薄める」必要がある。

この本は読みやすい軽妙な筆致で、手を変え品を変え「◯◯よりもアウトカムを優先しろ」というメッセージを繰り返す。 そして「◯◯よりもアウトカムを優先するからには、あなたの仕事はこうなるはずだ。逆に、こういうことはしてはいけない」といった具体例が多数添えられる。チャプターごとの切り口は違うので個別のテクニックについてのそれぞれの学びは得つつ「あ、結局言いたいのは、また"アウトカム"だな」と次第に"原液"の味を感じるようになってくる。牛乳で割ってもカルピスはうまいよね。

さて、この本で「アウトカムを優先すべき」とする比較対象は多岐にわたる。

「アウトプット」「社内政治」「アイデアにこめた意図」「ベストプラクティス」「アジャイル開発」「ドキュメント」「ロードマップ」「ビジョン/ミッション/達成目標」「データ」「チーム」...etc

こうやって並べてみると「アウトカムを大切にしたいからこそ、それを大切にしているんだ」や「そりゃアウトカムの方が大事にしたいけれど...現実的には難しい」と思うようなものもある。そんな現実の声をこの本も決して無視しない。むしろ、アウトカムという目的よりもそれらの手段を優先してはいないだろうかというバイアスに気づかせたり、いかにして現実的にアウトカムを優先するのかというHow toを具体的に書いたり...というのがこの本の多くを占める。

と、ここまで書いた内容でわかるかもしれないが、実はこの本は、読む以前の「モチベーション」に直接応える本ではなかった。(それには早い段階で気づいた)

自分は「プロダクトマネージャーのしごと」と銘打たれた書籍に対するイメージとして、開発フェーズごとにすべき業務や、それを支えるスキルやベストプラクティスを網羅するような本と実は思っていた。一方で、この本は以下のようなテキストから始まる。

本書は素晴らしいプロダクトを作るためのステップバイステップの手引きではないですし、ましてやプロダクトマネジメントの成功を保証するフレームワークや技術的な概念のリストでもありません。本書は、どんなツールやフレームワーク、「ベストプラクティス」でも対処できない課題をあなたが乗り越えられるようにするのを目的としています。曖昧さや矛盾、しぶしぶする妥協といった、日常的なプロダクトマネジメントの実践についての本です。端的に言えば、私のプロダクトマネージャーとしての初日に必要だった本であり、そのあとも何度も何度も必要としてきた本です。

― Matt LeMay. プロダクトマネージャーのしごと第2版 (p. 21). Kindle Edition.

言ってみれば、プロダクトマネージャーとしてのロールを担うにあたってのハードスキルの紹介を期待していたと言える。ところがこの本が2章の「プロダクトマネジメントのCOREスキル」で言うことはこれだ。

一般的にソフトスキルは、ふわふわしていて、内向きで、定量化や計測の難しい対人関係スキルとされています。一方で「ハードスキル」は、固定的で、目的がはっきりしていて計測可能と考えられがちです。たとえば、コミュニケーションや時間管理のスキルはソフトスキルとみなされますが、プログラミングや統計的分析はハードスキルとみなされます。

(中略)

プロダクトマネジメントに話を戻すと、ソフトスキルとハードスキルを区別することは特に有害になる場合があります。手短に言うと、あまりにも多くの人や組織が、ハードスキルにもとづいてプロダクトマネージャーを採用しています。しかしそれは、プロダクトマネージャーに期待される日々の仕事とはほとんど関係ありません。

― Matt LeMay. プロダクトマネージャーのしごと第2版 (p. 68). Kindle Edition.

「プログラミングはハードスキル」としたうえで、「ハードスキルはプロダクトマネージャーのしごととほとんど関係ない」と断じられる。 プログラマーとしての自分は、プログラミングを軽視するようなプロダクトマネージャーが推奨されているのだとしたらどうしよう...なんて身構えるが、決してそういうことではない。

重要なのは、技術面でエキスパートであることではなく、技術的ではないことと同じように、技術のことについて探索したり学んだりするのに抵抗がないことです。

(中略)

優れたプロダクトマネージャーは、技術面以外の話題と同じように技術面にも興味を持ちます。

― Matt LeMay. プロダクトマネージャーのしごと第2版 (p. 71). Kindle Edition.

...と続き、「あぁたしかにそういう人、一緒に仕事してると楽しいんだよなぁ」なんて思ったりする。

「PdMは技術的な方法論にあまり口出ししないでほしい」と「PdMも技術を軽視しないでほしい」の両方ともプログラマーが抱きがちな感情なのではないかと思うのだけれど、こういった「好奇心」というのが、そのバランスをとるキーワードなのかもしれないとも思った。

この本では「アウトカムにフォーカス」が繰り返されると書いたが、決して、原理主義的にアウトカムのみを追い求めるプロダクトマネージャーが推奨されているわけではないことも伝わるだろうか。むしろアウトカムにこだわりたいからこそ、開発者ともうまくやるための泥臭いソフトスキルも重要視しているように思える。

印象的だった箇所

「1章 プロダクトマネジメントの実践」

プロダクトマネージャーの役割の候補者を社内で見つけたいと考えている組織から相談を受けたとき、私はよく、会社のなかでの情報伝達の経路を図にしてもらいます。これは公式の組織図ではなく、人が互いにどのようにコミュニケーションしているかを示す非公式な概略です。すると、必ずいつも中心にいる人が出てきます。情報のブローカーであり、人やものをつなげる人であり、積極的に新しい視点を求めている拡大思考の人です。

― Matt LeMay. プロダクトマネージャーのしごと第2版 (p. 38). Kindle Edition.

ハードスキルありきで、PdMというロールの適性を考えてしまいそうな自分にとって目からウロコだった。「あーそういう人いるわー」と思ったし、思い浮かべたその人は現時点でPdMでなくとも「その人がPdMやってたら確かにしっくりくるかもな」なんて妄想もした。

プロダクトマネジメントのワークショップで教えていると、ほぼ毎回最初に聞かれる質問はだいたい同じです。それは、プロダクトマネージャーと、プログラムマネージャー、プロダクトオーナー、ソリューションマネージャー、プロジェクトマネージャーの違いは何なのか、というものです。

― Matt LeMay. プロダクトマネージャーのしごと第2版 (p. 46). Kindle Edition.

ずっと増え続ける「プロなんとか」という肩書きのリストのことを「曖昧に書かれたプロダクト関連の役割（Ambiguously Descriptive Product Roles、ADPR）」だと考えることにしました。これは、日々の活動や責任についてあまり多くを語らない無数の肩書きを包含するバナーコンセプトになります。

(中略)

ADPRとして、自分の仕事は具体的に何をするのかを絶対的に明確化することはできません。たくさんの質問を投げかけ、チームと密接に仕事し、いちばんインパクトがあることにできるだけ集中しましょう。

― Matt LeMay. プロダクトマネージャーのしごと第2版 (pp. 47-48). Kindle Edition.

僕が「うちの会社は"TPM"と呼んでるけど、こういう呼び分けにはどういう意図があるのかな」なんて考えていたことに対する究極のアンサーだった😂 プロダクトマネージャーがアウトカムのために何でもしなきゃいけない人ならば、結局同じ呼び方をしていても、そのときのビジネスやチームやプロジェクトの状況に応じてやることは変わるので、些細な呼び方は気にしなくていいやと思えるようになった。

「4章 過剰コミュニケーションの技術」

ステークホルダー、特に幹部のステークホルダーは、極めて多忙です。ミーティングでうなずいても、「わかった、ありがとう」のメールも、認知されていたとはしても、あなたの懸念点に必ずしも注意が向いていることを意味しません。プロダクトマネジメントの世界では、はっきりとした承認、明示的な賛意でないものは、驚くほど危険です。その曖昧な注意を払っていない非明示的な賛意の例としていちばんに上がるのが「よさそう」という反応です。 優秀なプロダクトマネージャーは、いろんな手を使って、人が「よさそう」とは答えられないようにしています。たとえぎごちなくても、イライラさせる可能性さえあっても、必ず自由回答式の質問をします。

― Matt LeMay. プロダクトマネージャーのしごと第2版 (p. 108). Kindle Edition.

「納得は全てに優先するぜ」じゃないが、僕はなるべくステークホルダーが納得していることを確認したいし、「コンセンサスが得られた」ということを明示的に確認して仕事を進めたいタチだと思う。だからこそ、その納得を確認する行為が、消極的な「よさそう」を引き出すことで単に「言質をとった」だけになっていないかったと考えさせられた。

また、それを回避するために「Disagree & Commit」というテクニックが紹介される。これはステークホルダーひとりひとりに「Disagreeでなければ、"Commitする"とはっきりと表明してもらう。それができないなら、遠慮なくDisagreeする」というIntel発祥のもので、おもしろい取り組みだと思った。 「Commitする」を全員に表明してもらうのは、結局新たな同調圧力になってしまわないかという不安もよぎるが、その検証も含めて何かのときに試してみたい。

「7章「ベストプラクティス」のワーストなところ」

プロダクトマネジメントを再現可能なベストプラクティスの適用にすぎないとみくびってしまえば、厄介で予測不能で絶対に回避できない人間の複雑さを洗い流してしまうことになります。その複雑さのなかを進んでいくのがプロダクトマネジメントの本来の仕事であるのにです。

― Matt LeMay. プロダクトマネージャーのしごと第2版 (p. 189). Kindle Edition.

時折、仕事などで「人間という複雑系をずいぶんとシンプルなモデルで捉えたルール/進め方/オペレーション...じゃないかな」と思わされるようなやり方に出くわすことがある。これらの人間の複雑さを洗い流すことがときに効果的であることは否定しないが、そういったプラクティスの強制はサステナブルではないよなと薄々思っていた。 そんな自分の気持ちにピッタリと合うような章だった。

最近、ほとんどのプロダクトマネジメントフレームワークやモデルは、有用なフィクションと考えるとよいことに気がつきました。「有用な」も「フィクション」も同じくらい重要です。

― Matt LeMay. プロダクトマネージャーのしごと第2版 (p. 197). Kindle Edition.

「ベストプラクティス」に加えて、プロダクトネジメントの「フレームワーク」についても「フィクション」と断じる。一方で、そのうえで「有用」と判断するのがこの本のいいところなんだよなと思う。

自分たちソフトウェア開発者が普段意識するようなプログラミング技術のベストプラクティスやフレームワークは、"ハード"スキルと言うだけあってもう少し手触りがあるものだとは思うが、たとえば組織論やマネジメント論などのソフトスキル寄りの発表資料などを読んでいて「めちゃいい話だけど、うちの現場においても再現性あるかなぁ」なんて思うことはときどきある。こういったものも「有用なフィクション」と考えて接するのがちょうどいいのかもしれない。

「9章 ドキュメントは無限に時間を浪費する（そう、ロードマップもドキュメント）」

プロダクトマネージャーとして働いていたときに受けた最高のアドバイスの1つが、ロードマップはいつ何を実行するかの厳密な計画ではなく、戦略的なコミュニケーション用のドキュメントととらえることでした。

― Matt LeMay. プロダクトマネージャーのしごと第2版 (p. 244). Kindle Edition.

プロダクトの仕様書はプロダクトではない

― Matt LeMay. プロダクトマネージャーのしごと第2版 (p. 249). Kindle Edition.

最高のドキュメントは不完全

― Matt LeMay. プロダクトマネージャーのしごと第2版 (p. 252). Kindle Edition.

「いかなるドキュメントや成果物でも、チームに共有する前に1ページ、1時間以上は使いません」

― Matt LeMay. プロダクトマネージャーのしごと第2版 (pp. 254-255). Kindle Edition.

ドキュメントについて書かれた9章は、自分好みのパンチラインが頻出する章だった。 ロードマップもガントチャートも、プロダクトマネージャーが書くことになりがちなドキュメントだけれども、そこに書かれた計画そのものに価値はなく、あくまでもコミュニケーションのためのドキュメントであることに価値があると強調する。そして、コミュニケーションのためのドキュメントという意味において、最高のものは不完全のものであると指摘し(僕たちが作る「たたき台」なんてまさにそれだよなと納得した)、だからこそ「チームに共有する前に1ページ、1時間以上は使わない」という具体的なテクニックにつながっていく。

このブログ書き上げるのにめちゃ時間かけてる自分が言うのも説得力ないのだけれど、本当にこれ大事だよな〜〜〜と、いつも自戒をこめて思っている。

「10章 ビジョン、ミッション、達成目標、戦略を始めとしたイケてる言葉たち」

アウトプットに著しく集中しているように見えるチームは、多くの場合、壮大で具体性の乏しいアウトカムを目指して仕事をしていたのです。チームやリーダーたちと何度もレトロスペクティブを繰り返すうちに、これが確実性と予見性を求めてしまう人間的な反応の結果なのだと理解できるようになりました。開発内容や期日は何らかの方法で決めなければいけません。アウトカムに具体性がなければ、アウトプットに具体性が求められるようになります。アウトプットに裁量を持ち柔軟に決めたいのであれば、チームはアウトカムを具体的に決めなければいけません。これをアウトカムとアウトプットがシーソーに乗っていると見立てることもできます。片方を具体的な開発内容と期日で押し下げれば、もう片方はテーマや機会のように変更可能なもので押し上げられることになります。

― Matt LeMay. プロダクトマネージャーのしごと第2版 (pp. 266-267). Kindle Edition.

いまの自分たちの開発における「アウトプット」と「アウトカム」に求められてる具体性のバランスを考えてみる機会となる箇所だった。たとえば「窮屈な開発」が強いられてると感じるとき、言い換えればそれは「アウトプットに高い具体性が求められる状態」なのかもしれない。そして、それによってアウトカムに具体性を持たせることを回避しているのかもしれない。もしも窮屈な開発を回避したいと思うならば「具体的なアウトカム」をコミットすることを手段として考えてみてもいいのかもしれないと思った。

また、この記事は結果的に「アウトカム」を連呼するものになってしまったけれども、そもそもの「アウトカム」という言葉の定義について疑問に思われているかもしれない。 それはビジネス上の価値を指すのか、ユーザーにとっての価値を指すのか...によって、日々の業務は違ってくるという感覚が当然僕にもある。

結局、これを決めていくのもプロダクトマネジメントの一環なんだということが、特にこの章で示唆されているように思えた。だからこそ、アウトカムを具体的に定義する必要があるし、「ゴール」や「達成目標」というものも、アウトカムをとらえるための方法なんだということがこの章では触れられている。

最後に

上で引用した箇所以外にも、「アジャイル開発」に対しての8章、「データビジネス」に対しての11章、「リモートワーク」に対しての13章なんかは、わかりやすくWeb開発者の僕たちも思うところがある章かもしれない。 その他諸々、epubはハイライトだけなんだけれども、きりがないのでこのあたりで...！

総じて言えば、「いやー、読みたかった本じゃなかったけど、読みたい本だった〜！」という感想でした。

「結局、プロダクトのアウトカムこそ大事だよね」みたいなの、ともすれば青臭いきれいごとで終わってしまうけれど、そうならないような具体的な泥臭さであふれているのも好みだった。一方で、そんなきれいごとで自分の仕事を見つめ直したくなるような、初心に返らせる強さもある本だと思う。

一緒に仕事をしていたり、同じコンテキストを共有していたりする人にこの本読んでもらったうえで飲みにいったら酒が進みそう。

プログラマとしての職責に軸足を置くことを変えるつもりはないが、プロダクトマネジメントのためのハードスキルこそ持ち合わせていなくとも、アウトカムの追求のためにできることなんでもやるぞ...なんて青臭い気持ちを書いて、この感想文を終えたい。

*1:参考: 社内PlatformチームのProduct Management | Taichi Nakashima

次男が生まれてからの過ごし方あれこれ

2023年9月末に次男が生まれ、10月から育休を取ってもうじき4ヶ月になる。早い。

長男が生まれたときは、転職直後かつコロナ禍になる前で、それほど休みを取らずに出勤を続けていて、産後1ヶ月は妻は実家で寝泊まりをしていた。 (いま考えると、悪いことしたな…と思う。ようやく、そういうことに気づけるようになった)

一方、今回に関しては、そもそも「次男の面倒を見つつ、長男も見なくてはいけない」という状況に家庭が置かれるので、会社に後押ししてもらったこともありしばらく育休を取ることにした。

特に産後1ヶ月(産褥期と言う。すごい字面だ)は、体がボロボロになっている妻に休んでもらうべく、家事育児をなるべく引き受けた…つもり…だったのだけど、当然自分は授乳できないし、心身の負担を引き受けきった！と胸を張っては言えないかもしれない…とも振り返っている。

次男は、当時の長男や世の多くの乳児たちと同じく、「抱っこしてるときは泣き止んでいても、横たわらせるとその瞬間から泣き始める」という傾向が強く、深夜に抱っこ対応した自分と、3時間ごとの授乳で疲労困憊になった妻で、日中は「お互い隙を見て寝る」を繰り返しているうちに1日が終わる…ということもままあった。 当時は抱っこしたままできる娯楽として、タイムゾーンの違う同僚と深夜にhuddleを繋いだり、MTG Arenaをタブレットでやったり、ということをしていた。

mtg-jp.com

ちなみにこのブログも途中までは子供を抱っこしたままスマホで書いた。

1ヶ月ほどして、少しずつ妻の体力が戻ってきて家事育児を分担できるようになり、少し生まれた可処分時間を(妻に応援してもらいながら)Web開発のお手伝いをする副業にあて始めた。

ohbaryeさんとの縁でSmartBankさんに声をかけてもらい、RailsやGoやReactに関する社員の方の手が届きにくいところなどを改善する業務をやっている。 また、この記事でも言及いただいたが、ADRについての知識共有なども行った。

blog.smartbank.co.jp

当然、育休中にフルタイムで働くほどの余裕はないのだけれど、「週に何日か1日数時間程度」であれば、ある程度時間が確保できるようになった中、こうやって社会と繋がる機会が得られたのは精神の安寧に繋がっていると強く感じる。

知っていることと知らないことの程よいバランスの中で知識をアップデートしたり成果を出したりするのは達成感に繋がるし、ロールを問わずカジュアルであたたかいコミュニケーションを取ってくれる雰囲気も心地良い。

ちょうどこの仕事を始めたばかりの頃に、ファウンダーのyutaさんのスライドが話題になっていて、

speakerdeck.com

特にCTOは本当にやるべきことにフォーカスするべきという趣旨での以下のページが特に心に残っていた。

一方で、ある日、興味があったMTGに都合が合わず参加できなかったことを残念がるコメントを個人channel(times的なの)に書き込んだところ、ファウンダーのyutaさんが「お時間あうときにぜひ」とコメントしてくれた。

CTOは、「PCの購入をするべきでなかった」と振り返りつつも「業務委託の自分のtimesをわざわざ見て、声をかけてくれるんだな」なんてところに会社の雰囲気を垣間見たような気がしたのだった。

また、"MTG"の話が続くが、平日日中に行われた忘年会に参加させてもらい、二次会ではPdMやデザイナーの方らと、Magic the Gathering部の活動に混ぜてもらった。 ここに来て、子供を抱っこしながらMTG Arenaでルールを覚えたのがコミュニケーションツールになるとは…！ 青黒フェアリー(?)の統率者デッキを貸していただき、"紙でやるMTG"の実績を解除したのだった。

そんなわけで、SmartBankさんのお手伝いは、皆さんに助けられてとても楽しくやれているのだった。だからこそ、もっと成果を出したい...！

と、そのように自分の可処分時間を積極的に副業にあてた結果、もともと育休中にやりたかったことがなかなかできないぞ...と気がついてしまった(当たり前だ)。 そこでまずは、ちょっとずつ進めていた「ゼルダの伝説 ティアーズオブザキングダム」を泣く泣く祠や地下の探索はあきらめて、全クリした...。

というわけで、ゲームはいったんお休みしようと、ゼルダに加えて、MTG ArenaやらFGOやらシャニマス/シャニソンやらも後ろ髪を引かれつつ封印している。 ただ、同僚がある日「GGSTにエルフェルト実装されたよ！！」と連絡くれて、年末にわちゃわちゃと格ゲーをやる夜があったのは、とても楽しかった。

そんな可処分時間の選択と集中を経て、最近はなるべくやりたかった学習に時間をあてようとしている。特に子供を寝かしつけしたあとの時間を使っている。

ひとまず、RustでWebアプリを書く本をひととおりやったり、

Webアプリ開発で学ぶ Rust言語入門

Webアプリ開発で学ぶ Rust言語入門

Amazon

App RouterになってからのNext.jsチュートリアルをやったり。

nextjs.org

ただでさえ時間ない中で自身の集中力のなさに悲観することもあるけれど、焦ってもしょうがないのでマイペースにやっていくことにしている。

そんな集中力のなさをカバーすべく、デスク周りに最近投資してるのだけれど、その話は長くなりそうなので別に書くことにする。(たぶん)

最後に子供の話に戻るが、この休暇の本分たる育児も、ときどき疲弊しつつも楽しんでいる。子供...かわいい...。

次男は0歳の頃の長男に似ていて、最近は、あやすと笑うようになってくれた。 泣いているときは、今でも反町隆史に助けられている。

www.oricon.co.jp

4歳の長男は電車好きに拍車がかかっていて、リビングに貼ったこの路線図を毎日食い入るように眺め、

「都市部路線図１ デカ文字」 東京（関東、首都圏）【ポスターケース発送】【ふりがな付き鉄道路線図】 5歳～年配の方、ビジネスにも 書いて消せる路線図 全路線全駅掲載 A1サイズポスター

「都市部路線図１ デカ文字」 東京（関東、首都圏）【ポスターケース発送】【ふりがな付き鉄道路線図】 5歳～年配の方、ビジネスにも 書いて消せる路線図 全路線全駅掲載 A1サイズポスター

  • 岩崎デザイン企画
Amazon

休みのたびに「この路線に乗りたい！」「この駅に行きたい！」とアクティブに僕たちを外に連れ出してくれる。

そんなわけで、息災にやっております、のたよりでした。

葛西臨海公園 - 1月の海は寒かった

2023年も残すはあと少し

「みてね」の「2023年1秒動画」は1/1に生成されるから今年の写真はさっさと現像してアップしないと！！と思い立ってなんとか終わらせてこんな時間。(22:37)

誰が見ているというわけでもないこのインターネット僻地に、さくっと自己満足を兼ねた備忘録だけでも書いて今年の雑な振り返りとしたいと思う。

仕事

チーム異動した。 GraphQL schema stichingによるマイクロサービスを扱うプロダクト開発チームから、プロダクトプラットフォームのチームへ。 技術要素的には、React/GraphQL/TypeScriptを扱うことが減って、Goを扱うことが増えた。

デブサミの登壇の機会があり、好評いただいたのがうれしかった。

blog.studysapuri.jp

家庭

第二子となる次男が9月末に生まれた。 生まれるまでは、"切迫早産直前につき自宅安静"との診断が妻にくだり、6月頃から家事や育児をできる限り自分で引き取るという動き方をしてきた。

朝5時に起きて少しリモートワークして、それから子供を保育園に送る準備をして、保育園に送った後またリモートワークして、保育園にお迎えいった後はデリバリーフードサービスなどに頼りつつ、ご飯食べてお風呂入って子供寝かしつけて自分も寝て...みたいな生活だった。

自分的にはなかなかに壮絶な日々だったが、その甲斐もあってか、第二子は元気に生まれてきてくれた。長男との絆も深まったように思うし、自分がこれまで妻に如何に助けてもらってたかを思い知らされた期間だった。

第二子が生まれてからは育休を取っている。(ありがたい)

2024年の3月頃まで取る予定。 育休中は新たなことをやる機会にも恵まれている。また今度どこかで書くかも。

その他

  • 子供の誕生に加えて、近親者の結婚や葬儀や大きな怪我などがあって、いろんなことがある年だった。
  • マンションの契約をした。家探しも大変だったことを今更思い出した。まだ建てているので住むのはまだまだ先。
  • Macbook Proを買い替えた。IntelのチップからM3へ。いえーい。
  • 子供が生まれた頃にMtG Arenaをやり始めた。...のだが、おもしろすぎて時間が溶けるので逆に今は少し距離を置いている。
  • すごく好きだったはずのマンガ読むことが、少しずつできなくなっていることに気がつく。惰性で続巻を買うがちゃんと読めてない、みたいなシリーズがある。
  • 育休中の可処分時間の使い方を最近見直して、意識的に学習に時間を充てようとしている。
    • なんか実を結んだり何かに繋がってほしい気もするが、そういう期待をするのもなんか違う気もする
    • とりあえず、Rustの写経をしたり、Next.jsのキャッチアップをしたりするのは楽しい
  • 写真、相変わらず子供の写真ばかりだ。α7iii + SIGMA 35mm f2.0の組み合わせか、GR IIIxをずっと使っている。
  • 長男の鉄道好きに合わせて、いままで行かなかったところに行く機会になっているのは楽しい
    西武鉄道 玉川上水車両基地 クリスマスイベント

良いお年を

2022年近況

大晦日〜〜〜〜！！！！

というわけで2022年振り返ってみる。

痩せた

2022年の一番変化なので、はじめに書いてみた。年始から12kgくらい落ちている。

なるべく筋肉を落とさないように体脂肪を落としたいというつもりで、食事と運動を頑張った。

食事は、PFCバランスを気をつけて、あすけんで毎食記録を行っている。

運動は、ジムに週2〜3行って胸・背中・脚の筋トレを行いつつ、週1〜2テニスやランニングで有酸素運動を行った。

来年はもう少し体脂肪率を落としてから、今度は筋肉量を増やしたいなぁとうっすら考えている。

2022/01/31 梅が咲いてた

2022/02/10 雪が降った

2022/03/28 桜と西武2000系

仕事

去年から携わっていたこのプロジェクトがリリースされた。

prtimes.jp

僕はRailsとApollo ServerをGraphQL schema stichingで繋いだバックエンドをメインに携わりつつ、強いフロントエンドメンバーのサポートを受けながらReactを書いたりしていた。

4月にプロジェクト内でのチーム再編成があって、自律的に動ける職能横断チームでアレコレやる楽しさを感じている。

この記事で触れている発表は、職場での働き方の雰囲気が垣間見えるものになっている。

highwide.hatenablog.com

Google Cloud PubSubを利用した新旧プラットフォームでのデータ同期や、GraphQLのFragment Collocationなど、扱った技術の定着を感じられた。

なお、副業として携わっていたAutifyは4月末をもって辞めてしまった。子育てしながら無理なく携われる副業ないかなぁって感じである...。

2022/04/16 秩父に旅行

2022/05/20 家族でディズニーランド

2022/06/25 同僚とテニス

子育て

子供は今月で3歳になった。かわいい。

今年はどんどん言葉や知識が増えていき、意思疎通がどんどん取れるようになったのが楽しかった。

電車好きの子供に合わせて自分も知識をつけていった結果、首都圏の車両の形式(っていう言い方でいいのか？「E235系」とか)がだいぶわかるようになった。

プラレールもめちゃ楽しい。

子供は漢字やアルファベットもおろか、ひらがなもろくに読めないけど首都圏各線のロゴマーク(青丸に「Z」で半蔵門線、とか)はすべてわかっている。すごい。

2022/07/10 家族で西武園

2022/08/22 山形に旅行

2022/09/25 高麗川 曼珠沙華

コンテンツ

音楽は、haruka nakamuraとずっと真夜中でいいのにばかり聴いていた。あとはシャニマスサブスク解禁ありがたい。

Podcastは、去年から聴いてるコテンラジオに加えて、ゆる言語学ラジオも聞き始めた。楽しい。

マンガは、ルリドラゴンが良かったなぁ。

ゲームは、去年に引き続きギルティギアストライブをよくやっていた。あと、FGOのメインストーリーが2年ぶりくらいに追いついた。

あと、時間の無駄ってわかってるんだけど、ついついTikTokを見てしまう悪癖がついた...。

2022/10/01 スカイツリー

2022/11/07 富山旅行

2022/12/07 有給とって寿司食べた

来年も元気に楽しく過ごしたいですね！

6年半前の「停止性問題」についてのLT資料をアップロードした

前職の同僚の @kiyotoyamaura に誘ってもらって、彼や彼の運営するコミュニティの方と「コンピューターシステムの理論と実装」の読書会を毎週行っている。

www.oreilly.co.jp

3月下旬から始まって、かれこれ半年ほどかけながら今は5章を読んでいる。ペースはゆっくりながらも、きちんと手を動かす時間を取りながら理解することを大事にしているので、自分にとってもとてもありがたい機会となっている。(特に自分はコンピューターサイエンスのバックボーンを持っていないので...)

5章では、抽象化されたコンピューター理論としての万能チューリングマシンと、実用的なアーキテクチャであるノイマン型コンピューターの紹介があり、NANDから始まってひたすら具象的な実装を積み上げる本書が後者に寄っているのに対して、前者の概念を理解するにあたっては同じくO'Reillyの「アンダースタンディングコンピューテーション」に助けられた...といった話を読書会でしていた。

www.oreilly.co.jp

と、アンダースタンディングコンピューテーションの目次を眺めていたら「停止性問題」の単語が目に留まって、最近自分のタイムラインに「無限ループを検出したいという相談を受けた」というツイート*1が流れてきておもしろかったと紹介した。

そのうえで、この「停止性問題」については前職の社内LTで発表したことを思い出し、当時の自分の資料を読み返してみると"勉強になるなぁ"と思ってしまったのだった。(身についていなかった、とも言う...)

拙い資料ではあるし、今更ではあるけど、せっかくならuploadしておこうかなと思って、6年半の時を経てSpeaker Deckにuploadしてみた。

speakerdeck.com

前職の社内勉強会「0x64物語」は毎回テーマ縛りでLTを行うという形式のもので、このときのテーマは「数」だった。*2

読み返しても対角線論法のところ、ちゃんと説明できる気がしないぜ...。

*1:https://twitter.com/kur/status/1566574932074852352

*2:「0x64物語」については以前社外のイベントで発表も行った: https://speakerdeck.com/livesense/wen-hua-falserihuakutaringu