「その資料みたいにしといて」が事故る理由
職場でよくある指示に、こういうものがあります。
その資料みたいにしといて。
一見、分かりやすそうに見えます。
参考資料がある。
見本がある。
それに合わせればよい。
しかし、実務ではこの指示がかなり事故ります。
特に危険なのは、元データや仕様ではなく、加工後の完成リストだけ渡されるケースです。
完成リストだけ見せられて、
これみたいにして。
と言われる。
しかし、そのリストがどう作られたのかは分からない。
どの元データを使ったのか。
どの列を削ったのか。
どの列を追加したのか。
どの項目を変換したのか。
どの基準日で切ったのか。
未確定者を含めたのか。
どの部署が何に使うのか。
ここが分からないまま、見本だけ渡される。
そして後から、
この列がない。
中身が分かっていない。
後工程を理解していない。
ただ写しているだけ。
姿勢が足りない。
と言われる。
これは、担当者の理解不足ではありません。
指示側が、仕様・列・定義・加工ルールを渡していないだけです。
加工後リストは仕様書ではない
加工後のリストは、成果物です。
仕様書ではありません。
もちろん、見本としては役に立ちます。
しかし、見本リストだけでは分からないことが多すぎます。
たとえば、次のようなことです。
- 元データは何か
- どの項目を正としているか
- どの列を必須にしているか
- どの列を省略しているか
- 表記を変換しているか
- 変換しているならルールは何か
- 未確定情報を含めているか
- 基準日はいつか
- 後工程は何に使うか
- 次回以降も同じルールなのか
これらが分からない状態で、完成リストだけ渡されても、担当者は推測するしかありません。
推測で作れば、後出しで詰められます。
元データどおり作れば、「中身を理解していない」と言われる。
見本に合わせて勝手に加工すれば、「なんで勝手に変えた」と言われる。
これが、加工後リスト丸投げ指示です。
「フォーマットを合わせる」と「中身を合わせる」は違う
「その資料みたいに」と言われたとき、まず分けるべきなのはこれです。
フォーマットを合わせるのか。 中身を合わせるのか。
フォーマットを合わせるとは、たとえば次のことです。
- 列の順番
- 見出し
- 表の体裁
- ファイル形式
- 並び順
- 提出形式
一方で、中身を合わせるとは、次のような話です。
- データ定義
- 種別名
- 対象者の範囲
- 参照元
- 未確定情報の扱い
- 基準日
- 後工程で必要な粒度
- 表記変換ルール
この2つは別です。
ところが、曖昧な指示ではここが混ざります。
最初は、
他部署とフォーマットを合わせて。
という話だった。
だから担当者は、見本リストに合わせて列構成や見た目を整える。
しかし後から、
この組織の種別は何？
会社内では従業員なのに、派遣って書いてあるけど。
こういう中身も考えて。
と言われる。
これは、フォーマットの話ではありません。
データ定義の話です。
データ定義を変えるなら、最初からそう言う必要があります。
「もともとない列」を後から責めるのはおかしい
特に理不尽なのが、見本資料にも元データにもない列について、後から責められるケースです。
たとえば、加工後リストを渡されて、
これみたいにして。
と言われた。
そのリストには、ある列がない。
だから同じように作った。
すると後から、
この列がない。
なんで入っていないの？
後工程を分かっていない。
気づけないの？
と言われる。
これはかなりおかしいです。
もともと見本にもない。
元データにもない。
追加指示もない。
必要な理由も説明されていない。
誰が追加判断するかも決まっていない。
それなのに、後から「なぜないのか」と詰める。
これは、担当者の理解不足ではありません。
必要な列を定義していないだけです。
本当にその列が必要なら、指示側が最初に言うべきです。
今回は見本にない列も追加してください。
追加する列はA、B、Cです。
参照元はこの資料です。
後工程で使うため必須です。
ここまで言えばよい。
それを言わずに、後から「列がない」は、ただの後出し採点です。
ラベルを付けるなら、列なし後出し詰めです。
元データが他部署作成なら、勝手に直す方が危ない
元データを他部署が作成している場合、担当者が勝手に表記を変えるのは危険です。
たとえば、元データに「派遣」とある。
担当者が気を利かせて「従業員」に変える。
すると、後でこうなり得ます。
- 元データと出力リストが一致しない
- 他部署は「派遣」という表記に意味を持たせていた
- 後工程で集計がズレる
- 「誰の判断で変えたのか」と言われる
- 次回以降、担当者ごとに判断が変わる
- 標準化できない
つまり、勝手に直すことが仕事ではありません。
むしろ、データ業務では、勝手に直さないことが品質管理になる場面があります。
正しい対応はこうです。
現状は他部署作成の元データを参照しているため、種別名称は元データどおり反映しています。
出力リスト上で別名称にする必要がある場合は、元データ側の定義または出力時の変換ルールを決める必要があります。
これで十分です。
「ただ写しているだけ」は仕事ではない、のズレ
「ただ写しているだけは仕事じゃない」
この言葉にも、半分正しい部分はあります。
たしかに、何も考えずに転記するだけなら改善余地があります。
しかし、ここで言う「考える」とは、勝手にデータを直すことではありません。
本当に考えるべきことは、次です。
- 元データを正とするのか
- 出力時に変換するのか
- 変換するならルールは何か
- 表記が変な場合、誰に戻すのか
- 後工程ではどの項目が必要なのか
- 見本にない列を追加するのか
- 次回以降も同じ処理にするのか
ここまで整理することが仕事です。
そして、整理した結果、
これは自分が勝手に決める話ではない。
定義者・判断者に決めてもらう必要がある。
となることもあります。
これも、考えた結果です。
考えていないのではありません。
考えたうえで、決定権限を分けているのです。
「理解不足」「姿勢不足」に飛ばすのがゴミ
この手の話で一番ストレスになるのは、論点がすぐ人の能力や姿勢に飛ぶことです。
- 理解不足
- 姿勢不足
- 後工程を分かっていない
- ただ写しているだけ
- 自分で考えていない
- 気が利かない
こう言われると、担当者側はかなり不快です。
なぜなら、実際には理解していないのではなく、理解したうえで、これは自分が勝手に決める話ではないと切り分けているからです。
これはかなり違います。
担当者が見ているのは、
- 何が未定義か
- 何を決める必要があるか
- 誰が決めるべきか
- 勝手に変えると何が起きるか
- 標準化するには何を固定するか
です。
それを「理解不足」「姿勢不足」と処理するのは、かなり雑です。
もし本気で「担当者が勝手に判断して直せばいい」と思っているなら、理解不足なのは担当者ではありません。
データ定義・変更権限・後工程の利用目的を分けられていない側です。
これは、理解不足ロンダリングです。
本当は定義不足なのに、担当者の理解不足に見せているだけです。
「考えろ」と「勝手に変えるな」のダブルバインド
この構造で一番きついのは、ダブルバインドです。
考えろ。
でも勝手に変えるな。
気を利かせろ。
でも元データと違うことをするな。
後工程を理解しろ。
でも後工程の条件は決めていない。
標準化しろ。
でも例外はその場で拾え。
これは無理があります。
担当者が勝手に変えれば、
なんで勝手に変えたの？
と言われる。
元データどおりにすれば、
ただ写しているだけじゃ仕事じゃない。
と言われる。
見本にない列を追加しなければ、
中身を理解していない。
と言われる。
見本にない列を勝手に追加すれば、
なんで勝手に列を増やしたの？
と言われる。
これは、担当者の理解力の問題ではありません。
変更ルールと判断者が未定義なだけです。
内定確定・入社予定者をどう扱うかも、基準日を決める話
同じように、入社予定者や内定承諾予定者の扱いも、担当者の気配りで処理する話ではありません。
たとえば、
- 明日、内定承諾するかもしれない
- 決まれば9日入社かもしれない
- まだ関係者には連絡していない
- 今週中には回答があると思う
- その情報を今回のリストに入れるか迷う
このようなケースです。
ここで担当者が、毎回メールを見て、未確定情報を拾い、入れるか入れないか判断する運用にすると、属人化します。
本来は、こう決めるべきです。
月初5営業日時点で、元資料に反映済みの確定データを対象とする。
または、
基準日以降に確定したものは、関係部署に同報されているメールをもとに、必要部署側で個別対応する。
翌月リストで正式反映する。
これなら、担当者の気配りに依存しません。
基準日を決めれば、漏れや判断ブレが減ります。
「メールを見て追加すればいい」は属人化する
「あるかわからない情報を、担当者がメールを見て追加すればいい」
これはかなり危険です。
一見、柔軟な対応に見えます。
しかし実態はこうです。
- 担当者がメールを常時監視する
- 未確定情報も拾う
- 元データ未反映でも気づく
- 入れるか入れないか判断する
- 後工程の必要性を察する
- 漏れたら担当者の確認不足になる
これは属人化です。
標準化の逆です。
同じメールが関係部署にも届いているなら、基準日以降の情報は、必要部署側がそのメールを見て個別対応する方が自然です。
月次リスト側は、基準日時点の確定データを出す。
それ以降の変動は、個別対応または翌月反映。
この分担にした方が、責任範囲が明確になります。
「その資料みたいにしといて」は、こう分解するべき
「その資料みたいにしといて」と言うなら、最低限、次を決めるべきです。
1. 見た目を合わせるのか
- 表の形
- 色
- 見出し
- レイアウト
- ファイル形式
2. 列構成を合わせるのか
- 列の順番
- 列名
- 必須項目
- 不要項目
- 見本にない列を追加するか
3. データ定義を合わせるのか
- 種別名
- 雇用区分
- 組織区分
- 入社日
- 在籍判定
- 対象者の条件
4. 基準日を合わせるのか
- 月初5営業日
- 16日まで
- 前月末時点
- 元資料反映済み時点
- 入社書類到着後
5. 参照元を合わせるのか
- 元資料
- メール
- 人事システム
- 他部署リスト
- 入社書類
6. 例外処理を合わせるのか
- 未確定者
- 入社予定者
- 書類未着
- 元資料未反映
- 緊急追加
これを決めないまま「その資料みたいに」は、かなり弱い指示です。
実務で使える確認文
こういう場面では、口頭で戦うより、画面に確認事項を出した方がよいです。
たとえば、こうです。
確認です。
今回「その資料みたいに」とのことですが、合わせる対象は以下のどれでしょうか。
- 見た目・レイアウト
- 列構成・項目名
- データ定義・表記
- 基準日・対象範囲
- 例外処理
現状は元データどおり反映しています。表記変更や列追加が必要な場合は、変換ルール・追加列・判断者を決めてから対応したいです。
月次リストなら、こうです。
次回以降は、月初5営業日時点で元資料に反映済みの確定データを対象としてリスト作成する形に統一したいです。
内定承諾予定・入社予定・元資料未反映の情報については、関係部署にも同報されているメールをもとに、必要部署側で個別に確認・対応いただく運用がよいと考えています。
未確定情報を月次リスト側で都度拾う形にすると、反映漏れや判断基準のばらつきが出るため、標準化しづらくなります。
これで、論点がかなり整理されます。
口頭で話すたびにストレスなら、画面に喋らせる
この手の話は、口頭でやるとストレスが大きくなります。
なぜなら、すぐに話がズレるからです。
- 理解不足にされる
- 姿勢不足にされる
- 後工程を分かっていないと言われる
- 「考えるのが仕事」と言われる
- その場で例外を足される
- 感情的な言い方になる
- 決定権限が曖昧なまま進む
こういう相手には、画面の文章に喋らせた方がよいです。
口で説明するのではなく、確認事項を見せる。
「話す」ではなく、読み上げる。
これで、相手の論点ズラしを減らせます。
自分のMPも守れます。
まとめ：「その資料みたいに」は、指示ではなく未定義の塊
「その資料みたいにしといて」は、かなり危険な指示です。
参考資料を渡すこと自体は悪くありません。
しかし、どこを合わせるのかを決めないと、後出し採点になります。
見た目なのか。
列構成なのか。
データ定義なのか。
基準日なのか。
参照元なのか。
例外処理なのか。
ここを決める必要があります。
加工後リストだけ渡して、後から「列がない」「中身を分かっていない」「姿勢が足りない」と詰めるのは、かなり無理があります。
必要な列があるなら、最初に言う。
表記変換が必要なら、ルールを決める。
元データと違う処理をするなら、判断者を決める。
未確定情報を含めるなら、基準日と例外処理を決める。
これだけです。
ラベルを付けるなら、こうです。
その資料みたいにしといて問題。 加工後リスト丸投げ指示。 見本資料ロンダリング。 列なし後出し詰め。 理解不足ロンダリング。 姿勢不足ロンダリング。 未定義の責任転嫁。
必要なのは、担当者の気合いではありません。
必要なのは、定義です。
