総合テストのスコープを適当に設定...プロジェクト大炎上 -リファイン-

2022年12月20日

無料でプロジェクト管理をもっと効率的に！

初心者PM向けに特別な資料をご用意しました！現在、以下の資料を無料でダウンロードできます。

📄 結合テスト計画書チェックシート

結合テストの目的設定からテストケース作成まで、実務で必要なチェックポイントを網羅しています。

テスト計画の作成を徹底したい方へ！

ダウンロードいただけるこの資料は、プロジェクト成功に欠かせない要素を網羅しており、初心者から上級者まで幅広く活用されています。

ぜひ無料でダウンロードしてください！

なお、他にも複数の専門資料やテンプレートが用意されていますが、それらはiPM naviコミュニティの無料会員限定でダウンロード可能です。

この機会に登録を検討してみませんか？

会員登録ページはこちら

プロジェクトの重要な品質チェックの工程として、総合テストがあります。

プロジェクトは入念にテスト計画を策定して慎重に実施して行かなくてはなりません。

特に複数のチームで総合テストを分担して実施する時は、PMが『各チームにお任せ』という丸投げマネジメントがプロジェクトを危険に晒します。

この記事では、読者のあなたへ、実際に私がPMアドバイザーとして参画し解決した、トラブルプロジェクトの実例を紹介します。

今回は、『総合テストのスコープを適当に設定...プロジェクト大炎上』というテーマです。

あなたのマネジメント業務で活用できるように、解決までのアプロローチを以下の順番でお伝えします。

・プロジェクトの状況

・問題の設定・原因追求

・解決策

・教訓（リスク管理表へ整理）

writing by MASA

2004年に大手コンサルファームBにジョイン。

大手事業会社をクライアントに持ち、クライアント社内で活用する品質マネジメント基準・開発プロセス基準の策定に従事。

また、PMOとしてクライアントのプロジェクト推進及び品質維持に貢献しプロジェクトを成功に導いた。

2016年に大手コンサルファームMにジョイン。

大手エネルギーインフラ会社のガバナンス部門にて、大規模システム開発プロジェクトのマネジメント品質管理に従事。

PMOとしてプロジェクト運営における問題点の可視化とプロジェクトマネージャおよび上位層への改善提案によりプロジェクトを成功に導いた。

2年前に公開したこの記事は、多くの反響をいただき、多くの方に読まれました。

今回、この内容を最新のプロジェクト管理トレンドに合わせてリファインしました！

2年前に公開した記事を最新のプロジェクト管理トレンドに合わせて更新しています。

なお、リファインされた最新情報は、会員限定のブログで公開しています。

詳しい実践事例や便利なテンプレートを活用したい方は、ぜひ無料会員登録をご利用ください。

会員登録ページはこちら

最新版には、以下のような追加情報が含まれています：

初心者PMが陥りやすい失敗に特化したセクションを追加

具体例をより豊富にして実践的なアドバイスを充実

最新のプロジェクト管理トレンドを反映

プロジェクトの状況(総合テストのスコープ)

1.プロジェクトのスコープと体制 ・顧客は大手半導体メーカー。・顧客の情報システム部で新規構開発を実施。・情報システム部の窓口は木村。・プロジェクトオーナーは情報システム部の山田。・システム化スコープは調達管理、資材管理、製造管理。・中堅SierのA社が開発ベンダーとして参画。・A社は全開発工程の成果物の納品、システムリリースの責任を請け負う。・A社の開発体制は業務チーム・基盤チーム・テストチーム・管理チームで構成。・A社のPMは佐藤（初心者PM） 2.プロジェクト目標 品質目標：100%の不具合修正スケジュール目標：予定通りのリリースコスト目標：予算内でのシステム完成 3.プロジェクトの進捗状況 現在、プロジェクトは総合テスト工程である。総合テストが所要期間の50%を消化した時点で、テスト状況を確認したところ各チームの進捗にばらつきがあった。特に、前倒しでテストを行っているチームのテスト範囲が間違っていることから、再テストを実施する必要があった。システムの品質を担保するには、リリース日を遅延せらる得なかった。そのために、PM佐藤は顧客の木村に、リリースの延期を依頼したが、『再テストを行うことは問題ない。』『しかし、リリースの延期はできない、当初の計画通り進めてほしい』と一蹴された。しかし、佐藤は状況を把握しているが、具体的な問題や解決策が分からない状態である。 **守秘義務により企業名・団体名・個人名等は架空名称となります。

問題の設定(総合テストのスコープ)

*私がアドバイザーとして、プロジェクトに参画して解決させた経緯のスタートです。問題を考える場合は、どのマネジメント領域で発生したかを分類することで、後続のアプローチがスムーズに行え、得られた結果の根拠も説得力を持つ。そこで、今回の問題は、プロジェクトで起きた事象を、様々なプロジェクト情報から考えをもとに考たところ『スコープマネージメント領域』で発生した問題として取り扱った。また、今回のプロジェクトの問題をこのように設定した。 ”総合テスト範囲がわからずスケジュール遅延” また、この問題を放置することで、品質目標である要望達成率100%を逸脱とスケジュール目標であるリリース日を逸脱する恐れがあった。

様々なプロジェクト情報とは

プロジェクト計画書、レービュー結果報告書、要求変更書、レビュー対象物、作業実績情報、作業範囲記述書、要件定義書、成果物一覧、課題問題整理表、役割分担表、要員の選定根拠、勤務表、成果物、関係者からのヒアリング結果

原因の追求(総合テストのスコープ)

原因を特定するためには関係者へのヒアリングが重要である。しかし、闇雲に関係者から聞き取りを行っても時間の無駄であることから原因の仮説を3つ立てた。 1.原因の仮説と検証 仮説1 総合テストに必要な所要期間が間違っていた。

仮説の検証

有識者の算出し所要期間も計画と同じであったか？【検証結果】有識者の算出した所要期間と同じであった。

仮説2 総合テストを実施するメンバーのスキルが低かった。

仮説の検証

総合テストの経験者がいたのか？【検証結果】優秀なベテランSEがいた。

仮説3 総合テストのスコープとテスト手順を理解していなかった。

仮説の検証

総合テスト計画書にテストスコープとテスト手順の記載があったか？【検証結果】 テスト範囲、テスト手順の記載がなかった。

2.今回の問題の原因 総合テストのスコープとテスト手順を理解していなかった。と判明した。また、大雑把なテストスケジュールを組んだだけで、テストスコープと手順は、各チームに任せていた。

解決策(総合テストのスコープ)

テストスコープ設定の重要性

わたしは3つの解決策を準備しました。解決策A テストスコープとテスト手順を、全ての見直しが完了するまで、プロジェクトを中断する。解決策B クリティカルな範囲のテストスコープとテスト手順を作成して、総合テスト経験者を増員する。解決策C テストスコープとテスト手順を全ての見直して、総合テスト経験者を増員し、リリース日を延期する。現在のプロジェクトの状況とこの解決策の案をPO山田へ提言した。 PO山田は、このような意向があった。 ⚫︎ 品質についてクリティカルな範囲に絞ってテスト計画を作成することは問題なし。 ⚫︎ リリース日についてリリース日の延期はできない。このことから、解決策Bを採用した。また、この解決策を施行することで、開発ベンダーA社はテストスコープの設定とテスト手順の作成により、計画工数を30%超過することになった。

総合テストのスコープ:教訓（リスク管理表へ整理）

今回の原因は、流用を前提にしていたことから調査が不十分ということであった。このような事態を、事前に回避することはできる。それは、プロジェクト計画の段階でこれらを実施することで防止できるのである。・総合テスト計画のガイドラインを作成する・総合テスト計画書にストスコープとテスト手順を盛り込む。今回のトラブルプロジェクトをリスク管理表に整理したので、あなたのマネジメント業務で活用して頂ければ幸いである。