8
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

開発初心者が8か月間のチーム開発に参加して感じた反省

Last updated at Posted at 2019-12-09

始めまして。大学の部活動として1年半ほどバックエンドの処理を書いてきたひとです。

つい先日まで、部活動の一環で一年間のプロジェクトとしてスマホ用にエンジニア向けのSNSアプリの開発にサーバーサイドとして関わっていました。
リリースを目指して自分たちだけで開発を行うという経験が初めてで、失敗したこと、こうしておけば良かったという反省点も多く感じています。
そこで今回はその振り返りとして、自分への戒めも兼ねて皆さんへそうした経験をお話できたらと思います。

#はじめに
まずはこれまでの自分の経歴について触れると、

・大学入学時に今の部に入部し、プログラミングを学び始める。
・夏頃からバックエンドの処理を学び初め、3-4か月ほどの期間で部の先輩方に誘導されつつ学祭で展示するアプリの開発に携わる。
・今年の春にプロジェクトの企画を立て、5,6月ごろから今回のアプリの開発を始める。

といった感じです。
2つ目の展示用のアプリは、先輩方に道筋を示してもらいつつ学びたての一年生たちが開発を行うというもので、開発の期間は勿論、自分たちだけで開発した訳ではありませんでした。
そのような状態から今回のプロジェクトを迎え、一から自分たちだけで作り上げるという事で得られた事も多いアプリ開発であったと思います。
アプリのもう少し詳しい説明はこのプロジェクトのPMを担当して頂いた先輩が TechTrainを利用してチームでアプリ開発をした話(Android編) で触れて下さっているので、興味があれば見て頂ければと思います。

#1. 主体性をもつ
今回最も足りなかったと痛感しているのがプロジェクトへの主体性についてです。

巷でよく言われる、所謂指示待ち人間と言えばわかりやすいでしょうか。
去年の開発では先輩が道筋を立ててくれていたり(そもそも時間の制約が緩かった)、今回に関してもPMやサーバーサイドを引っ張ってくれた人がいてくれたりして、自分の中で誰かがやってくれる、だとか__とりあえず目の前の事をこなしていけばなんとかなるだろう__、という気持ちが少なからずあり、受け身な姿勢であったように思えます。

そんな中で、サーバーサイドの先導に立って居てくれていた方が直接の開発からは退く事になり、それから自分が主としてサーバーサイドを担当する事になりました。結果的に、

  • 残っているタスクの量を正確に把握できていない
  • 早い段階で気づけていたであろう誤りに気付かず仕様の修正が遅れる
  • クライアント側との情報共有が不十分だった

というような事態が起こり、__プロジェクト全体にも幾分か影響を及ぼしていた__と感じています。
決して開発が嫌だとかプロジェクトをやめたいという気持ちがあった訳ではなく、自分たちで企画した一つのアプリを完成させたいという気持ちはあったものの、中だるみしていた感は否めません。結局、勢いを取り戻したのは後半に当時のペースに焦ってからでした。

指示待ちでも完璧に支持をこなせば問題ないでしょうが、少なくとも自分のようにただ受け身になってしまっているとこうした問題が起こりがちだと思いますし、グループワークである以上受け身が過ぎると相手からもコミュニケーションが取り辛く全体のパフォーマンスを下げてしまうように思います。

今回の反省から言えるのは最後まで__自分のやりたい事、目指す物__を意識し続ける事と、他人が何とかしてくれるのではなく(自分の影響外は除いて)__なんでも自分でその事について考えておく__という意識が大事だという事でしょうか。プロジェクトへの主体性というのは今後も強く意識していきたいです。

#2. コミュニケーションを疎かにしない
後半焦ってペースを上げていた時に出てきた問題なのですが、自分のペースを優先するためにコミュニケーションが疎かになってしまったと後悔している節があります。

どういうことかというと、仕様共有等のコミュニケーションにかける時間を削って自分の独断で作業を進めてしまうという状態です。
サーバーサイドは二人で担当していてお互い作業を分担しながらやっていたのですが、全体の実装に影響を及ぼしそうな部分だとか、API仕様の変更というような箇所について、自分だけで判断して「こういう風に実装したのでお願いします」というような場面を多く作ってしまいました。また、自分の頭の中でこういう仕様で考えているけどしっかり共有したか定かではないという箇所も幾らかありました。

本来「こうしたいんですがどうでしょうか」となる所を話し合いをすっとばして実装しているので、実装自体はペースが上がりますし後半の開発速度がそれで補われた部分はあります。それでもチームで開発するにおいて、せっかく人がいるのに個人で独走していた感があるのは流石に良くなかったと感じています。

焦っていたのもありますが、僕個人がコミュニケーションを面倒くさがっていた点があるのも事実です。一人で開発するのとチームで開発するというのは当然異なりますし、自分(だけ)がその場凌ぎでやりやすいからではなく、コミュニケーションを大事にするチームの利点を最大限活かす、といった事を意識するべきだったと思います。

#おわりに
ということで、自分が今回のプロジェクトを経験して、反省した点、こうすると良かったという点を主に二点にまとめて書いてみました。
ただの自分への反省文と化していないかと心配しながら、この記事を見て下さった皆さんには何かしら伝えられていられれば幸いです。
開発中の時点でぼんやりと今回挙げた反省点については感じていたのですが、改めて文章にしてしっかりと振り返る事ができたような気がします。
来年も恐らく部の活動で何らかのプロジェクトに参加する事になると思うので、勿論他にも多くの場面で共通する事だとは思いますが、今回の経験、反省を活かして今後携わるものはより良いものに出来るように努めたいです。

拙い文章かもしれませんが、ここまで読んでくださった方には本当に感謝です。ありがとうございました。

8
2
0

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
8
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?