  |
はてなキーワード:CIとは
日本だとなんかむっちゃ評価しない？勤務先は評価する。技術的にも内容的にも練られてなくても創り上げた凄い、100点って感じ
別に完璧になってから出せって話じゃない。やったのは凄いと思う。でもそれはそれとして技術やサービスについては色眼鏡無しで見るべきだし、そこからの継続的な改善も含めて見るべきだし、最初に定めた荒唐無稽なKPIKGIが未達成ならそこも聞くべき
と上司に提言で言ったけど一蹴された。正直子供が立って凄い凄いしてるみたいで無理
どこの会社のシステム部門もこんな感じなの？ていうか思いつきのゴミ作った奴が昇給してどっか行ってそのゴミの継続的改善とかマジ無理
Pythonちょっと勉強してたし、将来はAIエンジニアとしてバリバリ活躍するんだって思ってた。
入社したのは普通のソフトウェア開発会社で、同僚はみんな優しい。
でも…みんなこう言うんだ。
……まあ信じたよ。当初はね。
で、ある日の昼休み。
同僚の一人がふと見せてきたん。
そこにあったのが、Flutterで作ったマルチプラットフォームアプリ。
バックエンドはFirebase Authentication + Firestore。
UIの状態管理はRiverpod。画面遷移制御はGoRouter。
「あーでもこれ遊びで作ってるだけだからｗ」
しかもスクリーンショット見たらCI/CDがGitHub Actionsで回ってんの。
別の同僚もほぼ同じ。
「休日は何してんの？」って聞いたら「普段ゲームばっかで何もしてないわｗ」とか言うわけ。
でも昼休憩にそいつモニターを見たらタブに開いてたのがStackOverflowとかRFC 6455だった。
冗談で勉強してんの？って聞いたら「趣味ですｗ」とか言うわけ。正直引いた。
更に驚いたのが勉強会の存在で、あいつらの「休日何もしてない」は嘘だってことが分かった。。
俺が「休日は何もしてないんでしょ？」って聞くと
「してないしてない、何も〜。あ、でもLT会と、Go言語の勉強会は毎週参加してるかなｗ」
とか普通に言ってくる。
は？？何もしてないって言うのに土曜も日曜も、誰かの書いた技術書読んでんの？
もうこれさ……完全に別の生き物じゃん。
CloudWatch徹底理解
Terraform基礎 + Projects
IaC Security
企業へ応募
🔥AWS系
AWS Certified Security – Specialty (SCS-C02)
https://www.udemy.com/course/aws-specialty-security-scs/
AWS CloudWatch Masterclass
https://www.udemy.com/course/aws-cloudwatch/
The Complete Cyber Security Course —NathanHouse
https://www.udemy.com/course/the-complete-internet-security-privacy-course/
SOC Analyst –Blue Team Training
https://www.udemy.com/course/soc-analyst-blue-team-training-course/
MITREATT&CK + Threat Hunting
https://www.udemy.com/course/threat-hunting-mitre/
https://www.udemy.com/course/terraform-beginner-to-advanced/
ああ、安心しろ。俺は救いようのないほど無能なお前のところでなど働くつもりは一切ない。
だから出社もしない。
さて本題だ。
違う。
俺が言ってるのは、管理をシステム化できない組織は生き残れないという冷徹な事実だ。
お前の発想が古いんだよ。21世紀のマネジメントは、人間の監視じゃなくデータによる制御だ。
Slack・Git・Jira・CI/CD・成果ログ、全部自動で可視化される。管理者が人力で見張ること自体がコストの塊なんだよ。
それをまだ「俺が一人ひとり見ないとサボる」なんて言ってる時点で、お前は組織じゃなく保育園を運営して自己放尿してるだけだ。
その通り。そして現実を正しく認識したなら、次にやるべきは構造改革だろ。
俺が無能だから全員出社しろというのは、沈没船の船長が俺は泳げないからお前らも泳ぐなと言ってるようなもんだ。
それは管理職の定義を間違えてる。本来、管理職は人を叱る仕事じゃない。
怒鳴ることでしかマネジメントできないなら、AIにも置き換えられない非効率の象徴だよ。
そんな日々の中で最も厄介なのは、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.)
