「部下に任せないとダメだ」と考えさせられる一冊

いま『任せる技術』という本を読んでいる。プレイングマネージャを自負している方には是非読んでいただきたい一冊だ。まだ最初の方だけしか読んでいないが、とても心に響いている。

【CHAPTER1 ムリを承知で任せる より 引用】

そもそも部下の仕事とは「今日」の食いぶちを稼ぐことにある。一方で上司の仕事とは「今日とは違う明日」をつくることである。例えば、業務フローを標準化し改善する。営業戦略を立案し実行する。未来のビジョンを策定し部下を勇気づける。部下育成をする。これまでとは違うやり方を示し、より良い未来へ踏み出すのだ。

部下の仕事を奪っている上司は、これを怠っているということになる。目先の忙しさにかまけて本質的な上司の仕事を一切していないことになるのだ。先に掲げた「高い給与で部下の仕事を奪うこと」が目に見える損失だとすれば、「今日とは違う明日」づくりを放棄するということは目には見えない大いなる損失と言えるだろう。

【引用終わり】

耳が痛い。著者の小倉広氏は組織人事コンサルティング畑の方で、エンジニアではないが、技術者の上司と部下も同じことが言えるだろう。

小倉氏は上司が部下に仕事を任せない理由として次のようなことを挙げている。

• 部下に任せて失敗することを恐れている。上司の責任になってしまうのが恐い。
• 部下に任せることで仕事の質が下がり、部署全体の業績が下がることを恐れている。
• 部下に任せるためには手取り足取り教えなければならない。自分がやった方が早い。
• 部下に教えられるほどにノウハウが整理体系化されていない。
• 口べたであり、うまく部下に教えることができない。
• 部下が自分の仕事が増えることを嫌がり、場合によっては任せられることを拒絶する。
• 仕事を部下に任せることにより職場にストレスがたまり雰囲気が悪くなる。
• 部下に仕事を任せることで、上司が楽をしているのではないかと疑われるのが恐い。
• 上司自身が忙しくなることに快感を覚え、仕事を部下に渡したくない。
• 部下に任せることによるわずかな品質低下が許せないほどに上司が完璧主義者である。
• 部下に仕事を任せたいと思っているが、何をどこまで任せていいのかわからない。

まさに図星だ。自分の場合「部下に任せることによる品質低下が最終的に顧客満足を低下させることにつながらないか？」という恐怖が強い。しかし、そのことは自分が戦列を離れたときの顧客満足度の低下については考慮していないということになる。

「自分がいなくなったら？」「そんなことは知ったこっちゃない」ということになり、きわめて自己中心的であり、組織力を弱体化させ、結果的には顧客満足も下げてしまうことになりかねない。

【CHAPTER2 ムリをしなければ脳の筋肉はつかない　より引用】

「小倉さん、今の仕事にやりがいが感じられないのです。転職すべきかどうか迷っています。アドバイスを下さい」と言うのだ。なぜ、やりがいがないの？　と聞くと返ってくる答えは2種類に大別される。

1つ目は「今の仕事が自分には向いていない」というものだ。例えば営業をやっている人は自分には営業は向いていない、と言う。本当にそうであるかは大いに疑問が残るのだが。

2つ目の理由は、「上司や会社に問題がある」というものだ。職場に問題があり、上司に直訴しても変わりそうにない。だからあきらめて転職する、と言うのだ。

僕はその2つを聞くたびにこう思う。

「その状態でどこへ転職しても、絶対にやりがいは見つかりませんよ」と。

「やりがい」とは、楽ちんな仕事を通じては手に入らない。「やりがい」は壁を乗り越えた向こう側にあるものだからだ。決して壁の手前にそれはない。様々な障害やつらさを乗り越えたときに初めて僕たちは「やりがい」に出会い、それを手にすることができる。しかし、先に相談してくる人達のほとんどは壁を乗り越える前に逃げ出そうとしている人ばかりだからだ。

【引用終わり】

部下のモチベーションは維持しなければいけないし、ムリもさせないと基礎体力がつかない。自分自身は若いことムリをした経験がある。今の若い人達には「ムリをさせろ」ということ自体がムリという人がいるが、小倉氏が書いていることはその通りだと思う。障害やつらさを取り越えないで「やりがい」に出会えることなどない。

【CHAPTER3 部下が失敗する「権利」を奪うな　より引用】

失敗が喉の渇きを引き起こす

なぜ人は「任される」と育つのだろうか。

もちろん答えは一つではない。任されるから主体性が育つ。任されるからモチベーションが高まる。任されるから期待が伝わりそれに応えようとする。様々な要因があげられるだろう。

しかし、それらの中であえて一つを選ぶとするならば、僕は真っ先に「失敗の経験」をあげるだろう。つまり「任される」ことで初めて「失敗」を経験し、「失敗」により人は多くを学ぶのだ。「失敗」すれば痛みが伴う。そのとき初めて人は「失敗したくない」と心から思う。「うまくできるようになりたい」と切望する。つまりは、うまくやるための方法という「水」を求めて「喉が渇く」のだ。

そして様々な「試行錯誤」を行う。自分の頭で考えて「工夫」する。やがてうまくいくやり方を見つける。そこで見つけた方法をゴクリと飲み干すのだ。そうして全身にそれをしみ渡らせる。それを繰り返すことにより体で覚えていくのだ。

【引用終わり】

この話を、ソフトウェア開発の世界に投影してみると、何しろ今は「失敗させる機会」が少ない。「渇きを引き起こす」だけの「失敗の経験」を与える機会がない。また、ソフトウェアは失敗作でも一見動いてしまうこともあり、それが失敗であると気づかずに先に進んでしまうこともある。

さらに、大規模プロジェクトでは自分の作ったソフトウェアに失敗（＝バグ）があることを自分ではなく、後工程のメンバーが見つける責務を担っていることもある。作りっぱなしで失敗を見つけるのも他人という環境では渇きが起こらない。

自分の場合は「渇き」は「今よりも美しいソフトウェアを作りたい」「より楽に、より高品質で、クリエイティブな仕事がしたい」という気持ちから生まれていたと思う。

「失敗の経験」により「渇きを引き起こす」ためには、この本のタイトルどおり任せる技術が必要そうだ。「渇きを引き起こす」どころかやる気がなくなってもまずい。

失敗しないように手取り足取り教えてしまうと任せたことにはならず、「渇き」にはつながらない。

コンピュータではなく相手が人間だとこれほどまでに物事をうまく進めるのが難しい。もっと、この本を読み進める必要がありそうだ。