Lokka の検索はキーワード一つにしか対応していなかった。例えば うどん ラーメン と入力すると、確実に うどん ラーメン という語順で検索が行われる仕様になっている。これはちょっと不便だと思ったので半角スペースでキーワードを分割して AND 検索するようにした。つまり確かに うどん ラーメン という語順で文章が書かれていなくても、 ラーメン うどん という語順だったり、そもそも うどん と ラーメン が離れたところに書いてあるような文章でもオッケーな仕様にした。 diff はこんな感じ。
一般的な検索システムだと入力された検索キーワードを品詞分解したりして半角スペース入れたりせずともいい感じに検索できるのだろうが、データベースから直接検索するシステムではこれくらいできれば十分かなと思ってる。どうせこのブログで検索してるの自分一人くらいだし。
2018 年の 10 月に挑戦して失敗した糸島四座縦走にチャレンジして何とか達成することができた。前回は色気を出して浜崎（唐津市）側からスタートしたが、そのせいで最後の二丈岳に登る時間がなくなり三座縦走となってしまった。今回は反省して深江から二丈岳→女岳→浮嶽→十坊山の順に登り福吉へ下山した。
前回チャレンジしたときはアルプスから帰った後で少し調子に乗っていた。 3000m 級の山に登ったあとなら 700m 〜 800m の山なんて楽勝だろうと思っていた。しかし登山は標高が全てではない。むしろ北アルプスは登山道が整備されていて歩きやすかったりする。低山は道がはっきりしていないところもあるし（前回は蜘蛛の巣地獄に苦しんだ）、登山口と山頂の高低差よりも累積獲得標高が大事で、白馬岳に登ったときは累積獲得標高 1300m くらいだったが、糸島四座は 1700m くらいある。低山であっても縦走することでアルプス級かそれ以上の負荷になることがあるのだ。前回、糸島四座縦走に失敗したあと、宗像四ツ塚や雷山・井原山、祖母山、脊振山・金山、羽金山・雷山などで長めの距離を歩き経験を積んだつもりでいたが、相変わらず歩くのが遅く、福吉駅に着いた頃には日が暮れていた。日が長い夏でなければ危ない感じだった。
なぜ歩くのが遅いのか、太っているからか。コロナ禍で太ってしまったが、体重がいまより 5kg くらい少なかった頃でもやはり自分は歩くのが遅く、体重のせいではなさそうだ。自分より太っていても速い人は速い。 Apple Watch をつけ始めて自分の心肺能力が可視化されるようになったが、 Apple Watch によると自分の心肺能力は同年代の平均以下ということらしい。おそらく心肺機能が低いせいで持久力がなく歩くスピードが遅いのだろう。
遅いくせにカメラや使わないギアなどをリュックサックに入れすぎているのも響いていそうだ。写真を撮るのは好きなのでできればカメラは持っていきたいが、ミラーレスでもレンズ付きのカメラは 1kg くらいあって、リュックサックのストラップにくくりつけて歩くと 15km を過ぎたあたりで肩への食い込みがきつくなり痛みを感じるようになる。一度、カメラなしでどれくらいのスピードで歩けるか試してみたい。昨夏、カメラなしで家の近くの山を周回したが、その時も決して速くはなかったが、軽量な荷物では軽登山しかしたことがない。トレラン並とまではいかないまでも、水と行動食とスマートフォンだけの軽量装備でどれくらいのスピードで縦走できるのかには興味がある。
糸島四座縦走 / Hitoshi Nakashimaさんの女岳（福岡県）・二丈岳・十坊山の活動データ | YAMAP / ヤマップ
2 年前にソフトウェアエンジニアからプロダクトマネージャーにロールチェンジした。ソフトウェアエンジニア時代は割と頑張れてたし成果を出せてた気がするのだけど、プロダクトマネージャーになってからは正直かなり苦戦した。プロダクトマネージャー 3 年目を迎えてようやく仕事に自信が持てるようになってきた気がするので、振り返りを兼ねて、これから同じようにプロダクトマネージャーにコンバートしたいと思っている人の役に立てばと思って書きます。
ソフトウェアエンジニアだったとき、プロダクトマネージャーが不在のプロジェクトにアサインされたことがあった。機能コンセプトと画面デザインはあったが明確な仕様ドキュメントはなく、未確定の仕様をつまびらかにしつつ、関係者の合意を得ながらコードを書いていく必要があった。エンジニアだった頃の自分は機能的な仕様は誰か他の人に決めてもらって、自分は技術的な仕様を考えてコードを書くことに集中したかった。
このときは正直とてもつらくて、結局機能をリリースすることもできずプロジェクトはぽしゃってしまった。このような経験を自分はもうしたくないし、他の人にもさせてはいけないと思った。ビジネス的に成功するためだけでなく、エンジニアやデザイナーが不幸にならないためにも、きちんと作るものを定義してくれるプロダクトマネージャーが極めて重要だと思った。
その後しばらく時間が経ち、転職した職場でエンジニア・デザイナーが増えるにつれて専任のプロダクトマネージャーが存在しないことによる課題が露呈するようになった。プラットフォーム間での仕様の食い違いや、勘や憶測に基づく機能開発など。このままではプロダクトが間違った方向に進みかねないし、かつての自分のようにデザイナーやエンジニアが苦労をすることになると思った。誰か一人が専任のプロダクトマネージャーとなって交通整理をする必要があるだろうと考え手を挙げた。
プロダクトマネージャーの役割や定義については様々あるが、自分は「ユーザーに必要とされる製品を定義し、ビジネス的な成功を達成すること」だと考えている。プロダクトマネジメントについての本を何冊か本を読んだが、その中で最も感銘を受けた『 Making It Right 』という本にはこのように書いてある。
The product manager’s mission is to achieve business success by meeting user needs through the continuous planning and execution of digital product solutions.
— Merwe, Rian van der. Making It Right: Product Management For A Startup World (p.17). Smashing Magazine. Kindle 版.
この本を読んだ後に書いた記事ではこの部分を以下のように訳している。
ソフトウェアを継続的に企画・製造してユーザーのニーズを満たし、ビジネス上の成功を実現する
この記事の内容はいささか抽象的ではあったが、いま見てもそんなに違和感はない。記事内で引用した Dan Olsen の図から特に重要な部分を抜き出すと以下だろう。
上図の赤枠で囲われた部分、ユーザーのニーズとプロダクトをマッチングさせ、売れる製品を作ってユーザーの問題を解決すること（ Product/Market Fit ）がプロダクトマネージャーの役割だ。ユーザーの課題を解決する画期的な製品を作ることが出来たとしても、収益性が悪ければプロダクトマーケットフィットしたとは言えず（ Solution/Problem Fit に過ぎない）、プロダクトマネージャーの役割を果たしているとは言えない。
プロダクトマネージャーにふさわしい人物像として、プロダクトマネージャーは I 型人間であるべきと述べられている。再び同書から引用する。
First, they need to have their heads in the clouds. PMs need to be leaders who can look into the future and think strategically.
日本語訳: プロダクトマネージャーは雲の上に頭を置いておく必要がある。未来を見越すリーダーであり、戦略的な思考が求められる。
— Merwe, Rian van der. Making It Right: Product Management For A Startup World (pp.22-23). Smashing Magazine. Kindle 版.
But good PMs also have their feet on the ground. They pay attention to detail, and they know their products inside out. They are the product’s biggest users — and its biggest fans and critics.
日本語訳: しかし同時に、良いプロダクトマネージャーは地に足を付けていなければならない。良いプロダクトマネージャーは細かいところまで注意を払い、プロダクトの表と裏を知っている。良いプロダクトマネージャーはプロダクトの最大のユーザーである。最大のファンであり、批評家でもある。
— Merwe, Rian van der. Making It Right: Product Management For A Startup World (pp.23-24). Smashing Magazine. Kindle 版.
Most importantly, PMs know how to ship. They know how to execute and rally a team to get products and improvements out in the world where the target market can use them and provide feedback.
日本語訳: 最も大事なこととして、プロダクトマネージャーは製品のリリース方法を知っている。開発チームをとりまとめて開発プロジェクトを遂行し、製品を求めフィードバックを与えてくれる外の世界（＝対象とする市場）に届ける方法を知っている。
— Merwe, Rian van der. Making It Right: Product Management For A Startup World (p.24). Smashing Magazine. Kindle 版.
雲の上から俯瞰して戦略的にものごとを考えることも出来るし、地に足を付けていてプロダクトの細かいところも把握している。ユーザーの課題を発見するところから始まり、課題を解決する方法をとりまとめて世に送り出し、フィードバックを得るところまでできるのがプロダクトマネージャーにふさわしい人物像ということだろう。
具体的な仕事内容を挙げると以下のような感じではないだろうか。
本から得た知識をもとに、意を決してプロダクトマネージャーになってみたものの、想定と現実の間には大きなギャップがあり苦しんだ。具体的には、作るべき製品を定義するのがプロダクトマネージャーの仕事だと思っていたがそうではなかった。
エンジニアは作りたいものを作りたいし、プロダクトマネージャーが作るべきものを定義するまでもなく機能は開発されていく状態だった。開発すべきものがわからないのではなく、開発したい機能が多すぎて困っているという状態だった。
自分が思い描いていたのは以下のような役割分担だった。プロダクトマネージャーが必要な機能と要件・機能仕様をまとめ、デザイナーがデザインに落とし込み、エンジニアが機能を実装する。
しかし実際は以下のような感じで、機能のアイディアを出す企画段階からエンジニアが担当し、プロダクトマネージャーは他のプロジェクトチームや営業、マーケティングチームとの調整が主な役どころだった。製品の仕様に関われるのは既存機能の不具合対応のときくらいで、後は開発チームによって作られたソフトウェアを受け入れるだけの存在だった。
エンジニアが機能の企画・要件定義も行う体制では人手が足りず実装に十分な時間を割けないので、企画・要件定義を担当するエンジニアとは別に実装者のエンジニアがアサインされるようになった。企画・要件定義を担当するエンジニアがプロジェクトリーダーとなって実質的なプロダクトの責任者となる。プロダクトマネージャーは外部や経営陣との橋渡しをするだけの調整役になってしまった。
上図のプロジェクトリーダーと呼ばれるロールこそが自分の中ではプロダクトマネージャーだという認識だったが、このロールはプロダクトマネージャーのものではなかった。
なぜ期待と現実のずれが生じたのか。当時の自分は、プロダクトマネジメントというものへの認知が不足しているからだと思っていた。
プロダクトマネージャーという職能が日本で一般的に認識されるようになったのは伊藤直也さんや Higepon さんが Rebuild ポッドキャストで話していた 6 年くらい前からでないかと思う。その後 antipop さん達がプロダクトマネージャーの Slack コミュニティなどを作り、一時期プロダクトマネージャー界隈が盛り上がっていた。
しかし、一般的な日本のソフトウェア企業でその存在が認知されるようになってからはまだ日が浅い。プロダクトマネージャーという役割に対する理解は圧倒的に足りていない。それが自分の役割に苦しんだ最大の原因だと考えた。
本に書かれているプロダクトマネージャーのロールを押し通そうとして軋轢を生んだこともあった。『 Making It Right 』にも以下のように書いてある。
Common objections to the role include:
- “We have different people in the organization who fulfill each of these functions as part of their roles.”
- “I don’t see how the role will make us more money.”
- “Product managers will just slow us down.”
- “I don’t want to relinquish control of the product to someone else.” (OK, that one is usually thought without being said out loud.)
プロダクトマネージャーという役割に対する反対意見の例:
- 「うちの会社にはプロダクトマネージャーの役割を部分的に果たす人々がすでに存在してるんだ」
- 「プロダクトマネージャーとやらが会社を儲からせてくれとは思えないな」
- 「プロダクトマネージャーって連中は開発チームのスピードを下げるだけの存在だよね」
- 「プロダクトについての決定権を手放したくないんだよ」（通常、声を大にして言われることはない）
— Merwe, Rian van der. Making It Right: Product Management For A Startup World (pp.19-20). Smashing Magazine. Kindle 版.
プロダクトマネージャーが存在しない組織では、プロダクトマネジメントのロールをデザイナー、エンジニア、カスタマーサポートなど様々なロールの人々が少しずつ分担しながら製品が作られていく。そこに突然プロダクトマネージャーが現れて「それ僕の仕事なんで僕がやりますよ」と言うと反感を買ってしまう。
プロダクトマネージャーの存在が認知される以前から、ソフトウェアの仕様を固めたり、ステークホルダーと調整したりする仕事自体は存在していて、大体はエンジニアの中のリーダーがその役割を受け持っていたのではないだろうか。少なくとも自分がこれまで勤めてきたプロダクトマネージャーのいない職場ではそうだった。ビジネスサイドから提示された大まかなビジネス要件を元にエンジニア（もしくはデザイナー）のリーダーが機能要件をまとめていた。
同じような話が伊藤直也さんのプロダクトマネジメントについてのブログにも書かれてある。
なぜこのような慣習が出来たのかを考えると、日本のソフトウェア産業の構造が響いているような気がする。受託開発が中心だった日本のソフトウェア産業1では、ソフトウェア開発はひとまとまりに開発者（ソフトウェアを作る側）の仕事ということになっている。受託開発であったとしても受託者側で作るシステムの要件定義を行うケースがほとんどではないだろうか2。
このため作るべきものの定義と作る作業の境界が曖昧なのだと思う（一体型のソフトウェア開発）。一方でシリコンバレーではジョブデスクリプションが明確で役割分けに敏感なので、作るべきものの定義とその結果に責任を持つ人（プロダクトマネージャー）と、作ること自体に責任を持つ人（エンジニア・デザイナー）が明確に区別されているのだろう（分業型のソフトウェア開発）と推察する。
したがって、プロダクトマネージャーの役割の認知が広がらない限りはこの問題は解決できないと思うようになっていた。半ば諦めというか、自分では解決できない問題に立ち向かわなければならないようで、とても苦しく悶々とした日々を過ごした。
しかし一方で、プロダクトマネージャーの役割は会社によって異なると良く言われる。『逆説のスタートアップ思考』の馬田さんが書かれている記事には以下のように書いてある。
組織のリソースが豊富な場合はプロダクトの仕様を策定するだけの PM なのかもしれません。スタートアップのようにまったくリソースのない組織の場合は、全部の機能を一人がやらなければいけないのかもしれません。人を採用して少しリソースが増えたら、また PM に求められるバランス感が変わってきます。
組織の今の状況に応じて PM はその役割を変えますし、同じ組織においても時間が過ぎれば役割が変わっていくと認識しておくほうがよいのでしょう。
— プロダクトマネジメントトライアングルと各社の PM の職責と JD | by Taka Umada | Medium
当時の自分はこの観点が抜け落ちていた。もっと柔軟に振る舞って、どうすれば良いプロダクトをユーザーに届けられるかという視点に立ち、所与の環境でどういう働きをすべきかが考えられていなかった。
自分の失敗経験を踏まえ、一人目のプロダクトマネージャーとしてどう動けば良かったのかを振り返ってみる。
まず、プロダクトマネージャーが存在しない初期状態が以下だ。経営陣が戦略を、開発チームが戦術を担当する。
そこにプロダクトマネジメントの仕組みが導入されるとこうなる。プロダクトマネージャーは戦略と戦術の両方を股にかける動きをする。 What の領域に主眼を置きつつも、 Why や How にも関わる。
自分がプロダクトマネージャーになったとき、会社はプロダクトマネージャーに戦略性の高い領域を守備範囲とすることを期待していた。
しかしそれに反して自分自身は機能仕様の策定など、戦術的な領域を守備するつもりでいた。
この認識の違いのせいで会社、開発チームとの軋轢が生じ、仕事のやりづらさや違和感につながったと考える。
本で読んで得ていたプロダクトマネージャー像はどれも中規模以上の、プロダクトマネージャーが何人かいる組織でのものだった。なので一人目のプロダクトマネージャーとしてどう動くべきかという観点での参考資料にはなり得なかったのだろう。その点は自分の反省点だと思う。
一方で、組織が大きくなってプロダクトマネージャーの数が増えると、以下のように役割を分担できるようになる。
戦略性の強い仕事を上級のプロダクトマネージャーが担当し、戦術領域に関してはジュニアなプロダクトマネージャーが担当すればよい。
少し前に読んだ『プロダクトマネジメント』という本では、以下のような説明がなされていて納得感があった。
プロダクトマネージャーの戦術的な仕事では、機能を作って世に出すという短期的な行動に焦点を当てます。次にすべきことを決めるのに使うデータを処理したり、日々、開発者やデザイナーと一緒に作業を分解してスコープを決めたりすることも含まれます。
戦略的な仕事では、マーケットで勝利して目標を達成するためにプロダクトや会社のポジショニングを考えます。プロダクトや会社の将来像や、そこに至るために必要なことに着目します。
運営の仕事では、戦略を戦術的な仕事に結び付けます。プロダクトマネージャーは、プロダクトの現状と将来像をつなぐロードマップを作り、チームはそれに沿うように仕事を進めます。
— Melissa Perri 『プロダクトマネジメント』オライリー・ジャパン
以下の図もわかりやすい。
自分がプロダクトマネージャーの役割だと思っていたのは図中で言う「アソシエイトプロダクトマネージャー」か「プロダクトマネージャー」だったのだと思う。しかし会社は「プロダクト担当ディレクター」か「プロダクト担当 VP 」相当の存在を求めていた。戦術の領域はエンジニア・デザイナーに任せ、プロダクトマネージャーは戦略と運営にフォーカスするような働きが期待されていた。一方で自分は戦術にフォーカスしたプロダクトマネージャー像を持っていたため、組織のニーズにマッチできていなかった。
スタートアップのような小さな組織では常に人手が足りていないので、いくつかのロールを兼任することが求められる。小さな組織でプロダクトマネージャーが一人しかいないときには、戦術はある程度手放してエンジニアとデザイナーに丸投げし（エンジニア・デザイナーにプロダクトマネジメントのロールを兼任してもらう）、プロパーのプロダクトマネージャーは運営と戦略にフォーカスすべきだったのかも知れない。自分はそれができなくて、戦術に拘泥して失敗してしまったのだろう。
ただし、『プロダクトマネジメント』では、経営陣が期待するアウトカムではなく特定の機能（ HOW ）の実装を開発チームに要求し、一貫した戦略が存在しないためビルドトラップに陥る、ということも書かれている。プロダクトマネジメントの仕組みを整えるには、 CEO をはじめとした経営陣も一定程度戦術（どんな機能を作るか）からは手を引き、プロダクトマネージャーに権限を委譲していく必要がある。もちろん、なかなか簡単には HOW の領域から手を引いてもらえない（「プロダクトについての決定権を手放したくないんだよ」）ので、プロダクトマネージャーはうまい具合に立ち回って経営陣には戦略策定に特化してもらい、プロダクトについてのイニシアチブを自分で獲得していく必要があるだろう。
今年の前半に取り組んだプロジェクトで、プロダクトマネージャーになったときに自分のミッションだと思っていた Product Market/Fit を達成することが出来た。ユーザーがお金を払っても欲しいと思うものを考え、健全なマネタイズ手法を提案してリリースするところまで成し遂げた。これまで苦しんだ 2 年間だったけれども、ようやく自信を持って「プロダクトマネージャーやってます」と言えるようになった気がする。
Basecamp で従業員の大量離職騒動が起きていた。原因は社内で社会問題についての議論を禁止するという制度変更への反発。
Basecamp の制度変更の要旨
— morygonzalez (@morygonzalez) May 1, 2021
1. 社内での政治的な発言禁止
2. ジムなどの福利厚生終了（特定の価値観に基づくため）
3. 〇〇委員会禁止（仕事は個々人で）
4. 過去の決定を議論するの禁止
5. 360度評価終了（いい評価しか付かず役に立たないため）
6. 本業を忘れるな（ソフトウェアを作ることが仕事）
この制度変更の背景にはさらにややこしい問題があったようだ。
この記事にこれまでの出来事がまとめてある。 Jason Fried の制度変更表明はこれらの出来事に符合するものみたい。https://t.co/rys1Tx4BKG
— morygonzalez (@morygonzalez) April 30, 2021
この騒動を経て、以前 HEY を使ったときの感想として書いた以下の記事のことを思い出した。
ソフトウェアに必要なのは理念ではなく機能だ。そのことは Jason Fried も書いている。
6. No forgetting what we do here. We make project management, team communication, and email software. We are not a social impact company. Our impact is contained to what we do and how we do it.
ただ、 Jason Fried も DHH も本、 Twitter 、ブログで業務の一環かのように他社のソフトウェアやビジネスモデルに難癖を付けたりと舌鋒鋭い。その一方で従業員に社内で社会問題を議論をさせないのは矛盾しているような気がする。
以前書いた記事では、 Flickr は理念のみで機能が不足しているということを指摘した。 Basecamp の HEY については理念だけでなく、それを裏付ける機能があると支持した。しかし今回の騒動を見るに、理念の部分がだいぶ強すぎたと感じる。理念に引き寄せられて opinionated な人たちが集まったが、理念を表明して良いのは経営者だけで従業員は仕事だけして下さいと言われると反感を買うのは当然だろう。
理念や社会に対する意見があることは結構なことだと思う。しかしそれを声高に表明して回ることはソフトウェア会社の仕事ではないと思う。ソフトウェア会社の仕事はただ一つで、その理念に基づいたソフトウェアを作ることなはずだ。
そもそもソフトウェアで社会を変えられるのだろうか。自分はそうは思わない。世の中がソフトウェアをきっかけにして変わるだけだ。ソフトウェアは人々の内側にあった曖昧模糊とした欲求を具現化して解消しただけに過ぎない。 Uber で車と時間を持て余している人がお金を得られるようになったし、全然タクシーがつかまらなくて困っていた人はふっかけられることなく車で移動できるようになった。これは元々潜在的に存在していた需要と供給を顕在化させて結び付けただけだに過ぎない。どんなに画期的なソフトウェアやサービスも、人々に必要だと思われなければ意味がない。
崇高な理念や信念があったとして、それをいかにソフトウェアに吹き込むかがソフトウェア企業のやるべきことだ。自分は Rails エンジニアとしてソフトウェア業界に橋頭堡を築いたので DHH のことは尊敬しているけど、 Basecamp には人々に求められる良いソフトウェアを作ることにフォーカスして欲しいし、自分もそういう姿勢でソフトウェア開発に携わっていきたい。
土曜日、午後からスーパーに買い物に行ったが欲しいものがなかったので海まで歩いてみることにした。午前中天気が良くなかったので海にはほとんど人がいなかった。
昼飯にお好み焼きを食べ過ぎてお腹が重かったので、ちょっと運動しようと海沿いを歩いて生の松原の方に向かうことにした。
西福岡病院の前に新しくできた生の松原測候所の脇から砂浜に降りる。生の松原測候所は家具屋とギャラリーとカフェが一体になった建物のようだった。とても景色が良さそうなのでいつかカフェを利用してみたい。
生の松原の砂浜を元寇防塁まで歩く。松原は鬱蒼としている。長垂海浜公園の松林に比べると森といった感じで、砂浜を歩いているのにまるで登山に来たかのように森林浴をしながら歩くことができた。歩いている間はずっと Off Topic Podcast を聞いていた。
元寇防塁に近づくとやたら猫がいた。どうも野良猫のようだ。岩場に生息しているみたい。猫好きの近所の人たちが餌をあげに来ているみたいだ。釣り人もいるので雑魚をもらったりフナムシを捕まえて食べたりしているのかもしれない。
生の松原の端っこまでくると、十郎川の干潟で潮干狩りをしている人たちがいた。おっさんおばさんだけではなく、若者なんかも取りに来ていた。十郎川は結構澱んでいるのでアサリが取れたとしても食べて大丈夫なのかは気になる。
壱岐橋は渡らず、下山門の住宅街の中を通り抜けて家に帰ることにした。下山門の住宅街や団地街を通り抜け、いきまつバーガーの前を通りかかった。炭で肉を焼くうまそうな臭いが漂っていたが、売り切れ終いで閉店していた。いきまつバーガーの自動販売機でコカコーラゼロを買って飲んだ。
住宅街を通り抜け、 202 バイパスを目指す。いきなりバイパスに出ずに、下山門西公園に寄ってみることにした。
下山門西公園には大きなため池があって、釣りをしている人がいた。公園からはいつも西側から見ている叶岳と飯盛山が見えた。今宿側から見ると雄大に見える叶岳は、東側の生の松原側から見るとなぜかちっぽけな低山に見えてしまった。
下山門西公園から生の松原四丁目の住宅街を歩いてみることにした。公園横の坂を登り切ると福岡市内を一望出来た。遠くには脊振山系が見えた。
生の松原四丁目の住宅街はなだらかな斜面に住宅が建ち並んでいて、大学生の頃にポスティングのアルバイトで訪れた金沢文庫の住宅街を思い出した。あのときビラを投函して回った住宅街は駅から遠くて、暑い中坂を登ったり下りたりしてビラを投函して回るのはかなり大変だった。こんなに駅から離れたところに一軒家を建てて、駅まで何十分も歩いたあとに満員の電車に乗って大手町や有楽町に通っているのだろうか。かなり大変な暮らしだろうなと思いながらビラを配った。生の松原四丁目の住宅街からも下山門の駅までは歩いて 30 分くらいかかるだろう。まわりに人は沢山住んでいるのになぜかさみしい感じがする。一駅隣でもっと田舎の自分の家に向かって急いで歩いた。生の松原の住宅街からバイパス沿いに今宿を目指すと途中にラブホテルが二軒ある。場末の風情がある。今度は学生時代に当時住んでいた北馬込から自転車で大井埠頭まで行ったときのことを思いだした。言葉に言い表しようのないさみしさを感じる。
家に辿り着くと、家族は出かけていて家の鍵が閉められていた。うかつにも鍵を持たずに家を出たため中に入れない。庭で帰りを待とうとするが、庭は蚊だらけで 3 分くらいで諦めてアスファルトの道路に避難した。ここならば蚊はいないが、歩道におっさんが一人で立ち尽くし異様な光景だったと思う。家族はなかなか帰って来ず、日が沈むまでのあいだ道路脇に立ち尽くしていた。
この日はゼロシューズのペラペラのサンダルで 13km 歩きくたくたに疲れた。舗装路歩きは足へのダメージが大きい。残念なことにカロリー消費は 780kcal だったがワークアウトが 30 分に届かず Apple Watch のリングはすべて閉じられなかった。
家、若くして建てるとローンの返済が楽だが、購入する前に自分の人生観的なやつを確立しておく必要があると思う。
人生観的なやつとは働き方とか趣味とか何を面白いと思うかなど。借金して都会に 30 坪の土地と家を買ったあとに実は自分はウィンドサーフィン愛好家だったことに気がついて海の近くに住む必要があったとか、家にボードとかマストとかの置き場が必要だったとか、いろんな道具を積み込める巨大な車を停められる駐車場が必要だったと気づくのでは遅い。
〇〇風の建築が良い、的なやつも国内外を旅行してホテル泊や民泊などしてみて知識を蓄えておかないと、フツーの家を買ってしまったあとに実は地中海風の家が良かったことに気がついても覆水盆に返らず状態になってしまう。家を買う直前に付け焼き刃的に建築雑誌などを読んでもなかなか納得のできる家にはならないと思う。
とはいえいろいろ旅行したり、趣味を始めたり出来るような経済的な余裕が出て価値観が定まるのを待つと 40 歳くらいになっていて、そこからローンを組むのは定年後もローンを払い続けるリスクがあってきびしい。
自分の場合は 33 歳で家を買ったが、病気や浪人・留年で社会に出るのが遅かったので家を買ったタイミングでは到底人生観を確立したとは言えない状態だった。家を建てたあとにリモートワークするようになったものの家には仕事部屋がなく、寝室の一角で家族が寝てる横で仕事したりしてるし、キャンプや登山をするようになるとは思っていなかったので家に収納が少なく、キャンプ道具が廊下にあふれていて非常に家が暮らしづらい。家人も最近になってドライフラワーに開眼し、家はドライフラワーだらけで体の置き場がない。家を建てる前にこの辺のことを予見できていたら趣味の部屋や仕事部屋を作ったり収納を多めに作ったり出来たが、家を建てる前はインターネットして休みの日は街歩きして写真でも撮ってればそれで楽しいと思っていたのでこんなことになるとは思っていなかった。
40 歳を過ぎて家を建てても楽々ローンを返せるような高給取りではない人（自分含む）は、人生観の確立と住宅ローンの支払い期間を加味したタイムリミットを天秤にかけてギリギリのところで決断するしかない。その意味で自分は家を建てるのが少し早すぎたと思う。いま若い人にアドバイスするなら、 20 代のうちに旅行したり自分の趣味が何なのか（アウトドアなのか、インドアなのかなど）をよく探求した方がよいと思う。
最近、あまり自炊しなくなってしまった。リモートワークなので自炊しやすいはずなのに、レトルトとかしか食べてない。前職勤務時にリモートワークしてたときには良く料理していたのになんでだろうと考えてみると、フライパンが焦げ付きやすいからだと思い至った。
前職勤務時は T-fal のフライパンを買ったばかりで、炒め物をしても焦げ付きを気にすることなく料理していた。チャーハン、オムレツ、ペペロンチーノなんかを作ってた。
買った当時は焦げ付くことがなかった T-fal のフライパンは購入後 2 年を過ぎたくらいから激しく焦げ付くようになり、炒め物が億劫になった。テフロンが剥がれたあとのテフロン加工フライパンはただの異常に焦げ付きやすいアルミフライパンに成り下がってしまう。まだ鉄フライパンの方がましな状況で、目玉焼きを焼くのにも鉄フライパンを使うような状況だった。目玉焼きや肉料理であればまだしも、焼きそばやチャーハンなど炭水化物を炒めようとすると鉄フライパンは全くダメで、はちゃめちゃに焦げ付いてしまう。というわけで料理をしなくなってしまったのだった。
購入したのはバッラリーニ（ Ballarini ）のサリーナ（ Salina ）というフライパン。形状、コーティング、重さの三つのバランスが良くとても気に入っている。
金属を石っぽい材質の何かでコーティングしてあり、金属へらを使ってもコーティングが傷ついているようには見えずとても頑丈。テフロンフライパンは金属のへらを使うと傷が付いてそこからべろっとコーティングが剥がれてしまったりするが、そういうのがない。
縁がくっとそり立っており、炒め物でフライパンを振ったときに中身が飛び出しにくいようになっている。チャーハンや野菜炒めのときに思いっきりフライパンを振れる。
重すぎず軽すぎずでちょうど良い。軽いフライパンだと炒めるときに取っ手をつかんでいないと動いてしまったりするし、鉄フライパンだと重すぎて振れないが、そういう問題がない。 26cm と 20cm を買ったが、26cm でも重さは 1kg で、男性なら問題なく片手で持てると思う。
値段がちょっと高くて、 20cm でも 8000 円程度、 26cm は 1 万円弱したが、どうせリモートで飲み会とかも行かないのだし、調理器具に金かけても良いと思ったのでリストカット感覚で購入してみることにした。都会に住んでたら UberEats とかテイクアウトで豪遊できるのだろうけど、テイクアウトやってる近所の店は電話しても出来上がりは二時間後とか平気で言ってくるのでレトルトでない物を食べたいなら家で作るしかないと自分を説得した。ちょうど先月ぐらいから Amazon でクレジットカードの二回分割払いが出来るようになっていたことも後押しした。 8500 円ずつの二回払いなら何とかなる。
バッラリーニのサリーナフライパン、ちょっと高かったがとても良い買い物でした。おすすめです。
