先日、こんなことがありました。
後輩が担当している作業が、いつまで経っても「完了報告」を上げてこないのです。納期は迫っているのに音沙汰なし。心配になってこちらから進捗を聞くと、案の定、ほとんど進んでいませんでした。
詳しく聞いてみると、その後輩はテストケース表を作成している最中とのこと。私はレビュー担当だったので、いくつか質問を投げかけました。ところが返ってきた答えは「わからない」「知らない」の連発。どうやら、実際にテストをするイメージがまったくできていなかったようです。
その状態でテスト作業に入った結果、案の定、途中で完全に手が止まってしまいました。結果、稼働が大幅に膨らみ、さらにヘルプとして別のメンバーの工数を割くことに…。現場のスケジュールはさらに圧迫され、負の連鎖が起きてしまったのです。
なぜこんな事態になったのか？
原因は明確でした。
「作業の全体像やゴールをイメージしないままスタートしてしまった」
これに尽きます。
テストケース表の作成は、単に項目を書き出すだけではありません。
実際のテスト作業を想定しながら、どう進めるのか、どんな結果を期待するのかを頭の中でシミュレーションする必要があります。
その準備がないまま始めてしまうと、いざ現場で「どうやるんだっけ？」と迷い、手が止まり、質問や確認の時間ばかりが増えてしまうのです。
見切り発車を防ぐための3つのポイント
今回の出来事を振り返って、「これは最初にやっておくべきだった」と感じたことを3つ挙げます。
1. ゴールを明確にする
作業の目的や最終的な成果物の形をはっきりさせること。
「このテストケース表を誰が、何のために使うのか？」が理解できていれば、作成の方向性がブレません。
2. 手順をざっくり書き出す
頭の中だけで進めようとせず、紙やツールにざっくりした流れを書き出す。
「テスト環境準備 → データ投入 → 手順実行 → 結果記録」のように大まかでOKです。
3. わからない部分を事前に質問する
作業前に疑問点を洗い出して、先輩や関係者に質問しておく。
「この機能の仕様は？」など、始めてから聞くのでは遅すぎます。
まとめ：最初の10分が後の数時間を救う
仕事はスピードも大事ですが、イメージがないままのスピードは暴走です。
最初の10分でゴールと手順をイメージし、疑問点を潰しておけば、後の数時間を節約できます。
今回の件では、私も事前に「作業のイメージはできていますか？」と確認すべきだったと反省しました。
後輩のためにも、そしてチーム全体のためにも、見切り発車を防ぐ文化を根付かせていきたいと思います。
コメント