職場で一番重要なことー権限と責任

僕は、職場で起きる自我消耗はすべて、権限と責務の不均衡に行き着くと思っている。権限と責務が釣り合っていないと、次のような状況が起こりやすい。

• 責任だけあって権限がない: 結果に責任を負わされるのに、結果に影響する決定ができない。これは無力感、責任転嫁、そして最終的な品質低下につながる
• 権限だけあって責任がない: 決定はできるのに、その結果を引き受けなくていい。これは拙速な意思決定と、組織内の不公平感につながる

僕がこの状況を最もよく表していると思うのは、たぶん『半沢直樹』の筋書きだ。主人公の半沢直樹は銀行員で、誠実で、何事も銀行のためを考えて動き、汚職、賄賂、粉飾決算を激しく嫌っているが、いつも厄介な上司に出くわす。

こんな場面がある。上司が500億の融資案件を半沢直樹に任せるのだが、実は裏では西大阪鋼鐵と結託していて、急いで稟議を通したあと、すべての責任を半沢直樹に押しつける。当時、彼が審議部に叱責されたときに言ったのは（細かい台詞は忘れたが）：

半沢直樹：「この融資を通した責任はあなたたちにもある。ハンコを押して通したのはあなたたちだからだ」

審議部：「それはお前たちが何度も急かしたからだ」

半沢直樹：「何度も急かせば貸付が通るなら、融資の申請なんて簡単すぎる」

審議部：「現場の判断を尊重しただけだ」

半沢直樹：「現場の判断を尊重するなら、審議部なんて必要ない」

なぜ権限と責任がそんなに重要なのか？

社員自身が自分の権限や決定に責任を負わなくていいなら、意思決定の質は当然よくならない。たとえば、予算を管理する権限はあるのに、会社の売上に責任を負わなくていい場合だ。そうすると、チームが予算申請をしてきたとき、そのチームへの好き嫌いだけで予算を出すかどうか決められてしまう。

開発チームでも、こういうことはよくある。

• チームメンバーには開発速度を上げる責任があるのに、改善案は上層部に却下され、結局開発品質が悪化したときにチームだけが後始末を負わされる
• リファクタリング計画を出しても、上層部が技術的負債の重要性を軽視するため、その結果は開発チームが引き受けることになる。開発メンバーは毎日火消しをし、Hotfix を直し続けなければならない

権限と責任の不均衡が短期的にもたらす結果は、なかなか数値化しにくい。多くは心理面に表れるからだ。責任だけ負わされて権限のない社員は、「こんなに頑張っているのに、何も変えられない」と感じる。長期的な損失は明らかで、改善する動機を失い、指示されたことだけをやり続け、やがて帰属意識も失っていく。

以前読んだ『完璧決定之魂』には、権限を渡したがらない人は罪人だと書かれていた。

権限は責任から生まれるべきだ。たとえば100%出資のオーナーである社長は、会社を儲けさせる責任を負っているからこそ、100%の統制権を持つ。だから会社の意思決定はすべて社長が決めることになる。社長は会社倒産や給与が払えなくなるリスクを背負い、製品が売れれば会社の利益という果実も享受できる。社員は倒産リスクを負わないし、会社が儲かっても給与が必ず上がるとは限らない。

多くの経営者は社員に真面目に働くことを求めるが、要求するだけでは不可能だ。社員に社長のように必死で働いてほしいなら、同じ持分を与えればいい。

逆に言えば、よい報酬・罰則の仕組みを設計すれば、社員の成長をより引き出しやすい。機械学習には目標関数という概念がある。機械学習の訓練過程とは、損失関数を減らし、目標関数を最大化し続けることだ。モデルはあなたが「期待する」ことをするのではない。loss を小さくできることだけをする。

組織も同じだ。社員（あるいはチーム）は、口で重要だと言われたことではなく、実際に報われる行動を最適化する。

実際のやり方

とても簡単だ。権限付与と報酬の仕組みを作ればいい。相手の責任範囲の中で権限を与えるのだ。たとえば開発チームなら、Infra コスト、MTTR（Mean time to Repair）、イテレーション速度などの指標を最適化できるようにし、目標を達成したらボーナスを出すなどの報酬を与えるべきだ。その一方で、十分な権限も与えなければならない。たとえば予算内のツール費用は審査なしでそのまま通す、開発チームの技術選定には介入しない、などだ。目標を達成できなかったなら、やることは単純で、報酬を取り下げればいい。

簡単だと思わないだろうか。報酬関数は、できるだけ明確に設定したほうがいい。報酬関数は慎重に考えなければならない。たとえば Token Usage の多寡を業績評価の指標にしたら、数百万行の無駄なコードしか生まれないかもしれない。

Story Point も同じだ。ただ、こうした指標に上層部の監視が入ると、たいていは演技になる。社員はあらゆる手を使って指標を最適化し、実態を隠そうとする。その結果、帳簿上はチームの開発速度が速く、Story Point もたくさんあるように見えて、実際はまったく違う、ということが起こる。

多くの会社は責任と権限の重要性を理解していない。問題があれば社員を叱り、社員が改善しようとすればあちこちで方向が違うと説教し、最後には見ていられなくなって自分で降りてきてやってしまう。そのせいで、もっと重要なことに集中する時間がなくなる。僕は、これは多くの中間管理職や創業者が抱える悩みだと思っている。

こういうときは、責任と権限から見直せばいい。社員に適切な権限を与え、重要な意思決定だけは自分が行い、それ以外は社員の判断に手を出さない。

失敗したらどうするのか。僕は、ある程度の範囲で社員に失敗を体験させるべきだと思う。自分で経験してこそ、成長の可能性がある。あらかじめ目標と報酬を設定しておけば、失敗したら次に改善すればいいだけだ。だが、権限を渡さずに責任だけ負わせると、失敗したときに相手は当然「あなたの問題だ」と考えるし、報酬も得られずに落ち込むことになる。

だから僕は、次のような方向を勧める。

• もしあなたが社員なら
  • 出世したいなら: 自分から上司に働きかけ、期待値、自分の目標、権限の範囲をすり合わせる。達成後の報酬は何か、責任はどこまでかをはっきり確認する
  • 現状維持したいなら: ここ数か月の仕事を棚卸しし、自分の責任と権限を明確に分けて守る。責任をかぶらないことだ。同僚同士の助け合いは一時しのぎにしかならず、長く続くのは報酬の仕組みだけだ
• もしあなたが上司なら: いま会社が目指している目標は何かを考える。社員にどんな権限を与えるのか。彼らが目標を達成したら、どんな報酬があるのか。権限と責任は対応しているか。はっきり書き出すことだ。明確であればあるほどいい

期待値管理

期待値管理は、Denny が僕にキャリアにおいてかなり重要だと教えてくれたものだ。彼は、職場での失望の多くは、投入と産出の比率が合っていないことから来ると言っていた。

「僕はこんなに頑張っているのに、なぜ本来あるはずの報酬が得られないのだろう？」 Denny

考えてみると、確かにその通りだ。職場で何でもやる人、資料を補完し、バグを直し、カスタマーサポートまで受ける人は立派だし素晴らしい。しかし、それは本当に上司がやってほしいことなのか。たいていは違う。

期待値管理が重要なのは、双方が互いに何を期待しているのかを明確にできるからだ。そうすれば、「僕は ABCDE をやったのに、上司は実は F しか気にしていなかった」ということが起きない。逆に言えば、F さえ達成していれば、残りの ABCDE は昇給や評価の交渉材料になる。

権限と責任を完全に釣り合わせるのは難しい。だが、自分の能力の範囲で僕が勧めるのは、「本来は自分の仕事ではないことを自分の仕事として引き受け、成果に強くこだわる」ことだ。たとえば、あるタスクとして「顧客が、現在のアーキテクチャの月額コストを計算してほしい」と依頼されたとする。このとき、さらに「なぜ顧客は毎月のコストを知りたいのか」と考え、遠回しに観察して、製品の価格設定を計算したいのではないかと推測するのだ。

そこでついでにデータを集めて、現在の MAU（月間アクティブユーザー）や DAU（日間アクティブユーザー）を取得し、登録会員の転換率を計算する。仮に会社の目標粗利率が 50% なら、こうしたデータから価格を推定できる。これにはいくつか利点がある。

• 顧客が本当にそのデータを必要としていたなら、とても感謝される
• たとえ顧客が求めていたデータでなくても、追加でやったことだと分かっているので、損した気持ちにならない

職場では、成功したときのリターンが大きく、失敗したときの損失が小さい仕事にもっと集中すべきだ。

職場は劇場だ

最近、僕が強く感じているのは、職場ではみんな演技をしているように見え、仕事の90%以上は重要ではない、ということだ。多くの場合、職場にはすでに書かれた脚本があり、いくつかの決まったルールがあり、僕たちはそのルールに従って演じている。そんなゲームのルールが好きではないのに、従わざるを得ない。これが内耗だ。

たとえばこの記事で触れた期待値管理や、権限と責任の設計だ。それは、僕が退職について書いた記事で述べたように、必ずしもそういうゲームを遊ぶ必要はない、ということでもある。理不尽な点を見つけたときに、自分から改善してはいけないのか、なぜ自分がまったく納得していない指標を無理やり受け入れなければならないのか、と感じるかもしれない。

あるいは、会社で働く以外の可能性も考えてみるといい。（もちろん、みんなに今すぐ辞めろと勧めているわけではない！）