MDD

マニュアル駆動開発。
もちろん造語である。そしてまだどこにも存在していないものと思われる。
以前から結合テストとシステムテストの中間的なドキュメント（もちろんテスト仕様になるわけだ）を先に作成して、その後に実装に入るということを何度か試している。
これは、案外 良好なスタイルだと思っていて、かなりの精度で見えない部分をあぶりだすことにも効果があるし、設計のブレを抑制することに一定の効果を上げることを確認している。

しかしながら、万全というわけにもいかないということも体験的にわかっている。
システムやソフトウェアの特性に左右される部分が大きいからだ。特性とは性格を表す内部特性ではなくビジネスゴールにおける特性だ。
リリースされる成果物はきまぐれで、時として根幹を揺るがすような強力な反乱部隊を送り込んでくることがある。つまり、外観的な視覚特性が明らかになったところで、夢を語りだす悪魔が身を潜めていることに注意しなければならないということだ。
「この機能は、ここをチェックしてこっちのボタンをクリックしたときのほうがいいなぁ。」
現代の実装はできるだけスコープを狭く、シナリオでクローズすることが望ましいとされる。そのような工夫が、この時点で仇となり一気に反乱を起こすということだ。
この時点で実装を見直さなければならないことが高確率で予想できるし、テストで確認した点がすべて無効となるわけだ。
このような問題に関する有効な回答を探していたところで、ふと思いついたのが冒頭の言葉である。

マニュアル、つまり「取扱説明書」をまず先に作る。

ふざけているだろうか？
もちろん効果も確認していないし、精度も測定していない。第一試してみたこともない。
しかし、目の前に取扱説明書が提示されたなら、具体的なイメージを余すところなく掴めるはずだ。これはエンドユーザのみならず我々作る側の人間も同じだと思う。
作るものの明確なゴールが見えたところで、もっと突っ込んだ話ができるのも大きな利点だと思う。

それは、セキュリティ、ポテンシャル、スケール、耐久性、拡張性　といった非機能要件である。

この部分を具体的に詰めるのはとても難しい。
プロジェクトによってはざっくり切り捨てなんてことも珍しくないだろう。
そのような中で最も効果が上がるのを期待しているのは

見積もりである。