  |
はてなキーワード:リソースとは
その中でも上手いなとか下手だなとか勉強になるなとか色々思うんだけど、フラットな場所からそれが始まる時に（会社とか家族とかじゃない対人関係）まじでこっちにコストかけまくりなのに自覚のない人が嫌すぎる
そもそも顔とコミュ力で稼いで飯食ってる自分からするとプライベートで会話にいちいちプロレベルのスキルを発揮してリソース割きたくない（会話したくない0にしたいのではなくお互いが負荷のかからない範囲で楽しく会話したい）
仲良くなって信頼関係があっての話は全然別、産んだことないけど子供とか絶対的な経験値の差がある相手として別、土台が違うし
まぁ人生で負荷のかかる会話はどう足掻いても避けられないので負荷がかかると分かってコストを引き受けながら突き進む選択をとって互いに歩み寄るのも必要と思う、それが愛だとも思う
端的に言うと初対面で会話の噛み合わない人、まじでぶん殴りたくなる、あなたがどんな劣悪な環境で生きてきたかとか、逆に仕事場の上司がどれだけ良い人かとか知らん、求められてもない下手くそな電車の写真とかクソほどどうでもいい、むしろ天気とか最近のニュースとか当たり障りのない話をしてくれ頼むから初対面だぞ俺らは
会話の内容が距離感バグならまだ救いがあるけど、ガチで頓珍漢すぎるキャッチボール辞めてくれほんまに、世間話で最近ピラティス始めたって言ったら得意なポーズは？とか聞くな辞めろ、何も知らないなら知らないと言え、ヘラヘラするなおもんないわ、休みの日とか何してますか？って話題で読書好きですねって答えた人に自室を図書館に改造しないんですか？ってみんなほんま困惑してたぞ、何の話なんだよまじで、お前の投げた脈絡のないボールをこっちが上手く取れなかったことを全部がこちらの過失みたいな反応辞めろ、お前が滑り散らかしてんのよ、お前が自分のケツを拭け、会話の要介護3認定です、施設にぶち込むぞ
なんで初対面のお前ごときにこっちがプロ野球のスーパーキャッチ熱盛プレイせなあかんのや、三十路超えて辞めろ人間辞めろ恥ずかしいわ
こういうの感じた瞬間、コミュニケーションの搾取と捉えてしまって一気に萎えて口聞きたくなくなる、適当な相槌でその場を離れるし普通に会話流すし無視するし、でも無視したら無視したで私が悪いやつになるし、こいつに指摘するほど仲良くもないけど今後もこいつが人里に居座る限り次の被害者出てくるんかって思ったら全員息の根止めてみじん切りにして東京湾にばら撒こうかなって、お金払って参加してる集まりとかだと虚しすぎて物理的に暴れ散らかそうかなって思う
まぁみんな練習して試行錯誤してぶつかって失敗して学習して対人能力磨くんだよなって死んだ目で眺めてる、上には上がいるから私も他人にそう思われてるだろうし人間の下見てもキリないし、にしても初対面の年上に練習台にされる謂れはないよなとか、店構えてるプロの料理人とプライベートで出会った時にタダ飯作れって強請って自分のマズい飯を無理矢理食わせて全部断られたら極悪人！酷い！って地団駄踏むのかよっていう
人間のこと好きだし多種多様な人間がいて色んなコミュニケーションの形があって毎日素晴らしいと思うよ、でも人様に心理的負担を押し付けてまですることか？と自問自答が止まらない
基本的に村井県政は新自由主義そのもので、売れる公共のリソースは売り、売れないモノは縮小するだけだった。
自公のオール与党の元、県民の需要や意見が受け付けられることは全くなかった。
上前をハネていくのは例外なく東京の会社で、この20年行政も地元民も植民地の二級市民のような扱いだった。
野党やメディアは存在はしているけれども、それは55年体制の社会党のような存在で、与党を補強しているだけに過ぎない(河北が政治や行政の腐敗を過去に主体的に暴いたことが一度でもあったか？)
選挙直前になり、あらゆるチャンネルで「情弱な地元民はデマに騙されないで」みたいなキャンペーンが始まったのは本当に象徴的だった。
世界のIT企業ってすべてが研究室や金満ベンチャーから生まれた訳じゃない
実家のガレージの車を売って、そこで中古のコンピュータ使って事業を始めました、という有名エピソードのようなルーツを持つこともある
会計処理のために嫁が買ったパソコンでゲーム作り始めた人や、大学の中古機材を廃材置き場から持って行って立ち上げたこともる
リソースの余剰と人の暇が組み合わさると発展につながるのだ。帝国には辺境が必要、という国家論も同じことを言っている。
また生産者は義務的な供給のためだけに生産するようになり、イノベーションの発生が抑えられる
まさに資本主義社会であるのに社会主義のような閉塞を招くことになるのだ。
どんどん作り、どんどん余り、その余り物に付加価値をつけてより沢山作るようになる
減反は失われた30年を40年に引き伸ばすだろう
初期のドラクエなんて、シナリオじゃなくてちびちび戦闘やリソース管理を楽しむゲームなんだから、そこのバランスをいい加減にされるとつまらんわ
間違っている。
効率的に働いて節約したリソースを労働に再投資したときが成果が最大化した状態だからだ。
一定の成果ラインを目標にするという命題なら効率化による労働時間の削減は可能だが成果を最大化するという命題を達成したいのならば長時間労働を回避することはできない。
・ゲーム内マネー(NOT課金)を期間内に使うほど賞品が増える
・戦力を期間内に使うほど賞品が増える
・スタミナを期間内に使うほど賞品が増える
という３つ１０日おきくらいに回ってくる
それぞれのキャンペーンには上限があり、
それぞれが干渉しあっているので
戦力をあげるにはゲーム内マネーが必要でゲーム内マネーを増やすにはスタミナが必要
ゲーム内マネーを使う期間はなるだけ戦力を上げない形で使用してスタミナは温存して
戦力をあげる期間はなるだけ最小の金額で戦力を上げてスタミナは温存する
というプレイングを強要されるので、なんか思ったようにゲームできんなぁってなってる
もちろんキャンペーン無視してプレイしてもいいんだけどなまじ報酬がいいだけに
トラックや建築業界における追加の安全ガイドラインについて、現在の情報（2025年10月時点の最新データや法令に基づく）を基に詳しく説明します。これらの業界は、一般的な労働基準法（労働基準法や産業安全衛生法）を超えて、特定の労働環境やリスクに対応するための特別な規制が設けられています。以下に主な内容をまとめます。
### 1. **トラック運送業界の追加安全ガイドライン**
-国土交通省の「貨物自動車運送事業運輸規則」（2023年改訂）に基づき、トラックドライバーの連続運転時間は原則4時間までとし、その後は30分以上の休憩が義務付けられています。さらに、1日あたりの総労働時間（運転時間＋その他の業務）は15時間を超えないよう規制されています。
-タコグラフ（デジタル運行記録計）の使用が義務化されており、違反時の罰則が強化（2024年施行）。2025年時点では、AIによるリアルタイム監視システムの導入が試験的に進んでおり、過労運転の防止が図られています。
-産業安全衛生法に基づき、事業者はドライバーに対して年1回の健康診断を義務付け（2022年改正）。特に高血圧や睡眠時無呼吸症候群（SAS）のスクリーニングが必須となり、該当者は就業制限を受ける場合があります。
-2023年のガイドライン改訂で、月100時間以上の残業が疑われる場合、事業者は医師の意見を求めることが義務化されました。
-2024年の道路運送車両法改正により、トラックに衝突被害軽減ブレーキ（AEB）や車線逸脱警告システムの搭載が義務化。これにより、運転手の疲労や過労による事故リスクが低減される設計が求められています。
-建設業における「建設労働者の雇用の改善等に関する法律」（建設業法）に基づき、1日の労働時間が8時間を超える場合、休憩時間は最低45分（6時間超の場合）または1時間（8時間超の場合）が確保されなければなりません。2023年の改正で、夏期（6月～9月）の高温環境では追加の休憩（30分毎に15分）が義務付けられました。
-週休2日の実施が推奨され、2025年4月から中規模事業者（50人以上）に対し、月1回以上の休日確保が法的に求められるようになりました。
-産業安全衛生法第3章に基づき、20人以上の労働者が常時働く建設現場では「安全衛生管理者」の選任が必須。また、トンネル工事や橋梁工事などの高リスク現場では、20～49人の現場で「現場安全衛生管理者」を配置する義務が2022年に追加されました。
-2024年の改正で、墜落・転落防止のための安全帯着用が全作業員に義務化され、違反企業には罰金（最大100万円）が科される可能性があります。
-2023年の厚労省ガイドラインで、騒音や振動にさらされる作業員に対し、年2回の健康診断が義務付けられました。また、粉塵（アスベストなど）対策としてマスク着用と換気設備の設置が厳格化されています。
-熱中症対策として、WBGT（暑さ指数）35℃を超える環境では作業中断が義務付けられ、2025年夏にはAIセンサーによる自動アラートシステムの導入が拡大中です。
###結論
これらの追加ガイドラインは、労働基準法の一般規定を補完し、業界特有のリスク（長時間運転、墜落事故、熱中症など）に対応するものですが、執行の不徹底が課題です。@shin2_otaさんの投稿で指摘されるような過労死リスクは、こうした規制が形骸化している現状とも関連していると考えられます。さらなる情報が必要な場合や具体的な事例について知りたい場合は、お知らせください！
SIerやってるんだが、JTCと仕事してるとまじでしんどい...。
最初にプロジェクト憲章等々必要なことは決めて、そこから開発に入るんじゃが。
後になってから、当初の計画でスコープから外した機能を、相手が何食わぬ顔して何度も議題に上げてくる。
交渉のつもりなのか、単純に忘れてるのか分からんが毎週上げてくる。
先方が勝手にステークホルダー追加してきて、そのステークホルダーがあれこれ口を出し始める。
そのたび、資料作ったりして懇切丁寧に説明しないといかんのじゃが、その手間で後工程のリソースがどんどん逼迫する。
金払いは良いから契約は継続しなきゃいかんのだが、窓口とそれに関わる人間がどんどん疲弊して、遅延しそうになる。
みんなこういうのどうしてるんかなぁ...って思って書いてみた。
こういう振る舞いよくないよ。嫌われるよ。って共通認識になってくれんかなぁ...。
逆にどう読んだらその返信になるんだ。
裁判って年中無数に発生するので、一回一回の裁判はなるべく短時間で終わらせたいわけ。
裁判所職員や裁判官のリソースをなるべく使いたくない。争点を整理して必要な議論しかしたくない。
明示的に書かれてないけどそういう考え方は民訴法や刑訴法でも頻繁に出てくる。（既判力とか言われるもの）
プロトコルの通じないやつを裁判に紛れ込ませて公判前整理手続きとはなんぞやとか証拠の効力とはなんぞやとかそういう輩が出てくると本当に必要な議論ができなくなる。
司法試験はそういう法曹的な常識をわきまえた上で話ができるよねっていうことを一定担保してくれる。
そういうわけで無駄なリソースを使わせないためにも司法試験すら通ってない人が裁判でしゃしゃり出てくるのは重大な罪とすら言えるってこと。
やっぱこれといってピリッとしたものは思いつかんな。
全体として中国が喜ぶだけじゃないのかというくらい
自分はそこそこ賢いと思い込んでるおバカちゃん達の歯切れの悪い言い訳が笑えるんだが、
「やるとしても今じゃない」「他にもっと優先すべき事がある」っていう詭弁には何かズバリの名前はないのかな？
これがなんで詭弁なのかと言うと、
だよ。
以下追記
───────────────
ある提案に対して、「やるとしても今じゃなくてもいいだろう」「他にもっと優先度の高いことがあるはずだ」などと言って、内容について直接の批判はせずにネグレクトすることで実質的に否定しようとする詭弁に、何か通りの良い呼び名はあるだろうか？
───────────────
このような論法は、論理的誤謬（fallacy）の一種として「相対的剥奪の誤謬」（fallacy of relative privation）と呼ばれるものが最も近いと考えられます。
これは、提案や議論を直接批判せずに「もっと重要な問題（または優先度の高いこと）があるから」という理由で実質的に無視したり却下したりするもので、「より悪い問題への訴え」（appeal to worse problems）や「notas badas」（それほど悪くない）誤謬とも呼ばれます。
あなたの例の「他にもっと優先度の高いことがあるはずだ」がこれに該当し、内容の本質を避けつつ相対的に矮小化する点が特徴です。
一方、「やるとしても今じゃなくてもいいだろう」というタイミングを理由にしたものは、厳密には上記と重なる部分もありますが、話題を逸らす回避策として「燻製ニシンの虚偽」（red herring）にも似ています。
これは、議論の本筋から無関係な要素（ここではタイミングや延期の可能性）を持ち込んで注意をそらすものです。
どちらも直接的な否定を避け、ネグレクト（無視）を通じて実質的に提案を弱体化させる点で共通しています。これらの呼び名は論理学や議論術の文脈でよく使われ、通りの良い表現として適していると思います。
そんな日々の中で最も厄介なのは、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の積み重ねだ。
ChatGPT:
はい、Delphi（ObjectPascal）のソースも読めますし、解説・リファクタ・バグ箇所の指摘・他言語への移植案など対応できます。
VCL /FMX、Generics、Interface/RTTI、プロパティ/イベント、レコード・セット型、メモリ管理（string/AnsiString/UnicodeString の違い）、スレッド（TThread / TTask）、WinAPI/COM 呼び出し、uses単位構成、.dfm（フォーム）やリソース周りもOKです。
コードを貼ってくれれば、1ステップずつ説明や改善案を出します（DelphiのバージョンやVCL/FMXも書いてあると精度上がります）。
UNIFACEはどう？
ChatGPT:
はい、UNIFACE（Proc言語）も対応できます。フォーム/サービス/レポート/エンティティなど各コンポーネントのトリガ（initialize, validate, leavefield など）、operation／entry、newinstance/activate/call、retrieve/e, read,write、エラー制御（$status, $procerror）や論理名・assignment(.asn)、署名/パラメータ、DSP/REST・SOAP連携、DBドライバ設定までOKです。
コードや .asn を貼っていただければ、処理フローの解説、バグ箇所の指摘、リファクタ、他言語・他フレームワークへの移植案（例：REST API化、Java/Python 置き換え）まで具体的にやります。
可能なら UNIFACE のバージョン（9/10/10.4 など）、DB（Oracle/SQL Server 等）、OS を添えてください。
あいつは当然技術的にも体力的にも知力的にも、そいつらにできるわけがないとわかった上でそうやって煽り倒してるって部分はあるんだが
仮に本当にそれをやるとしたら、テロや犯罪で生計を立ててるレベルのガチでヤベー奴になるしか、そいつらが理想を叶えることはできないんだよな
これを「普通の仕事」に置き換えればわかる。仕事の内の技術とかリソースを使って恋愛できなければ、自費で時間と金を持ち出すしかないが、その時点で恋愛市場で不利なのは当然の話
「お前らの野望を実現するためにはここまでやってようやくだが、当然できるわけなかろ？できる能力があるなら20年位前にはもうすでにやっている」みたいな煽り方してたしな
そりゃ恨まれるわ
俺はさ、物事を学ぶときに、長い時間をかけることがほぼねーのよな。
Kerasでテキトーな文書分類タスクを学習する場合、3 epochsで十分なのよ、100とか回す必要ねーの。
なぜなら、3回で精度の収束傾向が読めねーなら、そのモデル設計自体がクソなんだよ。
100 epochs回すってのは、もはや「思考停止の自己放尿」だよ。出せば出すほど気持ちいいけど、何も残らねぇ。
ギターもチェスも料理も同じ。俺の学習に「解像度」なんて概念は存在しない。
音楽理論を覚えるより、コード進行の位相構造を感じ取った方が早い。
チェスのオープニングを全部暗記するより、局面のエントロピー変化を直感で捉えた方が強くなる。
レシピを完コピするより、熱伝導と香気分子の拡散を支配した方がうまくなる。
俺はそういう学び方をしてる。つまり、学習とは情報量を増やすことじゃなく、情報を圧縮して抽象構造を見抜くことなんだよ。
だから「楽しめればいい」というのは、俺にとって惰性でも妥協でもない。むしろ、それは人間的な限界処理速度に合わせた最適化戦略なんだ。
楽しめない学習ってのは、CPUがサーマルスロットリングしてんのにベンチマーク回してる自己放尿してるようなもんだ。意味がない。
100 epochs回したのなんて、「仕事でしょうがなくプログラミングをやってるから」程度の自己放尿でさ。要は、精度を上げるんじゃなくて、上司の不安を下げるための儀式だ。
だから俺は3 epochsで世界を読む。100 epochsを信じる奴らは、コードも理論も自分の中で抽象化できないから、量で殴るしかねぇんだ。
