「ちゃんとやってくれよ」と思った仕事を、モデル化してみた
今日は自分の周りで先日起こった「やや腹立たしい」出来事を、IT&Scienceの考え方で整理してみたらどうなったか、ということをお伝えします。
「これ、最後までお願い」と頼んだハズの仕事
先日、上司から資料更新を依頼されました。
更新箇所は8か所。資料には「どこをどう直すか」は書いてあります。ただ、細かい指示が多く、全部を読み解くにはそれなりに時間がかかる。
ちょうど自分が忙しかったので、私はAさんにお願いしました。「これ、提出可能な形までお願いします」そんな気持ちでした。
Aさんは、更新内容を把握している5人に依頼してくれました。
が、その依頼は元の資料をそのまま転送しただけー
そして、提出日になった
依頼された5人は、それぞれ自分なりに資料を読み解いて更新してくれました。
そして提出日。私が最終確認すると、更新している場所が人によって違う。漏れているところもある。内容も指示に沿っていない。
「これは何を意図した記載？」
「え、ここもやってないの？」
結局、私が5人に直接連絡して、確認、修正してもらうことになりました。（なぜAさんに言わないのかって？確かに・・・）
さらに提出後、今度は私自身の確認漏れが見つかりました。未更新の箇所が残っていたので、また5人に連絡。休みの人もいて、最後は私が自分で直さざるを得なくりました。
正直、かなり腹が立ちました。ここまで指示、確認しないとダメなのかと怒りや失望も湧いてきました。
「Aさんにお願いしたんだから、最後までちゃんと完成させてくれよ」
これが、そのときの率直な気持ちです。
でも、少し冷静になって考えてみた
立場上、Aさんに「ちゃんとやれよ！！」で済ますことも可能でしたが、そういう感情的なのはあまり好きではないので、自分なりに考えることに。
日頃、モデル化だの、仮説検証だのの重要性を述べていますので、この出来事をIT&Scienceの視点で考えてみました。
今回の仕事を単純にモデル化すると、
依頼 → 作業分解 → 担当割り当て → 更新 → 確認 → 完成
となり、当時の進め方には「確認」が足りなかったことが見えてきます。
でも、「8か所を5人に分担して、それぞれ更新してもらえば、資料は完成するる」は、あくまでこの進め方が適切であるという仮説です。
では仮説と対になる検証はどこで？
「たぶん大丈夫」を検証する
今回、私は提出日に確認し、そこで初めて抜けや更新誤りに気づきました。つまり、確認するタイミングが遅かった。
途中で一度確認して、「この分担方法で、本当に意図したとおりに進んでいるか？」を確かめればよかったのでしょう。Aさんに、そう聞くだけでも違ったかもしれない。
Scienceでは、仮説を立てたら、検証（実験）して結果を見る。
仕事でも同じ。「このやり方なら大丈夫だろう」ではなく、実際の結果（今回であれば途中結果）を見て、正しかったかを確かめる。これが「検証」なのだと思います。
検証して、初めて仕事の進め方が評価できる
今回の結果を見ると、「5人にそのまま依頼すれば、8か所の更新が正しく完了する」という仮説は、少なくとも成立しませんでした。
では、何が悪かったのかを、人を疑うのではなく、モデルに戻って考えてみます。
元の依頼は細かく、8か所もある。それをそのまま5人に渡した。担当者ごとの認識に差が出る可能性がある。
だったら次は、
依頼 → 8項目に分解 → 担当割り当て → 説明 → 更新 → 中間確認 → 最終確認 → 完成
というモデルに変えてみる。そして、また実行して検証する。この繰り返しによって、仕事の進め方そのものを改善していけば、組織として再現性のある仕事になってきます。
結局、Aさんが悪かったのか？
正直、今でもAさんには「もう少し最後まで見てほしかった」という気持ちはあります（笑）。でも、「Aさんが悪かった」で終わらせてしまうと、次も同じことが起こり、また腹立たしい気持ちを持ってしまうかもしれません。
今回のことで考えたのは、「この仕事は、どういう進め方をすれば確実に完成するのか？」ということでした。
仕事の進め方も、最初から正解が分かっているわけでありません。
まずモデル化する。
「このやり方ならうまくいくはず」という仮説を立てる。
実際にやってみる。
結果を確認する。
うまくいかなければ、モデルを見直す。
こう考えると、今回の「なんでこんなことになったんだ？」という出来事も、単なる愚痴では終わらなくなります。おのずと負の感情とも切り離されていくことが、実は最大の効果なのかもしれませんね。
身の回りの仕事を、仮説と検証の対象として見てみる。
それも、IT&Scienceの考え方を実践する一つの方法なのだと思います。
