1
1

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 3 years have passed since last update.

地獄のチーム開発で気付いたこと

Posted at

はじめに

興味を持っていただきありがとうございます。
某IT専門学生のひかると申します。

過去の記事はかなりデザイン寄りですが、今回はチーム制作の話です。
今も尚かなり貴重な経験をしているので書き綴っておこうと思います。

あくまで、自分の経験と進行であって他の方々とは全く違うかもしれません。
私自身の伝記のつもりで書いております。
読むの際は、何卒ご了承の上ご反応お叩きください。:sob:
とは言いつつも誰かのヒントや助けになればいいなと思っています。

前置

現状の説明からしましょう。
とある案件を学校で扱っているのですが、数チームに分かれて開発し、優勝を決めるという形で進行しています。
つまり、チーム分けが非常に大事なのですが、、、私はインターンに行っておりチーム決めには参加できませんでした。:sob:
そして気付いてみれば教官にリーダーに任命されていて...といった状況です。
それぞれリーダーが立候補して欲しいメンツを取り合った中、余り物といっては失礼ですが、私はそんなチームを率いることになってしまいました。チームは全員で8人。

最初にチームを教えられた時には絶望いたしました。裏で肥溜と揶揄されていましたw:joy:

初動

物事なんでも初動が肝心です。
一応、三年間一緒のクラスにはいたので、開発に関しては大抵のことは把握しているつもりでしたが、今一度細かく色々なことを聞きました。

  1. 一番得意な言語は?
  2. どの分野を担当したいか?
  3. コーディングは好きか?
  4. どれくらいの時間を開発に当てられるか?
    などなど一部抜粋ではありますが、こんなことを聞きました。
スクリーンショット 2020-07-02 17.57.56.png

驚きの結果でした。
嫌いって答えたやつ、なぜこの学校にいる?:thinking:
全くもって把握できていなかったことを反省しながら、作戦を練りました。

まずは、メンバーの分担です。

役割分担

知っての通り、役割分担は非常に大事です。
開発効率やメンバーのモチベーションにもかなり影響してきます。
(ただの課題レベルな時点でメンバーにモチベなんてのはなかったわけですが。)

まず、最優先に考えたのは、コーディングが好きと答えた私以外の二人です。
この二人は間違いなく最大戦力です。
彼ら中心の開発になるのが予測できていたので、かなり自由に動けるようにセッティングしました。
(幸いなことに二人とも得意な言語や分野が分かれていたので悩まずに済みました。)
バックとフロントに分かれたので、二人にはホウレンソウ以外の縛りは付けず技術選定をさせました。

残った5人。
正直、戦力としてはあまりにも拙い者たちばかり。
彼らが今まで作ってきたものも見てひとまず得意な分野に振りました。
バック:4人 フロント:3人 デザイン:1人
というバランスの分担にし、二人の元で作業に入ってもらいました。

モチベーションの向上、維持

端からないモチベーションをどうやって持ち上げるのか。
一番の難所ですね。
幾つか試したので、まとめてみます。

やったこと

  • 課題であり評価に影響すると認識させる(効果中)。
  • 一週間のノルマ制にしてみた(効果無)。
  • ノルマ達成できない叱責と原因解明(効果薄)。
  • とりあえず褒めちぎる(効果中)。
  • 可能な限りアドバイスをする(効果薄)。
  • お互いの出来高を競わせる(効果薄)。
  • ペアプログラミング形式に変えてみる(効果薄)。
  • 放し飼い状態にしてみる(効果無)。

などなどやってみたものの、少ししか向上できず。泣

そして最後に試したのが、チケット駆動開発です。

チケット駆動開発をやってみて気付いたこと。

  • チケットに有効期限がつけると実質ノルマ制も包含。
  • チケットを終了する時に、一定の達成感を味わえる。
  • 達成感と同時に、キリが良くなるため、休憩や集中力の時zx奥に繋がりやすい。
  • お互いの出来高がよく見える。
  • 誰がどこをやっているか把握できる。
  • 自分に合った難易度のチケットを取れる。

同時並行でやったこと。

  • 管生物などは一旦褒める。
  • 出来なければ原因を問い詰める。
  • アドバイスをなるべく欠かさない。
  • 日常のサポートをする(悩みなど)。

以上が大体やってきたことです。
その甲斐あってかメンバーのモチベはそれなりに高く(無茶苦茶高いわけではないw)保てています。

過去に学び今回気付けたこと

  1. ついてきてくれるメンバーの大切さ
  2. 優先順位の大切さ
  3. チームにあった開発手法の大切さ
  4. メリとハリの使い分けの大切さ
  5. 重要な授業には何がなんでも出席する大切さ

以上が気付けた主な学びです。
過去に組んでいたチームのメンバーの優秀さに気付けました!

最後に

まるで終わったかのうように書いていますが、あくまで中間報告時点の話ですw
まだ完成もしていないし、この先どうなるかはわかりません。

リーダーの在り方なんてのは、結局のところ持論でしかなく断定できるものではないです。
いわゆる正解のない問題というものだと思います。
正解はなくとも問題は飛んできます。
そして正解はなくとも不正解は存在しているようです。
(圧倒的に不利なゲームですねw嫌いじゃないですw)

まだまだリーダーとしての実力のなさや能力として低いところも垣間見えてしまいました。
修正しつつ、能力を高めつつ、経験を積んで行きたいところです。

長々と失礼いたしました。
拙い文章で伝えたいことが伝わっているのかわかりませんが伝わっていれば幸いです。

また、完全に収束したら記事にできそうなら記事にしようかなと思っています!
では、ごきげんよう。

1
1
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
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?