はじめに

初めまして、パーソルプロセス＆テクノロジーのITアーキテクト、Hajime.Iです。

私は直近、2年半の工期を要し、参画者が200名以上の大規模なプロジェクトにジョインしていました。日本において、工期1年以内のプロジェクトが8割弱を占める(※1)中、かなり大きいプロジェクトといって良いと思います。

(※1) IPA情報通信処理機構「ソフトウェア開発データ白書2018-2019」より

本プロジェクトにおいて、私はサービスイン前の最終テストである総合テストを計画から運用まで牽引しました。既にこのシステムは無事にサービスインを迎えており、これほどの大型プロジェクトで大きな問題なく稼働しているため「大成功」と言ってよいと思います。

ただ、ここに至るまでにはプロジェクトの各工程で様々な問題への対応がありました。今回は私がリーダーとして牽引した総合テストに絞り、成功のポイントをお話したいと思います。

大規模なシステム開発プロジェクトに参画されている方、その中で総合テストを担っている方、今後このようなキャリアにチャレンジされたい方に、少しでも参考になればと思います。

自己紹介

総合テストって何するの？

総合テストはシステムテストとも呼ばれ、開発したシステムがお客様要件通りに動作するかを確認する工程のことを言います。

ここで言う「システム」とはアプリケーションだけを指すものではなく、サーバーやデータベースなどのインフラ、定義ファイルやマスタなどのデータ、定期的なデータ更新などの運用業務が含まれ、お客様に提供するサービスに関わるもの全てについて、本番と同様に動作し実施できるかを確認していきます。

そのため、総合テストを行う上で考慮すべきことは多岐に渡ります。

機能テスト、移行テスト、性能テスト、運用テスト、セキュリティテストといったテスト実施の他にも、それぞれのテスト環境をどのように構築するか、その環境をどのように維持・管理していくか、アプリケーションや定義ファイルのバージョン管理やリリース管理、摘出した不具合の管理方法や品質分析、スケジュール、評価基準、リスクも考えなくてはなりません。

総合テストにおける私の役割

今回私はこの総合テストをリーダーとして牽引し、計画、準備から実行管理を行いました。

□計画
計画フェーズでは、総合テストの目的から前項で述べた多岐に渡る検討事項を計画書に落とし込みます。プロジェクトに合わせ、各チームとの密な調整が必要です。

□準備
上記で計画したことを実践するために、計画を具体化したり、ルール化したりします。

□実施管理
各テストを実施する中で、進捗管理や不具合管理などを行います。また、計画したことやルール化したことが実践されているかを監視し、もし実践されていなければ改善を行います。

これらの施策を行う中で成功のポイントとなった部分は、以下の３点です。

✔️成功のポイント①：プロセスデザイン
✔️成功のポイント②：見える化
✔️成功のポイント③：チーム任せにしない

以下、それぞれ解説していきます。

【成功のポイント①】プロセスデザイン

総合テストで行うテストは様々ありますが、いずれも目的を定め、その目的を達成するためのプロセスを決め、それらを確認するチェックリストを作ることが重要です。目的とプロセスがしっかりしていれば、凡そ間違ったテストにはなりません。

例えば、機能テストであれば、その目的は「システムで想定する業務が行えること」の確認にあります。そのため、以下のようなプロセスでチェックリストを作成していきます。

(1) 業務フローから「当該システムを使ってどのような業務を行うか（ユースケース）」を洗い出す。
(2) 基本設計書から、「データと機能の関連図」を作成する。
(3) 「ユースケース」と「データ･機能関連図」を組み合わせ、テストの「シナリオ」を作成する。
(4) テストで確認するポイント（観点）を要件定義などから洗い出す（「観点表」を作成する）。
(5) シナリオと観点を突き合わせて「チェックリスト」を作成する。

要件定義書や業務フロー、基本設計書をインプットとして、それぞれのプロセスのアウトプットを組み合わせてチェックリストに落とし込むことで、目的を達成するために確認すべきことを抜けもれなく把握しやすくなるわけです。

【成功のポイント②】見える化

「総合テスト」というキーワードでググると、たくさんの総合テスト推進の方法論が出てきます。ただ、どのメソッドも、具体的に作業や工程の内容がイメージできるほどには詳しく解説されていません。

日本のシステム開発の大半を占めるウォーターフォールモデルでは、製造･単体テスト工程の工数が一番大きくなり、その後の工程では工数が徐々に減少していきます。最後の工程となる総合テストを経験しているエンジニアはそもそも少ないのです。

実際、今回のプロジェクトでも本格的な総合テストを経験しているエンジニアは少数で、大半がどのようなことをするのかイメージできていませんでした。

今回私は総合テストをリードするにあたり、このような背景も認識していたため、メンバーが総合テストの内容を具体的にイメージできるような「計画書」を作成することを心掛けていました。

例えば、先ほど機能テストの例でご紹介したような、ユースケースなどの中間成果物のフォーマットを提示し、インプット元となる資料からどのように中間成果物を作り出すのか、その方法やプロセスを「計画書」として例示し、「見える化」していました。

また併せて、テスト環境の構築においては、進め方や注意点を可視化することを意識的に行なっていました。テスト環境の構築は、ググって出てくる一般的な方法論では「本番環境に近い環境でテストする」と記載されていますが、それをより具体的にした、ということです。

即ち、テスト環境はいくつあり、それぞれの用途は何か、どのような社外システムに接続されているか、データの内容や各環境の差異、更には並行して複数人がテストする際の注意点やルールなどまで、徹底的に「見える化」することで、経験の浅いメンバーでも総合テストにおける位置付けをイメージできるようになりますし、またメンバーが何かに迷ったときにも拠り所として計画書が機能します。

また、具体的に「見える化」することで、曖昧なまま内容が決まっておらず、いざテストをするときになって「これはどうすれば良いのか…」となることを予防する効果も期待できます。曖昧な部分は計画する人ですら想像できていないことがあるために発生するものなので、これを極力減らすように計画していきます。

このような努力を行った結果、概ね計画通りに総合テストを推進できました。

【成功のポイント③】チーム任せにしない

今回のような大規模プロジェクトの場合、システムを作り上げる際にたくさんのチームが連携します。サブシステムごとにチームが分かれていたり、インフラ・移行・運用・品質管理など機能別にも分かれていたりしますが、これら全てのチームと連携しながら総合テストを計画していく必要があるわけです。

各チームは自分のチームのことで精一杯であることが多いため、私はリーダーとして、各チームの課題を突っ込んで吸い上げ、他チームを巻き込んで解決できることがあればその橋渡しをするような役割で動きました。

例えばテスト環境の利用計画を検討する場合、各テストチームがどのようなプロセスでテスト実施に入るのか、そこまでのスケジュール感を確認します。そのうえで、いつまでにテスト環境を整備し、各チームがいつどの部分のテスト環境を使うかを調整します。環境が足りない場合は、他プロジェクトで使っていない環境を使い回せないかを検討し、各所と調整しながら問題を解決していきました。

おわりに

今回は総合テスト成功のポイントを私自身の経験から紹介しました。

この経験は、総合テストのみならずプロジェクトのいろいろな場面で応用できることだと感じています。大事なのは視座を高く保ち、プロジェクトの目的を意識して行動することだと思います。

今回の成功を経て、私は同じシステムの追加開発において同じ役割を任されることになりました。実際のプロジェクトではここに書ききれないくらいのたくさんの反省点もありましたが、次のプロジェクトではこの成功のポイントを踏襲しつつ、反省点を改善してより良い貢献ができればと考えています。

最後までお読みいただき、ありがとうございます。この記事がみなさんの業務の一助になれば幸いです。

パーソルクロステクノロジーでは幅広いポジションで積極的に採用中！

超上流から関われるプライム案件にジョインしていただけるエンジニアを募集しています。企画から保守運用まで一気通貫で関われるSIerの組織で、エンジニアとしてのキャリアアップを目指しませんか？

現在募集中の職種は、以下リンクの事業領域「システムインテグレーション」をご覧ください。