LoginSignup
1
0

More than 1 year has passed since last update.

チーム開発で失敗した話とその時に学んだこと

Last updated at Posted at 2022-11-14

【はじめに】

 こんばんは。奈切しのです。
 最近、チーム開発を行っていたのですが、結論から言って失敗しました。 なぜ失敗したのか、私なりに考え、こういう人が失敗するという失敗談として記載していこうと思います。
 また、このような場合の対策として行うべきこと、そして最後に少々、今回開発をするにあたって学んだ技術についてまとめてありますので、どうぞお時間の許す限り最後までご覧ください。

【目次】

・実際に作っていたものの詳細
・どのように失敗したか
・同じケースを予防するには
・おまけ「今回新たに習得した技術」
・さいごに

【実際に作っていたものの詳細】

 こちらに関しては、著作権侵害防止のため、名前は伏せさせていただきますが、ファミリーコンピュータのゲームを再現しようという内容でした。作品名は挙げられませんが、内容としては、 「ブロックを破壊しながら上に登るタイムを競うゲーム」 です。なんとなく感づいている方もいるのではないでしょうか。「そのようなゲームをUnityを用いて模倣する」という内容でした。何を作ったか知りたい方は以下のリンクからどうぞ。ここでは名前を伏せさせていただきます。

【参考文献】Wikipedia

【どのように失敗したか】

 そして、ここからが本題の、「なぜ失敗したのか?」「何をどう失敗したのか?」について記載していきます。

 まず、Unityでチーム制作をするにあたり、ソース管理システムを利用すると思いますが、その際、GitHubとSourceTreeを利用したのですが、ペアの方がリポジトリを落としてくることができずに、連携が取れませんでした。当然ながら、その状況ではプッシュもプルもできず、コミットすらできない状況で、私のパソコンのみで制作を進めることになりました。

 そこまではまだよかったのですが、それからというもの、テクスチャの切り抜き作業を終え、燃え尽きてしまったのかスクリプトを書かず、私の作業量が膨大な量となってしまいました。担当の先生にペア関係を切って頂きました。どのようにしたら、ペア関係を解消せずに済んだのでしょうか。

【同じケースを予防するには】

1.プロジェクト始動時に適切な役割分担をする

 意外とできていると思っていても、いざ始まった時に何をしたらいいかわからなくなる等がありました。その原因として考えられるのは、しっかり役割分担した"つもり"になっていたのだとあらためて考えた際、思いました。

 どういうことなのかというと、「適材適所の分担にできていない」ということです。

 これは、「自分がやった方が速いのに...」と思った時点で破綻しているのです。私も実際そう感じた場面が多々ありました。「ペンタブ持ってるから私の方が速いのに...」という風になりました(笑)。


2.メンバーとの熱量を可能な限り近づける

 これは非常に大事だと痛感しました。なぜかというと、誰かが一人で頑張っても誰かがやらなかったら100%のパフォーマンスにならないからです。私はどこかで「チーム開発は掛け算である」という言葉を聞いた覚えがあります。

例えば、4人のチームで、3人の生産性が1だとします。しかし、1人の生産性は0.8でした。1人のやる気がないだけで、1x1x1x0.8 =0.8となってしまいます。
もし本当にチーム開発が掛け算なのであれば、納得してしまいます。ですので、如何に士気を高めるか、高めあえる人たちと開発できるかがカギになると私は思います。
※あくまでも個人的な意見です。

【今回新たに習得した技術】

 では最後におまけで、今回の開発を通して学んだマネジメント以外での技術について記しておきます。
今回しっかり触る機能はたくさんありました。
 例えば、
・OnCollisionEnter2D
・OnTriggerEnter2D
・GetCompornent
・Raycast
 主に上記の4つが大きな学びとなりました。

スクリーンショット (108).png
 まず、スクリプトを大量に書いたことで、C#の基本的な使い方がある程度わかってきました。
例えば、On~Enter系の関数は当たった時に自動で返ってくる等です。しかし、今回最も勉強になったのが「Physics2D.Raycast」です。
 そして、onGroundFlag = !onGroundFlag;にするとフラグを反転できると知り、新たな知識を得ることでプログラムを頑張る意欲になりました。

 Rayは一直線に当たり判定の光線を伸ばし続ける機能で、この光線の長さを調整して、自分の求めたい範囲に変え、様々な当たり判定に利用するというのが今回私が行った使い方です。今回は、頭とブロック、足とブロックの当たり判定が別々だったので、Rayを二つ利用して、判定を分けることができました。

 ただ、判定を調整しないと永遠に上にRayが伸びたり下に伸びたりするので、そこの調整が大変でした。
このRaycastに関しては、友人に教えてもらったのですが、その後自分でも調べてみたのでそのリンクを以下に貼っておきます。
【参考文献】UnityDocumentation

【さいごに】

 前半が失敗談、後半はほとんど技術のことに関してになりました。
 私自身もチーム開発の経験が乏しく、以前ゲームジャムに参加した際、私は何もできずに終わってしまいました。それこそ今回のペアの方のような振る舞いになってしまいました。なので、その反省を生かして、自分から行動、そしてわからないことはすぐに有識者に聞いたり、ネットで調べたりと様々なことができたかと思います。


 また、前回の失敗は今回で取り返せましたが、今回は今回でまた失敗したことがいくつかあるので、それを次、必ず繰り返さないように頭の片隅に常に置いておこうと思います。

 そして、チームで大切なことは感謝を伝えることだと思いました。任せっきりになってしまったら、
相手に「ありがとう」、そう伝えて、自分ができることを常に探していくのが大切だと再認識しました。

 最後まで長々とお付き合いいただきありがとうございました。それでは、また。

1
0
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0