予想しきれないバグ！テスト工数が大超過！
お疲れ様です、ゆーろー@常駐しないPMOです。
わたしがプロコンサルとして参加しているiPM naviのコラムをご紹介します。
今回のコラムは大手コンサルファームで活躍している”MIRIO”さんが、実際にPMアドバイザーで参画した炎上プロジェクトの実例となります。
テスト結果の分析はしてますか？これって、大変面倒くさいですよね。
しかし不具合の傾向を分析しないで、次のテスト工程に進むことを許可するPMが意外にも多いものです。
「不具合の分析は不要」と考えるPMもいますが、不具合の傾向こそが、次のテスト工程のリスクを緩和せるための材料になります。
更に、品質向上の鍵となるのです。
こんにちは、プロコンサルのMIRIOです。
私が参加しているiPMでは、PM初心者のスキルアップやDX時代に適応したいPMのリスキリングのサポートとして、iPM TRAININGを運営しています。
その中のオプションサービスとして、『トラブルプロジェクトの実例から学ぶ失敗しないマネジメント』をお伝えしています。
このコラムでは、読者のあなたへ、実際に私がPMアドバイザーとして参画し解決した、トラブルプロジェクトの実例を紹介します。
今回は、『予想しきれないバグ！テスト工数が大超過！』というテーマです。
あなたのマネジメント業務で活用できるように、解決までのアプロローチを以下の順番でお伝えします。
・プロジェクトの状況
・問題の設定
・原因追求
・解決策
・教訓（リスク管理表へ整理）
👍 このコラムは
むずかしさ ：
★★☆☆☆（PM初級者向け）
ボリューム ：
★★★☆☆(5分-8分で読める)
気付き学び ：
★★★★★(テスト分析の重要性)
お役立ち ：
★★★★★(コスト管理)
仕事の実用性：
★★☆☆☆（有識者のサポートが必要かな）
もっとMIRI0さんのコラムを読みたい方はiPM naviへメンバー登録（無料）してください。
登録は（こちら）。
プロジェクトの状況
1.プロジェクトのスコープと体制
・顧客は大手出版会社。
・顧客の情報システム部で新規構開発を実施。
・情報システム部の窓口は木村。
・プロジェクトオーナーは情報システム部の山田。
・システム化スコープは受注管理、出稿管理、営業管理。 ・中堅SierのA社が開発ベンダーとして参画。
・A社は全開発工程の成果物の納品、システムリリースの責任を請け負う。
・A社の開発体制は業務チーム、基盤チーム、テストチーム、管理チームで構成。
・A社のPMは佐藤（初心者PM）
2.プロジェクト目標
品質目標：100%の不具合修正
スケジュール目標：予定通りのリリース
コスト目標：予算内でのシステム完成
3.プロジェクトの進捗状況
現在のプロジェクトは結合テスト工程である。
所要期間の50%を消化した時点で、想定外の不具合が多発している。
テストの実行とプログラムの修正に計画以上の工数が発生している。
そのために、PM佐藤は顧客の木村に、リリースの延期を依頼したが、
『品質基準をクリアするように工夫して欲しい。』
『当初の計画通り進めて欲しい。』
と一蹴された。
しかし、佐藤は状況を把握しているが、具体的な問題や解決策が分からない状態である。
**守秘義務により企業名・団体名・個人名等は架空名称となります。
問題の設定
*私がアドバイザーとして、プロジェクトに参画して解決させた経緯のスタートです。
問題を考える場合は、どのマネジメント領域で発生したかを分類することで、後続のアプローチがスムーズに行え、得られた結果の根拠も説得力を持つ。
そこで、今回の問題は、プロジェクトで起きた事象を、様々なプロジェクト情報から考えをもとに考たところ『コストマネージメント領域』で発生した問題として取り扱った。
また、今回のプロジェクトの問題をこのように設定した。
”想定外の不具合による結合テストの工数超過”
また、この問題を放置することで、コスト目標である予算内でのシステム完成を逸脱する恐れがあった。
様々なプロジェクト情報とは
プロジェクト計画書、レービュー結果報告書、要求変更書、レビュー対象物、作業実績情報、作業範囲記述書、要件定義書、成果物一覧、課題問題整理表、役割分担表、要員の選定根拠、勤務表、成果物、関係者からのヒアリング結果
原因の追求
原因を特定するためには関係者へのヒアリングが重要である。
しかし、闇雲に関係者から聞き取りを行っても時間の無駄であることから原因の仮説を3つ立てた。
1.原因の仮説と検証
仮説1
結合テストの工数が間違っていた。
【 仮説の検証 】
有識者が算出したテスト工数と同じであったか？
【 検証結果 】
有識者の算出したテスト工数と同じであった。
仮説2
総合テストの所要期間が間違っていた。
【 仮説の検証 】
有識者が算出した所要期間と同じであったか？
【 検証結果 】
有識者の算出して所要期間と近い数字であった。
仮説3
単体テストのバグ分析が行われなかった。
【 仮説の検証 】
単体テストでテスト密度やバグ密度の組み合わせ分析を行ったか？
【 検証結果 】
密度分析は行わずテスト消化数と修正数をテスト管理していた。
2.今回の問題の原因
単体テストのバグ分析が行われなかった。
と判明した。
また、探偵テストで発生した不具合の傾向を分析せず、結合テストを進めていた。
解決策
わたしは3つの解決策を準備しました。
解決策A
単体テストをやり直して、結合テスト移行のスケジュールを見直す。
解決策B
技術力の高いメンバーを増員して、単体テストの不具合分析を行うことで結合テスト項目の精度を上げる。
解決策C
技術力の高いメンバーを増員して、単体テストの不具合分析を行うことで結合テスト項目の精度を上げる。 その上で、スケジュールを延期する。
現在のプロジェクトの状況とこの解決策の案をPO山田へ提言した。
PO山田は、このような意向があった。
⚫︎ 品質について 単体テストの分析による結合テスト項目の精度を上げることに問題なし。
⚫︎ リリース日について リリース日の延期はできない。
このことから、解決策Bを採用した。
また、この解決策を施行することで、開発ベンダーA社は技術力の高いメンバーを増員することにより、計画工数を30%超過することになった。
教訓（リスク管理表へ整理）
今回の原因は、流用を前提にしていたことから調査が不十分ということであった。
このような事態を、事前に回避することはできる。
それは、プロジェクト計画の段階でこれらを実施することで防止できるのである。
・テスト密度とバグ密度の分析及び、不具合の原因や傾向の調査実施を方針とする。
・単体テスト工程で不具合の分析から原因と傾向を把握して結合テストの対策を検討する。
なぜ、プロジェクトが破綻したのか？
今回、プロジェクトが破綻したのは、PM経験が少ないことによるプロジェクト計画の策定を失敗したからです
PM経験が浅い方は、プロジェクト計画で何を考えれば良いかが曖昧になっているケースがあります。
プロジェクト計画で、重要なのはプロジェクトを成功させるための要素を認識していなくはなりません。
プロジェクト計画を構成するは3つの要素
WHY：
なぜプロジェクトを行うのか。
WHAT：
どのような作業を行なって、どんな成果物を作るのか。
HOW：
どんな成功に導くための手段や方法を用意するのか。
破綻するプロジェクトは、3つの要素に対して、これらのことが出来ていないからです。
・どれか一つが漏れてしまった。
・間違った手順で作ってしまった。
・正しいメソッドやノウハウを使えなかった。
そのため、PMはプロジェクト計画を立てる時に、以下を意識してください。
1.構成を順番通りに、
2.正しい手順で、
3.メソッドやノウハウを使って、
4.「プロジェクト計画書」に、まとめる。
もし、あなたがこれらを意識していけど、
「勉強したいけど、何から手をつけていいか分からない」
「今の勉強方法が実践で使えるか自信が持てない」
「体系的にプロジェクトマネジメントを学び体験したい」
このように感じているなら、iPM TRAININGにチャレンジしてください。
あなたのプロジェクト計画書を作るスキルUPをサポートするサービスです
最後まで、読んでいただき有難う御座いました。
いいなと思ったら応援しよう！
