人間が健康に生きていくには緊張と緩和が大事なのだが、いかんせん緊張が占める時間の割合が大きすぎると思う。

緊張状態にある人はただ生存するのに必要な量以上の生産を行う。その行為は一般に労働と呼ばれる。経営者からしてみれば労働者は緊張状態にて生産を行うのだから、なるべく緊張状態に留めておこうと監視の眼を光らせる。しかし、人間はずっと緊張状態で生きていけるわけがない。何せただ生存するのに必要な量以上の生産を行うためのエネルギーを使っているのだ。

それに、緊張状態は基本的に出力モードである。焦点が定まっていて、そこに集中するのには適しているが、アイデアを発散させたり新しい情報をインプットするのにはまるで向いていない。緊張から緩和に動いた時にアイデアが浮かぶ。シャワーを浴びたり散歩をしたり旅に出てみたり、緊張から解放された瞬間に飛躍がある。

効率性を向上させるために働き方を仕組み化する趣旨の指導や書籍はたくさんあるし、私もここ数ヶ月、仕事を効率よく進めるための型化を行ってきた。しかし、効率化を進めると労働に占める緊張の時間の割合が増えることに気づいた。計画を立てて効率的に仕事をこなしていくことで仕事は確かに前進したが、細かいミスが増えてきた。これは明らかに緊張の割合に身体が耐えられていない証拠である。だからこそ、仕事の効率化を行う際には、労働時間のうちどの程度を緊張、どの程度を緩和に振り分けるのかということを自分で定めておくことが、労働者として生きていくには大事なのではないかと思った。

小林秀雄、いい。

Claude Code をしばきすぎて二人称が＊になった。

紀伊国屋書店で日記の舌を立ち読みしているときに、こんな感じのデザインのサイトを作りたいなって思い、スタバでデザインを組んだ。

手作りタコスパーティ！

マサから記事を作って、コーラとオレンジジュースで肉を煮込んで、野菜を刻んで、記事を焼いて、とにかくやることがめちゃくちゃ多い！メキシコ人ってちょっとルーズな印象があったけれども、タコス作れる国民がルーズなわけない。すまねえ。

日記アプリを作った。

GitHub - Tsuuuuuuun/hibiContribute to Tsuuuuuuun/hibi development by creating an account on GitHub.GitHub

限りなくシンプルかつ Twitter のように気軽に書き込める場所でありたいという思想の下で作った。

何かを思いついたときに気軽にメモを取りたいという動機が常にあった。それはX（旧 Twitter）によって満たされていたのだが、今のXはユーザーを中毒にさせることに躍起になっており、単にアイデアを刻むだけのツールとしては不適切なものになってしまった。

他の色々なアプリを試した。bluesky は X のような扇情的なものがなくて気に入ってる。ただし、自分が投稿したものは自分の持ち物ではなく bluesky 側の持ち物であるのが少し気になる。

要は自分の書いたものが自分の手元にあって、かつ思考の流れを追うことができる、すなわちタイムラインの形をしていれば良いのだ。その要望を obsidian thino は叶えてくれた。書いたものは手元の markdown ファイルの中に残る。ただ、各カードの書き味がちょっとイケてないと感じたり、公開や共有には向かなかったり、結局は obsidian のエコシステムの中に閉じているのが気になってしまい、使わなくなっていった。

同じようなことができるのが memos だ。obsidian thino のような書き味で、セルフホスティングが可能なのであらゆる端末から書き込めるし、公開も容易である。

実際に最近使い始めており、仕事で気になった技術や話題についてメモを残している。かなり便利で99%満足なのだが、デザインがちょっとやかましいような気がしている。もうちょっと削ぎ落としたい。

などなどを考えながらこのサイトを作った。

（なお、ここより前の投稿は思い出しながら書いたものになる。）

編集画面を実装した。

feat: 編集画面を実装 · Tsuuuuuuun/hibi@e7d5cbbContribute to Tsuuuuuuun/hibi development by creating an account on GitHub.GitHub

かなり直感的で気に入ってる。同期ボタンが本当に使いやすい。

今のところは手元の macbook でのみ編集できる形ではあるが、VPSに移動してssh繋いで色々な端末から編集できるようにしたいなと考えている。他に必要な機能、検索はできた方が良い気がするくらいかな。

あと、手元に情報を残しておきたいという思想には少し反するが、これをデプロイしている cloudflare の都合でファイル数が 20,000 に制限されているので、画像は R2 に置いて配信するのが良い気がしている。ビルドやデプロイの時間も短くなるので、手が空いたら着手したい。

検索窓を実装した。これで思い出が遡りやすくなった。

feat: 検索画面を実装 · Tsuuuuuuun/hibi@f1e0182Contribute to Tsuuuuuuun/hibi development by creating an account on GitHub.GitHub

カレンダービューを実装した。

feat: カレンダーを追加 · Tsuuuuuuun/hibi@4ec6919Contribute to Tsuuuuuuun/hibi development by creating an account on GitHub.GitHub

月と日は検索できるようにした。週単位のビューも実装したい。

風の噂の折りたたみ iPhone って搭載される OS は何になるのだろうか？

個人的には iPad mini が折りたためるくらいのテンション感なら、値段次第ではありだなって思っている。

Claude Code に「やっぱり、」って言葉を使った時、Claudeは内心ブチギレているだろうなと思った。

ブログを作って眺めている場合などではない。明日までに自己評価シートを作成しなければならない。こんな時間から白紙のExcelを埋めている。

前回の自己評価シートの方が中身があることを書けているなと思った。今期はやることが多い！！！と思いながら日々を過ごしていたら終わってしまった感覚がある。

最近のXでは一日の労働時間が8時間なのは長すぎるのではないかという議論が繰り広げられている。個人的な思いとしては、一日のうち8時間を労働に費やすこと自体はまあ妥当だとは思う。ただ、それは8時間の間ずっと業務に従事すべきという意味ではない。今の仕事に対してより効率的なやり方はないか、将来的に自分はどのようなキャリアを進みたいのか、キャリア戦略に対して自分の現状の位置はどこなのか、そのギャップを埋めるためには何をしなければならないのか、それらについて考えたり手を打ったりする時間を込みで一日8時間は妥当だが、業務に8時間費やした上で今述べたことを業務外の時間に進めるのはしんどい。ここに残業が加わると、もう目の前のタスクをこなす以外の体力は残されていない。食事、睡眠、入浴、家事などのタスクをどれだけ効率化したり切り詰めたりしたところで、仕事でHPが尽きてしまうという問題は解決しない。

今期はまさに目の前のタスクで体力を使い切ってしまい、振り返りや自分のキャリア・スキルのポートフォリオ戦略を怠ってしまったという反省がある。持続可能な働き方を達成するために、きちんと priority を明確にした上で、現在地点と目標地点の距離を定期的に振り返る機会をちゃんと設ける九月にしたい。

年々、時間が経つのが遅くなっている｜ハヤカワ五味誕生日のたびに、「年を取るのがつらい」という前提で連絡をもらうことがよくあります。 今年で31歳になったので、「29歳とか30歳に比べたら、そこまで衝撃はないですよね」みたいな。ありがたいんですけど、正直、年齢を重ねること自体にネガティブな感情はあんまりないんですよね。 それと同じくらいよく聞くのが、「年々、時間が経つのが早くなるよね」という話。みんな当たり前の前提として話してくるんですけど、これも私はあまり共感できなくて。むしろ逆で、年々時間の経つのが遅くなっている感覚があります。 具体的に言うと、「まだあれから半年しか経ってないんだ」と思うことがめちゃくちゃ増えました。AI以note（ノート）

めちゃくちゃ良い話だ。イベントに対する意識、大事。

ほっかほっか亭のタルタルチキンかつを食べた。

手戻りを引き起こさないためにも、ちゃんと作業は型化したほうがよい、、、

基本設計に着手したときに固めておくべき要件に気づくことはまああるし、詳細設計で feasibility に気づくこともないことはないが、実装で「この要件って固まっていたっけ？」になっちゃあいけないや。

オムライスを食べた。

何でもかんでも環境変数にしない - モヒカン技術ブログシステムにおいて「環境変数」として扱うべきものは実は限られている。環境差がないものは環境変数として扱うべきではない。 そもそも環境変数とは何か 環境変数はOSがプロセスに渡す名前付きの文字列である。アプリケーションは起動後に $_ENV や process.env などから必要な値を読み込み、その後の処理に利用する。言語やフレームワークに依存しない、実行時入力の仕組みだ。 環境変数についての最も権威的な出典は The Twelve-Factor App の Config という記事だろう。 12factor.net この記事で言う環境変数は、ステージング・本番・開発環境などデプロイの間で異なり…モヒカン技術ブログ

何を環境変数にするべきかの判断基準は単純で、環境を変えても値は同じかどうか。同じならコード、違うなら環境変数。

確かに命名のことを考えるとそうだなと気づいた。この指摘で環境変数と secret の違いの気持ちを把握した。

環境変数である必要がないものまで環境変数にしていると、AIエージェントはそこを推測で補って解釈し、コードを出力することになる。果たして、そんなコードを信用してコードレビューに出せるだろうか？

この観点は盲点だった。アプリ側で人間が定めたい設定項目については config に分けるのがあるべきなんだろうな。

高学歴に対してノブレスオブリージュを押し付けることに対する違和感、人間を「社会にどれだけ有用な成果を供給できるか」によって序列化する思想に由来するような気がしていて、となると能力の低い人間に対して「あなたから社会が受け取れるものは大してない」という評価を下せるような不穏さを感じる。

さらに言えば、「能力の低い人が社会について発言したり、公共的活動をしたりするより、優秀な人に任せたほうが社会的効用が高い」というところまで行き着いて、結果的に「社会を動かすのは優秀な人間の仕事であり、普通の人間はその受益者であればよい」という、かなりエリート主義的な社会観になってしまい、結果的に格差がどんどん拡大するような気がする。

R-style倉下忠憲による、知的生産やライフハックをテーマにしたブログ。R-style

〈である原理〉では二人称である「あなた」は想定されていません。しかし、読む人は実際にいるわけです。文章を提出するときに誤字脱字やロジックを整えるのも、そうした読む人がいることが想定されているからでしょう。しかし、その人は「あなた」ではない。文章の書き手と読み手という風に立場が分かれるのではなく、「われわれ」（実際論文でよく使われる表現です）という同じ営みを続けるものとして扱われている。

面白い。誰に読まれるのかと、いうところから常体・敬体が定まるのか。

久々にモロゾフのプリンを食べた。卵があまりに濃厚で、もはや茶碗蒸しに片足突っ込んでいる気がする。