こんにちは、エンジニアの新卒採用を担当している福島です。 先日行われた、学生向けイベント「げんなま」について、レポートします！
※過去のレポートも合せて御覧ください
プログラミング教育版
SHOWROOM版
MYCODE版
プラットフォーム版
キュレーション版
今回の登壇者
いつもサービスにフォーカスして行っているイベントですが、 今回は、毛色を変えて｢2年目エンジニア特集｣と称して、 各部門で奮闘中の3名の2年目エンジニアが登壇しました。
配属後、およそ1年半たった新卒エンジニアが、 どのような仕事を任され、どのように働いているか、 生々しくお伝えしました！
サーバサイド責任者兼スクラムマスター
新人研修後すぐにチラシルに配属された池松は、 次々と起きたチーム内の無茶ぶりを伝えます。
配属後4ヶ月で、サーバサイドの大黒柱に
2014年の8月に、エンジニア研修を卒業した池松は、 そのまま現在の「チラシル」チームに配属されました。 ようやく業務を覚えてきた同10月に、当時の上司からいわれたのはこんな言葉。
配属2ヶ月で難題を受け取った池松は、今では立派にチームの大黒柱になっています。
配属後1年足らずで、プロジェクト進行管理改善のリーダーに！
次の挑戦は、エンジニア以外の職種も巻き込む、プロジェクト進行管理改善のリーダー。 今年の6月、優先順位の付け方なども曖昧だったチームの 進行管理の改善を任された池松は、周囲を巻き込んでそれを実行しました。
何をすべきか、自ら考え、周りに説明し、納得してもらいました。 そして、何より大変だったのが、実践してもらうこと。
現在池松は自ら考えた進行管理がうまく機能するように、 自らスクラムマスターとなってチームを率いています。
Mobageプラットフォームのインフラ部隊
研修後、インフラエンジニアとして現場配属された浅見。 配属後1年で体験してきた、DeNAならではのインフラエンジニアのチャレンジを紹介しました。
時には技術課題に敗北することも。解決すること自体が価値ではない。
浅見から紹介されたエピソードは、｢技術課題を解決出来なかった｣というもの。
オープンプラットフォームのサーバ運用で用いている、 メトリクス可視化ツールで起きたトラブルの話です。
欲しい機能が入ったバージョンに上げたところ、メモリリークするようになり、 それを解決するために valgrind を使ったり commit log を追ったりして原因を探りました。
結果、 ツールが利用している外部ライブラリの内部でリークしている可能性が高いことが判明し、 そこで調査は打ち切ったと言います。
このライブラリを書き換えて解決するよりも、 メモリリークが起きたときに自動で再起動するバッチを仕掛けるほうが、 時間対効果のよい解決方法と判断したのです。
インフラエンジニアは多くの場合、技術課題の解決をミッションとしますが、 やはりサービスの運用が最優先。 時には運用でカバーし、技術的に理想の解決を諦めるという判断も必要になってきます。
ミッションは、「いかに作業時間を短くするか。」
参加者からの ｢みなさんはそれぞれ、どういう指標を背負っているのですか？｣ という質問に対し、浅見の回答は特徴的でした。
「インフラエンジニアである自分のミッションは、自分の作業時間を減らすこと。 自分がした作業は全て会社にとってはコスト。 安全にサービスが運営されていることを前提に、 今やらないと後々のコストになる作業は今やる、 技術的にいくらチャレンジングであっても、安定運用にプラスにならないものはやらない、 など、考えながら仕事をしています。」
工数を減らすと言っても、 今やるべき作業をやらずに後回しにすると後でしっぺ返しが来て、 結果的に作業工数は増えてしまいます。
将来のことも考慮した上で、インフラエンジニアが一番働いていない状態が サービスにとっても一番良い状態なのかも知れないと思いました。
｢戦魂｣のUnityエンジニア
最後は、ゲーム開発エンジニアとして奮闘している宇塚です。 大学生のころからゲーム開発が好きで、そのまま職業にしたエンジニアです。
機能オーナーからAI開発まで。自分のやった仕事でユーザが喜んでくれる喜びを体験
配属後、宇塚は戦友機能や、敵AI、バトル委任モードなど、 戦魂プレイヤーなら一度は触れたことのある機能の開発を担当しました。
バトル委任モードは、プレイヤーにかわって自動でバトルをやってくれる機能です。 AIが考えなしすぎると役に立たないが、 頭が良すぎるとユーザーが自分でやる意味がなくなってしまう というジレンマの中で、「ちょうどいいAI」を開発し、 Twitter等でも好評を頂きました。
こだわったのは「ひたすらにテンポ重視」
｢戦魂｣は、DeNAのゲームの中でも、リッチな表現を追求したゲームの一つです。 デザイナーが細部まで拘ってつくりあげたキャラクターが、 数多く登場します。
解像度を落とさずにキャラクターの魅力を伝えようとしたところ、 動作が激重に・・・！
戦魂のエンジニアチームは、 ・通信が必要なところは、予想されたタイミングで出来るだけ早く開始 ・UIはギリギリまで止めずに動かす ・頻繁に表示されることのないUIは必要になるまでメモリに載せない など、小さな工夫を組み合わせて、ストレスをかけないアプリを作り上げています。
当然、これらの手触りについては、企画書や仕様書には書かれていません。 実際に作って、動かせるエンジニアの腕の見せどころなのです。
質疑応答
今回は、年代が近かったこともあり、働き方やそれぞれのミッションに対する質問が多かったです。
Q. 入社する前に抱いていたイメージとの違いは?
A(宇塚). もっと怒られるとおもっていました(笑) スケジュールの遅延やバグを起こしてしまっても、あまり怒られないですよね。
A(浅見). 個人が責められるというより、チームとして、個人のミスを再発させないためにどうするか議論しますね。
A(宇塚). 結局、それでチームやユーザに迷惑がかかることはわかっているので、 怒られなくても凹むんですが・・・。
A(池松). たしかに、意外とみんな優しいです。 みんな論理的だから理詰めにされる印象をもっていましたね。
A(南場). それはみんな、チームに恵まれてるね〜。 DeNA全員がそうっていうわけじゃないからね。私なんかは・・・・(略)
(3名). ((((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
Q. ゲームアプリ市場は踊り場と捉えられることもありますが、今後どうなっていくと思いますか？
A(宇塚). ハードの進歩を考えると、 これからもっと、スマートフォンなどみんなが持っているデバイスで遊べるゲームの可能性は広がると思っています。 ｢業界がどうなるか｣というよりは、その技術を用いて、みんなに遊んでもらえるゲームを、 自分が作っていきたいですね。
おわりに
エンジニアとしてまだまだ駆け出しの3人ですが、 彼らがどのように働いているかは、 学生エンジニアのみなさんにとっても非常に興味深いものだったようです。
登壇など不慣れなメンバーでもあったのですが、 会場のみなさんのおかげで滞り無く開催できました！ ありがとうございました。
最後まで読んでいただき、ありがとうございます！
この記事をシェアしていただける方はこちらからお願いします。