新提案

調布祭スタイル

やり方

1.報告会を前半,後半に分ける。 どのプロジェクトが前半,後半なのかはプロジェクト参加者の偏りを見ればだいたい分かれるのでは無いでしょうか。

2.発表する側のプロジェクトリーダーはプロジェクトの説明+報告を1分で発表する。 1分は簡潔に要点を説明するのに適した時間だと思います。当然,次の人に交代する時間を含めて1分です。

3.発表する側のプロジェクトは教室内に散らばり,作品の展示や説明などを行う。 調布祭,新歓スタイルです。発表していないがわが見学者という体で。

4.適当に時間が経ったら交代をする。 15~20分くらいが適当では無いでしょうか。

メリット

終了時間の予想がつき,長引かない。
興味のあるプロジェクトに質問,意見しにいける。全体のコミュニケーションが図れる。
プロジェクトの活性化につながる。

デメリット

自分が見学者の時に自分の興味のないプロジェクトばかりになる可能性もあるかも。

やるとしたら・・・


別の提案

ある人は,書いていきましょう。

対案1

やり方

煩雑するぎるプロジェクトをいったん整理して、親子関係をはっきりさせる。例えばAndroid系プロジェクト、iPhone、Arduino、etcは統合してスマートフォンでなにかやるとしていいレベルだとおもう。 吉里吉里プロジェクトもプログラミングプロジェクトの目的に準じているのでその傘下とみなしていいはず。 ゲーム系のプロジェクトも、1から始める~の傘下のようだし、発表はその親プロジェクトだけでよい。 親プロジェクトのリーダーが子プロジェクトの進捗状況を取りまとめて報告する。 発表内容は原則、進捗状況+プロジェクト方針の変更があれば報告、のみにする。 また、発表時間を遵守する。できないならばタイムキーパーをつければよい。 個々のプロジェクトの詳細は、Wiki等での情報公開で対応し、どうしても面と向かって発表したいという者が多いのであれば部会前に、任意参加の報告会を設ける。

メリット

先の案では報告会のために掛ける労力が多すぎる。プロジェクトの現状や、おおまかな活動内容が確認できればいい程度の報告会に、活動の総括である調布祭規模の発表スタイルを採用する意図がわからない。同時報告では見れない発表が必ず発生する。この案で発表プロジェクトを圧縮すれば、全プロジェクトの進行状況だけを把握することが出来る。

デメリット

個々のプロジェクトの詳細が報告会だけでは把握できない。が、前述したとおりWiki等で十分対応できる。そもそもppt等を作ってくるのであればWikiに上げてくれればそれでいい。wikiの活性化にもつながり一石二鳥。


トップ   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS