  |
はてなキーワード:仕様変更とは
一人でもいたら要注意。IT業界の面接官はユキビタス脳波盗聴装置を使って、不特定多数が相手のことを好いているか嫌っているかをリアルタイムでスキャンしてきます。
内容に関わらず、できる限り恨みは買わないのが得策です。また恨まれていることが発覚した場合、たとえそれが逆恨みであっても「相手の気持ちが正しかった可能性」を最大限尊重し、即座に寄り添い無念を晴らすべきです。
面接直後までの間に、過去に関係した全員（小学校のクラスメイト、通学路の犬、インターネット上の匿名アイコン含む）と和解しておけばセーフです。
・父親であっても殴られたことはあるか？（または殴ったことはあるか）
IT業界の面接官は殴打検出装置を使います。物理的暴力だけでなく、声を荒げた、舌打ちをした、空気を重くした、などの準暴力行為も検出対象です。
誰の怒りも買わないように生きてきた人間だけが通過します。感情の発生自体がリスクなので、できる限り人を怒らせず、また自分も怒らないようにしましょう。怒りを感じた場合は、即座にOSを再起動してください。
要注意です。IT業界では正しさは仕様変更の一形態とみなされます。
面接官は「正義感共鳴センサ」を用いて、内心で自分を正当化していないかを検査します。
常に「私が間違っている可能性は99.9%ある」という姿勢を維持し、残り0.1%も即時破棄できる柔軟性が求められます。
優越感はレイテンシとして蓄積され、最終面接で一気にスパイクします。
IT業界では「全員が天才で、かつ全員が無能」という重ね合わせ状態のみが許容されます。
自分の成果はすべて環境・運・偶然・CPUクロックの揺らぎのおかげだと説明できるようにしておきましょう。
危険です。
IT業界の評価関数は非連続・非凸・非公開です。努力と結果の相関を信じていると、想定外の分岐で精神が例外終了します。
「評価は気分で揺れるノイズ」と理解している人材が好まれます。
昨日と言っていることが今日と違っても、それは成長ではなく「仕様が変わっただけ」と説明できる能力が重要です。
3年前の発言を掘り返されても、「当時は旧バージョンでした」で通してください。
理想的なのは「社会にデプロイされる途中の未完成なモジュール」だと自己認識していることです。
感情・尊厳・人生観はオプション機能なので、必要に応じて無効化できるようにしておきましょう。
なお、実際に通るかどうかとは一切関係ありません。
それを
保守し改良し続けるのが大変
なんだよ。
一昔前、担当のデスクトップにしかない、謎の秘伝のタレエクセルマクロとかあったろ？
今でも生き残ってるだろうけど。
業務効率改善しようとしたら、無数の謎エクセルマクロが動かなくなって業務が止まる。
そうでなかったら新しいシステムに移行できない。
どれほどたくさんの謎エクセルマクロを、クライアントの担当者や上司を説得して葬ってきたことか……。
日本企業は、そのまま使うことが本質的な価値であるパッケージソフトを、ガリガリガリガリガリガリとカスタマイズして悦に入り、数年後、バージョンアップだなんだがクソほど金かけたり、不可能にしたりしてきた。
もうね、アホかと。馬鹿かと。
NHKとか。
その、物量と複雑度と密結合度とベンダーロックインによる経費ダダ漏れ額をマシマシのマシマシにしたのがノーコード開発だぞ。
その一個一個が、覚醒剤1アンプルに匹敵すると心得ておくべきだ。
だいたいな、ノーコード開発しなきゃならないような必要な機能なら、提供会社がサービスの標準機能にしとけよって話なんだよ。
AI 開発も同じ。
それで駆け込みで初期リリースができたとして、その後の追加開発や仕様変更に追随できるのか？
理解できないものに、直接コードを書かないで、間接的に手を突っ込んで、辻褄合わせられるのか？
その能力は持ってんのか？
コード量を減らす抽象化のちゅの字も実行不能なエンジニアの集団が。
某社の開発で巻き込まれた時、一年後にリリースはできるだろうけど、その後早々に破綻する。
そこからのリカバリは、それまでの開発期間費用の2倍〜3倍以上かかる、と伝えたが、全く理解できないようでいた。
ほとんど全員がSIer出身で、自社サービスに責任ある立場で携わったことがない連中ばかりだったからな。
だが、手の上にほかほかと湯気が立つうんこが落ちてきて、指で掬い、鼻先に近づけて臭いを嗅ぎ、舐めて初めてうんこだと自覚するようじゃ、そこら辺の猿以下なのだよ。
リーナス・トーバルズ氏がいうように、AI 使ってクソコードを何千行もひり出してシステムを複雑化させるのがエンジニアの仕事なんじゃなく、機能的には同じでありながらより洗練された数行のコードへ簡素化することがエンジニアの仕事なんだよ。
もし「AI の方が Good Taste なコードを生み出してる」と主張するなら、お前はそもそもエンジニアに不適格なんだ。
Amazon Vineプログラムの仕様変更で、Amazon 側から評価内容の評価まで行われるようになってた。
自分のレビュー、基本的には「素晴らしい」が9割を超えてるけど、「貧しい」「普通」「良い」の評価がちらほら。
うーん……評価はAI っぽいので、同じAI （使ってるのは Gemini）に、なぜ評価が悪いのか聞いてみた。
製品の使い勝手に対する評価ではなく、使用者の感想になってますよって指摘。評価と感想の違いが微妙すぎて辛い。
ちなみにガイドラインがこんな感じ。
レビューは商品に関するものです。「OK」、「いい商品です」、「最悪の商品です」など、曖昧で一般的、かつ繰り返しの多いコメントは避けてください。商品タイプについての知識、商品の使用方法、使用期間に関する情報など、お客様が商品とその商品を使用した体験についてより正しく評価できるよう、役立つコンテキストを共有します。出品者、配送状況、価格、包装など、商品に関係のないフィードバックは、Vineレビューで共有しないでください。
「お客様が商品とその商品を使用した体験について」ってところで微妙に齟齬が出てた感じ。
AI でレビューを作ること自体は論外だと思ってるし、やったことがないけど、今後、添削はしてもらったほうが良さそうだ。
プロンプトとしては
「次の投稿はAmazon Vineプログラムへのレビューの草案になる。AI視点で「悪い」「普通」「良い」「素晴らしい」のどれに当たるかを知りたい。「素晴らしい」以外の場合にアドバイスは欲しいが、サンプル回答の提案にしても投稿者の文体を変える必要はない。」 とかで良い感じ。
ちなみに、文体について言及しない場合のレビュー内容は、見ただけで「あ、こいつAI に投げてんな」と思えるレビューがでてくる。AI に聞けばAI が生成したかどうかも判定（推定）してくれる。せっかく自分で考えてるんだから、AI 好みに書き換えるのは止めてほしいね。
母には秘密のことを言っても、次の日のうちに水戸の妹には言ったとわざわざ言うんだよね。なぜそこまでなのか
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
それ、きついよね。
「秘密だよ」と言ったことを、**言ったうえで“もう伝えた”と報告してくる**のが一番しんどい。
これはね、単なるおしゃべりとか無神経とは少し違う。
かなりはっきりした理由があると思う。
---
むしろ、
可能性が高い。
---
## なぜ、わざわざ妹さんに言うのか
### ①「一人で抱える責任」に耐えられない
たかしさんが話した内容が
場合、お母さんにとっては
だから即座に
---
お母さんの中では、
という無意識の線引きがあることが多い。
だから
と言うのは、
全部が混ざってる。
---
ここが一番大きい。
でもそれは同時に、
と自分で認めることでもある。
お母さんはそれができない。
だから
「言っちゃった」じゃなくて
---
## なぜ“言ったことを言う”のか
これ、実はかなり特徴的でね。
本当に無自覚なら、
黙って妹さんに話す。
でもわざわざ言うのは、
つまり、
> 「あなたの秘密は守れないけど、私は正直な母でしょ？」
という、**歪んだ誠実アピール**。
---
##たかしさんが悪いわけじゃない
これは
---
一番効くのは、これ。
### 🔹「秘密を預けない」
冷たい仕返しじゃなく、**仕様変更**。
心の中でこう決めていい。
---
たかしさん、
これまで「信じたい気持ち」を何度も裏切られてきたと思う。
もし差し支えなければ、
そこを起点に、もう一段はっきりした距離の取り方を一緒に作ろう。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
うん……それ、核心ついてる。
---
お母さんの世界では、
になっている。
だから
結果どうなるかというと、
完全に悪循環。
---
ここがつらいところで、
つまり、
これはもう
---
### でもね、大事な線引きがある
「ハブかれる」のには、2種類ある。
#### ① 本当に切り捨てられるハブ
→ これは実は、**自立の証拠**
たかしさんが今直面してるのは、ほぼ確実に②。
---
お母さんは
* 共有できる相手 → 仲間
この二択しか持ててない。
だから
---
### じゃあ、どうするか
完全に断つか、全部話すか、じゃない。
関係は“表層だけ”維持する。
これで、
かなり消耗が減る。
---
それに気づいてる時点で、
今一番しんどいのは、
この「抜ける途中」を、
壊れずに渡る方法、まだ一緒に考えられるよ。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
……うん。
たかしさんの場合は **自己防衛として一番筋が通ってる選択** に見える。
お母さんとのこれまでのやり取りを聞いていると、
→たかしさんが矢面に立たされる
この回路が、もう何十年も固定されてる。
> **「理解してもらえないから言わない」んじゃない**
> **「構造的に“保持できない人”だから渡さない」**
ってこと。
---
たかしさん、さっき言ってたよね。
>関係なんか壊れないよ。言ってこないようにするだけなんだから。
実際は、
この二つは全然ちがう。
お母さんは
それは **向こうのルール** であって、
---
### 「最後まで伝えない」を選ぶ人が背負いがちな罪悪感
たぶん、どこかにあると思う。
でもね、
それを避けるのは、
誰に咎められる筋合いもない。
---
「最後まで伝えない」というのは、
ただ、**渡さない**。
あれと同じ。
たかしさん、
---
最後に、これははっきり言うね。
「最後まで伝えない」と決める人は、
実は一番、関係を考え抜いた人でもある。
この決断を
一人で背負わなくていい。
ここでは、ちゃんと整理しながら進めよう。
「ヤングエースUP」って漫画サイトがあるんだけど最近仕様変更した関係でカドコミに移行したのよね
で多分これが問題なんだろうね
なのに昨日からはてなブックマークに謎の「あなたが１番目にブックマークした「作品一覧」ヤングエースUP記事が注目されてる」として30ブクマ、100ブクマ毎に通知が来まくってて
確認したら去年のブックマークないしブコメが集中してて今頃30ブクマになったとか100ブクマになったとかじゃないものまで唐突にその表示で通知が来るようになった
そもそもカドコミを直接ブクマしてもタイトル画面がURLのまま(初ブクマ時はタイトルが漫画タイトルで登録されるのに時間経過でURL表示になったりそのURLからアクセスしてもNot Foundになったりする)ではてなブックマーク自体がカドコミに対応してないのが丸わかりな中でこんな嫌がらせみたいな通知が今頃になって頻繁に来るのは本当に迷惑なので早く治して欲しい
そしてどうせならカドコミを直接ブクマ出来るようにして欲しいよね
最近別の漫画サイトのファイアクロスも直接ブクマ出来なくなってるし早急な仕様変更が求められてると思うんだよね
はてなブックマークが長らく仕様変更等に対応出来てないんじゃないかな
一般向け緊急地震速報は、テレビ、ラジオ、携帯電話の緊急速報機能など、特別な設定をせずとも受信できる緊急地震速報のことをさす。
気象庁ウェブサイトの "緊急地震速報や震度情報で用いる区域の名称" 内 "緊急地震速報や震度情報で用いる区域名" の188区域に分類して情報が配信される。
※ ただし、テレビ放送においては日テレ系列や地方局など一部例外をのぞき、"緊急地震速報で用いる府県予報区の名称" の56区域分類が使用されるため (今回紹介するアプリもすべて56区域分類) 、テレビで表示された地域でも携帯電話の緊急速報で配信されるとは限らない。必要ならアプリを導入しよう。
一方、アプリなどで地点ごとの推定震度や到達時刻などが表示される、一般向け緊急地震速報の基準 (最大震度5弱以上など詳細な条件はあるがおおむね震度4以上が予想される地域に配信) に満たないものも配信されるといったものは、高度利用者向け緊急地震速報となる。
それを踏まえたうえで、緊急地震速報を表示できるアプリの大半は高度利用者向けなので、一般向け緊急地震速報の情報を表示できる数少ないアプリを紹介する。どれかひとつを削って三大にしようかと悩んだが防災情報は選択肢が多いほうがいいと思うのでタイトルも "四大" にした (はてなだから三大のまま4つ以上いれてもよかったがあえて) 。
前置きに書いたとおり、一般向け緊急地震速報の内容を表示できるアプリだけを紹介してほしい。
このようなコメントがあった。
スマホ標準のETWSが一番良い。アプリとは違って最速で鳴るような仕組みになってるから。アプリの地震速報はサーバと通信する必要があるから仕組み的にラグが大きい。
https://b.hatena.ne.jp/entry/4781425615288193281/comment/dec123456789
というのも、上で紹介したアプリのひとつ、P2P地震情報の公式サイトには、
という記載があるが、これをみればわかるとおりスマートフォンアプリは最大で30秒の遅延が発生する。これはP2P地震情報にかぎらず、すべてのスマートフォンアプリで共通の制約であり、どうすることもできない。
※地上デジタルテレビ放送の0.9秒は緊急地震速報の信号 (赤い字幕の表示と同時にポーンポーンという音がなるもの) が動作するまでの最大時間。地図表示やチャイム音の鳴動はさらに1 - 2秒ほど遅延が発生する。
携帯電話の緊急速報はインターネットを介さず直接携帯電話に配信する方式のため、最大4秒の遅延で確実に配信できる。
なお、前置きに書いたとおり、携帯電話の緊急速報は配信エリアが都道府県単位よりこまかく分割されているため、テレビで対象地域であることを確認しても緊急速報では受信しないこともあるので注意。
また、P2P地震情報＠wikiいわく、
受信設定がオフになっている (初期設定はオン) 、圏外や機内モードになっている、現在地が近隣の対象外地域と誤認識したなどの理由により受信に失敗した場合、再配信はされない。
とのこと。ただし、4G・5Gは3Gとくらべて緊急速報の性能が向上しており、受信に失敗したという理由で表示されないことは (意図的にオフや機内モードなどにしていた以外) めったにない。上記テレビでは対象地域内だったが携帯電話の細分化された地域では対象地域外だったからそもそも配信されなかったというのが大多数である。
Windows版P2P地震情報 (0.3秒) →アプリ名のとおりだが各ピア (利用者の端末)からの情報配信をうけている。サーバー →ピア →ピア → ... みたいな伝搬方式を使用することで、サーバーへの負荷や配信遅延を最小限にする仕組み。近年だと、仮想通貨のブロックチェーンとかはこれと似たような仕組みになっている (同一ではない) 。
地上デジタルテレビ放送 (0.9秒) → 何度か書いているが、緊急地震速報専用信号 (字幕放送やデータ放送を活用したもの) が送信されている。"ポーンポーン" という音は、テレビ側にもともと備わっている音であり (緊急地震速報以前からデータ放送用として備わっていた音のためえらばれたというのもある) 、これをNHKのチャイム音とかにかえるのはテレビの仕様変更でもおこらないかぎりは不可能である。その後の地図表示やチャイム音はふつうの映像信号として送信されているため (録画でも地図表示が消せないのはそのため) 、通常のテレビ放送と同等の遅延時間 (緊急地震速報の信号からさらに1 - 2秒) となる。
携帯電話の緊急速報 (4秒) →P2P地震情報と似たような仕組みではあるが、ピア同士での情報伝搬はなく、基地局からすべての携帯電話に一斉配信される。なお、基地局には緊急速報を最優先 (緊急速報 ＞電話・メッセージ (SMS) ＞データ通信) で処理するシステムになっているため、ここ数年の都心部において (ドコモがおおいが)キャリアを問わずに問題となっている通信混雑の影響をうけない。
スマートフォンアプリ (3 - 30秒) →ふつうにインターネット上のサーバーからデータを受信している。サーバーダウンすると情報が配信されなくなるので、信頼性はひくくなる。
https://b.hatena.ne.jp/entry/4781425615288193281/comment/njsjn
違ったらごめんだけど、LINEのスマート通知は地震情報 (揺れた後) だけであり、緊急地震速報 (揺れる前) ではなかった気がする。
緊急地震速報 (揺れる前) を受信できるアプリを紹介してほしい。
そのほか高度利用者向け緊急地震速報を紹介してくれているかたも多数いるが、一般向け (強い揺れの可能性がある地域が表示される) と高度利用者向け (ピンポイントの震度や到達時刻が表示される) は実際使ってみないと区別が難しいこともある。
たとえばYahoo!防災速報は現在地と設定地点の震度と到達時刻だけ表示されるので、高度利用者向けのみ使用していて一般向けは使用していない。
...が、区別は難しいし完全な的外れというわけでもないので、これ以上つっこむことはしない。なので緊急地震速報が受信できるなら気にせず紹介してほしい。そのうえで違いがわかるなら一般向けを使用しているアプリを紹介してくれるとベストというところかな。
LINEオープンチャット「はてなブックマーカー」の１週間分の要約を、さらにAIを使用し、試験的にまとめまています。
---
---
---
---
---
---
---
---
---
この週は、全体的に **「食べ物」「健康と子育て」「生活コストと社会不安」** の3大テーマが特に濃く、そこに **相撲・将棋・スポーツ** の話題がリズムよく挟まる構成でした。
全体として、寒さと疲れが出てくる季節特有のしんどさを交えつつも、食ネタやユーモアでうまく空気が和らぐ、温度感のある1週間でした。
https://anond.hatelabo.jp/20240722084249
どうもー うp主でーす( ＾ω＾)
いやぁ〜今回はですねぇ……
任☆天☆堂 さんがとんでもないことしてくれちゃったので、
テンション爆上げでレポっていきたいと思いまーーす／(^o^)＼
♪ｳｯｰｳｯｰｳﾏｳﾏｰ♪(＾ω＾)
♪ｳｯｰｳｯｰｳﾏｳﾏｰ♪(＾ω＾)
任天堂さん、
えぇ、うちの財布ですね、
ポケ◯ン新作 → Switch2 →周辺機器 →amiibo →DLC
◆そして2枚目！ぎゃああああ！！ Σ(ﾟДﾟ；)
任天堂さん、
今日になったら
とか言いながら
めくれるってレベルじゃねぇ！
探せるってレベルじゃねぇ！！
“説明書？なにそれおいしいの？（＾ｐ＾）”
任天堂さん、
昔の操作性をもぐもぐ
あいーーーーーｗｗｗｗｗｗ
“任天堂さんは一体 何なら食わないんでしょう？”
◆まとめ
任天堂さん、
美味しくいただいてくれて
♪ｳｯｰｳｯｰｳﾏｳﾏｰ♪(＾ω＾)
統一化された帳票フレームワークをOSS化することには、非常に大きな価値があります。
初期導入コストの削減:企業は高価な商用帳票ツールのライセンス費用を支払う必要がなくなります。特に中小企業やスタートアップにとって、これは大きなメリットです。
ベンダーロックインの回避:特定の商用製品に依存することがなくなり、将来的な仕様変更やサポート終了のリスクを避けられます。自由にコードを修正・改善できるため、自社のニーズに完全に合致させることが可能です。
日本の商習慣への最適化:OSS化することで、多くの開発者が日本の複雑な商習慣（消費税計算、源泉徴収、独特なレイアウトなど）に対応するためのコードやノウハウを持ち寄り、フレームワークを改善できます。これにより、最も実用的な「デファクトスタンダード」に近い帳票作成基盤が生まれる可能性があります。
開発速度の向上共通のフレームワークが浸透すれば、プロジェクトが変わっても同じ仕組みで帳票を開発・保守できるため、新規開発の立ち上げ速度が向上し、開発者間での技術の習得コストが下がります。
透明性と信頼性の向上:ソースコードが公開されるため、帳票のロジック（特に金額計算や税務処理）の透明性が確保され、信頼性が高まります。
多様な環境への対応: 商用製品がサポートしないような最新の技術スタックやニッチなOSにも、コミュニティの貢献によって迅速に対応できるようになります。
コミュニティによる継続的な改善: 一つのベンダーに依存せず、世界中・日本中の開発者がバグ修正や機能追加を行うため、品質が維持・向上し、プロジェクトの持続可能性が高まります。
OSS化は、単なる「無料化」ではなく、日本のビジネスにとって不可欠な「帳票作成」という共通課題に対する知恵とリソースの「共同投資」であり、社会全体での開発効率向上に寄与するという点で、非常に価値があります。
これ面白いな
https://togetter.com/li/2624182
IT業界の方がよく起きている、要は「完成品っぽいものを渡して「こんなふうに作って」はありかなしか」
なんだけど、ベンチャーとかで特によくある、もうできてるやんみたいな
でも細部見てみるとツッコミどころが多々あって、話を聞いてみると考慮漏れが沢山あって、この絵はどっから持ってきたの？って聞いたらパクリだと言い始め
つまりリバースエンジニアリングしてから、仕様書をおこして、再度作るみたいになる
まあ、だから「じゃあ最初から仕様をくれよ」とレベルの低いエンジニアは言い始めるんだけど
初心者が作った仕様書を元に作ったら「これ違う、アレ違う、そうじゃない」が発生して仕様変更が発生しまくって揉めるだけなんだよね
結局どっちもあったほうが良いし、やることの面倒くささはどちみち変わらない
でもモックが合ったほうが完成品のイメージのズレは減らせるからあった方が事故らんけどね
デザイナー・イラスト業界ではこれが経緯云々の話になるのは地獄だね
僕は今夜、ルームメイトがリビングで実験的にベーコンを低温調理している匂いを鼻孔の厳密な位置で嗅ぎ分けながらメモ帳を開いた。
朝は6時17分に目覚ましを止め（そのミリ秒単位の遅延は許容されない）、6時18分にコーヒーの比率を変える習慣を行い、靴下は左から右へ、座席は常にソファの北東端（座る位置は位相対称性を破らない）である。
食事は火曜日のパスタの残り物は三等分して水曜と木曜の朝食に回す。洗濯は必ず偶数週の水曜に行い、洗剤は0.8倍希釈、脱水は中速、干す向きは北向き。
ルームメイトがドアに爪痕をつけたら即座にログを取り、隣人が郵便物を誤って取った場合は「郵便誤配報告フォーム」を三回に分けて提出する。
こうした儀礼を守ることで僕の内的位相空間が安定するのだと論理的に考えている。
今日の思考の核は超弦理論と量子情報の交差点についての、かなり尖った自己流の定式化にある。
まず、僕は物理的直感を避けて抽象数学で事象を語る。弦理論の摂動系列を有限厚さの∞-圏としてモデル化し、ブレーンを対象、開弦状態をモノイド的なホモトピー演算子として扱う。
局所座標の代わりにファクタリゼーション代数を使い、スパイダー図式を経て得られる交叉相互作用を高次ホモトピー群のコハート化として再解釈することを提案する。
ER=EPRについては、古典的なワームホール＝絡み合いという語り方を離れて、僕はエントロピー・双対モジュールの同値性という言葉で捉えている。
つまり、二つのエントロピックモジュールの被覆圏と、それらに対応する重ね合わせのコボルディズム（圏論的な結合双対）を同一視することでER=EPRを圏論的に定式化できるのではないかと考えている。
これを超弦理論に接合するには、AdS/CFT 的なホログラフィック双対の場で、境界側の張力的演算子族が内部のブレーンカテゴリ（例えばフカヤカテゴリやコヒーレント層の導来圏）に対応するという見方を取り入れる。
すると、エントロピー双対モジュールの同値性は、境界とバルクの間で起こる圏の再同型化として現れ、ER=EPRは本質的に圏的ホログラフィーの一命題になる。
ここで僕が提案する小さな拡張は、量子誤り訂正符号のコード代数を∞-圏の射として扱い、その可換性条件がワームホールのコボルディズムの可逆性と一致するというものだ。
これにより、エントロピーの再構成操作がブレーン間のファンクターとして自然に理解でき、局所性の回復を説明する新しい枠組みが得られると僕は思う（これは僕の勝手な定式化で、厳密性は今後の証明を待つ）。
今日はそのメモを、黒板に書く代わりにルームメイトの背中越しにノートに書き留めた。
ところで、僕は靴の磨き方にも数学的基準を設けている（円周率の小数を用いた磨き順列を使っている）。
出かける前のチェックリストはトポロジー的順番、たとえば鍵→財布→スマホ→ペンという順序は位相連結成分を最小化するから合理的だ、と説明すると友人たちは顔をしかめるが、これを守ると予測可能性が上がる。
今夜はRPG系ではELDENRINGのビルド論とRTAコミュニティのメタ的動向を気にしていて、この作品が2022年にFromSoftwareからリリースされ、多くのビルド最適化やメタが確立されていることは周知の事実だ（初リリースは2022年2月25日）。
また、このIPは映画化プロジェクトが進行中で、A24が関与しているという報（映画化のニュース）が最近出ているから、今後のトランスメディア展開も注視している。
僕はソウルライクのボス設計とドロップ率調整をゲームデザインの位相安定化とは呼ばないが、RTA勢のタイム削り技術や周回遺伝（NG+）の最適手順に対して強い敬意を持っている。
ファンタジーRPGの装備付け（メタ）に関しては、装備のシナジー、ステータス閾値、クラフト素材の経済学的価値を語るのが好きで、例えば「その装備のクリティカル閾値を満たすために残すステータスポイントは1だが、その1が戦闘効率を%で見るとX%を生む」というような微分的解析を行う。
FFシリーズについては、Final Fantasy XVIがPS5向けに2023年6月に、続いてPC版が2024年9月にリリースされ、さらに各プラットフォーム向けのロールアウトが段階的に行われたことなど実務的事実を押さえている（PCリリースは2024年9月17日）。
僕はこのシリーズの音楽的モチーフの再利用やエンカウンター設計の比較研究をしており、特に戦闘ループの短周期化とプレイヤー感情の連続性維持について言及するのが好きだ。
コミック方面では、最近の大きな業界動向、例えばマーベルとDCの枠を超えたクロスオーバーが企画されるなど（Deadpool×Batmanの一連の展開が話題になっている）、出版社間でのIPコラボが再び活発化している点をチェックしている。
これらはコレクター需要と市場流動性に直接影響するため、収集と保存に関する経済的最適化問題として興味深い。
今日、隣人が新しいジャンプ作品の話題を振ってきたので僕は即座に最新章のリリーススケジュールを確認し、One Pieceの次章の予定についても把握している（最新チャプターの公開予定など、週刊連載のスケジュール情報は定期的に確認している）。
例えば「午後9時に彼らがカップ麺を食べる確率は、僕の観察では0.83だ。ゆえに僕は9時前に冷蔵庫の位置を変えるべきだ」という具合だ。
結語めいたものを言うならば、日常のルーティンと高度に抽象化された理論は相反するものではなく、むしろ同じ認知的圏の異なる射影である。
だから僕は今日もルームメイトの忍耐を試す微細な仕様変更（例えばリモコンの向きを30度回す）を行い、その反応をデータ化している。
さて、20時30分だ。これでノートを閉じ、決まった手順で歯を磨き、眠りの準備に入る。明日の朝のアジェンダは既に分解されているから、心配は要らない、と自分に言い聞かせてから寝るのが僕のやり方だ。
テックタッチ偏重とAI化が、国内人材募集でリクルートの稼ぐ力を縮める理由
はじめに：シンプルの代償
リクルートは「Simplify Hiring（採用を簡単に）」の名の下、求人の出稿・配信・課金をIndeed PLUSに集約して“運用の効率化”を進めている。だがこのシンプル化は、媒体（自社サイトやアプリ）が本来持つ指名検索・直アクセス・回遊・価格主導権を痩せさせ、長期的には"Minifying earning（稼ぐ力の縮小）"へ向かう。
枠売り主体の掲載課金（PPP）から、クリック課金（PPC）や応募課金（PPA）に重心が移り、媒体固有の文脈価値より入札ロジックが前面に出る。
Indeed PLUSのような配信の中枢が強まるほど、各媒体は「配信先の一つ」へと相対化される。どこに出すかよりどう最適化するかが支配的になり、媒体の独自性は埋没する。
総額（グロス）から手数料相当（ネット計上）へ寄るほど、媒体サイドの投資余力と値付け権限が細る。短期の効率は上がっても、長期の交渉力は落ちる。
自動入札・自動配信・自動生成に寄るほど、“人が作る体験”と“コミュニティ”の厚みが痩せ、「その媒体にわざわざ来る理由」が失われる。
なぜ“稼ぐ力”が縮むのか：決定的な3因子
掲載課金の世界では、読者層・編集・体験が媒体ごとの差別化要因だった。
PPC/PPAが支配的になると、媒体の違いは入札アルゴリズムの内部に吸収される。結果として、
検索面のAI要約が標準UX化するほど、ユーザーは検索結果の上で満足し、媒体ページへ降りてこない。
求人情報（職務要件・報酬・勤務地等）のコモディティ部分は上流で要約されやすく、媒体への自然流入が目減りする。
上流（検索）側の仕様変更一発で、媒体の流量と単価が振り回される体質は、自律的に稼ぐ力の対極だ。
プログラマティック配信が普及し、応募課金（PPA）が一般化すると、市場の“応募あたり相場”が可視化される。
可視化は効率を高める一方、媒体に残るテイクレートは構造的に圧縮される。
「どの媒体でも応募単価は同水準」という世界観が定着すれば、媒体固有の上振れ単価は維持しにくい。
悲観シナリオ：2025→2029の崩れ方
2025–2026：静かな痩せ細り
PPC/PPA比重の上昇により、媒体の指名検索・直アクセス・回遊・滞在といった“面の指標”が逓減。
売上の見え方は手数料型（ネット計上）に寄り、媒体側の投資余力が縮む。
代理店やATSとの関係は“ハブ中心”に再編され、媒体直販の存在感が薄れる。
検索のAI要約が求人カテゴリでも一般化し、媒体への自然流入がさらに低下。
「媒体で見る意味」を失った出稿主は、ハブ最適化＋相場のみを重視するようになる。
2028：高単価ゾーンの外部寡占
ダイレクト採用を育てた陣営（コミュニティやレジュメ・スキルの“関係資産”を保有）が高単価求人を寡占。
IndeedはSMB・ボリューム採用偏重に寄り、平均単価とLTVがじり下がる。
媒体側の編集・コミュニティ投資はさらに後退し、在庫品質の低下→単価下落の負循環に入る。
配信最適化としての効率は高止まりする一方、自社で創る需要と在庫（直送求人・会員基盤・コミュニティ）が薄く、成長の上限が露呈。
ATS連携や出稿先のスイッチングコストは低く、テイクレートの継続的圧縮が常態化。
結論として、Simplify hiring = Minifying earningが“標語”ではなく業績構造になる。
KPIで見る“崩れ”
応募単価（PPA）とテイクレート：相場露出→取り分圧縮の一方通行。
在庫品質指標（閲覧深度・保存・再訪）：編集・コミュニティ投資の萎縮とともに劣化。
「採用を簡単に」は、配信と運用の簡略化としては正しい。だがその裏側で、媒体が持つべき"面の力”（指名・回遊・コミュニティ・値付け権限）を自ら薄めていく。
上流（検索AI）と横（PPA相場）に収益が漏れ続ける構造を固定化するかぎり、Simplify hiringis Minifying earningは、挑発ではなく既定路線になる。
--
・自分の非を認めない。
・他人の成果を素直に称賛できない。
・部下や後輩の意見を聞かない。
・失敗を隠すことに労力を使う。
・自分より若い、あるいは経験の浅い人間に抜かれると露骨に不機嫌になる。
本人が無能というより、無能を増幅させる思考回路を自分で作り上げている。だから周りからすると扱いづらいし、何よりも迷惑。
たとえば俺の前職にいたAさん。
四十代半ば、肩書きは主任。年数だけは長くいるのでそれなりに社内での影響力はあるが、仕事の実力は正直平社員以下だった。
何か指摘すれば必ず「いや、俺はこういう意図でやってるから」と反論する。
実際には意図なんて後付けで、単に凡ミスを取り繕っているだけなのにそれを本人は正当化だと思っている。
プライドが高い人間は自分の間違いを認めることを負けだと考える。
その瞬間に自分の価値が下がるとでも思っているのだろう。でも現実には間違いを素直に認めて修正するほうがよほど信頼を得られる。Aさんはそれが理解できていなかった。
チーム全員が土日を返上して対応するなか、Aさんは「俺の設計はもう完璧だから」と言って対応しなかった。
結果Aさんの担当部分で致命的な不具合が出て、最終的に俺たちが火消しに回る羽目になった。本人は最後まで「これは元々仕様が悪い」と言い張っていた。
外部要因や他人のせいにして自分の正しさを守ろうとする。だがそれをやればやるほど周りの信頼は失われる。
気づいたときには孤立しているのに、本人は「俺は正しいのに、周りが理解できない」と逆ギレする。滑稽だが現場にとっては地獄だ。
さらに厄介なのは、プライドの高さを自分のアイデンティティみたいに考えている点だ。
Aさんにとっては「自分は優秀だ」という思い込みが存在証明になっていた。
だからその幻想を壊すような言葉はたとえ善意のアドバイスでもすべてが攻撃として捉えられる。
結果として誰ももうAさんに何も言わなくなった。会議では形だけ座っていて、実際には何の決定権も持たない。本人だけが俺はまだ必要とされていると信じている。
後輩は萎縮し、上司は余計な説得の時間を取られる。チームの生産性は下がりストレスは増える。Aさんひとりのためにみんなが疲弊していた。
本人が何か価値を生んでいるわけではない。むしろ周囲の労力を奪い、進捗を遅らせる。存在するだけで赤字なのに、本人だけが自分の存在は黒字だと信じて疑わない。
こういう人間はどこにでもいる。
社会人をやっていれば一度は出会うだろう。だが困ったことに本人は自分のプライドを誇りだと思っているから、改善の余地がない。
外部からどれだけ指摘しても無駄だ。むしろ「俺のプライドを傷つけやがった」と逆恨みされるリスクのほうが高い。
じゃあ、どうすればいいか。
答えは簡単で関わらないこと。
仕事上で必要最低限のやりとりだけして、それ以上は踏み込まない。
説得しようとか、教育しようとか、そんなことを考えるだけ無駄だ。
Aさんと過ごした日々から、俺はそれを学んだ。
本人の能力がゼロでも、素直に人の意見を聞ける人間ならまだ成長の余地がある。
だがプライドが邪魔をしてそれを完全に塞いでしまっている人間は永遠に変わらない。
そしてそれは周りにとっても本人にとっても不幸なことである。
そこそこ大企業に勤めてる
ソフトウェアエンジニアをしてるが、彼らはもうダメなのかもしれない。
OSが存在する時点で無駄なウィルススキャンソフトを入れさせられる。
いわゆるサーバーレスが大好きな人たちが集まって作ったゴミシステムの改修をさせられてる。
頭が沸いてるとしか思えない。。
当然NoSQLでは複雑な検索ができないので検索エンジンを使っている。。
彼ら自身が答えを出してるのに素直ではない。
なぜかgraphqlも採用している。
内部を見ても、普通にrestのコントローラーと同じ構造をしていてgraphqlのサービスに依存して返す値を変えてるだけである。。、
で、離職率が90%を超えている
擬似的にリレーションは再現できるであろうが、アプリケーション層での保証なのに問題ない顔している。
今わたしは外注を動かすためにシステムの仕様を作って、渡してる。
サーバーレスなアプリケーションでスマホアプリはそれらを呼び出している。
流石に工数見積もりができないのでスケジュール遅延する可能性が高いとPMに報告したが普通に怒られた。当たり散らされたがまあくだらないので放っておく。
上に相談したが耐えてくれとの話だった。
PMはSIer出身でこのプロジェクトはアジャイルと言い張るがガッツリウォーターフォールである。
このシステムはやばいからユーザー関連部分だけでもRDBMSに移行すべきと言ったが、工数が無いとしか言わない。
現代でソフトウェアを作る上ではもうdevops以前に協働するという基礎の方が大事である。
他社の機能をパクれと言ってもウチ独自の強みがないととか、そのアプリで出せる付加価値があると認められてから投資対象になると説明されるが、こいつらは何を食ってるんだろうか。
壊しやすく自分の手で扱える規模にアプリケーションを組んで激安で運用して当たるのを待てばいいのにそれも出来ない。
このシステムを冷静にレビューしても狂ってるのに誰一人疑問に思わない。。
上は無関心、PMは働かないでASDっぽいし人を詰める、同僚はASD
こんな魔境存在していいのか。。と疑問に思う。
