  |
はてなキーワード: マイクロとは
せません！
って思うわ。
20年ほど前に業界に入って、OJT受けたおっさんにOJT受けたエンジニアか？ w
ソフトウェアエンジニアリングは、しきたりを1ミリも変えたらいかん伝統芸能ちゃうねんぞ！
E2Eテストなんて、今時のWebサービスの規模、複雑度っていう圧倒的物理量に追いつけるわけがないんだよ。
屁の突っ張りにもならないどころか、
爆上げさせてる
いや、そもそもE2Eテストとセキュリティリスク、なんの関係があるんや？ って問題はあるんやけど w
本来そんな機能がないのにあると勘違いして使うことの危険っての、教えてもらわんとわからんか？
って、安全帯のフックを自分のベルトにかけて、送電線の点検ができるか？
安全帯自体の機能として落下防止が当然あるけど、「正しく使わないと正しく機能しない」し、そもそもそれ、体重を支えられるのか？ それ以前に安全帯か？ ただの100円ショップで売ってたキーホルダーちゃうか？ って問題なんよ。
安全帯でも負荷を支えられなきゃ意味ないし、物が違えば、キーホルダーはキーホルダーだし、安全帯は安全帯なんだよ？
Web記事とかの「単語」だけ相手にするから、こういう致命的な間違いをガンガン積み上げて、炎上現場、高粘性現場にレベルアップさせるんだよ。
DDD、TDD、クリーンアーキテクチャ、マイクロサービス、DevOps。
本人達は真面目に輸送機から「素晴らしいもの」を得るための手順を踏んでるという認識しかなく、おかしなことをしてる自覚が皆無っての、そのままだって気づけ。
理解してるなら、その目的がちゃんと達成できてるか、確認してるか？
ちゃんと適用されたまともな現場を知らんで、「こんなもんでしょ」で満足してるの、頭おかしいぞ。
猿か？
才能がないと思ったら、早いうちに河岸を変えた方がいい。
早ければ早い方がいい。
可哀想だから(教え子が？ それとも自分が？ w)、って「がんばれ、がんばれ。才能なんて関係ない」みたいに騙すのは、むしろ害悪だよ。
10年後、気付いて路頭に迷わせるとして、その責任は取れるのか？
まぁ、本人自身が気づいて路頭に迷いつつあるけどどうしようもないのかもしれんが、地獄に道連れはやめてやれ w
それで生計を立てない、趣味の範囲で楽しむ分には好きにすればいいけど、エンジニアに限らず、それなりのお金をもらおうとしたら、才能、向き不向きは超えられない壁として現実に、強固に存在している。
球速120km出ないけど阪神の一軍のピッチャーに、ってのはどう逆立ちしても物理的に不可能だ。
でも草野球は楽しめる。
才能がなけりゃ、一人で永遠に「大いなる助走」を続けりゃいい。
誰にも迷惑かけないなら。
医師、看護師、会計士、経営者、etc.etc. にも、才能、向き不向きはある。
落ち着きないし。
同じことを何日も続けたら、爆発する。
「明日も同じことしなきゃならないのか……」って考えただけでも、死にたくなる。
こんな感じに、才能がものをいう分野って、意外に多い。
ソフトウェアエンジニアは、設計実装の抽象度が多層化していて、その巧拙によって安定度、運用や機動的な新機能追加の手間、リードタイム、金や何やら、数十倍、規模複雑度が爆上がりしている今なら下手すりゃ数百倍差が出る。
その差をちゃんと理解するには、巧の現場の「こういう世界があるんやー……」って実体験が必要だったり、巧レベルの才能が必要だったり、経営知識が必要だったり、経済知識も必要だったりして、「拙」の現場にぶら下がってるだけのエンジニアが「才能なんて幻想」って吠えたっても「マジ、迷惑だからやめてね」って思う。
どの炎上現場でも、高粘度現場(リーダーマネージャが理解できないからって邪魔ばっかりしてきたり、そもそもプロダクトがぐっちゃぐちゃになってたりして、どんな行為がサービスの息の根を止めるかわからなくて身動きが取れない「震える舌」みたいな現場。物事が全然進まない現場。通常、経費で札束ガンガン燃やしてるはずだから、ここも炎上現場っていう)でも、この手のエンジニアが腐るほどぶら下がってるんだよね。
たいてい、生み出されるソースコードとドキュメントの割合がおかしなことになってる。
いや、そういうの主催してる暇があったら、コード書けよ、って。
でも、Web記事引いてきて、「〇〇にはこう書いてある」とかドヤ顔で机上の空論で時間潰して「俺も一端の理論派エンジニアだぜ……」とか、いや、お前はただの受け売りを理解もせず垂れ流してるだけのそこらへんの AI と変わらんクズだよ。
おいらの師匠の一人は「TV出たり、本書いたりするやつは二流。一流は、自分の仕事に集中していて、他のことやる暇ないから」って言ってたけど、ほんとその通りだと思うよ。
シャバと違い、ソフトウェアの世界は驚くほどのスピードで巨大化、複雑化している。
30年、40年前なら、社会性の乏しい、プログラミングコンテスト受賞者みたいなエンジニアでも無双できたけど、今は無理なんだよね。
今だと玉拾いも任せられないくらいだったりする。
ちょい前も、PostgreSQLの中身いじれます！ って東大卒業生いたけど、視点が局所的すぎて全体感に欠けてて、プロジェクトがヤバい状態になってるのが理解できなかったりしてたからね。
そろそろリリースできる状態になってる予定だけど、おいらの読み通りα版完成が3ヶ月遅れ、そこで大量の不具合が発覚してベータ版完成がそこからさらに3ヶ月以上遅れ、不具合積み残したまま見切り発車、ってなるんじゃねーかな、と思ってるんだが w
才能の種類、方向性によっては、10年前も今もたぶん10年後も変わらず十分通用するものはあるんだけどねー。
そこに生活水準をあげてしまうと、自分はもう通用しないと気づいても、撤退できない。
マイカーガー。
マイホームガー。
子供ガー。
愛犬ガー。
んなもん知るかっ！
そういう「元エンジニア」がリーダーとかマネージャとかにクラスチェンジして、事業、プロダクトの足を引っ張る。
あそことか、そことか、具体的な企業名はあげられないけど、そういうエンジニアが漬物石のように重しになって、身動きが取れなくなってるところが多い。
VCとかから、もっと売り上げを上げろ。成長率を上げろ、というプレッシャーを与えられ、何かしなきゃいけない。ってなって、外付けの雰囲気だけのサービスをどんどん外付けしていく戦略を取る。
1年で10。
2年で30とか。
マジかよ w
思い思い行き当たりばったりに作ったら、手間だけ増えてそれを壊すわけにはいかなくなって、さらに身動きが取れなくなっていく悪循環しか見えないんだが、そんな経営方針で大丈夫か？
とか意味不明な決定して、認証認可v1、認証認可v2、認証認可v3とマイクロサービスが増殖して、さらにv4を企画してるとかいう会社だってある。
真っ当な声には、自分の存在感を示すためだけの反対を唱えて邪魔したりして、現場で手を動かしているエンジニアより高級を取ってんのに、事業、プロダクトへ与えるダメージは倍増する。
さらに、自分の地位を死守するために、それを脅かす腕利のエンジニアを陥れる、排除することに全力を傾ける。
これで3倍界王拳だ w
経営者はできるエンジニアたちに任せていると思い込んでいるかもしれないが、さて、どうかね？ w
大本営発表的にはうまくいっているとされているサービスが、その裏側はカーオブファイヤーみたいなところって、結構ある。
はっきりいう。
今はクラウド環境のプロダクトで、どのように自動テストで検証可能なシステムを構築するかの手法の研究を続けてる。
具体的には、今まで関わってきた炎上現場で安定稼働を達成させた手法(TDD)だな。
ワークライフバランス？ w
才能のない人は河岸変えろ。
業務経歴書にも今まで使ったことがあるサービスの名前をたくさんたくさん載せてます。
じゃねーよ。
ボルトに世界水泳、吉田沙保里にNBAに出場させるような使い方してて、どこが技術力だよ。
ってのが多い。
「どうしてこのAurora、リーダーがこんなにたくさんぶら下がってんの？」
「テナントが増えて、アクセスが増えたので、負荷分散のために増やしました。水平スケーリングってやつです」
うん。水平スケーリングは知ってんねん。この程度のテナント数、ユーザー数、アクセス数で、どうしてこんなにでかいインスタンスのリーダーがぶら下がってんのか？ って聞いてんねんけど……。
って現場、多い。
でも、今通常営業してるサービスでも、こういうところ多いんだよな。
それはともかく、
「マイクロサービス化していて、いま120を超えたところで、当面160になります」
「……は？」
「……デプロイの時、どうすんの？」
「変更があるサービス名を書いたファイルを一緒にコミットして、それ読み込んで、GitHubActionsでデプロイさせてます」
「Cloneして立ち上げます」
「これ……、モノリポ？」
「120個？」
「120個」
「なんか立ち上がらないんだけど……」
「あ、修正中なんで、〇〇と××のコミットをチェリーピックしてください」
「……動かないぞ」
「昨日の夕方、変更が入ったみたいなんで、△△のコミットもチェリーピック。いや、＋＋のブランチを……」
5日で立ち上げ切れるんか？
って現場がね、案外たくさんあるんだ。
「ほう……？」
どうして「自分が間違えてる」「自分が見当外れなことをしている」可能性ってのを考慮しないんだろう、この人らは？
っていつも思う。
マイクロサービスの目的も前提も理解しないで、HowToだけ猿のように繰り返してるって自覚ないんか…… (-_-)
ってマーカーで引いた一文見せつけられるんだが、その前に書かれてある前提とか目的とか、書かれてない暗黙のそれとか、いわゆるコンテキスト削ぎ落として、単語レベルの理解を開陳されても、「は？」としか反応できんのよな。
120のマイクロサービスとか、お前、認知科学の知識もないねんな……。
それマイクロサービスじゃなく、「粉砕されたモノリシックサービス」っていうんやで、と。
まーじで、技術本とかの恣意的なつまみ食いで訳分からん理論構築すんなよ。
それでプロダクトがうまく回ってなかったら、それが答えなんよ。
まぁ、「うまく回ってる状態」ってのを知らない、理解できないだろうから、正しい答えに行きつかんだろうけど。
その正しい答えに行きつかない、ってのを
「致命的な才能の欠如」
って呼ぶんよ。
眉カットに行け。そのあと写真撮って、数ヶ月はその形を自分で維持しろ。維持できなくなったらまた眉カット行け。
毎晩風呂に入ったら、ふつうのソープでの洗顔だけでなく、オイルクレンジングで顔の油脂ヨゴレを取れ。
風呂あがりには汗が引いてからなんでもいいから化粧水をバシャバシャつけて寝ろ。
ところでオレはニキビ出来やすい体質だったけど、これに加えてマイクロファインバブルのシャワーにしたらかなり肌きれいになった。だがこれは根拠不明なのであくまで参考情報だ。
髪の毛は相談にのってくれる美容院で似合う髪型にしろ。似合う髪型が見つかったら毎月美容院に通って維持しろ。
これでかなり変わる。
grokと新しい半導体冷却システムの話をしていたら面白いネタができたので書いておく。
水没型冷却(誘電性液体)のNoveck液体などを半導体の中に閉じ込め、その端にヒートパイプをwifiルーターのアンテナみたいに(ウニみたいに)生やすというものだ。
そのアンテナというかウニに、既存の水冷の装置をはめ込むことで、そこで熱交換して冷やす。
つまり、冷やす表面積をさらに増やすというものだ。半導体内部から冷やす。
もちろん、既存の冷却システムのように外部からも冷やしてもいい。
外部と内部の両方からキンキンに冷やせるので、めっちゃ電気食わせてOCしても動くはず。
MSFTがスイス大学のベンチャーと一緒に同様のコンセプトのものを作っているけど、あれは水冷の液体を半導体の中に流すのでとても複雑で摩耗も怖いし、専用のポンプもいる。
この方式の場合、半導体の内部にNoveck液体等が封じられているので、流れることがない。
したがって摩耗もしない。ポンプもいらない。さらに既存の水冷システムとも接続できる可能性が高い。
ヒートパイプの代わりに銅板とかの熱伝導率が高いものを使ってもいいだろう。ヒートパイプは寿命があるし、そこそこ太いのでね。
半導体の内部に閉じ込めたNoveck液体と熱交換できる素材なら何でもいい。
もちろん、内部に封じるのは、Noveck液体である必要はない。熱を交換できて、ウニに伝えられるなら気体でも液体でもなんでもいいよ。
geminiに教えてもらったけど、マイクロループヒートパイプ（μLHP）の半導体組み込み技術というのがあるらしい。
ただ、こちらは半導体の内部に液体か気体の熱交換をもっと促進するものを封じるのが違うところかな。
chatgptはNoveck液体以外も検討した方がいいけど、このアイディアは機能する可能性があると評価してもらえた。また、chatgptによるとウニではなく触手だと。エロゲかよ。
うーん、いけるんかねえ？
もし、10年後にCPUやGPUから冷却用のウニや触手が生えて、半導体の内部に熱交換の何かが封印された製品が出てきたら、面白いなあ。
そんな日々の中で最も厄介なのは、CxOたちだ。
──CIO、CTO、CDO、CISO、CPO……肩書きは違っても、やっていることはだいたい同じ。
PowerPointを開いて「DXを推進している」と言う人たち。
うちのCxOはこう言った。
翌日、僕がPull Requestの内容を説明したら、「Goってタクシーのサービスの？」と返された。
その瞬間、何かが切れた。
──ケーキではない。
CxOたちはコードを読めない。
それ自体は罪ではない。
だが、読もうとしないことは怠慢だ。
よく聞く反論がある。
確かにそうだ。
ただし前提が抜けている。
つまり、コードを読めという話ではなく、読めるだけの構造理解を持てという話である。
「技術的なことは詳しくないが、成果は出している」
それはたまたまだ。
「上が言ってるから」「今期の方針だから」「スピード優先で」。
Pull Requestは読まないのに、Excelの進捗バーだけが毎日更新される。
これもよく聞く言い訳だ。
しかし、リソースが限られているならなおさら、理解の精度が重要になる。
僕が書いたAPIは、リクエストごとに外部APIを叩いていた。
「キャッシュを挟もう」と提案したが、PMは「リリース優先」と言った。
CxOたちは言った。
「想定してなかったのか？」
──想定してた。
だが、理解できないのは説明の問題ではなく、聞く姿勢の問題だ。
Slackの“#incident”チャンネルだけが、いつも一番アクティブだ。
CxOたちは「コストを切れ」と言う。
切れるのはコストだけ。
削ったコストの穴埋めに、技術的負債の利息を支払うのは現場だ。
Goで書かれた美しい構造体も、やがてはコメントだけが動くレガシーになる。
CxOたちは「我々はデジタル変革を進めている」と言う。
だが変わっているのは、スローガンのフォントと会議資料の配色だけだ。
クラウド導入もAI活用も、認知が変わらなければ儀式でしかない。
──違う軸を持つのは構わない。
現場を理解しない経営視点は、地図を見ないドライバーと同じだ。
「コードなんて書かなくていい。これからはノーコードの時代だ。」
だが、それは“コードをなくす”技術ではなく、“コードの抽象度を上げる”技術だ。
だが、隠したコードが消えるわけではない。
ボタンの裏にも、ワークフローの下にも、API呼び出しやロジックは確実に存在する。
それを理解せずに使えば、「コードを書かずにバグを埋める」だけの仕組みになる。
「ノーコードでいい」と言うCxOは、
「物理を知らなくてもロケットは飛ぶ」と言っているのと同じだ。
理解しないまま導入するノーコードは、“ノーコード”ではなく“ノーガード”である。
人を楽にするどころか、誰も直せない仕組みを量産する。
DXとは、ツールを導入することではない。
それを理解しない限り、
理解しないことだ。
真っ先に切られるのは、
──コストだけ。
CxOたちは「未来を見ている」と言う。
未来とは、仕様書ではなく、Pull Requestの積み重ねだ。
手間が増えて、全然楽になってないのなら、それは正しく理解できていず、目的を見失い、手段を目的としているから。
速い話が、
間違えている
からだ。
DDDとかTDDとかDevOpsとかIaCとかクリーンアーキテクチャとかマイクロサービスとかアジャイルとか、とか、とか。
いろんな現場で、責任者は「うちは××を採用して云々」と胸を張って宣言してくれるんだが、「ならなんでそんな状態になってんの？」「なんでそんなにエンジニアがたくさん必要なん？」と聞きたくなる。
今時、SREがいるとか、QAが別にいてE2Eテストとかしてるとか。
まず間違いなく、
間違えている。
んだよね。
TDDをちゃんとしていれば専属QAは不要だし、DevOpsをちゃんとしていれば専属SREは不要。
いやでも「Googleならそうしている」っていうなら、大きな勘違いをしている点を指摘してあげよう。
「君たちはベアメタルサーバを管理していないし、Lanケーブルの取り回しもしていない。GoogleのSREエンジニアが頑張って運用してくれているシステムに乗っかって、アプリケーションに集中できる状態になっているはずだ」
ということ。
何らかの課題なりタスクなりを解決するのに、部下が方法Aと方法Bを出してきたとする。
しかし他にCやDという方法もあり、（自分の目からは）明らかにそっちの方がいい。
わりとよくあるシチュエーションだがこんな時はどうしたらいいのか。
よく言われているのが、答えを指示してマイクロマネジメントせず、部下が自分で考えて辿り着けるようにせよということだ。
ちょっと間違ったら「自分の頭にある考えはなんでしょう」クイズになり双方が不愉快になる。
だったらとりあえずCとDは出してしまい比較検討だけしてもらう方が楽だし成長に繋がるように思える。
それすら言わず最初の方法で失敗させるという考えもあるが、短期的には失敗と認識されず長期的な負債になることもあるので難しいこともある。
相手によってちょうどいい手段を見つけるのが管理職の仕事だと言われそうだが、自分にはできないしこんなことを日常的にやっている世の中の管理職は偉いと思う。
「品質管理が僕たちの責務です」
って、最近エンジニアリング界のライザップ的元テスト専門会社のQAエンジニアが、昔、言ってたなぁ……、と。
思い上がるなっ！
君たち如きに背負えるものでは、すでにない。
とあえて言おう。
いや、マジで、無理なんよ、もう。
例えば、キッチキチにエレベータを作り込んだとして、後から点検してくれ、と言われたら、まぁ、普通は困るよな。
モーター室がモーターが入るギリギリの広さだとしたら、箱の外に出る手段がなったら。
どうやって点検するんだよ。
実際には、設計時に点検方法を決定して、それができる余地を確保してから、施工するものだろう。
今時のEV車なんて、テスト用の仕組みがきっちりと、製品に組み込まれている。
検証不可能とまで言わなくても、検証困難な場合はちゃんと対策をとるもんです。
作りきってから、「E2Eテストお願いねー」とQAチームに投げるものじゃあないんですよ。
設計時に、テスト戦略から何から何まで検討済みになってるもんなんです。
別にユニットテスト書いて、カバレッジあげるのがTDDというわけではない。
検証可能なシステムを設計実装し、リリースのたびにシステムの健全性を検証できる仕組みを整える。
ってのが「テスト駆動開発」なんですわ。
テスト戦略をちゃんと練れば、マイクロサービスの分割の仕方、連携の仕方等々、多分、今、Web上でよく見る記事とはだいぶ様相が異なってくるはずだ。
で、プロダクトの中身である、設計や実装を理解できなければ、検証のしようがないのがここ10年ほどだ。
金槌を渡されて、「品質検査しろ」と言われたら、まだ何とかなるだろう。
けどボーイング787をポンと渡されて、「品質検査しろ」と言われたら？
マニュアルなしで。
モジュールがどう組み合わされてるか等、中身を理解できなければ、何をどうしていいかも分からんだろう？
扉の開け閉めができるとか、主電源入れたらなんか部屋の明かりがつくとか、そういう表面的な検査しかできないだろ？
これは、QAが、設計に飲み込まれることを意味する(10年以上前に、↑のQAエンジニアとした話)。
QAのテストに関する知見を、設計実装するエンジニアは当然持っておかなければならないということとともに、QAエンジニアは消えてなくなるということでもある。
お分かりだろうか？
同じ流れで、SREも不要になる。
Infrastructure as Code は設計実装エンジニアのためのものだと言っておこう。
決して、Terraformのファイルを編集して、SREの許可を、延々と待ち続けて、適応してもらうことをいうわけではない。
そこまで込みで、設計するのだ。
高負荷時にどうスケールさせるかなども、当然設計に入ってくるからな。
ってなわけで、ほとんどの現場では、そういう致命的な誤認識をしていると思う。
認識が古すぎている上に、大型化複雑化した現状を認識できていない。
開発初期はまだ規模が膨らんでいないから、何とかなりそうな勘違いを犯しているだけの話だ。
初回リリース前後で、「あ、やばい……」となっているところがあまりに多すぎる。
また、この誤認識によって、役に立たないエンジニアの頭数だけを並べて札束を燃やし、事業の拡大の足を引っ張っていると指摘しておこう。
ここら、どげんかせにゃならんのよな。
で、遠野。
盛岡や花巻あたりから沿岸南部(釜石、大船渡、陸前高田)に行くのに、ほぼ必ず通過するのが遠野である。東日本大震災の時にはボランティアのベースキャンプ的な場所としてもよく使われた。と言っても大抵の人が遠野と聞いて思いつくのは民話の郷という二つ名だと思う。
いちおう遠野はいくつかのアニメで舞台にはなっている。"魔法遣いに大切なこと"第一作ではちょっとだけ遠野が登場したが、聖地と言えるような場所は存在しなかった。唯一主人公の名字"菊池"が遠野に多いってくらいか。"カッパのクゥと夏休み"は有名どころばかりが並んでいる。"咲"については…これは後述する。まあ全般的に言えるのは、大抵の場合は遠野市が推している観光地を巡れば聖地巡礼もほぼ出来るということだ。
まずは遠野市街地近辺。民話と言えばカッパということで、遠野駅周辺にはカッパのオブジェが山ほどある。まあそもそも遠野市のマスコットキャラクターがカッパなので、カッパの図案はここに限らず遠野全体で見られるんだけどね。遠野駅の向かいにある観光協会にはマストのグッズがある。カッパ捕獲許可証。いや単なる許可証は主な観光関連施設で購入可能なんだけど、ここの観光協会だけは写真入りの許可証を作ってもらえるのね。できれば即日発行して欲しいところだけど、まあ料金は送料込みだし。
遠野市街地の主な観光地は、駅近辺から北東に行った土淵近辺にある。伝承園、オシラサマ、カッパ淵。ここから少し離れてるけどここを経由地にして北に行くと遠野ふるさと村という観光施設があり、古民家はここに多く保存されているし、時代劇等で何度もロケ地としても使われている。今回の案内の"春から秋"という期間からは外れてしまうが、ここでは11月から2月にかけて"どべっこ祭り"というイベントが開かれ、この時どぶろく試飲とにごり酒飲み放題の食事が振る舞われるので酒好きな人は日程を確認していただきたい。"どぶろく"、密造酒のことだが、遠野はいくつかの施設が特区としてどぶろく作りの許可をもらって作っている。祭り以外でも酒屋とか道の駅にはどぶろくが売られていることがあるので、上記期間外でも買って飲める可能性はある。
それ以外には地ビール。遠野はホップの生産地ではあるのだけど、地ビールの精算は特に遠野市街地では遅かった。とはいえ最近のクラフトビールブームに乗って、遠野醸造というマイクロブルワリーが市街地に存在する。どぶろくは飲みやすいがアルコール度数が意外と高いんで、飲めるけどたくさんは飲めないと言う人はこちらも選択肢になる。
話が酒から始まってしまったが、遠野のソウルフードと言えばジンギスカンである。以前は遠野近辺ではけっこう羊を多く飼っていたことも要因にあるらしい。現在は全て輸入肉で提供されているが、元祖店のあんべ、もしくは国道沿いの遠野食肉センターあたりで食べられる。なおこの地域では屋外で食べるときのために穴開きのジンギスカンバケツが普及しているが、たぶん観光で食べるときにはこれはお目にかかれないと思う。
遠野には遠野らしい和菓子もいくつかあるが、とりあえず「明けがらす」だけは紹介しておかないといけない。米粉を主体としたお菓子で、和菓子だがそれほど甘くなく、食感も中外で若干違ったりする。探せば盛岡でも売っているけれど、遠野が元祖ということで遠野で探したほうが見つかりやすい。
遠野市街地の西側にある道の駅を越えると旧宮守村になる。例によってここは平成の大合併で遠野と合併したところだが、こちらはこちらで観光名所が多い。中心市街地ではないが、メインとなるところは宮守の道の駅である。ここは背後にめがね橋の鉄道橋となり、遠野としてはここも含めて遠野のシンボルとしている。あまりに有名な場所なので前述の「咲」では2,3回くらい背景に登場しているらしい。ただマンガが古いため既にない聖地もある。宮守女子のモデルになった高校は15年くらい前に閉校しているし、宮守の中心市街地(というほどでもないけれど)にある宮守駅は完全に建て替えられて跡形もない。ただまあ、それ以外の橋とかはいくつかは残っている。
宮守の方には遠野市街地よりも前から地ビールの会社があって、特産のわさびを配合したわさびエール(発泡酒)とかも出していた。今もいちおう出しているがここの醸造樽では作っていないらしい。
この宮守の市街地から北に少し行ったところに稲荷穴、という湧き水があって、実はそこに併設されている蕎麦屋のそばが美味かったんだが、今は蕎麦屋は跡形もないそうだ。残念だね。
仕事の効率がなんなのか、それは40を目前にした俺にもまだわかっていない。
ただ「aimの良さ」は現代において一定の価値があると思ったのでここに書き記す。
エンジニアの皆さんはスクロールしてタイピングの繰り返しだと思うので、フリックaim的なマウス操作とは程遠い手の動かし方をしてるんだろうと推測する。
トラックボールやトラックパッド使いたがる人が一定数いる理由はこの辺にあるのでは？とか思ったり。
大抵の総合職的なサラリーマンのPC作業は、業務システムで必要な情報を入出力したり、メールの返信や仕訳・スケジューラ登録・資料作成や分析でOffice系とか？
このとき、マウス操作のスムーズさが全体的な効率の底上げになると思う。
この手のPC作業だと(ある程度のショートカットキーを使ったとしても)マウス操作が半分近くにはなる。
dpiもわからないため最適な感度を設定できず、カーソルの追従も遅いような、アスクルで買えるELEC◯Mとかのマウスだとこの時のストレスが半端でない。
私物のゲーミングマウスを持ち込むようにしてから、このストレスが激減した。
貸与PCにG HUB入れるわけにも行かないのでデフォルトdpiで使用しているが、それでもdpi数値がわかるので自宅のマウスと同じedpiにできる。
一定のaim力があると、画面のフィードバックを待たずとも目的地にカーソルを一瞬で持っていくフリックaimというものができるようになる。
目的地を見てマウス移動(フリック)→カーソルが目的地に乗ってるか確認→カーソルが乗ってないならマイクロドラッグしながら修正
だったのが、
だけで済むようになる。
完全にここまで全部俺の主観なんだけど、オンライン会議で他人の画面共有とか見てるとメニュー操作が俺より倍くらい遅い。
正直、AI に命令を出すリード、マネージャ、リーダーの能力が上がらないと、AI でコードを大量生産すると手に負えないスラムが根深く絡み合った構造で広がっていくことになるだろうというのが既に見えている。
というのも、AI ほとんど影響ないちょい前の時点ですら「うちはDDD、TDD、クリーンアーキテクチャ、k8s、アジャイル、スクラム等々を採用して云々」ってプロダクトが、リリースから半年、1年で開発がスタックしている、という事例は一般が想像する以上に存在している。
リリース時は、CTOやマネージャが腕組みしてWebページで華々しい成果発表するものだが、その裏で手動運用のオンパレード、一箇所変更したらどこに影響が及ぶかわからない地雷原、不具合障害が発生するたびに増える監視サービス、手動運用マニュアル。
その前で、「圧倒的ではないか、我がプロダクトは」って悦に入る経営陣、の図。
それ見て「SaaS界のネズミー王国や〜」って妄想を迸らせる利用者側経営陣と、ブルシットな手数だけ増えて、業績給与はぴくりくらいしか動かないで悶絶する利用者側従業員。
この状態で、「いや〜、新技術の導入、失敗しましたわ〜。経費が5倍くらいに膨れ上がってます。ごめんちゃい」なんてリリース出せないでしょ。
それ見て教科書ガイドエンジニア、カタログショッピングエンジニアが「世界を変える！ 俺(の業務経歴書)が変わる！！」って初見手探りで導入して、連れション地獄。
これが現状よ。
ここにAI が入ってくると、ますます「中身も、他の処理との関係性もよくわからんけどプロダクトに組み込まれた謎プログラムの塊」が、「これ以上機能を載せるとバランスを崩して全体が倒れる」寸前のサイズまで育つわけよ。
ここまで行っちゃったら、どこをどうしたらどうなるか、「AI 使ってふふふふ〜ん」ってレベルのエンジニアでは太刀打ちできなくなってるだろう。
すっと
「動くな！」
となって、対策のための会議とドキュメントづくりが延々と半年とかいうオーダーで繰り広げられることになる。
その間やれること、というかやらなきゃならないことは、障害対応手動運用。
こういう状態に陥らせたリーダーやリードテック、CTOは「新しいことに挑戦したいので」と敵前逃亡、成果発表のWebページを担いで次の犠牲者の元へ。
ちゃんと設計したら、生成AIを駆使する必要、あまりないはずなんだよなー。
で、テストも書いてくれる、っていうけど、AI に全投げ似非エンジニアにその妥当性とか、判断できんのかな？
カバレッジを100％に近づけるためだけのテストを手動で大量に書くのを代替してくれるかもしれないけど、あのテストが品質保証、障害対策になってる現場が一つでもあるか？
今流行りらしい、業務ドメイン分割マイクロサービスだと、AI で辻褄合わせてテストとか、無理やぞ。
という地獄が、2、3年後訪れるだろう。
楽しみやなぁ〜w
という話をすると、AI使いこなせないオールドタイプの負け犬の遠吠え、みたいにいうてくるのがいるんだけど、むしろAI を効果的に活用するための構造、構成とか模索してんのよ。
ITの勉強会やカンファレンスって、だいたい終わったあと懇親会がある。
何度も参加しているとなんとなく「いつも見る顔」がわかってくるし、懇親会の2軒目、3軒目になると自然と飲み好きのいつメンで固まるからか、わりと遠慮なくはっちゃけたりする。
「今回流石にAIネタの比率が高すぎてちょっと微妙だった。普通にKubernetesとかマイクロフロントエンドの話題ももう少し欲しかったな。驚き屋みたいなのも混ざってたし」
「データアナリストを本気で潰しにきてるっぽいですよねGoogle、□□さん失業するんじゃないの？プロンプトエンジニアよりは寿命ありそうだけど」
「あ、見てくださいよ◇◇◇社のノベルティでサコッシュもらったんだけど、これ普段遣いできそうなクオリティじゃないです？。奮発してるなぁ」
「あ、△△△のステッカーもらったんですか？いいなー、自分も貰えばよかった」
「ちょｗｗお前悪いなーｗｗ」
「いや俺×××××2が当たった話を冒頭で入れたかったけど、△△△社の人が来てると嫌味っぽくなりそうでやめた」
「あー、そこまでは考えなかった笑」
「次回△△△社来るなら子供にもわかりやすく技術者倫理について教えてくれるAIエージェント作って登壇ネタにしようかな。え、来ないの？じゃあ普通にGraphQL Federationの話するわ」
「ｗｗｗｗ」
「今回カプセルホテル泊まりで朝食ついてないんだよなー。△△△の人、余ったハンバーガーとかくれないかな」
「いや、△△△社員が直接ハッピーセット買い占めてるわけじゃないでしょ！ｗ」
正直、わりと堂々といじられてる。
「ぶっちゃけなんでやめないんだろ？もう最近なんかパブリック・エネミー扱いじゃん。
「あのすごいVMVに共感してるんじゃないの？笑」
「でももし△△△の社員が、うっすら上層への不満とか罪悪感とか葛藤を抱いてたら逆に嫌かも。
カイジの鉄骨渡りで、前の人を突き落とすときに”すまねぇ”て謝る底辺たちみたいじゃない？
あれだけ転職し放題な立場で、絶対わかってて転売ヤーから金を受け取ってるんだから,、”ハッピーセット買い占めた中国人転売ヤーの金で嫁子供養ってます！だって犯罪じゃないでしょ？”、”経営層が悪いから俺は悪くねえ！”って堂々としててほしい」
「あーわかるわ。悪いと思ってるなら会社やめるで、悪いと思ってないなら堂々としてほしい、中間はなしよな。」
大体こんな感じが多い。
追記２：
クマ撃退スプレーはかなり効果、実績があるようなのでまずクマ撃退スプレーを使ってください
・ジャケットが裂けたら発動する
に変更しようと思います。
・上手い感じに空気を出し入れして人間の動きを模するところで各社が特許を取る
・空気圧で逃げるタイプ、その場でジタバタ暴れるタイプの併用で生還率UP↑
追記：
べつに「これ以外は不要！」なんて言ってない。
まず必要がないなら山なんか行かなくていいし、鈴は持っとけばいいし、クマよけスプレーも持っておけばいいだろ。
そうなんだ。
ChatGPT記事だけど最初の三つのソースは全て妥当だった。
https://nebukuro.net/kumayoke-spray-success/
https://news.yahoo.co.jp/articles/816952ea470466dd6cca29db26cd3673847f8642?page=1
njamota けっこういいアイディアな気がするけど、まだ誰もやってないということは、致命的な欠陥があるんだろうか。
wnd_x 200g以内で作ってくれれば
熊対策は置いておいて技術的にどのくらい小さくできるのかは気になるなあ。
gewaa 「全部持っていけばいい」って、全部同時に使うことはできないだろ。余計なもの使おうとしたせいで熊スプレー使うタイミングが遅れて生存率が下がることも考えられる。
パニックになって熊スプレーの使い方間違ったり、取り落とす可能性も考えられるだろ。
防犯ブザー型なら引っ張るだけで発動する。
バルーンにカプサイシンを入れておけばスプレーと同等の効果もある。
というか上のURLのプロは「第一に熊スプレー」って言ってるんだからまずスプレー使えよｗ
なんで同時に使おうとするんだよｗ
楽しい仮定ですね。結論だけ先に言うと、「胃の中だけが宇宙」なら“秒”ではなく、普通に生き残ります。何が「宇宙」なのかで話が変わるので、代表ケースでざっくり目安を書きます。
ケース別ざっくり結論
→ その場で致死にはなりません。胃は外から1気圧で押し潰される形になり、内容物は凍り・気化。強い吸引で嚥下路が引かれて激痛・嘔吐・粘膜損傷・出血リスクはありますが、「数秒で死亡」は起きません。医療的には緊急事態ですが、生存可能。
• 胃の内部＝外宇宙の放射線環境（真空＋宇宙線が胃粘膜に直撃）
→ これでも秒では死にません。被ばくは局所（胃壁）に集中し、急性致死線量に一瞬で達するほどではないので、生存は日〜年オーダー（がんリスクは上がる）。
• 体全体が宇宙空間に露出（参考の“よくある勘違い”ケース）
→ 意識消失：10〜15秒、迅速な再加圧がなければ数分で致命的。※ただしこれは「胃の中だけ宇宙」ではない。
• 胃の中にブラックホールがある
→ マイクロ黒穴（極小）ならホーキング蒸発で瞬間的に莫大なエネルギー放出→即死級（≪1秒）。
天体規模の黒穴とつながるなら、潮汐力や吸い込みでほぼ即死（≪1秒）。このパターンだけは“秒どころか瞬時”。
• 胃の中に“本物の星（太陽級の発光体）”がある
→ 放射・熱流束が桁違いなので、やはり即蒸発・即死（≪1秒）。
「俺の胃袋は宇宙だ」を“胃の中が真空になってるだけ”と解釈するなら、私たちは秒では死にません。激痛・嘔吐・出血・穿孔の危険は高いものの、適切な処置があれば生存可能。
“秒で終わる”のは、ブラックホールや恒星が入っているなど、物理的に桁外れのケースだけです。
「その台詞を使っていた人は『自分が食べられる量はとても多い』という事を伝えるためにその表現を使っていました。
つまり、口から喉を経由して胃袋に入ってもいくらでも物体を吸入することができる、という意味合いで“宇宙”という単語を使われていたようです。
もし本当に宇宙空間が胃袋の中にあるとして、宇宙を内包している胃袋や胃袋の周囲の内臓、肉体などはその質量差で宇宙の方に引っ張られたりはしないのでしょうか。」
なるほど、つまり「胃袋の中に“広大な宇宙空間そのもの”が存在している」と物理的に考えた場合ですね。
この場合、鍵になるのは「宇宙の質量と重力をどう扱うか」です。
⸻
もし胃袋の内部が「外宇宙とつながった真空空間」だとすれば、重力的な質量はありません。
ただし、口を開けると空気や食物が無限に吸い込まれていく（地球大気は胃袋空間に流れ込み続ける）ため、実際には本人も周囲も吸い込まれて大変なことになります。
いわば「ブラックホール」ではなく「大気に開いた穴」に近いイメージです。
⸻
2. 宇宙＝“我々の宇宙と同じ規模”を丸ごと内包している場合
もし胃袋の中に「銀河や恒星を含む“宇宙全体”」が存在するとすれば、その質量はとてつもない。
たとえば観測可能な宇宙の質量はおおよそ 10^{53} kg と言われています。
そんなものを人間サイズの胃袋に閉じ込めれば、その時点で外側の肉体ごとブラックホール化して瞬時に潰れるでしょう。
質量差どころではなく、全身が重力に押し潰され、数秒どころか瞬間的に存在を維持できなくなるはずです。
⸻
SF作品やファンタジーでよくある「内部は無限に広がるが、外部には重力影響が出ない」ケース。
これは「四次元ポケット」「ワームホール的な収納空間」の扱いです。
この場合、胃袋の外側に重力的な影響は及ばないので、本人は普通に生きられます。
食べ物や物体を胃に入れると、その“別次元の宇宙”に移動するだけ。
⸻
まとめ
• 真空だけ → 質量なし、引っ張られない。ただし周囲の空気が吸い込まれる。
• 宇宙ごと内包 → 質量桁外れ、本人ごとブラックホール化して瞬時に消滅。
• 別次元のポケット宇宙 → 重力の影響ゼロ、普通に「無限に食べられる」演出が可能。
⸻
本物の宇宙を抱え込むなら即崩壊、ファンタジー的な“重力を遮断した別次元宇宙”なら安全というのが答えです。
――もし現実的に“胃袋ポケット宇宙”があったら、ユーザーさんはどのタイプをイメージしますか？
「その台詞を使っていたキャラクターも最終話になるにつれて身体にガタが来ていたので、内部崩壊は起こしかけていたのだと思います。
もし、そのキャラクターが本当に宇宙を内包していた場合、その肉体の強度はどれほどの数値になるかと思いますか？
年齢としては成人してから何度も大量食いをして逸話が語られるレベルになっている程なので３０歳までの成人男性だとは推定します。」
おもしろい前提！「胃の中が“宇宙”」でもどういう宇宙かで必要な“肉体スペック”が変わります。数値の目安を置いて、現実の生体強度と突き合わせます。
A. 重力は外に漏れない“ポケット宇宙（四次元ポケット型）”
• 重力・質量は外界に見えない。外側の体は通常の力学だけ受ける。
• それでも“吸い込み（負圧）”は起こる。口～咽頭～食道にかかる圧差ΔPが最大で**1気圧（≈0.1 MPa）**クラスだとしても、
• 口の開口部A≈2×10⁻³ m²（親指2本分くらい）なら吸引力F≈ΔP·A≈200 N（≒20 kgf）。
• 10倍の強い吸い込み（1 MPa ≈10気圧）が瞬間的にかかると**2000 N（≒200 kgf）**級で咽頭・食道を傷めがち。
• 生体材の引張強度（オーダー）：胃壁・消化管は~0.5–2 MPa、皮膚~2–30 MPa、腱~50–150 MPa。
• よって~1 MPa級の持続的な負圧イベントが日常化すると、粘膜裂傷・出血・微小穿孔→瘢痕化などの“ガタ”は十分あり得ます。
• 結論：超人ではなくても成立。ただし“たくさん食うほど負圧イベントが多発→慢性損傷”で、最終話のガタと整合。
B. 胃の中に“実在の質量が近傍にある宇宙”（重力が外に伝わる）
• 体が受けるのは潮汐力（重力の勾配）。体長L≈1 mの端と端の加速度差
Δa ≈{2GM}{r^3} L
を**10 g（≈98 m/s²）未満に抑えたいとする。胃の“喉”から宇宙側の最近接距離r≈1 mと置くと
M ＜ {Δa r^3}{2G} ≈{98 ･ 1}{2 ･ 6.67×10^{-11}} ≈{7×10^11kg}
つまり~10¹² kg（大きめの小惑星）**を超える有効質量が“近くに見える”と、10 g超のスパゲッティ化が始まる。
• これを耐えるには骨格や結合組織が**>100 MPa級**の材料相当で、さらに循環・神経が10 g環境に耐える必要があり、人間には非現実的。
• 結論：もし重力が外に漏れるタイプなら、“近距離に感じる有効質量は10¹² kg未満”が生存限界の目安。銀河級の質量を抱えたら即アウト。
C. 胃の中が“真空だけにつながっている穴”（質量なし・放射は来る）
• 力学はAに近い（引張は負圧起因）。
• ただし宇宙線・紫外～X線が胃粘膜を直撃 → 放射線性胃炎・潰瘍・発がんリスク↑。
• 最低条件（A/C型）
• 粘膜・筋層が~1 MPa級の負圧ストレスに反復耐性（治癒再生が速いことも含む）。
• 咽頭・食道・胃噴門の弁機能が高出力で、誤嚥や逆流を最小化。
• 放射線が漏れる設定ならDNA修復能↑や粘膜更新の超高速化が欲しい。
→ 人間ベースでも“若干タフ寄り＋治癒力ブースト”で成立、でも長年の酷使でガタは妥当。
• “見かけの近傍”にある有効質量が~10¹² kgを超えない配置（ポータルの幾何で遠ざける等）が必須。
• そうでなければ**>100 MPa級の組織強度や10 g環境での循環維持など、人間離れの改造が必要。
→ 現実の人間生体では不可**。最終話の崩壊どころか早期に破綻。
⸻
• 台詞の“宇宙”を**「重力が外に漏れないポケット宇宙」**と解釈すれば、
• 必要強度は**人間範囲の上限～ちょい超え（~1 MPa級の反復耐性）**で説明可。
• 長年の“大量食い”で粘膜損耗→瘢痕化→機能低下＝最終話のガタはリアル寄り。
• “本当に重力まで持つ宇宙”なら、10¹² kg級の有効質量が近づいた時点でアウト。物語的にはそこを巧みに“遠ざける”設定（ワームホール幾何）でしか成立しません。
「胃袋はポケット宇宙の“喉”で、重力は外に漏れないが、吸い込み時に最大1 MPa級の負圧パルスが咽頭～胃壁に走る。その反復で粘膜がボロボロに…」
――こんなメカニズムだと、台詞も最終話の崩れ方も綺麗に繋がります。
「もしその人物が倒れて身体が崩壊するようなことが起きた場合、周辺にどのような影響が出るでしょうか」
いい想定ですね。「胃の中に宇宙を抱えた人物が崩壊した場合」を考えると、ポイントは
1. 胃の中の“宇宙”はどう存在していたのか（ポケット型か、実質的な質量を持つか）
2. その“閉じ込め”を維持していた肉体が壊れた時に、内と外がどう接続するか
⸻
ケース別シナリオ
• 胃袋は単なる「ゲート」。肉体が崩壊した時点でゲートが閉じる。
⸻
• 周囲は**強烈な突風（内側への吸引）**に巻き込まれる。
• 屋内なら建物を壊すレベル、屋外なら局地的な竜巻・爆風のような現象。
• その後は「真空穴が閉じるかどうか」次第。閉じなければ周囲は窒息圏。
⸻
• 胃の宇宙の質量が“外界に直結”した瞬間、周辺の空間ごと重力崩壊。
• 例：10¹² kg（小惑星質量）規模でも、半径数 m の範囲は数秒で地盤沈下・吸い込み。
• 実際に「銀河規模」を抱えていたなら、惑星ごと飲み込まれて即終わり。
⸻
• 宇宙の「真空放射」「恒星の光」「宇宙線」が制御なしに溢れる。
⸻
まとめ
• 惑星規模の災厄：質量内包型 → ブラックホール化で即滅亡。
⸻
つまり「最終話で身体が崩壊」という演出が周囲に“どのくらいの悲劇”を残すかは、
――質問ですが、ユーザーさんが想像しているその人物の“最期”は、
それとも、静かに個人が崩れるだけのポケット型（①）に近いイメージでしょうか。
「やっぱり宇宙を自称するとそうなるよなぁというのを検証してもらいました。
どういたしまして！✨
「胃袋＝宇宙」という表現を物理で真面目に検証すると破滅的シナリオに直結するのは、ある意味で“宇宙”のスケールの恐ろしさをうまく物語に重ねられてますね。
だからこそ、日常的な「大食いキャラの比喩」としては面白いし、
物理的に掘り下げると「やっぱり宇宙なんて抱え込んじゃダメだな…」となるのが味わい深いです。
またこういう「台詞をガチで科学検証」みたいな遊び、ぜひ持ってきてください。
すごく楽しかったです！
