ソフトウェア開発プロジェクトを蝕む10の典型的な過ち

　プロジェクト管理は決して精密な科学ではないが、これにソフトウェア開発が持つ予測が難しいという性質と組み合わせられると、大きな悲劇のレシピが生まれる。わたしは、ソフトウェア開発プロジェクトに取り組んでいるプロジェクトマネージャーがよく犯す過ちを数多く見てきた。それらの過ちの一部はソフトウェア開発に限ったことではないが、この文脈では特に頻繁に起こり、ダメージも大きい。

1．「人数を増やせばよい」という誤解

　Fred Brooks氏は同氏の有名な言葉の中で、よくあるプロジェクト管理の間違いについて「ある女性が9カ月に1人子どもを産めるからといって、9人の女性がいれば1カ月に1人の子どもを産めるわけではない」と表現している。そして、この間違いは今でも頻繁に見られる。ある問題に多くの人間を割り当てれば、その問題は早く解決するという考え方だ。残念ながら、これは正しくない。

　プロジェクトに人を1人投入すれば、その分だけプロジェクトに摩擦が増える--他の人に追いつくのにかかる時間や、他の人の作業とすりあわせをするのにかかる手間などが増えることになる。実際わたしの経験では、ある点を超えると、人が増えれば増えるほど、特に最初の数カ月間は、仕事のスピードは上がるどころか、かえって遅くなってしまう。そして、多くの人やチームに同時に分担させられない仕事も多い。そういった仕事は、一歩ずつ順番に進めて行くしかない。

2．間違った指標を採用する

　マネージャーは、例えば「成功」や状況の度合いを測ったり、業績の評価や分析を行ったりといった、さまざまな理由から指標を必要とする。わたしが非常によく見かける間違いは、集めるのが簡単な指標ほど、何かを測るには役に立たない可能性が高いということだ。もちろん、集めたり理解したりするのが簡単な指標ほど、使われることが多い。例として、「バグチケット」を考えてみよう。

　入力されたチケットの数を数えるのは簡単だ。しかし、これは品質を測る指標としてはよいものではない。なぜなら、それらのチケットのうち、どれだけがユーザーのミスが原因か、実際に「機能」の問題が原因かがわからないからだ。このため、マネージャーは次の段階の指標である、チケット解決率（1日または1週間、1リリースなどの、特定の期間当たりに閉じられたチケットの数）に目を向ける。もし、実際には解決していない問題のチケットを閉じるのが常態化しており、チケットの増加を招いているヘルプデスクを扱った経験があれば、この指標を元にして動いている組織を扱うのがどのようなものかはよくおわかりだろう。

　実際に仕事をしたりユーザーを助ける（例えば、ユーザーが問題が解決したと認めるまでチケットを開いたままにしておく）代わりに、組織はチケット解決率を上昇させるために、できるだけ多くのチケットを開き、できるだけ素早くそれを閉じようとしてしまうものだ。設けられた機能、施された変更などに関して作成された本当の「バグチケット」率や、それに類似するものなど、より役に立つ数字は、計測するのが難しいだろう。言うまでもなく、これは理解や収集、報告することが簡単な数字ではない。そのため、組織は、便利さゆえに、正しい指標よりも間違った指標に基づいて判断を下すことを選択することになってしまう。