職場には、地味に危ない依頼の仕方がある。
こんな感じの情報で毎月送ってね
これである。
一見すると、普通の依頼に見える。
前月のサンプルがある。過去のデータもある。なんとなく形式も分かる。
だから作業者は、その雰囲気に合わせて毎月処理する。
しかし、この「こんな感じで」は、あとから問題になりやすい。
この項目、入れてないの？
今出して本当にいいの？
〇〇さんは違うって言ってたけど？
前はあったよね？
こうなると、作業者からするとこう思う。
知らんがな。
最初から項目と基準日と提出日を決めてくれ。
これは単なる愚痴ではない。
定型業務でよく起きる、かなり再現性の高い構造問題である。
「こんな感じ」は仕様ではない
「こんな感じで毎月送ってね」は、仕様ではない。
それはサンプルである。
雰囲気である。
過去の流れである。
仮運用である。
本当に仕様として扱うなら、少なくとも次のようなことを決める必要がある。
- 必ず入れる項目
- 任意で入れる項目
- 参照する元データ
- 何日時点のデータを使うか
- 何日に提出するか
- 変更があった場合に誰が判断するか
- 他部署から追加要望が来た場合の反映ルール
これが決まっていないなら、作業者は過去のサンプルをもとに「たぶんこうだろう」と処理するしかない。
その状態であとから、
これ入れてないの？
と言われても、それは作業者のミスとは限らない。
単に、仕様がなかっただけである。
3ヶ月何も言われていないなら、それは少なくとも黙認された運用である
ここで重要なのは、実際にその運用で何ヶ月も回っていた場合である。
たとえば、担当してから3ヶ月間、毎月月初に従業員名簿を提出していた。
その間、誰からも「出す時期が違う」「この項目が足りない」「この基準日では困る」とは言われていなかった。
この場合、後から急に、
16日発行分で出すから、1日の今出して本当にいいの？
と言われても、それは過去の作業ミスとは言い切れない。
なぜなら、3ヶ月間その運用で受領されていたからである。
もちろん、途中で他部署の使い方が変わったり、職位が必要だと分かったり、発行タイミングを見直したくなったりすることはある。
それ自体は悪くない。
ただし、それは「新しい要件が出た」という話である。
「今までの担当者が間違っていた」という話ではない。
3ヶ月間何も言わずに受け取っていたなら、少なくともその運用は現場上黙認されていた。
そのあとで必要な項目や提出時期を変えるなら、やるべきことは責めることではなく、仕様を更新することである。
問題は「職位を入れていないこと」ではない
たとえば、毎月発行する従業員名簿のような業務があるとする。
他部署から、
職位がないと分からないかもしれない
と言われた。
そこで、上司や担当者が作業者に、
これ、職位入れてないの？
と聞いてくる。
この時点で、話が少しズレている。
問題は、職位を入れていないことではない。
問題は、職位を必須項目として定義していなかったことである。
だから、本来の会話はこうでいい。
なるほど、今後は職位も必要なんですね。
では次回以降、項目に追加します。
これで終わりである。
未定義の項目が必要だと分かった。
では、今後の仕様に追加する。
ただそれだけの話である。
追加要望を「ミス発見ゲーム」に変換するな
業務では、あとから必要な項目が分かることがある。
それ自体は悪くない。
他部署が使ってみて、
職位もあった方が分かりやすい
基準日が分からないと確認しづらい
この項目もあると助かる
と気づくことは普通にある。
だから、本来の対応はシンプルでいい。
では次回から追加します
今回分も必要なら追加版を出します
今後はこの項目を標準にします
これでいい。
しかし、問題解決が苦手な職場では、これがなぜか「ミス発見ゲーム」に変換される。
なんで入ってないの？
今まであったのに
誰が違うって言ったの？
前の話と違うって言っていいの？
その指摘した人が間違っていたと言うのか？
違う。
論点が違う。
新しい要望が出たなら、仕様に足せばいい。
不足が見つかったなら、次回から標準化すればいい。
基準日が曖昧なら、決めればいい。
それだけである。
「指摘した人が間違っていた」と言う必要はない。
「作業者がミスした」と言う必要もない。
「前任者が悪かった」と言う必要もない。
必要なのは、今後の運用を決めることだけである。
決まっていないなら、決めるだけ
この手の話で一番大事なのはこれである。
決まっていないなら、決めるだけ。
職位を入れるか決まっていない。
では、入れるか決める。
1日時点のデータで出すのか、16日発行直前のデータで出すのか決まっていない。
では、基準日を決める。
毎月何日に提出するのか決まっていない。
では、提出日を決める。
他部署から追加要望が来たときの扱いが決まっていない。
では、反映ルールを決める。
これだけである。
それを、
誰がそう言ったのか
前と言っていることが違うのか
これはミスなのか
なぜ入れていなかったのか
誰の認識が間違っていたのか
という話にすると、一気に無駄な会議になる。
これは問題解決ではない。
未定義を放置したまま、責任の置き場所だけ探す作業である。
過去の資料を掘るなら、目的を決めるべき
こういう場面で、過去の資料を掘り始める人がいる。
過去の名簿はどうだった？
前は職位が入っていた？
いつから抜けた？
誰の時から変わった？
もちろん、過去資料を見ること自体が悪いわけではない。
過去資料を見る目的が、
今後の標準項目を決めるため
過去との違いを把握するため
他部署が何を見ていたか確認するため
なら意味がある。
しかし、目的が、
誰が抜かしたのか
誰が間違えたのか
指摘した人が正しいのか
作業者がミスしたのか
になっているなら、それはほぼ無意味である。
それは業務改善ではなく、責任採掘である。
過去を掘っても、今月の名簿に職位が必要かどうかは決まらない。
過去を掘っても、基準日が1日なのか16日なのかは決まらない。
過去を掘っても、今後の提出日ルールは自然には生まれない。
過去確認は、仕様を決める材料として使うなら有効。
犯人探しに使うなら無駄。
ここを分けないと、定型業務は永遠に不毛になる。
「誰が悪いか裁判」にすると仕事が止まる
この手の職場では、問題が出たときにすぐ裁判が始まる。
誰がそう言ったのか
前任者はどうしていたのか
指摘した人が間違っていたのか
作業者が確認不足だったのか
どちらの認識が正しいのか
もちろん、重大事故や法令違反なら原因究明は必要である。
しかし、毎月の名簿項目のような定型業務で、追加項目が出てきただけなら、そこまでの裁判は不要である。
必要なのは、次の一言である。
では、今後は職位も標準項目に入れます。
これでいい。
必要なら追加で、
基準日は毎月1日時点でよいですか。
16日発行分として、提出日は毎月何日までにしますか。
と確認すればいい。
これが仕事である。
「誰が悪いか」を探すより、「次からどうするか」を決める方が100倍早い。
雰囲気要件は、後出し採点を生む
「こんな感じで」という依頼の怖さは、あとから採点できてしまうところにある。
最初に明確な項目表がない。
基準日もない。
提出日も曖昧。
元データも変わる。
でも、成果物だけは毎月出てくる。
すると、あとから見る人は言える。
この項目がない
前と違う
今出していいの？
別の人は違うと言っていた
しかし、それは成果物だけを見て採点しているだけで、依頼時点の曖昧さを見ていない。
もし最初に、
従業員名簿は、氏名・所属・職位・入社日を必須項目とする
データ基準日は毎月1日時点とする
提出日は毎月10日までとする
16日発行分に反映する
と決まっていたなら、話は簡単である。
その仕様から外れていれば、作業ミスと言える。
しかし、最初に「こんな感じで」としか言われていないなら、後から必須項目扱いするのは危ない。
それは仕様違反ではなく、仕様未定である。
元データが変わるなら、基準日を決めないとブレる
名簿のような業務では、元データが変わる。
職位が変わる。
所属が変わる。
入退社がある。
氏名や表記が変わる。
発行時点によって情報が変わる。
だからこそ、「何日時点の情報で出すのか」が重要になる。
1日時点のデータで出すのか。
16日発行直前のデータで出すのか。
依頼が来た時点のデータで出すのか。
人事発令が反映された時点で出すのか。
これを決めずに、
1日の今出して本当にいいの？
と聞かれても、作業者は困る。
それは作業者の判断力の問題ではない。
基準日が決まっていないだけである。
基準日がない業務は、毎回ブレる。
ブレたあとに怒るのではなく、先に基準日を決めればいい。
改善するなら、項目・基準日・提出日を固定する
この手の業務を安定させるには、難しい改革はいらない。
次の3つを決めるだけで、かなり楽になる。
1. 項目
例：
- 氏名
- 所属
- 職位
- 社員番号
- 入社日
- 必要に応じた備考
何を必須にするのか。
何を任意にするのか。
他部署が見るために必要な項目は何か。
これを決める。
2. 基準日
例：
- 毎月1日時点
- 毎月15日時点
- 発行日前営業日時点
- 人事発令反映後時点
元データが変わるなら、基準日がないと必ずズレる。
3. 提出日
例：
- 毎月10日までに提出
- 16日発行分に使うため、毎月〇日締め
- 休日の場合は前営業日
提出日が曖昧だと、「今出していいのか」問題が毎回出る。
つまり、必要なのは気合いではない。
仕様である。
実務で使える返し方
項目追加の要望が出たとき
なるほど、今後は職位も必要なんですね。
では次回以降、項目に追加します。
今回分も必要であれば、職位入りで再作成します。
3ヶ月同じ運用で何も言われていなかったとき
これまで3ヶ月間、月初提出で運用しており、特に指摘はありませんでした。
今後、16日発行分として基準日や提出時期を変更するのであれば、次回以降の標準として決められればと思います。
必須項目が曖昧だったとき
これまで具体的な必須項目の指定はなかったため、サンプルベースで作成していました。
今後は職位を含める形で運用します。
発行タイミングを確認されたとき
16日発行分として、何日時点のデータを使うか決めておけると認識違いが減ると思います。
毎月1日時点でよいか、発行日前時点にするか確認させてください。
誰が間違っていたかの話になりそうなとき
誰かが間違っていたというより、これまで項目や基準日が明確に決まっていなかった認識です。
今後の標準として、職位を含めるか決められればと思います。
この返し方のポイントは、責任追及に乗らないことだ。
「誰が悪いか」ではなく、「次からどうするか」に戻す。
まとめ：雰囲気で頼むなら、後から採点するな
「こんな感じで毎月送ってね」は、便利な言葉である。
でも、そのまま運用すると、あとから揉めやすい。
項目が決まっていない。
基準日が決まっていない。
提出日が決まっていない。
元データは変わる。
他部署の要望も変わる。
それでも、3ヶ月間何も言われずに受領されることもある。
この状態で、あとから「これ入れてないの？」と責めるのは危ない。
必要な項目が出てきたなら、追加すればいい。
基準日が曖昧なら、決めればいい。
提出日が曖昧なら、固定すればいい。
それだけの話である。
未定義を見つけたら、責任者探しではなく仕様決めをする。
それが仕事である。
追加要望が出た
じゃあ入れますね
で終わる話を、
誰が悪い？
ミスなのか？
前と言っていることが違うのか？
指摘した人が間違っていたと言うのか？
に変換しない。
それは仕事ではなく、猿裁判である。
定型業務に必要なのは、声圧でも責任採掘でもない。
項目・基準日・提出日の明文化である。
