プロジェクト・マネジャーが知るべき97のこと/熟練と並の開発者の生産性
さて、初めてソフトウェアプロジェクトにアサインされたプロジェクト・マネジャーのために、開発者のスキルに関する神話のウソを暴いていきましょう。本当にすぐれたソフトウェア開発者は、並の開発者よりもはるかに生産性が高いことを理解しましょう。実際のところ、本当にすぐれた開発者はそうでない開発者よりも、何桁もすぐれているという統計すらあります。1桁というのは10倍ということです。要するに言いたいことは、熟練したプログラマというのは並のプログラマよりも少々すぐれているどころではない、ということです。その違いはとてつもなく大きいのです。
新たにトレーニングを受けたソフトウェアプロジェクト・マネジャーにとって、このことは製品開発を計画するときにどんな意味があるのでしょう?
マネジャーは、たとえ優秀で才能ある開発者が手に入らなくても、二流の開発者からも何かしら有用なものが得られるものと考えています。これは間違いです。下手な溝掘りでもいつかは溝を掘れるでしょうが、ソフトウェアの開発は溝掘りとは違うのです。
ソフトウェア開発では、今日プログラムされたものが明日の基盤となります。二流の開発者に基盤を作らせてしまうと、本当にすぐれた開発者は前へ進む前に、後ろへ戻って欠陥を修正しなくてはなりません。二流もしくは並の開発者を雇うと、プロジェクトのベロシティ†は低下します。実際のところ、すぐれた人を加えるよりもダメな人をチームから外した方が有益なのです。
このことと、遅延したプロジェクトに人員を追加するとプロジェクトはさらに遅延する、という事実とを合わせて考えてみましょう。そうすれば、ほとんどの企業において、開発がゆっくりとしたペースでしか進まないのはなぜなのか、理解できるはずです。経験の浅いソフトウェアプロジェクト・マネジャーは、たとえば、倉庫係を増員すればするほど、すばやくトラックに荷積みできるのだから、プログラマも追加で雇えば雇うほど、プロジェクトを完了させるのに必要な時間も短縮できるはずだと思うのです。
しかし、これはうまくいきません。新しい人員をプロジェクトにキャッチアップさせるのには時間がかかりますし、ほかのプログラマの手をわずらわせることにもなります。さらに、チームに人員を追加するたびに、コミュニケーションチャンネルは増えていきます。ベッツィー・スーとビルの2名からなるチームでは、チャンネルはひとつです。そこにマイクが加わると、チャンネルは3つに増えます。こうしてチャンネル数は指数的に増大し続けるのです。
チャンネル数の算出式は、n(n-1)/2になります。12名からなるチームには、12(12-1)/2のチャンネルがあります。言い換えると、プロジェクト・マネジャーとして管理しなければならない関係が66もあるということです。さらにもう1名増えると、管理すべきコミュニケーションチャンネルは78になります。
並の開発者とともにソフトウェアを作ることで、プロジェクトの神話のウソが2つ暴かれます。ひとつは人員を追加することでプロジェクトを短縮できるという神話、もうひとつは並の開発者に並のペースで並の(バグのある/仕事以前の)コードを作らせても問題ないという神話です。実際には、並の開発者は全体の生産性の足を引っ張り、プロジェクトを完了させるのに必要以上の時間がかかってしまうのです。
解決策はあるのでしょうか?
はい、すぐれた開発者に強力なツールを与えましょう。そうすれば、もっと高品質なソフトウェアを、もっとすばやく手に入れることができます。それからもうひとつ、無能な人がいてもプロジェクトには役に立ちません。それどころか、ダメな開発者の面倒まで見なければいけないとなると、職人気質のすぐれた開発者の生産性は低下してしまいます。ソフトウェアは非常に複雑なので、工場の組み立てライン作業のようにはいかないのです。
もっとすばやいソフトウェア開発があなたの望みですか?
それなら、すばらしいソフトウェア開発者を雇うこと、そして育てることにもっとお金をかけましょう。短期的にも長期的にも、元が取れるはずです。
この作品はクリエイティブ・コモンズ 表示 3.0 アメリカ合衆国ライセンスのもとに利用を許諾されています。
あなたは以下の条件に従う場合に限り、自由に
- 共有 – 本作品を複製、頒布、展示、実演できます。
- 再構成 – 二次的著作物を作成できます。
あなたの従うべき条件は以下の通りです。
- 表示 – あなたは適切なクレジットを表示し、ライセンスへのリンクを提供し、変更があったらその旨を示さなければなりません。これらは合理的であればどのような方法で行っても構いませんが、許諾者があなたやあなたの利用行為を支持していると示唆するような方法は除きます。