いっちー|ゲームプログラマー・プロデューサー出身のSS事業責任者&EM @辰巳電子工業

決断はリーダーの重要な役割ですが、それだけに振り切るPLやゲームディレクターには注意が必要です。
経営の意図を伝えることや、現場の不満を上げること自体は難しくありません。
本当に難しいのは、事業上・技術上の制約と心理的負荷を整理し、双方が理解できる形に言語化することです。

「コスト削減」や「前倒し」も、設計や依存関係の見直しという課題に分解できます。

前提を揃えてから決断する。その構造化こそがリーダーの仕事だと考えています。

開発現場で陰口が多くなる理由｜情報が正規ルートに乗らないという構造｜itchie@辰巳電子工業 ゲームやシステムの開発現場で「陰口が多い」「人間関係が悪い」と言われることがあります。ですが、実務を見ていると、それを単純に個人の性格や感情の問題として片付けられないケースが少なくありません。 この記事では、 ・なぜ正式な場で意見が出にくくなるのか ・なぜ懸念が裏で共有される状態が生まれるのか その構造を整理します。 感情論ではなく、情報の流れという観点から見直してみます。 「空気が悪い」と...

note 開発現場で陰口が多くなる理由｜情報が正規ルートに乗らないという構造｜itchie@辰巳電子工業 @itchie_tatsumi note.com/itchie_tatsu...

エンジニアに必要な「国語力」が話題になっていますが、超ざっくり言うと、だいたいこのあたりになるかと思います。

■ Lv.1：基本
・仕様に書かれている内容を正確に読み取る力
・主語・条件・例外を取り違えない力
・事実と推測を分けて報告する力

■ Lv.2：応用
・仕様に明記されていない前提や制約に気づく力
・曖昧な言葉を定義し、共通認識をつくる力
・相手が答えやすい問いに整理して質問する力

おはようございます！

昨日までの遠征から一転、本日より日常に戻って通常業務です。声出し＆ジャンプで筋肉を使い回ったからか、今は全身筋肉痛です！応援というものは全身運動なんだなあとつくづく感じます。

本日も宜しくお願い致します！

大分名物　関アジと関サバ

私が担当していた格闘ゲームは毎年新作を出していました。
外からは2チーム体制と言われましたが、実際は1チームでした。企画が次回作を準備する間、プログラマー3名で移植と外注管理を担い、役割をローテーションして全工程を経験しました。
今思えば無理のある体制ですが、納期遅延なく回せてしまったため増員の話は出ませんでした。
あの頃、無理をしない選択ができていたら、と考えることもあります。

3年で辞める人と、10年残る人の違い。
能力差ではないことが多いです。

3年で辞める人は、「環境が合わない」と感じたら限界が来ます。

10年残る人は、環境を我慢しているのではなく、“環境の使い方”を見つけている感じですね。

・理不尽を学びに変える
・成果が出なければ役割を変える
・居心地悪ければ立ち位置を調整する

残る人は強い訳ではなく、構造を読んでいます。

ゲーム開発でよく起きるチュートリアル離脱の問題｜理解度を憶測してしまうケース｜itchie@辰巳電子工業 本記事では、「ソーシャルゲームのチュートリアルで離脱率が高くなる理由」について整理します。特に、説明を増やしても改善しないケースで、現場では何が起きているのかを構造的に見ていきます。 チュートリアルは、ゲームの第一印象を決める重要な工程です。しかし、離脱率の改善施策がうまくいかないという相談は、決して珍しいものではありません。 反応の多かった“説明不足”という仮説 以前、ソーシャルゲームを開...

noteを更新しました！

ゲーム開発でよく起きるチュートリアル離脱の問題｜理解度を憶測してしまうケース｜itchie@辰巳電子工業 @itchie_tatsumi note.com/itchie_tatsu...

仕事と自己評価は分けて考えたほうが健全です。

バグやレビュー指摘、案件の失敗をそのまま自分の価値と結びつけると消耗します。

仕事は成果物で、コードや設計は改善でき、やり直しも可能です。

問題は「自分がダメ」ではなく「今回の判断のどこが弱かったか」。

事実と感情を分け、構造で振り返る。

この距離感が挑戦を続ける力になります。

生成AI時代に生き残るのはどんなエンジニアか。

AIが実装やテストを高速化し、“書く速さ”はコモディティ化します。

差が出るのは、設計の重さを理解し、変更の波及や運営コストまで見通せる力。
不具合を仮説で切り分け、事実で詰める力。
全部やらない勇気を持ち、成立を優先する取捨選択。
そして判断根拠を言語化し共有できる力です。

AIは量を軽くしますが、判断の責任までは代替しません。

自分のタスク見積もりが苦手なエンジニアは少なくありません。

外れる原因は、多くの場合「実装時間」しか数えていないことです。

実際は、動作確認の修正、レビュー差し戻し、QA対応、例外処理など後半工程が半分を占めます。

実装時間と完了時間は別物です。

半日単位まで分解し、不明点や外的要因も明示するのがコツ。

見積もりは未来予知ではなく、誤差を共有し制御するための作業です。

おはようございます！

全国＆ネットで売り切れ続出のSoftware Design 2月号ですが、隣に座っていた社員が買っていました！さっそく貸してもらいました。あれだけ探したのに、隣で見つかるとは不思議なものですね。

本日も宜しくお願い致します！

2D経験者が3D開発で異世界に飛ぶ｜座標系と行列｜itchie@辰巳電子工業 最近、昔のゲームの発売記念日を知らせる投稿を見かけることが増えました。90年代のタイトルを見ると、素直に「懐かしい」と感じます。 一方で、初代PlayStationやセガサターンの時代のタイトルを見ると、少し違う記憶がよみがえります。2Dしか作ったことのなかったプログラマーが、急きょ3Dを担当することになった、あの頃の空気です。 私も例外ではありませんでした。 行列を間違えると異世界行き ...

noteの記事を更新しました！

2D経験者が3D開発で異世界に飛ぶ｜座標系と行列｜itchie@辰巳電子工業 @itchie_tatsumi note.com/itchie_tatsu...

エンジニアのフォロー面談が機能しない理由ですが、実は多くの場合「回数」ではなく「設計」にあります。

よくあるのは、
・月1の面談が“雑談”で終わる
・課題が言語化されない
・仕事と評価が接続されていない
・現場と面談者の情報が分断されている
・フォロー内容が仕事に反映されない

フォローが“イベント”になっていて、“仕組み”になっていない訳です。

本来フォローは、
① 現状の可視化
② リスクの早期検知
③ 成長テーマの具体化
④ 次のアクションの合意
ここまで落として初めて機能します。

フォローの構造を設計することで、個人の善意・配慮に依存しない「サポート体制」を整えることができます。

Xで【組み込み系エンジニアの間で「開発環境では動くのに、実機で固まる／起動しない」】という話題をポストしたら、たくさんの方からご意見をいただいています。私はゲームプログラマーあがりなので、あくまでゲームの事例なのですが、やはりゲームと組み込み系は親和性が高いのか、組み込み系の方のご意見が目立ちます。本当に面白いものです。

おはようございます！

体調が回復したので、本日は久しぶりの出勤です。私は家にいると気が滅入る方なので、家から出て歩いただけでテンションが上がりますね。

本日も宜しくお願い致します！

ソーシャルゲームにおいて、毎日ログインしてもらう仕組みは、
「ユーザーさんの習慣を作るため」だけではありません。

本質は、“やらなきゃ”と思わせすぎないための設計です。

・時間がかかりすぎない
・今日サボっても致命傷にならない
・数分で区切りがつく

これがないと、楽しいはずのゲームが心理的な負担になり、
一度中断すると復帰してもらいにくくなります。

ソシャゲのデイリー設計には、
心理的負担をコントロールするという側面もあります。

おはようございます！

本日は風邪が完全に治ったか不安のため、自宅で業務を行います。人それぞれかと思うのですが、私は自宅だと気が散ってしまうので、明日は普通に出勤したいところです。余談ですが、1番集中できるのは新幹線の座席だったりします。

本日も宜しくお願い致します！

オブジェクト指向が必ずしも最適解にならない場合｜ゲーム開発を事例として｜itchie@辰巳電子工業 この記事では、「ゲーム開発においてオブジェクト指向はどこまで使うべきか」と言う内容を整理します。 設計書や書籍ではオブジェクト指向の重要性が語られますが、実際のゲーム開発現場では少し違った議論になることが多いです。 問題は「良いか悪いか」ではなく、「どこで使うと後が楽になるか」という判断にあります。 現場でよく出る反応と違和感 の話題に触れると、「設計はきれいに作るべきだ」「オブジェクト指向で...

noteの記事を更新しました！

オブジェクト指向が必ずしも最適解にならない場合｜ゲーム開発を事例として｜itchie@辰巳電子工業 @itchie_tatsumi note.com/itchie_tatsu...

キャリアはスキルの足し算ではなく、経験の編み直しです。
障害対応での切り分け力は設計レビューに活き、炎上案件の反省は見積もり精度に変わる。
ゲームでのフレーム落ち対応は負荷見積もりの精度になり、バランス調整の苦労は数値設計の勘所になる。
同じ3年でも、やった量より「再利用できる形にできるか」で市場価値は変わります。

おはようございます！

建国記念日ですね。当社は発祥地が橿原市なのですが、よく考えたら発祥地が日本国と同じなのはすごいなあ、と思います。橿原神宮はじめ、久々に橿原市の史跡を巡りたくなりました。奈良県立橿原考古学研究所附属博物館はおすすめ！

本日も宜しくお願い致します！

「好きなことを仕事にすると幸せになれる」。これは一面では事実だと思います。
実際、当社にもゲーム開発にキャリアチェンジしたい方が多く来てくれます。ただ現場で見てきて感じるのは、成果が見えにくく地味な時間まで含めて受け入れられるかが分かれ道になる、という点です。
原因不明の不具合調査や微調整、曖昧な仕様のすり合わせ、事前の最適化など、完成の喜びより長い工程が続きます。
向き不向きは職種ではなく、作業への耐性と相性で決まることが多いと感じています。

運用保守の現場でも、将来のキャリアに資する経験は積めると考えています。運用で身につくのは、本番で負荷が集中しやすい箇所、障害に直結しやすい変更、安全に触れる範囲を事実と経験から判断する力です。
この視点があると、設計段階で詰まりやすさや運用破綻を理由付きで予見できます。重要なのは役割ではなく、運用で得た知見が次に活かされる構造があるかどうかだと思います。

ゲーム・Web開発現場でよく起きる「低レイヤー離れ」の問題｜技術が成熟した結果という構造｜itchie@辰巳電子工業 低レイヤーに興味がないのは問題なのか、という疑問 この記事では、「最近の若手エンジニアは低レイヤーに興味がない」と言われる背景について整理します。 これは本当にスキル不足の問題なのか、それとも開発環境の変化によって生まれた自然な構造なのか。 ゲーム開発やWeb開発の現場文脈を踏まえながら、なぜそう見えるのかを構造的に説明します。 現場でよく聞く反応と違和感 現場では、「メモリやCPUキャッシ...

ゲーム・Web開発現場でよく起きる「低レイヤー離れ」の問題｜技術が成熟した結果という構造｜itchie@辰巳電子工業 @itchie_tatsumi note.com/itchie_tatsu...

ゲームやWebの新卒・未経験の方のポートフォリオを見るとき、「人から指導されて作った」こと自体は、前提として理解しています。実務未経験なのですから、そこは問題にしていません。

面接で見ているのは、言われたことを再現したかどうかではなく、 なぜその形を選んだのかを、自分の言葉で説明できるかです。

現場に入って困りやすいのは、
・指示がないと止まってしまう
・分からない点を抱えたまま進めてしまう
・後から認識のズレが発覚する
こうした状況が重なるケースです。

そのため、ポートフォリオを見ながらの面接では、試行錯誤した点、迷った判断、割り切った理由を落ち着いて説明できるかを重視しています。

若い頃は「優秀」と言われていたのに、気づくと現場から離れていくエンジニアは少なくありません。
一方で、無理なく現場に立ち続けている人もいます。

その差は才能より「労働をどう再生産しているか」だと感じています。

まず守るべきは心身の健康、家族、自分の時間です。短期的な稼働より、生活の土台を壊さない働き方の方が、結果として安定した成果につながります。

無理はしない。ただ思考は止めない。知識をどう活かすかを考え続けることが、長く現場に立つための現実的な戦略です。

おはようございます！

衆院選にオリンピックにと、昨晩は珍しくテレビをずっとつけていました。
今朝目を覚ましてみると厳しい寒波もあり、現実を突きつけられますが、気持ちを切り替えて頑張ることにします。

本日も宜しくお願い致します！

エンジニアが経営者視点を持てと言われる理由｜待遇が決まる構造｜itchie@辰巳電子工業 「経営者視点を持て」と言われる理由が分かりにくい問題 ITやゲーム開発の現場で働いていると、「経営者視点を持ったほうがいい」という言葉を耳にすることがあります。一方で、現場の業務に集中している立場からすると、その言葉に違和感を覚えることも少なくありません。 この記事では、「なぜ経営者視点が語られるのか」「それが評価や待遇とどう関係しているのか」という疑問を整理します。 経営者になることを前提と...

noteの記事を更新しました！

#note
エンジニアが経営者視点を持てと言われる理由｜待遇が決まる構造｜itchie@辰巳電子工業 @itchie_tatsumi note.com/itchie_tatsu...

本日は大阪歴史博物館で企画展2 つ「河内源氏と壷井八幡宮」「郷土玩具が好き」を常設展の入場料で見られると聞き、寒い中足を伸ばしました。ボランティアの方による難波宮の説明もあり、大変ボリューミーな一日でした。

ゲームのグラフィックは、しっかりレビューしたはずでも、開発終盤になって不具合が表に出ることがあります。

最適化後にモデルがチラつく、長時間プレイでテクスチャが荒れる、負荷調整時に構造が重なり手が出せなくなる、といった例です。

レビュー時は問題なく見えても、条件や制約が変わると一気に露見します。怖いのは派手なバグではなく、「今は動くが後で詰む構造」。

レビューは出来栄えではなく、将来詰みそうな構造が残っていないかを見る工程だと思っています。