多人数でソフトウェア開発を行う時、プロジェクトマネージャ(PM)の大きな役割は誰にどのタスクを割り振るかを決めることです。実際に開発が始まれば、PMが進捗を把握しようがしまいが、順調に終わる作業もあれば遅れる作業もでます。もちろん、人の意志は弱いので、「他人に見られている」ことには意味があります。意味があるからこそ、逆にぼくはPMだけに「進捗を監視する行為」を押しつける気はありません。開発メンバーが相互に進捗を見合う方が良いと思っています。開発の進捗は最終的にはコードです。つまり、「相互かつ継続的なコードレビュー」に価値があります。特権的な誰か(PM)に監視を任せて、他の人は他人の進捗には無関心、というよりずっと良いはずです。

と言うわけで、PMの責任の大半は誰に何をやらせるかという決定に関わってきます。

例えてみれば、試合中にどんなサインを出すかよりも、先発メンバーや投手の役割を決めることの方が監督にとって重要であることのようなものです。

各自にやりたいことをやってもらう、というアサイン方法があります。これは一見、責任放棄のようですが、無策というわけではありません。ソフトウェア開発の効率には個人のモチベーションが大きく効いてくるからです。知らないとこの効果を過小評価しがちですが、少なく見積もっても2倍の差はでます。効率が2倍ということは、2ヵ月かかる仕事が1ヵ月で終わるという話です。

モチベーションの話は今日の主題ではありません。今日の主題は、タスクの難易度とアサインの関係です。プログラマの能力に大きな差があることは良く言われます。生産性の差が10倍以上、もっと過激には100倍以上の差がある、と言う人もいます。数字に関してはどうでもいいので興味がないですが、能力差があるのは当然の話です。人間なので、得意分野や向き不向きもあります。アリエルにもマルチスレッドプログラマのO氏(アリエル的には負け組)やXMLプログラマのF氏(勝ち組)がいます。ちなみに勝ち組負け組は以下の資料を参考にしました。

• http://www.softpanorama.org/People/Ousterhout/Threads/ (字が小さくて見づらい)
• http://www.cs.utah.edu/~regehr/research/ouster.pdf (こっちの方が見やすい)

現代風に書き直すとこんな感じです。

勝ち組               プログラマ                    負け組
<=======================================================>
XMLプログラマ
                  Javaプログラマ
                                       C++プログラマ
                                                    Threadsプログラマ

CプログラマとPerlプログラマはもう生きている人が少ないので書いていません。

タスクアサインの話に戻ると、陥る罠は、難易度の高いタスクに能力の高い人を割り当ててしまうことです。難しい仕事を能力の高い人にやってもらうのは当然ではないか、と思うかもしれません。実はそれほど自明ではありません。問題の本質は、開発の難易度とその機能の重要度には相関が無い点です。作ることの難しいものがユーザにとって価値があるとは限りません。冷静に見て、無相関と考えるのが妥当だと思います。

理屈上は、重要な機能の開発ほど能力の高い人にアサインすべき、という結論が得られます。最初に、分かっていても陥る罠と書きました。この結論はなかなか実践できません。難しいタスクを能力の低い人にアサインして、そもそも終わるのか、という疑問があります。いや、疑問に思うならまだマシで、絶対無理、としか言えないことがあります。結局、難易度をベースに能力の高い人をアサインしておき、残ったタスクを残った人で分割する、ということになりがちです。重要度を無視するわけではないですが、二次的な尺度になることを否めません。

例えてみれば、相手の先発が松坂と分かっている西武戦と楽天戦を前にして、どちらにエースをぶつけるかという選択のようなものです。どちらに勝っても一勝と割り切って、エースを楽天戦に先発させるか、松坂相手に二線級は失礼と、エースを先発させるかです。ぼくなら、松坂にエースをぶつけます。だから、たぶんPMとしては失格です。