仕様変更の影響範囲はどこまで及ぶのか？

ソフトウェア開発

ソフトウェアの障害管理表を見ていたら、こんな問題を見つけた。概略を簡単に示すとこのようになる。

  • 問題：ある特定の条件下である操作を行うと、アプリケーションがエラーを起こす。
  • 原因：仕様変更の連絡が不充分で、担当者への連絡が出来ていなかった。
  • 対策：仕様変更時には関係者への連絡を徹底する。

よく有りがちなミスだし、この類の対策もよく有るものだと思う。チケットの記載として、これはこれで理屈の通ったものだろう。（これ以上何を書いたら良いのか？）

しかし、実際問題として、その実践は難しいと思う。特に、大きなシステムにおいて、影響範囲を見極めることは容易ではないはずだ。アプリケーションの下層レイヤーや共通部分、ユーティリティ、コアの処理を担当しているのなら影響範囲に巻き込まれる可能性が高いわけし、そもそも、その時のシステムの状態によって「影響を受ける」「影響を受けない」が動的に決まるケースもあり得るはずだ。

そんな状況の中で「この仕様変更は、あなたの担当範囲に影響しますか？」というメール連絡が一日に何件も届く状態になったら、一つ一つ確認するのは大変だし、当然確認漏れやミスも発生してしまうことだろう。だから「関係者への連絡」を徹底するのは必要とは言え、現実問題としては、もう少し合理的で確実な方法を探るべきだと思う。

少しでも役立つ情報として、こんなものが利用できるかも知れない。

  1. 行にクラス名、列に機能を列挙した表を用意し、クラスと機能の関係を可視化しておけば「関係しない」ことが明確に分かる。この方法の問題点は、クラス名の列挙は機械的にツールで引き出せるのに対し、機能の列挙は曖昧で不確実なものになってしまう点だ。仮に人手で機能を列挙しても、その情報を随時更新していくのは非現実的な話だと思う。
  2. ツールを使ってソースコードをリバース解析し、そのクラス構造を図に表し、該当機能の処理を手作業で辿っていく。この方法の問題点は、クラス図という静的な情報を使って、その動作という動的な側面を考えなければならない点だ。静的構造と合わせて、（部分的な情報で良いから）動的な構成を可視化出来れば大変便利なのだが。
  3. ツールを使ってソースコードをリバース解析し、コールグラフを作って各モジュールの呼び出し関係を明らかにする。この方法の問題点は、クラス（や関数）という単位でしか情報を表現できないので、例えば、その時のインスタンスの状態はどうなっていたか？という情報が欠落してしまい、影響する・影響しないの見極めが簡単ではない点だ。

いろいろ考えてみたけれど、どの方法も不充分で決定打は無かった。他の開発者（組織）は、このような問題に一体どのようにして対処しているのだろうか。もしかして、もっと賢い方法が有るのだろうか？