本プロジェクトは毎週木曜日に定例の報告会をしています！

---

こんにちは、ディレクターの笹口です。
GWも終わり、気づけば汗ばむ頃合いですね。あっという間に夏になりそう...ｱﾂｲﾉｲﾔﾀﾞ...

さて、今回は 「定例報告会のすすめ」　というタイトルで、プロジェクトメンバー全員が集まって行う定例会についてお話しできればです。

本プロジェクトは、毎週木曜日の18時から定例報告会を行っています。 コアメンバーは必ず会社の会議室に集まり、その他スポットで助力をもらっているメンバーやリモートで作業をしている人とはオンラインミーティングをつないで実施しています。

主なトピックとしては下記の5つです。

• 各セクションの進捗報告
• 議題の収集、話し合い
• プロジェクトのニュース
• 次回定例までの確認、マイルストーンの確認
• 雑談

それぞれについて、お話します。

---

各セクションの進捗報告

これはそのままですね。 企画セクション、プログラムセクション、デザインセクションのそれぞれのディレクターから、セクションの進捗の報告を行います。

ざっと、
　「今週はどんな作業をしたのか」
　「来週の作業予定はどんなものがあるか」
　「他セクションへの共有事項」
の3つの観点で報告をしています。

本プロジェクトでは、Gitでバージョン管理を行っているのでログを辿れば誰がどんな作業をしたのかはわかりますし、作業リストでステータスも確認できますが、全員の状況を一人で確認するのは結構大変なので、代表してディレクター3人で各セクションの状況を伝えることにしています。

チームでのゲーム開発では、セクション間での連携は必須になります。
例えば、「○○の機能が実装できたのでテクスチャを貼ってほしい」、「△△の機能を組むので使用したいパラメータの洗い出しをしてほしい」 などの状況では、セクションをまたいで調整が必要になります。
担当する人がすぐに動ける状況だったり、対応自体が軽微なものであれば特に心配事もないのですが、状況が転々とする中で、対応中のタスクや作業者の状況がどうなっている、という認識を全員で合わせるのが難しかったりします。
そのため、毎週の定例報告会でそれぞれのセクションの状況についての認識を全員でアップデートする目的で、各セクションの進捗を報告しています。
（開発初期は、チームの人数が片手で数えられる人数だったので、全員一人一人に進捗報告をしてもらっていましたが、今では人数も増えて時間がかかるため、ディレクターからの報告のみとなりました。）

議題の収集、話し合い

各セクションからの報告を終えたら、メンバー全員を交えた定例報告会で相談したい事項についての議題の収集を行います。
要は相談事がある人はいますかー？みたいな声掛けですね。 こちらも人数が増えてきたので、今では事前収集となっていますが。

基本的には、広く意見が欲しいものや、ディレクター陣への確認事項が主になります。
今だと、ロゴのラフを見ながらどれがよさそうか、などを話したりしています。

特に事前確認も設けていないので、誰でもフラットに投げかけができて風通しはよいのではないかなと思ってます。

プロジェクトのニュース

議題の消化が完了したら、ディレクター陣からプロジェクトとしてのニュースがあれば共有します。 次のマイルストーンはいついつで、要件はこんな感じ。とか。 全員の耳に届けておきたいことの共有です。

次回定例の確認

最後に次回の定例の確認をしておしまいです。
基本的に毎週木曜日の18時ですが、祝日だったり、予定が合わない人がいれば、このタイミングで調整して日程を決めます。
後々で調整しようとすると連絡を忘れたり、日程調整でバタバタして時間ももったいないので、こういう確認も大切。

雑談

時間が余った時には、雑談もしてます。というよりは、雑談混じりの進行になりすぎて、ズルズルと延びる、みたいなことも多々。
時間がもったいない、と思われるかもしれませんが、結局はチームメンバーも人同士。こういった関係性も大事なのです。

---

定例報告会のすすめ

定例報告会は、「作業の手を止めて集まる必要があり非効率的」 、「形骸化してしまいそう」 という忌避する声をよく聞きます。
確かにどちらも一理あると思いますが、それでも実施するメリットは大きいと考えています。
少なくとも、僕が設定した定例の目的に対して、一定の効果があると感じているためです。

目的その1 「作業メンバー間の関係構築」

本プロジェクトは同じ会社のスタッフを集めて開発していますが、メインで別のプロジェクトでの作業がある人も多く、同じ会社と言えど接点が少ないこともしばしば。顔と名前は一致するけど、どんなことが得意な人なのか、どんな人柄なのか、あまりよく知らない、なんてこともありました。
そこで、全員が一同に会す場で、メンバーが自分自身を知ってもらうことができる場を用意することが必要だと考えたのです。

最初は結構よそよそしく話す場面も多かったですが、今ではみんな打ち解けて、ケタケタ笑いも起きる場面もありますしね。

目的その2 「状況管理と情報共有」

初期は少人数での開発だったので、そこまで状況が掴みづらい、ということはなく、作業管理もそこまで厳格にせずとも支障はありませんでした。
ただ、人数も増えてくるにつれ、プロジェクトの全体像が掴みづらくなってしまい、これは情報のアップデートが定期的に必要だなと感じ始めました。とはいえ、一人で全作業者の状況を確認するのもツラい、ということで、他2人のディレクターと一緒に、各セクション単位で進捗をまとめて報告することになりました。
進捗を確認するために、各作業者には定例報告会と併せて週報の記載もお願いすることに。
これによって、容易に各ディレクターは自セクションの状況を整理することができましたし、定例での他セクションの状況を共有してもらうことで、全体像を効率的に掴むことができるようになりました。

これについては、ディレクター目線でのメリットのみならず、作業者目線でもメリットは大きいです。
メンバーが増え、チームが大きくなると作業者は細かい作業やパーツの作りこみに励むことになるので、ゲームの全体像が見えづらくなってきます。「他の作業者がどんなことをしているのか」、「ゲーム全体としての進捗はどんな感じなのか」 、というのはディレクターやマネージャーのみならず、チーム全員が確認できると良いと思います。

---

ちなみに、定例のやり方は都度やり方を変えて、その時々のチーム状況に合わせて変化しています。
当初は、ディレクター組の席の近くでこじんまりと開催していたり、チャットツールのスレッドの中で完結させようとしたり... 週次の開催ではなく、隔週でもいいんじゃないか、といった意見もありました。
どのやり方が有効なのかは、定例報告会の目的やチーム状況によって変わるので、うまく調整しながら実施する大変さは確かにあります。

ですが、うまく定例報告会が機能したときの恩恵は大きいと思います。
昨今のゲーム開発のチーム規模は大きくなりがちなので、特にゲーム全体像を掴みづらくなることの懸念は大きいです。コアメンバー10名以下の小規模な部類の本プロジェクトでさえ、管理が大変な訳ですし。
専門的に管理をしてくれるマネージャーがいれば、また話も変わりそうなものですが、全員が作業者となっているプロジェクトにおいては、こういった定例報告会は有効だろう、というお話でした。

もし、これを読んでいる皆さんがチームで何かを作るときには、定期的に顔を合わせて、状況を共有しあう場を設けてみてはいかがでしょうか？

それでは今回はこの辺りで。また次回。(｡･ω･)ﾉｼ