リファインされたブログをご覧いただくには、無料会員登録が必要です！
リファインされた内容を確認したい方は、iPM naviコミュニティの無料会員に登録をしてください！
👉 ［ iPM naviの活用方法はこちら ］
初心者PMや実務者が実践で活用できるよう、より分かりやすい内容に更新しました。
リファインのポイントは以下のとおりです。
✅ 「初心者PMが陥りやすい失敗」セクションを追加し、注意点を整理
✅ 原因セクションを新設し、問題を体系的に整理
✅ トレンドに合わせた解決策A、B、Cを記載
さらに、他のリファインブログや追加コンテンツも閲覧可能です！
プロジェクト管理の効率をさらに高めたいあなたへ
🔗 [今すぐ無料会員登録はこちらから]！💡 無料ダウンロード資料のご案内
初心者PM向けに特別な資料をご用意しました！ 現在、以下の資料を無料でダウンロードできます。
📄 結合テスト計画書チェックシート
結合テストの目的設定からテストケース作成まで、実務で必要なチェックポイントを網羅しています。
👉 今すぐダウンロードして、あなたのプロジェクト成功に活かしてください！
[🔽 無料ダウンロードはこちら 🔽]
✨ 他では得られない特別な特典 ✨
他の無料記事では手に入らない、iPM naviならではの特別な特典を最後にご紹介してます！
writing by OSAMU プロジェクト計画では、スケジュール作成します。 しかし、テストの難易度からテスト日数の算出を行わないPMがいます❗️ 計画ミスにより、スケジュールが遅延してプロジェクトが破綻するケースがあります。 なぜ、このようなトラブルが起こるのでしょうか？ それはテストの難易度を理解するアプローチに不備があるからです。
このコラムでは、読者のあなたへ、実際に私がPMアドバイザーとして参画し解決した、トラブルプロジェクトの実例を紹介します。 今回は、『テスト計画のミスでスケジュール遅延_』というテーマです。 あなたのマネジメント業務で活用できるように、解決までのアプローチを以下の順番でお伝えします。 ・プロジェクトの状況 ・問題の設定 ・原因追求 ・解決策 ・教訓（リスク管理表へ整理）
テスト計画 スケジュール遅延：プロジェクトの状況
テスト計画 スケジュール遅延
1.プロジェクトのスコープと体制
・顧客は大手エンターテーメント会社。
・顧客の情報システム部で新規構開発を実施。
・情報システム部の窓口は木村。
・プロジェクトオーナーは情報システム部の山田。
・システム化スコープはタレント管理、給与管理、営業管理。
・中堅SierのA社が開発ベンダーとして参画。
・A社は全開発工程の成果物の納品、システムリリースの責任を請け負う。
・A社の開発体制は業務チーム、基盤チーム、テストチーム、管理チームで構成。
・A社のPMは佐藤（初心者PM）
2.プロジェクト目標
品質目標：100%の不具合修正
スケジュール目標：予定通りのリリース
コスト目標：予算内でのシステム完成
3.プロジェクトの進捗状況
現在、プロジェクトは結テスト工程であり、所要期間の50%が経過した。
結合テスト計画のテスト数・作業工数・割当人数・所要期間を有識者のレビューで合格をもらったにも関わらず、大幅に進捗が遅延した。 そのため、顧客の情報システム部 木村にリリース延期を依頼した。 しかし、木村から 「計画が正しいにも関わらず遅延の原因が分からない。」 「そんな状況で、リリースの延期は認められない。」 「当初の計画通り進めて欲しい。」 と一蹴された。 佐藤は状況を把握しているが、具体的な問題や解決策が分からない状態である。 **守秘義務により企業名・団体名・個人名等は架空名称となります。
テスト計画 スケジュール遅延：問題の設定
*私がアドバイザーとして、プロジェクトに参画して解決させた経緯のスタートです。
問題を考える場合は、どのマネジメント領域で発生したかを分類することで、後続のアプローチがスムーズに行え、得られた結果の根拠も説得力を持つ。 そこで、今回の問題は、プロジェクトで起きた事象を、様々なプロジェクト情報から考えをもとに考たところ『スケジュールマネージメント領域』で発生した問題として取り扱った。 また、今回のプロジェクトの問題をこのように設定した。 ”テスト項目ごとの実行計画のミスによるスケジュール遅延” また、この問題を放置することで、スケジュール目標であるリリース日を逸脱する恐れがあった。
様々なプロジェクト情報とは
プロジェクト計画書、レービュー結果報告書、要求変更書、レビュー対象物、作業実績情報、作業範囲記述書、要件定義書、成果物一覧、課題問題整理表、役割分担表、要員の選定根拠、勤務表、成果物、関係者からのヒアリング結果
テスト計画 スケジュール遅延：原因の追求
原因を特定するためには関係者へのヒアリングが重要である。 しかし、闇雲に関係者から聞き取りを行っても時間の無駄であることから原因の仮説を3つ立てた。 1.原因の仮説と検証 仮説1 想定外の不具合が多く発生していた
仮説の検証
バグ管理表に想定外の不具合の記載はなかったか？ 【 検証結果 】 想定外の不具合の記載はなかった
仮説2 過剰にテスト項目が多かった
仮説の検証
有識者の算出したテスト項目数も計画と同じだったか？ 【 検証結果 】 計画と同程度であった
仮説3 テスト難易度の設定が間違っていた
仮説の検証
テスト項目に難易度の記載はあったか？ 【 検証結果 】 難易度は記載されていなかった
2.今回の問題の原因 テスト難易度の設定が間違っていた と判明した。 また、テストの難易度がテスト実施日数に影響することを知らず、テスト項目を同じ分量で担当者へ割り振っていたことが分かった。
テスト計画 スケジュール遅延：解決策
わたしは3つの解決策を準備しました。 解決策A テスト難易度を設定せず新規メンバーを投入してテストを続行する。 解決策B テスト難易度を設定して、一人当たりの分量を見直す。 解決策C テスト難易度を設定して、一人当たりの分量を見直す。その上でスケジィールを延期する。 現在のプロジェクトの状況とこの解決策の案をPO山田へ提言した。 PO山田は、このような意向があった。 ⚫︎ 品質について テスト難易度を設定して、一人当たりの分量を見直すことに問題なし。 ⚫︎ リリース日について リリース日の延期はできない。 このことから、解決策Bを採用した。 また、この解決策を施行することで、開発ベンダーA社はテストの難易度を設定する工数が必要となり、計画工数を30%超過することになった。
テスト計画 スケジュール遅延：教訓（リスク管理表へ整理）
今回の原因は、テストの難易度の設定が間違っていた（または、行なっていない）ということであった。 このような事態を、事前に回避することはできる。 それは、プロジェクト計画の段階でこれらを実施することで防止できるのである。 ・結合テスト計画として、テストの難易度が設定されていることを方針として盛り込む。 ・結合テストでテストの難易度から、実施日数を検討して最適なスケジュールをする。 今回のトラブルプロジェクトをリスク管理表に整理したので、あなたのマネジメント業務で活用して頂ければ幸いである。
最後まで、読んでいただき有難う御座いました。
リファインされた詳細情報は無料会員限定！
リファインされたブログを読むためには無料会員登録が必要です！
🔗 [今すぐ無料会員登録はこちら]
精度の高い工数算出でプロジェクト成功を目指しましょう！
他では得られない特別な特典
👥 会員限定ダウンロード資料のご案内
iPM naviの無料会員に登録すると、以下の貴重な資料セットをダウンロードできます！
📘 結合テスト関連資料セット
計画書サンプル：プロジェクト全体を見渡せる結合テスト計画のひな形。
レビュー実施ガイドライン：効率的なテスト進行やレビュー時の確認ポイントを解説したガイドライン。
📘 総合テスト関連資料セット
テスト計画書の作成用チェックシート、テスト計画書サンプル、レビュー実施ガイドラインを一括で提供し、総合テスト全体を効率よく進められる構成。
📘 ユーザーテスト関連資料セット
テスト計画書の作成から実施までをカバーするチェックシート、計画書サンプル、レビュー実施ガイドラインをまとめたセットで、ユーザーテストの品質向上を徹底サポートします。
👉 この特典を見逃さず、次のステップへ進みましょう！
[🔗 無料会員限定特典を見る 🔗]
iPM naviコミュニティの使い方を動画でチェック！
プロジェクト管理に関する情報交換や相談ができる「iPM naviコミュニティ」に参加してみませんか？
フォーラムの魅力や活用方法を4分間のガイド動画で分かりやすく解説しています！
この動画では、次のポイントをお伝えしています：
フォーラムで何ができるのか
活用することで得られる便利な機能や情報
iPM naviコミュニティの魅力をチェックし、今すぐ無料会員登録をして次のステップへ進みましょう！
今すぐ無料会員登録！
「プロジェクト管理をもっと効率よく！」iPM naviコミュニティで情報を手に入れ、成長の一歩を踏み出しましょう。
[📥 無料会員登録はこちら]