ただの適当な開発記

会社勤めしつつUnityでアプリ作ってる人の雑記

新卒スマホエンジニアの2014年振返り

明日から業務開始なので2014年の振返りと2015年の方針を再確認しておきます。

入社してからの軌跡

  • 4月

ネット業界の緑の会社に入社

  • ~6月末

社内研修
java言語仕様➡ネットワーク➡js,html,css,photoshop等フロント側関連➡javaサーバサイド➡javaフレームワーク➡チーム開発演習
という流れだった
思えばここでjava仕様についてがっつり勉強したおかげで後に別の言語を使う際にスムーズに移行できた気がする。

オラクル認定資格教科書 Javaプログラマ Silver SE7 スピードマスター問題集 (EXAMPRESS)

オラクル認定資格教科書 Javaプログラマ Silver SE7 スピードマスター問題集 (EXAMPRESS)

講師の方に勧められて買ったこの本の問題を解くのが楽しかった。

チーム開発ではtwitterライクなwebアプリを作れとのこと。フロント・サーバー・デザイナの3つの役割があったわけですが自分はサーバー側を担当することに。
apache/tomcatでサーバーを建てるところから始まりアプリはspringフレームワークを使って作成。エンジニア側のリーダーとして取り組んだけど、開発期間の最初はフロント側との連携がうまく取れなかった苦い記憶が。
期限直前は泊まり込みでなんとか完成にこぎつけました。時間でカバーするのはよろしくないと気づき、現実的な見積もりと後のことを考えた設計を身につけることを固く誓った経験でした。

弊社では研修終了前に部署と使用する技術の希望を申請することができます。
様々な選択肢がありましたが自分はスマホゲームを開発する部署でクライアントエンジニアとしての配属を希望しました。
そもそもこの会社に入ったのが今後一人で稼いでいけるようなスキルを身につけたかったからなのですが、学生の頃からサークルとアルバイトでやっていたのはサーバー側の開発だったので、会社ではクライアント側の技術をもっと学びたいという動機がありました。

  • 7月~

希望通りスマホゲームの部署に配属され、最初の2週間は研修としてunityで新規ゲームのモック開発。
7月半ばからはcocos2d-xを用いたプロジェクトへの参入が決まる。
cocos2d-xということでc++を使うわけですが、既存コードで起きてるメモリリークを探すのにポインタやらデストラクタやらこれまで意識してなかった仕様をがっつり学んだ。

ロベールのC++入門講座

ロベールのC++入門講座

分厚かった。

  • 9月

なんやかんやあってこのプロジェクトの開発体制について上司に直談判したところ、なんやかんやあって部署内の別プロジェクトへ異動することが決まった。(なんやかんやの部分は機会があれば
別プロジェクトではunity/C#を使っていました。このプロジェクトはコードが非常に奇麗で勉強になった。
上長に当たる先輩がコードレビューを頻繁にやってくれたおかげでこの頃から「第三者の目」を特に意識してコーディングするようになった。
学生時代に読んだリーダブルコードを再度手に取ってみると当時は実感の湧かなかった「分かりづらいコードあるある」が分かって理解は一際進んだ気がした。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

  • 12月

業務時間外ではunity(4.5)/NGUI/C#の勉強を主に進めていた。おかげでこの頃になると新規機能に関しても大体は一人でスムーズに実装できるようになっていった。
しかし残念なことに、プロジェクトの売上が伸びずにクローズすることになってしまった。
今後の選択肢として9月頃までいたプロジェクトに戻るか、別部署のプロジェクトに異動するかを選んでいいと言われ迷う。
最終的な判断は使うツールで決めました。cocosかunityですね。
cocosとunityをどっちもプロジェクト単位で使ってみて感じたのはビルド・コンパイル時間の差があまりに大きいといこと。cocosはクリーンビルドして実行するとシミュレータ上に表示されるまで大体20分くらいかかったがunityは数秒。
作業効率で言ったら断然unityだったので新しいプロジェクトに行く事に決めました。(cocosを用いたプロジェクトでそんなに時間がかかったのはヘッダファイルをお互いにimportしまくってる内部コードのせいでもありました。要は設計ミス。)
というわけで、2015年1月からは別部署に行く事に。

2014年にあった出来事はこんな感じです。

学び

研修も含めると3つの異なるグループで開発を経験したわけですが、その中での学びをまとめておきます。

1. セクション間で必要な情報は過不足なく把握できる仕組みを作る
ゲーム作りにはプランナー・エンジニア・デザイナーといった役目の人がいるが、他セクションの動きを完全に把握している人はほとんどいない。
例えばパラメータ異常のバグが出た際に、それがサーバ側の不具合なのか、クライアント側の実装漏れなのか、プランナーのパラメータ指定ミスなのかというのは、各役割とそれぞれが実装で担当した箇所を把握していればすぐに特定できるはず。お互いが何に影響がある作業をしているのかは皆が平等に把握しているべきだと感じました。
redmineを使ったタスク管理を全セクションが導入すれば一目でわかるのかな。

2. コードを書く際には常に「第三者の目を」意識する
自分の書いたコードも1週後に見れば他人のコードと一緒だなーと。
第三者の目を常に意識することでより分かりやすいコードになるし、説明できるようにならなければならないので「詳しくは分からないけどとりあえず自分が望んだ動きをしてくれる」というコードがなくなる。

3. 「責任」と「心身の健康」で両立できる基準を自分の中にしっかり持つ
この業界における心の処方箋というやつでしょうか。この1年で周りで潰れてしまった人を大勢見てきました。最終的に一番大事なのは自分なので、心身ともに追いつめられたときはプロジェクトのことは放っておいて自分のケアに勤めようと思ってます。責任と命を乗せた際に命が下がるような秤を持っていれば、自分の健康を損なわないで果たせる責任のラインをしっかり見極められると思うので。

4. 工数はエンジニアが提示するもの
これは今思うと当たり前なんですが、これがまかり通らないプロジェクトが多々あるのが業界の現状なんだと思います。
仕様と納期を元に工数が決まるのではなく、仕様を元に工数と納期が決まるのです。決まった納期が遅ければ仕様を削って再度工数を出す。このルールに説得力を持たせるためにはエンジニアが提示する工数の精度がより正確でなければならないので気をつけなければ。

こんなところですかね。

2015年の方針

諸々踏まえて今年はどうするのかっていうのも考えます。

1. 2ヶ月ごとに1本アプリリリース
会社からの独立はしません。学べることはたくさんあるし、何より収入が安定してるので。
独立しない代わりに2ヶ月ごとに一本アプリをリリースするというルールを自分に課します。本当は1ヶ月につき一本にしたかったのですが、この年末年始で新しいゲームを作ってできた成果物を鑑みて2ヶ月と決めました。

2. 工数対実装に対する信用を得る
自分のいた部署ではエンジニアの出す工数に対する信用があまりありませんでした。原因は様々なのですが、少なくとも自分と自分に関わるエンジニアの出す工数の精度は上げていきます。

3. エンジニアとしてのアウトプット機会を増やす
去年はインプットばかりだったので外へ出していきたいです。kobitoを活用。

こんなところでしょうか。会社における地位や役職はあまり興味がないのですが、あれば嬉しいものだと思うので拾えるものは拾っていきたいです。去年は手柄を譲ることが多かったので自分の手柄ぐらいは主張してきたいです。