グループ演習で学べる事

大学でのグループ演習で学べること

基本皆動かない

ほっといてプロジェクトが進むことはまずない。リーダーっぽい人がいても難しい。リーダー＋サポータがそろって、なんとか動く感じ。

メンバーの能力把握

必須。これがないと仕事の配分ができない。お互いにお互いの能力を知っておけば、円滑に進む。また、この時点で積極的キャラか、消極的キャラかも分かる。

勉強会

消極的キャラが多くても、必ずミーティングをやる。そこで勉強会は必要。知識を自分から仕入れられる人は稀。知識を仕入れて、プロジェクトが進む程度にはサンプルコードやレジメを与えて勉強することが大事。

コードを書かない

もし、リーダーかサポータに回るとしたら、極力プログラムは書かないほうがいい。自分がプログラムを書くのは最後の手段だと思ったほうがいいかもしれない。その分の労力は、プロジェクトの進歩管理、TODOリストの作成、メンバーのサポートの回るのが吉。
逆にしっかりとしたリーダーがいるなら、コーダーに回るのも悪くない。信頼が置けるならそれも良し。

設計を見る

常に見よう。全体の把握をする。それをひたすらに心がける。仕様を常にチェックし、それを基準に考える。変更があるなら、速やかにそれを実行。たぶん、それが一番難しい。そして、メンバーの全員とは言わないができるだけ多くのものにそれらを説明して、把握させよう。小さいプロジェクトならそれが一番だと思う。

10分ミーティング

レジメの用意や、仕事の割り振り、進歩チェックを必ずしよう。準備に時間をかけても、ミーティングに時間をかけてはいけない。10分なら集まれないことはないだろう。これに参加しないものがいるのなら、メンバーからはずすことを考えた方が良い。

完成を求めない

成績や完成させることを目的とすれば、自分が手を出してしまいメンバーの仕事をとることが頻繁に起こるだろう。それよりも、プロジェクトを動かすことがどれだけ難しいか。それを学ぶことをに集中しよう。

オールマイティーに動く

メンバーの特性をよく観察し、主張するものをリーダーに、自分がサポートに回るというのが一番楽だと思う。現実は、主張する人がいない場合が多いので自分がリーダーになることも多い。
ただ、プログラムがかけるから人に仕事が割り振れるかというとまったく違う。むしろ、バランスの良い人がそれになるべき。もし、自分が人よりある程度プログラムが書けたり能力があると思っている人は、プロジェクトを動かす難しさを知るには面白いかもしれない。

最後に

人を動かすより、自分が動く方が楽。しかし、どっちがいい選択かは状況による。