現場に身を投げ、自身の成長の余地を知る

WRITER: internship
このエントリーをはてなブックマークに追加

自己紹介

初めまして、菅沼レンゾです。

2024年12月に株式会社グレンジの新規事業準備室で得た学びをこのブログで共有できたらと思っています。よろしくお願いします。

 

新規事業準備室とは？

ハイパーカジュアルゲームでグローバルヒットを目指すことを目的としています。

ハイパーカジュアルゲームとは、広告収益とアプリ内課金の２つの軸で収益を上げていくモデルで、海外で勢いを伸ばしています。

SGEもハイパーカジュアルゲームの市場でも戦っていくためにこの市場に挑戦をしていて、この挑戦をしている子会社のうちの１つがグレンジです。

 

インターン参加への目的

私はUnityC#での開発以外にDxLib、DirectXTKでの開発にも関心があり、実際にコンテンツの制作に打ち込んでいます。

技術領域を広げ、より深い領域への理解を深める取り組みと、チーム制作への参加を積極的にしてゲーム制作の経験を深めることもしていましたが、

チーム制作ではマネージャーを務めることがほとんどで、引っ張られる側の経験が浅かったのです。これでは、視野が狭くなってしまうと思いました。並びに、

学生同士では自分の成長が頭打ちになってしまっている、伸びしろが短くなってしまっているのではないのか？と思い、実務経験を積むことと実際に自分の腕前がどのくらい現場で通用するのかの腕試しを試してみることにしました。

また、会社説明会へ参加した際にサイバーエージェントの若手に積極的に挑戦をさせる、していくカルチャーと自分の常に挑戦と成長をし続けたいマインドがマッチしていると思ったのも決定打でした。

 

入る前と後の比較

グレンジさんへお邪魔する前には技術をある程度は磨けたつもりでしたが、「仕事の仕方」においては磨けていませんでした。

効果的なコミュニケーションの仕方、コードを書く際にどこを気にするのか、どのように質を担保していくのか、他職種の方にどのように仕事を引き継いでいけば、引き継ぎやすいのか？などは自分が意識したつもりになって満足していることでした。

これを特に学ぶことができたと思っています。

加えて、社員さんたちの経験、仕事をする時に考えていること、意識していることを密度高く聞け、実際に同じ現場で、同じ土俵にたって経験できたのは大きく、貴重な経験だと思っています。

 

得た学び

インターンを通して特にソフトスキルを伸ばすことができました。意識していたことを挙げていきます。

計３項目です。

  1. 記述したコードのクオリティの担保の仕方、どこをどう評価していくのか
  2.  チームで動くこととはどういうことか？
  3.  何を伝えたくてどのような演出でユーザーに伝えていくのか？

 

記述したコードのクオリティの担保の仕方、どこをどう評価していくのか？

今までスピード重視の開発しか経験していなかったため、「早く実装できて仕様通りに動けば実装の甘さや隙があっても許容される」と勘違いをしていました。

これはバグの温床になり得て、想定しない動作や実行結果の原因でかつ「負債」となってしまうことを学び、認識を改めました。

実装した機能のさまざまな状況への適応力、求められる処理が遂行されることが担保されているのか？

プログラマの意図通りにコードが書かれているのか？などきめ細かい箇所での学びが多かったです。

「実装スピード」より「実装した機能のメンテナンス性、拡張性、動作の安定性」を求め、既存の基盤の上で開発していくことをないがしろにしないことの重要性を実感しました。

実装のクオリティを担保する上で

・無駄な処理を実行していないか？

・無駄な変数宣言をしていないか？

・基底クラスの設計の意図を破壊していないか？

・可読性を下げるような処理を実装していないか？

・その一連の処理が適切な箇所で定義されているのか？

・さまざまなパターンに対してその処理が確実にどのパターンに対しても同様に、求められる実行結果を出せるのか？

・パフォーマンスを無駄に悪くしていないか？

 

上記の事項を意識することを学びました。

加えて、ソースコードだけでなくコミットをした差分が果たして必要なのか？など、徹底的に不安要素、バグ発生の可能性の排除、動作の安定性の担保をする際の評価をしていくことも学びました。

コミットする差分が最小限に抑えられることでチームメンバーの作業を停滞させる差分の衝突、ロールバックを確実に減らせ、コードレビューをするレビュアーのレビューの負担の軽減を望めることを学びました。これによって担保できる質の高さも底上げできると思っています。

 

チームで動くこととはどういうことか？

実装していく際に「チームで実装している」意識を持つことの重要さも同様に学べました。

・ひとりのノウハウでは対応できる範囲、分野が限られてくる

・もうすでに実装されている機能を聞き出すことによって「車輪の再発明」をせずに無駄な工数を削減、タスク消化の効率化が目指せる。

・自分より広い分野で深い知識を持つ人がいるので「経験」がないと解決できない問題も早期解決が目指せる。

・知見を借りることで納期に間に合わせることができる

 

また、一番私がチームで開発することのアドバンテージを感じたのは実装をしていく中で、煮詰まり視野が狭くなってしまって、実装の効率が著しく低下している際に他者の視点からの意見を求めて自分が見逃してしまった箇所を指摘してもらうことで、実装が進むことが本当にあることを知りました。

さらに、自分が何をすればいいかわからない、どう走ればいいかわからない状態をチームに共有せずにカバーしてもらうタイミングが遅れてしまった結果、タスクの遂行ができず自分の作業が負債になってしまうことを学びました。

また、経験から得られる知見はただ単純に知識を集めることより効果的で、より信頼できるものだと実感しました。

 

何を伝えたくてどのような演出でユーザーに伝えていくのか？

演出の実装を今回のインターンでは主に担当し、デザイナーさんと連携をとってタスクを消化していきました。

その際の上長のFBから得た学びから自分の頭の中にはなかった感覚を得ることができました。下記が自分が言語化できたことです。

・現実世界で明らかにこれはあり得ないと思うことをしない

「今まではゲームだからなんでもありなのではないか？」と勘違いをしていましたが、そうではないことを学び、認識を改めました。

横並びに置かれている木箱を右から左に波打つようにジャンプさせる演出の実装をしていたのですが、

「縮んでから飛んだ方が視線誘導できる上、”っぽさ”があるから実装してみよう」と安直な考えでゼリーが飛ぶみたいな演出を実装してしまいましたが、そもそも木箱はゼリーみたいに縦に縮んで伸びることはあり得ないから違和感があるとFBを受け、箱は何かしらの力が加わって跳ねることはあってもゼリーみたいな柔らかい物体の挙動をしないからそこに違和感の原因があり、違和感を感じる境界線が「現実で再現できる挙動をするなら違和感は感じないが、明らかに再現し得ない挙動は違和感を感じる」ところなのだと学びました。

個人的に、どこからどこまでなら違和感がなくどこから違和感を感じてしまうのかを研究をしていきたいと思っています。

 

・何を伝えたいかによって画面の要素へ意識を向けるタイミングを調整する

上記で触れた視線誘導に近いところなのですが、どこをみて、次にどれをみて…とユーザーが向ける意識の先を考えて実装を進めていきました。これによって想定する体験を的確にユーザーに提供できると学びました。

 

・常にプレイヤーの目線で演出を確認していく

演出の間隔が長すぎたりしないか、テンポ感が悪くなってないか考えてきました。

 

今後のコンテンツ制作で新しく取り組みたいこと

・モブプログラミング

新しくプロジェクトに参加する人のために処理を追いやすくなる、どのような思想で実装、設計をするのかを共有し、属人化をなくす。

 

・インターンで得た記述したコードのクオリティの担保、評価の仕方をベースとした実装

今まで書いてきたコードのクオリティが低かったのでこれを以下の方法で改善していく。

コードを可能な限り明示的に記述していき、意図が一目でわかりやすい状態のコードを書くこと。

 

// CS4014警告が出力されないための代入

var _ = DOTween.Sequence()

.AppendCallback(() => {

_waterSplashEffect1.Stop();

_waterSplashEffect2.Stop();

_idleAnimation.Rewind();

_idleAnimation.CrossFade(IdleStateName, 0.1f);

})

.SetLink(Body.GameObject)

.Play()

.SetLoops(-1);

 

上記のコードのようになぜ _ にDoTween.Sequenceの戻り値を代入しているのかを明確に記述して「これは意味のある構文だ」ということを示せるコードを記述していきたい。

このように書いた理由が、CS4014警告がコンパイルをしたタイミングでハンドリングされ、解消すべき致命的なエラーや、確認すべき警告文がコンソールから見えなくなるため、このようにCS4014警告を回避するために明示的にここで破棄をすることでコンパイラ側からも警告が出力されなくなるし、この構文の影響範囲が絞られるから。

 

実装の影響範囲を最小限に保ち、メンテナンスにかけるコストを削減する。

コミットした差分がその差分でないと求める実行結果が得られないのかを精査し、差分の更新箇所を最小限に抑えて他に作業をするメンバーの作業ファイルに対してロールバックや差分の衝突が発生しないことを担保していきたい。

・効率的なコミュニケーション

適度に認識をすり合わせて、「同じゴールを見る」ことを意識し、円滑なチームワークの実現を目指す。

 

・スケジュールマネジメント

「いつまでに最低でもどれが用意できていないといけないのか？」と今までは最終的にいつまでには実装と結合を終わらせる作業終了のデッドラインのみを決めていたことを今後は意識的に作業の終了と開始のデッドラインを引いたうえでタスクの進捗を頻繁に確認し、最低限必要な要件と現在割ける無理のないリソース量で満たせる追加の要件を満たしていく方法で、より確実で、クオリティの高い仕事の遂行を目指していく。

 

まとめ

今回自分の課題がソフトスキルを磨くことだとわかり、限られた時間の中で磨くことに取り組みました。また、自分が「スピードを優先すべき」と思っていたことも、実際の開発の現場ではそうでないことを学び認識を改めました。

腕試しをするつもりが、そもそも腕を上げれていないことがわかり、度々少し落ち込むこともありましたが、まだ自分は成長することができると気づきました。

このひと月は自分のエンジニアとしてのスキルのさらなる向上と成長を実感できるもので、自身の能力をさらに強化できることに気づくことができました。この貴重な体験を糧にエンジニアとしての修行をさらに積んでいく所存です。

この記事がこれからTechJOBを受けるか迷っている方、受けたいと思っている方、この記事が目にとまってここまで読んでいただいた方々へ何かしらの有益な情報を供給できることを祈って、この記事を締めたいと思います。ここまで読んでいただき、ありがとうございました。

災害時における動画配信のための衛星通信の有用性検証 #インターネットゼミ
次の記事
インターンでABEMAのスパイク時の累計メモリ割当量を2TiB削減した話
前の記事