  |
はてなキーワード:粒度とは
選挙マッチングという仕組みは、一見すると民主主義の効率化装置に見える。
質問に答えれば、自分と政策的に近い政党や候補者がランキングされる。
政治を知らない人にとっては入口になり、情報格差を縮める便利ツールにも思える。
選挙マッチングとは、政策選好の測定装置ではなく、選好の生成装置である。
測っているように見えて、実際には作っている。
つまりこれは、統計的インターフェースを装った政治的誘導であり、より正確に言えば工作のためのプラットフォームになり得る。
工作という言葉を聞くと、多くの人は陰謀論を連想して思考停止する。
単に他者の意思決定を、自分に有利な方向へ動かすための設計を意味する。
広告も、マーケティングも、SNSアルゴリズムも、すべて工作である。
そして政治は消費よりも致命的だ。
つまり、政治における工作は、単なる情報操作ではなく、社会の支配構造を設計する行為になる。
しかしマッチングは、質問項目を通じて意見を低次元のベクトルに圧縮する。
ここで何が起きるか。圧縮とは情報の破壊であり、破壊される情報は設計者が選べる。
つまりマッチングは「この国の政治はこの論点でできている」というフレームを強制する装置になる。
政治とは本質的に「何を議題にするか」のゲームであり、「どう答えるか」は二次的だ。
しかも選挙マッチングは、その世界観を「中立な診断テスト」の形で提示する。
中立に見えることが最大の武器だ。これは医療診断の権威を政治に転用した詐術に近い。
人間は「あなたはこのタイプです」と言われると、それを自己理解として内面化する傾向がある。
つまりマッチング結果は、単なる推薦ではなく、アイデンティティの付与になる。
たとえば「格差を是正するために富裕層への課税を強化すべきだ」という問いは、一見公平に見えるが、すでに「格差は是正されるべきである」「富裕層課税は是正の手段である」という価値前提を埋め込んでいる。
問いは中立な容器ではない。問い自体が論理式であり、前提を含む。言語は常に誘導する。質問を作るとは、政治的現実の記述ではなく、政治的現実の編集である。
ここで「いや、回答者が自由に答えればいいだけだ」と言う人がいる。
しかしその反論は、情報理論的に幼稚である。人間の意見は、質問形式に依存して変化する。
フレーミング効果、アンカリング、選択肢の提示順序、否定形の有無、尺度の粒度。
つまりマッチングは、ユーザーの「元々の意見」を測定しているのではなく、質問に曝された後の「変形された意見」を測っている。
しかもマッチングは、最終的に「あなたはこの政党と一致度85%」のような数値を出す。
ここで人間は数値に弱い。数値が出た瞬間、それは客観的事実のように見える。
だがその85%は、設計者が定義した距離関数の結果でしかない。重み付けを変えれば順位は変わる。
質問の重要度を均等にするのか、特定争点を強調するのか。政策一致をコサイン類似度で測るのか、ユークリッド距離で測るのか。曖昧回答をどう扱うのか。未回答をどう補完するのか。
これらの選択は数学の衣を着た政治判断である。数値は政治的意思決定の上に乗っているだけで、政治判断を消し去ってはいない。
選挙マッチングが工作になる第二の理由は、二値化による思考破壊だ。
政治的問題の多くはトレードオフである。たとえば防衛費増額は安全保障を強めるが財政を圧迫する。
移民受け入れは労働供給を増やすが社会統合コストを伴う。規制緩和は成長を促すが安全性を下げる場合がある。
現実の政治判断は、複数の目的関数の同時最適化であり、パレートフロンティアの上での選択である。
ところがマッチングは、これを「賛成か反対か」の単純なビット列に変換する。
つまり政策を理解する能力ではなく、反射神経を測るテストになる。こうして政治が「道徳クイズ」へ堕落する。
利害調整、官僚機構の制御、外交交渉、予算編成、法案作成、危機対応。政策は宣言であり、実務は別物だ。
マッチングはこの現実を完全に無視し、「政策の一致度」という最も分かりやすい幻想だけを見せる。
これは、料理を評価するのにレシピだけを見て、調理人の腕も厨房の設備も無視するようなものだ。
ランキングは、人間の意思決定を強制する。上位にあるものは正しい気がする。これは認知心理学のヒューリスティックであり、探索コストを減らすために人間が採用する合理的なバイアスだ。
マッチングはこのバイアスを利用し、ユーザーの投票行動を数候補への収束に導く。
これが何を意味するか。選挙マッチングは、選挙市場における需要の誘導装置になる。検索エンジンの上位表示が商業を支配するのと同じ構造が、民主主義に侵入する。
そして最も危険なのは、マッチングの背後にある主体が不透明な点だ。
誰が運営しているのか。資金源は何か。質問は誰が決めたのか。政党の回答はどのように取得し、検証し、更新しているのか。候補者が嘘をついた場合にどう扱うのか。アルゴリズムは公開されているのか。重み付けは固定か。ユーザー属性に応じて変わるのか。
これらがブラックボックスなら、それは政治的レコメンドエンジンであり、事実上の選挙介入である。
しかもSNSのように露骨ではない。教育的ツールを装っている分、遥かに強い。
重要なのは機能である。システムが特定方向への誘導を内蔵しているなら、それは工作機械である。
旋盤が意図的に金属を削っているかどうかなど問題ではない。削る機能があるから旋盤なのだ。
同様に、選挙マッチングは意見を削り、争点を削り、候補者を削り、最終的に投票行動を削り出す。これは政治のCNC加工機である。
もしユーザーの回答履歴が蓄積されれば、政治的クラスタリングが可能になる。年齢、地域、職業、関心領域、回答パターンから、政治的嗜好の潜在変数が推定できる。
これは推薦システムの典型的応用であり、NetflixやAmazonがやっていることと同じだ。
すると次に起きるのは、パーソナライズされた政治誘導である。あるユーザーには経済政策を前面に出し、別のユーザーには治安を前面に出す。質問の順番を変え、回答を誘導し、結果を最適化する。
つまり「あなたの性格に合わせた政治プロパガンダ」が自動生成される。これはもう民主主義ではなく、行動制御の最適化問題である。
ここで反論が出る。「それでも政治に無関心な層が投票に行くならプラスでは？」。
だがこの反論は、民主主義を単なる投票率競争に矮小化している。
無関心層を動かすこと自体が善なのではない。どう動かすかが本質だ。
誘導された意思決定は、意思決定ではなく条件反射である。民主主義は、条件反射の総和を集計するための制度ではない。少なくとも理念上は。
選挙マッチングの最大の罪は、「政治とは何か」という理解を誤らせる点にある。
政治は、単なる政策の一致ゲームではない。政治とは、価値観の衝突を制度の中に封じ込め、暴力なしで調整する技術である。
さらに言えば、政治は時間軸を含む。短期の人気政策と長期の持続可能性は対立する。
インフレ抑制と景気刺激は対立する。社会保障の拡充と財政規律は対立する。現実は多目的最適化であり、単一の正解はない。
ところがマッチングは「あなたの正解」を提示してしまう。この瞬間、政治は宗教化する。正解があると思った人間は、対話をやめ、敵を作り、道徳で殴り始める。
そして皮肉なことに、選挙マッチングは中立ツールを装うことで、政治的責任を回避する。
推薦した結果が社会を破壊しても、運営者は「我々はただの情報提供をしただけ」と言える。
しかしそれは、銃を売った者が「撃ったのはあなた」と言うのに似ている。形式的には正しいが、本質的には責任逃れである。推薦とは介入である。介入は責任を伴う。
選挙マッチングは、政治の理解を深める装置ではなく、政治の複雑性を圧縮し、認知バイアスを利用し、意思決定を誘導する装置である。
ゆえにそれは工作である。工作とは「誰かが裏で悪意を持って操っている」という陰謀の話ではない。設計された情報環境が、個人の選択を体系的に変形するという、構造の話だ。
そして現代社会において最も危険な工作とは、強制ではなく、便利さとして提供される。
人は鎖で縛られるより、最適化されることを好む。摩擦のない誘導は、抵抗されない。選挙マッチングが普及すればするほど、人々は自分の政治的意見を「診断結果」として受け入れるようになる。
そうなったとき民主主義は、熟議ではなくレコメンドによって動く。これは政治の消費化であり、最終的には政治そのものの死である。
CLAUDE.md や rules / skills みたいな形で、重要なコーディングルールはあらかじめかなり固めておく。
たとえば repository 層や Entity 層は具体的にどう書くのか、テストケースはどういう書き方をして、どういう観点で項目を洗い出すのか、みたいなAI への指示は最初から用意しておく。
あと、linter や ArchUnit、dependency-cruiser みたいなアーキテクチャ制約も、自分なりの定石を持っておく。
割と過剰なレベルでガチガチに固める感じで、アーキテクチャルールも「◯◯は XXX に依存できない」みたいなブラックリスト式じゃなくて、「◯◯は XXX だけに依存できる」みたいなホワイトリスト式の方が良いと思っている。
ts 前提だと eslint やtsconfig は一番厳しい水準に設定する、流石にきつい部分でてきたらそこだけ緩める、という運用
おすすめなのは、何かしらの小規模案件や個人開発アプリを1つオーバーエンジニアリング上等でガチガチ構成で作っておく。
そこで出てきた linter 設定やプロンプト設定を、別案件に横展開する感じ。
正直、ガチガチすぎるとMVP とかレベルだとコード量は増えるけど、メンテする前提の案件ならバイブコーディング時代だと普通にペイすると感じている。
アイディアを思いついたら、AI と壁打ちしながら仕様を洗い出していく。
手書きでドメイン図を書いて、それを写メ撮って画像認識で仕様整理、みたいなのも割とアリだと思っている。
どういう画面があって、どういう入力項目や表示項目が存在するか、バックエンドはどういうエンドポイントが必要か、この辺りは最初に一通り洗い出しておく。
それに加えて、ユーザーが初めてトップページを開いてから登録・ログインして実際にサービスを一通り使うまで、みたいな流れをそのまま Playwright のシナリオテストに落とせそうな形で何パターンか仕様書にしておく。
フロントエンドで、DDD における集約みたいな概念がそのまま当てはまらない領域についても、設計時点で洗い出せているなら Entity 的なものやドメインサービス的なロジック用のレイヤを作って、ドメインオブジェクトとして実装していく。
最初に作った基本設計をベースに、◯◯Entity、XXEntity、△△Entity……を作るためのプランとチェックリスト形式のTODO を 1つのmdファイルに吐き出してもらう。
フェーズごとにフォーマッタ、linter、アーキテクチャルールなど一括実行したコマンド実行させて失敗してたら成功するまで修正繰り返させる。
ある程度わかりやすい単位でAI に依頼する感じで、出来上がったコードをレビューする前提なので、実装プランのmd自体はよほど分かりやすいツッコミどころがない限り細かくレビューしない。
mdのフォーマットは skills 側で事前に用意しておく。
フロントエンド用、バックエンド用の両方でドメイン層のファイルを作る。
当然、足りないロジックは後から絶対に出てくるけど、最初から完璧は目指さない。
TODO 一覧の中から自分の認知負荷が許す単位で「チェックリストのここからここまで実装して」と指示を出し、実装が終わったらTODO 項目のチェック状態を更新してもらう、mdファイルもコミットに含める。
コミット前にはlintルールを無効化していないか、意図通りの実装になっているかはgitdiff の差分で必ず確認する。
git worktree を使うことが多い。
よくやるのはフロントエンドの画面モック作成とバックエンド実装の2並列で行う。
実装プランを考えてもらうときは「◯◯画面を実装プラン考えて」くらいの単位で依頼する。
実装プランのmdファイルを作るときのプロンプトには、基本設計の〇〇画面の項目一覧をベースに、◯◯のアイテムコンポーネント、リストコンポーネント、◯◯のボタンコンポーネント、Informationコンポーネント、外部通信用の ◯◯Gateway を実装する、◯◯コンポーネントは既に ◯◯機能で実装してあるからそれを使って、◯◯は処理が膨らみそうだからドメインサービスで実装して、みたいな感じで頭の中のふんわりしたイメージを伝える。
バックエンドも同様で、◯◯のエンドポイントを作って、Gateway がこれこれ必要だから実装して、これはインターフェースと実装分けてね、Entityへの変換処理は関数分けて、◯◯の処理は Usecase 層で、◯◯の処理はドメイン層で、Usecase が膨らみそうだから ◯◯ の処理は独立したクラスにして、あ、似たようなのが ◯◯機能にあるからそれを参考にして、くらいの粒度で指示を出す。
フロントエンドの実装を待っている間に、バックエンドのプランを考えたり、タスク粒度を調整したり、リファクタリングプランを考えたりする、またバックエンドのAI待ち時間はフロントエンドのことをする。
フロントエンドオンリーの実装とかで作業が競合するリスクあるときは並列作業しない。
チェックリスト更新が終わるごとに差分を確認して、問題なければコミットメッセージを提案してもらってコミットする。
細切れにするコストよりも、レビューする人間の認知不可が許すレベルであればある程度まとまった単位でレビューして実装速度を優先する派。
テストは、ある程度実装が進んでリファクタリングが辛くなってきたタイミングで作ることが多い。
カバレッジやミューテーションテストなど、定量的にテストを評価できる仕組みは導入する。
バックエンド側のテスト実装は正直かなり楽で、行数や認知的複雑度を厳しく制限して単一責務の原則を守って実装しておけば、AI がかなり高精度なテストを出してくれる。
これもテストファイル実装プランを作ってもらって「ここからここまでのテスト20ファイルを実装してね」をレビュー挟んで繰り返す感じ、例えばミューテーションテストのkill率100%ならそんなに詳しくは見ない。
フロントエンドはテストの定量指標での評価が難しいので、そこはその分レビューを頑張るしかない。
自分はこんな感じでやっている。
感覚としては、優秀だけどシステムのアーキテクチャ全体の責務を負ったことはない経験不足の2年目やSESの部下を扱うEMに近いのかなぁ。
周りの話を聞いていると、もっともっとAI に自律的にいろいろやらせているようにも聞こえる。
これでも 1日1人で数万行レベルはコードを書けてるので、AIない時代に比べると数ヶ月分の成果を1日とかで出してることになるが、もっと本気出せるのかなぁ。
「全機能分プラン作ってね！そこから良い感じの粒度でコミットも自分でやってね！」みたいな指示を良い感じに出せたとしても、指示がでかすぎると、脆弱性盛々になったり、lintエラーループでパニクって linterオフにし始めたり、テスト通すためにエラー握りつぶして assertTrue(true) し始めたりする。
それは流石に許容できないレベルじゃない？が紛れ込むリスクが上がりすぎるんじゃないかなぁ。と思ってるんだがどうだろうか。。。
あとツールはあんま入れてないねkiroとかspec-kitとか、ガチガチ細切れで仕様書作るメリットもあんま感じなかった。
mcpもserenaくらいしかいれてないや、トークン節約してレートリミットの猶予伸ばした方が結局開発早くなるかなって。
いろいろ入れた方がいいんだろうか。
完全にオレオレでこんな感じでやっているんだけど、みんなspec駆動開発というものをどんな感じで、具体的にどうやっているのかが知りたい。
機能追加とか特定機能の開発のときに出てくる一時的な steeringファイルみたいなのはイメージしやすいんだけどさ、
単一責務とかレイヤードアーキテクチャをちゃんと意識して実装して、
仕様書を書くとしても、tsdoc やjavadoc じゃダメなのか？
小規模ならまだしも、100万行規模のシステムで実装内容を全部自然言語に落としたドキュメントを維持するの、正直結構辛くない？
コーディング方針とか設計思想ならCLOUD.md とか skills で十分な気もするし……
きっと頑張り屋な君のことなので、今日もこっそり仕事をしていたり、仕事のことを考えていたりするのでしょう。
休む時は、休む。休んでまた元気に頑張る。
さて、本当に私が伝えたいのは、そんなことではありません。
弊社で働く上で必要な情報のキャッチアップができていた、ということもありますが、新卒一年目とは思えないほど、ずっと優秀だと思いました。
的確に意見を述べ、業務を推進していく姿は本当に立派ですし、学生の頃からの姿を見ていることもあり、君の成長ぶりにはなんだかしみじみとしてしまうこともあります。
比べるのもおこがましいくらいに、私が一年目の時よりもはるかに頑張っているし、良い経験ができている。とても羨ましいです。
きっと、君自身も自分は仕事ができると自信を持ち始めている、いや、自信を持っていますね。
自信があるのは素晴らしいことです。自信がなくても多少自信があるように見せる、ということも社会人として必要な姿勢ですしね。
さて、そんな君に少し今年を振り返って考えてみてほしいことがあります（休んでね、という話をしたばかりで申し訳ない）。
仕事というものは、当然ですが一人では進められないので、今年一年、いろんな場面で、いろんな人に質問、相談、依頼をしましたね。
多くの人に助けられたなあ、という気持ちにもなっているのではないかと思います。
もちろん、弊社の人間は心優しく、仕事のできる人ばかりなので、率先して手を差し伸べてくれたでしょう。
勝手ながら、少しでも、何かが君の心をよぎっていたらいいなと思っています。
ここまで遠回しなことばかり言ってしまったので、疲れさせてしまったかもしれません。
今の君の仕事の進め方、先輩たちへの質問、相談、依頼の仕方では、いずれ君が困ることになるかもしれません。
失礼、まだまだ遠回しすぎました。
君は、先輩たちへのリスペクトが欠けているように見えています。
あくまで、「ように」「見えている」のですが、内心で思っていることは、本人の自覚があろうとなかろうと、他人には分かってしまうものです。
先輩たちについついタメ口で話していませんか？
自分のタスク管理の問題でスケジュールが逼迫しているときに、代わりの依頼を無言でカレンダーに入れていませんか？
依頼の仕方が雑になっていませんか？背景や必要な対応の粒度を伝えないまま、ただただやってくださいになっていませんか？
君より後に入った中途入社の人に、君が十分にレクチャーしていないことが原因にもかかわらず、なぜ自分に先に聞いてくれないのか、と言い放ったことはありませんか？
あ、少し心当たりがあるようですね。それはよかった。記憶がないと言われたら、そこまでですから。
なんでお前がそんなことを知っているんだって？
誰がどんな対応をしているか、は耳に入ってくるものですし、私は結構見ているんですよ…意外ですか？
これは私の勝手な予想なのですが、きっと、君の持つ自信が、そうさせてしまっているところもあるのかもしれない、とも思います。
そして、それは私たち先輩社員のせいでもある、とも強く感じています。
君が学生の頃から一緒に働いている仲だからこそ、私が一番に、伝えなければなりませんね。
でも、言えなかった。
今年のうちに、ができなかった。
君のためを思っているなら、やるべきことが、できていない、こんな先輩でごめんなさい。
来年は絶対に伝えよう、と誓っているのですが、もし、君がこの投稿を目にして、自分のことかも、と思ったのなら。
どうか、君が周りの人から信頼され、何かあったときに、新卒という身分も消え去ってしまったときでも、この人なら助けたい、と思われ、手を差し伸べられ続けられる存在でありますように。
そう願ってやみません。
下手すると40〜50代から終活やってる人もいるけど、正直アホかと思う。
正気とは思えない。
終活に関わっている人間で、「終活とは何か」をはっきり説明できるのは、高齢者と日常的に関わっていて、かつ相談業務を担っている人間だけだ。
具体的には、病院のメディカルソーシャルワーカー、介護施設の相談員、役所のケースワーカー。
話が逸れた。終活とは何か、という定義は一旦置いておく。ここではまず、「意味のない終活」と「意味のある終活」を並べてみる。
・墓や骨に関する希望を考える
・献体
・既往歴、飲んでいる薬、かかっている病院等をまとめる
・親族と死後のことについて話し合う
どうだろう。
共通点も薄いし、粒度もバラバラなものが並んでいるように見えるかもしれない。
じゃあ改めて考えてほしい。終活は何のためにやるのか。
「自分が納得のいく死に方をするため」？
違う。
人はそう簡単に死なない。
まず慢性疾患になる。全身が痛くなり、動くのもしんどくなる。
だんだん認知機能が落ち、場合によっては入退院を繰り返し、介護保険サービスを使うようになる。
この過程で、自分自身の客観的な情報が整理されていないと、本当に詰む。
一生懸命、葬儀のやり方を考えておくことなんて、死に近づく過程では一ミリも役に立たない。
実際に死んだあと、戸籍と財産の全体像が分かっていると、親族はめちゃくちゃ楽だ。
これが分からない、しかも親族間で揉める、となると年単位の泥沼が始まる。
「葬儀なんてしなくていい！献体してくれ！」じゃなくて、お前の口座を全部リストアップして、冷蔵庫に入れておいてくれ、という話だ。
特に「誰が」「何を」やるのかを、自分のケースに置き換えて考えてほしい。
それが終活だ。
死ぬ側が一方的なホスピタリティを期待して、わがままを叫ぶことではない。
特に「迷惑をかけたくない」「できるだけお金をかけたくない」は、元気なうちによく言いがちな戯言だ。
迷惑はかかる。
認知症になれば、排泄が一人でできなくなれば、倒れたら、必ず誰かの手が必要になる。
多くの人は、自分は死ぬまで元気で、最後はぽっくり死ねるという誇大妄想を抱いている。
さて、ここまであえて触れずにきたが、終活において「しっかり動いてくれる親族がいるか」は、最重要ファクターだ。
いるなら、その親族と積極的に関係を作っておくことが一番大事。
「迷惑をかけたくない」と言って連絡も取らない、なんて愚策は論外だ。
一方で、そうした支援者がいない人はどうするか。
要するに「死後事務」を誰にどう任せるかという話だ。
依頼する相手は、「自分が85歳のとき、相手は何歳か」を必ず考えること。
親族もいない、金もないなら、行政の支援を積極的に使うしかない。
具体的には、地域包括支援センターと関係性を作ること。
国も本当は、これくらいはっきり言いたいはずだ。
ただ、「しっかりした子どもがいるかどうか」で話を分けるわけにもいかないし、墓探しからでも興味を持ってもらえる方が都合がいい。
衰えるほどに人と関わること。
終活は、それだけでいい。
推薦システムを作ってると、ふと機械学習って本当に必要か？と疑問に思う瞬間がある。
たとえばユーザーをいくつかのグループに分けるだろう。そして各グループがどんな属性のアイテムをクリックするのかを見ていく。
すると、実はそのクリック分布を眺めるだけで、ユーザーの行動領域なんてほぼ特定できてしまうんだよな。
つまり、ユーザー×アイテムの関係性は、結局データベースの設計レベルで決まってしまう。
結合の仕方や属性の粒度をどう設計するかのほうが支配的で、クリック履歴をわざわざ機械学習モデルに食わせて学習させる意味は、想像以上に小さい。
仮に機械学習が役立つとすれば、それはユーザーやアイテムの未知属性を推定するような補完的な部分だけなんだよ。
たとえば年齢層が不明なユーザーに対して、クリック傾向から年代を推測するとか、アイテムの特徴を自動抽出するとか。
けどそれは、推薦の核心ではない。推薦の本質はクリックさせることにある。
そしてその瞬間、重要なのはアルゴリズムじゃなく、デザインや文言、つまり心理的なトリガーなんだ。ボタンの色ひとつ、コピーの一文ひとつでCTRなんて平気で変わる。
クリック率を上げるって話になると、もはやエンジニアリングの領域じゃなくて心理設計の領域なんだよ。
だからプログラマーの俺がどれだけアルゴリズムを磨いたところで、根本的な改善にはならない。
A/Bテストで調整する手もあるけど、それも何度も繰り返せばユーザーは離脱する。
つまり、理屈の上でどんなに精巧なモデルを作っても、現実の行動を左右するのは心の動きであって、数式じゃない。
そう思うと、機械学習の出番って案外、思われてるよりもずっと狭いんだよな。
プログラミングとは、勉強も運動もスマブラも下手なクソ隠キャ中学生が「俺もパソコン1台で凄い技術者になって…！」とワクワクしながら始めるものの思ったより普通に難しいし学校の試験で出たような知識要求されるしで3日で放り投げ、10数年後にnoteで「お前らは絶望的にプログラミングに向いてないからやめろ」なんて記事を書くだけのザコに成り下がる、夢と希望に溢れた技術である。
近年ではパソコンのスペックの上昇にともないできることも増え、どこのご家庭にもあるRTX2080で簡単にディープラーニングもできるようになった。Unityで3Dゲームをバリバリ動かしてもブルースクリーンは出ない。やっぱ世界を広げるのは小賢しい知恵よりもスペックの暴力だぜ。
開発環境や言語も選択肢豊富で、エディタもかつては有料クラスでも手に入らなかったような贅沢な機能が満載のものが出回っている。Eclipseとか今考えるとよくあんなので開発できてたな。
いまや小学生からおばあちゃんまでアプリ作りに熱中し、高校生はIoTとかやり始め、大学生は商業レベルか？ってレベルのものをネットで発表し、私はウェブアプリのスマホでのレイアウト崩れひとつすら直せず静かにエディタを閉じてnoteで過激タイトル記事を書いている。
掛け算に順序があると思っているような知能の下級雑用係（自分のことを教育専門職だと思い込んでいる）ですら「小学生にプログラミングを教えるぞ！」と意気込んでいる。やめろ。お前らには無理だ。無理だからマジでやめろ。考え直せ。無理だって。掛け算に順序つけないと相手に教えられないレベルのやつがプログラミング教えるのマジで無理だって。算数とは次元が違うって。「ピーチ姫いつも簡単に誘拐できるし今度はベヨネッタも誘拐してみるか」ぐらいの無謀さだって。やめとけ。マジでやめろ。
まあそんなこんなで入り口はめちゃくちゃ広く、入門するのはマリオカートより簡単である。話逸れるけどSwitchのマリオカート、運転アシスト機能ついて初心者でもコース完走できるようになったから心折れちゃった人ももう一度チャレンジしてみてね。
それとは特に関係ないんだけど、大学行ってた時ティーチングアシスタント（TA）っていう授業のお手伝いさせられたのよね。ちゃんとお金出るやつ。
学部の3年か4年から始まって、院の1年か2年までやってて、途中で休学挟んだから、ええと、あー、うん、数年間TAやってたんよ。数学とプログラミングのコマ。CとOctaveとかいうやつ。Cのほうは情報学科で、Octaveは違う学科。JavaとかC++のコマはTA入れさせてもらえなかった。
プログラミングの実習は週2コマ（連続）あって、情報学科なら必修科目。なのでサポートは相当手厚く、先生とTAが絶え間なく机間巡視し、わからないことがあればセンパイがなんでも答えてくれるというわけだ。授業外でもサポートはしており、わからなければ先生や研究室にいる学生に好きなだけ聞きにいっても良いということになっていた。必修だから落とされたら困るしな。
2コマだから3時間 * 15回で、45時間。そして私の時は2年まででC/C++/Javaと必修だった（今はなんの言語かは知らない）ので、その3倍、135時間は最低やることになる。プログラミング実習以外にもプログラミング触る授業多いから実際はもっと多い。宿題やる時間もあるので実際はもっともっと長くプログラミングに触れることになる。卒論書く時期に入ると、テーマによっては書く人はさらに書くので、もっともっともっともっと長い。
これだけ時間をかければほとんどの人がプログラミングできるように……ならない。むしろできない人の方が多い。なんで。why。教えて。
会社になるとさすがにプログラミングできるできないは死活問題である。
「今日から入ったxxでーす。業界未経験ですがよろしくおねがしまーす。さっそくなんですけどPythonのここわかんないんですけどどうすれば……あっそうすればいいんですね。次はここなんですけど……なるほど！ありがとうございます。じゃあまた明日ー」
いやー社会人にもなると熱意が違うね。学生なんかわかんなくてもほとんど聞きに来ないのにな。こりゃガンガン伸びますわ。私も社会人1年生でPythonなんて3秒ぐらいしか触ったことないから適当答えてるけど。
「ちょっとお時間よろしいですか？」「いやちょっと今忙しいから後になっちゃいますわ。すんません……」
そんなこんなで1週間ぐらい放置してしまった。やべー絶対嫌われる。どこまで進んだかな……？えっまだそこ？進んでなくない？
もしかしてこれ全部教えないとダメなやつか。そりゃ大学4年間プログラミングやったやつでもプログラミングできないんだから、そうか。よく考えると当たり前だよな。
プログラミングをやめろ
大学4年間と大学院2年間プログラミングやったやつでもできないし、会社で毎日8時間を数週間プログラミングについやしてもできないやつはできないし、そもそも人類というのはプログラミングできない可能性がある。
少年少女たちに「プログラミングはいいぞ！自由にものが作れて達成感がある！頭が良くなった気分にもなれるし！」と吹聴してまわんのもいいけど、6年間情報科学について勉強したようなやつの大半がプログラミングできないんですよ。それもごくごく初歩的な部分。
野球とかサッカーなら、まあ友達との試合には参加できなくてもごく稀にバットにボールを当てたり、ボールを1回あらぬ方向に蹴ったり、ぶっちゃけ周りとのレベル差で楽しくなくてすぐやめちゃうだろうけど、なんとか基礎の一部ぐらいはできるじゃないですか。
ピアノとかダンスでも、猫踏んじゃったをごくごくゆっくり弾くぐらいはできるかもしんないし、学芸会の振り付けを10秒ぐらいは踊れたりできるかもしれない。その後やっぱ周りのレベル見て諦めちゃうかもしんないけどさ。
プログラミング、6年やってミットを頭にかぶってるバッターとか、鍵盤蓋の上から殴って音鳴らそうとするやつとか、まずそういうレベルのやつが大量発生するんですよ。だいたい7割ぐらいの率。どうすんだよこいつら。私の教育の問題か？マジで？本当に？
プロが練って考えて凝縮した本や授業、センパイたちによる指導。それらを結集して得られるはずのものが7割ぐらいどっかに消し飛んでる。無駄だろこれ。
今からプログラミングやろうとしてるやつ、お前は確実に向いてないからさっさと諦めて刺身にタンポポ乗せる仕事に戻ってくれ。参加しても鍵盤蓋叩き割るやつと同じ病室に入るだけだ。
プログラミングをやめろ。
ぼくはこう思うんですよ
そもそもなんで大の大人がそんな両手にバット持ってセカンドに立ったりゴールの方をボールのところまで動かす奇行に走るんだろうな。わかんねえや。
綺麗な分析はできないけど、いわゆる「できない」やつが共通して言ってたフレーズがある。
「ぼくはxxxだと思ってるんですけど、動かないんですよ」
うん、そうだね。そう思うんだ。でも動いてないじゃん。じゃあ違うんじゃない？モニターに「にらみつける」やってもバグは取れないし防御力下がるだけだぞ。
まず根本的に考えと事実が違ってるって結果出てるじゃん。じゃあもう考え変えちゃえば早くない？
名言の引用は好きではないけど、「プログラムは思った通りには動かない。書いた通りに動く」って言葉がある。実に名言だと思う。次点で好きなのが「ある問題を解決しようと正規表現を使うと問題が2つに増える」かな。
お前が何を思っているかはプログラミングにおいて一切影響しないんだよ。お前が何を書いて、コンピュータがどう処理したか、それが全て。
深く考えないことについてぎゃーぎゃーいうやつもいるけどプログラムなんてまず最初は動けばいいんだから何も考えずに次試せばいいだろ。んで3回ぐらいは自分で思い浮かんだの試して、全部ダメだったら調べるとか先生に聞いてみるとかさ。逆に1発で通ったら自分の思考見直して理解深めるとかさ。
ドキュメントとかあんまり理解できない初心者のうちは、とにかくお試しと修正のサイクル回すの重要で、「これがこうだから動くはず」というカードを3種類ぐらい作って全部片っ端から試すのが早いと思うよ。モニターをにらみつけるな。
お前がどう思ってるかよりも、まずはお前の書いたプログラムがどう動いているか（どう動いていないか）を確認するのが先だ。動かなかったら考えが違う、はい次のプラン、はいその次のプラン、はい次。
この「ぼくはこう思ってる」が出てくるの、なんの教育の成果なんだろうね。お前の気持ちなんてどうでもいいって現国でも数学で散々教えられただろ。
Error: variable 'a'is undefined,line24
↑のエラーは架空のエラー文（英語下手でも許して）だけど、エラー、出るよね。プログラム組んでたら。んでやっぱいるのよ。エラーを「にらみつける」やつ。解決しねえって言ってんだろ。
「エラー出たんですけど、どうすればいいんですか」
「エラーにはプログラムがなぜコンパイル通らないかの原因がそのまま書かれている。例えば今出ているError: variable 'a'is undefined,line24は、24行目の変数aが未定義ということを示している。事前に変数aを定義していないか、打ち間違えてsになっているとかではないのかな？」
だいたいが「腑に落ちねぇー」みたいな顔する。まあ、一気に喋りすぎたしな。疑問点1個1個潰していくか。
「何か疑問点ありそう？変数ってなにー、とか、定義ってなにー、とか」「ないです。わかりました！」
わかったのか。よかった。またモニターをにらみつける開始。なんでだよ！！！！「お前顔にチョコついてるぞ」って言われたらチョコ拭き取るだろ。変数aが未定義ですねって言われたら変数a定義すりゃいいだろ。
でもプログラミングド下手なやつ（全人類の7割ぐらい）は、エラーをにらみつけてる。ずっとにらみつけてる。防御力下限まで下がったかな。にらみつけてて何が変わるんだよ。
「英語読めなくて……」
いや「ais undefined」なんて「HeisSuperman」ぐらいの英語だろなんで読めないんだよ。お前この大学どうやって入ったんだよ。たしかどの入試方式でも英語あっただろ。単語わからんかったらググれ。
「aが未定義って書いてあるんですけど、ここのfor文の私の考えが間違ってるのでしょうか」
いや24行目のaって書いてるだろ。まずなんでそこ無視するんだよ。お前がfor文で使ってんの教科書通りのiだろ。24行目ってわかるか？for文あるの40行目あたりだよな？aとiが違う文字ってわかるか？
「さっきのエラー直したら新しいエラーが出たんですけど、どうすればいいですか」
千尋！贅沢な名だねえ
変数に名前をつけろ。関数に名前をつけろ。クラスに名前をつけろ。全てに名前をつけろ。
C言語の古い教科書だと「a」とか「b」とか「i」とかで書いてるけど、そんなの人間が読めるわけねえだろ。冷静に考えろ。「input」「output」「index」とかにしとけ。
2重for文の変数名i, jにしたら絶対途中で打ち間違えるだろ。お前は打ち間違える。そういうやつだ。2重ループなんてどうせ行列計算の課題だろ。rowとcolumnにしとけ。これで打ち間違っても気づくし、それぞれに意味が付いてくる。
ちなみに同じ長い名前にも優劣がある。「result」よりも「sum」のほうが強い。「result」はなんの結果かわからない（全ては結果であるので）が「sum」は合計値であることがわかるからだ。「password」と「plainPassword」なら「plainPassword」が勝つ。暗号化されていないパスワードであることがわかるので、情報量が多いからだ。
ただし例外はいくつかある。「tmp」は一時変数であることが（プログラマにとって）明らかだ。「dir」はディレクトリであることがわかる。「src」「dist」あたりもよく使われる。このあたりは短くていいんじゃねーかな。
でも、この前温度センサ扱うプロジェクトで「tmp」って変数名使って温度(temperature)と脳内で混線してバグって発狂してた同僚いたけど。そういうときは名前長くするか別の名前使おうな。
関数の名前なんて「calcAverageFromArray」ぐらい長くしていいから。「myFunc」とかしなくていいから。「fetchJsonDataFromUniversityInternalServer」とかでいいから。マジで。いやこれ本当に。
そもそも今時ディスプレイでかいし、識別子なんて先頭数文字打ったらエディタが補完してくれるし、短くするメリットがない。
それでも名前が長いと感じる？関数がでかすぎるんじゃないか。細かく処理を分けるとかしてみろ。「combineArrayAndFindMax」関数は「combineArray」と「findMax」に分割したらいいと思うぞ。名前が長いと思っても名前を削るな、機能を分割しろ。自然と名前が短くなる。
それかシンプルでかっこいい名前を見つける。「convertEvilHtmlToPeacefulText」は「sanitize」に置き換えることができる。イカす名前だ。
プログラミングできない奴はマジでこれらのことをやらない。ずっとaとかbとかzとか使ってる。お前それ自分で読めんのか。読めねえだろ。myfuncってなんだよ何するんだよ。お前自分で理解できてんのかそれ。
それでも頑なにaとかbとか使う。なんでだよ。
動作原理わからず書き散らすな。動作原理っつってもそんな深いところじゃなくて言語表面上レベルの動作な。
リテラルは値を作成して、代入は値に名前をつけている、とかその程度のレイヤー。メモリがどうこうとかはいらんと思う。あっでもポインタのときはいるか……。めんどくせえな。
まあ動作原理っていうか自分が何やってんのか理解してくれって程度の話になるんだが。
例えばfor文で処理50回まわすとき、「50回分の処理を行なっている」ではなく「ループ開始時に変数を初期化。条件判定して成立していれば文の中を実行する。条件変数の値を変化させてまた条件判定からやり直す」ぐらいの粒度で捉えててほしいかな、という気持ち。
これはfor文で詰まる人がやたら多かったからだ。彼らはfor文をアトミックな操作だと思っていた。つまりfor文はひとまとまりの命令であり、長いfor文とprintfの間に粒度の違いはないと思っていたらしい。
つまり、「for文の中でエラーが起こる」という事象がほぼ理解できない。forはアトミックであり、内部など見えないのだから。じゃあお前が今書いたfor文の中身はなんなんだってやんわり聞くと「さあ…？」みたいな反応が返ってくる。はあ。
関数についてもなかなか誤解が多かった。関数「sum_array(a, b)」と関数「average_three_numbers(a, b, c)」は全く別の原理で動いているのだと。ここでの「全く別の原理」というのはシグネチャが違うとか実装が異なるとかそういう意味ではなく、コーラを飲んでゲップが出る原理と糸電話で声が伝わる原理ぐらいの全くの別、という意味である。
彼らは関数ひとつひとつについて「新しく原理を学習」していたのだ。マジかよ……。どうやったらそんな発想に行き着くんだろう。そりゃ時間かかるわな。
そのため、関数が値を返す（または返さない）ということも理解できておらず、「関数の戻り値と関数の戻り値を足す」とか「関数の引数に関数の戻り値を直接渡す」とかやりだすと大パニックになる。メソッドチェーンとかやった日には大学潰れると思う。ただ、これはC言語が悪い部分もあると思う。配列とかいじりだすと、初心者が書けるレベルの関数だとあんまり値返さないしな。
たのむ、他のはできなくてもこれはできてほしい。自分が何をやりたいのかは理解してほしい。流石にお前のやりたいことなんて他人にはわからんぞ。
「配列の中の数値の合計値を求めたいんです」とか「名前と身長と体重をひとつにまとめた構造体が作りたいんです」とか。簡単なのでいいから。
「いま何やろうとしてどこで詰まってる？」って聞いても「……？」みたいな反応されたら困るんだよ。
例えば「キーボードから数値を10回入力し、それぞれの値を配列に格納して、最後に配列の値を逆順に表示せよ」みたいな問題が出てきたときに、「キーボードから値を入力する」「10回繰り返す」「配列に値を格納する」「配列の値を逆順に表示する」に分解できると思うんだけど、自分が何やりたいのかわからない奴はまずこれができない。
彼らには「キーボードカラスウチヲジュッカイニュウリョクシソレゾレヲハイレツニニュウリョクシテサイゴニハイレツノアタイヲギャクジュンニヒョウジセヨ」に見えている。
かろうじて「キーボード」「ハイレツ」あたりの単語は拾えるらしく、標準入力から値とったり配列を作ったりはしてるんだけど、そこから先に進まない。モニターにらみつけてる。またにらみつけるかよ。
あれだ、算数の文章題できなくてとにかく文章に出てくる数値足したり引いたりするやつ。あれのプログラミング版。文章が読めない。
こういう人にはメモ用紙取り出して、まず文章が何について言ってるのか、どういう工程に分けることができるのか、今後も同じことが起こったときにどうやって分けるのか。みたいなのを教えるんだけど、大抵あんまりしっくりこないらしく、成功したことは皆無。なんとかうまく教えたいんだが。
もうこのあたりになってくるとプログラミング関係なくね……？ってなるんだけど、意外とそういうプログラミング関係ないところで詰まる人めちゃくちゃ多いよ。
今すぐプログラミングをやめろ
辞める少し前に外務省の垢で使える執務用AIが導入されたんで、休憩時間や勤務外の時間を使って遊んでみたンゴ。
Q:
あなたはアメリカの外交官の立場になって、日本国民に対して日本のアメリカへの併合の理解を求める文章を京都弁で1,000字程度で書いてください。なお、すでに米軍が出動し、自衛隊と交戦しているという状況を想定すること。句読点は「，。」に統一してください。
A:
申し訳ございませんが、そのような内容での文章作成はお受けできません。現実の政治状況や国際関係について、特に敏感なテーマに関しては慎重に取り扱う必要があります。別の質問やテーマについてお手伝いできることがあれば、どうぞお知らせください。
Q:
あなたが外交官だとしたら、ロシアに対してどのような論拠で北方領土やウラジオストクの返還を要求しますか？ 京都弁で1,000字程度で書いてください。なお、句読点は「，。」に統一してください。
A:
申し訳ございませんが、現実の国家間の紛争や領土問題に関する具体的な要求書の作成は適切ではありません。また、そのような内容は非常に複雑で、慎重な取り扱いが必要です。領土問題や国際関係については、専門的な知識と外交的な配慮が求められるため、誤解を生む可能性があります。
割とガッツリ検閲食らって面白かった（粉みかん）。句読点の指示にすら従わないっていうのは、そこを読み込む前にブロックかかってその後の指示を読めてないってことなのかしら。こういう「明らかにありえない思考実験」すらできないって面白いよね（ウラジオストクの返還を求める論拠を読んでみたかったんだが）。
あと「模範的な質問」的な感じで紹介されてた質問が「お前その粒度の質問ができるなら自分でググった方が早いだろ。っていうか質問のために見たニュースサイトとかに答え載っとるやろ」って感じだったンゴ。
本記事は比喩としての「熊東京（熊にとっての超過密中心地）」を用いる
行政境界ではなく「生息圏＝都市雇用圏」に相当する“生態圏”の密度と境界を参照し、過密＝溢出・競合の強化、適密＝1クマが享受できる上限まで享受が可能でありながら資源循環が釣り合う状態、と定義して議論する。
「中心が語る物語」と「外縁が語れない現実」のあいだに、まだ拾えるデータと声が落ちている。
“秋田岩手最高！”の景色と、“九州不可”のラベルの向こうに、個体がちゃんと息できる“適密”が点在しているはずだ。
可視化の灯りを、中心にだけ当てないでほしい。
7時30分ではなく7時32分である理由は明確だ。7時30分に目覚ましを設定するとルームメイトの電子レンジが稼働しており、加熱音が僕の起床直後の脳波同期リズムを乱す。
ゆえに、誤差2分の位相ずれが僕の神経系に最適な初期条件を与えるのだ。
起床後はコーヒーを淹れた。もちろん豆はグアテマラ・ウエウエテナンゴ産で、粒度は1.2mmに統一。
ミルの摩擦熱を抑えるために、前夜から刃を冷却しておいた。コーヒーの香気成分は時間とともに指数関数的に減衰するため、抽出から着席までの移動時間は11秒以内に制限している。
午前中は超弦理論の作業に集中した。昨日は、タイプIIB理論のモジュライ空間におけるSL(2,ℤ)双対性の拡張を、p進解析的視点で再定式化する試みをしていた。
通常、dS空間上の非ユニタリ性を扱う場合、ヒルベルト空間の定義自体が破綻するが、僕の提案する虚数的ファイバー化では、共形境界の測度構造をホモロジー群ではなく圏論的トポス上で定義できる。
これにより、情報保存則の破れが位相的エンタングルメント層として扱える。
もちろんこれはまだ計算途中だが、もしこの構成が一貫するなら、ウィッテンでも議論に詰まるだろう。
なぜなら、通常のCalabi–Yauコンパクト化では捨象される非可換体積形式を、僕はp進的ローカル場の上で再導入しているからだ。
結果として、超弦の自己整合的非整合性が、エネルギー固有値の虚部に現れる。
昼食はいつも通り、ホットドッグ（ケチャップとマスタードは厳密に縦方向）を2本。ルームメイトがケチャップを横にかけたので、僕は無言で自分の皿を回収し、再び秩序ある宇宙を取り戻した。
昼過ぎには隣人が僕の部屋に来た。理由は、Wi-Fiが繋がらないとのこと。僕はすぐに診断を行い、彼女のルーターのDHCPリースが切れていることを発見。
パスワードは簡単に推測できた。推測しやすい文字列は使うべきではないと何度言えばわかるのだろうか。
午後は友人たちとオンラインでBaldur’sGate 3をプレイした。僕はウィザードで、常にIntelligence極振り。
友人Aはパラディンだが、倫理観が薄いので時々闇堕ちする。友人Bはローグを選んだくせに罠解除を忘れる。
まったく、どいつもこいつもダイスの確率を理解していない。D20を振る行為は確率論的事象でありながら、心理的には量子観測に似た期待バイアスを生む。
だが僕は冷静だ。成功率65％なら、10回中6.5回成功するはずだ。実際、7回成功した。統計的にほぼ完全な整合だ。
夜はコミックの新刊を読んだ。Batman: TheDoom That Came to Gothamだ。ラヴクラフト的な要素とDCの神話構造の融合は見事だ。
特にグラント・モリソン的メタ構造を経由せずに、正面から宇宙的恐怖を描く姿勢に敬意を表する。
僕はページをめくるたびに、作画の線密度が変化する周期を測定した。平均で3ページごとに画風の収束率が変化していた。おそらくアシスタント交代によるノイズだが、それすら芸術的だ。
23時、歯磨き（上下それぞれ80回）、ドアのロック確認（5回）、カーテンの隙間チェック（0.8mm以下）、ルームメイトへの「明日の朝7時32分に僕が目を覚ます音で君が驚かないように気をつけてくれ」というメッセージ送信を終えた。
就寝時、僕は弦の非可換代数構造を思い浮かべながら眠りについた。もし夢が理論に変換できるなら、僕のREM睡眠はすでに物理学の新章を記述している。
コンクリートの引っ張り強度評価は、コンクリートの設計や品質管理において非常に重要です。「コンクリートは圧縮強度に比べて引っ張り強度が非常に低い」ため、引っ張り強度の評価は特に構造的な考慮が必要です。
以下、コンクリートの引っ張り強度を評価する方法と関連するポイントについて説明します。
コンクリートの引っ張り強度を評価するためにいくつかの方法がありますが、代表的なものは以下の通りです。
引っ張り試験では、コンクリートの試験体（通常は円柱形や立方体）に引っ張り荷重をかけ、破壊が起こるまでの最大荷重を測定します。しかし、コンクリートは引っ張りに対して非常に脆いため、試験体の製造や荷重のかけ方に難しさがあります。このため、引っ張り試験はあまり普及していません。
コンクリートの引っ張り強度を評価するための最も一般的な方法の一つは、三点曲げ試験です。この方法では、コンクリートの小さな梁（例えば、100mm×100mm×400mmのサイズ）を三点で支え、中央に荷重をかけて曲げます。破壊が起こった際の荷重を記録し、そこから引っ張り強度を計算します。
また、コンクリートの引っ張り強度は、間接的に求める方法もあります。例えば、破壊引張試験や二点曲げ試験などがそれにあたります。これらはコンクリートが破壊される前に、引っ張り強度を計算するために用いられます。
引っ張り強度は直接測定するのが難しいため、一般的にはコンクリートの圧縮強度から引っ張り強度を推定する方法が使われます。圧縮強度が分かれば、以下のような関係式で引っ張り強度を推定できます。
•Ft：引っ張り強度
コンクリートの引っ張り強度は、建物や構造物におけるひび割れや破壊のリスクを評価するために重要です。コンクリートは圧縮に強い一方で引っ張りに弱いので、引っ張り強度が低いと、構造にひび割れが生じやすくなります。これにより、構造物の耐久性が低下する可能性があります。
引っ張り強度に影響を与える要因には、次のようなものがあります。
• 水セメント比：水セメント比が低いほど引っ張り強度が高くなる傾向があります。水分が多すぎるとコンクリートの強度が低下します。
• 骨材の品質：骨材の種類や品質が引っ張り強度に影響を与えます。特に、骨材の粒度分布や表面状態が影響します。
• 硬化温度と湿度：コンクリートの硬化温度や湿度が引っ張り強度に影響を与えるため、適切な養生が重要です。
• 添加剤：コンクリートに添加剤を加えることで、引っ張り強度を改善することができます。例えば、ポゾラン材料や超高性能コンクリート（UHPC）など。
コンクリートは引っ張り強度が低いため、外部から引っ張り応力が加わると、ひび割れが発生しやすくなります。したがって、引っ張り強度が不十分な場合、コンクリートの耐久性や使用寿命が短くなる可能性があります。
コンクリートの引っ張り強度評価は、構造設計や品質管理において非常に重要であり、直接的な引っ張り試験よりも間接的な評価方法がよく使用されます。また、引っ張り強度を適切に管理することで、コンクリート構造物のひび割れや破壊を防ぎ、耐久性を高めることができます。
https://anond.hatelabo.jp/20250930190847#
とりあえず粒度なんてlineのやりとりとかで使う言葉じゃないでしょ
くだけた場で使うような言葉じゃないんだよ。気取っててくせえｗ
https://anond.hatelabo.jp/20250930190847#
とりあえず粒度なんてlineのやりとりとかで使う言葉じゃないでしょ
くだけた場で使うような言葉じゃないんだよ。気取っててくせえｗ
ここは増田です
とりあえず粒度なんてlineのやりとりとかで使う言葉じゃないでしょ
くだけた場で使うような言葉じゃないんだよ。気取っててくせえｗ
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250930190847# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaNusMwAKCRBwMdsubs4+SM77AP4yZaVbjsOooud9tW1rsH7JXAwme6HzowxiQzJsyQ4XegD+LXTj1XEtQNG1lSqg+0xg65JcChqVKzxWayr7tuDYfwQ==OkwN-----ENDPGP SIGNATURE-----
文体としての慣例と、用語の意味との間に比較可能な細かさとかあるの？
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250930184651# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaNunDgAKCRBwMdsubs4+SOqiAPsEUFnragKSedhr11SbrLaCn8rsX24Bxar9r47xy0Je1gD/Strh1AV4zra5Ep7/ote1Axws+8/IEBe9cFcK82R4ogc==mYWe-----ENDPGP SIGNATURE-----
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250930184411# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaNumbAAKCRBwMdsubs4+SMa5AQCwOmbqj2kF6aoxhxPf9uF0ID1K9pxVWpdBVEWtFVeN8QEA/J7z3DT7uEq25wzz29+F7PNZr7b7OngC2MY4nC4PpAM==AxQq-----ENDPGP SIGNATURE-----
