脱力駆動開発記スマートフォン用の表示で見る脱力駆動開発記ゲームアプリを作るエンジニアの日常・技術メモ閉じるHOMEWORKS閉じる2015-01-04新卒スマホエンジニアの2014年振返り明日から業務開始なので2014年の振返りと2015年の方針を再確認しておきます。社内研修java言語仕様➡ネットワーク➡js,html,css,photoshop等フロント側関連➡javaサーバサイド➡javaフレームワーク➡チーム開発演習という流れだった思えばここでjava仕様についてがっつり勉強したおかげで後に別の言語を使う際にスムーズに移行できた気がする。見る講師の方に勧められて買ったこの本の問題を解くのが楽しかった。チーム開発ではtwitterライクなwebアプリを作れとのこと。フロント・サーバー・デザイナの3つの役割があったわけですが自分はサーバー側を担当することに。apache/tomcatでサーバーを建てるところから始まりアプリはspringフレームワークを使って作成。エンジニア側のリーダーとして取り組んだけど、開発期間の最初はフロント側との連携がうまく取れなかった苦い記憶が。期限直前は泊まり込みでなんとか完成にこぎつけました。時間でカバーするのはよろしくないと気づき、現実的な見積もりと後のことを考えた設計を身につけることを固く誓った経験でした。弊社では研修終了前に部署と使用する技術の希望を申請することができます。様々な選択肢がありましたが自分はスマホゲームを開発する部署でクライアントエンジニアとしての配属を希望しました。そもそもこの会社に入ったのが今後一人で稼いでいけるようなスキルを身につけたかったからなのですが、学生の頃からサークルとアルバイトでやっていたのはサーバー側の開発だったので、会社ではクライアント側の技術をもっと学びたいという動機がありました。7月~希望通りスマホゲームの部署に配属され、最初の2週間は研修としてunityで新規ゲームのモック開発。7月半ばからはcocos2d-xを用いたプロジェクトへの参入が決まる。cocos2d-xということでc++を使うわけですが、既存コードで起きてるメモリリークを探すのにポインタやらデストラクタやらこれまで意識してなかった仕様をがっつり学んだ。9月なんやかんやあってこのプロジェクトの開発体制について上司に直談判したところ、なんやかんやあって部署内の別プロジェクトへ異動することが決まった。(なんやかんやの部分は機会があれば別プロジェクトではunity/C#を使っていました。このプロジェクトはコードが非常に奇麗で勉強になった。上長に当たる先輩がコードレビューを頻繁にやってくれたおかげでこの頃から「第三者の目」を特に意識してコーディングするようになった。学生時代に読んだリーダブルコードを再度手に取ってみると当時は実感の湧かなかった「分かりづらいコードあるある」が分かって理解は一際進んだ気がした。業務時間外ではunity(4.5)/NGUI/C#の勉強を主に進めていた。おかげでこの頃になると新規機能に関しても大体は一人でスムーズに実装できるようになっていった。残念なことに、プロジェクトの売上が伸びずにクローズすることになってしまった。今後の選択肢として9月頃までいたプロジェクトに戻るか、別部署のプロジェクトに異動するかを選んでいいと言われ迷う。最終的な判断は使うツールで決めました。cocosかunityですね。cocosとunityをどっちもプロジェクト単位で使ってみて感じたのはビルド・コンパイル時間の差があまりに大きいといこと。cocosはクリーンビルドして実行するとシミュレータ上に表示されるまで大体20分くらいかかったがunityは数秒。作業効率で言ったら断然unityだったので新しいプロジェクトに行く事に決めました。(cocosを用いたプロジェクトでそんなに時間がかかったのはヘッダファイルをお互いにimportしまくってる内部コードのせいでもありました。)というわけで、2015年1月からは別部署に行く事に。2014年にあった出来事はこんな感じです。学び研修も含めると3つの異なるグループで開発を経験したわけですが、その中での学びをまとめておきます。セクション間で必要な情報は過不足なく把握できる仕組みを作るゲーム作りにはプランナー・エンジニア・デザイナーといった役目の人がいるが、他セクションの動きを完全に把握している人はほとんどいない。パラメータ異常のバグが出た際に、それがサーバ側の不具合なのか、クライアント側の実装漏れなのか、プランナーのパラメータ指定ミスなのかというのは、各役割とそれぞれが実装で担当した箇所を把握していればすぐに特定できるはず。お互いが何に影響がある作業をしているのかは皆が平等に把握しているべきだと感じました。redmineを使ったタスク管理を全セクションが導入すれば一目でわかるのかな。コードを書く際には常に「第三者の目を」意識する自分の書いたコードも1週後に見れば他人のコードと一緒だなーと。第三者の目を常に意識することでより分かりやすいコードになるし、説明できるようにならなければならないので「詳しくは分からないけどとりあえず自分が望んだ動きをしてくれる」というコードがなくなる。「責任」と「心身の健康」で両立できる基準を自分の中にしっかり持つこの業界における心の処方箋というやつでしょうか。この1年で周りで潰れてしまった人を大勢見てきました。最終的に一番大事なのは自分なので、心身ともに追いつめられたときはプロジェクトのことは放っておいて自分のケアに勤めようと思ってます。責任と命を乗せた際に命が下がるような秤を持っていれば、自分の健康を損なわないで果たせる責任のラインをしっかり見極められると思うので。工数はエンジニアが提示するものこれは今思うと当たり前なんですが、これがまかり通らないプロジェクトが多々あるのが業界の現状なんだと思います。仕様と納期を元に工数が決まるのではなく、仕様を元に工数と納期が決まるのです。決まった納期が遅ければ仕様を削って再度工数を出す。このルールに説得力を持たせるためにはエンジニアが提示する工数の精度がより正確でなければならないので気をつけなければ。こんなところですかね。諸々踏まえて今年はどうするのかっていうのも考えます。2ヶ月ごとに1本アプリリリース会社からの独立はしません。学べることはたくさんあるし、何より収入が安定してるので。独立しない代わりに2ヶ月ごとに一本アプリをリリースするというルールを自分に課します。本当は1ヶ月につき一本にしたかったのですが、この年末年始で新しいゲームを作ってできた成果物を鑑みて2ヶ月と決めました。工数対実装に対する信用を得る自分のいた部署ではエンジニアの出す工数に対する信用があまりありませんでした。原因は様々なのですが、少なくとも自分と自分に関わるエンジニアの出す工数の精度は上げていきます。エンジニアとしてのアウトプット機会を増やす去年はインプットばかりだったので外へ出していきたいです。こんなところでしょうか。会社における地位や役職はあまり興味がないのですが、あれば嬉しいものだと思うので拾えるものは拾っていきたいです。去年は手柄を譲ることが多かったので自分の手柄ぐらいは主張してきたいです。Qi...2016-11-30開発合宿@山喜旅館この週末に山喜旅館に開発合宿に行ってきました。はてなブログPro会社でもプライベートでもゲームアプリを作ってる6年目エンジニアです。(2)はてなブログをはじめよう!cocokyoroさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。