はじめに
これは、2015年10月にUnity未経験から幸運にもUnityの現場に参画し、1人で2016年3月にリリースまで辿り着いた話です。
これを書いた目的としては、
- 過去の案件の中で、記憶に残っているうちの1つなので、忘れないようにしたいから
- 自身が面談でこの経歴を聞かれた時、どのようにして乗り越えたかをきちんと答えられるようにするため
- あわよくば自分と同じ悩みを持っている人の助けになればと思ったから
です。
さて、まずは当時の筆者の状況から話していきます。
当時の筆者の状況
当時のスキルセットは以下の通りでした。
- Unity未経験
- C#未経験
- 実務経験1年半くらい（Javaアプレットを利用したWebアプリの開発のみ）
- プログラミング歴5年半くらい（大学1年生のC言語の講義から、使用可能言語はC、Java、PHP、HTML、CSS、JavaScript、Objective-C、ただし実務で使用したのはJavaがメインで、他は独学レベル）
現場入場（2015年10月）
Unity未経験ながら、幸運にも現場に参画させていただくことができました。
入場時、現場では2つのUnityプロジェクトが動いていました。どちらも新規開発プロジェクトでした。
一方はパズルゲームアプリで、課金システムやサーバ連携などを組み込んだ、パズドラやモンストみたいなゲームアプリでした。
もう一方は、とある市の観光アプリで、VRモードやアドベンチャーモードがあり、こちらは課金システムもサーバ連携もなく、アプリのみで完結するものでした。
自分が入ったのは後者のプロジェクトでした。こちらはプログラマが1名、デザイナーが1名、PMが2名、シナリオライターが1名というチーム構成でした（うろ覚え）。そして、自分はプログラマとして参画しました。
つまり、UnityもC#も未経験なのに、開発は1人でやらなければいけないということでした。
手を動かしながら、自分なりにイメージする
そもそも未経験なので、Unityとはなんぞや？というところから入りました。
一応、大学時代にクラスメイトがUnityでゲームを作ったという話を聞いていたので、「Unityは、ゲームを作るためのツールなんだな」という認識でした。
まず、公式サイトからUnityをダウンロード&インストールして、開発環境を整えました。
幸いにも、Unityはそれだけで環境構築できるのが有り難かったです。
まずは「Unity 入門」とググりました。すると、公式サイトのチュートリアルがヒットしたので、そこから手をつけることにしました。
このチュートリアルを通して、Unityの基本操作、GameObjectとは何か、コンポーネントとは何か、などを「イメージ」で覚えました。
具体的には、「人間だったり動物だったり建物といった物体がGameObject。GameObjectに動くための命令を与えたり、色情報を与えたりすることで、何もないものに命を吹き込むのがコンポーネント。そしてUnityエンジニアは、何もない3次元のキャンパス上にGameObjectやコンポーネントなどをうまく配置して1つの世界を作る創造主である。」と解釈しました。
まるで昔映画で見た、「ドラえもん のび太の創世日記」でのび太が創生セットで地球を作るみたいな。（わかりにくかったらごめんなさい笑）
この「イメージ」が重要だと考えています。
人間は、イメージによって視覚化された情報の方が理解しやすいからです。
そして、そのイメージは自分にとって馴染みがあるものがよいでしょう。
自分にとって身近なものと、専門的な知識を紐づけることによって、「これは○○でいうところの△△だな。」とすんなりと頭に入ってくるようになります。
これによって、技術の学習スピードが格段に上がり、2週間後くらいにはスムーズにUnityを扱うことができるようになりました。
未知なるものを恐れず、受け入れる
プログラミングができる人とできない人の大きな違いはなんでしょうか？
センス？理系科目が得意かどうか？勉強量の多さ？
どれも不正解ではないですが、はっきりと正解とは言えないと思います。
自分が考える大きな違いとは「プログラミングに対する恐れがあるかどうか」だと思っています。
自分は、大学生の頃に講義がきっかけで本格的にプログラミングをはじめました。
最初はC言語でしたが、自分の書いたプログラムが動いたことに大きな感動を覚えました。自分の思った通りに動いてくれることが快感でした。
他のクラスメイトが「全然意味わからない」と言っている中、自分は「こんなの簡単じゃん！」と思っていました。
難しい概念が出てくるにつれ、多くのクラスメイトが諦めムードを出している中、自分は逆にどんどん燃え、ガンガン概念を身につけ、気がつけばプログラミングの成績はトップでした。
どうしてここまでの差が出たのか？
おそらく諦めムードを出していたクラスメイトは、「プログラミングは意味不明だ、自分には理解できない」と恐れを抱いていたのではと思います。その恐れによって、学習する意欲すら喪失してしまっていたのではと思います。
自分の場合は、「プログラミングは楽しいものだ、自分の手足のように思うままに動いてくれる」と思っていました。そして、「自分にできないプログラムは存在しない」と思っていました。だからどれだけ難しくなっても、「自分が理解できないなんてありえない！」と、それが学習のモチベーションになっていたのではと思います。
仕事ならではのプレッシャーを利用する
学生時代なら、勉強していなくてもどうということはないですが、仕事となるとそうはいきません。
何しろプログラミングで給料をもらって生活しているわけなので、勉強して技術がつかなければ給料はもらえず、生活できなくなります。未経験ならなおさらです。
つまり、勉強せざるを得ない状況なわけです。そして、1日でも早く即戦力になることが求められる。
独学や大学でのプログラミングの講義と比べれば、格段に集中でき、身につくスピード早くなるはずです。
ただ、あまりにプレッシャーに押しつぶされすぎて精神病むなら、一度やめたほうがよいです。体制を立て直しましょう。
よりよい実装方法を考える
アドベンチャーモードの実装を一旦し終えた時でした。
ここで、「よし、とりあえずそれっぽく動いてるし、問題なさそうだから次に行こう」と考えるのは間違いです。
そうではなく、「もっとシンプルに実装できないかな？今後アドベンチャーモードで物語が増えたり、変更になったりした時に、簡単に実装できるようにしないとな。」と考えました。
いわゆる「リファクタリング」ですね。
最初は処理が少ないので、1つのクラスに処理を書くのはあまり問題になりませんが、実装が進むうちに処理が増え、1つのクラスでの管理には必ず限界が来ます。
その限界が来るとわかったら、今は大丈夫でもリファクタリングを検討するべきです。
クラスを分割したり、デザインパターンを利用したりして、今後に備えましょう。
自分は「そろそろリファクタリングしようかな」と思ったタイミングですぐにリファクタリングしていたおかげで、一貫してスムーズに追加や修正に対応することができ、特に大きな問題もなく、リリースまで辿り着くことができました。
ただ、これは開発が1人だったのも大きかったと思います。
チームでの開発だと、なかなかリファクタリングのタイミングが難しかったりすることもあるので。
一方のパズルゲームアプリのチームは複数人で開発していましたが、プログラムぐちゃぐちゃな上に炎上していて大変そうでした。。
どうやらネットからソースをコピペするだけで、ろくに自力でコードを組まなかったメンバーがいたそうです。。なんと恐ろしい。。
何より楽しむ
手を動かしながら、自分なりにイメージする。
未知なるものを恐れず、受け入れる。
仕事ならではのプレッシャーを利用する。
よりよい実装方法を考える。
これらをやり遂げるためには、「何より楽しむ」ことが一番です。
手を動かしながら、「こうなったら面白いだろうな〜！」と、面白おかしくイメージする。
「こんなのがあるんだ！面白そう！」と未知なるものを受け入れることを楽しむ。
「ここを頑張ったら、技術力もアップして将来につながる！」と自分の未来がよりよくなることを想像する。
「世界一シンプルでわかりやすいコードにする！」と自分のコードの美しさを極める。
どうやったら楽しくなるかを常に考え、実践していきましょう。
さいごに
いかがでしたでしょうか？
Unity未経験から現場に参画し、リリースまでに辿り着くまでに、自分自身心がけていたこと、実践したことを当時の記憶を思い出しながらまとめてみました。
この記事が、未経験で現場に参画した人や、プログラミング初心者の人たちにとって助けとなりますように。