新人プログラマ、大暴走!? 間違った自発性が呼んだバグ地獄
僕がまだ新人だった頃、担当が決まっていない重要パートに、自分から手を挙げて挑戦したことがあります。
プログラミングだけでなく、企画の提案にも積極的に取り組み、ほぼ毎日終電近くまで残業しながら、一人で大量のコードを書き上げていました。
当時、周囲からは「すごい新人が入った！」と大注目されました。
ところが、この“全力アピール”が、後々とんでもない事態を引き起こしてしまったんです…。
今回は、そんな僕の新人時代の失敗談をお話ししたいと思います。
2025/1/26 追記 YouTube動画版も作りました！
「スキル実装を全部やりたい！」と意気込んだ新人時代
僕が社会人になって2年目くらいの頃、チーム内で、プレイヤーの攻撃スキルやジャンプスキルといった機能見当が始まっていました。でも当時、そのスキル開発のメイン担当はまだ決まっていませんでした。
僕は学生時代からインディーゲームをいくつも作っていて、「他の新人よりは自分ができるはずだ」と妙に自信を持っていました。だからこそ「スキル担当は自分が全部やります！」と手を挙げたのですが、リードプログラマの先輩は慎重で、「経験者をメインに置いて、サブとして新人をつけたい」と言っていました。
今思うと、それは非常に妥当な判断だったと思います。ところが当時の僕は、周囲の不安をよそに、夜遅くまで残業して勝手に枠組みを組み立て、「こんなの作ってみました！」とどんどん提案していきました。
最初は先輩プログラマも慎重でしたが、熱意と実際に動く試作品が評価され、最終的には僕がスキルのメイン担当に抜擢されることになりました。若手としては異例の待遇だったと思います。同期からも驚かれていました。
僕は調子に乗っていて、未来のことを考えていませんでした。
それに気づくのは、何年も後のことでした。
驚異的な残業と大量の試作
担当に決まってからの僕は、勢いのまま突っ走りました。
平日は夜10時、11時まで残業するのが当たり前で、土曜も出てきてコードを書いていました。残業が月に80時間から100時間なんていう時期も続きました。
「新人のうちに頑張って認められたい」と思っていたのも大きいです。実際、スキルのアイデアを一人で考えて実装し、次々とデザイナーやアニメーターに協力を呼びかけることで、20個近いスキルを開発しました。
その結果、「すごく積極的で頼りになる新人」と周囲から評判になり、ディレクターからも高い評価をもらえました。
一部の先輩は、新人の僕が大量の仕事を請け負っていることを心配していましたが、僕は決まって「いくらでも残業して全部やり切ります！任せてください！」と返していました。
でも、これが大失敗の始まりだった
最初のうちは「新人が頑張って成果を出した！」としか見えていなかったのですが、スキルが増えるにつれ、僕の設計の甘さが浮き彫りになってきました。
当時の僕は、保守性や拡張性などをほとんど考えていなかったのです。コードの構造はまさに“我流”でした。コンポーネント志向や、SOLID原則など、設計の理論は一切無視。複数のスキルで共通して使う規定クラス（SkillBase）が肥大化し、さらにそこから「攻撃スキル」「投げ物スキル」「ホーミング投げ物スキル」とどんどん継承を重ねて、継承ツリーが深く入り組んだ状態に。親クラスの処理を少し変えるだけで、大量のスキルの挙動が変わってしまう状態でした。
しかし、リファクタリングに時間を割く余裕はまったくありませんでした。メンバーの少なさに対して求められる物量が多かったため、「とにかく新しいスキルを量産して、動かすことが最優先」という空気がチーム全体を覆っていたんです。チームにコードレビューの文化がなかったのも痛かったと思います。僕の間違ったやり方を注意してくれる先輩プログラマは、いませんでした。
スケジュールの末期、やってきた“バグの嵐”
破綻した設計のまま、つぎはぎを重ねてなんとかスキル実装が一通り完了しましたが、いざデバッグ作業が始まると、恐れていた事態が一気に噴出しました。
当たり判定がずれていたり、特定のステージだけ挙動がおかしくなったり、エフェクトの表示が崩れたり……。問題が発生するたびに「このステージだけ処理をカットする」「関数をオーバーライドして空っぽにする」といった、その場しのぎの修正を追加してしまいました。
結果としてコードはどんどんスパゲッティ状態に。あまりのバグの多さに、さすがに先輩プログラマたちも危機感を感じ始めたのですが、プロジェクト全体の締め切りは間近。抜本的な作り直しはもう不可能でした。
そのため、大量の突貫修正を重ねて何とか出荷するしかなかったんです。
プロジェクトが成功すると起こる「次の問題」
これでプロジェクトそのものは、最終的にリリースまでこぎ着けてしまったんですよね。しかもタイトルとしてはそこそこ成功したんです。
そこで何が起きるかというと、「アプデや続編で同じソースコードを使いまわす」という展開になります。
僕自身は「成功したプロジェクトの若手」ということで次のチームに異動したのですが、僕が残したコードを引き継ぐ人たちは悲鳴を上げることになりました。バグが出ても、原因を探るだけで非常に時間がかかる。結局、新規のスキルを作るどころではなく、バグ潰しに追われてチームの生産性がガタ落ちしたそうです。引き継いだ後は、片手で数えるほどしか新しいスキルを作れませんでした。
失敗を振り返って思うこと
後から振り返ると、いくつかの大きな問題があったと思います。
新人をいきなりメイン担当にしたこと
大きな責任を負うポジションには、経験者の視点や設計の知見が必要です。そこを曖昧にしたまま「やる気があるから任せよう」としたのはリスクが大きかったように感じます。（強引に進めたのは本当に申し訳なかったですが）コードレビューの欠如
僕の独走状態を誰も止められなかった理由の一つが、チームにコードレビュー文化がなかったことだと思います。「見ればわかるだろう」と思うかもしれませんが、忙しい現場ほどレビューの仕組みを作らないと、質の担保は難しくなります。成果を“量”だけで評価していた
プログラミング経験のほとんどないディレクターが僕を評価していたので、「とにかく動くものがたくさんある＝優秀」という認識になってしまっていました。実際には、長期的な保守性やチーム全体への貢献が評価に含まれるべきだと感じます。
経験から学んだ教訓
こうした失敗を経て、僕は「ゲームプログラマの本当の成果とは何か」を強く意識するようになりました。
動く機能が数多くできることも確かに重要ですが、同時に「将来的な運用のしやすさ」や「他メンバーが引き継ぎやすいコードの設計」が大事だと痛感しています。
たとえば、クラスの継承をどこまで使うか、共通処理と個別処理の境目をどう作るか。そこを考えないまま量産すると、あとから必ずツケが回ってきます。特に大規模なチームほど、コードレビューをはじめとした仕組み作りは欠かせないものだと思います。
また、僕自身のように「新人がいきなりすべてを引き受ける」というのは、正直かなり危ういことではないかと感じます。少人数で作っていた学生時代のゲームとは違い、何十人、何百人というチームで進めるプロジェクトでは、洗練された設計ノウハウが必要です。
おわりに
僕が2年目で味わったこの失敗は、結果的に大きな学びになりました。
最初に伝えたように、「量産すればいい」というわけではなく、長期的な視点で保守や拡張をしやすい設計・運用を意識すること。そして、成果を正しく評価できるようなレビュー体制やコミュニケーションが欠かせないこと。
もし「やる気のある新人に全部やらせたい」と考えているチームがあれば、そこには慎重な配慮が必要だと思います。もちろん若手に任せるメリットはあるのですが、その過程で先輩プログラマがしっかりレビューし、必要に応じて介入する仕組みづくりをしておかないと、後々手痛いしっぺ返しを食らうかもしれません。
読んでくださったみなさんも、同じような状況に遭遇したら、ぜひ「長期的な保守の視点」と「チーム全体を見渡す設計」を意識してみてください。そうすることで、お互いに気持ちよく成果を出し合える環境を作れるのではないかと思います。
最後まで読んでいただき、ありがとうございました！
Xでも情報発信をしていますので、よかったらフォローしていただけると嬉しいです！