任せた仕事を取り戻していた。進捗報告ではなく「動いた証拠」を見るようにした

私は、任せた仕事の進みが遅い、品質が不安、顧客への影響が出そうだと感じると、自分で引き取ることがありました。

その場では速くなります。問題も解けます。ただ、同じ種類の問題が起きるたびに私が戻るため、仕事を任せた範囲は実質的に広がりません。

そこで、委譲したかどうかではなく、一度任せた仕事を社長が再び担当した割合を見るようにしました。

委譲の失敗は、相手の能力だけでは決まりません

「この仕事を任せる」と伝えても、成果、権限、途中確認、例外条件が決まっていなければ、問題が起きた時に誰が判断するか分かりません。

たとえば開発では、「この機能を作る」だけでは不十分です。誰が使うのか、どんな場合に成功なのか、異常時はどう動くのか、何を見れば完成と判断できるかまで必要です。

これがないまま任せると、担当者は作業を進めても、社長は完成像が合っているか不安になります。結果として、途中から社長が設計と確認を引き取ります。

人を信じるかどうかの問題にする前に、任せ方の条件を明確にする必要があります。

仕事を渡す前に、五つを決めます

Beekleでは、少なくとも次の五つを先に決めます。

1. 成果：何が変われば完了か
2. 権限：本人が決めてよい範囲と、承認が必要な範囲
3. 確認時点：どこで方向性と品質を確認するか
4. 例外条件：期限、予算、契約、顧客影響など、上げるべき条件
5. 完了証拠：画面、数値、顧客返信、動作結果など、完成を確認できるもの

この五つがあると、担当者はどこまで進めてよいか分かり、社長は何を見ればよいか分かります。

途中確認を増やしすぎると、委譲ではなく細かな指示になります。仕事のリスクと担当者の経験に合わせ、確認点を絞ります。

「順調です」ではなく、利用場面ごとの証拠を確認します

進捗率は便利ですが、90%と報告されても、残り10%に重大な問題が残ることがあります。

PM on Railsでは、利用者が実際に行う場面ごとに、動作結果を確認します。たとえば、登録できる、重複時に正しく止まる、権限がない人には見えない、外部システムに反映される、といった条件です。

作業者やAIは、条件を満たした画面、テスト結果、記録を残します。私は、作業量ではなく、合意した場面が動いたかを見ます。

これにより、すべてを自分で再実装するのではなく、問題がある場面にだけ介入できるようになります。

社長が入る時は、役割と出口を決めます

重大な問題では、社長が入るべき場合があります。介入そのものを失敗扱いにすると、問題報告が遅れます。

ただし、入る時に次を決めます。

• 今回、社長が判断すること
• 元の担当者が続けること
• いつ、どの条件で責任を戻すか
• 再発防止として何を仕組みに残すか
• 次回同じ問題が起きた時、誰が判断するか

緊急対応が終わった後も、社長が担当者のまま残ると、委譲した仕事が一つ減ります。介入と恒常的な巻き取りを分ける必要があります。

「取り戻し率」を経営指標にしました

委譲した仕事のうち、社長が再び主担当になった割合を、次のように見ます。

仕事の取り戻し率 ＝ 社長が再び主担当になった仕事数 ÷ 委譲した仕事数

この数字をゼロにすることが目的ではありません。重大事故を防ぐ介入は必要です。

見るべきなのは、同じ種類の問題に何度も社長が介入しているか、介入後に判断基準や確認方法が変わったかです。

合わせて、社長が使った時間、元の担当者に戻せた割合、同じ原因の再発回数、品質や納期への影響も確認します。

現在の課題は、委譲の仕組み自体を運用し続けることです

成果、例外、証拠を決めても、すべての委譲が成功するわけではありません。仕事の難しさ、担当者の技能、顧客事情によっては、社長の支援が続くこともあります。

また、細かな仕事まで同じ形式で管理すると、記録の負担が増えます。そのため、何度も繰り返される仕事、失敗時の損失が大きい仕事、社長が毎回戻っている仕事から対象にします。

私は、自分が問題を解けることを強みにしてきました。ただ、会社を強くするには、自分が解いた後の判断方法まで残す必要があります。

一度助けた仕事を、次回は同じ形で助けなくてよい状態に変える。

そのために、進捗報告より、成果、例外条件、動いた証拠を中心に委譲を設計しています。

社長の時間を作るほかの取り組みは、社長の時間を作る経営DXにまとめています。

参考資料

• PM on Rails
• 入山章栄『世界標準の経営理論』