約3年前に「 ソフトウェア開発のスケーラビリティ 」の記事を書きました。一番書きたかったことは、ある一定の開発期間を経たソフトウェアには次の2種類のタスクが残るという話です。

• 難しくて重要なタスク
• 簡単でどうでもいいタスク

ソフトウェア開発に新しい人が来るたびに、これがジレンマになります。新しい人は、比較的簡単なバグ修正などの作業から入って、作業しながら全体像を把握するのが常套手段です。スキルがある人やベテランでも事情は同じです。自分の経験を振り返っても、新しいソフトウェアを目の前にした時は、手を動かしながら全体像を探っていくのが一番効率的だったと思います。

一方、どうでもいいバグは本当にどうでもいいことも多々あります。開発期間の長いプロジェクトの場合、数年放置されているようなバグも普通に存在します。このようなバグはそもそも修正が必要なのかどうかすら怪しいものがあります。修正による挙動の変化やバグの埋め込みの可能性を考慮すると、合理的に考えて、修正しない判断が正しいことも多々あるからです。

とは言え、鶏と卵の問題で、簡単なタスクで手を動かさないと新しい人が開発に慣れていきません。なので、どうでもいいタスクの中から見繕ってタスクをアサインしてきます。

開発期間が長くても、簡単で重要なバグがたくさん現れる例外的なプロジェクトがあります。それは、修正によって次々とエンバグしてしまう場合です。従来動作していた機能が壊れるので、このようなバグの修正は必須です。動いていたコードと動かなくなったコードの両方を見ることができるので、この手のバグの修正は、比較的容易です。このようなバグ(リグレッションバグ)の発生は避けられませんが、大量に次々と現れるソフトウェア開発は、大局的には終わっています。

皮肉なことに、プロジェクト管理の観点では問題がありますが、人材育成の点では結構良い環境だという点です。たくさんのバグを次々に修正していくと達成感も得られ、自信もつきます。壊れやすいコードや、プログラマがどうミスをおかすのかを多く目にできるのも長い目で見れば良い経験です。