エンジニアからみるマネジメント基礎 - 第5回 部下の育成
では前回に引き続き、以下の全7回のうちの第5回目になります。
- 管理の基礎
- 仕事の管理
- 改善と問題解決
- 人間行動の理解
- 部下の育成 ← 今回はここ
- よい職場つくり
- 管理者の自己啓発
第5回 部下の育成
管理者の価値は、部下の行った仕事の成果で判断される。とすれば部下の能力を育成するためにはいかなる時間も努力も惜しんではならない。部下の育成は苦労のともなう仕事である。しかしそれだけにやりがいのある仕事なのである。
5.1 部下育成の基本
5.1.1 部下育成の意味の確認
- 部下は自分の成長を願っている
部下は力をつけて成長することを願っており、自分よりも経験を積んだ上司が自分を指導し、育成してくれることを求めている
- 部下育成こそ「人間性の尊重」そのものである
人間性の尊重とは精神的充実を与えることである。労働条件が良くても、潜在能力が開発されなければ部下は精神的充実を感じれない。
- 部下育成=意欲づけ
部下を育てることが上手な管理者とは、部下にやる気を起こさせることの上手な管理者である。端的に言えば、部下育成=部下の意欲づけ=部下の人間性の尊重ということである。
- 部下育成は管理者のためでもある
目先の成績をとるために、部下育成をせずに実績を積み上げることに腐心する管理者は少なくない。一方で部下育成もしながら実績も積み上げている管理者もいる。管理者の真価が問われるのはどうやって実績を上げたのか、すなわち鍛え育てながらなのか、あるいは単に手足の如くこき使うことによってなのかである。この違いは社内の人望の差となって現れ、より大きなプロジェクトを任されるようになるだろう。つまり、部下育成は管理者のためでもあるといえよう。
エンジニアマネージャーとして
部下の成長=技術力の向上がなされれば、アウトプットが増えるのは自明である。それはつまり自分のチームの成果の向上にもつながる。忙しいからといって育成を放棄してしまうことは、部下の人間性を尊重していないということになる。
5.1.3 OJTの方法の基礎
- 人は経験することによって学ぶ
OJTはやって学ぶのが効果的である。ラーニング・バイ・ドゥーイング。失敗したら自分なりに考えてもう一度取り組んでみるというのが学びの基本であり、効果的な"学ばせ方"である。
- OJTのステップとポイント
管理者は部下に仕事を命じる際に、取り組み方を工夫させたり、進め方を指示・助言します。そうして部下はどう進めたらいいのか考え、いいと思ったとおりに取り組みます。管理者はその取り組み方を観察し、改めるべき点に気づかせたり、中間報告させたり、結果に対して注意したり・ほめたりし、部下は改めるべき点に気付くというのが、職場における部下の学習と指導の過程です。
- 管理と育成
職場における部下育成は、仕事や部下の管理と別ものではない。言い換えれば「仕事が忙しくて部下育成をしている時間的余裕がない」というものではない。OJTは時間的ゆとりの有無とは無関係である。
- 部下育成の上手な管理者と下手な管理者
部下育成の上手な管理者は、教え方というより管理の仕方そのもののレベルが高い。最大の決め手は仕事の割当である。教え方が不十分なために育たないということはあまりなく、むしろ部下に仕事を任せないことのほうが育成上致命的なマイナスである。部下を育てるという意識をもって仕事の割当をしているかどうかが一番大切なのである。
- 知識・技能・態度と指導方法
教育の分野では人の行動を支えているものを３つに分けて考えている。知識、技能、態度である。もし、部下が取り組むべきことをきちんと取り組まなかったら、その原因はすなわり「知識が不足しているか」「技能不足か」「態度に問題がある」かの３つに起因する。この３つを補強すれば行動は改善されるというわけである。
エンジニアマネージャーとして
エンジニアもOJTでの成長が基本になる。本で読んだりして知識を入れたところで、実際にコードを書いて動かしてみないと自らにその技術が定着しないという覚えは、全エンジニアあると思う。ましてやサンプルコードを書くのと、プロダクトのコードを書くのとではその定着度・理解度は段違いである。マネージャーとしては積極的にその機会を与えたい。
5.2育成計画のつくり方
5.2.1 育成目標と育成計画
育成方向を定める
「馬を川辺に連れて行くことはできるが、飲みたくない水を飲ませることはできない」ということがしばしば言われるが、血の通った部下育成でないと、部下はそっぽを向いてしまいます。部下個人の将来を考えて育成計画を作ることは、血の通った育成計画にするための必須条件である。
啓発必要点と育成目標
育成方向といっても漠然としていたのではつかみどころがない。具体的なイメージを描くための現実的なやり方は大きく分けて２つある。１つは「〇〇さんのように」というロールモデルを見出す方法、もう一つは「一級建築士や経営企画のマネージャー」といったように業務やポストを想定する方法である。あまり遠い目標でも現実的でないので2~3年後の中間目標を設定することも必要である。そのイメージを実現させるために必要とされる能力を部下と一緒に考えて、足りない能力を導き出し、それを埋めるように育成計画・目標を策定します。
エンジニアマネージャーとして
社内にロールモデルがいるのが理想だが、社外のエンジニアでもロールモデルになりえます。部下にアンテナを張らせてロールモデルを探してもらいましょう。他にもSREエンジニアや、AIエンジニアなど肩書系のエンジニア像を目標にするのも有効です。まず彼らがどんな能力を持っているかを部下と一緒に考えて、足りない能力を導き出し、育成計画を策定しましょう。
能力・適正の把握と受け皿の展望
育成計画を立てる際に重要なのは、部下の能力・適正の把握と、受け皿の展望である。適正の把握を怠ると部下の能力を殺してしまうことになりかねない。また受け皿の目処をを付けておかないと、せっかく開発した能力を活かせる場所がないということになる。部下の能力・適正発見の着眼点は以下の点が上げられる。
- 短所よりも長所に目を向ける
- 興味関心の方向を考える
- これまで手掛けてきた仕事を分析し、経験を活かすことを考える（特に年輩者の場合）
- 継続的に観察し、どの面がどのくらい伸びたかを整理する
- 人事考課、自己申告などの人事記録を参考にする
- 機会がなく、発揮できなかった能力にも目を向ける
エンジニアマネージャーとして
部下の適正という問題は、非常に難しいと思います。ですが、まずは好きだったり興味があるというのだけで十分ではないでしょうか。数学が苦手で興味もないけど、AIエンジニアになりたいという矛盾は普通は生じないでしょう。ただこのIT業界は市場・技術の変遷が早いので、キャッチアップし続ける必要がありますし、マネージャーは部下育成のためにもアップデートを続けなければなりません。そうでないと市場で価値のないエンジニアになってしまうかもしれません。社内で凄腕の熟練COBOL使いがいたとしても、新人にその道を歩ませるのかは良く考えなければいけません。
また受け皿問題ですが、あまり社内での受け皿を意識する必要はないと思います。3年後にあるであろうポジションが見通せる会社でしたらいいですが、見通せない会社がほとんどではないでしょうか。社内になくても、市場にあれば転職することができます。流動性の高い業界ですので、1社に固執する必要もないし、それだけの広い視野で部下の育成を考えて上げたほうが、部下からの信頼も勝ち取れるでしょう。
育成方向と個別育成計画
何をどれくらい身につける必要があるかがわかったら、次に考えるべきことはどのようにそれを身につけさせるかの手段を講じることである。知識・技能・態度のいずれを強化したいのかを考えて、適した方法を選ぶことになる。座学中心なら、部下をそれを確実に学習できるように工夫したり、実践の機会をあたえたりするような"場つくり"が管理者には求められる。また部下個人がやりたくても、上司の理解や配慮がないとやれないのは仕事の割当である。仕事の割当は職場の計画に直結したものであり、これが部下の育成の中枢をなすものである。
エンジニアマネージャーとして
たとえば、部下がクラウドサービスをもっと学びたいと希望しているとします。ですが、携わっているシステムがオンプレであり、社内を見渡してですらそのような機会がないという悩みも多いのではないでしょうか。もし、部下の欲求が会社のためになると管理者も強く思えるなら、クラウドサービスに携われる機会を上層部を説得してでも作り出しましょう。ゲーム会社でないのにUnityで遊んでみたいとかいう欲求には、「家でやってろ」で済みますが、テクノロジーに進化の流れでデファクトスタンダードになっていっている技術には、会社としてキャッチアップする必要はあるでしょうし、それが正義だと思います。
5.2.2 育成計画の中心は仕事の割当て方
人を育てる仕事のポイント
部下を伸ばし育てる仕事とは、それを手掛けることで"勉強になる仕事"である。ではどんな仕事が勉強になるかについて、基本的には2つの観点からとらえることができる。1つはその仕事に自由裁量の余地があるか、もう一つは本人がどれくらい経験し、熟達しているかである。それらを図にすると以下のようになる。部下を伸ばし育てるためには、部下がある仕事をマスターしたら新しい仕事に挑戦させると同時になるべく部下に判断を任せて、自由に腕をふるわせるようにしなければならない。
エンジニアマネージャーとして
マンネリしないようにタスクを振り分けるのもマネージャーの仕事です。熟達している人にその分野のタスクを渡したい気持ちはありますが、それでは誰の成長にも繋がりません。未熟な人にこそ裁量の余地があるタスクをお願いし、熟達している人にはメンターとなってもらうなど工夫しましょう。
職務拡大と職務充実
職務充実とは、それまで担当していた仕事の範囲内で、よりレベルの高い仕事に挑戦させること。 職務拡大とは、それまで担当していた仕事に加えて新たな仕事を任せ、仕事の幅を広げること。 職務充実では垂直方向に能力を高めていくのに対し、職務拡大では水平方向に能力を広げていくといえる。
エンジニアマネージャーとして
フロントエンドの畑の人が、フロント関連の仕事でレベルの高い仕事に挑戦するのが職務充実。バックエンドも、インフラもと新しい分野に仕事の幅を広げることは職務拡大となります。
権限委譲について
自由裁量の余地を大きくすることが部下の成長に繋がるといったが、言い換えれば、管理者はどのくらい権限を部下に委譲するかということである。委譲する権限は大きくわけると以下の3つになる。
- 目標
- 達成方法
- 必要な資源
全てを管理者が決めて、部下に「お前に任せるよ」と言っても、部下は任されたとは感じないであろう。なお、このような権限を部下に委譲できても「責任は委譲できない」ということは忘れてはいけない。管理者はその任せた仕事が失敗しても管理責任を追わなければならない。
5.2.3 仕事の進行中の指導のあり方
教えるよりも考えさせる
仕事の進行中の指導の基本は、部下自身に考えさせることである。基本的には部下自身に考えさせ、部下自身で問題解決を図らせるべきなのである。
エンジニアマネージャーとして
ググレカスは一見厳しいようですが、部下自身に問題解決させるという意味では方向性は正しいでしょう。技術的なことについては特に部下自身が調査検証しながら、解決していくのが本人のためになります。
指導のチャンスとキッカケ
部下の指導は"機会教育"といわれるくらい、タイミングをとらえた自然なものであることが大事である。日常のごく自然な指導の機会を整理すると以下のようになる。
- 部下が指示を求めてきた時
- 部下が報告してきた時
- 部下に指示・命令を与える時
- 職場会議を開く時
- トラブルが発生したとき
- 仕事が暇な時
5.2.4 評価
評価とフィードバック
部下の行った仕事や、とった態度・行動に対して何の評価もないと、自分のやったことが正しかったのか間違っていたのか部下からするとよくわからない。管理者は部下に仕事を任せるだけでなく、その結果と結果に至る過程、努力の過程に対して公平に評価し、なるべく具体的な事実をベースに部下本人に直接フィードバックしておくことが大切である。
エンジニアマネージャーとして
Slackで「いいね」アクションをつけるくらいの軽い感じでも、それが上司からなら部下本人は自信に繋がります。
無言の評価と信賞必罰
"無言の評価"とは、お互いがお互いを見る目であり、非公式に行われている評価である。"皆がしていること"はたとえそれが好ましくないことであっても"していいこと"であり、”皆がしていないこと”はたとえそれが好ましいことであっても、”する必要のないこと”なのである。「するべきこと」「してはならないこと」を管理者が職場の全員に明示するとともに自らが自分の行動として示さなけれなならないだけでなく、全員に対して例外を作らず厳しく守らせなければならない。信賞必罰はここまで徹底して行われてはじめて効果をもたらすのである。ときどき思い出したように信賞必罰をやってみてもたいした効果は期待できないであろう。
エンジニアマネージャーとして
社内セキュリティ上規定されていても、上司や周囲が破っていた場合に、管理者が咎めなければ、それは”やってもいいこと”になります。アクセスキーやユーザーの使いまわしなど、ついついやってしまうと思いますが、セキュリティ事故になってから、後で規定を持ち出されて懲戒処分となっても、部下は理解はすれど納得はしません。
しかるべき時にはしかる
真剣に本人のことを思ってしかるのは、部下もわかるし、必要なことである。しかし、そのしかる行為が管理者の自己保身からくるものであった場合には、信頼を失ないます。
- ほめるべき時にはほめる
人間は成長したり、難しい課題を解決したときは嬉しいものであり、周囲の人々から評価されたいものである。管理者はそんな部下の気持ちを見逃さずに、正当に評価しほめることが大切である。
エンジニアマネージャーとして
是非難しい課題を解決したりした場合には、管理者が率先して社内にアピールしましょう。LTなどを社内してもらったりなど、社内PRしてもらうなど、部下を担ぎ出すことも管理者の仕事です。
区切りごとの評価も必要である
評価・フィードバックは日常の中で絶えず行われるべきであるが、部下を育成するためにはまとまった評価も必要である。どんな評価をするかは次のように大別できる。
- 仕事の進行に合わせた不定期評価
- 毎年の定期評価
- 異動するとき
5.2.5 自己啓発
- 自己啓発の意味
OJTとOff-JT以外にも学習の方法としては「自己啓発」がある。自己啓発は知識・技能・態度はもちろん、仕事と直接関係ない面まで含めた「人間的教養」を自分自身で意識的に向上させることに大きな意味がある。
- 「学び合う」職場風土づくり
管理者は自らが自己啓発するとともに、部下の自己啓発に対する意欲を援助し、促進させる役割がある。自己啓発を尊重することにより、職場全員がお互いに切磋琢磨し、「学び合う」職場風土をつくることである。
- 「自己啓発」における管理者の役割
管理者は部下の自己啓発の内容をよく把握し、彼・彼女の学習意欲が絶えず向上するよう側面からバックアップすると同時に、自分自身も絶えず意欲を向上させる努力が必要である。
エンジニアマネージャーとして
自己啓発こそエンジニアの本分です。技術が大好きな人は言われなくても自己啓発を行いますが、社会人になって初めてエンジニアになるという人たちには、そのような習慣がないかもしれません。マネージャーとしては、そのような人たちに、なぜ自己啓発が大事かについて語れるようになりましょう。
以上、第5回 部下の育成でした。
