  |
はてなキーワード:マルチとは
・せっかちになった
若い頃はだらだら決めもせず結局やらない、みたいなことが仕事でもプライベートでも多かったが、
仕事上、とにかく前に進める！という経験(だらだら進めずに失敗した経験)を経て、
なんだも先に決めようという癖がついた。
若い頃はちゃんと話を聞いたうえで、怪しいアンケートだったりしたらスルーしていたが、
実際、ほぼすべてが「あやしいアンケート」「マルチの勧誘のきっかけ」などなど‥
なので最近は一言だけ聞くか、場所的に確実にあやしい確定のときは手振りで無視してる
道に迷ってる人とか、人を助けたい派なんだけど、
こないだ明らかに道に迷ってる老夫婦がいたので「何か探してますか？」と声をかけたら
おばあちゃんのほうが「え？ああ‥」と明らかに拒否の目線で返事をされたのでイラッときて
「あ、大丈夫っすね、じゃ」と冷たく去ってしまった。(実際おばあちゃんは拒否だったのでそれでいいのだが)
おじいちゃんの方は「えっとね‥」と話そうとしていたことに気づいたがおばあちゃんの拒否にいらっときて無視してしまった
いきなり俺の↑の逆で、いきなり若いやつに声かけられたら警戒しちゃうよね。
なんとなく様子見て、目が合えば声かける、とかにすればよかったかなと。
それか新宿だったから、警察もいっぱいいるし、無理に助ける必要もなかったのかも
・たまに何かがやけになる
「すべてがくだらん〜！」「すべてがつまらん〜！」「おれはこのまま死んでいくんだ〜！」「っていうか実際友達死んじゃったよ〜！」となることがあります。
鬱かと言われるとそんなことはなく、仕事もプライベートも通常運転でそれなりにやりがいや嬉しみも持ちつつやっていますが、
なんかたまにこんな気持になる
人並みの生活をしてきた21歳だが、これからまだ人生詰みポイントがいくらでもあるのが怖い。
・急に難病になる
・人に騙される
・変な人に粘着される
・知らないうちに犯罪者になる
平凡に生きたい
「作りたがる奴ばかり多くて、受け手が圧倒的に少ない界隈」地獄じゃね
具体的に言うと、個人アプリ開発、インディーゲーム開発、個人Vtuber､歌い手､ハンドメイド、物書き､ピアノとか
誰かが作品をリリースする。「すごい！」「リリースおめでとうございます！」とリプライが飛ぶ。
一見、活気があるように見える。
これ、何が起きてるかっていうと、全員が「次は自分の番だ」と思って義理いいねを投げ合ってるだけ。
純粋な客なんてどこにもいない。
で、この構造の中で唯一、確実に儲けてる奴らがいる。
「ツルハシ売り」だ。
ゴールドラッシュの時と同じことが､現代のクリエイター界隈でも起きてる。
作り手ばかりいるから、そこをターゲットにした商売だけが肥大化していく。
「何かを作って表現したい」という純粋な欲求が、カモとして養分にされていく。
一番闇が深いのがこれ。
最初はみんな純粋に「良い作品を作りたい」と思って参入するんだよ。
でも、すぐに気づく。「あ、これ誰も見てねえわ」って。
市場には供給が溢れかえっていて、可処分時間の奪い合いですらない｡ただノイズをつくってネットの海に投げてるだけ。
そこで心が折れたけど､飯は食わなきゃいけない人間がどこに向かうか。
「作りたがる人にノウハウを売る側」に回るんだよ。
「アプリが売れなかったから、バイブコーディングの稼ぎ方を売って稼ぐ」
「ハンドメイドが売れなかったから、ハンドメイドの稼ぎ方を売って稼ぐ」
#新人〇〇さんとつながりたい
みたいなハッシュタグにはこういうワナビーをカモにする側に回った連中が殺到する
始めたばかりの新人は不安だし､作品を発表しても受け手もいないので孤独だ｡そこに奴らは接触してくる｡
新人から見たら相手は経験豊富な先輩だし､｢〇〇◯万円稼いでる｣とプロフにも書いててすごい存在に見えてしまう｡
そうして信頼関係を築いたあと､DMで高額商材を売りつけてハメる｡常套句は｢すぐ稼げて元取れるから｣
最近歌い手や個人Vtuber界隈でちょっとした騒ぎになってたやつね
商品じゃなくて、夢を売って会員を増やしていく。
末端の会員（新規参入者）が金を出して、古参がそれを吸い上げる。
｢夢を諦めるな！｣
もういいよ。
みんな、頼むから「客」になってくれ。
Permalink |記事への反応(31) | 13:28
紹介文にネタバレあり
・連載中
https://kakuyomu.jp/works/1177354054888930318
異世界に転生した少年が前世から持ち越したのは恨み、憎しみ、飢え、渇きのみ。
暴力が支配するこの世界でどれだけの戦場を駆け巡れば恨みや憎しみは消え去るのか。
どれだけの敵を殺せば飢えや渇きは癒やされるのか。
人類全員に読んでほしいので何回でも紹介する。
5ちゃんねるのWEB小説感想スレにてループする話題「なぜこれが書籍化しないのか？」において常にトップに上がる作品が満を持して書籍化。
もし読んでみて「つまらなかった」「時間を無駄にした」と思ったら、スベったブコメにカラースターを進呈するのでこっそり知らせてほしい。
・連載中
https://kakuyomu.jp/works/1177354054885436251
債権奴隷に落ちた少年は借金返済のため冒険者となって迷宮で一攫千金を目指す。
力がなく戦士になれず、信仰心が低いので僧侶になれず、不器用なので盗賊になれず、学校で学べば誰でもなれる魔法使いで迷宮に挑む。
一度は書籍化したものの1巻打ち切りにあい、出版社を変え6年後に再刊行を果たし「このライトノベルがすごい！2026」第8位に輝く。
扱いの軽い命、がめつい教会、疲れの取れない宿屋、ボッタクリの店、そうウィザードリィだ。
読者感想欄でもWizネタで盛り上がるのでプレイヤーなら2割増しで楽しめるが、知らなくても2割引きにはならないので是非読んでほしい。
血と汗にまみれ、汚泥にまみれ、吐瀉物にまみれ、魔物の臓物にまみれ、拷問をする仲間、思いやりと人情のある敵、罪悪感と後悔、苦い後味、うらやましくないハーレム、そんな小説が好みならおすすめ。
コミカライズは商業とpixivのファンメイド（原作者公認）があるが、pixivの方が面白い気がする。
・連載中
https://kakuyomu.jp/works/16816927862215511326
少年が見る夢は正夢なのかそれとも過去の巻き戻しなのか、それとも他人の人生なのか。
母と妹を守る為、見た夢に従って動き出した少年は大きな運命に飲み込まれていく。
その夢は本当に少年を正しい道に導いているのか。
ただ母と妹を守りたかっただけなのに。
陰謀や権謀術数に否応なく巻き込まれていくのでスカッとする展開も少なめ。
主人公の恋愛要素もないし（同年代の異性が登場するのは妹を除けば180話以降）チートもない。
少年同士の友情や騎士の絆がメインなので、女性向けかもしれないが勿論男性が読んでも非常に面白い。
思ったよりも評価ポイントが伸びないのは4サイトものマルチ投稿のせいだろうか。
・連載中
https://kakuyomu.jp/works/1177354054886644108
いじめを苦に自ら命を絶とうとした少年は地獄のような異世界に転移する。
それから数十年後、全ての力を手に入れた少年は自殺する瞬間に戻り、今度は自分をいじめたクラスメイト達を異世界に引きずり込む。
流行が2周3周した結果「勇者は善、魔王は悪」どころか「追放側が有能、追い出された方が無能」「主人公がざまぁされる」といった作品もあるが「いじめっ子（正確には傍観者）がいじめられっ子に復讐する」という作品は非常に珍しいのではないだろうか。
その試みが100％うまくいってるとは言い難いが、他にはない味わいなので読んでみてほしい。
・連載中
https://kakuyomu.jp/works/16816927859769787769
作者の前作『カルマの塔』が合わなかった為、食わず嫌いで長い間読まなかった。
文章に癖があり、特に会話文や固有名詞に理解しにくい箇所は多々あるが、それを乗り越えられれば。
読者コメントにネタバレが多く、初回は感想欄は開かないほうが良い。
・完結済
https://ncode.syosetu.com/n4809dw/
作者らしい安定感で期待を裏切らない作品。
リゼロに代表される「死に戻りスキル」が主人公ではなくそばにいる人物が所持していたら……？
現在コミカライズ版のWEB広告が出ているが、これですらエロ漫画風に切り取られてしまうのか…。
・第1部完結 第2部連載中
https://ncode.syosetu.com/n1132dk/
集団転移は非常に難しく、主人公一人が突出化して周りがモブになるか、早々に離脱して別の道を歩む作品が多い。
しかしこれは41人を濃淡はあれどきっちり描ききった作品で、退場後も主人公に影響を与えていく。
クラスメイト同士での殺し合いも多々あり、グロい表現も多く読者感想欄でも忌避感を示すコメントもあるので万人にすすめることはできないが、興味があれば読んでみてほしい。
・完結済 続編連載中
https://ncode.syosetu.com/n5363hf/
よくある異世界転移ものだが、とにかく「処刑人」ラング（51歳）が魅力たっぷりで、この人物一点突破でおすすめしたい作品。若者と年配のバディが好きなら読んでみてほしい。
・完結済
https://ncode.syosetu.com/n7679cq/
どうやらこの世界は終わるらしい。
上記の作品群はまだ甘い？もっとダークでハードなものが読みたい？
書籍化もコミカライズもなく、完結から10年を経て尚、評価ポイントが入り読者コメントも付く名作。
作者は前書きで「デッドエンド・ファンタジー」と警告している。
Permalink |記事への反応(12) | 14:31
と質問とした所、
いい質問。ただ、**今回私が提示したC#コード（MemoryMappedFile + Parallel.For でCR を数える）**には、明確に一つの「このネット上の記事／リポジトリをそのままコピーした」元ネタはありません。
いくつか似たアイデアを使ってる部分と参考になる記事／ドキュメントはあるので、それらを紹介します：
---
*Microsoftドキュメント — Memory-Mapped Files (.NET)*
([Microsoft Learn][1])
*Kieren Johnstone: 高速に MemoryMappedFileからバイト列を読む方法（StackOverflow）*
`MemoryMappedViewAccessor` を使って unsafeコードからポインタを取得し、Marshal.Copy で効率よく読み出す方法。
([StackOverflow][2])
*Red-Gate: Sharingis Caring: Using Memory Mapped Files in .NET*
MemoryMappedFile を使ったキャッシングなどの応用。
*Stephen Cleary のブログ: Memory-Mapped Files と Overlaid Structs*
メモリマップトファイルへ構造体を重ねて（オーバーレイ）扱う方法など。
([blog.stephencleary.com][4])
---
もしよければ、**あなたのコード（CR を数えるもの）に特化した元ネタをさらに探してみます**。やりましょうか？
[1]:https://learn.microsoft.com/en-us/dotnet/standard/io/memory-mapped-files?utm_source=chatgpt.com "Memory-Mapped Files - .NET"
[2]:https://stackoverflow.com/questions/7956167/how-can-i-quickly-read-bytes-from-a-memory-mapped-file-in-net?utm_source=chatgpt.com "How can I quickly read bytes from a memory mapped file in ..."
[3]:https://www.red-gate.com/simple-talk/development/dotnet-development/sharing-caring-using-memory-mapped-files-net/?utm_source=chatgpt.com "Sharingis Caring: Using Memory Mapped Files in .NET"
[4]:https://blog.stephencleary.com/2023/09/memory-mapped-files-overlaid-structs.html?utm_source=chatgpt.com "Memory-Mapped Files and Overlaid Structs"
ChatGPT:
が、出てきて、やってくれと言ったら、こういうのが出てきた。
了解しました — 広く（英語・日本語・GitHub・ブログ・StackOverflow 等）再検索しました。結論と見つかった“近い”ソースをまとめます。
結論（要点）**
「あなたが求めている**MemoryMappedFile を使い、UTF-8バイナリ中の `CR`（0x0D）だけを数える・マルチスレッドで分割して処理する**」という **完全一致の“元ネタ”ソースコード**は、公開されたweb 上のリポジトリや記事の中では見つかりませんでした（複数の検索ワード／検索対象で確認）。([hyr.mn][1])
ただし、ほぼ同種の要素（メモリマップドファイルの読み方・大きなファイルの行数カウント・バイト単位カウントを高速化する手法）は複数見つかりました。これらを組み合わせれば、先に示した実装は典型的なパターンであることが確認できます。([Microsoft Learn][2])
見つかった“近い”・参考になりそうなソース（抜粋）**
1. .NET の公式ドキュメント（MemoryMappedFile の説明） — `MemoryMappedFile` の基本とCreateViewStream /CreateViewAccessor の使い方。必須の参照。([Microsoft Learn][2])
2. 「Countinglines withC#」というブログ記事（C# で改行（CR/LF）カウントに関する実装とGitHubリンク） — 行数カウントを目的とした実装パターンがある。([hyr.mn][1])
3. StackOverflow：MemoryMappedFileから高速にバイトを読む方法（`MemoryMappedViewAccessor` / unsafeポインタ / Marshal.Copy 等の議論） — 高速実装のヒント。([StackOverflow][3])
4. StackOverflow／Q&A：ファイル中のLF/CR の数を求める方法に関するスレッド（`grep -c $'\r'` 等のunix 例やC# でのカウント方法の議論）。([StackOverflow][4])
5.GitHub のサンプルリポジトリ（MemoryMappedFile のテスト／サンプル） —メモリマップドファイルを使う実装例。([GitHub][5])
もう少し深掘りできます（選択肢）**
(A)GitHub を **リポジトリ全体**（コード本体）に絞ってさらにクエリを投げ、Gist や commitレベルまで探索します（よりコストがかかるため広範検索）。
(B)ブログ・技術記事を対象に **全文一致（コード断片）検索** を行い、私が先に示したC#コードの実際の一節（たとえば `mmf.CreateViewStream(offset, size)` や `Interlocked.Add(ref totalCount, localCount)` など）を直接検索して完全一致を探します。
(C) 「オリジナルはGitHub にあるはず」と思われるなら、あなたが覚えている**リポジトリ名の断片／作者名／投稿日**などを教えていただければ、それを手がかりに探します（断片情報があるとヒット率がぐっと上がります）。
どれを優先して探しましょうか？（A:GitHub全探査 / B:コード断片で全文検索 / C:あなたからヒント提供）
※続けて深掘りする場合は、すぐにさらに広い検索を行って該当ソースを探します（そのまま実行します）。
[1]:https://hyr.mn/catching-flowers-with-a-net?utm_source=chatgpt.com "Countinglines withC# - hyr.mn"
[2]:https://learn.microsoft.com/en-us/dotnet/standard/io/memory-mapped-files?utm_source=chatgpt.com "Memory-Mapped Files - .NET"
[3]:https://stackoverflow.com/questions/7956167/how-can-i-quickly-read-bytes-from-a-memory-mapped-file-in-net?utm_source=chatgpt.com "How can I quickly read bytes from a memory mapped file in ..."
[4]:https://stackoverflow.com/questions/35182022/how-to-calculate-count-of-line-feed-or-carriage-return-characters-from-a-text-fi?utm_source=chatgpt.com "How to calculate count ofline feed or carriage return ..."
[5]:https://github.com/byGeek/MemoryMappedFileTest?utm_source=chatgpt.com "test csharp code for using memory mapped file."
utf8の文字コードで構成されたバイナリーファイルがある。このファイルの改行の数を数えよ。改行はCRのみとする。このファイルにはCR が必ず含まれており、CRで分割すればマルチスレッドで処理できる。
size_t count_cr_in_file(conststd::string&path) {
std::ifstreamfs(path,std::ios::binary);
size_t size =fs.tellg();
fs.seekg(0);
const size_tthread_count =std::thread::hardware_concurrency();
const size_t chunk_size = size /thread_count;
std::vector<std::future<size_t>> futures;
for (size_t t = 0; t <thread_count; t++) {
size_t start = t * chunk_size;
size_t end = (t ==thread_count - 1 ? size : (t + 1) * chunk_size);
futures.push_back(std::async(std::launch::async, [start, end, &path]() {
std::ifstreamfs(path,std::ios::binary);
fs.seekg(start);
size_t count = 0;
for (size_t i = start; i < end; i++) {
char c;
if (c == '\r') count++;
}
return count;
}));
}
size_ttotal = 0;
for (auto& f : futures)total += f.get();
returntotal;
}
importmmap
mm =mmap.mmap(f.fileno(), 0,access=mmap.ACCESS_READ)
returnmm.count(b'\r')
c#で書けと指示したところ、
using System;
using System.IO;
using System.IO.MemoryMappedFiles;
{
public static long CountCRInFile(stringpath)
{
using varmmf = MemoryMappedFile.CreateFromFile(path, FileMode.Open, null);
using varaccessor =mmf.CreateViewAccessor(0, 0, MemoryMappedFileAccess.Read);
long fileSize =accessor.Capacity;
int processorCount = Environment.ProcessorCount;
long chunkSize = fileSize / processorCount;
longtotal = 0;
Parallel.For(0, processorCount, i =>
{
long start = i * chunkSize;
long end = (i == processorCount - 1) ? fileSize : (i + 1) * chunkSize;
long localCount = 0;
byte b;
for (longpos = start;pos < end;pos++)
{
if (b == 0x0D) //CR
localCount++;
}
lock (lockObj)
{
total += localCount;
}
});
returntotal;
}
{
long count = CountCRInFile(path);
Console.WriteLine($"CR count = {count}");
}
}
というコードが出てきた。
実際はcrlf,lfもあり得るんだが、そこは考慮しなくてもよく、そう考えるとaiはすごいとしか言いようがない。
なお、utf8として成立する単位で区切りつつ改行を数える場合、もう一工夫いる。
だが、あれを“次世代機”なんて呼ぶのは、あまりにもおこがましい。
あんなの、十年前の設計思想をツギハギした「老朽アーキテクチャのゾンビ」だよ。
エンジンの限界を誤魔化して“効率化”なんて言ってるのは、昭和の家電と同じ発想だ。
まるでワードやエクセルのマクロ地獄を延命し続けたWindowsの焼き直しだな。
結局、Switch2がやってることは“UIのスキンを変えただけ”。
中身はレガシーの塊。
Joy-ConをBluetoothで繋いで、またジョイコンドリフトを再発させる気か？
Cellは賛否両論あったが、“過去の互換”なんていう鎖を自ら断ち切った。
そしてフルスクラッチでマルチスレッド・ストリーミングの未来を提示した。
あれこそ「次世代機」だった。
Switch2？ あんなの“古い泥舟の塗り直し”に過ぎない。
任天堂は“過去資産を捨てない”ことを美徳だと思っているらしい。
AIが使用履歴を解析し、視線追跡と入力予測でゼロレイテンシを実現する――
それが本当の意味での“快適性”だ。
なのにSwitch2のUI？
「スペックじゃない、遊びだ」
――聞き飽きた言葉だ。
Switch2がやってるのは、“過去の懐古”と“子供向けマーケティング”の繰り返し。
21世紀のエンタメを自称するなら、まずOSを捨てろ。GUIを再設計しろ。
Switch2は“過去の遺物”を温め直しただけの奇形化デバイス。
十年後には、PS3が示した理念の方がずっと前衛的だったと気づくだろう。
この国のメーカーが「レガシー互換」という鎖を断ち切れない限り、
Switch2？
といってもやってたのはFFではなく、ネクソンやNCSOFTの韓国ネトゲが主だったけど。
今はmiHoYoのゲームを色々やってる。マルチでMMOっぽい遊び方ができそうなのは原神くらいだけど。
オンラインゲーム続ける気のあるMMOプレイヤーの半数くらいは原神に行ったんじゃないかな。
もしやるなら捨てアド fumo@tensi.org にUIDを送ってくれたらフレ申請するぜ。
世界探索の手伝いでもいいし、マルチプレイ限定のアチーブメントとか自分も全然取れてないからそういうのもいいし。
星々の幻境っていうUGC(ユーザー生成コンテンツ)のミニゲームを一緒に遊んだり、七聖召喚っていうDCG(デジタルカードゲーム)の対戦相手になったりすることもできる。
20代中盤が近づくとこういう感じになるよね。
俺も意識高い系界隈がカッコよく見えて何して食ってるのかわからない人のやってるちっちぇー社会人サークルのイベントとか行きまくったわ。
まあでも今になって思うとこいつらみんなワナビなんだよな。何かになりたいけど何すればいいかわかんないからなんかしてそうな人にくっついて歩いたりそれっぽい会話をして酒を飲む。
本当に何かしたいなら何でもいいから何かした方がいいということに後から気が付いた。
あとこの時期が一番マルチみたいなのにかかりやすい危ない時期だから気を付けてね。
フェミニズムの分類が多すぎると聞いて
記述集合論（Borel階層, Projective階層, 汎加法族）
モデル理論（型空間, o-極小, NIP, ステーブル理論）
再帰理論/計算可能性（チューリング度, 0′, 相対計算可能性）
構成主義,直観主義,ユニバース問題,ホモトピー型理論（HoTT）
体論・ガロア理論
表現論
K-理論
初等数論（合同, 既約性判定,二次剰余）
解析数論（ゼータ/ L-関数,素数定理,サークル法, 篩法）
p進数論（p進解析, Iwasawa理論, Hodge–Tate）
超越論（リンドマン–ヴァイエルシュトラス, ベーカー理論）
実解析
多変数（Hartogs現象, 凸性, severalcomplex variables）
関数解析
バナッハ/ヒルベルト空間,スペクトル理論, C*代数, von Neumann代数
フーリエ解析,Littlewood–Paley理論, 擬微分作用素
確率解析
常微分方程式（ODE）
偏微分方程式（PDE）
非線形PDE（Navier–Stokes, NLS, KdV, Allen–Cahn）
幾何解析
リッチ流, 平均曲率流,ヤン–ミルズ,モノポール・インスタントン
エルゴード理論（Birkhoff, Pesin）,カオス, シンボリック力学
点集合位相,ホモトピー・ホモロジー, 基本群,スペクトル系列
4次元トポロジー（Donaldson/Seiberg–Witten理論）
複素/ケーラー幾何（Calabi–Yau, Hodge理論）
スキーム, 層・層係数コホモロジー, 変形理論, モジュライ空間
多面体, Helly/Carathéodory,幾何的極値問題
ランダムグラフ/確率的方法（Erdős–Rényi, nibble法）
加法的組合せ論（Freiman, サムセット, Gowersノルム）
彩色,マッチング,マイナー理論（Robertson–Seymour）
列・順序・格子（部分順序集合, モビウス反転）
測度確率, 極限定理, Lévy過程, Markov過程, 大偏差
統計学
ノンパラメトリック（カーネル法, スプライン,ブーストラップ）
時系列（ARIMA,状態空間, Kalman/粒子フィルタ）
非凸最適化
離散最適化
整数計画,ネットワークフロー, マトロイド, 近似アルゴリズム
Littleの法則, 重み付き遅延, M/M/1, Jackson網
エントロピー,符号化（誤り訂正, LDPC,Polar）, レート歪み
公開鍵（RSA,楕円曲線, LWE/格子）,証明可能安全性,MPC/ゼロ知識
計算複雑性
機械学習の数理
量子場の数理
相転移, くりこみ, Ising/Potts, 大偏差
数理生物学
数理神経科学
データ解析
一年が過ぎた。あの「何もしてないのに壊れた」事件の三人組は、今や職場のエースだ。
当時は「ディスプレイの電源の入れ方がわかりません」で全員の昼休みを潰した彼らが、だ。
人は成長する。いや、正確には「環境を与えられると覚醒する」というべきかもしれない。
あのあと、一応上司に報告した。「新人がディスプレイの電源を入れられない件について」と題したメールに、
あのときの顛末を淡々と書いた。報告を読んだ上司が言った一言が、すべてを変えた。
……え？
泣きたい。いや、もう笑うしかなかった。
Windowsのレジストリだのバッチファイルだのに全員アレルギーがあったらしい。
「Win端末って……Altキーが右にもあるの、何のためですか？」と真顔で聞かれたとき、
私の中の何かがそっと崩れた。
で、ちょうど一ヶ月後、上層部が「彼らの生産性を最大化するため」とか言い出して、
あっさりMac端末が支給された。MシリーズのMacStudio＋Studio Display構成。
「あ、それComposeで並列処理に変えました」とか平然と言う。
気づけばTerraformで開発環境をインフラ化までしていた。
処理速度？ 正確に計測したら、あのときのWindows仮想環境の十倍。
社内のGitリポジトリの更新履歴が、ほぼ彼らのコミットで埋まるようになった。
「それ、Homebrewで入れましょうか？」
……もう、何言ってるのか半分もわからん。
かつて「ディスプレイの電源が入れられない」と言っていた口で、
ただ、あのときの端末が彼らの性能に追いついてなかっただけ。
今日も彼らの後ろ姿を見ながら、私は小さく笑う。
——何もしてないのに、すごくなったな。
「きょうだい」が多いと学力は低下する？ 学生1900人以上を対象に調査 北大が研究発表
https://www.itmedia.co.jp/news/spv/2510/10/news044.html
分析は、2010～2016年にかけて実施された全国調査のデータを用い、小学1年生から中学3年生までの1971人（1203世帯）の子どもを対象としている。マルチレベル分析という手法により、家族間の違いを統制しながら、同一家族内のきょうだい同士を比較することが可能となった。
分析の結果、きょうだい数については負の影響を確認。算数・数学では一人っ子と2人きょうだいの間に学力差は認められなかったが、国語では2人きょうだいの時点から学力低下が表れていた。3人きょうだいになると両教科で学力低下が見られ、4人以上では更にその傾向が強まった。
少子化対策として、未婚率を下げるよりも既に産んでいる人に2人３人と産ませるべきだという声が大きいが
それをやっていくと優秀な子供の数は減るのでは？
