チーム開発

趣味のプログラムと仕事のプログラムとの最大の違いは、「チーム開発」にあるような気がします。
　
チーム開発って何？っていう人のために。
チーム開発の基本の１つは、「ソース管理」ですね。
各人が勝手にソースをいじくり続けていては、いつまでも完成しません。
どこかで、Fixする必要があります。
また、プログラムというものは、ソースを修正した際には、どこかに影響がでることがあります。
昨日までは問題なく動いていたものが、あるソースを修正したために動かなくなった、ということがよくあります。
（そして、原因を調査したところ、実は新人が勝手にソースを修正していた、とか…）
というわけで、誰かがソースを一元管理する必要があるのです。
　
2つ目は、「チーム間のインターフェース」ですね。
例えば、Webアプリであれば、画面チーム・ロジックチーム・DBチームなどに分かれます。
そして、チーム間での値の受け渡しのインターフェースを決めたりするわけですが、
これがいい加減だと、
Aチーム「ここのパラメータを増やしたいんだけど…」
Bチーム「えーー！！その部分を変えると、うちの影響範囲デカいんですけど！」
Aチーム「そこをなんとか…」
Bチーム「（まったく…、最初にちゃんと決めておいてよ、、。）…ところで、さっき動かしたところ、おたくの処理にこうこうこういうデータを入れたら、落ちたんですけど」
Aチーム「え？それって、そっちでチェックかけるって話ですよね？」
Bチーム「いや、聞いてないよ。そっちでやるんじゃないの？」
Aチーム「そんな！こっちだって聞いてないよ」
という、ピリピリしたやり取りが繰り広げられます。
個人開発にはない醍醐味ですね（笑）
　
３つ目は「進捗管理」でしょうか。
例えば、趣味であればいつまでも作り続けててもいいのですが、仕事には納期というものがあります。
期間内にきっちり終わらせるよう、自分の仕事を管理できないと、どんなに技術力があってもダメプログラマーの烙印を押されてしまいます。
また、他から呼ばれる共通処理を担当しようものなら、それができないと他の人の作業を止めてしまうわけです。
それはとても迷惑ですよね。
　
と、こんな感じでしょうか。
推測ですが、ゲーム開発でも同じようなものだと思っています。
「ソース管理」は当然あるだろうし、「チーム間インターフェース」もプログラマーとデザイナー（ポリゴンのデータ形式とか）・グラフィッカー（抜き色とか）、プログラマーとサウンドディレクター（サウンドのデータ形式とか？）、といった連携をうまくとらなければならないだろうし、「進捗管理」は言わずもがな。