◆はじめに
記事を開いていただきありがとうございます！
普段はQA業務を行っており、QA歴は4年目となります。
本記事では、タスク引継ぎの「前任者」と「後任者」どちらも経験した私の視点で
「タスク引継ぎを行う際に意識すること」をまとめようと思い、作成しました。
記事作成がまだ2回目なので、拙い箇所があると思いますがよろしくお願いします。
◆経緯
今年度、私は業務幅拡大に伴い、QA業務における引継ぎ作業を多数経験しました。
その際に自身が必要と感じた要素が3つありましたため、実例を添えて記事とさせていただきます。
◆必要と感じた3つの要素
①期限、範囲の明確化
「いつ」までに「どのレベルまで完了しているか」引継ぎする際に期限やタスクを細分化して段階を設けることが多いと思われます。
この状態で「引継ぎが完了している日時」のみ決めていると、そこで終わってしまい、中途半端な状態で引継ぎが行われる危険性があります。
特に、長期間を要する場合には、完了日だけでなく、「この日」までに「どのレベルまでこなせる様になっているか」をあらかじめ決めておくことで、形式だけの引継ぎだけでなく、後任者が自立してタスクを行える状態になりやすいと考えております。
▼実例
私がタスクを引き継がれる際、前任者と協議しつつ、徐々に移管していく形で行っていました。
恒常的に行っている検証タスクを引き継ぐ際、前任者と範囲のすり合わせが漏れていたものがあり、「引継ぎ済みのタスク範囲」の認識相違が起こっていました。
幸いなことに、検証箇所の重複確認や未検証の項目が出るなどの被害はありませんでした。
②タスクを行う理由の共有
引継ぎの際、疎かになる箇所だと考えております。
「なぜこのタスクが存在しているのか」を後任者に引き継ぎ、成り行きでタスクを消化していると、流れ作業になってしまい、ミスを誘発します。
事前に理由を共有することでミスを防ぐ側面もありますが、引継ぎ後に問題が発生した際に大きく状況が変わると考えています。
理由がわかっている場合、対処する箇所に見当がつきやすくなり、事前/事後対処を迅速に行えると考えます。
また、前任者がタスクを見つめ直す機会でもあると考えています。
▼実例
私が後任者に引継ぎを行った際、定常的に実施しているタスクの役割を共有しました。
仕様書をもとにマスターデータと比較する検証ですが、「何を」比較しているのか、「どこ」を見て確認しているのか具体的に共有を行いました。
実施中にNGが出た際にも「なぜ」NGが出ていて、どこが間違っているのかを紐解いて説明も行いました。
③イレギュラーの共有
事前にいくつかのイレギュラーや過去事例を共有しておくことによって、引継ぎ後のトラブルを未然に防ぐことができると考えております。
▼実例
例としては、過去の傾向をもとに仕様書とマスターデータで相違している場合に参照や修正対応を行う手順および相違している理由を引継ぎ時に共有しました。
◆実施結果
実際に3要素を取り入れて引継ぎを行い、以下のような結果を得ることができました。
①期限、範囲の明確化
・認識相違が発生した後日に再度すり合わせを行い、タスクの範囲を明確化することで引継ぎを無事に行えました。
・別タスクの引継ぎ時には「範囲」と「期限」を明確化していたこともあり、実施漏れが起こらずに済みました。
②タスクを行う理由の共有
・具体的に説明を行ったことが実を結んだのか、後任者のタスクへの理解が深まって来たため、効率化を提案できるところまで成長が見られ、引き継ぐ際に必要な要素だと痛感しております。
③イレギュラーの共有
・結果として、事前に共有を行ったイレギュラーは後任者のみで対応が可能となり、前任者の確認を必須とする期間を短縮することができました。
◆さいごに
引継ぎの手法として、私は「デリゲーションポーカー」や「マニュアルの作成」を行って来ましたが、これらに3つの要素を追加して行くことによって未然に防げるトラブルもありました。
手順が複雑なものや、「実際にやってみないとわからない」部分はタスクによって差があると考えていますが、同じような境遇の方に少しでも役に立つ記事となっていれば嬉しい限りです。