【雑談】チーフプログラマー、気をつけることは？

[jay]

学校の共同作品制作でチーフプログラマー（プログラムリーダー？）の役目を任されました
複数人でゲームを作ること自体には経験がありますが、まとめ役になるのは初めてです

仕様書の通り動くようにプログラムの仕様を考え、必要な変数や構造体を用意する
そこまで出来たらチームメイトと自分がそれぞれ担当する箇所を決めて指示を出す、と言ったところでしょうか。
（ちなみにライブラリは学校配布のモノを使います）

プログラムの本体（ベースプログラム？）を僕が管理して、各々が作ったプログラムを順次それに組み込んでいく、という作業形態を取るのですが
（もちろんチームリーダーにもバックアップを保管してもらいますが）
どのようなことを心掛ける・注意するべきでしょうか？

構造体や変数には分かりやすい名前をつける、それぞれの用途をハッキリさせる（コメントを書く）
その関数がどのような動きをしているのか分かるように細かくコメントを書いていく、またチームメイトにもちゃんとコメントを残すように注意を促す

このくらいは思いつくのですが、注意を促す以外は個人でゲームを作る時にも言えることですしね
チーム制作だからこそ気をつけるべきことというのは何があるでしょうか？
経験があるお方がいましたら教えて頂ければと思います。

[たいちう]

学生としての経験がないから想像しにくいですね。
私の興味本位が半分の質問ですが、
他の回答者の為にも補足説明をしてもらえますか？

共同制作は全部で何人？どんな学校の何年生？
制作期間は何カ月程度？平均して週に何時間くらいさけるの？
メンバーの内で真剣に取組み、それなりの実力もある人は何人くらい？
チームリーダーとチーフプログラマ（あなた）の役割分担は？
プログラマは何人？他のプログラマと比較したあなたの実力は？
（上位10％には入る・中の上くらい・自信なし、程度の回答でいいんで）

[softya（ソフト屋)]

プログラムチーフだとしたほうが良いことは。

・プログラムの設計書を書く
・組み込むデータや必要なデータを整理する。ファイル構成を決める。
・そのゲーム専用のライブラリというか下回りを設計
・ｓｕｂｖｅｒｓｉｏｎなどでバージョン管理
・ツールが必要ならツールの設計
・構造体や変数だけでなく関数名の規約も必要です。constなども使うようにする。
・つねに進行状況を把握する。

なんて当たりでしょうか。

[jay]

それぞれの仕様を作るのに必要な時間を考えて、作業ごとに必要な時間を割り振って作業ごとの〆切りを決めて守らせるようにする、というのも必要ですね。
考えれば考える程色々出てくるような・・・。


＞たいちうさん
補足説明ですね、了解です

メンバーは全部で８名、プログラマーが５名（内１名がチームリーダー）とデザイナーが３名。　全員この４月から専門学校の２年生です
制作期間はおよそ３ヶ月、授業で使わせてくれる時間は６時間です
でもみんなやる気はあるのでプライベートの時間もそれなりに削ってやるつもりです。
幸い（今のところは）メンバー全員真剣に取り組んでいます
まだ企画と準備段階ですが準備はそれなりに進んでいるので、来週中盤辺りから本格的に制作を開始する予定です

チームリーダーは企画書の作成と担当講師への必要事項の報告
会合の招集と司会進行、プログラマーとデザイナーの作業の進み具合を見ておおまかな指示をだすこと（細かい指示はそれぞれのチーフが担当です）
そして（プログラム学科なので）当然プログラミングにも携わります。
どのようなゲームにするのか、どのようなシステムを実装するのかという部分は学生のみでの制作ということでみんなで話し合い、既に仕様もおおまかには決まっています（現在リーダーがそれをまとめた企画書作成中）

僕（チーフプログラマ）の役目はプログラムのベースとなる部分（必要なグローバル変数や構造体の準備、メインループの骨組みなど）を用意すること、これは今まさに行っている最中です。
そしてメインループで呼び出す関数の仕様を考えること
中身はみんなで分担して作りますが、この関数は何をするのか・どのような順番で処理するのか　等々大まかな流れを形作るところまで担当します。
リーダーからのおおまかな指示を元にプログラマー陣に細かい指示を出すのは僕の担当なので、当然プログラミングの作業に関しては僕が他のメンバーにもリーダーにも指示を出します。

ちなみに僕やチームリーダーがそれぞれ準備をしている間にも他のプログラマーのみなさんにはＢＧＭや効果音などの必要な素材をかき集めてもらっています。
デザイナーのみなさんは既に出来る所から作業を始めています。

他のプログラマーは、リーダーを含めてこの学校に入ってからプログラミングの勉強を始めたそうです
僕はＣ言語の勉強を始めて３年、ゲームプログラミングの勉強を始めて２年（ちなみにＣ言語検定２級）他の人より経験が豊富という理由で抜擢されました

聞かれた事にそのまま答えたつもりですが、このくらいでよろしかったでしょうか？

[jay]

＞softyaさん
なんだかこうしてたまにスレ立てする度に丁寧に教えて頂いている気がします。
いつもありがとうございます

言われてみれば１人で作る時は気ままに作業できましたが、チームで作るならバージョン管理もしっかりしておかないとバグや不具合の元ですよね
認識を改めないと・・・

constも使うとの事ですが、僕はいつも定数を宣言するときには#defineを使っているのですがconstを使った方がいいのでしょうか？
それとも何かしらの基準で使い分けた方がいいのでしょうか？
せっかくなので教えて頂けると嬉しいです。

[ISLe]

わたしがメインプログラマを担当したときは、
・初期化する関数の名前
・1フレームに1回呼び出される関数の名前
・後始末する関数の名前
の3つを決めたらあとは翻訳単位で好きなように書いてOKというふうにしてましたけど。

グローバル変数とか構造体とか、公開する情報が多くなるほど公開する範囲が広くなるほどまとめるのがたいへんですよ。
剥き出しのグローバル変数を使わないといけない状況はデスマーチまっしぐらという気がします。

[へろりくしょん]

constも使うとの事ですが、僕はいつも定数を宣言するときには#defineを使っているのですがconstを使った方がいいのでしょうか？
それとも何かしらの基準で使い分けた方がいいのでしょうか？

主に、関数の引数などの事だと思いますよ。

[softya（ソフト屋)]

constも使うとの事ですが、僕はいつも定数を宣言するときには#defineを使っているのですがconstを使った方がいいのでしょうか？
それとも何かしらの基準で使い分けた方がいいのでしょうか？
せっかくなので教えて頂けると嬉しいです。

C++ならconstを使ってくださいって意味でした。言葉足らずでしたね。
へろりんさんの言われるとおり、引数ではconstをなるべく書くようにしてください。
#defineももちろんですが、出来るだけenumも使ったほうが良いと思います。

軽いコーディング規約を決めておくのも３ヶ月と時間がないので良い方法かも知れませんね。
・構造体や変数だけでなく関数名の規約も必要です。constなども使うようにする。
も規約なのですが、戻り値の返し方とかエラー処理の方法とか、引数チェックでassertしようとかも決めておいたほうが結合中のトラブルを防げます。
ただ、あんまりにガチガチだと窮屈なので軽い感じで。

グローバル変数は、できるだけ機能単位で構造体にまとめられることをお勧めします。

[たかぎ]

他の回答者と重複することもあるのですが...

最初の段階でやらないといけないのは、プロジェクトの構造を決めることですね。
時間がないので、うまく（DLLも含めた）ライブラリの形でプロジェクトを分割して、それぞれに担当者を割り振った方がよいでしょう。
各プロジェクトは、結合しなくても動作させられるようにしたほうがよいでしょう（私は大抵コンソールアプリとして動かせるようにします）。

エラー処理の方針と、デバッグの手段も決めておく必要があります。
・例外を送出するのはどういうケースかを定め、例外クラスを整備する。
・返却値でエラーコードを返すのであれば、わかっている範囲でかまわないので、エラーコードの型や値を決めてしまう。
・エラーハンドラを使う場合は、ハンドラのシグニチャや設定方法などを決める。
・トレースのためのAPIやログの記録方法を決める。
・assertや、可能であればstatic_assertに関する方針を決める。

メンバ全員が共通に使うようなライブラリや、技術的に難度が高いモジュールは、（おそらく最もスキルが高い）チーフが引き受けるべきです。
そして、少々バグがあってもよいので、できるだけ早くほかのメンバが使える状態にしましょう。
逆にいえば、それ以外の量をこなすような仕事は他のメンバにまかせるべきです。

メンバのスキル次第では、もっと開発効率を上げる方法があるわけですが、スキルが低いとそれを理解させる手間でかえって効率が下がるので、状況を正確に見極める必要がありますね。
たとえば、SubversionやVisual SourceSafeなどは便利ですが、その習得で１日（多分２コマ＝３時間ですね）潰すぐらいなら、手を出さない方が得策だったりします。

[softya（ソフト屋)]

開発言語をC言語かC++をちゃんと明記されたほうが良いようですよ。話の流れからするとC言語みたいですが。

そうそう書き忘れてましたが、プログラマーから逆にリーダーやグラフィッカーにほしい情報・仕様を先に要求する必要もあります。
これはチーフがまとめたほうがスムーズに進むかと思います。
グラフィックはテスト用、仮のもの、本番と分けて出来るだけ早くもらったほうが開発がスムーズに進みます。

あと仕様変更が必ず起こると思いますが、手戻りが最小限になるようにメンバーでよく相談してください。

最後に大事なことで、スケジュールに必ず開発状況の途中の確認ポイントと最終デバッグの期間を設けてください。
その日までに、何らかの動く物を見せ合うことでモチベーションアップにもつながります。
出来れば本当のゲーム開発のようにアルファ、ベータリリースの日付を決めて置くことも良いんじゃないでしょうか。

[jay]

長くなりそうですので２回に分けて返信させてもらいます、お見苦しいかも知れませんがご容赦下さい


>>ISleさん
確かにあまり制約をつけ過ぎても他のプログラマーのみんなもやりづらいでしょうし、僕自身も必要以上に負荷が増えそうですしね。
もとからそのつもりでしたが、最低限の仕様を決めたら後は各々に任せるのが良さそうですね。

学生時分でデスマーチを体験したくないですしね（苦笑）
先生から聞きましたがもう体験しないと想像できない喰程に大変なそうですしね。

肝に銘じておきます、ありがとうございました。


>>へろりんさん
はうあ！　そう言う意味でしたか、ご指摘ありがとうございます。
ちょっと参考書を確認しておかなければ（え？）


>>たかぎさん
ご教授ありがとうございます
プロジェクトの構造は形を決めて今現在（宙船を聞きながら）作っている最中です、当然ですがメモ帳か何かで構造について説明しておくべきですよね
口頭だけでは上手く伝わるかどうか分かりませんし。

他のお方の回答も踏まえて一度割り振りを考え直すべきかもしれませんね（最も割り振りを考えている最中でしたけどｗ）

SubversionやVisual SourceSafeなどは便利ですが、その習得で１日（多分２コマ＝３時間ですね）潰すぐらいなら、手を出さない方が得策だったりします。

おっしゃる通りです、むしろＤＬして環境を整えて使い方を把握してみんなに説明して、となると３時間では済まない気がしますがｗ

まぁ、他のメンバーのスキルは過信できないので（僕も偉いことは言えませんが）、これも経験と思って頑張ります。
色々とためになるお話、ありがとうございます。

[jay]

>>softyaさん
むしろ僕の未熟さ故に意味を取り違えてしまって申し訳ないです。

列挙型は検定の勉強の時に意味と扱い方は身につけましたが、実際に使ったことは数えるくらいのような（汗）

そうそう書き忘れてましたが、プログラマーから逆にリーダーやグラフィッカーにほしい情報・仕様を先に要求する必要もあります

どのような画像や素材を用意するのか、これは（学生故に）ある程度は会合で決めると思いますが、それだけでは絶対不十分ですしね（汗）
チーフがまとめて要求することで余計な混乱を防ぐ訳ですね、納得です。

最後に大事なことで、スケジュールに必ず開発状況の途中の確認ポイントと最終デバッグの期間を設けてください。
その日までに、何らかの動く物を見せ合うことでモチベーションアップにもつながります。
出来れば本当のゲーム開発のようにアルファ、ベータリリースの日付を決めて置くことも良いんじゃないでしょうか。

まさに経験に基づく、といった助言ありがとうございます。
次の会合で早速アルファ版の仮の〆切り決めてみましょうか・・・、ってそれを決めるのはリーダーですね（苦笑）

何度も丁寧に教えて頂きありがとうございました。


いつまでも「助言」ばかりを頂いてそれと返信にばかり時間を取られていてもアレですしね（僕が遅筆なだけですが）
ひとまず「解決」とさせて頂きますね、助言を下さった皆さん、本当にありがとうございました。

[たいちう]

> 聞かれた事にそのまま答えたつもりですが、このくらいでよろしかったでしょうか？

ばっちりです。その情報を元にして私ができるアドバイスなど微々たるものですが、
他の回答者の役に立ったと思います。
何より、チームをまとめる人に必要なスキルの筆頭はコミュニケーションです。
この調子で頑張れば、メンバーの離反の可能性も下がると思います。
（質問してもリーダーからろくな返事が返ってこないと、
誰だってやる気をなくすでしょ。）

他の回答者と被る事柄、反する事柄もあると思いますが、
思いついたものを書かせてもらいます。


１．バージョン管理ツール

8人×3カ月 = 24人月ですので、プロなら数千万円のプロジェクトとも言えますが、
メンバーのスキルや割けられる時間、何より経験不足から、
十分経験を積んだ人にとっては、実質1～2人月程度の規模だと推測します。
この程度の規模ならば、プロジェクトのフォルダ毎コピーして、
DF.exeなどで比較すれば十分だと思いますので、
私もバージョン管理ツールの導入は不要だと思います。

メンバーに元々使いこなせる人がいるならば別かもしれません。
その他の便利なツールも、投資してから利益を得るまで時間がかかることを考慮してください。


２．タスクの粒度

絶対避けた方が良いと思う事は、実装すべき機能を5分割して、
チームの締め切りの１週間前までに各自分担を仕上げ、
それから結合してデバッグしようというような計画です。
（そんなことをしないように教わっていますか？）

メンバーが勝手な方向に走ったり、行き詰ってもSOSを出さなかったりするし、
リーダーとしても進捗管理もできません。
週に一度程度は結合し、プログラムの実行結果から徐々に成果が見えていく方が
モチベーション維持にもつながると思います。

例えばシューティングならば、
１．自機を表示
２．方向キーで自機を操作
３．自機が弾を発射
４．敵を表示
５．弾と敵との当たり判定
６．敵が弾を発射
．．．

などと言う感じに結合後のプログラムが育っていけば、
進捗も判りやすいし、メンバーも達成感が得られると思います。

[たかぎ]

> 8人×3カ月 = 24人月ですので、プロなら数千万円のプロジェクトとも言えますが、

これは事実誤認があるのでは？
3か月といっても、おそらくは1日あたり2コマ（=3時間）を週2回、前期いっぱいなので3か月（=13週）ではないでしょうか？
だとすると、3×2×13×8=624人時=3.9人月になります。
デザイナーが3人なので、プログラマに限れば約2.4人月になります。
しかも、おそらくは1回（場合によっては2回）は発表会とかがあると思いますので、さらに割ける時間は減ります。

スケジュール的には相当厳しいと思います。
なので、技術的にはまりそうな問題を最初に洗い出してクリアしておくか、場合によってはそれを回避できるように仕様変更するしかありません。

学校でやるので、同人活動よりはましですが、それでも途中で学校に来なくなるメンバや、顔は出しても実質的に何もしないメンバが出てきます。
これを避けるために全体のモチベーションを維持するのが一番大切ですが、それは、まずはリーダーの仕事ですね。
ただ、脱落者が出ることはある程度想定しておいた方がよいと思います。

[たいちう]

たかぎさん

> これは事実誤認があるのでは？

はい、私としては故意の事実誤認です。
人数がいて期間もあれば、相当の事ができるような錯覚を戒めるつもりで書きました。


> でもみんなやる気はあるのでプライベートの時間もそれなりに削ってやるつもりです。

と書かれているように、授業以外の時間も計算に入れれば、
普通に勤務するように週に40時間かけることも可能でしょう（計算上は）。

そんなことはないんだよ、と言う意図で書きましたが、
たかぎさんに伝わらなかったとしたら、jayさんにも伝わらなかったかもしれません。
ご指摘ありがとうございます。

[softya（ソフト屋)]

とりあえず、ありそうなデスマーチ・パターンと対処案を書いておきましょうか。

・仕様書のツメが甘い。
　[解決策]　時間外ミーティングをしてでも早急にまとめる。なぁなぁが一番危険。
・製作中に仕様が二転三転。
　[解決策]　みんなの意見を入れすぎない。上と被るが仕様を明確にして、全員が了承する。　
・チーフの指示が曖昧。
　[解決策]　仕様の分解か理解が足らない。プログラム全体の設計に精を出す。
・チーフの仕事量がパンク。
　[解決策]　とにかく他のメンバーに割り振るしか無い。あるいはチーフが死ぬ気でやるしか無い。
・結合したらバグが取れない。
　[解決策]　結合前にテストを良くテストを行っておく。チーフのデバッグ力が高くないと地獄に。
・リーダーがまとめ切れず脱落。
　[解決策] 　チーフのどちらかが早急にリーダーに。

ぱっと思いついたのはこんな感じです。

[たかぎ]

たかぎさんに伝わらなかったとしたら、jayさんにも伝わらなかったかもしれません。
ご指摘ありがとうございます。

そうかな？ という気はしましたが、一応念のため。