自動化前の業務トレース｜担当者の「開き直す・聞き直す」を1週間で記録する

担当者がメールを読み、台帳を開き、もう一度メールへ戻る。業務を自動化しようと隣で見ていると、「確認して入力する」という短い作業手順にまとめたくなります。しかし、戻った理由が添付資料の照合なのか、依頼者への聞き直しなのかで、引き継ぐべき条件は変わります。ここを推測で埋めると、必要な確認まで飛ばす処理を作りかねません。

業務トレースでは、実際に行った順序を追い、その場で使った情報と判断根拠を記録します。本記事では、最初の1週間を五営業日に分け、本人が読み返して直せる観察ノートを作る方法を提案します。説明用の題材は、社内申請を受け取り、台帳に登録して処理済みを知らせる作業です。月末など週内に現れない処理は、未確認として次の観察へ残します。

月曜：同じ画面に戻っても、ノートの行を消さない

最初に「申請を受け取ったところから、登録結果を依頼者へ知らせるところまで」と観察範囲を決めます。受領と完了の間に何を挟むかを見たいので、担当者には普段の順序で作業してもらいます。観察の目的、閲覧してよい資料、録画する場合の対象と保存先も先に合わせます。記録対象の申請と無関係な画面まで集める必要はありません。

ノートには「メールを開く→台帳を開く→メールへ戻る→添付を開く」と、戻った動作もそのまま書きます。「入力ミスに気付いたのだろう」と考えても、動作の欄には入れません。別の質問欄に「なぜメールへ戻ったか」と残します。本人への確認前に順序を整えてしまうと、後から理由を尋ねる手がかりが消えるためです。

政府向けのデジタル庁の業務可視化の説明でも、まず現行業務について、担当、実施する時点、内容、順序などを見えるようにする考え方が示されています。観察ノートも、望ましい手順を書く前に、現在の作業をたどれる形にします。

手を止めた場面では、作業をしていない時間にも印を付けます。ほかの申請へ移ったのか、返信を待っているのか、資料を探しているのかは、その時点で分かる範囲だけ残します。入力操作だけを抜き出して自動化すると、照会への返事を待たずに台帳へ登録するような順序の逆転が起こり得ます。「止まっている理由」は削る前に確かめる対象です。

火曜：「内容確認」を、見たものと決めたことに書き分ける

翌日はメモを読み返し、「確認」「処理」「対応」といった言葉を具体化します。たとえば「申請内容を確認した」だけでは、何を比べ、どこで次へ進めると判断したかが読めません。「依頼本文の対象期間を添付資料と照合した。食い違いがあったため依頼者へ照会した」と分ければ、参照した情報と行動のつながりが残ります。

記録には、行を識別する番号、順番と時刻、見た資料、行動、本人の説明、残った質問、結果を置きます。そのうえで、情報の確かさを「観察」「本人説明」「未確認」に分けます。本人が後から説明した内容は重要ですが、その場で見たことと同じ扱いにしないほうが、次に何を確かめるかが分かります。次の表は、記録を直すときの記入例です。

場面	観察したこと	本人の説明	残す質問・結果
受付	依頼本文と添付を開いた	対象期間が一致するか見た	どの記載を照合したか確認する
照会	メールへ戻り返信を作成した	期間が違うので訂正を求めた	登録せず返信待ち
登録	台帳へ入力した	訂正版を受領してから入力した	訂正版の受領を確かめる行とつなぐ

Microsoftのタスク記録の準備手順では、細かく記録された操作を意味のある活動にまとめ、依存関係を考え、作業者や監督者の意見を取り入れる方法が説明されています。ノートもクリックを全部転記することを目的にせず、「照合する」「照会する」といった行動へまとめます。ただし、その中で何を根拠にしたかは省略しません。

時刻を残す場合は、手を動かした区間と返信を待つ区間を区切ります。「受付から登録まで」をひとまとめにして短縮対象とすると、入力を速くしたいのか、返事が来ない状況を変えたいのかが曖昧になります。途中で別の依頼を扱ったなら、その切替も記録します。作業の速さを評価する前に、何が起きていた時間かを読めるようにします。

水曜：「なぜ戻ったか」を本人に読み返してもらう

観察者がノートを読み上げ、担当者に順番と理由を直してもらいます。「この行では入力を間違えたのでメールに戻った、と理解しました。合っていますか」と聞くと、推測を確認できます。担当者が「入力前に添付の対象期間を見直した」と答えたら、行動の解釈を訂正します。黙って書き換えるだけでなく、何をどう直したかも残します。

訂正前の記録が「メールへ戻る」、訂正後の説明が「対象期間の再照合」なら、最初に見えた動作は維持できます。質問欄に確認日と確認した人の役割を添え、判断根拠の欄へ説明を追加します。この残し方なら、後から読む人は、観察者が直接見た部分と、本人への聞き取りで補った部分を区別できます。

理由を尋ねるときは、「いつもそうですか」だけで終えず、「何が一致していれば進めますか」「一致しないときはどこで止めますか」と聞きます。「経験で分かる」という返事なら、見ている記載や照合先をさらに確かめます。それでも言葉にできない条件は、未確認のまま残します。観察者がもっともらしい基準を作って埋めると、本人も気付きにくい誤りになります。

海外メーカーStoneridgeについて、UiPathが公開する工程記録の事例では、買掛業務などを対象に、作業のステップと進み方の違いを記録したことが紹介されています。本記事で参考にするのは、一本のきれいな流れに丸めず、違いを残す点です。海外の事例や製品文書にある運用を国内で使う際は、労務、承認権限、情報管理の制度・規程が異なるため、自組織のルールを確かめます。

木曜：「いつもは違う」を、未観察の別メモにする

通常の順序が読めたら、「同じ依頼が再送されたら」「途中で取消が来たら」「添付が足りなかったら」と、違う進み方を聞きます。この日に実際に起きたことと、担当者が過去の対応方法として説明したことを分けて書きます。観察していない経路を、通常の手順へ混ぜて確定しないことが大切です。

例外のメモには、発生条件、止める位置、照会する相手、再開できると判断する情報、戻る行を置きます。重複依頼なら「同じように見える」だけでは足りず、何を比べて同一と判断するかを聞きます。取消なら、登録前と登録後で扱いが変わるかを確かめます。答えが出ない欄は「担当者へ確認中」とし、次に尋ねる相手を決めます。

週内に起きなかった月末処理や、別の担当者だけが行う確認も別メモへ入れます。「見なかった」と「存在しない」は区別します。次の観察日が必要なら予定を置き、実際の記録が残っているなら閲覧可能な範囲で照合します。何も確認できなければ、その経路の判断を今回の自動処理へ含めないと明記します。

記録の収集や整理にはAIの活用も考えられます。NECの2025年12月3日の発表は、ブラウザの閲覧・操作履歴からノウハウを抽出・蓄積する仕組みと、企業のルールやポリシーを考慮した動作設定・運用を説明しています。記録を活用する技術と、その組織で許される処理を確かめる作業を、併せて考える参考になります。

観察ノートの整形をAIに任せる場合は、入力にある「未確認」を維持し、不明な判断理由を補わないよう指定します。出力と元の行を照合し、本人の説明にない分岐が増えていたら戻します。読みやすい文章になったことと、担当者が内容を確認したことは別です。確認していない記録を、整形しただけで確定版へ変えないようにします。

金曜：次の人が説明できるノートになったか確かめる

最後は担当者本人に加え、登録結果を受け取る人にもノートを読んでもらいます。「何が渡ってきたら、自分の作業を始められますか」と尋ね、台帳の登録だけで足りるのか、通知や添付資料も必要なのかを確かめます。作業者が終わったと思う場所と、次の人が受け取れる場所が一致しているかを見る確認です。

引き渡す前に、ノートだけで「どの資料を見るか」「何を根拠に先へ進むか」「止めた後に誰へ聞くか」を説明してもらいます。説明できない行があれば質問欄へ戻し、観察済みの範囲と未確認の範囲を分けます。録画や資料への参照を添える場合も、読む人に閲覧権限があるかを確かめます。誰でも見られる場所へ原本を複製して解決しないようにします。

renueが重視するのは、前の作業で得た情報と次の作業へ渡す条件を言葉にしてから、AI化や効率化へ進むことです。開き直しや聞き直しにも、後の処理を成立させる理由があるかもしれません。理由が確認できた行から実装へ渡し、判断が不明な行は人への照会に戻す。この線引きまで書ければ、観察ノートは開発担当者と話せる材料になります。

現場の理解を開発へつなぐ考え方は、renueの要件定義と実装を並行する開発モデルにも関わります。ノートを引き継ぐときは、完成した説明だけを渡さず、確認が済んでいない行と次に聞く相手も添えます。そこを見える形で渡すことが、仕様に推測を混ぜないための準備になります。

この記録を使って試行の予定を組む際は、導入検証を週単位の計画へ落とす進め方と接続できます。対象が会議後の登録や報告なら、タスク抽出・課題検出・進捗報告の工程を検討する前に、それぞれの入力と確認者をノートへ置きます。最初の1週間で目指すのは、すべてを自動化することよりも、担当者と次工程の人が同じ根拠をたどれる記録を残すことです。