開発プロセスで定義されてないから検証してはいけない？

昔の同僚やその友人などの間で意見が割れて、盛り上がった話。あまり使ったことがないサブシステム（ハードウェア、ミドルウェア、DB）を使った開発の場合、限界性能での挙動、エラー処理、ダウンの仕方、復帰方法等がわからなければ、うまく設計ができない場合がある。そういう場合に、早い段階で事前入手の算段を整え、早い段階で検証できるようにするのが普通だと思っていた。ひょっとすると、自分たちが意図する用途では使いものにならないかもしれないのでその確認もできるし、それを踏まえてテストを設計すればよりよいものになるだろう。

検証の際に、必要であれば簡単なプログラムを作ることもある。スタブやドライバと呼ぶようなものもあれば、負荷をかけるためのツールのときもある。その場にいた人たちの間では、このような作業を含めて設計と呼ぶと思っている人が半分ちょっとくらい。私はこっち派だった。しかも、私は誰でもやっていると思っていた。それは標準的なプロセス定義には含まれていないから、そういうことはコーディングのフェーズまではやらない、あるいはコーディングをやってくれるパートナに任せる、という人たちが残り半分。後者には、設計時の検証を標準開発プロセスへの非遵守になるので、意図的にやらないという人も含まれていた。

食事中の雑談という感じだったので、その場にいた人の間で「検証」のイメージが揃っていたか、かかるコストについて合意がとれていたかは不明だが、ショッキングな結果だった。同様のご経験がある方ならば、盛り上がりそうな話だなぁと思っていただけるのではないかと思う。

さらに、どちらの立場にいても他方がとても異常にみえてしまうようなのでエントリにした。議論としては「責任分界点を超えた話だから。。」というものもあったが、検証することとそれを明示的に伝えたり責任を持つことは別のこと、ということになった。また、標準プロセス定義に「検証」を入れるという話も出た。が、これはプロセス定義のいたるところに検証があらわれてしまうのでは？ということになった。ご自身ならどうされるだろうか？