個人でゲームを作り、だんだん形になってきた人にぜひ覚えておいてほしいことがあります。
敵や弾が増え、マップが広がると次に問題になるのは処理量です。
単純な作り方のままだとすぐに重くなります。
そこで役立つのが次のようなアルゴリズムです。
・空間分割（QuadTree / BVH）：近い物だけ計算する
・A*探索：キャラクターの経路探索
・衝突判定（AABB / Sphere）：当たり判定を効率化
・LOD：遠くの物を簡略表示
・ステートマシン：敵やNPCの行動整理
どれも見た目は地味ですが、ゲームがスムーズに動くかを支える重要な技術です。
ITエンジニアは「答えが最初から決まっていない問題」を扱うことが多い仕事です。
現場では、再現しない不具合に出会うことがあります。ログを見て仮説を立て、再現を試す。そうした試行錯誤を繰り返しながら、少しずつ原因に近づいていきます。
ソフトウェア開発は、曖昧な状況を整理し、仕様や設計に落とし込み、実装として成立させていく営みでもあります。
要件が固まっていない開発や技術選定、障害切り分けなど、答えが決まっていない領域を扱える人が現場では重宝されます。
答えが決まっている仕事は仕組みやAIが得意になりますが、そうでない状況を整理し判断する力は、人の価値としてこれからも残っていくのかもしれません。
本日はサッカーの試合前に「中冨記念くすり博物館」を訪問しました。サッカーの遠征も負けたら腹立つだけですが、観光とセットならまあ気も紛れます。
リードになった直後「自分がやるのが確実な重要機能」を多く持った結果、気づけばチーム全体が“自分待ち”になる。
WBS上は問題なく見えても、現場では止まり方が違うことがあります。タスク配分で見落としやすい点をnoteの記事にしました。
#note
WBSでは見えにくい「開発リーダーの自分待ち」が起きるとき｜itchie@辰巳電子工業 @itchie_tatsumi note.com/itchie_tatsu...
大手で「なぜ売上を追い続けるのか」と疑問でしたが、上司の「成長は新しいポストを作ること」という言葉で視点が変わりました。
組織が停滞すれば席の奪い合いになりますが、成長していれば管理職だけでなく、専門職や新領域の役割も新設できます。
今の私には、組織の成長は単なる数字の追求ではなく、社員のキャリアの選択肢を広げるために不可欠なものに見えています。
停滞は現状維持ではなく、可能性の縮小。
挑戦し続ける組織だからこそ、個人の「なりたい姿」も多様に描けるのだと、今の実感を込めて振り返っています。
エンジニアの経験年数で、バグを見る視点は変わっていく気がします。
若手
不具合の種類
中堅
システムへの影響
ベテラン
ビジネスへの影響
同じ不具合でも、どこまで影響を想像できるかで見え方が変わります。
#エンジニア #キャリア
先日、仕事でプレゼンがとても上手な方々の発表を間近で拝見しました。
内容やスライド構成も素晴らしかったのですが、それ以前に印象的だったのは話し方でした。
・声が大きいこと
・ゆっくり話すこと（意識しないと早口になりやすいからかもしれません）
・大きなジェスチャーや豊かな表情
・会場の一人ひとりに語りかけるような視線
どれも少し芝居がかったように見えるほどでしたが、大げさぐらいの方が伝わるんだなあと実感しました。
特に「声を大きく、ゆっくり話す」だけでも内容が理解しやすく、自信も感じられます。
やはり「伝える力」は声から始まるのだと改めて思いました。
ゲーム開発を長くやっていると、不具合で「まずここを疑う」というポイントが絞られてきます。（あくまで現場の経験則です）
①入力系のエッジケース
同時押し、連打、先行入力。
②データ
コードに見えて、実はマスタ設定やセーブデータのフラグだったりします。
③状態遷移
攻撃中、ダメージ中、イベント発火など。状態の組み合わせでロジックが崩れることがあります。
④実行順序
処理が間違っているというより、順番が1つズレているケース。
⑤通信同期
オンライン要素があると、クライアントとサーバーのわずかなズレが原因になることがあります。
他にはメモリリークやハード固有の挙動などが多いですね。
RPGの開発では、調整しやすさを考えてスキルやパラメータをデータで持つこと(=データ駆動)がよくあります。
ただ、これを広げすぎると、見た目は整っていても挙動が追いにくくなります。今回のnoteでは、データ駆動が有効に働く範囲と、どこから重くなりやすいかを整理しました。
RPG開発でデータ駆動が複雑になりやすい場面｜itchie@辰巳電子工業 @itchie_tatsumi note.com/itchie_tatsu...
「コードを書き直す」のは一瞬ですが、「周辺への影響を読み切る」のにはその数倍の時間がかかります。なので、ベテランエンジニアは、エディタを開く前にまずこれらを確認する人が多くなるようです。
・git blame / 過去チケット（当時の背景など）
・cron / バッチ / ジョブ
・外部APIなどの依存関係
・DBの実データや分布
・過去の障害履歴
負債に見えるコードが、実は「過去の事故を防ぐための防波堤」だった、ということは珍しくありません。
改修の現場では、コードそのものより「そのコードがなぜそこにあるのか」を理解する時間の方が長いことも多いですね。
レガシー改修で怖いのは、複雑なコードそのものより削除してよいか判断できないコードだと思うことがあります。
コード検索で参照が見つからなくても、実際には夜間バッチや外部ツール、特定ユーザだけの処理から呼ばれている場合があります。
もちろん不要なコードの整理は大切ですが、レガシー改修では「コードが読めるか」より「なぜそのコードが置かれたのか」が分かる方が難しい場面も多いと感じます。
だからこそ、ツールやテストを使いながら背景を確認しつつ、少し慎重に触るようになります。
システム開発やゲーム開発でありがちですが、理想は
・仕様を決めてから設計へ
・設計が決まってから実装へ
と進むものですが、実際には仕様・設計・実装のすべてが同時に揺れながら進んでいくケースが相当数あります。
「仕様書を読め、仕様書を信じるな」という言葉はよく言ったものです。
炎上案件に入ると、よくこう言われます。
「人を増やせませんか」
ただ実際には
・仕様が揺れている
・確認待ちが多い
・優先順位が頻繁に変わる
など、作業の流れが詰まっていることも多いです。
人を増やす前に見るべきものをまとめてみました。
#note
炎上案件に入ると、なぜ「人を増やそう」という話になるのか｜itchie@辰巳電子工業 @itchie_tatsumi note.com/itchie_tatsu...
「非エンジニアの上司は話が通じない」「現場を知らないコーポレートがうるさい」「技術を知らない顧客が無茶を言う」といった言葉を見かけることがあります。
ただ視点を変えると、エンジニアがコードを書くことに集中できるのは、営業が仕事を取り、コーポレートが会社を回し、マネジメントが調整し、顧客やユーザーが価値を感じてくれるからでもあります。
給与の源泉をたどると、その多くは技術の専門知識を持たない人たちからの売上です。
技術は知見を誇るためではなく、誰かの不便を解決する道具として使いたいものです。互いを尊重する姿勢は忘れたくないですね。
改修あるある
若手「この改修すぐ終わります」
中堅「ここ触ると他壊れそう、ちょっと待って」
ベテラン「今日は触らない方がいい」
経験を積むほど慎重になる理由
・不可逆かもしれない
・影響範囲まだ読めてない
・この時間帯に障害を出すと復旧コストが高い
経験積むほど「直す」より「壊さない判断」が最優先になりますね。
#エンジニア #プログラマー
CPU / GPU / DSPの違いについて多くのご意見をいただきました。ゲーム開発の感覚で雑に整理すると、概ねこんな役割です。
CPU → ゲームを動かす
（AI、当たり判定、状態管理など。分岐の多い処理）
GPU → 画面を描く
（頂点処理、ピクセル処理など。同じ計算を大量並列で回す）
DSP → 音を作る
（ミキシング、リバーブなど信号処理系）
GPUを触ると強く感じるのが「アルゴリズムよりデータ配置」。
CPUでも重要ですが、GPUではメモリアクセスのパターンで速度が大きく変わることがあります。ゲームエンジンのデータ設計が厳密なのは、だいたいこの経験から来ています。
炎上したプロジェクトに助っ人で入ると、最初の打ち合わせでだいたいこう言われます。
「この案件、ちょっと事情がありまして…」
ただ、いくつか案件に入るうちに気づいたのは、「特殊なプロジェクト」ではなく「よくある条件が重なったプロジェクト」だったということでした。
炎上案件に入ると、だいたい最初に聞く一言｜itchie@辰巳電子工業 @itchie_tatsumi note.com/itchie_tatsu...
ゲーム開発者が会社を立てて見た「現実」5選
①信頼ゼロからのスタート
実績も与信もなし。「怪しい者ではありません」と実在を証明する所から。
②コードより泥臭い交渉
営業から海外の売掛金回収まで。作る以上に「集金」が生存に直結する。
③契約書は命を守る「盾」
一字一句が社員の生活を左右する。法務知識は最大の守備力。
④利益より「キャッシュ」
P/Lが黒字でも現金が尽きれば即ゲームオーバー。通帳の数字がHP。
⑤最初の10人が「文化」になる
初期メンの熱量や価値観がそのまま会社のOSとして固定される。
起業はチュートリアルなしのハードモード。
週末「CPUよりメモリが遅い」という話を投稿しましたが、それに絡めGPUを初めて触った頃を思い出しました。
当時のゲーム開発は、ポリゴン変換やZソートなど多くの幾何計算をCPUで処理していましたが、GPUはラスタライズやテクスチャ貼りを圧倒的なスループットで処理しました。
ただ触り込むと、GPUは万能ではなく「同じ処理を同じ形のデータに並列実行する」場合に強いと分かります。
逆に分岐が多かったり、データがバラバラに配置されていると急に遅くなります。
そこで強く意識するようになったのがデータの持ち方です。
最近のCPUでも、あの感覚に少し似ている気がします。
おはようございます！
本日は「関門国道トンネル開通の日」です。実は関門トンネルは徒歩で渡れてしまいます。子供の頃は、トンネル最深部の福岡県と山口県の県境を越える時にワクワクしたものです。ドラクエ1のリムルダールに向かう洞窟みたいな気分ですね。
本日も宜しくお願い致します！
プロジェクトの振り返りで「この判断は間違っていた」と言われることがあります。ただ、現場に長くいると、少し違う見え方をします。多くの場合、問題は判断ミスではありません。
問題は 「なぜその判断をしたのか」のログが残っていないことです。noteの記事にしてみました。
#note
プロジェクトが失敗する主な理由：「判断ミス」ではない｜itchie@辰巳電子工業 @itchie_tatsumi note.com/itchie_tatsu...
組織は人数が増えると、単に大きくなるのではなく「動き方」が変わるポイントがあります。
私自身、5人で立ち上げた会社を100人弱まで、現在の事業でも6人から250人規模まで拡大してきました。
振り返ると、5人・50人・150人・300人あたりで構造が変わってきます。
5人は口頭共有で回りますが、50人になるとコミュニケーション経路10→1225に増え、チーム分割やレビューなどの仕組みが必要になります。
150人を超えるとダンバー数の壁で、制度や評価基準が重要になります。300人規模ではチーム間連携が速度を左右します。
人数が増えるほど、組織は「人」から「仕組み」で動くようになります。
本日は豊中市の「久保修切り絵ミュージアム」を見学。切り絵体験もしてきました。昨日、テレビで久保修氏の特集をしたみたいです結構な盛況でした。
個人開発や、立ち上げ間もないスタートアップの方だと、優先度としては低く見られがちかもしれませんが、開発速度を大きく変える基盤機能があります。導入で開発速度が2〜10倍変わるケースも珍しくありません。
・ホットリロード（再起動せずにコードやデータ変更を即反映）
・デバッグUI（ゲーム内部の状態をその場で操作・確認）
・リプレイ機能（プレイ内容を記録して同じ状況を再現）
・プロファイラ（CPU/GPU時間を測定してボトルネック特定）
・ログ可視化（大量ログを整理して挙動を追跡）
後回しにされがちですが、後から導入するより最初に組み込んでおく方が、トータルの開発コストを数倍安く抑えられます。
おはようございます！
私は昔から肩幅が大きく、既製品の服ではXLとかを買っていました。ダイエットした今でも骨格までは縮まらないので1サイズ落としたぐらいなのですが、昨日は人生初のSサイズを購入。元がどれだけオーバーサイズに作られているのかとビビりました。
本日も宜しくお願い致します！
未経験からエンジニアになった方が、現場で戸惑うケースを何度か見てきました。
多くの場合、難しさの正体は言語そのものではなく、開発環境やツールが暗黙の前提になっている構造にあります。資格や言語学習はとても良い入口です。ただ実務では、環境構築やGit、ログ調査などの周辺リテラシーも必要になります。
また現場側も、このギャップを前提にオンボーディングを整えると立ち上がりはかなり変わります。構造を整理してnoteに書きました。
現場視点：未経験エンジニアが現場で戸惑いやすい本当の理由｜itchie@辰巳電子工業 @itchie_tatsumi
note.com/itchie_tatsu...
若手エンジニアが最初に知っておくと得することがあります。それは「CPUよりメモリが遅い」という事実です。
最近のCPUは計算が非常に速く、処理時間は計算よりメモリアクセスで決まることも多くなっています。結果を配列に保存して読むより、その場で再計算した方が速いケースもあります。
昔は switch→テーブルジャンプ が速いことが多かったですが、最近は if が有利な場面もあります。分岐予測が効くことと、テーブル参照のメモリアクセスが重いことが理由です。
最適化では計算を減らすより、メモリアクセスを減らす方が効くことがあります。アルゴリズムだけでなく、データの持ち方や配置を見る視点も重要です。
noteを更新しました！
「電話キャンセル界隈」|認知負荷とコンテキストスイッチの観点から考えてみる｜itchie@辰巳電子工業 @itchie_tatsumi note.com/itchie_tatsu...
即効性のある技術を学ぶと、成長を感じやすくモチベーションも上がります。アルゴリズム、新言語、フレームワークなどは成果が比較的早く見えます。
一方で、仕様を読み取る力、設計意図を言語化する力、レビューで論理的に伝える力、非エンジニアと対話する力は、成果が見えるまで時間がかかります。
ただ、プロジェクトが大きくなるほど差が出るのはむしろこちらです。地味ですが、仕様の入出力や例外を書き出す、設計の目的と方法を3行で説明する、といった訓練は確実に効いてきます。
可視化に時間がかかる分、続けた人ほど強みになります。
業務システムやWeb開発では「要件定義の難しさ」がよく話題になります。実務を見ると、最初から関係者のイメージが完全に一致していることは多くありません。クライアントは業務を理解していますが、それをそのまま仕様に落とすのは簡単ではないからです。
どこまで自動化するか、どんな操作なら負担が減るか、どんな画面なら迷わず使えるか。こうした点は、実際に動くものを作り触ってもらう中で見えてくることが多いです。
ゲーム開発でも同様で、「爽快」「遊びやすい」といった言葉だけでは仕様は決まりません。小さく作り、触り、調整する往復の中で要件が具体化していく、という構造はよく似ています。
