一見簡単にみえる変更規模が小さいバージョンアップの難しさをどう説明しますか？
既存ソフトウェアの更改によるトラブルがニュース等で報じられるのを目にします。ソフトウェア開発に携わるとその難しさが理解できるのですが、既存ソフトウェアの更改は予期せぬ誤りを混入してしまうことが少なくありません。大きな変更をすれば誤りが混入する可能性が高まるということは直感的なイメージできやすいのですが、変更規模が小さいからといって誤りが混入する可能性が低くなるかというと必ずしもそういうわけではありません。
文献Basili V., B. Perricone “Software Errors and Complexity: An Empirical Investigation”, Communications of the ACM, vol. 27, no. 1, p. 42-52(1984)では、ソフトウェアの更新を観察し、モジュールごとに変更規模と単位規模あたりの欠陥数の関係を調べています。モジュールの変更規模が小さいほうが単位規模あたりの欠陥数が多くなることを報告しています。文献はここ（ACMの電子図書館）に掲載されています。著者のサイトでも公開されています。
小規模変更の難しさは変更に非常に慎重にならないといけない場合とそうでない場合が混在していて、既存バージョンと変更のそれぞれを理解しておかなければ、すぐには見分けがつかない点です。小規模な変更で旧バージョン（既存部分）との整合性をあまり考えなくてよいすぐに修正すれば済む場合もあれば、変更により旧バージョンの動作が期待どおりでなくなることを見逃してしまうことがあるからです。
これは変更に必要なコストについても同様で、旧バージョンの動作を確認するためのテストの規模は、変更規模よりは旧バージョンの規模に左右されやすいです。旧バージョンの理解や旧バージョンが期待通り動作するかを確認するテストを実施するためのコストを見積ると「ちょっとした変更なのにコストがかかるなぁ」という違和感を与えがちであることもこの問題の難しさの一つでしょう。
旧バージョンのテストの自動化やXDDPやSPLE等の開発フレームワークといった対策はいくつかあります。手法やフレームワークと同様に上述のような小規模変更の難しさを関係者が理解することも大切です。プログラミングの経験や小規模変更の2パターンを実際に経験していれば想像するのはそれほど難しくありませんが、そうでない方には、なかなか伝わらないものです。
そのような難しさを伝える例として、公共交通機関の時刻表の変更があると思います。私は公共交通機関の時刻表の専門家ではないので細かい部分で誤りがあるかもしれませんが、メタファーとしては比較的適切ではないかと思います。たとえば、終電を20分遅らせて電車をもう1本増やしたいという場合に、単純に時刻表を変更して告知するだけで十分かというとそういうことはほとんどないでしょう。車両のスケジューリング、運転士の人数、駅員の退勤時間、各種メンテナンスのスケジュールを加味してからでないと判断ができないでしょう。それらの調整が意外に簡単にできる場合もあれば、様々なものを調整しないとできない場合もあるように思います。旧バージョンの更改に通じるところがあるのではないかと思っています。
この話をする機会を2013/6/28に静岡大学浜松キャンパスで開催されるサイエンスカフェin浜松でもらいました。プログラミングや対象ソフトウェアの知識が少ない方に対しても小規模変更の難しさを理解していただけるような内容で本問題を紹介したいと思います。本イベントは専門家ではない方向けのものですので、専門家の方には周りの方への説明の方法として参考になれば幸いです。詳細はこちらから。