多人数開発で大事なこと

id:mzp:20070304:manageでは『優秀な人材とは』について書くつもりだったけど、ちょっと切り口を変えてみることにした。
多人数で開発すると、一人での趣味プログラムとは違った部分がいくつかでてくる。そこで、今回のお仕事で気がついたこと・注意したことを列挙してみよう。
断定口調で書いちゃってるけど、たんなる経験論よ。あと、多人数とはいっても4・5人の小規模なものね。

仕事の分割

要するにモジュール分割が重要だよ、というお話。
プログラムを分割すると、その間のインターフェイスが必要となるため、プログラムの総量と複雑さは増加する。しかし、その反面、分割したモジュールがある程度独立性が高ければ(結合度が低ければ)、並行して開発することができる。

そのため、モジュール分割を行うと作業量は増えるものの、作業効率は上がる。言い換えるとモジュール分割をするとスループットが増加する。

適度なアシスト

ほったらかしはよくない。

なんらかのトラブルの遭遇した場合、ひとりで対処すると簡単なことを見落としがちになる。あるいは、ひとりだと無意味に焦ったり、凹むことがあるので作業効率が落ちてしまう。これを防ぐためには、隣に座って、その作業を手伝うのがいい。

また、言語によっては入門レベルを越えた部分に落とし穴がある場合がある(例:Javascriptのthis)。この種の問題に中級者が遭遇した場合、やたら時間がかかってしまう。これは、となりに上級者がついて、適当なタイミングでアドバイスをするのがいい。ただし、早すぎる段階でのアドバイスは問題そのものを認識できないのでよくない。

さらに、ほったらかしにすると、その人が書いたコードが把握できないので、土壇場での修正を他の人が行うことができない。

というわけで、1人だけで作業をさせず、最低2人ぐらいでチームを組ませるのがいい。

各自の特性の把握

プログラマにはそれぞれ特性がある。それを把握して、適当な対処が必要。

例えば、能力のばらつき。コーディングは得意でも、設計が苦手な人はいる。そういう場合は、一緒に設計を行ったり、出来上がった設計をチェックするようにする必要がある。逆もまたしかり。

あるいは、軽いトラブルに遭遇した場合、どんどん深みにはまってしまう人がいる。そういう場合は、隣に座って一緒に問題解決に当たるといい。それとは逆に、一人で静かに考えると自分で解決できる人もいる。こういう人はしばらく放っておいて、それでもダメなら手伝えばいい。

というわけで、特性を把握してそれによって対応を変えるのが大事。とはいっても、難しいんだけどね。

まとめ

• モジュール分割をしろ
• チームをつくれ。(一人ぼっちにするな)
• 特性を把握しろ

# ふう、こんな簡単な事、経験からじゃなくて、本とかから学びたいものだ