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

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

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

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

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

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

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

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

3．現実離れしたスケジュールを組む

一部のプロジェクト管理手法でよく見られる問題は、スケジュールや時間の見積もりに関して現実離れした想定で決めがちだというものだ。どの開発者がどの機能部分に1カ月か2カ月以上作業するかは分かっていると本気で思っているマネージャーがいたとしたら（非常に大きな、幅広い機能でない限り）、おそらく間違っているし、失望する可能性が高いだろう。ソフトウェア開発は非常に予測が難しいものだ。スケジュールや優先順位を変えてしまう可能性のあるあらゆることを防げるか、それらがすべて想定に入れられたとしても、想定通りの時間で仕事が進むという保証はあまりない。

4．時間の見積もりが大雑把すぎる

時間の見積もりに関するもう1つの典型的な問題は、作業を十分に小さく分割しないというものだ。もしわたしが、ある仕事に1週間かかるだろうと言われたら、その数字はどこから来たのかと聞き返すだろう。その作業に含まれている小さな作業をすべて分析したのでない限り、「1週間」という時間の見積もりは単なる推測であり、無視すべきだ。

5．作業を計算に入れ忘れる

テストのような必要不可欠な作業を計算に入れずに決められたために、破られた締め切りがいくつあったことか。これが、作業を部分的なタスクに分割しないままスケジュールが決められた仕事を決して引き受けてはならないもう1つの理由だ。そのスケジュールの見積もりには、なにか重要なことが抜けている可能性がある。

6．コミュニケーション不足

常に全員にプロジェクトの状況を周知徹底しておくことは非常に重要であるにも関わらず、忘れられがちだ。これが原因でIT部門と事業部門の間に不信感が生じることも多い。事業部門が、プロジェクトで起こっていることを十分に掌握していないと感じるのだ。また、暗闇に取り残されていると感じるほど、事業部門はIT部門に対してマイクロマネジメントをし始めようとしたり、やり方を強制しようとする。関係者に対して、定期的に報告をし、また一定の節目を迎えたり状況が変わったりしたときに状況を知らせておけば、この問題を緩和することができる。

7．ビジネス上の優先順位を無視する

開発を進めている組織内でのプロジェクトの優先順位と、全体的なビジネスの観点から見たプロジェクトの優先順位、そして開発を要求している側から見たプロジェクトの優先順位の間には、大きなギャップがあることが多い。よくある問題は、ある部門にとって「優先順位の高い」プロジェクトが、収益を生まないためビジネスの観点からは重要視されず、このため開発者もそのプロジェクトの優先順位を下げてしまうというものだ。全員の優先順位が一致している必要があり、そのためには、ビジネス全体から見て優先順位が低いと見なされているプロジェクトを元に、事業部門が評価されないということを保証する必要がある。

8．手続きによる壁を作る

開発チームが追い詰められていると感じる場合、それに対する自然な反応の1つは、物事のスピードを落とすために、多くの手続きを作ることだ。わたしはどんな簡単な変更でも変更申請書（もちろん紙で）を3通作成して稟議にかけ、関係するマネージャーのサインを集める必要があり、その上で作業が終わるまでに最短で45日間かかるという職場で働いたことがある。言うまでもないが、この組織はビジネスでは「パートナー」や「仕事をするために重要な相手」と見られることはなく、コストセンターであると見なされ、そのように扱われた。手続きによる壁は、手続きの中にあるより根が深い問題や、企業文化の問題に対処するための対症療法であり、壁を作ることはそういった問題そのものを解決するよりも簡単だが（一部の企業では、問題が解決不可能な場合もある）、手続きによる壁を作ることは非生産的であり、敵意に満ちた環境につながる。

9．「すぐに本格的な作業を始められる」という神話

プロジェクトに人を増やす時には、すぐに本格的な活動を開始できると仮定しがちだ。ソフトウェア開発の世界にはすぐに本格的な作業を始められるということはあり得ないし、そういう発言をする人は間違っている。すべてのプロジェクトには順応期間があり、プロジェクトが大きくなるほど順応期間も長くなる。これは、あらかじめ理解し、掌握しなければならないコードの量が多くなるからだ。これを計算に入れるのを忘れると、大きなトラブルになる。プロジェクトの初期にはこれに数日から数週間しかかからないかもしれないが、プロジェクトが始まって長い時間経ってから参加した開発者が生産性を完全に発揮するには、何カ月もかかる可能性がある。

10．マルチタスク

これも、多くの人が自分が持っていると考えているが、本当には持っていない「スキル」の1つだ（「すぐに本格的な活動を始める」スキルと同じように）。マルチタスクを要求すればするほど、仕事の質は落ち、時間もかかるようになる。これは、数分単位のマルチタスク（電子メール、電話、実際の仕事などを切り替える）にも、数時間から数日単位のマルチタスク（複数のプロジェクトを処理する）にも当てはまる。人材に対して多くを要求するほど、歯車の狂いは大きくなる。さらに悪いことに、マルチタスクは仕事をダメにしがちなだけでなく、人間を押しつぶし、最終的にその人は他の仕事を探し始めることになる。その結果、プロジェクトの最中に新しい人材を迎え入れざるをえなくなり、さらに問題は大きくなってしまう。√