IVEC テスタークラス シラバス読解 Part11

はじめに

今回は前回の続きで、プロジェクト管理におけるシラバス読解の続きを進めていく
(8ヶ月ぶりの更新ですが)

プロジェクト管理（個人進捗管理も含む）

個人管理

学習の目的

役割の確認：テスト実行での役割を理解する

チーム構成を把握し、自分に任された役割を完遂する必要がある。そのためには各テスト実行担当者
に割り当てられた役割を理解しておく。またテストチームはチームワークにより成立する活動である
ことを理解する。各自が与えられた役割に対し、責任をもって実行することが必要である。

テストはチームで進めることが多い仕事であり、自然とチームでの活動が多くなる。
チームで活動する以上、チームワークの善し悪しがテストの成否を分けるといっても過言ではない。

チームワーク形成の難しさを考えた時、新しい人が入ってきた際の対応が思い浮かんだ。
他者との対話が得意でない人が入ってきた場合、特にチームが成熟したフェーズにおいては、自然と孤立してしまい、チームワークが機能しなくなるリスクが想定される。
　最悪なケースはそのままテスト実行した結果、誤った判断や別の人と重複して行っていたことで、手戻りや無駄な工数が発生してしまうことだ。

チーム内に気が利くメンバーがいれば、多少はマシかもしれないが、
年齢や経歴が異なるのが当たり前な世界において、見知らぬ人への応対は思った以上に難しさがある。
となると、テストを管理するリーダーが積極的に関与することが大事なポイントかもしれない。

テスト実行生産性の管理：テスト実行生産性の予定と実績を管理する

テスト実行生産性の管理には以下の要素がある。
① テスト実行項目数の予定と実績
② テスト実行時間の予定と実績
テストのスケジュールを守るためには、テスト実行担当者は割り当てられたテスト範囲、テスト実行
予定件数や実績件数など、テスト目標と進捗状況を常に把握しておく必要がある。テスト実行管理者
はチーム全体の予定と実績、および個人とチームの生産性を把握する。スケジュールに遅れが発生し
た場合は稼働時間増などで調整することがありますが、慢性的な状況が続くとモチベーションの低下
や品質低下につながる。
テスト実行管理者は日々の進捗を把握し、スケジュールの遅れが大きくなる前に対策を検討する必要
がある。また、テスト実行担当者は、テスト実行の遅れがチーム全体のスケジュールに影響を及ぼす
可能性があることを理解する必要がある。

テスト実行担当者は自身のテスト範囲と日頃の実績を頭に入れて作業に臨むことが求められる。
限られた期間でテストを完了させる上で、テスト実行の難易度のばらつきから、全員が同じ進捗を稼ぐことは現実的ではないかもしれないが、進捗を稼げるメンバーがリカバーしてあげる姿勢が大切になる。
　また、進捗に遅れが発生した際は、ボトルネックになっているのはどの部分かを言語化しなければならない。そうしないとテスト実行管理者がステークホルダーに対し、テスト遅延の理由を説明できない羽目になり、テストリーダーの心労が増し、テストメンバーへの当たりが強くなってしまいかねない。

テスト実行管理者は日々のテストの進捗を観察し、テスト実行でボトルネックになっている部分がないかをチェックした上で、必要に応じて開発担当やステークホルダーへ打ち上げる。
　テスト実行上の課題を放置し、宙ぶらりんの状態を避けるため、テストチーム内で抱えている問題が内部で解決できるのか、外部に助けを求めるべきかの早急な切り分けが求められる。

コミュニケーション管理：テスト実行中のコミュニケーションの重要性を理解する

テスト実行において報告・連絡・相談・質問のコミュニケーションは必須である。テスト実行中のコ
ミュニケーションには以下のようなものがある。
・報告：進捗報告、不具合報告、質問事項の報告、トラブル報告など
・連絡：チーム内外のステークホルダーへの周知事項など
・相談：不明点や確認事項など、テスト実行担当者個人で判断出来ないことの指示を仰ぐ場合など
内容によって手段やタイミングが異なる。タイミングを誤ることでスケジュールに影響を及ぼす可能
性があるため、適切な手段とタイミングを理解しておく必要がある。

コミュニケーションが多様化した中において、テストチームやステークホルダーに対し、コミュニケーション管理のあり方や運用ルールを決めておくことは重要な要素になる。
特にSlackやTeams等、コミュニケーションツールが普及した現代においては、チャットが行き交うことでチームメンバーからの質問や課題が埋もれてしまいがちになる。
テスト実行中のコミュニケーションに関しては、チームを取り巻く環境によって最適解は変わってくるため、テストが始まる前に何らかの形で合意形成を図っておくと、テスト実行時にカオスな状況にならずに済むかもしれない。

[報告]

• 不具合発生時の起票フロー作成及び運用
• 毎日決まった時間に定型のフォーマットに沿った進捗報告の実施
• 仕様に関する疑問点の解消フロー作成とステークホルダーへの合意形成
  [連絡]
• 日時、週次の定例ミーティングの開催とアジェンダの策定
  [相談]
• コミュニケーションツールのやり取りに関するルール形成
  (チャットをn回以上往復した場合、通話での直接やり取りする etc)

おわりに

久々に読解記事を書きました。
中途半端な形で終わらせたくないので、2025年2月末を目処に終わらせにかかります。