プロジェクト・マネジャーが知るべき97のこと/モグラたたき開発を避けよう

『プロジェクト・マネジャーが知るべき97のこと』(オライリー・ジャパン、2011年)を出典とする。

ソフトウェアプロジェクト・マネジャーは早く納品するための様々なプレッシャーに直面しています。とりわけ時間は重要です。どうすればすばやく仕事を片付けられるのでしょうか？

チームにバーニーとロブという2人のプログラマがいるとしましょう。2人とも有能で、同程度のドメイン知識を持ち合わせており、言語スキルも同じくらいです。開発を進めるうちに、あなたはロブよりもバーニーの方がすばやく機能実装を終えていることに気づきました。

バーニーがコードをすばやく仕上げることに専念している一方、ロブはコードのリファクタリング†に時間をかけていました。ロブの方が変数や関数にうまく名前を付けていました。コードが動くようになっても、ロブはコードをもっと小さな部品に分割しました。それから、コードの各部品が意図通りに動いていることを確かめるため、テスト仕様を書いていました。そしてある程度満足がいったところで、ロブはその機能のコーディングが完了したと宣言していたのです。

ところが、こういった細かいことについて、あなたは何も知らなかったとしましょう。機能が完了したと宣言するスピードだけを見れば、明らかにバーニーの方がすぐれているとは思いませんか？

数週間後、顧客に新しい機能をデモすることになりました。いつも通り、顧客は完成した機能を気に入ってくれましたが、今回はいくつか変更と改善を依頼されました。そこで、あなたは開発者にコードを変更するよう依頼しました。

やがて、新たに改善した機能を顧客のもとに持っていきました。顧客はロブが実装した機能を試して、その変更に満足してくれました。

ところが残念なことに、顧客はバーニーが実装した機能におかしなところを見つけました。新しい機能についてはうまくプログラムできていたのですが、以前はうまく動いていたのに動かなくなったところがいくつか見つかったのです。顧客はこれらを欠陥だと見なしました。あなたはバーニーに修正を依頼します。そうして、顧客はもう一度その機能をテストしました。今度はまた別のところでおかしなことが起こりました。どうやら何かが壊れているようです。一体何が起こっているのでしょうか？

あなたに子どもがいるなら、どんなことが起こっているのかわかるはずです。バーニーはモグラたたきのようなものを作っているのです。モグラたたきはゲームの一種です。子どもたちは木製のハンマーを手にして、ランダムに顔をのぞかせるモグラをたたきます。モグラが次にどこから顔をのぞかせるのかわからないので、子どもたちは喜びます。しかし、あちこちランダムに壊れたコードが顔をのぞかせるようなアプリケーションを修正するのは、少しも楽しいことではありません。それはあなたをイライラさせ、今後どうなるか予測もできません。そして、製品開発を遅らせます。バーニーは最初にダッシュしましたが、間違った方向に走ってしまったのです。

ロブは最初は遅いように見えたのですが、実際には質の高いコードを書いていたのです。彼のペースは持続可能なものでした。最初からコードの品質が高かったので、動作可能なまま、すばやく変更することができました。しかも、最初に書いておいたテスト仕様のおかげで、新しいコードが他の部分と互換性を保てているか、すぐにフィードバックを得ることができました。

機能実装にかかった時間を計測するときには、最初にその機能を書き上げるのにかかった時間だけを考慮してはいけません。コードの強化、修正、改善にかかった時間も加えてください。品質の高いコードとテストを書くのには時間がかかります。これは短期的には損失に見えますが、長期的には利益をもたらします。

とにかくスピードがあればよいのか、持続可能な進歩を得たいのか、自分自身に問いかけましょう。