私が仕事を任せる(委譲する)時の3つのポイント

こんにちは、NE会社に勤めますきんじょう(@o0h_)がお送りします。
突然ですが、皆さんは「権限委譲」やっていますか？^[1]
「権限委譲」というのが大げさであれば、「自分の持っていた仕事を他の人に任せる」くらいの感覚で、読み替えてみても良いかも知れません。
いかがでしょう？

業務負荷の集中を避けたり、後進の育成を目的として取り組んでいる人も多そうにも思います。
ただ、実際にやってみると「意外に難しい」とも感じる場面があるのではないでしょうか。
あるいは、「やりたいけどやれていない」という難しさもあるかも知れません。

私はマネージャー業に就いてから、あるいは自分より「若手」の多い職場に所属したことで、色々な場面で「仕事を預ける・任せる・委譲する」という経験をしてきました。
また、上司などの他の人から「仕事を受け取る」側の立場になったことも、もちろんあります。

そんな実践の中で、自分なりに気をつけていたものを、3つのポイントに絞ってまとめてみようと思いました。

私が考える3つのポイント

細かいテクニックなどはあれど、基本の部分として「気にしていること」はこの3つです。

1. ただ「自分の仕事を軽くするだけ」の委譲はしない
2. 期待と預ける責任の範囲を明確に示す
3. 与えた信頼を「泥棒」しない

1つずつ見ていきます。

1. ただ「自分の仕事を軽くするだけ」の委譲はしない

いきなり「ケースバイケース」「要はバランス」な面が色濃い思想ですが、意識していることです。

マネジメントの仕事において取り組むべき事は？と問われたら、書籍「HIGH OUTPUT MANAGEMENT」で語られているように「レバレッジを効かせる」ことだ、という視点に自分は立っています。
そのための手段として、「ボトルネックやSPOFを解消する」「人材を育成する」が出てきます。
権限や仕事の委譲についても、この原則は守られるべきだと考えています。

その前提で、「自分の仕事を軽くするだけ」を目的とした委譲、すなわち「忙しいから、仕事の一部を部下に担ってもらう」というタイプのものについて評価してみます。
果たして、組織の担える仕事を効果的に増やせている=レバレッジを効かせられているか・・？
自分には、コレは少し「弱い」と感じられるのです。コストもリターンも変わること無く、場所が移動しただけですよね。

もちろん「負担が肩代わりされることで、ハイパフォーマンスな人員が別の効果的な仕事に取り組める」という効果はあると思います。
だとしても、「上の人」「下の人」の構図を強化するような仕事の流れになってしまい、自分としては避けたいなと思われるのでした。

反対に、自分がやるべきは「自分より上手くやれそうな所に委譲する」ことだと考えています。

例えば、「今とりくんでいるプロジェクトが直面している技術課題について、しっかり吟味して検討して、適切な対応策やその実施コストを算出すること」などは、広範囲にヒト・モノ・カネをマネジメントしなければならない立場にある人よりは、「現場」の方が上手くやれるでしょう。なので、これはチームのリーダーに任せます。
「カスタマーサポート部門と協調して、既存機能の改修方針についての取りまとめを行い、実装をした後に継続的にコミュニケーションを取りながら次のフィードバックを得ること」も、実際に手を動かしながら考えていける人に委ねた方が精度が高そうです。

他方で、「中長期的な方針を示して意識を揃えるためのロードマップを作る」とか「組織の幅広い範囲から情報を収集して、相対化したり全体のバランスを取る」といった話題に関しては、「現場から遠い」「広いアクセス権を持っている」ようなポジションの方が相性が良いです。

そういう風にして、「この仕事が、組織の中における上下左右の座標で考えた際に、どこに落ちるのが最も良い効果を上げそうか？」を考えていきます。
そこから判断して、自分が担うべきもの・委譲すべきものを決めていく・・というスタイルを私は取っています。

もちろん、「やるべき・べきでない」という軸とは別に「できる・できない」という軸もあります。この二者は、別々の問題だと考えてください。経験を積ませる・教育目的の「委譲」はありえます。
なので、「自分より上手くやれそうな所」というのは、個々人の能力よりも「組織全体という空間で捉えた時に、レバレッジを効かせられそうなポイント」というニュアンスになります。

「ここにチームを支えられるリーダーがいて欲しい」という箇所があれば、「ここのリーダーになってもらおう」という将来的なビジョンを持ち、その実現に向けて「仕掛け」ていきます。場数を踏ませる、練習の機会を作ることです。
当然ながら投資的な目線が入ってくるケースにおいては、リスクをコントロールする負荷が上乗せされますし、支援コストも生じてきます。それでいてなお、アウトプットのクオリティは低くなるかも知れません。
でも、全体の向上を目指したら、やるべきなのです。マネージャーは、この局面で「自分でやったほうが早い病」を発症しないように我慢すべきところなのでしょう。

どうやってチェックするか

それでは、どのようにして「単に肩代わりして欲しいだけなのか」「これから先を考えての全体の能力を引き上げるためなのか」を区別すればいいでしょうか？

非常に主観的ですが、「誰でも(自分以外でも)良いものだから、やらせてみよう」なのか「より上手く行きそうだという期待から、やらせてみたい」なのか、どちらの心理で委譲を考えているのか？を自問してみるようにしています。

その結果として、「期待」に基づく委譲だと言えそうであれば、ただの「委託先」ではなくて「全体を向上させるためのパートナー」になります。
立場に関係なく、そうした前向きな信頼によって仕事を駆動させていけるのがハッピーだと考えています。

2. 期待と預ける責任の範囲を明確に示す

仕事や権限の委譲でよくある失敗は、「思ったよりやってくれなかった」「説明がざっくりしすぎていた」というものです。
果たしてほしい責任(結果)、実施可能な行動、直接的に干渉可能な範囲(人や組織)etc、「どこまでやっていいから、どこまでやって欲しい」かは、委譲する側から受け取る側にしっかりと説明されるべきです。
何度も繰り返して共有される必要があるかも知れませんし、行動をしながらのフィードバックという形で擦り合わせも必要かもしれません。

個人的には、マネジメント3.0の基礎ワークショップで、"ほとんどの場合において、マネージャーはメンバーやチームに仕事を委任する際、コントロールの明確な境界線を与えません。" という説明を聞いて、感銘を受けました。

see: https://www.slideshare.net/StefanNsperling/management-30-81588515#28

委譲した先が「思った通りのパフォーマンスを発揮してくれない」という時には、こちらの説明・・特に「どこまでやっていいか」の共有が足りないのかもな、と思うようにしています。

「アレコレを、こういう形でやって欲しい」という指示的な内容は事細やかに共有する必要はありませんが、「何をしていいか」については、丁寧に説明して良いと思います。特にリーダーシップを取ることに慣れていない相手や初めての領域に挑戦する相手に対しては、しつこいくらいでも良いのかも知れません。

「最初に言ったから、あとは任せた」では、決して適切な委譲とはいえないと考えます。
委譲をしたとしても、任せた側から責任が無くなるわけではないのです。こちらもこちらの責任を果たしましょう。委譲者の責任は、委譲相手がそれを完遂するまで続きます。

まず、「責任」といった時に2つの責任 = 「説明責任: accountability」と「実行責任: responsibility」に分けて考えるところからスタートです。
このあたりは、書籍「エンジニアリングマネージャーのしごと」でも触れられています。^[2]
やり方を選ぶ権利は委譲された側にありますが(それを渡したんですよね？)、「許容できるリスクを超えていないか」「その方法が最適であったと、なぜ言えるのか」についての責任は委譲する側から移りません。
つまり、「好きにやらせるがケツは持つ」ことを意識するべきです。

この「責任のとり方」という点に視線を向けた時に、「委譲レベル」という発想が出てきます。
ざっくりといえば「どうやって決めさせるか」と「どう伴走していくか」の段階分けです。
(これについても、「エンジニアリングマネージャーのしごと」の中で「委譲の物差し」という表現で説明がされています)

本記事では説明を割愛しますが、「delegation poker」などのキーワードで検索してみてください。
あるいは、Decision Cards™にも同様の試みが見られるので、こちらもオススメです。

「どの程度の委譲なのか」を意識して、常に自覚的に接していくことが必要になります。

どうやってチェックするか

こうした「2つの責任」を考えていく中で、どのようにして委譲が健全に進んでいるかをチェックできるでしょうか？

委譲先がチームの場合は、ふりかえり(retrospective)に参加して見るのも手です。
その際に観察するべきなのは、「どんな課題や打ち手が出てきているか」よりも少しメタな視点で、「自分たちのコントロールすべき範囲を、どのように認識していそうか？」という部分になります。
もし、違和感を感じたり自分の認識とのズレがありそうであれば、素朴に意思表明をしてみる事が可能です。「(急に否定をするのではなく)自分としてはこういう期待をしているのだけど、どう捉えていますか？」といった形です。

「マネージャーからリーダーへの委譲」のような、対個人の場合には、定期的に1on1をするのも便利です。
私も1on1を実施しながら、いくつかの質問を使ってみることで検査をしていました

• (プロジェクトなどの場合)期日はいつまで欲しいか・どのくらいあれば終わりそうか、その確率は体感で何％か
  • その根拠として、どういう見立てを持っているか(残りの課題や、その進め方など)
  • 課題は、何があれば解決できると考えているか
  • => このあたりが汲み上げられると、こちらも「説明責任」を持つことができますし、介入のレベルを調整する判断材料ともなります
• 自分にやって欲しい事はあるか？
  • 逆に、手を出さないでほしい事や、やめてほしい事はあるか
  • => このあたりが見えてくると、互いの認識している「コントロールできる範囲の境界線」のイメージが揃えられます

関連して、影響範囲や関係者の存在については、割と積極的に情報の提供や指摘をすることが多い気がします。「あのチームとは調整がついている？」とか、「あの人は何て言っていた？」とかいったものです。
ここで自分の仕事の輪郭を見極めやすくなる効果もありますし、あるいは「マネージャー間の頭出しだけやっておこうか？」といった業務的・心理的な負荷が大きくなりそうな部分は巻き取れる余地が生まれます。

3. 与えた信頼を「泥棒」しない

これは、「自分がやられて嫌だったので、誰かに対して絶対にやらないようにしよう」と気をつけていることです。

仕事や権限の委譲は、一定の「信頼」「期待」を基にして行われます。それらは、コチラからアチラへと受け渡されたものです。
さて、そんな中で、「自分が任されたプロジェクトの仕事」だと思っていたものを、上司やリーダーが「ちょっと気になったし時間があったから、プロジェクト内でやる事になっていたあの調査はやっておいたよ」と告げてきたら・・どうなるでしょうか？

手を出した本人からすると、良かれと思って、あるいは無邪気に実施した内容に過ぎないのかとは思います。
しかしながら、「自分の代行をして欲しくて、任せただけなのか」とも「こちらに与えられた境界線を踏み越えてきた」とも感じる行為になりかねません。
なので、単に「仕事に干渉する」のに留まらず、「信頼を泥棒する」のに等しい事だと考えます。

「代わりに片付けておいたよ」や「先に話しておいたよ」などの、ちょっとした事でも、十分な配慮をするべきだと考えます。
一度、仕事や権限を委譲したのであれば、その実行についてのオーナーは「元の持ち主(=あなた)」ではなく「委譲を受けた人」だと心得ましょう。もし、手を出したいのであれば、しっかりと許可を得るべきです。

どうやってチェックするか

前提として、こちらが出来ることは「観察」と「助言」だというのが基本的なスタンスになるかと思います。
その上で、自分がやろうとしていることが、相手の領域内の「新しい仕事を増やす」あるいは「今ある仕事を減らす」のであれば、一線を越えた干渉になっているのではないでしょうか。

とりわけ、「先んじて、代わりにやっておいた」は危険に感じます。そうする前に、せめて「どうなりそう？」と確認を取り、認識を揃えた上で援助を申し出る・許可を得ることができるはずです。
下から上への「確認しすぎ、判断できなすぎ」はあっても、上から下への「すり合わせや許可依頼が過剰」は無いものと考えています。

ただし、どこまで具体の行動を許されるか？については、委譲レベルによっても異なっていることに注意が必要です。

例えば「半年単位のプロジェクトのリーダーを任せられる相手」に「明日から再来週までの、チームのタスクリストはどうなっているの？」と尋ねるのは違和感を感じます。
踏み込んで良いのは、せいぜい「今月末のマイルストーンは達成できていそうか」といった粒度ではないでしょうか。(もちろん、それらの話を聞いた上で不明点や違和感を表明する権利はあると思います。「説明責任」に基づいた行為です。)

逆に、「他部門との接点をあまり持ってきておらず、今回が部署横断の動きは初めてとなる相手」に対しては、各部署の役割や特徴であったり、連携に際してのプロトコルをティーチングする事は自然でしょう。顔合わせの場をアレンジする、なども代行する余地があると思います(もちろん、委譲相手との確認と合意の上で！)

最後に

個人的には、マネジメントの醍醐味は「部下が自分の想像を超えた働き・成長をした瞬間に立ち会える瞬間」にあると感じています。そうした場面では、思わずベンチから飛び降りて片膝でガッツポーズを取りたくなるものです。

そのため、この「仕事や権限を委譲すること」は非常に重要だと考えています。
自分の望む喜ばしい瞬間に出会える確率を増やすために、「チャレンジさせる」機会を増やしていくのは必須です。

「自分より上手くやってくれる人」の可能性に懸けたいのです。
そうした意味では、自分のマネジメントは、部下やメンバーを「使役する」という感覚は弱いかも知れません。
自分にとっては、「自らの手足」のような部下やメンバーを増やすのは興味がない事な気もします。
タレントを引き立てるプロデューサーみたいな感じなんですかね・・

委譲を押し進めるには確かに有用なテクニックもありますし、それらを上手に使うことは重要になってきますが、先立つものはマインドなのではないかな、とも思っています。
相手を一人の大人として扱う、信頼はまず自分から与える、才能を刺激して革新的なモノを生む、そんな所を大事にしていきたいです。

参考文献

• エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法
  • 本文中でも触れました！
• マネジメント3.0 　適応力の高いチームを育むための6つの視点
  • 本記事では、話をコンパクトに収めるために言及を避けましたが、「委譲対委任」のコンセプトも、個人的には重視しています。本書は読むのに骨が折れるかも知れませんが、当記事を読んでくださった皆様には、「第7章 チームにどのように委任するか」だけでも読んでみてもらいたいです
  • あるいは、ワークを交えながら概念的・感覚的にマネジメント3.0のコンセプトに触れられるので、基礎ワークショップに参加してみてください。
    (参考: https://management30.jp/events/ )
• エラスティックリーダーシップ ―自己組織化チームの育て方
  • 現在は書籍の入手が難しくなってしまっていますが、「委譲レベル」の概念と本書の「リーダーシップのスタイル」の話を関連付けて考える事には大きな意義があると考えます
  • 委譲相手(例えばリーダー)との接し方を自分自身が考えたり、あるいは委譲相手に対してチームとの関わり方を示す際にも、強力なヒントをくれるはずです
• パワートゥザエッジ: ネットワークコミュニケーション技術による戦略的組織論
  • より大きな話として、「組織全体としての機動性を、どう高めるか。なぜ必要なのか」については、こちらの本を一読してみるのが良いのではないでしょうか

脚注

1. 今回の話は「移譲」ではなく「委譲」です。両者は違うものだ、というのを意識した上で話を進めています。
   参考: 「委譲」と「移譲」の違い | 日本語早わかり

2. 直前でマネジメント3.0のスライドを共有していますが、こちらで語られているaccountability/responsibilityと「エンジニアリングマネージャーのしごと」の内容は、異なる次元のものになっているので注意が必要です。