■
昨日は会社でスキーヤー3人のイベント。アイスランドにスキーとサーフボード積んで一周してきた様子を動画とフォトブックにしたので、動画の上映会。アイスランド一周ってすごい。
現地のスキー場で、こんなところ登っていいの、というところまで登って滑ることができる。勿論本人たちが自己判断でいけると思ったところを滑るという、行動に対する責任を強く求められる状況なのだけれど、それにしても。
事前に下からある程度プランニングしているのだろうけど、滑り始めたら計画通りにはいかないだろうと思う。山の溝に積もった雪を綺麗に滑っていくが(斜面を乗りこなしている、というふうに見えた)、滑れそうな先がとうとう無くなってきたシーンがあった。それを本人もわかっているのだろう、遠くから少しスピードを落としてコースを見定める。よく見ると滑れそうな斜面に少しだけ雪が残っていて、しかし本当に滑れそうか怪しそうなコースに勇気を持って飛び込む。そのあとは、またスピードを出して滑り出す– このシーンがめちゃくちゃカッコよかった。
DJしていてすごくいい流れが作れているとき、もうこれ以上手持ちがないような気がして追い込まれる時がある。過去のプレイリストも含めて曲を探して、プレイ中の曲を繋げるなら次の小節で流し始めるしかない、ヒリヒリしながら頭出しをして、流しながら勇気を持ってフェーダーをあげる。もうこうなったら、繋げるしかない。どんな曲だったか曖昧で不安になりながら繋げ切る。そんな状況と少し重なるなと、ブログ書いてみたら思った。
最近本当にブログが書けていなかったんだけど、新しい会社に入社したら皆文章力や言語化が見事で、何か書きたいなと思っていたから書いたんだけど、やっぱり書くのは良い。公開しなくてもいいけど、公開すると決めると、何かしら書き切ったり構成を気にする勢いが生まれるので良い。
そういや、そもそもブログ書いてみたのは、遅くに風呂に入ったらシャワーのお湯がぬるくて、多分娘が温度のボタンを勝手に押したからなんだけれど、家族全員がすやすや寝ている深夜に時空を超えてイタズラされるのが面白いなと思ったのだった。(娘は風呂に入るとよく給湯器のボタンを押す。)で、なぜ遅くに帰ってきたかというと、会社の一階でスキーヤーの上映会があったからなんですね。

そういえば、この映像のエンディングを歌ってた人、チョー歌が上手かった、凄かった。
Cloudflare Accessで自宅サーバーにアクセスすると数分間だけ500 Bad Gatewayになる
Cloudflare Accessで自宅サーバーに建てているminiflux にアクセスしようとすると、久々なアクセスだけ500エラーが続き、数分経つとアクセス可能になる、という謎の挙動が続いていた。しばらくの間お茶を濁していたが、いい加減なんとかしようと思って調べたら、なんと時計がずれていた。全然使ってないと、こういうことが起きるなー
2025-10-05T08:45:40Z ERR Request failed error="error while processing middleware handler AccessJWTValidator: oidc: current time 2025-10-05 08:45:40.414097363 +0000 UTC m=+4002600.071369122 before the nbf (not before) time: 2025-10-05 08:59:13 +0000 UTC" connIndex=0 dest=
event=0 ip=198.41.192.47 type=http
NTPパッケージを入れて、立ち上げとく。
$ yay -S ntp $ sudo systemctl start ntpd $ sudo systemctl enable ntpd
// enableとstartを同時に実施したいときは、 systemctl enable --now を使うといいらしい。へええ: (小ネタ) systemctlでサービスの有効化と起動を同時に設定 - zaki work log
ntpq -p で様子が見れる。
$ ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== time.cloudflare 10.126.9.168 3 u 17 64 1 4.018 +816460 0.000 x.ns.gin.ntt.ne 129.250.35.222 2 u 16 64 1 2.932 +816460 0.000 y.ns.gin.ntt.ne 129.250.35.222 2 u 15 64 1 3.138 +816462 0.000
offsetがおおきい。しばらくこの記事を書いたりしてたら、同期されてた。
$ ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== time.cloudflare .STEP. 16 u 110 64 0 0.000 +0.000 0.000 x.ns.gin.ntt.ne .STEP. 16 u 124 64 0 0.000 +0.000 0.000 y.ns.gin.ntt.ne 129.250.35.222 2 u 4 64 1 2.627 +2.498 0.000
poll の秒数経ったら参照しにいくらしい。 when は最後に参照してからの時間だけど、手前の二つはしばらく経ってるのは不思議だな。
もう少し経ったら、こんな感じになってた。
$ ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== time.cloudflare 10.126.9.168 3 u 41 64 3 2.628 +4.254 1.690 x.ns.gin.ntt.ne 129.250.35.222 2 u 35 64 3 3.282 +3.737 0.239 y.ns.gin.ntt.ne 129.250.35.222 2 u 25 64 7 2.986 +6.199 2.929
ふむふむ。なんかいい感じに参照してるんだな。 というわけで、これでいい感じだと思われる。
ユーザーが受け取るべき利益について
株式会社において…。(一般論)
株主の皆様にお約束した事業の目標を達成し、株価として、配当として、還元している。
従業員にも、それなりに支払われている(とする。)
はたして、ユーザーやクライアントにはどうなのだろうか?
本来ユーザーやクライアントが受け取るべき利便性が蔑ろになって、事業目標を追いかけすぎてはいないのか?ひいては、株主ばかり見ていないだろうか?世界は幸せになっているのだろうか?本来ユーザー受け取るべき配当があるのでは?
というのを考えていた。
しかし、一会社員としては事業目標を達成するのは当たり前で、その上でユーザーも大喜びする部分を作ることが重要なのかもしれない。それは顧客理解と事業理解から来るのではないかとすれば、僕らはまだまだ何も理解できていないのだ。
UIも、ユーザーのペインも、事業構造も全てを抑えて、オトシドコロをみつけなくてはいけない。
これが株主にとっても良いことなのかは不明だと思う。でも、現状そうなっている。
ここから脱するには、小さなチーム、大きな仕事なのかもしんない。