■ はじめに

表題の通り、ゲーム業界で働いて10年を超えました（13年ほどかな？10年の節目にやればよかった…）
ここらで一度、自らの振り返りでもしようかな、という記事です、よかったらご覧下さい。
まぁまぁ長文なのでぼちぼちお読み下さい。

■ 自らについて

• 中小のゲーム開発会社（デベロッパー）勤務のプログラマー。

• 家庭用が主。

• 業界歴は13年ほど（月日が経つのは早い…）

• 他業種を経てから、専門学校通いゲーム業界へ

正直すげープログラマーでは決してなくて
普通くらいの自己評価です。

■ 専門学校時代

専門学校時代のお話はこちらを参照下さい。

■ ダメダメな新人時代

あの頃の自分は、今思い返しても、本当にダメダメだったなと思います。
何がダメダメだったかというと

1. 人に頼る事がなかなかできず、無知である事を恥ずかしがってしまう。

2. 貪欲に経験を積もうという意識も低い。

3. コードの品質も高くない。設計力が低すぎた。

4. 仕様に対して口出しする事もなく、決まったものをロボットのように実装。

▼「人に頼る事ができず、無知である事を恥ずしがる」

• 新人なんだし、無知である事を恥ずかしがらず、ぐいぐいいけば良かった。

• 今でも「そんな事も知らないの？」って言われるのは怖いですけど、一時の恥なんかどうでもよくて、プロジェクトを前に進めるのが優先です。今は必要に応じて聞いたり頼ってます。

▼「貪欲に経験を積もうという意識も低い」

• 新人のうちから、あれやりたいです！これやらせてください！と色々な経験を積むべきだったなと、ただ、それをこなせるだけのスキルが無かった…。

• ゲーム会社にいても、作りたいゲームが作れるとは限りません。やりたいタスクがあるなら飛びつこう。

▼「コードの品質も高くない。設計力が低すぎた」

• 新人だったので多少はしょうがないですが、クラス分けもあまり行わず、同じクラスに付け足し付け足しで、今思い出してもやべーコードを生成してしまったと思います、申し訳ない。

• 設計って「誰に何の役割（責任）をもたせるのか」を明確にすれば、自ずとスッキリできる感覚です。

▼「仕様に対して口出しする事もなく、決まったものをロボットのように実装」

• これの何がダメかというと、実装のしやすさ等を考慮していないので、汎用性や拡張性に欠けた作りになったり「これどこに使うの？」っていうリソースが出てきたりしがちです。

• 企画側の仕様通りのものをそのまま実装するのではなく「企画側の意図」を汲み取り、実現したい事は同じでも、コスト安く作りやすい方法を模索提案出来るとよいですよね。

■ ダメダメな中堅時代

まだダメダメなんかよw と思った事でしょう（すいません）
もちろん新人の頃よりかは、マシにはなってたと思いますが
自分の感覚として、ある程度使えるプログラマーになれてきたかな、と思えたのは6年目ぐらいからな気がします。
何がダメだったのかを振り返ってみようと思います。

▼「人に頼る事がなかなかできず、無知である事を恥ずかしがってしまう」

• 新人時代にもあったこれですが、やっぱりまだ「人に聞く」という行為、「そんな事も知らないのか」と言われるのを怯えて、一人で奮闘していた気がします。

• 人に頼らないので、タスクもキャパオーバーになりがちで、体調を崩す事もしばしば、結局他の方にフォロー頂く事もありました。

▼「実装難易度の低いものを選びがち」

• 新人時代の「貪欲に経験を積もうという意識も低い」と、多少被りますが「チャレンジしてこうぜ！」という意識が低く「失敗したくない」「使えない奴と思われたくない」という思いが先行し、できるだけ実装難易度の低いタスクを選んでいた気がします。

• そうするとどうなるか？というと、確かにタスクは無難に終える事ができるでしょうが、本人の成長に繋がりません。

• 困ったら誰かに助けてもらえばいいと思うので、できるだけ、今までやった事のないタスクにチャレンジする事をおすすめします。

▼「コードの品質も相変わらず高くない」

• 振り返ってみると、おそらくこの頃の自分は、自分に自信がなく「人にコードを見られる」という事が恥ずかしかったのかもしれません。

• できるだけ目立ちたくなくて（？）、極力クラス（ファイル）分けしないような実装だったり、共有化できるような処理を共有化してなかったり。今思うと意味不明な行動ですね。
  今はいかにクラス分けできるかを考えるというのに。

• あと、コピペプログラマーな気質があったと思います。
  コピペ自体が悪いというよりかは「自分のコード」として扱っていない事が問題でした。
  コピペしてきたとしても、そのコードが何をやっているのかというのを理解し、自分の中で咀嚼して「自分のコード」に出来ていればいいかと思うのですが、例えば、コピペしてきたコードにバグがあった場合、ただただコピペしてきただけだと「バグの原因がわかりません」という事になります、ダメですね。

■ ようやくマシになってきた

それ以降は、経験を重ねる事で設計力も上がっていき
また、リーダー経験等も経て、褒められる事も増えてきました。

リーダー経験を経て感じた事として、自分の強みは
コミュニケーション であったり 求められているものを察知する力 なのかな？
という事もわかってきて、少しづつ自分に自信がついてきました。
そうなってくると、仕事は楽しいしかなくなってきます。

▼ コミュニケーション

自分は、子供の頃からあまり人見知りをしない性格だった事と、関西出身で「ボケ」と「ツッコミ」が日常的にある環境で育ったので、人とコミュニケーションするのは好きだし、得意な方ですね。
自分を介して、縦や横のコミュニケーションを活性化させるように意識してます。

▼ 求められているものを察知する力

自分は、自分を評価する立場の方から、ありがたい事によく褒めて頂けているのですが、それは、上が求めているものが何なのか？を考えているからなのかな？と思っています。

以前、別業種で働いていた時の先輩の言葉で

といった言葉を今でも覚えています。

そういった意識を持つことで、今は役職持ちじゃなかったとしても
役職持ちの方のフォローやサポートを行えるようになり、その方から感謝されます。
また、いざその役職になった際にも、スムーズに移行できるかと思います。

▼ 成長に大事な事

成長していくには、定期的に振り返る事が大事なんだと思います。
前回のプロジェクトでは、どんな成功があり、どんな失敗があったか。
前回と比べて何が成長できて、自分にまだ足りない部分はどこなのか。
それを踏まえて次のプロジェクトではどうしていくか。

こういった事を意識しながら仕事に取り組む事で、毎回何かしらの気づきや成長があるんじゃないかな、と思います。

■ リーダーについて

業界歴10年超えてますけど、そこまでのリーダー経験はなくて、1～2年くらいのプロジェクトを、3つ4つといった所です。
管理する人数も多くて4、5人とかだったと思います。
そんな自分ですが、リーダーについて振り返ってみます。

▼ リーダーの役割

あくまで個人の意見ですが、リーダーの役割は
プロジェクトを前に進める事 かなと思います。
またそのためのサポート、フォローを行う事かと。
タスクさえこなしていれば無事終わるんだったら楽なんですけどね。

今、どういった問題が発生していて、それを解決するためにはどうしたらいいのか。問題は、技術的な問題なのか、コミュニケーションやワークフロー的な問題なのか。

技術的な問題であれば、解決策を模索し、最悪、百点満点の答えが見つからなかったとしても、何かしらの代替案を提案する。

コミュニケーション的な部分が問題なのであれば、自分を仲介・潤滑油としてコミュニケーションを活性化させたり、コミュニケーション・ワークフローの見直し・提案をする、といった事を意識しています。

▼ リーダーのプレイング割合

実作業もやりつつ、マネジメントもしつつ、な人を「プレイングマネージャー」と呼んだりしますが、自分はこれには否定派です。
否定派というか、それを行って「プレイング100」「マネジメント100」を叩き出せる人って、ほんの一握りだと思うんですよね。
多少なりともどちらかが犠牲になる…。

リーダーやマネージャーなど、管理的なポジションの人間は、極力実作業を持たずに、いつでも突発的な作業やフォロー・サポートができる体制がよいのでは？というのが自分の考えです。

とはいえ、じゃあ全く実装作業等はしないのか？と言われれば、正直自分も実装等はしてます。
ただ、できるだけ重い作業は持たないようにはしています。

■ リーダーをやる際に意識している事

自分がリーダー的なポジションをやる際に意識している点は以下です。

1. 何でも言いやすい雰囲気作り

2. 実作業は持ちすぎない

3. できるだけ作業者に実りある作業を割り振る

4. 1人にタスクが集中しないように

5. できるだけ属人性を下げる

6. 日々の様々な問題に積極的に介入

▼ 何でも言いやすい雰囲気作り

属にいう「心理的安全性」というやつですね。
言いたい事があるのに言えない、というのは不健全かと思いますので
そういった事がないようコミュニケーションには気をつけています。

▼ 実作業は持ちすぎない

これは先述の通り、いつでも突発的な問題や、他の人のフォローに入れるように、持ちすぎないようにしています。

▼ できるだけ作業者に実りある作業を割り振る

プロジェクトの成功だけを第一に考えるのであれば「いつもの人」にタスクをお願いしたほうが、確実性が高いです。
ですが、そればかりだと
タスクの属人性が上がる というのと 他の人の成長に繋がりません。

Aさんだったらすぐ終わる作業なんだけど、あえてＢさんに振って、何か困った事があればAさんに聞く、といったようなタスク割り振りも必要かなと個人的には思っています。

▼ 1人にタスクが集中しないように

1人に集中しないように意識はしていますが、他の人の手が空いていても
「スキル的にAさんじゃないとこなせない」といった作業に関しては難しい所ですね。

▼ できるだけ属人性を下げる

できるだけ「作業の属人性を下げる」という事を意識しています。

• 知識に偏りが出ないように、情報共有をこまめに行う。

• 先述の通り「いつもの人」に作業を振らないようにする。

• わかりやすいコーディング・実装を心がけ、他の人に引き継ぎが発生しても、引き継ぎしやすいようにする。

「Aさんにしかできない」作業があった場合
Aさんが何かしらの理由によって、プロジェクトを抜ける事があれば、プロジェクトは行き詰まってしまうでしょう。
属人性が下がっていれば、他の人がフォローに入れます。

▼ 日々の様々な問題に積極的に介入

主に、トラブルシューティングであったり「転がっているボールを拾う」だったりですね。
見てみぬフリをせず、他人事にせず、自分事として取り組む事を意識しています。これは別にリーダーじゃなくてもですが。

こういった事の積み重ねが「プロジェクトを前に進める」事に繋がるんじゃないかなと思っています。

今後どう生きていこうかな

個人的には、スペシャリストというよりはジェネラリスト向きだと思うし
キャリアパス的にも、ガリガリ実装のスペシャリストより、リーダーやマネージャー等の管理ポジションを目指していくのがいいんだろうな、とは思っています。

とはいえ、何かしら実装部分においても「これは他の人に負けない！」を持っていたいですけどね。
とりあえず、今目指している人物像としては
「どの会社でもそこそこやれる人材」
「何をやらせても70～80点を叩き出すような人材」
かなーと思っています。

長文お読み頂きありがとうございました。