見積もりの肝― 試験工程の難易度
「高品質」を担保するために必要な「確認・検証作業」の難易度が年々上がってきていることを実感している。
外部システム（外なるブラックボックス）との連動やパッケージソフト、ミドルソフト等多種多様な製品（内なるブラックボックス）との組み合わせにより機能を提供するケースが多くなったこと、がひとつの要因として挙げられる。
この場合、「自己製造責任外のソフトウェアも含んだシステム全体の確認・検証作業」を行う必要があり、従って、作業に必要な「資源」つまり、ハード環境、ネットワーク環境、試験実施のために必要なデータ準備作業（作成に必要な稼動）は膨大かつ複雑となり、試験計画・実施・試験結果確認に必要な「制約条件」や「有スキル者」も多くならざるを得ない。
もちろん、設計工程における「インタフェース条件」の相互理解や机上検証、プロトタイプ検証による事前の不具合摘出も当然行うのであるが、実際は、運用に近い環境において、運用実データを用いた（バリエーション）試験を実施することにより初めて見つかる（気づく）不具合も少なくない。
不具合が発生した場合の対応も、労力を要する。外部システム開発ベンダやパッケージ提供ベンダ等との間で不具合の切り分けを行い、根本原因を明確にした上で、試験のフェーズやサービス開始時期等を考慮し、ユーザに迷惑を極力かけない対処を講じる必要がある。
特に、パッケージの活用においては、かなり活用事例の多いパッケージにおいても、その組み合わせや使い方により「想定外の」不具合に遭遇するケースがままある。早期問題解決ため、採用するパッケージ等対応の技術者確保はもちろんであるが、パッケージ提供ベンダ等とある程度わたりあえる技術力をプロジェクトに内部蓄積することも大切である。
我々としては、これら「ブラックボックス」をやみくもに過信するのではなく、システム全体の品質を自らの手できちんと検証し、自らの目で確かめる（期間と資源を準備する）こと、使い方によって不具合はある程度発生することを念頭に「ブラックボックス」とうまくつきあっていく（余裕をもつ）こと、が肝要である。
