Part�T　【テストは本当に必要か？】

　かつて、日本のシステム開発における技術者の階級は、頂点のシステム･エンジニア（SE）に始まり、テスト要員や運用・サポート要員は最下層に位置していました。それでも日本の企業システムや製品の品質が高く維持できたのは、頂点に立つSEが極めて高度な技術や管理能力を持ち、システム全体の品質に常に目を配っていたからです。そして、当時のテストは、そのSEが必要とする不具合や不安要素などの情報収集を目的として行われていました。

　しかし、今日のシステム開発では、規模の拡大や基盤の複雑化、期間短縮、コスト削減といった制約により、ひとりのSEがシステム全体に気を配ることが困難となりました。この結果、テスト自体の必要性や目的も不明確となり、いつの間にかテストが本当に必要なのか疑問視されているように思います。この結果が、プログラミング・バグがなければ品質が良いという誤った風潮や、テストをすれば品質が良くなるという誤解（テストは品質を測定するのみ）を生んでいるのです。

　もともと、システム開発は複数の利用者の要求を一人もしくは少数の技術者が抽象化し、これを具象化／部品化して複数の作業者に構築させるという複雑な作業です。最初の抽象化、再具象化、そして部品化の時点という少なくとも３つのポイントで誤解が発生する可能性があります。もちろん、部品の構築にあたるプログラム実装でバグが混入する可能性もありますので、品質を正確に把握するためには様々な観点と尺度でシステムを精査ことが必要です。

今日のように、テスト目的や目標をSEが強力にリードできない体制下では、プロジェクト全体での品質管理方針や手段の具体化が極めて重要になります。いくら作業者が完璧なプログラムを作っても、上流段階で発生する誤解やミスを完全に防止できない限り、最終的にはテストという方法によって品質を可視化するしかありません。しっかりとした「テスト計画」、すなわち品質向上のシナリオを作り、これに沿って開発／テストを含めたプロジェクト全体が力をあわせて行くこと、これがシステム開発本来の姿であるとすれば、今日のシステム開発においても「テストは必要である」と結論できるのではないでしょうか。