トンカチにとってすべての問題は釘に見える

早い段階で品質をチェックしたい。
だからといって、設計書のページ数に対するレビュー後の不具合指摘数を基準とするのはどうだろう？

これは、イテレーション開発の品質を考えるときに出たある品質保証の考え方の話だ。

小さな開発の集合となるイテレーション型開発では、一つのイテレーションであるレベルの品質を確保する。
うまく分割されていれば、それはかなりの精度のなるが、うまく分割されていない可能性を残しているのであれば（決して、その努力を怠ったわけではなく、すこし前に進んでみないとわからないから、進んでから調整をすると言う意味だけど。）、ある程度ということだろう。
でも、その結果、当初の不確実性を排除できる。
アジャイル的な進め方というのは、開発の不確実性に対して、すこしづつ事実を積み上げる方式だ。
しかし、現在主流のやり方というのは、開発に不確実性が含まれていない、もしくは、それをすべて排除できると考えている、もしくは、開発の初期に排除可能である（もちろん、努力によってである）と考えている。
逆にだからこそ、新しいやり方（技術って意味）を好まない。不確実性が排除されるなら、それでまず安心。決して、今回の開発においてそれが十分な解決策ではないとしてもだ。
新しいやり方がおそらく適合するだろうということも、不確実な話だ。
しかし、明らかに、・・・たとえば、それまでのやり方（SSHベースでの開発とか）よりも、ここは気楽にもしくは軽くいきたいと考える、いや、柔軟なやり方で取り組んだほうがいいだろうと、考えるケースがある。
ただし、問題領域が複雑であり、新しい技術の取り組みを含めた開発は不確実な要素を増やすだけだとすれば、止めたほうがいいのかもしれないが、問題領域がそれほど複雑でなければ、新しい技術でのチャレンジを試みたほうがいいだろう。それによって、次にもし複雑問題領域や違ったシーンにおいて、新技術を使うことはその時点で不確実性が下がっているからである。
こうして考えると、今の確かと思われる技術を使うなかでシステム開発をすることと、新技術（少なくとも自分たちにとってでいいけど）を使って開発することは同じにしてはいけない。
同じ土俵で考える以上、それぞれの考え方は相容れない。
かたや、実績を主張するし、かたや、技術の仕組みを強調するし、相容れない。

では、我々はどうすべきだろうか。
今の開発方法でまったく不確実なものがない、と考えたとして、それ以外に問題になっていることはないだろうか。
それを解決しなれば、コスト要求や期間要求に応えられないとすれば、改善に向けたやり方を検討すべきだろう。
安全なやり方を踏襲することで、ビジネスが継続できるなら問題ない。
しかし、ビジネスがシュリンクするとか、衰退していくとすれば、
もう待てないだろう。
最終的には、現状のやり方の改善が効果を出すか、新しいやり方に移行することが効果を出すか、それはわからない。だからこそ、比較はするべきだろうし、そのときには、まずお互いの本質を受け止めることから始めるべきだろう。

その結果、新技術に足りないもの、今のやり方の改善の方向性が正しいのかも評価できる。
（と思っている。まあ、そう思って比較してみないといけないだろうということ）

やってはいけないのは、新しいやり方を、今の評価軸で評価しようとすることだ。
本質的に間違っている点から開始するのはもっとも危ないアプローチ。

で、設計書レビューの不具合件数や率って、その時点で何かを生むのだろうか。
少なくとも、全部の設計書をやっていく中では、最低３ヶ月ぐらい期間があるだろう。
それの最後では、危ないと思うから、途中のレビュー率を測る。
しかし、設計書を全部書いていないのだから、その率は測れないだろうよ。
で、FPをもとにした規模から、算出するのだろうか？

え、設計書のページ数とFPは相関関係にあるのか？

これまた大発見だ。

（ちなみに、タイトルは、http://p.tl/cmzuについて書いたブログhttp://p.tl/_rp_より拝借。