【振り返り】最近のPT工程での遅れについて

【今回の紹介】

最近、あんまりうまくいかなったPT工程付近のふりかえり
自省して、つぎはもっと円滑に作業をすすめられるようにしたい。

【内容】

■前提

　規模　：2000〜2500項目
　体制　：PT工程に携わる人数は4,5人
　作業者：開発者2人、テスター3人
　環境　；各自ローカル端末
　作業内容；PT（開発者では作業員がテストを行う。）そのため、個別機能に必要なデータは用意が必要
　※pjリーダはいるが、PT工程を統括して推進する人が明確でない状態
　　経験豊富な開発者は、同時並行で行われていたPT仕様書作成のため、多忙

■よかった点

1.主体的に動けたこと（全体項目数の報告、日々の消化項目数の推移の報告）
2.定量的に報告できたこと(１日あたり◯項目数消化の見込みであり、○日までに終わる見込み)
3.役割・立場の変化（作業者→とりまとめ、作業指示をだす側へ）

■改善点

1. 理想：WBS通りにタスクが遂行される
　　現状：２週間ほどの遅れがでていた
　　原因：
　　　　　①WBSに漏れていたタスクがあった（PT環境準備・追加のPTテスト機能）
　　　　　　→なぜ①がもれたのか
　　　　　　リーダー担当部分のため、不明。
　　　　　　
　　　　　②PT準備時に時間に想定以上の時間を取られた
　　　　　　なぜ、想定以上の時間を取られたのか
　　　　　　→PT準備を細かく砕いたタスクを把握していなかった（どのような環境が必要なのか・障害表の管理の仕方・最低限動作に必要なマスタデータ）
　　　　　　 そのため、場当たり的にPT実施を止め、PTも必要な作業を実施してしまった
　　　　　　なぜPT準備の全容を把握していなかったのか
　　　　　　→経験不足。PT計画からPTに関わったことのあるメンバがいなかった。
　　　　　　　知見のある人は同時進行で進んでいたPT仕様書の作成で精一杯であった。
　　対策；
　　　　　①については、役割・立場では、対策をうてないため、省略
　　　　　②については、
　　　1.曖昧な作業項目は必ず細分化し、共有・確認すること
例えば、PT準備というタスクを降られたときに、今回のpjの場合なにを行わなければならないのか
を明確にする。切羽詰まっているときこそ、いったん俯瞰的にみることが、難しいけど大事
2.汎用的な作業項目は整理しておく
　例えば、PT実施前には、いかのような作業が必要だと思う（順不同、思いついたのをとりあえず）
　　・PT実施計画の作成
　　・テスト観点の明確化
　　・障害の管理方法の決定（周知方法・修正タイミング・資産反映タイミング）
　　・エビデンスの取得方法の決定
　　・テスト環境の準備（※ローカル端末で行うのであれば、マスタデータ・その他テスト実施者共通の設定などの共有）
　　などなど