テスト・移行フェーズのPMの役割
確実に作業を進める
- 1つ一つの作業を確実に行う
- 確認が十分にされずに行われている作業がないか手順や役割が不明確になっている作業がないかなどを調査し、迅速かつ適切に対応する
- システムの移行作業のテストも十分に実施する
※移行テストとは、既存のシステムから新しいシステムへ移行する際に、移行の手順や移行による問題点などを確認することである。受け入れテストから運用テストまでの移行が円滑に行われるように実施されるものである。
※受け入れテストとは、納品されたシステムが要件を満たしているか確認する
※運用テストとはシステムの運用者によって行われるテスト
テスト・移行フェーズの作業手順 テスト作業開始前
プロジェクト状況の説明
- テスト作業に着手する前にプロジェクト・チーム・メンバー全員を集め、現在の状況と今後の作業について説明をする
- システム本稼働前の最後のフェーズなのでミスや見落としは許されないため、1つひとつの作業を確実に行うようにメンバーに伝える
- 特にコミュニケーションミスによる認識違いが発生しやすいので気を付ける
テスト・移行フェーズの作業手順 テスト作業中
作業の実行指揮・監視コントロールとリスク・マネジメント
- プロジェクトのスケジュールに従い、各作業の実施指示を行う
- 適宜、作業状況と進捗状況を確認して予定と実績の差異を把握する
- 定期的に進捗会議を行い、進捗状況をプロジェクト・チーム・メンバーや顧客などと共有する
- 外部から要員を調達している場合は、契約通りテスト作業を行なっているか契約先の管理担当者とコミュニケーションをとり、認識齟齬がないようにする
- 本稼働運用を行う上で、阻害要因となりうる事項がないか精査し、あればリスクとして管理する。メンバーにも不安要素の報告をもらう。
- リスク影響度、影響範囲を算定して対応優先度をつける
- 影響が大きいと想定したリスクについては、リスクが発生した場合の影響度を金額換算などで定量化する
- リスクに関する定性的または定量的評価を考慮に入れ各リスクの対応策を検討し、リスク対応計画としてまとめ、その上で具体的な対応を指示・実行する
- テスト・移行フェーズにおいて、システムが本稼働できない場合のコンティンジェンシープランの検討を行う(予想外の事態に備えた代替案)
品質チェック
- テスト作業による成果物が、当初決めた品質を満たしているか随時確認を行う
- テスト時のチェック項目にはテスト密度やバグ発生件数などがある
※テスト密度: 「テストケース数/規模」で算出。規模については、プログラムの行数や機能数などによって数値化する - 新システムのユーザー教育を行う。顧客満足はユーザー教育の内容や進め方に大きく左右されるので、新システムを受け入れてもらえるようにユーザ視点にたった理解しやすいユーザー教育を計画・実施する
スムーズな情報伝達及び調整
- PMは担当者間の情報伝達がスムーズになるように支援、調整する。テストで出たバグを重要度に応じて関係者と素早く連携する
- このフェーズのテストで露呈する露呈する問題には要件定義や設計時のコミュニケーションミスに起因するものが多くある。コミュニケーションの問題の場合、責任追求してもメリットがないので、責任追求の議論にならないようにPMは仕切る
変更対応
- テスト結果から機能変更の必要性が発生した場合は、コスト、スケジュールに及ぼす影響を調査の上、変更申請を行う
- 変更管理委員会で承認された場合はプロジェクト計画書を修正する
テスト・移行フェーズの作業手順 テスト作業後
次フェーズの用意
- テスト・移行フェーズでできなかったことや課題の積み残しを確認すると共に、運用・保守フェーズのWBSや作業項目を見直し、必要に応じて計画の変更を行う。作業を行うのに必要な資源や工数、期間を再度見積もりする。
- 運用・保守フェーズの体制や要員計画についても見直す。システム安定稼働に伴いメンバーを減らしていく。
- 運用・保守フェーズでは、新システム本稼働時に発生したバグの対応を円滑かつ適切に行う必要がある。
- バグ発生時の連絡方法や対応判定手順について再検討、再確認
- プロジェクトの状況報告や意見収集の頻度や形態も再検討、再確認
テスト作業の承認と移行判定
- システム移行作業の実施数日前には、スポンサーやステークホルダーを集め、システム移行を予定通り行うか否か判定する(移行判定会議)
※移行判定会議ではスポンサーやステークホルダーにテスト結果を説明し、どれだけテストが完了したのか、解決していない問題がどのくらいあるのか、システム移行によりどのようなリスクがあるのか明確に伝え、予定通りにシステム移行を実施するか否か判断を仰ぐ
テスト・移行フェーズの作業手順 移行実施
- 移行判定会議でシステム移行承認が下りたら、システム移行に向けての最終調整に入る。
- 移行作業は正確さと時間が大事
- それまでに作成した移行計画をもとに着実に作業を進める。
議論タイム
- 確認とかすぐ終わると思ってても実際には時間がかかるし大事
- 外部の立場でテスト事項が曖昧のまま降りてくるのが辛い
- プロジェクト状況の説明では具体的に話す内容
- ユーザーストーリー(どのようにユーザーが使うのか)
- スケジュール状況によっての動き方
- 重点的に見て欲しい部分など(粒度の高いテストが必要な部分など)
- 見るポイント。例えば、「UX的に設計したものが達成されているか見てください」などみるポイントを伝えておく
- テスト仕様がどうあるべきか理解しておかないとPMとして動けない
- この本の例だと、ユーザーテストのタイミングが遅い。プロトタイプを作っておいて、ユーザーテストを行うべき
- テスト段階で精査なしに丸投げで修正依頼が来るとスケジュール的に対応できない(本質的ではない項目が降りてくる)
