数学の入試問題に登場する大問は、大抵の場合ストーリーになっている。大問が大きく、３つの小問から成り立つとすれば、（３）を解くためには（２）を解く必要があり、（２）を解くためには（１）を解く必要がある。そして、（１）を解くために必要なのは問題文で与えられる条件、という具合になっているのだ。
このように順序立てて問題を出される方が実は問題を解くのは簡単である。いきなり（３）を問われてしまうと、解法の自由度が高くなってしまい、逆に難しいのである。ただ、順序立てて問題が問われる場合には注意点が必要である。例えば、（１）で凡ミスをしてしまえば、（３）で得られる最終的な解答が間違ってしまうことになるからだ。
システムの設計を進めていくのは、このような数学の問題を解くことによく似ている。あくまでシステムを作ることを目的とするのであれば、システムを動かすためのソースコードを作成する必要がある。そして、ソースコードを記述するためには内部設計をする必要があり、内部設計をするためには外部設計を固める必要がある。さらに、外部設計を決めるためには、システム要件を明確に定義しなければならない。
ただし、実際の現場では、そもそもエラーを作りこまないなんてことの方が少ない。要件定義の段階で検討が漏れる場合もあるし、外部設計で検討が漏れる場合もある。そうやって事前段階でエラーを作りこんでしまえば、結局間違ったシステムが生み出されることになるのである。
もちろん、間違ったシステムを正しく動作させるために、設計が終わった後には試験工程が存在する。とは言え、どれだけの間違いがあるのかなんてことを初めに見積もるのは困難である。結局想定していたスケジュール内にバグを排除できない場合だってある。
それでも、人を増やしたり、労働時間を増やしたりすることで最低限の対処をすることでシステムは正しい状態でリリースされる。最低限の対処とは、提供するシステムのソースコードは正しい（というよりは最も正解に近い）状態にすることである。ただし、時間的な制約のせいで、設計書自体はソースコードに合わせて修正が追い付いていないことがほとんどである。
これを数学の問題で喩えるのであれば、大問の最後の小問のみ正解している状態と言える。ただし、どうだろう。大問の最後の小問だけ正解していれば、大問として概ね正解だと言えるのだろうか。
否。小問（１）、（２）だって正しくなければならない。それらが揃って初めて正しいシステムを提供していると言えるのである。ウォーターフォールモデル開発で、お客さんに設計書などを提供するのであれば、尚更である。
そして、何より問題なのは、その開発プロジェクトが完了した後に、別の追加案件が入った場合、設計のインプットドキュメントとして、間違っている設計書を活用してしまうことである。こうして、また同じようにバグを作りこむことになる。
しかし、私たちは過去の設計書が真であるという前提で設計を進める。それはなぜか。誰もソースコードを理解していないし、理解する気もないからである。私たちが直接ソースコードを作るわけではないからだ。
私自身、過去の設計書を元に設計を進めてきたが、結局、それが本当に今の仕様なのかどうかなんて一々照合している時間はないため、それを信じざるを得ない部分があった。結果として、既にいくつかバグが見つかっている。
方法としては、大きく二つしかないように思う。一つは、完全にソースコードと設計書、その他の関連ドキュメントの整合性を合わせること。だが、これははっきり言ってあまりに非現実的過ぎる。数万枚あるドキュメントを見なおして全て正しい状態にするための稼働なんてものは与えられない。
ならば、ソースコードを読める人間を増やす、ということだ。私の担当ではこれが属人化しているため、解析するなら有識者にお願いすれば良い、ということになっている。ただし、管理する我々としては、有識者の調査結果が本当に正しいのかどうかを判断できる必要はあるはずだ。その人が正しいと言っているからOKなんて言ってたら間違っていた時何の対策も打てない。
あるいは、今のソースコードから設計書を逆に作る、リバース・エンジニアリング的な取り組みができるならそれもアリなのかもしれない。いずれにせよ、設計書が全て正しいなんていう幻想は捨てたほうが良い。
