>>296
>・ユニットテストは軽視してはならない。むしろ重視すべき。
->軽視はしていない。重視もしていない。
　おれは、テスターじゃなくて、プログラマー上がりなので、
ユニットテストの大切さを知っている。ただ、組織としてユニットテストを
　成功させる場合は、以下の前提条件を満たせないとだめだ。
1. バグが減ったことを評価して、ボーナス査定をUPさせる。
　2. 機能実装よりバグが少ないことを重視する。
重要なのは、2 だ。ユニットテストを重視した結果開発のスピードが
　落ちたのだ。つまり、機能的要件（フレームワーク、下位コンポーネント
　を除く）を実装するチームに関しては、ユニットテストがボトルネックになる。
　よーは、すべてがトレードオフなのだ。ユニットテストを重視しすぎると
　逆に効率が落ちる開発フェーズがあることを俺は、経験で学んだ。
　
>・ユニットテストはプログラマが行うべき
-> ユニットテスト＝ホワイトボックステストなら同意。

>・ユニットテストを重視することは、顧客のメリットになる
　-> 大規模開発では、顧客には理解されない。
　 業務系ではないうちでは、専門的すぎて説明するのが難しい。

>・（おまけ）外部設計と内部設計という考え方はある
-> うちの会社にも昔はあったよ。外部設計、内部設計という言葉が
間違っているのに気がついた。
　　 確かに、システムというものを対象にした時にそれの外部について
記述したドキュメントと内部について記述したドキュメントはある。
ただ、外部か内部かという言葉は、対象物を前提としている。
システム、サブシステム、コンポーネント、ライブラリ・・・・などだ。
そして、これらは、整然と関連付けられる。内部設計とか外部設計という
言葉をこれに当てはめると間違いである事が理解できる。
外部は仕様書で、内部は設計書なんだ。これでもわからないなら。
　　 仕様書と設計書の違いを説明してくれないか