通常業務と並行して1000件近い確認作業の納期を守る

当社製品をご利用のお客様の移行作業に関するコンサルティングサービスの中で、当社側で定義ファイルの妥当性に関する確認作業を行うプロジェクトが立ち上がりました。実際にお客様から定義ファイルをいただき確認したところ、1000件近い確認が必要であることが分かりました。

通常業務には支障を出さず、効率的に確認作業を進めて期間内に作業を終わらせる必要がありました。
このように限られた期間内で大量の作業を完了させた際の進め方をご紹介します。

なお、この記事はチュートリアルの情報をご存知の方を対象にしています。

概要

確認作業について

このプロジェクトはカスタマーサポートのチームが主体となり、技術部やコンサルティング本部と協働しながら進めました。この内、カスタマーサポートが Placul を用いてどのように確認作業を進めたのかについてご説明します。

必要な確認作業は大分類のレベルで11件あり、確認項目としては1000件近くありました。また、大分類ごとにお客様ご希望の納期があるため、実質的には一週間ごとに作業を完了させ続ける必要がありました。

1つの確認項目に対して10分程度はかかる想定であったため、翌週以降の先行対応も考慮して以下の体制で進めることにしました。

役割と人数	主な作業内容
作業者（5名）	定義の妥当性を確認する実作業を担当する
承認者（2名）	作業者が確認した結果をレビューし、お客様へ提供可能な状態か判断する

進め方について

確認項目の分量が多いため、最初にどのように進めるかについて話し合いました。

この確認作業は日々の製品サポート業務には影響を出さないことを前提としています。サポート業務はお客様からのお問い合わせの量に依存するため、作業者は毎日同じだけの確認作業をできるとは限りません。

事前に担当を割り当てた場合、担当者がお問い合わせ対応などで作業できない時が続いてしまうと、担当の再割り当てなどのスケジュール調整が都度必要になってしまいます。今回のケースでは事前に担当を割り当てるのは適さないと考えました。

実施した進め方の概略は下図の通りです。作業者自身が実施するタスクを自分に割り当て、確認作業を実施するという流れを繰り返す形です。

この方法の場合は手の空いた人が作業を進めていくことになるので、再スケジュール調整は不要になります。その代わり残作業がどれくらいあるかを把握し、現状のペースで終わりそうなのかどうかを判断することが重要になります。

構成

ここからは実際の作業を模したダミーデータを用いて、どのような構成で作業を進めたのかについて説明します。

Placul では「チーム」と「フォルダー」、「タスク」を用いて作業を管理します。Placul のタスクやタスクノートについては、「タスクを作成してみよう」や「タスクノートを使ってみよう」をご参照ください。

これらの要素を、今回は以下のように扱うと決めました。

要素	説明
チーム	部署を横断して、関係するメンバーを集めて新規に作成
フォルダー	納期ごとに分けて作成（前述の「大分類」と一致）
タスク	確認対象の定義ファイル内の分類単位で分ける（「タスクの構成について」にて後述） 各確認項目は、タスクノートのマイクロタスクとして作成

以降ではそれぞれの要素をどのように利用しているのかを説明します。

チームの構成について

通常業務とは異なり複数の部署にまたがることになるため、Placul に「〇△社向け特命プロジェクト」というチームを新設しています。チームのメンバーには実作業を行うカスタマーサポートのメンバーと、コンサルティング本部、技術本部のメンバーを入れています。

フォルダーの構成について

Placul を利用することの主目的は「お客様へ適切な時期に納品するためのタスク管理」です。しかしそれを運用するための情報や各種コミュニケーションがバラバラのツールに散在するのは好ましくないと考えています。

そのため事前準備として必要な作業や運用ルール、社内の打ち合わせ、お客様からの問い合わせなど、このプロジェクトに関連する情報をすべて格納できるようにしました。

実際に確認作業を行うタスクは、「確認対象（納期順）」というグループの中にフォルダーを作成し、納期ごとにタスクを管理できるようにしました。お客様への納品が終わったものについてはフォルダーの名称に ✅ をつけておくことで、フォルダーを開かなくても完了の判断ができるようにしました。

このような構成にすることで、以下のようなメリットがあると感じました。

● 一か所に情報を集めることで必要な情報を探しやすかった

確認作業以外の情報やコミュニケーションについても一か所に集まっているので、経緯や現状の共有や理解が早かったと感じました。特に、メールやチャットなどのコミュニケーションツールでは、一部の人の間だけでやり取りがされたり、後から参画した人が情報にたどり着けないことになりがちですが、そのようなことはありませんでした。

タスクの構成について

どのような単位でタスクを作成するかについては、運用上わかりやすい、作業しやすい単位で分割すればよいと考えています。

今回は確認対象の定義ファイルに含まれる「グループ」という単位で分割すると管理も作業もしやすいと判断したため、そのグループ名がわかるようにタスクを作成しました。

名称のカラムの左側にあるチェックマークが白いものは未完了で、青いものは完了のものです。デフォルトでは完了したものは表示されないため、画面に表示されているものが作業すべきタスクです。

右端の「ノート」については、タスク内にあるマイクロタスクの数と、完了数を表しています。

つまりフォルダーを開いてタスクの一覧を表示した際に以下のように判断できます。

状態	判断基準
未着手	担当者が未設定
着手中	担当者が設定されている ノート列の完了数を見ることで、確認の進捗状況も判断できる
完了	表示されていない

このような構成にすることで、以下のようなメリットがあると感じました。

● 全体の残作業数を把握しやすい
● 誰が作業に着手できているのかがわかる（誰の手が空いているかがわかる）

次回の納品までにどれくらいのタスク、マイクロタスクが残っているのかを、フォルダーを開くだけで把握できるのがわかりやすく手間もありませんでした。

最終的にすべての確認作業が終わった時には、以下のように一覧には何も表示されなくなるため、この状態を目指して作業をしました。

タスクの内容

この作業は同じ確認を大量に実施するため、確認のルールなどは別途運用を決めて整理しておき、各タスクには記載しないようにしました。

実際には下図のように、確認対象のファイルが配置されている共有ドライブへのリンクを記載するだけです。

確認項目はノートにマイクロタスクとして作成します。今回はユーザーという単位で確認をする必要があったため、それが判断できる情報をマイクロタスク名に指定しています。こちらも必要最低限の情報のみを記載するようにしました。

マイクロタスクについては担当者を設定しない運用も考えられるのですが、以下の2点から担当者を設定することにしました。

● 作業者が担当者であれば、確認作業を実施中と判断できる
● 承認者が担当者であれば、結果のレビュー中と判断できる

また、Placulのタスク／マイクロタスクの結果欄は「現在の状態」を表すことも想定しているため、業務や運用に合わせた状態の共有をするために結果欄を使うことができます。今回は以下のように運用するようにしました。

結果欄に書く内容	意味
レビュー依頼	作業者による確認が完了したため、承認者によるレビューを依頼した
レビュー完了	承認者によるレビューが完了した（これ以上の作業はない）

承認者への申し送り事項や作業者へのフィードバックがあるときは、マイクロタスクのコメントを使ってやり取りすることにしました。これらを結果欄に書くこともできますが、運用ルールとしてはシンプルにしておきたかったためです。ルールに決められていないことは、縛りを設けずにコメントでコミュニケーションをとることで、意思の疎通を図りながら作業を進められました。

具体的なコメントのやり取りについては「補足：運用」の箇所で説明します。

このような構成にすることで、以下のようなメリットがあると感じました。

● 作りこみをせずにシンプルにタスクの割り当てや状況の可視化ができた
● マイクロタスクのコメントを使うことで、作業とコミュニケーションが一か所にまとまった
　　〇 質問する側としてはどこで聞けばよいのかを悩まなくなる
　　〇 作業とそれに関するやり取りが残るので、作業の引継ぎ時に経緯が把握しやすかった

まとめ

当初はスプレッドシートで進めることも考えましたが、大きくは以下の理由から断念しています。

● 作業状況の進捗を確認するための作りこみが必要になる
● コミュニケーションを取るのに別のツールが必要になる

特に後者は、別のツール上で「ここの作業が終わりました」のように連絡をする必要があり、手間もかかる上にミスも発生しやすいと考えました。また、スプレッドシートとコミュニケーションツールが分かれてしまうので、スプレッドシートに記載されている結果に対して「そのような判断に至るやり取り」が残らないのも問題でした。

Placul を用いて管理をすることによって、以下のようなところが良かったと感じています。

● 運用方法をゆるく決めるのみで、作りこみをしなくてもすぐに作業を開始できた
● タスクやマイクロタスクの状態から、現在の進捗状況が一目でわかった
● リアルタイムにデータが同期されるので、誰かが割り当てたことに気づかずタスクの担当者を上書きしてしまうことがなかった
● 作業しているタスクのコメントを自由に使えるようにしたのでコミュニケーションコストが下がり、また情報がタスクに関連付いて残るようになった

以上が、通常業務と並行して1000件近い確認作業の納期を守る例でした。
この利用例を通して、Placul 活用の一助になると幸いです。

以降は補足として、作業の流れを説明しております。

補足：運用（作業の流れ）

ここまで説明してきた確認作業をどのように進めていたのかを、一つのタスクを例にとって作業の流れをスクリーンショット付きで説明します。これはあくまで今回このように運用したというものであり、こうすべきというものではありません。Placul 利用時の参考になればと考えます。

なお、一つのタスクを完了させるまでには、「作業者が確認をする → 承認者がレビューをする」というステップを踏むため、節のタイトルに「作業者」か「承認者」かがわかるように含めています。

（作業者）タスクを割り当て、内容を確認する

締め切りが近いタスクの中から、担当者が未設定のタスクを探して開きます。「私に設定」のリンクをクリックすると、操作者自身が担当者になります。

このとき作業を進める前に内容を確認します。不明点があるなら、タスクのコメントを使って承認者とコミュニケーションをとって疑問点を解消します。

（作業者）確認作業をし、承認者にレビューを依頼する

ノートを開き、作業対象のマイクロタスクに自身を割り当てて作業を開始します。割り当て方はタスク側と同じです。

確認作業が終わったら、担当者を未設定にしてから「結果」に「レビュー依頼」と記載します。その後にメンションで承認者2名にレビューを依頼します。

レビューを依頼したら作業者は次のマイクロタスクの作業に移ります。

このようにして確認作業と依頼を繰り返し、承認者からの確認コメントがあればそれに対応してます。

（承認者）レビューを実施し、マイクロタスクを完了させる

作業者がレビュー依頼のコメントを行うと、承認者のインボックスにメンションの通知が届きます。

通知をクリックすると発生元のタスクを開くことができるので、承認者はタスクを探し出す必要はありません。

そのタスクから作業者が実施した内容の妥当性を確認します。

作業内容を確認して特に問題がなければ、結果欄に「レビュー完了」と記載してマイクロタスクを完了にします。

最終的にすべてのマイクロタスクが完了になったらそのタスク自身も完了とすることで、一つのタスクの作業が完了します。

なお、承認者が複数名いるため承認作業を同時に進めてしまう可能性があります。そのため作業者がタスクを割り当てるのと同様、承認作業をする際に自身を担当者に割り当てることで作業が重複するのを防ぐようにしました。

（承認者と作業者）作業内容に対して確認が必要なケース

たとえばやり直しが必要なケースであったり、作業順序を組み替えるためにペンディングするなどが想定できます。

結果欄で表すステータスを細かく規定することもできましたが、発生するかもわからないことに対してあらかじめ細かく規定することはしませんでした。

結果的には、タスクやマイクロタスクのコメント機能を使って、お互いにコミュニケーションをとることで問題なく作業を進められました。

たとえば承認者からフィードバックをするケースについては、以下のようなやり取りをするシンプルな形です。

Placul ではコメントをする際にメッセージタイプ（連絡や相談、感謝など）を指定できるため、それを活用することでどのような意図のコメントなのかが判断しやすくなります。

またコメントでメンションをすると相手のインボックスに通知が届きます。ここには自分が確認を必要とするものだけが届くため、メールのように連絡が埋もれてしまって対応が遅れてしまうということもありませんでした。

以上です。少しでも役立つ内容であれば嬉しく思います。