はじめに
初めてのアドベントカレンダーの3日目担当のinazawaです。今回のテーマは「初めて」ということなので、初対面の方々と「初めて」チーム開発を行った際の反省点や改善点を共有し、皆さんの「初めて」のハッカソンやコンテストでのチーム開発のヒントになれればいいなと考えています！拙い記事ですがよろしくお願いします！
エンジニア力編
学生間でのチーム開発では、これまで歩んできた経験が違うのでプログラミング自体が初めての方やその言語やフレームワークが初めての方、バリバリ経験を積んできた方などの幅広くエンジニア力が違った人たちが集まって開発することになります。そこでうまくいかなかったことを挙げていきます。
身の丈にあった技術選定
コンテストなどは１ヶ月長くても２ヶ月のものが多く、ハッカソンはそれよりも短期間のものが多いです。その期間でいろんな技術に挑戦しようとしてはうまくいきません。チーム開発では、初心者のメンバーがよく使用している言語やフレームワークを選択し、初心者の方に基礎的なところを負担してもらい、経験者が応用的なところや+αをチャレンジするとうまくいきやすくなります。
チーム間での開発力の調整
最初の点とも関係するのですが、メンバーの開発力を最初期に確認し、チーム間での開発力の格差をある程度解消しなければなりません。これはメンターの方にも言われたことなのですが、開発する前にチーム間で勉強会やチュートリアルをこなしておき、メンバーの技術力の底上げを行うと同時に、メンバー間での技術力の相互確認が行うことでどのレベルまで任せられるのか、どこからがメンバーにとってチャレンジするレベルになるのかの指標にもなります。また、コーディング規約やコメントをどのくらい残すのかなどのことも決めておくとよりよく開発が行えると思います。
コミュニケーション編
はっきりいって、コミュニケーションが一番重要です。チーム間のコミュニケーションがうまくいかなければ、ほぼチーム開発は失敗になります。柔らかでアットホームな職場やチームを作っていきましょう(ブラック企業ぽいけど)
雑談をしよう
雑談はやわらかい雰囲気づくりの上でかなり重要です。メンバーが技術の質問をしようにも、作品の改良案を言おうにもなんでも言えるアットホームな雰囲気がないとなかなか怖気付いて発言出来ません。発言したいメンバーが初心者なら尚更です。そんな時に、メンバー間の仲を深めておくと自然に聞くことができるし、改善案も積極的にいうことができます。雑談は全ての潤滑油になるのです。
質問やコードレビュー
質問やコードレビューに関しては非常に参考になる記事がこちらにあります。
このほとんどは初心者の時期にチーム開発を行ったことがある人なら体感したことがあると思います。マジで、「公式ドキュの〇〇みた？」や「その書き方見にくいな〜」とか言われるとどんどんモチベーションが下がります。学生間のチーム開発は、仕事ではないのでこういうことが起きるチームはメンバーがよく飛びます。私の初めてのチーム開発がこういう雰囲気のチームでしたがエンジニア4人中2人が飛び、残ったのは私と怖いレビュワーの二人だけでした。ですが、今振り返ってみると彼のおかげで公式ドキュメントを見る癖がつき、エンジニア力の向上につながったと思います。
ようやく公式ドキュメントのありがたみを理解することができましたし、先輩プログラマーたちが公式ドキュメントを勧めてくる理由も理解できるようになりました。
また、ダメなところを指摘する前にいいところをいくつか伝えてあげましょう（全くなくても態度や意図を褒めてあげましょう）。いいところをいくつか伝えることで、ダメなところを伝えても、比較的モチベの低下に繋がりにくく、〇〇の意図は間違ってなかったんだ！という自信にもつながります。
開発の小ネタ
コンテストやハッカソンではスケジュール通りにうまくいくことはほとんどありません。そこで実装する機能要件の取捨選択が必要になってくるのですが、評価される作品にしたいならコアの機能をメインに実装しましょう。例えば掲示板アプリなら、掲示板の機能が最初に開発し、次にログインやプロフィールなど、というふうにコアの機能を重点的に開発するほうがいいと思います。（ログインなどの周りの機能は他と差が出にくい機能であるため)
終わりに
ハッカソンやコンテストは非常に力のつく経験であり、普段個人開発をしているとなかなか気付かない点を多く指摘してもらえたり、他人のコードを読むことでどういう意図で作ったのか、などを考え、身につけることができる体験でもあります。なので、初心者の方にこそ、参加して欲しいし、その土壌をみんなで作っていくことで日本のエンジニアの育成にもなります。辛いこともありますが、頑張って乗り越えれば力になるので積極的に参加していきましょう！