マイクロソフトの伝説のプログラマー、デビッド・カトラー率いるWindowsNT開発物語「闘うプログラマー」の中に興味深い記述（[上]p.209,213）があります。
プロジェクトがはじまってから二年半になるが、コーディングにはOS/2を使っていた。そろそろ、NTを使って書くべきだ。複雑なプログラムの場合、早く各部を組み合わせるほど、バグを早く発見できる。複雑なソフトウェアを開発するときに、自分でつくったドッグフード（引用者注：プログラムのこと）を食べるのはめずらしいことではない。そうしなければ、オペレーティング・システムの各部を組み合わせたときに発生するバグは、発見できない。（中略）
ドッグフードへの切り替えは、三段階で実施された。第一段階ではグラフィック機能のないNTを使い、つぎにグラフィック機能をつけ、最後にネットワーク機能をくわえる。
この話は、新しいOSを、今開発しているOS自身を使用して開発することが、バグを消す一番の方法であることを示していますが、この方法のメリットはバグの発見だけにとどまりません。自分で実際に使ってみることで、使い勝手の悪さや、仕様自体の不備を、自分の目で確認することができます。
更に言えば、何もOSの開発に限ったことではありません。アプリケーション自体の開発にも同様の考え方が適用できます。アプリケーションの場合、開発そのものにアプリケーションを使用するわけではありませんが、開発する機能の検証に、開発しているアプリケーション自体を使用すると言うことになります。
アプリケーションの不連続性
こう言った開発の考え方の意味を、もう少し踏み込んで理解するために、アプリケーションの不連続性と言う概念を説明します。
全く新規に一からアプリケーションを開発する場合ではなく、既に動作しているアプリケーションに、新たに機能を追加する場合を考えます。通常、追加する機能にもよりますが、アプリケーションの一部の機能の追加であっても、その影響範囲を調べ、関係する箇所のコードの変更作業が発生します。この作業が、関連する全ての箇所で完了して初めて、アプリケーションを使用した確認作業が可能になります。
つまり、アプリケーションと言うものは、それに機能を追加したり変更したりする場合に、動作確認できる一定の範囲と言うものがあり、その範囲の中を細分化して動作させることはできません。別の表現をすると、アプリケーションの中身を、ある「状態」からある「状態」へ遷移させた場合、それらの中間の「状態」は存在しないと言う意味で、両者の状態は不連続であったと言うことになります。これをアプリケーションの不連続性と呼んでいます。
先のNTの例で言えば、『ドッグフードへの切り替え』における三段階が、それぞれ不連続であるのは一目瞭然です。
さて、次に、このある「状態」のアプリケーションと言うものが、アプリケーション自体の進化に決定的な影響を与えると言う話をします。以下次回。 KAI