まずは、基本的なプロジェクトのコスト構造を理解しよう❸ | テスト

6回シリーズの第3回目です。以前の回でお話しましたが、コスト見積をするためには、まず工数を算出することが必要です。そして、その工数を出すためには、工数を決めるための見積前提を理解して、設定することが重要です。

今回はテストです。テストのなかでも、色々な問題が多発するシステムテストについて、取り上げます。


そもそもシステムテストとは?

システムテストは、プロジェクトによっては、総合テストとか、統合テストとか呼ばれていますが、要は「ユーザに見て貰う前のシステム総仕上げのためのテスト」です。

よく出てくるVモデルで言うと、プログラムに対して行う結合テストが終わった後、ユーザが決めた業務要件が網羅的に満たされているか確認するためのテストになります。

そのため、テスト内容も、IT的なものというよりは、ビジネスシナリオがメインのテストとなります。

最後の総仕上げテストですから、色々な要素が入ったテストになりますが、工数見積としては、ITパートナが持っている見積ツールで計算することが多いと思います。


大きな要素は、やはりテストシナリオ数

テストの工数ボリュームを決める要素として、大きいのはテストシナリオ数です。実際にシステムテストが始まった後の進捗も、シナリオが何本完了したかで評価されます。

システムテストは、ビジネスシナリオのテストです。そのため、業務フローや業務機能の種類や数が、シナリオ数を決める大きな要素になります。そこに、データパターン、外部システムとのインタフェース数が加わります。

基本的には、ITパートナが持つ見積ツールで自動計算されることが多いですが、この辺りの見積要素を知っていることは、見積の妥当性を確認するうえで重要です。

テスト工数がすごく大きい。でも、接続するインターフェスの数がすごく多いから、確かに大きくても不思議は無いかも。

さて、ここまでは、システムテストの工数見積の基本です。この後、少し応用編です。


同時並行で別の大型プロジェクトが動いている場合のテスト

ユーザ企業によっては、全社DXと銘打って、ERPだけでなく、色々な大型プロジェクトを並行して走らせることがあります。

システムテストも、ERP単体のときよりも、絶対に大きなものになるはずです。そうした場合には、どのようにテストの工数見積をすれば良いでしょうか。

まず、工数見積の前に、そういった複数プロジェクトが並走する場合のテストの仕方について、お話します。

テストの進め方

こういった場合に、いきなり全部をつなげてテストをするのは危険です。何か問題が出たときに、それがどのシステム起因の問題なのかを見極めるのが大変難しくなるからです。

例えば、以下は一例(他にも色々な可能性があります)です。

まずは、中核となるERPをしっかりテストして、品質を上げておきます。

次に、他のシステムとひとつずつつなげてテストを行います。そうすることで、問題が発生する箇所を限定して、対応し訳します。

そして、最後にようやく全体のテストをします。

そうすることで、テスト効率を維持しながら、段取りよくテストを進めていくことができます。

工数見積の方法

こういったテストの工数見積にあたっては、係数を使います。

最初のERP単独のテストは、普通にERPテストの100%実施です。

次に、他のシステムとつないでいくテストでは、ERP単独テストで品質が上がっていることと、連携テストで利用するERP機能が限定されていることを踏まえて、20%くらいのボリュームだと置きます。最後の全体テストは、また利用するERP機能が増えるので40%。

そうして、その一連の工数を足すと、ERPテストの200%の工数ボリュームになるという計算です。

実際の機能数やIF内容を確認して、精度を高めていく場合もありますが、どこまで行っても仮説は仮説です。最後は、何らかの係数をおいて計算することが多いです。

ここまで、システムテストの工数見積について、お話しました。

しかし、実際のプロジェクトにおいては、システムテスト工数の見積間違いといった話はあまり聞きません。

それよりも、品質問題による工数増の方が、より頻繁に、より深刻に目にするようにに思います。


見積間違いよりも、品質問題の方が影響が大きい

以前の回でもお話しましたが、大規模プロジェクトでは、テストフェーズの延伸という話がよく聞かれます。

原因は、システムテストの工数見積を間違ったからではありません。たいていは、設計開発フェーズで埋め込まれた品質問題や、要件定義フェーズの踏み込み不足による仕様変更などが原因です。

この問題にも、色々と深掘りしなければいけない点が多々ありますが、ここでは割愛したいと思います。

ただ、覚えて頂きたいことは、テストの工数は削らない方が良いということです。

システムテストの工数は、プロジェクトのなかでもかなり大きなボリュームを占めます。そのため、工数見積が出て、見積精査をしているときに、つい削りたい欲求にかられます。

でも、先ほどお話したように、テストは膨らみがちです。あまり強引には削らないことをお勧めします。


テスト工数も、ITパートナが持つ工数見積ツールで計算することが多いと思います。

その場合でも、見積ファクターを理解しておくことで、出てきた見積の妥当性をチェックすることができます。また、大きなテストなどでは、ツールでは自動計算できないこともありますので、係数をうまく使うことも大事です。

ただし、繰り返しですが、品質問題で、テスト工数は膨らみがちです。テスト工数は多めに確保しておくことをお勧めします。

最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。

ITプロジェクト研究会

Related Insights

まずは、基本的なプロジェクトのコスト構造を理解しよう

カラムリンク
❶要件定義
カラムリンク
❷設計開発
カラムリンク
❸テスト
カラムリンク
❸データ移行

プロジェクト見積の進め方を理解しよう

カラムリンク
❶基本の手順
カラムリンク
❷精査の視点