「【IT基礎講座】システム開発におけるテストの重要性」について書いていきたいと思います。
・業務の要件が正しくシステム化されているかテストしなければならないけど、システムのテストってどんなことするの？
ということをもう少し詳しく知りたい人は必見です！
コンサルタントを目指している人やコンサルタントにはあまりITとかのスキルはいらないと思われている方も少なくないです。
しかし、現在はDX（Digital Transformation）の時代です。
ビッグデータやIoT、AIやクラウド、5G等新しいデジタル技術を経営に活用することが当たり前の時代です。
また、ビジネスコンサルタントでも業務プロセス改革で効果を創出するための手段としてRPA（Robotic Process Automation）の導入を支援したり、全社の基幹システムの構築でSAPのERP（Enterprise Resource Planning）のパッケージの導入支援を行ったりします。
現在では、ビジネスコンサルタントにとってITのスキルは必須のスキルと言っても良いと思います。
特に、業務改革や新しい事業の構想を策定しただけでは、コンサルタントの仕事は終わりません。
その後の工程として、業務プロセスの設計をしたり、システムの導入を支援したりと様々な仕事があります。
クライアントと一緒に検討した業務の要件が開発されたシステムに実装されているかを確認するユーザー受入テストの際のクライアントへのサポートは重要です。
そのため、システムのテストについての基礎的なスキルが必要になります。
今回は「【IT基礎講座】システム開発におけるテストの重要性」というテーマについて書きたいと思います。
コンテンツ
1.なぜシステム開発でテストが重要か？
テレビや新聞等でも報道され、大きな社会問題となるようなシステムの重大事故が時々起こります。
非常に大きな事故としては、2002年4月に発生したメガバンクでのシステムの事故です。
合併前にも相当の規模であった3つの銀行を統合した際のシステムのトラブルです。
営業開始の初日に、ATMがシステムの障害で使用できなくなり、自動引き落とし等の口座振替ができなくなりました。
障害発生から5日後には、250万件の口座振替等の処理が未処理で溜まってしまったとのことです。
システム開発の工程が遅れてしまったということもありますが、このようなことが無いようにシステムを開発したり変更したりする時は様々なテストを行って、システムが問題なく動作するのか検証することが必要です。
システムを開発するというと、プログラムを作っているようなイメージを持っている人も多いかも知れませんが、システムの基本設計からシステムテストまでの工程の中で、システムのテストには3割から4割程度の工数が割かれます。
※詳しくはIPAの「ソフトウェア開発データ白書」（https://www.ipa.go.jp/files/000069381.pdf）等をご覧ください。
それだけシステムのテストは重要な仕事ということです。
2.システム開発でのテストの種類
では、システムを開発する際にどのようなテストをすれば良いのでしょうか。
一般によく言われるウォーターフォール型という開発でのテストの位置づけを示したのが以下の図になります。
※もう少し詳しく知りたい方はIPAの「ソフトウェア開発の標準プロセス」（https://www.ipa.go.jp/files/000004771.pdf）を参照してください。
システムのテストには大きくは4つの種類があります。
- 単体テスト
- 結合テスト
- システムテスト
- ユーザー受入テスト
それぞれについてみていきましょう。
1.単体テスト
開発したプログラムの一つ一つがプログラムの仕様書通りに動くかどうかをテストするものです。
プログラムの中の全ての条件や処理が正しいかどうかをテストします。
このようなテストの形式をホワイトボックステストと呼びます。
2.結合テスト
一つのプログラムだけで動作しているシステムはほとんどなく、大抵は多くのプログラムの組み合わせで動作します。
大きいシステムだと数万本というプログラムから構成されています。
そのため、単体テストで検証できたプログラムを接続して、プログラム同士が設計した仕様通りに連携して動作するかどうかを確認するのが結合テストです。
結合テストも基本的には、ホワイトボックステストを実施します。
3.システムテスト
結合テストが終了後に、システム全体で当初想定した仕様通りにシステムが動作するかどうかを検証します。
この段階では、システムが要件定義で決めた機能通りに動作するかということと合わせて以下のようなテストも実施して、本番の業務で運用しても問題ないかを総合的な観点からテストします。
- マニュアル検証
- 運用テスト
- パフォーマンステスト
- 負荷テスト
- 障害テスト
これまでの単体テストや結合テストでの検証が不十分だと、様々な箇所で問題が発生しがちです。
大きなシステムでは、どの箇所に問題があるのかを探し出し、対応策を検討するだけでも大変なことです。
そのため、各テストのステップできちんとテストを実施し、品質を担保することが何よりも重要です。
4.ユーザー受入テスト
システム開発を外部の会社に委託した際、システムテストまでは受託したシステム開発の会社が責任をもって実施しなければなりません。
一方で、システムテストが終わったことが確認できたら、ユーザーとして要件通りにシステムが動作するかどうかを最終的に確認する必要があります。
要件として決めた内容通りにシステムが開発されているとは限りません。
要件から設計書に落として、プログラムの開発に続く道のりで、要件がうまく反映されていない何てことも時々発生します。
そのため、要件通りに動作するのか、業務運用する際と同じようなシナリオを作成してシステムのテストを行います。
当然、ユーザー側ではシステムの中身については分かりません。
そのため、ユーザー受入テストでは、システムの中身ではなく、外側から要件通りに動くかどうかを確認します。
このようなテストのことを中身が分からないことからブラックボックステストと呼びます。
単体テストや結合テスト、システムテストと言ってもわかりにくいですよね。
簡単に図に表すと以下のような関係になります。
3.難しい回帰テスト
これまでは、システム開発の工程の順を追って実施すべきテストについて紹介してきました。
ユーザー受入テストが終了すると、実際にシステムを業務で運用することになります。
実際にシステムを運用し始めると、業務が変わったりすることで、システムを直さなければならなくなります。
そのため、変更が必要になるプログラムを特定し、変更の仕様書を作成してプログラムを変更します。
ここで、重要になるのが回帰テストです。
「リグレッションテスト（Regression Test）」と言ったりします。
この回帰テストとは、プログラムを変更したことで、同じプログラム内の他の箇所や、システムの他のプログラムに想定外の影響が現れていないかどうかを確認するためのテストです。
「直したところだけテストで確認すれば良いのでは？」って思いますよね。
「悪魔の証明」のようではありますが、回帰テストもとても重要な工程です。
例えば、家のリフォームを思い浮かべてみてください。
大がかりなリフォームをして、柱を切ったり、壁の位置を変えたりすると家の全体の強度が落ちたりして、全然関係ないところの扉があきにくくなったり、増築した部分から雨が侵入し、増築部分と関係ないところにある部屋で雨漏りが起こったりします。
同じように、プログラムも変更の度合いが大きくなればなるほど、当初想定した構造が崩れてしまい、直した部分と関係ないところでトラブルが起こってしまいます。
そのため、プログラムを変更した部分以外が変更する前と同様の動作をするかどうかを確認することは、非常に工数がかかる作業ですが、避けて通ることはできません。
4.まとめ
システム開発におけるテストの重要性を理解いただけましたでしょうか。
プログラムは、プログラムに書かれたコードの通りにしか動作しません。
例えば、プログラムを変更した際、間違えて変更とは関係ない部分のコードの［．（ピリオド）］を一つ消してしまっても、プログラムは暴走してしまいます。
ビジネスコンサルタントとしては、このようなプログラムの開発や変更に直接携わることはほとんどないと思いますが、PMO（プログラムマネジメントオフィス）という形で、クライアントのシステム開発プロジェクトを支援するようなことはよくあります。
その際に、このようなテストに対する正しい考え方を理解して、クライアントをリードすることがコンサルタントとして重要な役割になります。
