  |
はてなキーワード:CIとは
そんな日々の中で最も厄介なのは、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の積み重ねだ。
一年が過ぎた。あの「何もしてないのに壊れた」事件の三人組は、今や職場のエースだ。
当時は「ディスプレイの電源の入れ方がわかりません」で全員の昼休みを潰した彼らが、だ。
人は成長する。いや、正確には「環境を与えられると覚醒する」というべきかもしれない。
あのあと、一応上司に報告した。「新人がディスプレイの電源を入れられない件について」と題したメールに、
あのときの顛末を淡々と書いた。報告を読んだ上司が言った一言が、すべてを変えた。
……え？
泣きたい。いや、もう笑うしかなかった。
Windowsのレジストリだのバッチファイルだのに全員アレルギーがあったらしい。
「Win端末って……Altキーが右にもあるの、何のためですか？」と真顔で聞かれたとき、
私の中の何かがそっと崩れた。
で、ちょうど一ヶ月後、上層部が「彼らの生産性を最大化するため」とか言い出して、
あっさりMac端末が支給された。MシリーズのMacStudio＋Studio Display構成。
「あ、それComposeで並列処理に変えました」とか平然と言う。
気づけばTerraformで開発環境をインフラ化までしていた。
処理速度？ 正確に計測したら、あのときのWindows仮想環境の十倍。
社内のGitリポジトリの更新履歴が、ほぼ彼らのコミットで埋まるようになった。
「それ、Homebrewで入れましょうか？」
……もう、何言ってるのか半分もわからん。
かつて「ディスプレイの電源が入れられない」と言っていた口で、
ただ、あのときの端末が彼らの性能に追いついてなかっただけ。
今日も彼らの後ろ姿を見ながら、私は小さく笑う。
——何もしてないのに、すごくなったな。
「ぶっちゃけ日本のIT技術者のレベルが元々低いだけ」論、読んだけど、雑に日本叩き→雑に海外持ち上げの“気持ちよさ”に全振りしてて、論としては穴だらけだよ。順に潰す。
“発明”って規格？論文？OSS？製品？この区別を曖昧にして「思い浮かばない＝ない」をやるのは主観の事実化。
反例を淡々と置く（全部2010年代以降の「世界で通る」技術・成果）：
HTTP/3 / QUIC系仕様・QPACKの主要貢献者のひとりは日本人エンジニア（例：Kazuho Oku）。IETFのRFCはまさに“世界標準”。「世界で通用」どころか世界の土台。
Chainer / CuPy（Preferred Networks）は動的計算グラフ系フレームワークの先行例。PyTorch隆盛の流れに技術的影響を与えた。CuPyはいまも広く使われてる。
ソニーのCMOSイメージセンサは世界シェア筆頭。これは“ハード”に見えて、設計・製造・信号処理・ツール群までソフトの塊。スマホのカメラ品質＝AI前処理の土台。
日本人が中心メンテに関与した高性能HTTPサーバ（H2O等）はCDNや低レイテンシ配信に採用例多数。
産業用ロボット（FANUC、安川）周辺の制御・通信・ツールチェーンは世界の現場で常用。表に出にくいB2B領域は“見えないだけ”。
「LINEが～」みたいなB2Cの派手さだけが“発明”じゃない。基盤を握るのは地味仕事。あなたが気づかない＝存在しない、ではない。
Winny／一太郎／CD-ROM／MIDIを“国民的知名度”で持ち上げて、以後は「思い浮かばない」って、知名度＝技術力の誤用。
2000年代以降、ITは不可視化（クラウド、プロトコル、ライブラリ、半導体、サプライチェーン）へシフト。見えないところほど難しくなった。派手なガジェットが減ったからレベル低下、ではない。
問題領域で言語は変える。Webは「5歳児でも」動かせる？今のWebは、
CD/CI、IaC、K8s、SRE、ゼロトラスト、分散トレーシング、暗号化、フロントの再レンダリング戦略……
これらを運用で落とさないのが本番。Cが偉い／Webが軽い、は90年代の教養で止まってる。
起業に国の試験？それ、フィルタにはなるけどイノベーションの十分条件じゃない。
トップダウンは国家プロジェクトやインフラ敷設には強い。しかし、
分野で強弱は揺れる。制度の一軸で「勝ち負け」を断ずるのは幼い。
それ、犯罪としてのサイバー強盗の話でしょ。規制準拠の金融基盤と国ぐるみのハッキングを同じ土俵で比べるのは、
「百メートル走で銃使えば最速」って言ってるのと同じ。比較の土俵設定から破綻。
日本のITが伸び悩んだ要因は複合要因：内需の構造、調達・多重下請け、英語コミュニケーション、ストック報酬の弱さ、エクイティ文化、大学と産業の距離、IPO市場の質、人口動態、為替…
これを全部「技術者のレベル低い」で片付けると、説明力を失う。制度と資本設計の問題は制度と資本で解くのが筋。
「勝ってる」を“B2Cでバズるアプリ”だけに限定するから見落とす。
最後に一個だけ。
https://biomarkerres.biomedcentral.com/articles/10.1186/s40364-025-00831-w
1-year risks of cancers associated withCOVID-19 vaccination: a large population-based cohort study in SouthKorea
SARS-CoV-2 の発がん性の可能性については仮説的に提唱されてきたが、COVID-19感染やワクチン接種に関する実世界データは不十分である。そこで本研究では、韓国ソウルにおいて実施された大規模な人口ベースの後ろ向き研究により、COVID-19ワクチン接種後 1 年間におけるがん全体の累積発生率およびそのリスクを推定することを目的とした。
2021 年から 2023 年にかけて、韓国国民健康保険データベースから 8,407,849 人のデータを抽出した。参加者はCOVID-19ワクチン接種の有無に基づいて 2 群に分類された。全がんリスクは多変量 Cox 比例ハザードモデルを用いて評価され、データはハザード比（HR）と 95％信頼区間（CI）として表された。
その結果、甲状腺がん（HR 1.351, 95%CI 1.206–1.514）、胃がん（HR 1.335, 95%CI 1.130–1.576）、大腸がん（HR 1.283, 95%CI 1.122–1.468）、肺がん（HR 1.533, 95%CI 1.254–1.874）、乳がん（HR 1.197, 95%CI 1.069–1.340）、前立腺がん（HR 1.687, 95%CI 1.348–2.111）が、ワクチン接種 1 年後に有意に増加していた。
ワクチンの種類別にみると、cDNAワクチンは甲状腺がん・胃がん・大腸がん・肺がん・前立腺がんのリスク増加と関連し、mRNAワクチンは甲状腺がん・大腸がん・肺がん・乳がんのリスク増加と関連していた。また、異種混合接種は甲状腺がんと乳がんのリスク増加と関連していた。
これらのCOVID-19ワクチン接種とがん発生率との関連が年齢・性別・ワクチン種類によって認められたことから、特定の集団において最適なCOVID-19ワクチン接種戦略が存在するかどうかを明らかにするために、さらなる研究が必要である。
こないだ、IL-6でがんが活性化するとかいう話もあったが、コロワクもちゃんと検証しないとやべーだろ
例:CI/CD完全攻略！現場エンジニアが教えるAPIテスト不足の解決法
https://qiita.com/Nakamura-Kaito/items/8c56e7402a8fe5081e33
どうせApidog宣伝してるんだろうなと思って開いたら本当にしていたので、今回は興味本位でこの投稿者のアカウントを掘ってみた
@Nakamura-Kaito:https://qiita.com/Nakamura-Kaito
フォロー中のOrganization:株式会社野村総合研究所 ※ApidogのスパムはNRIフォローしがち
さて、まずアカウントのフォロワーを調べてみると、どっからどう見てもスパムだらけ
@digitalsmmstore54731フォロー
@digitalsmmstore58331フォロー
※これらフォローされているアカウントすべてがスパムアカウントやフォロワー買いという話ではない
https://qiita.com/digitalsmmstore583/following_users
@rana_kualu@sakes9@satokenichi@MIDO-ruby7
https://qiita.com/digitalsmmstore547/following_users
@rana_kualu@sakes9@satokenichi@MIDO-ruby7
※これと同じようなフォローリストを形成してるスパムはいくつもあったが、木を隠すなら森の中方式か否かは調べないと分からない
フォローリストの一番下を見ると、Qiita公式とともにこのアカウントがある
佐伯真人@makotosaekit求職中
このQiita公式と佐伯真人のフォロー順序が、2つのアカウントで微妙に異なっていた
digitalsmmstore583は：
2.Qiitaキータ@Qiita1.佐伯真人@makotosaekit
digitalsmmstore547は：
2.佐伯真人@makotosaekit1.Qiitaキータ@Qiita
不思議ですね
というわけでこの`佐伯真人@makotosaekit` が気になったから、いいね100を超えた最初の記事を見てみた
AIを「物知り博士」から「知的パートナー」へ。「背理系」プロンプトエンジニアリングAIhttps://qiita.com/makotosaekit/items/ca9f707f8718d7c2471d
1. @deihate2. @p_kun
https://qiita.com/deihate/likes
makotosaekit@makotosaekit(佐伯真人)2025年09月26日AIと『対話しない』対話法、モノローグ法makotosaekit@makotosaekit(佐伯真人)2025年09月15日「文字」というオカルトmakotosaekit@makotosaekit(佐伯真人)2025年09月14日コンテキストエンジニアリングの源流へ、AIと心理学makotosaekit@makotosaekit(佐伯真人)2025年09月09日Vibe Codingから、Drive Coding (欲動のコーディング)へ
makotosaekit@makotosaekit(佐伯真人)2025年09月26日AIと『対話しない』対話法、モノローグ法makotosaekit@makotosaekit(佐伯真人)2025年09月15日「文字」というオカルトmakotosaekit@makotosaekit(佐伯真人)2025年09月14日コンテキストエンジニアリングの源流へ、AIと心理学makotosaekit@makotosaekit(佐伯真人)2025年09月09日Vibe Codingから、Drive Coding (欲動のコーディング)へ
うん・・・当初の目的であるApidogスパム深堀りとは横道に逸れてるのと
見た感じmakotosaekitがBOTのボスとは思えないんだけどおなかいっぱいです
正直スパムは最初に書いたNakamura-Kaitoのフォロワーに無限にいるのだが、スパムを掘るよりもこれ書くためにまとめるのが面倒
こういう記事を熱心に書ける人はすごい
QiitaでApidogを好意的に取り上げている記事はスパムだと思います
おまけ:
Apidog公式｜業務効率化｜APIライフサイクル管理｜API設計＆ドキュメント生成｜テスト自動化@ApidogJPAPI通信と同時にデータベースのCRUD実行可！Apidogの「データベース接続」機能で、SQL/MongoDB/Redis等のデータベースに容易に接続🚀API開発中にDBデータ取得やレスポンス検証、DBへの書き込みをスムーズに行える！！！#API #開発効率UP #データベース詳しくはこちら⇩
＞ 本サービス、本規約の規定又は趣旨に反しているため、限定公開となっております。 ＜＞ 投稿者様側で記事の修正を行い、再公開することで閲覧が可能になります。 ＜
「子宮内アセトアミノフェン曝露の臍帯血バイオマーカーと小児期における注意欠如・多動症（ADHD）および自閉スペクトラム症（ASD）リスクとの関連」
Association of Cord Plasma Biomarkers of In Utero Acetaminophen Exposure With Risk of Attention-Deficit/Hyperactivity Disorderand AutismSpectrum Disorder inChildhood
Yuelong Ji, PhD1; Romuladus E. Azuine, DrPH, MPH, RN2; Yan Zhang, PhD3et al
JAMA Psychiatry
Published Online:October 30, 2019
https://jamanetwork.com/journals/jamapsychiatry/fullarticle/2753512
質問（Question）
子宮内アセトアミノフェン曝露の臍帯血バイオマーカーと、小児期の注意欠如・多動症（ADHD）および自閉スペクトラム症（ASD）のリスクとの関連は何か？
所見（Findings）
ボストン出生コホートに含まれる996組の母子を対象としたコホート研究において、アセトアミノフェンへの胎児曝露を示す臍帯血バイオマーカーは、小児期のADHDおよびASDのリスク増加と有意に関連していた。
意味（Meaning）
これらの知見は、子宮内でのアセトアミノフェン曝露が小児期のADHDおよびASDリスクの増加と関連することを示唆している。
要旨（Abstract）
重要性（Importance）
先行研究により、妊娠中の母親によるアセトアミノフェン使用と、その子どもにおけるADHDやASDリスク増加との関連が懸念されてきた。しかし、多くの研究は母親の自己申告に依存している。
目的（Objective）
臍帯血中のアセトアミノフェン代謝物と、医師により診断された小児期のADHD、ASD、両者併存、ならびに発達障害（DDs）との前向きな関連を検討すること。
デザイン・設定・参加者（Design, Setting, and Participants）
本前向きコホート研究では、ボストン出生コホートの一部である996組の母子を解析対象とした。これらは出生時に登録され、1998年10月1日から2018年6月30日までボストン医療センターで前向きに追跡された。
曝露（Exposures）
出生時に収集され保存されていた臍帯血サンプルを用いて、3種類のアセトアミノフェン代謝物（未変化アセトアミノフェン、アセトアミノフェングルクロン酸抱合体、3-[N-アセチル-L-システイン-S-イル]-アセトアミノフェン）を測定した。
主要アウトカムと測定項目（Main Outcomes and Measures）
小児の医療記録に記載された、医師によるADHD、ASD、その他の発達障害（DDs）の診断。
結果（Results）
996人の参加者（平均［標準偏差］年齢9.8［3.9］歳；男性 548人［55.0％］）のうち、最終的な解析対象は、ADHDのみの児 257人（25.8％）、ASDのみの児 66人（6.6％）、ADHDとASDの併存 42人（4.2％）、その他の発達障害（DDs）304人（30.5％）、神経学的に定型発達の児 327人（32.8％）であった。未変化のアセトアミノフェンは、すべての臍帯血サンプルで検出可能であった。臍帯血中アセトアミノフェン負荷の第1三分位群と比較すると、第2三分位群および第3三分位群ではADHD診断のオッズが有意に高く（第2群 OR＝2.26；95％CI＝1.40-3.69、第3群 OR＝2.86；95％CI＝1.77-4.67）、ASD診断のオッズも高かった（第2群 OR＝2.14；95％CI＝0.93-5.13、第3群 OR＝3.62；95％CI＝1.62-8.60）。感度分析およびサブグループ分析では、母体の適応、物質使用、早産、子どもの年齢や性別など潜在的交絡因子の層別を含め、アセトアミノフェン負荷とADHD、ASDとの関連が一貫して認められ、ADHDではORが2.3〜3.5、ASDでは1.6〜4.1の範囲であった。
結論と意義（Conclusions and Relevance）
胎児期アセトアミノフェン曝露の臍帯血バイオマーカーは、小児期のADHDおよびASDリスクの有意な上昇と 用量反応関係 をもって関連していた。本研究の知見は、妊娠期および周産期のアセトアミノフェン曝露と小児の神経発達リスクとの関連を示す先行研究を支持するものである。
タイトルの通り。
ゲーム業界を目指す人はめちゃくちゃ多く、少なくとも新卒での入社は狭き門となっている。
業界の知り合いなどいれば現状や対策もわかりやすいが、そうではない人が入ろうとするには情報を集めにくい側面があると思う。（実際に自分の新卒就活時には情報が足りていなかった）
そのため、新卒では入れなかったもののゲーム業界の末席に籍を置く自分が、当時知りたかった情報を自己満足で記載していこうと思う。
一応記載しておくが、自己満足のためのものなので記載の内容をもとに行動してうまくいかなかったなどの責任は取らない。最終的には自分で判断してほしい。
【経歴】
こういった話はどういう人間が言ったかによって信憑性が変わると思うので、自分の経歴について先に話しておく。
念のため書いておくと、ゲーム業界に入れた自慢のつもりで書くつもりはないが、自慢だと受け止めてもらっても嬉しいだけなので構わない。（そもそも新卒では入れてる人を常時目の当たりにするので自慢に思えていないので）
特定は怖いのでフェイクを混ぜるが、おおよそ変わらないと思う。
自分は偏差値50程度の情報系大学の出身で、入学以前からゲーム業界（プログラマ）を志望していた。
入学難易度がたいしたことない大学だが、その分上位10％よりは上の成績だった。
就活の時期が来たので、一人で作った2Dゲームや、大学の講義でのグループ開発したWEBシステムなどをポートフォリオにして就活を行った。
その結果、ゲーム業界はどこにも引っかからず、IT企業で客先に常駐するいわゆるSESの会社に入社した。
最初は非ゲームのスマホアプリの開発に従事させられたが、営業の人にゲーム業界に行きたいと伝えてあったので、1年ほど経って契約終了のタイミングで小さなソシャゲ会社に移動した。
そこではUnityなどで開発の経験を積ませてもらった。裁量が割と雑な企業だったので広範な部分の技術を触れたのを覚えている。
2年強そこで働いたものの、サービス終了をきっかけに転職を試みようと思い退職。
その後ゲーム業界専門の大きなSES企業に入社し、運よく大手のソシャゲ開発案件に入れた。
そこで大手の分業の仕組みに慣れながら働いていたが、もともと志望していたコンシューマゲーム業界へのあこがれもあり、本社の営業チームに希望を出していたがタイミングが合わず案件がない時期が続いた。
2年ほど経って、プロジェクト単位での派遣という形だが、Unityなどソシャゲと共通の技術を使うためか、コンシューマゲームの開発経験が無くてもOKなコンシューマゲームの案件が出てきて、そこに転職した。
今は会社は小さめだが、IPはそこそこ強いコンシューマゲームの案件で、不安定な立場ながら従事している。（可能であれば正社員として登用してほしいが、今のところ何も話はない）
【本題】
ここからは実際にゲーム業界を目指す者についてのアドバイスだ。
まず第一に、有名なゲームディレクターの桜井さんの動画にもあったが、ゲームを作ることが重要。
企画職、プログラム職は言わずもながで、デザイン職やサウンド職の芸術系の人でも、そういった経験があると必要な素材の勘所がつかみやすくなるので、作っていた方がいい。
経験を積み上げるために1、2本ではなく何本か作っていてほしい。
可能であれば複数人のプロジェクトでゲームを作り上げているとなお良い。
目指す企業があるなら、その企業のジャンルに近いゲームの方がアピールになる。
なぜゲームを実際に作ることが重要なのかというと、企業が欲しいのは「良いゲームを作れる人材」だからだ。
良いゲームを作れるとアピールする最大の方法は、実際に良いゲームを作ったという経験を伝えることだからだ。
経験の量や質が良ければ、その分ポートフォリオや自己ＰＲでも伝えられることが増えて、有利になるのは言うまでもないだろう。
なので時間をかけて1本や2本作るよりも、何本か完成させて経験として伝えられる方が基本的には有利。（その1本や2本が、それなりの売り上げを上げられるほど優れた作品なら話は変わるかもだが）
そして、入社後に実際に働く際には、当然複数人でその企業で開発されるジャンルのゲームを開発することになるので、入社後に働けるアピールをするためには、複数人でそのジャンル（例えば3Dのアクションとか、2Dのパズルとか）に近いゲームを作っておいた方が有利になる。
もちろん希望職種に合わせた経験を積んでいることが好ましいが、他職種の作業も軽く把握しているとやりとりがスムーズになることが多いので、こちらは参考程度にかじっておくとよいかもしれない。
では、どうして「入社時点で」ゲームを作れることが重要になってくるかというと、やや厳しい現実だが数か月の研修～最悪入社後いきなり業務に放り込んで、ゲーム作りに従事できるかを見られているからだ。
ゲーム業界に来る求人は、経験則でいえば小さな会社でも相当な数になる。その分優秀な人材、いわゆる即戦力が来る可能性も高くなっていく。
そんな状況で、ゲーム作りもそれに類する技術もなく、熱意だけあるというような人を採用して育てていくよりも、ある程度ゲーム作りの経験があって、その下地をもとに仕事を進められそうな人を採用してすぐに働いてもらった方が効率が良いのである。
小さい会社から大きい会社まで数々の新卒の人を見てきたが、どの人も下地としてゲーム開発の経験がそれなり以上にはある人ばかりであった。
それから、一般的な就活の対策と同じになるが、コミュニケーション能力は求められる。
ここでいうコミュニケーション能力とは、雑談などで盛り上がる力ではなく、業務の遂行に向けたやり取りを円滑に行う力である。
ゲーム開発は、言語化の難しいあいまいな感覚を伝えなければならないケースがままある。
それらを時に図持したり、時に実例を見せたりして、伝えなければならない。
この辺りは企画職の人に特に必要な技能かもしれないが、プログラマやデザイナも日々多くの人とやり取りをすることになるので、とにかく伝える・受け取る技能は必須だ。
そういった部分に難がないことを見るために面接などを行っていると思われるので、その点は意識しておいた方がいい。
意識するべきなのは、自分がその職に就いたとしてどのような業務を行うかということである。
企画職なら
レベルデザイン・ゲームデザイン・ディレクション・PM業務など
プログラマなら
インフラ・サーバーサイド・UIプログラム・キャラクタープログラム・CI系・グラフィックスプログラムなど
デザイナなら
キャラクターデザイン・背景デザイン・UIデザイン・モデリング・リギング・エフェクトなど
こういった中から、自分はどのポジションにいたいのか、あるいはすべてをこなせる万能手になりたいのかなど、戦略を考える必要がある。
基本的にはより詳細な募集になる中途採用の情報などから自分の志望するポジションを考えるのをおススメする。
ーー
さて、一通り記載したが、もちろん自分は上記のことをできていなかった。
シンプルにゲームの開発経験も足りなければ、自分のポジションの意識もふわふわしていた。できてた可能性があるのはコミュニケーション能力くらいである。
しかし、これまで見てきた新卒で入社する人は上記のことを努力も才能も偶然も含めて結果的にこなせている人材ばかりである。
はっきり言って一朝一夕で何とかなるようなものではないものもあり、すでに就活を行っている人などでは間に合わないようなケースもあるだろう。
そうなると選択肢は2つ。「ゲーム業界をあきらめる」か「なんとか中途でもぐりこむ」のどちらかである。
あえてはっきり伝えたいのだが、自分は「ゲーム業界をあきらめる」ことを悪いことだとは思っていない。
ゲーム業界に入ることが絶対的にエラいことなのかというととてもそうではなく、志望者が多いということはそれだけ入れない人が多いということになるので、切り替えて別の目標を探すということができるのも一つの能力だと思うからだ。
むしろ能力が足りずに経験も積めてないのに、あきらめることだけはできずにいる方が、よっぽと精神には悪い。一歩間違えると自分もそちら側になっていた（なんなら今も危うい）と思うと恐ろしさを感じてしまう。
挑戦してダメだったというのも、あきらめきれるきっかけにもなるかもしれないので、挑戦すること自体は良いことだとは思うが。
それでもあきらめられないのであれば、「なんとか中途でもぐりこむ」ことを選択することになる。
これに関しては様々なルートがある。第二新卒だったり、自分のように客先常駐や派遣で、何とか未経験でもＯＫのところを探す方法だったり、個人で開発経験を積んでから、中途採用に応募するケースだったり。
運について、そもそも新卒と違い、自分の入社できるポジションが企業に存在するかがわからないので、志望企業に応募すらできない可能性もある。（おそらく求人自体はあるだろうが、第二新卒以外は経験者限定でのものがかなり多いだろう）
仮に応募できたとしても、競争相手は少なくなるが、その分枠も少ないという戦いになる。
未経験である以上、ポテンシャルで採用してもらうしかないので、企業側がその気があるのかはどうしても運になる。
自分の場合は客先常駐で常駐先に同じ会社から出向している人がいたので、その抱き合わせみたいな形で入社できたところがあったので、運が良かったとしか言えない。（別プロジェクトだったので面倒は見てもらえてないが）
こればかりは巡りあわせなので、試行回数を増やして確立を上げるか、万一コネなどあれば、確率の高いルートを用意してもらうかするなどでしか対策はできない。
能力について、何をいまさらと思うかもだが、新卒の時よりも少しシビアになっている。
第二新卒なら新卒同様の扱いになるが、そうでなければ研修など1日程度で簡単に済ませての即戦力としての採用になるので、いきなり現場に出ることになる。
選考時には現場で戦えるかをみられることになり、採用されても即現場なので、使い物にならなければ、雇用形態によってはすぐに首を切られることになる。
なので、業務を遂行するだけの能力が必須になる。その重みは新卒時より重い。
こちらに関して自分については、正直に伝えると少なくともいきなり放り出されても業務を遂行する程度の能力はあったので何とかなっただけだ。（新卒入社の人もこなせていただろうが）
従事する業務に関してはより明確になっているはずなので、食らいついて最低限以上の仕事をしていく必要がある。
中途での現実はそんな感じだ。
競争相手は少なくなるので、単純な確率は上がるが、その分それ専用の武器を用意しなければならない。
一つだけお伝えすると、逆に一度潜り込んでしまえば、経験者の採用を受ける権利が得られるので、より世界は広がる。
ーー
以上がゲーム業界に遠回りして入った身からできるアドバイスだ。
この辺りの話を新卒のころに知りたかったので、これから就活をしようという人に伝わったら嬉しい。
ーーーーーーーー
【追記】
自己満足で書きなぐっただけなのになんかめちゃくちゃ反応ある。
文章が優れてるとは到底思えないので、ゲーム業界の注目度の高さを示しているのだろう。
ざっくり読んだが、結局のところ正解のある話ではないので、いろいろな意見があって当然だと思う。
みんな自分の経験なんかもあるだろうし、適当言ってるだけの可能性も自分含め全然あるだろうし、名前を出しているでもない限り参考程度で読むのがいいと思う。
学歴についての言及も多かったのでその点に触れようと思って追記したが、そりゃあ当然学歴があった方が良いだろう。
実際応募数の多い大企業では、足切りの条件の一つに使われるのも止む無しだと思うし、そうでなくても大体の高学歴の人はシンプルに優秀だ。
だけど高学歴なだけでは入れないのも事実だと思う。逆に偏差値が低かったりする場合でもそれだけで切られることはそんなに多くはない（ちゃんとしてれば書類は通る）。
実際、大企業なんかでも意外と専門学校の卒業生（たいていはトップ層だが）もいたりするのを結構見てきた。高学歴が入社しやすいのは、それだけ優秀な人が多いというだけの話だと自分は考えている。
高校生とかで有名なゲーム会社で働きたいなどのモチベーションから勉強を頑張るのは大いに問題ないかと思うが、専門学校で業務に使えるような技術を身に着けて、ゲームをたくさん作る経験を積んで一点突破の能力でゲーム業界に挑むのも本気であれば間違いではないと思う。
いろいろなことを選べる立場のうちは、自分がどうなりたいのかを考えて、いろんなパターンから自分に向いている道を選んでいくのが良いだろう。年を重ねるごとにだんだん選べる道は減っていくので、その時に後悔しない道を選ぶことができれば理想だ。
逆に年を重ねると道が狭まっていくことは多いが、年を重ねることで見えてくる抜け道のようなルートもあるので、悲観しすぎないことも重要だろう。
自分も今から進路を考える立場だったら、専門学校を選択していたかもしれないと思うことはある。
学歴は選べる立場なら真剣に考えるべきだが、そうでなければ囚われすぎないことも大事だというのが個人的な結論だ。
あとは、採用の人間でもないのに偉そうなことをというニュアンスのものがあったが、もとより自己満足のための記載なのと、偉そうな文章に関しては、文の書き方から特定されないようにしているために、普段しないような言葉遣いをしているのが原因なので、勘弁してほしい（意味があるかはわからないが）。
Permalink |記事への反応(14) | 23:29
うちのチームには、とにかくコードが大好きな女性プログラマーがいる。
勉強熱心で、新しいフレームワーク、アーキテクチャ、ライブラリ、Lintルール、CI/CDの最適化…とにかく探求心の塊。
その姿勢自体は、正直素晴らしい。だが、ビジネス側のスピード感や優先度にまったく寄り添えないのが問題。
たとえばプロダクトのローンチが迫っている時、チームとしては「多少コードが荒くてもいいから、まず動くものをリリースしよう」と判断する場面がある。
だが彼女はそういう「割り切り」が大の苦手で、汚いコードは絶対に許さない。
しかも機嫌が悪くなる。
ミーティングでも静かに険しい顔をしていて、周囲も話しかけづらい空気を感じている。
正論ばかりで論破しようとするわけではないが、「これでは技術的負債が…」という言葉がもはや口癖のように繰り返される。
いや、それはわかってる。でも今はそこじゃないんだ……
さらに困るのは、彼女が導入したがるツールや技術の学習コストが高すぎること。
他のメンバーからも「正直ついていけない」「彼女のためのプロジェクトじゃない」といった声が上がってきている。
表面上はみんな協力的だが、裏では「あれはちょっと…」とこっそり相談されているのが現状だ。
簡単に外すこともできない。技術的には信頼してるし、いなくなったら困ることもある。
でも、今のままではチームのバランスが崩れる。
そんな彼女に、どう伝えればいい？
今度イギリスの製薬会社が、性欲をピタッと押さえ込むパッチを出すらしい。
ニコチンパッチみたいに腕にペタンと貼るだけで、煩悩が全部蒸発するって話だ。
っていうのはまったくの「嘘」なんだけど、実際にそんなもんが出てきたらどうする？
世の中、性欲で人生こじらせてる奴が多すぎる。電車でスマホ片手にエロ広告を消すのも面倒だし、週末の夜は「彼女ほしい」と言いながらAVで自家発電大会。「風俗なんて行く金がねぇ」、「マッチングアプリでメンタル崩壊」、「女友達と飯行くだけで下心がバレる」、「結婚したけどレス地獄」。そんな毎日なら、もう全部パッチで消してくれって気分にもなる。
そもそも、性欲とやらがなければ、もっと有意義なことに脳みそ使えるんじゃないか。受験生の頃、「くだらねえ妄想消して単語帳に全集中できたら東大行けた」とか、仕事中にスクリプト組んでても、なぜか脳裏にアイドルのあの表情がフラッシュバック。「この時間が全部計算資源に変換できたらCIパイプライン爆速じゃね？」なんて考えたやつ、俺だけじゃないだろ。
でも、いざパッチを貼ってサクッと欲望ゼロになったら、空っぽのロボットになる気もする。好きな人と目が合っても何も感じない。推しアイドルの新曲MV見ても「はえー色使い綺麗っすね」とかしか思わない。そもそも金曜の夜に飲み会で変なフラグ立てることもなくなる。「恋」「ときめき」「妄想」「嫉妬」・・・こんな人間くさい情動を、ぜんぶパッチの下に封印してしまう。それで何を楽しいと思えるんだろう。
冷静に考えれば、性欲如きに踊らされる人生もどうかしてる。でも全部消してしまえば、人間社会そのものが根っこから成り立たなくなる気もする。文明の起動エネルギーを全部オフにした世界で、進化はもうあり得ない。
いっそパッチで悩みが消えてしまえば楽ではある。でも、欲望を抱えて泥臭く生きてる今が、案外悪くないんじゃないかとも思ってしまう。
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250908171913# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaL6RggAKCRBwMdsubs4+SE8oAQDxVlhq4JTJmgqHTRUdqxQcxCqFtnwJdblEFcx7BKtJAAEA5LxNxuvxj/ci+IemMQC6tk78Eup01jYFkmrKg3pOmQU==5K8o-----ENDPGP SIGNATURE-----
テスラの「Sr.Software Engineer, Full Stack - Tesla Cloud Platform（TCP）」の求人（https://www.tesla.com/careers/search/job/sr-software-engineer-full-stack-tesla-cloud-platform-249132）を起点に、自動車各社が同種人材を採用する“目的”の違いを整理した。日本勢はIT基盤やSRE運用の比重が高い一方、テスラは社内クラウド自体をプロダクトとして内製し、中国勢のNIOやXPengはAIインフラ（自動運転やロボティクス、エネルギー連携）に特化、ECARXはOEM向けの外販プラットフォームという立て付けである。
| 会社 | 主要目的 | What to Expect | WhatYou’ll Do | WhatYou’ll Bring | Compensation and Benefits |
|---|---|---|---|---|---|
| Tesla | 社内クラウド（TCP）を“製品として”内製し、全社サービスの速度と統制を握る | TCPはテスラの内製クラウドであり、複数DCにまたがる計算・ストレージ・ネットワーク・IDを提供し、開発者がセルフサービスで使える基盤をつくるチームである | コアAPIやサービスの設計実装、セルフプロビジョニングの自動化、可観測性、ReactやNextやTypeScriptによるダッシュボード | GoやReactやNextやTypeScript、Kubernetesや仮想化、CI/CD、分散システムの知見 | 年収133,440〜292,800USDに加え、現金賞与と株式付与および福利厚生。提示額は勤務地、市場水準、職務関連の知識、スキル、経験など個別要因により異なる。本職の総合的な報酬パッケージには、提示される職位に応じて他の要素が含まれる場合がある。各種福利厚生制度の詳細は、内定時に案内される。 |
| WovenbyToyota | 製品直結サービスを“止めない”SRE運用（AreneやEnterpriseAIやCity Platform） | ミッションクリティカル運用の信頼性最適化を担う | 監視や可観測性やインシデント対応や運用自動化、マルチクラウド横断 | SRE実務、Kubernetes、Terraformなどの基盤スキル | 給与は多くが非公開。米拠点の類似シニアは$169K–$200Kの例あり。 |
| Nissan | 全社ITや開発のモダナイズと標準化（Platform EngineeringやDevEx） | 社内開発者のクラウド活用を底上げする基盤を整える | CI/CD、セキュア環境の供給、教育や展開、オンプレとクラウドの統合運用 | クラウドやコンテナ、CI/CD、セキュリティ設計 | 多くがレンジ非公開（地域により待遇差） |
| Honda（Drivemode含む） | 製品直結のAWS基盤と開発者体験の高速化（DevEx） | モバイルやIVIやバックエンドの横断基盤を整える | AWS設計運用、GitOps型プロビジョニング、CI/CD、観測やセキュリティの自動化 | AWS、TerraformやCDK、Kubernetesなど | 本体US求人はレンジ非開示が多い。Drivemodeはホンダ完全子会社（前提関係） |
| NIO | AI学習や推論インフラの内製強化とエネルギー運用統合 | 自動運転やVLMやLLMなどのAI基盤を構築する | GPU最適化、分散学習、データパイプライン整備 | 深層学習や分散処理、クラウド、最適化 | 米SJ拠点で$163.5K–$212.4Kのレンジ例。 |
| XPeng | FuyaoAI PlatformによるADやロボやコックピット向けAI基盤 | 社内共通のMLプラットフォームを提供 | データローダやデータセット管理、学習や推論スループット最適化 | 分散処理、MLプラットフォーム運用 | クラウド 米サンタクララ拠点の公募多数（給与は媒体や募集による） |
| ECARX（Geely系） | OEM向けに外販するクラウドやソフト製品（Cloudpeakなど） | 車載SoCからクラウドまでを束ねる外販スタック | 製品機能開発や統合、導入支援、機能安全準拠 | 車載とクラウド統合、機能安全、顧客導入 | ハイパーバイザなど 直近レンジ情報は公開少なめ（事業広報は多数） |
なお、関連するポストとして、SETI Park氏のポストを挙げる。
https://x.com/seti_park/status/1961629836054859810
「自動車メーカーがなぜクラウド専門人材を探すのか」に答える文脈で、2024/07公開のテスラ特許（US2024249571A1）を手がかりに、ロボタクシーやフリート運用の中核となるクラウド基盤が競争優位になり得る点を示唆している。
単なるストレージではなく、フリート運行やデータ連携を統合管理する“中核プラットフォーム”としての重要性が強調される。
上記はテスラのTCP求人（セルフサービスIaaSやダッシュボード、プロビジョニング自動化の開発）という具体の採用と整合的である。
Build policy
Thisis a guideline andhasnot yet been successful .
Plan A
Do the sameasbuildingonWindows ormacOS (probably not possible)
>OnLinux ,only maui-androidis available, so a lot of build errors occur .
>gt k workload cannot be installed
Plan C
KeepCI /CDrunning (mostlikely )
>It might be possible torunGitHubActions locally usingact (currently there are some errors , butit should work ifyoutry hard)
> SameasPlan B,gt k workload cannot be installed
Plan D
https://tensor.art/articles/897541615583763170
https://www.gemtracks.com/demonslayeinfinitycastle/
> Makingit withQt (Qt .NET ( old)) ( Ifeellike the license (GPL /LGPL )is abit tricky )
Fornow, I'llgo with plan C.Plan B seems almost the same, though... (Plan B seems easier to use when creating the materials , sinceyoudon'tneed to include "act" oranythinglike that.)
Build policy
Thisis a guideline andhasnot yet been successful .
Plan A
Do the sameasbuildingonWindows ormacOS (probably not possible)
>OnLinux ,only maui-androidis available, so a lot of build errors occur .
>gt k workload cannot be installed
Plan C
KeepCI /CDrunning (mostlikely )
https://subscribepage.io/thestone2025subthai
https://subscribepage.io/thestonefullversion
https://subscribepage.io/xem-mang-me-di-bo-vietsub-thuyet-minh-full-hd
https://subscribepage.io/mangmedibovietsub
>It might be possible torunGitHubActions locally usingact (currently there are some errors , butit should work ifyoutry hard)
> SameasPlan B,gt k workload cannot be installed
Plan D
https://mirror.xyz/0xbB7D6e360b93B2ED4FEF9d972c71F86844121ee7
> Makingit withQt (Qt .NET ( old)) ( Ifeellike the license (GPL /LGPL )is abit tricky )
Fornow, I'llgo with plan C.Plan B seems almost the same, though... (Plan B seems easier to use when creating the materials , sinceyoudon'tneed to include "act" oranythinglike that.)
GitHub（ギットハブ）は、ソフトウェア開発者にとって非常に便利なツールであり、特にチームでの協力作業において大きな効果を発揮します。GitHubはGitというバージョン管理システムを基盤としており、コードの変更履歴を管理しやすく、過去の状態に戻したり、特定の変更内容を確認することができます。また、Pull RequestやIssue機能を使えば、チーム内でのコードレビューや意見交換が円滑に行えます。さらに、GitHubは世界中の開発者が参加するオープンソースプロジェクトの中心的なプラットフォームとなっており、自分のスキルを活かして貢献することも可能です。CI/CDなどのDevOpsツールとの統合も簡単で、自動テストやデプロイの自動化によって、開発のスピードと品質が向上します。加えて、READMEファイルやWiki機能を使ってプロジェクトのドキュメントを整備できる点も、学習や共有に役立ちます。このように、GitHubは個人開発にもチーム開発にも不可欠な存在であり、効率的かつ協力的なソフトウェア開発を実現するための強力なプラットフォームです。
https://mavenanalytics.io/project/38415
https://mavenanalytics.io/project/38386
日中の生産性は、夜の過ごし方、特に「就寝」というクリティカルなタスクをいかに成功させるかにかかっている。本記事では、つい夜更かししてしまうエンジニアのために、早寝を「技術」として体系化し、再現性のある形で実践するための具体的な手法を探求する。これは精神論ではない。あなたのQoLと生産性を向上させるための、実践的なスリープエンジニアリングだ。
我々エンジニアにとって、夜は不思議な魅力を持つ時間だ。日中の喧騒から解放され、思考は冴えわたり、ゾーンに入りやすい。しかし、その魅力的な時間は、往々にして「早寝」という、人間の生存に不可欠な基本プロセスを犠牲にすることで成り立っている。
「リファクタリングが楽しくなってきた」
これらの探求心はエンジニアの美徳であるが、同時に我々を「睡眠負債」という深刻な技術的負債へと導く。本稿は、この負債を返済し、持続可能な開発（と生活）を実現するための「早寝」という技術に焦点を当てる。
早寝を実装する前に、まずは現状のアーキテクチャに潜むアンチパターンを特定しよう。
就寝前のスマートフォンは、まさに同期的なブロッキングI/Oだ。SNSの無限スクロール、動画プラットフォームの自動再生、チャットアプリの通知。これらは我々の意識というシングルスレッドを完全に占有し、本来実行されるべきsleep()プロセスへの遷移を妨げる。
深夜まで続くコーディングや問題解決は、脳を極度の興奮状態にする。ベッドに入っても、アドレナリンやコルチゾールといったホルモンがCacheに残り続け、CPUがクールダウンしない。shutdown -hnowを叩いても、プロセスが終了しないのだ。
「夜更かしの供」として注入されるカフェインやアルコールは、一見するとパフォーマンスを向上させるように見える。しかし、これらは睡眠の質という重要なmetricsを著しく劣化させる、誤った依存関係だ。特にアルコールは、入眠を助けるように見えて、実はレム睡眠を阻害し、睡眠のアーキテクチャ全体を不安定にする。
不規則な就寝・起床時間は、体内時計という最も重要なCronジョブを破壊する。毎日異なる時間に実行されるジョブが安定した結果をもたらさないのと同様に、不規則な睡眠スケジュールは、日中のパフォーマンスを予測不可能なものにする。
では、どうすればこれらのアンチパターンを排除し、安定した早寝pipelineを構築できるのか。ここではSleepas Codeの概念に基づき、具体的なプラクティスを紹介する。
毎晩、同じ手順で就寝プロセスを実行することで、入眠を自動化する。
-PC/スマホのシャットダウン: 最も重要なステップ。物理的に電源を落とすか、手の届かない場所（別のコンテナ）にdeployする。
- 入浴: 38〜40℃のぬるめのお湯に15分ほど浸かる。これにより深部体温が一時的に上昇し、その後の下降とともに入眠が促される。これはHot-swapならぬHot-bathによるクールダウンだ。
静的コンテンツの消費: 激しい思考を伴わない、静的な情報（紙の読書など）に切り替える。電子書籍ではなく、紙媒体が望ましい。
ストレッチ: 軽いストレッチで、日中のcommitで固まった体をreleaseする。
すべての準備が整ったら、ベッドという本番環境にデプロイする。余計な思考はgitclean -fdで強制削除し、呼吸に集中する。
例：「夕食後のコーヒーが原因だった」→「カフェインの摂取は15時までというSLAを設ける」
早寝は、単に体を休める行為ではない。日中の高いパフォーマンス、明晰な思考、そして創造性を維持するための、最も効果的で再現性の高い「技術」だ。
我々はインフラをコードで管理し、CI/CDでデプロイを自動化するように、自身の睡眠もまた、技術と工夫によってコントロールできる。今夜、あなたのwhile(true)なループをbreakし、持続可能なパフォーマンスを手に入れるための第一歩を踏み出してほしい。
Happy sleeping!
日中の生産性は、夜の過ごし方、特に「就寝」というクリティカルなタスクをいかに成功させるかにかかっている。本記事では、つい夜更かししてしまうエンジニアのために、早寝を「技術」として体系化し、再現性のある形で実践するための具体的な手法を探求する。これは精神論ではない。あなたのQoLと生産性を向上させるための、実践的なスリープエンジニアリングだ。
我々エンジニアにとって、夜は不思議な魅力を持つ時間だ。日中の喧騒から解放され、思考は冴えわたり、ゾーンに入りやすい。しかし、その魅力的な時間は、往々にして「早寝」という、人間の生存に不可欠な基本プロセスを犠牲にすることで成り立っている。
「リファクタリングが楽しくなってきた」
これらの探求心はエンジニアの美徳であるが、同時に我々を「睡眠負債」という深刻な技術的負債へと導く。本稿は、この負債を返済し、持続可能な開発（と生活）を実現するための「早寝」という技術に焦点を当てる。
早寝を実装する前に、まずは現状のアーキテクチャに潜むアンチパターンを特定しよう。
就寝前のスマートフォンは、まさに同期的なブロッキングI/Oだ。SNSの無限スクロール、動画プラットフォームの自動再生、チャットアプリの通知。これらは我々の意識というシングルスレッドを完全に占有し、本来実行されるべきsleep()プロセスへの遷移を妨げる。
深夜まで続くコーディングや問題解決は、脳を極度の興奮状態にする。ベッドに入っても、アドレナリンやコルチゾールといったホルモンがCacheに残り続け、CPUがクールダウンしない。shutdown -hnowを叩いても、プロセスが終了しないのだ。
「夜更かしの供」として注入されるカフェインやアルコールは、一見するとパフォーマンスを向上させるように見える。しかし、これらは睡眠の質という重要なmetricsを著しく劣化させる、誤った依存関係だ。特にアルコールは、入眠を助けるように見えて、実はレム睡眠を阻害し、睡眠のアーキテクチャ全体を不安定にする。
不規則な就寝・起床時間は、体内時計という最も重要なCronジョブを破壊する。毎日異なる時間に実行されるジョブが安定した結果をもたらさないのと同様に、不規則な睡眠スケジュールは、日中のパフォーマンスを予測不可能なものにする。
では、どうすればこれらのアンチパターンを排除し、安定した早寝pipelineを構築できるのか。ここではSleepas Codeの概念に基づき、具体的なプラクティスを紹介する。
毎晩、同じ手順で就寝プロセスを実行することで、入眠を自動化する。
-PC/スマホのシャットダウン: 最も重要なステップ。物理的に電源を落とすか、手の届かない場所（別のコンテナ）にdeployする。
- 入浴: 38〜40℃のぬるめのお湯に15分ほど浸かる。これにより深部体温が一時的に上昇し、その後の下降とともに入眠が促される。これはHot-swapならぬHot-bathによるクールダウンだ。
静的コンテンツの消費: 激しい思考を伴わない、静的な情報（紙の読書など）に切り替える。電子書籍ではなく、紙媒体が望ましい。
ストレッチ: 軽いストレッチで、日中のcommitで固まった体をreleaseする。
すべての準備が整ったら、ベッドという本番環境にデプロイする。余計な思考はgitclean -fdで強制削除し、呼吸に集中する。
例：「夕食後のコーヒーが原因だった」→「カフェインの摂取は15時までというSLAを設ける」
早寝は、単に体を休める行為ではない。日中の高いパフォーマンス、明晰な思考、そして創造性を維持するための、最も効果的で再現性の高い「技術」だ。
我々はインフラをコードで管理し、CI/CDでデプロイを自動化するように、自身の睡眠もまた、技術と工夫によってコントロールできる。今夜、あなたのwhile(true)なループをbreakし、持続可能なパフォーマンスを手に入れるための第一歩を踏み出してほしい。
Happy sleeping!
Claude Code使って個人開発してるけど、性能が自分の上位互換すぎてしんどい。
実装速度が速いのは言うまでもないけど、保守性・拡張性を意識した良いコードを書く（少なくとも自分よりは）。
日本語で「〇〇の機能実装して」と書くだけでタスクを勝手に分解して動くし、ドキュメントも一言いうだけで完璧に書いてくれる。
インフラが整っていなければその整備などは人間がやるだろうけど、
基盤がすでにあってCI/CDがしっかりしてればもう人間がやるのは最終確認だけなんじゃないか...
既存のシステムとの兼ね合いがあるから今すぐにエンジニアの需要はなくならないとは思うけど、
そんな寝言を垂れ流す前に、その脳内の自己放尿を止めろ。現実を知らずに感情論で殴りかかるのは、ただの知的怠慢だ。
まずな、「コードを書く」と一口に言うが、AIはGPT-4以降、文脈理解、設計意図の読解、エラーログの解析、APIドキュメントの要点抽出、果てはCI/CDパイプラインの構築補助まで、実用レベルで人間の工数を削減してる。
そもそも、お前はAIが書いたコードをレビューしたことがあるのか？
エッジケースの処理、ユースケースに応じた構造の変化、リファクタリング提案までやってくる様子を見たことがあるのか？
それもせずに「書けない」などと言うのは、自分の無知を自己放尿のように撒き散らしてるに等しい。
今なお「自分の手で書かないとコードじゃない」とか言ってるのは、馬と車の比較で馬の方が魂があるとか言ってた時代錯誤の連中と同じだ。
Vaccination and Neurodevelopmental Disorders: A Study ofNine-Year-Old Children Enrolled in Medicaid
Anthony R. Mawson, Binu Jacob
Peer Reviewed, Clinical Research
01/23/2025
ワクチン接種と神経発達障害：メディケイドに登録された9歳児に関する研究
合計47,155人の9歳児に関する診療データを解析したところ、以下の知見が得られた：
ワクチン接種は、調査対象としたすべてのNDDについて有意なオッズ比の上昇と関連していた
早産かつワクチン接種を受けた児童のうち、39.9%が少なくとも1つのNDDと診断されており、これはワクチン未接種の早産児（15.7%）と比べて有意に高かった（オッズ比3.58、95%信頼区間：2.80〜4.57）
ワクチン接種を受けた回数が多いほど、ASDと診断される相対リスクが高かった。1回の接種歴のみの児童は、未接種児と比べてASDと診断される可能性が1.7倍高く（95%CI: 1.21〜2.35）、11回以上接種を受けた児童は、未接種児と比べて4.4倍高かった（95%CI: 2.85〜6.84）
結論：
本研究の結果は、現在のワクチン接種スケジュールが複数の神経発達障害のリスク増加に寄与している可能性を示唆している。また、早産とワクチン接種が組み合わさることで、ワクチン未接種の早産児と比べてNDDのリスクが著しく高まること、さらに接種回数の増加によりASDリスクが上昇することが明らかとなった。
どうすんのこれ。
入社して最初の仕事は「AWS認定ソリューションアーキテクト」の資格を取ることだった。
会社の先輩はAWSアカウントの管理だけで頭を抱えていて、俺は「クラウドってすごいんだろうな」と思っていた。
甘かった。
大学時代はPythonでちょっとしたWebアプリを作るのが楽しかったのに、今はIAMポリシーとSecurityGroupの設定で一日が終わる。
コードを書いているはずが、実際はYAMLとJSONばかり書いている。
先輩（30代）は「昔はサーバーにSSHして直接デプロイしてたんだよ」と言うけど、正直それの何が悪いんだろう。
デプロイ自体は確かに自動化されるけど、その仕組みを作るのに疲れ果てる。
Kubernetes？EKS？ECS？Fargate？Lambda？Step Functions？どれを使えばいいのか分からない。
友人はGCPを使っているけど、別の呪われた世界があるだけだと言っている。
Azureの話は聞きたくもない。
懐かしい感覚だった。「gitpushherokumain」だけで済んだ。
こんなに簡単だったのか。
herokuの料金は高いってよく聞くけど、精神衛生上の価値はある。
最近のスタートアップでは「NoOps」とか「クラウドレス」みたいな言葉が流行っていると聞いた。
Vercel、Netlify、Railway、Fly.ioなどを使ってインフラをほぼ考えずにデプロイするらしい。
もしかして、クラウドの複雑さに耐えられなくなった開発者が増えているのかもしれない。
いや、きっと俺のスキルが足りないだけだ。「クラウドネイティブ」になるべきなのだろう。でも正直、モノリスに戻りたい気持ちもある。
きっと、単純なものが複雑になりすぎたんだ。
