  |
はてなキーワード: 組み込みとは
初期増田を代表する作品。アーケードゲーム文化を濃密に描き、独特の恋愛模様を織り交ぜた異色作。オタク的な趣味嗜好と青春の機微を見事に結びつけ、SNSでの共感を呼んだ。
「非モテ」というネットスラングから生まれた作品。リアルな空気感とコミュニケーション不全の描写が、ネット世代の心を掴んだ。増田の読者層と主人公の世界観が見事にシンクロした代表作。
ネットの匿名掲示板で話題となった体験記をコミカライズ。メンタルヘルスという重いテーマを、独特のタッチで描き切った意欲作。増田らしい「実話系」作品の代表格。
★人間のいない国（岩飛猫）
SNSでバズった設定を基にした作品。ディストピア的世界観と緻密な心理描写が特徴。「増田」的な物語の語り方を確立した重要作品。
学園モノの新機軸。SNSやメッセージアプリを介したコミュニケーションを自然な形で物語に組み込み、現代の青春を描いた秀作。
ネットスラングや若者文化を巧みに取り入れた学園コメディ。Twitterでの実況を意識したような展開と台詞回しが特徴的。増田的ユーモアの代表作。
メンタルヘルスの問題を独特の視点で描いた異色作。匿名ダイアリーのような告白調の語りと、シュールなギャグを織り交ぜた増田らしい作風。
オタク文化とネット用語を駆使した異世界モノ。「おっさん」視点のネタと考察の深さで、匿名掲示板発の物語としての新境地を開いた。
SNS時代の複雑な人間関係を描いた恋愛作品。誤配や取り違えというネット小説的な設定を、リアルな心理描写で昇華させた秀作。
アイドルカルチャーとSNS時代の闇を描いた意欲作。匿名掲示板的な情報戦や、ネットでの炎上を巧みに物語に組み込んだ増田的傑作。
これらの作品は、ネット文化やSNS時代の人間模様、匿名掲示板発の独特な語り口、現代的なコミュニケーションの機微など、「増田」的な要素を色濃く持つ作品として選定しました。作品それぞれが、インターネット時代における新しいマンガ表現の可能性を示している点で重要です。
陰謀論が広まる背景には、情報の誤解やバイアス、感情的な反応が関わっていることが多いです。そのため、陰謀論を特定し、理論的に検証するためのチェックリストを作成しました。このチェックリストは、個人がある情報が陰謀論であるかどうかを判断するのに役立ちます。
• 提示された証拠が、信頼できる学術的なデータや確立された研究に基づいていないか？
• 情報源が匿名であるか、もしくは特定の意図や利害関係を持つ団体から発信されているか？
2. 反証可能性の欠如
• この理論が誤っていることを証明するための明確な基準が存在しないか？
• 反証が行われても、それを「さらなる証拠」として組み込み、理論を変えずに強化してしまう傾向があるか？
• 「彼ら」や「エリート」といった敵対者の存在を強調し、意図的に何かを隠していると主張しているか？
• 特定の個人やグループを悪意ある陰謀の主犯と決めつけ、その意図を過度に強調しているか？
• 複雑な社会問題や出来事を、極端にシンプルな原因や特定のグループのせいにしていないか？
• 「全てはこうすれば説明できる」といった形で、他の可能性を排除しているか？
• 「真実を知っている」特別なグループに属することで、他者よりも優れていると感じさせる要素があるか？
• 信頼できる専門家の意見を無視し、「専門家は信用できない」「真実は隠されている」と主張しているか？
• 事実を確立した科学的なコンセンサスに対する不信感をあおっていないか？
• 単なる偶然の一致を、何か意図的な行動の証拠として捉えていないか？
• 他の主張と矛盾する事実や情報が出てきた場合、それを無視するか、または歪曲しているか？
• 主張が「大きな秘密」や「隠された真実」に依存しているか？
• 「普通の人はこの情報を知らない」という形で排他的な姿勢をとっているか？
• この情報がソーシャルメディアや陰謀論者のコミュニティを通じて広まっているか？
• 大手の報道機関や信頼性のある情報源ではほとんど取り上げられていないか？
• 批判的思考を養う: 情報を鵜呑みにせず、事実確認を行うための批判的思考を持つことが重要です。異なる視点や反証の探求に努めましょう。
• 信頼できる情報源の活用: 学術論文や信頼できる報道機関の情報を確認し、複数の信頼できる情報源から情報を収集することを習慣化します。
• 対話の促進: 陰謀論に傾倒する人と対話を試みる際には、感情的にならず、相手の考え方を理解しつつ冷静に事実を示すことが効果的です。
• デジタルリテラシーの教育: 誤情報や陰謀論を見分けるためのデジタルリテラシー教育を推進し、より多くの人々が正確な情報にアクセスできるように支援します。
消費者集合：N = {1, 2, ..., n}
消費ベクトル：各消費者 i の消費ベクトルを X_i ∈ X_i ⊆ ℝ^(k_i) とする。
個人効用は自分の消費 X_i と政府支出の使用用途 G に依存する。
税収：T ∈ ℝ_+
国債発行額：B ∈ ℝ_+
政府支出の配分：G = (G_1, G_2, ..., G_m) ∈ G ⊆ ℝ_+^m
政策空間：P = { (T, B, G) ∈ ℝ_+ × ℝ_+ × G }
予算制約：
Σ_(j=1)^m G_j = T + B
可処分所得：消費者 i の可処分所得 Y_i は、所得税 t_i によって決まる。
Y_i = Y_i^0 - t_i
T = Σ_(i=1)^n t_i
p_i · X_i ≤ Y_i
目的：政府は社会的厚生 W を最大化するために、以下の政策変数を決定する。
国債発行額 B
政府支出の配分 G = (G_1, G_2, ..., G_m)
制約：
消費者の最適化：政府の政策 (t_i, G) を所与として、各消費者 i は効用を最大化する。
最大化 U_i(X_i, G)
X_i ∈ X_i
制約条件：p_i · X_i ≤ Y_i
結果：各消費者の最適な消費選択 X_i*(G) が決定される。
W(U_1, U_2, ..., U_n) は個々の効用を社会的厚生に集約する。
合成関数：
W(U_1(X_1*(G)), ..., U_n(X_n*(G)))
最大化 W(U_1(X_1*(G)), ..., U_n(X_n*(G)))
{ t_i }, B, G
制約条件：
Σ_(j=1)^m G_j = Σ_(i=1)^n t_i + B
t_i ≥ 0 ∀i, B ≥ 0, G_j ≥ 0 ∀j
X_i*(G) = arg max { U_i(X_i, G) | p_i · X_i ≤ Y_i } ∀i
X_i ∈ X_i
政府の役割：公共財の配分 G と税制 { t_i } を決定する。
消費者の反応：消費者は政府の決定を受けて、最適な消費 X_i*(G) を選択する。
(b) 力学系の特徴
スタックルベルクゲーム：政府（リーダー）と消費者（フォロワー）の間の戦略的相互作用。
最適反応関数：消費者の最適な消費行動は政府の政策に依存する。
(c) 一階条件の導出
L = W(U_1(X_1*), ..., U_n(X_n*)) - λ ( Σ_(j=1)^m G_j - Σ_(i=1)^n t_i - B ) - Σ_(i=1)^n μ_i (p_i · X_i* - Y_i)
微分：政策変数 t_i, B, G_j に関する一階条件を計算する。
チェーンルール：消費者の最適反応 X_i* が G に依存するため、微分時に考慮する。
(a) 公共財の種類
公共財ベクトル：G = (G_1, G_2, ..., G_m)
例えば、教育 G_edu、医療 G_health、インフラ G_infra など。
U_i(X_i, G) = U_i(X_i, G_1, G_2, ..., G_m)
各公共財 G_j が個人効用にどのように影響するかをモデル化。
将来への影響：国債発行は将来の税負担に影響するため、長期的な視点が必要。
制約：債務の持続可能性に関する制約をモデルに組み込むことも可能。
(c) 公共財の最適配分
優先順位の決定：社会的厚生を最大化するための公共財への投資配分。
政府の決定問題：消費者の反応を予測しつつ、最適な { t_i }, B, G を決定。
情報の非対称性：消費者の選好や行動に関する情報を完全に知っていると仮定。
消費者の行動：政府の政策を所与として、効用最大化問題を解く。
結果のフィードバック：消費者の選択が社会的厚生に影響し、それが政府の次の政策決定に反映される可能性。
(a) モデルの意義
包括的な政策分析：政府の税制、国債発行、公共財の使用用途を統合的にモデル化。
最適な税制と支出配分：社会的厚生を最大化するための政策設計の指針。
一般性の確保：特定の経済状況やパラメータに依存しないモデル。
政府は、税制 { t_i }、国債発行額 B、そして公共財の配分 G を戦略的に決定することで、消費者の効用 U_i を最大化し、社会的厚生 W を高めることができる。
このモデルでは、政府の政策決定と消費者の消費行動という2つのステップの力学系を考慮し、公共財の使用用途も組み込んでいる。
[0. はじめに]
東京ヤクルトスワローズというと、東京・神宮球場を本拠地とするNPBセントラルリーグの人気球団のひとつである。数年前には、セ・リーグ優勝、日本一ともなり、なかでもそのマスコットキャラクターのつば九郎は、ドアラ(中日ドラゴンズ)とともに大人気である。そんな球団もここ数年は低迷しているが、2020年から3年余りのコロナを経て来場者は爆増である。ただ、この来場者増はどの球団でも同じ傾向であり、行動制限をともなう3年余りの反動と思われる。
[1. 本題]
野球観戦人気が高まり観戦チケットは球団公認ファンクラブに入っていないととても買いづらい状況である。こうしたファンによっては、全球団のファンクラブに加入していたり、シーズンシートオーナーになったりするケースがある。そこで、ヤクルトファンクラブ更新システム障害の件になる。
事前告知があり、2024/9/17 14:00- ヤクルトファンクラブ更新が開始された。このシステムにも問題があり、ログインできない、項目を入力して選択して次を押しても進めない、エラーで元に戻り最初からやり直す、といったシステム障害が発生し、70分後の15:10頃にシステムメンテナンスとなり、一時停止となった。
こうしたチケット販売システムと同様の特性として、発売時間からシステムへの膨大なアクセスが発生し、システムダウンや一時利用制限に至る事はヤクルトファンクラブ更新システムだけでなく、他でも多く見られる。
例えば、広島カープ公式チケットサイト(2月から3月頃に一斉に全試合を発売)、阪神タイガース公式チケットサイト(2月から3月頃に一斉に全試合を発売)、ぴあ、イープラなど。他には、iPhoneオンラインショップなど、大変だった記憶があるでしょう。
当然、ヤクルトファンクラブ更新システムの詳細は公開されていないが、システムの挙動から主な構成を書く。
一般的な、Webシステム構成で、[Web/APサーバ(Apache)] - [DBサーバ]のシングル構成となっており、恐らく拡張性は低く、Web/APサーバ1台、DBサーバ1台(Non-FT, Non-Cluster; Non-HotStandby, Non-ColdStndBy)とみられる。
Webサーバは、It works!と表示されているページがあったことから、Webサーバ(Apache)と見られる。セキュリティ設計・設定は詳細まで詰められていない可能性があると見られる。
関連システムとして、スワクルファンクラブシステム(NPB12球団の共通的な仕組み; どの球団も同じ構成)、スワチケ販売システムがあり、[DBサーバ]にはファンクラブ会員テーブルが存在している。
アプリケーションは、1) ファンクラブ新規/更新メンバーチェック、2) ファンクラブ会員種別選択、3) ファンクラブ特典選択、4) 決済方法選択(クレジットカード決済)、といった流れになっている。ここで問題である業務設計としての画面遷移が、i) スワクルファンクラブシステムへのログイン、から 2) ファンクラブ新規/更新メンバーチェック、になっているあたり。
スワクルファンクラブシステムへのログイン認証をしておきながら、次の画面で、会員番号、生年月日、電話番号を入力させて新規/更新メンバーチェックとして、DBを全検索している。DB全検索の負荷が高く、このあとの画面でも毎回同じ検索が実行され、ログイン及びセッション情報をもって何度も検索されることでさらに負荷が上がる。WebシステムとしてもSubmitボタンを連打できてしまうことでこの負荷が際限なく上がってしまう。このように、少ないユーザでは問題とならなかった動作が同時多数になることで動作できなくなってしまう。
これにより、何度もシステムを再起動していたものとみられる。(submitでの検索が全く反応が無くなることがあったことから。)
[4. 原因と対策]
→ 今更、そんなすぐにはできない。
→ 現実的にはこれかな。スワクルファンクラブシステムへのログイン後に会員種別で更新画面への遷移バナーを用意して順次、更新システムへ誘導。
→ 今更、そんなすぐにはできない。年1回だけしか使用しないものにお金を掛けることがきっと見合わない。
→ 今更、そんなすぐにはできない。F1チケット販売システムなどで使用されている待ち行列システムを間に挟むパターン。
Ref.
https://www.yakult-swallows.co.jp/news/detail/30203
【お詫び】2025年度Swallows CREWの入会受付再開について
https://www.yakult-swallows.co.jp/news/detail/30269
[コメント]
システム障害から挙動をみて何が問題でどうしたら良いのかまで、即時に思いついてしまうのだが、文字に起こしてこれを分からない人にも理解できるような文章、図解して、、予算関係者に承認貰って実施して、となると大変だよな。外から見てるだけで、やるべきことも見えるんだけどきっとこういうシステムを担当している人は業務もシステムも精通してないから、何が問題でどうしたらいいのかまで思いつかないのかもなー。システムごとに導入ベンダ、運用ベンダーが各社入り乱れると、責任範囲も違うしこうすればいいのにってのも非常に調整が難しい。
2) 会員種別による段階的システム開放、の対策案で進められると思うから、とっととやってください。
それにしても、プロ野球シーズンはまだ終わってないのに来期のファンクラブ会員募集って気が早すぎるよなあ。顧客満足度を上げて更なるリピートする仕組みを構築していくためにできること、他にすべき仕事があると思うのだけど、まあいいや。
情報工学系の学生だったんだけど、サークルの先輩５人ぐらいから「SEもコーダーもマジでブラックだ！もうこの業界は駄目だ！俺は組み込み系とかに行くけど、そうやって逃げるやつだらけで転職もまともに出来ない！」と言ってるのを見聞きして、俺はIT系に進むのを辞めた。
結局俺が進んだ業界もそこそこにブラックで転職しても転職してもハズレだらけで「あーこれならプログラマーでもやってりゃ良かったわ」とずっと後悔してた。
それから２０年ぐらいして、長く関係の続いてる人やネトゲとかで繋がりがあった４０代５０代ぐらいのIT業界の人間が少しずつおかしくなっていくのが分かってきた。
プログラマー３０代定年説って奴の亜種何だと思うんだが、最新の技術についていけずレガシーな分野でつまらん仕事を高いとは言えない給料で延々とやることのストレスがあるようだ。まあ大部分は直接顔も合わせずにブログやツイッターの書き込みを読むだけの情報だけど。
肩書だけ上の方について、若手がキラキラした仕事をしているのをサポートするばかりで自分が前線には立てなくなっているとかなんとか。
彼らが出世競争に敗れて、上の方で指揮を取って自分の理想を現場に叶えさせる立場に立てなかっただけな気もするんだけど、年齢的なのもあってそこから独立して自分の理想通りの軍隊を作るみたいな気力はないらしい。
というか、俺の知り合いだけあって最初からそういう気力なんてないような人間、それこそ「IT業界で極めればｶﾁｬｶﾁｬﾀｰﾝマクロポチーで仕事終わってあとはテレワークをいいことに時間つぶしてゲームでもやってりゃいいぜ！」ぐらいの感覚の人間が多かったってのはありそう。
どんなにレガシーな技術を使ってても、ベースとなる部分がドンドンアプデやサービス終了をかますせいで新しいことを覚え続けることからは結局逃げられず、その癖自分の頭はボケていくってことに相当苦労してるようだ。
俺は逆に職場の他の人がパソコンに疎すぎるせいで所謂「大先生」のポジションになり、マクロや数式の補修をチョコチョコやるだけでクソほど褒められる。
まあオマケ程度の雑用ばかりだから評価シートに書いても全然査定が有利にならんので、昇給レースで敗北しきった負け犬ポジションではあるんだけど。
俺が２、３０年「悔しい！俺もあの業界で飯食ってればよかった！仕事が毎日つまらなすぎる！」と嫉妬していた人達は別に俺より楽しそうに生きてない。
俺と大差ないレベルで死にたいとか辛いとか金がないとか居場所がないとか結婚できてないとか老後が怖いとか趣味がゲームとアニメしかないとか言っててまあ要するに同じレベルで人生が終わっている。
結局、俺達にはどの業界だろうが等しく生きていくための才能がなく、ITに行ったら行ったで「他の業界にすれば良かった！仕事がずっとクソすぎる！」と叫んで暮らしていたんだと思うんだよな。
そして、どの業界に行った所で「アレ、実は俺の仕事なんだよね」なんて言えるような仕事はなく、どっかのゲームの小さな大会で３位になったとか、サラリーマン川柳で下の方の賞を取ったとか、小学生の頃に読書感想文コンクールで入賞したとか、そういうクッソほどしょーもないことを人生における数少ないトロフィーとしてずっと誇って生きていくのだろう。
普通の人はミドルエイジクライシスとか言って３０代で発症して３０代で治るものを、俺は１０年早く発症して１０年遅く治しているって考えるとさ、マジで生きる才能がないんだなあ。
生きる才能がないなりに頑張ってるなあ。
IT土方です。ゲーム開発を仕事としたことはないけど、だいたい同世代っぽいので反応します。
ゲームエンジンに相当する根っこの部分を実装するチャンスがなくなっちゃったって話、似た話題はITだと大体どの分野でもあるとは思いますね。
たとえば昔はCOBOLで自前でデータ操作してたけど今はデータベース（RDBMS）使うよね、とか。
携帯の新端末が出るたび何百万行っていうコード量のOS開発してたけど今はAndroidになっちゃったね、とか。
それを寂しいとか退屈とか感じる理屈はわかるけど、でも自分はそこにあまりネガティブな感情は無いんですよね。
こっちはこっちでプライド持ってやってるけど、とはいえ究極的には自分の作ってるソフトなんて全然つまんねえからね（ゲームと比べると）。
「生産性向上」って言葉にしたらみなさん鼻で笑いますけども、でもOracleやMySQLがやってることを自前で実装しろっていわれたら冗談じゃないわけですよ。
まあ実装はなんとかできるかもしれないけれども、その自前のトランザクション管理がバグって客先環境のデータ壊れちゃってみたいな運用まで考えるとね。。。
そのあたりの根っこの部分をまだ「買って終わり」になってないのは組み込み屋さんだと思う。車載OSとか。
理論上めちゃくちゃブラックなはずなんだけど、あまり話が聞こえてこないんだよね。どこも内製してて転職市場に流れないからなのかな？
自分が子供のころはPCとかマイコンって「ゲームを作ろう」から始まったけど（ベーマガ的な）、
今の子ってMincraftみたいなブロック組み合わせてLegoマインドストームみたいなロボット制御するのが初手だったりするから、生産性向上ヤバイ
うまくまとまらんけど、
https://b.hatena.ne.jp/entry/s/zenn.dev/sta/articles/2024-08-10-sat-what_is_si
Web系とSIerがネット上では対立してるって言ってるけど、Web系がSIerや電機メーカ(組み込み系)を馬鹿にする内容がほとんどだよね。
ソフトウェアで食ってるという共通点だけで、ビジネスモデルが違えば求められるスキルセットも全く違う(Web系はハードスキル、SIやメーカはソフトスキルを重視しがち)のに、自分たちの基準で他人を測ることに何の意味があんの？
そんなにWeb系が賢くてSIが馬鹿なら、SIの方が儲けてるんだからさっさと成り代わって代わりに稼げばいいじゃん。個人単位でも技術力軽視なSIerに異世界転生して無双とか出来るんじゃないの？でも現実はそうなってないよね？なんでだと思う？
ソフトっていうと、Web、サーバー関係、ゲーム、組み込み制御などを日本では暗に指している。
半導体を設計するためのEDA、機械関係のCAEのようなシミュレーション系、工場の工程最適化するようなオペレーションズ・リサーチとか、
そういうので実務に耐えられるのがない。
製造業はソフト軽視だから、という意見が出ると思うが、指摘で導入が期待されているのは、Web経由で管理するソフトとか、ラズパイでデータ収集とか、そういうのだろう。
CPUやGPUは皆大好きだが、実際どう設計するかは共有されてないし、ソフトが対応しないと設計が出来ない。
業務で機械学首（データマイニング）、Web（業務システム）、組み込み（産業インフラ設備）の経験があるので、分野ごとの相違点と発生しがちな軋轢を書いておく。
| - | 機械学習 | Web開発 | 組み込み開発 | 発生する軋轢 |
| コードの寿命 | 半年間 | 20年間 | 40年間 | 組み込み開発er「産業系の組み込みは発売から40年後にアップデートするケースもあるので、ドキュメントは、開発担当者が全員退職して誰も残っていなくても理解できるように書いてください！」 |
| コードのアップデート頻度 | 試行錯誤しつつ随時 | 2週間に1回 | 半年～5年に1回 | Web開発er「組み込みはどうしてそんなに時間がかかるの？アジャイルを導入してください。ウォーターフォールは硬直的でデメリットばかりですよ」 |
| アップデートの提供方法 | -（コードは少人数の同僚だけで使用） | サーバに自動デプロイ | 技術者が現地訪問してアップデート | 組み込み開発er「アジャイルだから最初は若干のバグを残して発売し後日アップデートするって？グローバルで既にXXX台受注しているけど、誰が現地に行くの？費用を負担する部署はどこ？」 |
| 開発者の属性 | 数理系の修士～博士、少数精鋭 | 専門学校～修士、文理混在、大人数 | 電気系、機械系、情報系の修士～博士 | 機械学習er「数式で表現できない知識は民芸品です。エンジニアを名乗っちゃダメでしょ」 |
| 関係部署 | マーケティング・企画 | 顧客 | ハード開発・工場 | 組み込み開発er「納期3カ月前なのにソフトが完成していないの？生産立ち上げを工場に相談していない！？スケジュールをゴールから逆算できなかったの？？今回は船便での輸送になるけど、それも計算に入れてあるよね？」 |
| 計算資源 | 潤沢 | 予算次第 | 貧弱 | 組み込み開発er「データマイニングやってたKさんがOSSを使うらしいけど、サイズが5MBあるんだぜ。5MB全部必要なのか聞いたら一部機能しか使わないんだって。で、他チームとの容量調整は丸投げされたの。感覚を破壊されるよな。」 |
| 3rdパーティライブラリ | OSS | OSS | 買ってくる | 組み込み開発er「OSSに不具合があったらどうやって修正して顧客にデリバーするつもりなんだろう？リスク移転の考えで、不具合の補償契約込みで買えばいいのに」 |
| 通信プロトコル・データフォーマット | 生データが王様なので、生データに従う | 最新のものを取り込む | 実績重視 | Web開発er「HTTPの実装がないの？TCPを直接使う！？暗号化や認証はS社の独自プロトコル？古いプロトコルを使い続けているから開発効率が低いんだよ」 |
| 電源OFFタイミング | 任意にコントロール可能 | 定期メンテナンス | コントロール不可 | 組み込み開発er「ファームウェアアップデート中に電源OFFしたらどうなるの？ファイル書き込み中の電源OFFは？状態遷移図って知ってる？」 |
| 性能 | 出来高 | 顧客要件、常識、予算に従う | ミリ秒～マイクロ秒単位のタイムスライスで管理 | Web開発er「性能改善でXX関数の10ミリ秒を1ミリ秒以下に短縮するために2週間も試行錯誤したって？プロパ社員の人件費は7万円/日だから70万円を消費したね？AWSでEC2の性能を調整すれば2000円/月で解決だよ。損益分岐点は350カ月だけど顧客のこれまでのリプレース実績から判断してこのシステムはそこまで長期間使われない」 |
| 学会発表・特許 | 結構ある | ほぼなし | 年1件の特許出願ノルマ | 組み込み開発er「学会発表も特許出願もなく、何を開発したの？ドメイン知識をソフトウェアに翻訳してAWSでポチポチやっただけなの？開発行為ではなく作業だね」 |
分野ごとに要求される製品特性が異なるから、異分野に移ると文化摩擦が起きるという話だと思う。製品特性の違いを理解し自らの行動に反映できるようになるには、ベテランでも数年かかるケースがある。開発期間10年のテーマを経験したことがあるが、そうした場合だとワンサイクルを経験するのに10年かかるので。経験から学ぶのが愚者、歴史から学ぶのが賢者ともいうが…。
競プロと機械学習系のクソコード・クソジャークっぷりが取り立たされてるけど、クソコード・クソジャークっぷりは何も競プロerと機械学習erの専売特許ではない。
