庵主の日記２
３月１日、東京航空交通管制部でフライトプランを処理するコンピュータシステムがダウンし、関東の空港を中心に終日混乱した。原因は、ソフトウェアの修正ミスとして公表されているが、果してそれが原因だろうか。結果としてプログラムにミスが入ったわけだが、その原因をどの「プロセス」に見いだすか。それによって、この組織の能力が見えてくる。
稼働しているソフトウェアシステムに修正を加えたり、新しい機能を追加するのを、私は「派生開発」と呼んで、「新規開発」のプロセスとは全く別のプロセスを使うことを勧めている。「要求」の性質が違うためにプロセスを変えているのである。プロセスが違うということは、そこでの要求仕様書（私はこれを変更要求仕様書と呼ぶ）から始まって、ほとんど全てのプロセスが新規開発のプロセスと異なってくる。当然、プロセスから生み出される中間成果物の内容や構成も変わってくる。
しかしながら、私がコンサルティングしている中で見えている限りでは、「派生」と「新規」の区別ができていたところは１つもない（もっとも、それができていれば私に依頼は来ないだろう）。そのために、プロセスのミスマッチによる混乱を招いて、多くの時間を失い、それがさらに必要なプロセスを省くという負の連鎖に入ることになる。そのうえ、プロセスが適切に設計されていないため、中間成果物が有効に利用されておらず、そこからまたバグが入り込むし、後の方のプロセスが効果的に実行できないことが起きる。こうしてエラーが連鎖してしまう。
新規開発や派生開発に於ける機能追加部分の場合は、設計する過程で下位構造の部分の仕様を（その時点で）決めながら作業を進めていく。つまり、全体の仕様のバランスを考えながら設計を進めていく。それに対して派生開発の場合は、一般に、既に実装され、機能しているプログラムに与えた「仕様」を変える必要が生じる。ここで修正すべき箇所を発見できずに修正モレが起きる。
最初の「変更要求」は、システムレベルの仕様に対する変更であるが、その変更を満たすためには、関連する仕様の変更の必要性を調べ、更には、実装レベルでの仕様の中に変更の必要のある仕様（箇所）を見つけ、それをどのように修正するかというところで更に効果的な検討（レビュー）が必要になる。これらの一連のプロセスは、新規開発のプロセスとは全く違うのである。
コンサルティングの中で、「派生開発プロセス」を取り入れることで、それまで起きていた混乱はほとんど解消する。これはそこで用いたプロセスが要求（変更要求）と一致したことを意味する。もちろん、取り入れる程度によって結果も違ってくるが、私がイメージしている程度に取り入れられたときには、目覚ましい結果となる。もちろん、「プロセス」で問題の全てが解決できるわけではない。「設計技術」に負うところは大きい。だが、そこで用いたプロセスが不適切だと、折角の「設計技術」が活かされないのである。
今回の場合、どのようなプロセスが採用されたか知らないが、一般に「派生開発」の難しさはここにあって、トラブルが発生しているところでは、派生開発プロセスが新規開発“もどき”のプロセスで運用されていることが多い。
庵主の日記の目次に戻る