労力ではなく結果を評価する

ソフトウェア開発には多大な労力が必要です。とはいえ、「300 万行を超えるアプリケーションを開発している」という自慢話を耳にしたら、それだけのコードが本当に必要なのか尋ねてみましょう。

余計なコードが追加されるのは、たいていの場合、拡張性を考慮しすぎたためです。拡張性†は重要ですが、正しくやらないと逆効果になる恐れがあります。プロジェクトを遅延させる原因にもなりかねません。

プロジェクトスコープ外の余計なコードがあるということは、プロジェクト・マネジャーが余計な時間と余計な労力に見返りを与えているということです。もしプログラマは長時間仕事をするのが当たり前だと思い込んでいるなら、実際にプログラマがそれだけの成果を生み出せているか確かめましょう。

私は自宅の芝生を青々とさせたくて、毎日の水やりをスプリンクラーに任せています。ところがコロラドでの最初の夏、カエデの木のひとつがすっかり葉を落としていることに気づきました。私は暑くて乾燥しているのが原因だと考え、もっと水をやりました。ところが一向に改善する気配は見られません。専門家に助言を求めると、彼は私にこう尋ねました。「どれくらいの頻度でどれくらいの時間、水をやっていますか？」

私の答えを聞いて彼はこう言いました。「それが問題です！

水をやる頻度と時間を半分に減らしてください。そうすればよくなるでしょう。」

私は水のやりすぎで木を枯らしてしまうところでした。水やりを少なくすることが、実際には木のためになるのです。それが木の抵抗力をつけ、成長の助けになるのです。アドバイスにしたがってから2 週間後、木は健康を取り戻し、青々とした葉でいっぱいになりました。

勤務時間に関して、プログラマはカエデの木のようなものです。プログラマに短いけれども適度な時間と、大雑把に定義されたタスクを少し与えてみましょう。するとプログラマはいきいきと働きます。彼らに大きなタスクの束を与えて、定期的に残業するよう頼んでみましょう。するとプログラマは意気消沈します。しかも既存のコードを書き直して、さらにややこしくしたりするのです。なぜなら彼らには時間があり余っているためです。

私はみんながどれだけの時間働いているかを重視しているマネジャーの下で働いたことがあります。そのマネジャーは、従業員が実際に生み出すものよりも、土曜日の朝に仕事をしたり晩遅くまで残ったりすることの方が重要だと考えていました。しかし、プログラマが1 日に12 時間以上も高い生産性を維持して、効率よく仕事をするというのは、実際のところ不可能なのです。

別のチームのマネジャーは、従来通り8 時間の勤務スケジュールを守らせていました。確かに従業員が遅くまで居残る日もありましたが、それはノルマではなく例外でした。従業員は長時間仕事をするよう要求されていないことを知っていましたが、コミットした成果物をスケジュール通りに提供しなければなりませんでした。そのため、チームは注意散漫になることなく仕事に集中し、仕事をうまく優先順位付けして、時間を効果的に活用しました。開発者の能力ではどちらのチームも同程度でしたが、前者の消耗するまで仕事をするチームよりも後者のチームの方が多くのことを成し遂げていました。

プログラマには、どれだけ仕事をしたかではなく、彼らが実際にやった結果を報告させるようにしましょう。コンピュータの前でどれくらい時間を費やしたかよりも、結果を得ることに関心をもちましょう。あなたは結果指向のマネジャーであり時間指向のマネジャーではないとチームメンバーが実感すれば、彼らも自分たちの勤務時間ではなく、自分たちが達成した結果に注目するようになるでしょう。