任せるコツ：「自分でやったほうが早い」という名のバグを修正する

「──よし、ここも私が引き受けよう」 

深夜一人で全体のスケジュールを再確認しているとき、チームの誰も気づいていない潜在的な課題を見つけてしまうことがあります。その瞬間、私の脳内には諦めではなく「私がやるしかない」という妙に静かな、腹をくくる感覚が満ちていきました。自分だけの時間を削ってでも、このタスクを背負い込む覚悟を決めてしまうのです。

1. 「私がやるしかない」という名の自己満足

今振り返れば、それは決して健全なリーダーの姿ではなかったのかもしれません。ですが当時の私は、優先度の高低に関係なく、自分の両手に溢れんばかりのタスクを抱え込んでいる状態そのものに、強烈な「自己満足感」や「自己達成感」を覚えていました。他人に任せて成果物の質にヤキモキするくらいなら、自分がすべてを掌握し、自身の基準で完結させる。その過剰な負荷に耐えている自分自身に、どこかで深く酔っていた部分があったのだと感じています。

しかし組織が拡大し、複数部署にまたがる複雑な課題が押し寄せたとき。この「自己完結型」のシステムは物理的な限界を迎えることになります。私一人がボトルネックとなり、目の前の課題が次々と停滞し始めるという、致命的な「現場の歪み」が牙をむいたのです。

この歪みを解消するため、私は仕組み化という「既存の解決策」にすがったこともありました。業務の標準化マニュアルを緻密に作り込み、タスク管理ツールを導入して、すべての進捗を画面上に可視化しました。「これでシステムは自走するはずだ」と確信していたのです。

ですが、現実はそれほど甘くはありませんでした。ツールによって「状況ログ」のインプットには成功したものの、本質的なバグは消えませんでした。メンバーが当事者意識を持って能動的に動き出すという「駆動のアルゴリズム」までは、マニュアルやツールだけでは書き換えられなかったのです。道具を整えても現場は変わらない。そればかりか、管理を強めようとする私に対して、画面の向こう側の現場からは、静かな拒絶反応という、新たなバグが発生し始めていたのです。

2. 「依頼の5要素」という名の理想論

手探りのマネジメントに行き詰まりを感じていたとき、私は山本渉氏の著書『任せるコツ』に出会いました。そこに書かれていた「依頼の5要素（意欲創出、目的、欲求充足、選択肢、負担配慮）」というフレームワークは、人に仕事を任せるためのステップとして、極めて精巧に設計された理論でした。私がずっと手探りで組み立てようとしていた「依頼のソースコード」が、すでに体系化されて目の前にある。そう感じた瞬間でもありました。

しかし読み進めるうちに、胸の奥に重たい問いが浮かびあがってきました。

「本当に現場で、仕事を切り出すたびに、これほど重厚な準備を一枚一枚丁寧に行っていけるのだろうか……」

この問いは、私個人の弱さではないと今は思っています。学校法人産業能率大学総合研究所の調査（2023年）によると、上場企業の課長職の94.9％が、自身も現場を抱える「プレイングマネージャー」です。さらに、プレイヤー業務が及ぼす支障として「部下の育成・指導」が60.4％でトップを占めています。

つまり、自分のプレイヤー業務だけでリソースが100%埋まっているような日々のなかで、さらに膨大なコミュニケーション・コストを支払うよう求められているのは、私だけではなかったのです。

正しい理論をそのまま適用しようとすること自体が、現場にさらなる負荷をかける「見えないバグ」の始まりだったのかもしれない——そう気づいたのは、もう少し後のことです。

▼Amazon

3. 画面の向こう側の「タスク増えた感」

理論に背中を押されるようにして、私は定例ミーティングを設定し、各自の進捗や実績を細かく報告してもらう仕組みを導入しました。マネージャーである私が状況を正しくインプットできる状態を作ろうと考えたのです。

ですが、その仕組みを動かし始めた途端、画面の向こう側に、ある独特な空気が漂い始めるのを感じることになります。

「……今週の進捗は、以上の通りです」

ミーティングの場で返ってくるのは、どこか形式的な報告。あるいは、ルールを説明したときに漏れ聞こえた「え～」という小さなため息でした。メンバーが発信している「管理のためのタスクが増えてしまった」という無言のプレッシャーを、私は感覚的に受け止めていたのです。

その空気を察したとき、私の胸の内に去来したのは、相手への苛立ちではありませんでした。「まあ、そんな反応をするのも無理はないよな」という、どこか冷めた、しかし妙に納得している思いだったのです。私にとっては大切な可視化のステップであっても、日々の業務に追われるメンバーにとっては、単に「やらされる作業が一つ増えただけ」の負担に映っているのだと痛感しました。 

結果として、チームの状況を以前よりも把握できるようにはなりましたが、メンバーが自発的に課題一覧を更新するような「意識の向上」にはどうしてもたどり着けませんでした。コミュニケーションの量を増やせば増やすほど、現場には「タスク増えた感」という副作用が蓄積していく──。この目に見えない摩擦を前にして、私はプレイングマネージャーとしての深い葛藤の中に立ち尽くしていました。

4. 表現の夜な夜な最適化コスト

「任せる」という行動を実践しようとするとき、本当に深刻なのは、相手に伝える言葉を選び抜くために消費される、膨大な「脳内リソース」の存在です。私自身、メンバーに何かを依頼するときや、メッセージに返信をするとき、今でも深い迷路に入り込んでしまうことがあります。

「どう言えば、相手が一番動きやすいだろうか」

「この表現だと、少し冷たく感じられてしまうかもしれない」 

相手の心理を想像し、チャットツールの一文を打つためだけに、15分も20分も画面を見つめて推敲を重ねてしまうのです。夜な夜な、自分が100%納得のいく完璧なワードが決まるまで、時計の針が進んでいくのを横目にリソースを注ぎ込み続けていました。

主観的になりがちな「任せる」を、目の前の相手自身がすんなり理解できる形に翻訳して手渡す。その言い回しやタイミングを準備すること自体が、実はマネージャーにのしかかる巨大な「副作用」だったのだと感じています。

背景にあったのは私自身の「完璧主義」。言い換えれば、自分が100%納得できるまで手を離せないという性格でした。最終段階でどうしても発生してしまう成果物の「手直し」を防ぎ、品質を私の基準で担保するためには、指示出しのフェーズで、あそこまで言葉に時間をかけなければならない、と自分を追い詰めていたのかもしれません。自分で手を動かしていた頃のほうが、どれほど精神的に楽だっただろう。そうした本音が、頭をよぎることもありました。

それでも私が「任せる」という選択を手放さなかったのは、このバグを放置したまま組織が動き続けることへの、もっと大きな恐怖があったからです。

5. 思考アルゴリズムをコード化せよ

数々の失敗と葛藤の果てに、私は一つの確信に至りました。「仕事を任せる」とは、単に作業手順を相手に渡すことではない。手順の奥にある「自分ならどう判断するかという思考プロセス」そのものを、相手のなかに移植していく作業です。ただし、一度で完了するものではない。それは私が、何度も同じ失敗を繰り返しながら学んだことでもあります。

相手が「やりたい」と思える文脈になっているか。その仕事が「なぜ必要か」を伝えているか。負担の配慮はできているか——本書が示す問いは、依頼の設計図というより、思考アルゴリズムを相手に渡す前の「コンパイルチェック（実行前の最終確認）」に近いものでした。

チームが自走するためには、マニュアルでも管理ツールでもなく、この「チェックの習慣」を自分のなかに実装することが先決だったのです。

ⅰ. 「判断軸」の事前共有

タスクを渡す前に「最も優先すべき軸は××」という自分の判断基準をあらかじめ言葉にして手渡す。これは相手を管理するためではなく、相手が迷ったときに「自分で判断できる」状態をつくるための下地です。指示待ちを生むのは、多くの場合、タスクではなく「判断の根拠」が渡されていないことに原因があります。

ⅱ. 「権限の境界線」の明示

「ここまではあなたの判断で進めて構いません」と裁量の範囲を透明にする。やりたいことがあっても動けないメンバーは、多くの場合、意欲がないのではなく、どこまで踏み込んでいいか分からないだけです。境界線を引くことは、相手の行動範囲を制限するのではなく、むしろ解放することに近いのです。

ⅲ. 「リテイクコスト」の事前合意

「ズレが生じた場合はこの基準で一緒に修正しよう」と、振り返りのルールを最初に握っておく。任せることへの躊躇の多くは「後で大きく手直しが必要になるかもしれない」という不安から来ています。修正のルールを最初に共有しておくことで、任せる側も任される側も、安心してその仕事に向き合えるようになります。

あれから時間が経ちます。今も深夜に一人でスケジュールを眺めることがないわけではありません。ただ、そのとき頭に浮かぶのは、もう「私がやるしかない」という腹のくくり方ではなくなっていました。

代わりにあるのは、「誰にこの判断軸を渡せるか」という問いです。

バグは、自分一人で抱えても修正できない。そのことに気づいたとき、組織の景色はほんの少しだけ、変わり始めていました。

▼なぜ連載するのか