仕様化はインサイドアウトで進めよ
よくソフトウエア開発で仕様の整合性が保たれていないなどの嘆き声を聞くことがある。
この問題は様々な要因によると思うが、仕様化の進め方に問題があることは十二分に想像できる。
ではどのような点が問題なのであろうか？
ソフトウエア開発では、要件獲得を行いそれをもとに分析・設計・実装していく。この分析・設計時に仕様化を行う。
この際にインサイドアウトすなわち内部的な構造から外部仕様を確認してく作業が不十分だと仕様の整合性は危うくなる。*1
要件獲得から外部仕様（機能仕様）に落としただけでは、それぞれの機能で利用する内部構造（データ）には共通意識はないので整合性を担保することは難しい。特に大規模でチームが分かれている場合は全く確認されていないと思ったほうが良い。
内部構造（データ）の整合性を考えるには、内部構造（データ）に対する共通認識をプロジェクト内で一致させる作業が必要になる。そのうえで、再度外部仕様（機能仕様）を確認・整理する作業を行う必要があるということだ。
このインサイドアウト作業はタイミングも重要だ。仕様の不整合がある仕様は手戻りが発生するためだ。
できれば要件獲得から外部仕様を定義するタイミングと同時に整合性の確認ができることが望ましい。もちろん詳細なレベルは無理なので一定の粒度のモデルで確認する。
ちなみに、DOAではこの確認をデータベース定義を利用して早期に行う仕組みになっている。OOADでも概念モデルを利用して行うことができるが、ユースケースだけを利用して進めているとインサイドアウトの作業のタイミングが遅くなったり省略してしまう可能性があるので注意する。
仕様化の細かな技法はあるが、要は、仕様化をインサイドアウトなしに進めると危険ということだ。
