※2012年12月1日より新ブログに移行しました。自分で言うのもおこがましいですが、20代の頃に書いた本ブログよりも、30代に入ってから書いている現行ブログの方がはるかに中身が濃く、内容が多岐にわたり、面白いと思いますので、是非ご覧いただけるとありがたいです!
>>>現行ブログ free to write WHATEVER I like
August 25, 2010

人材育成計画の立案時に陥りやすい4つの落とし穴(1)

拍手してくれたら嬉しいな⇒
 先週は2回にわたって、戦略とリンクした人材育成計画を作成するためのポイントを整理してきた。要点を繰り返すと、まずは戦略を実行するための業務プロセス=「社員に期待する行動」を定義し、それに基づいて社員に求められる能力(知識・スキル)を洗い出す。そして能力をレベル分けし、それぞれのレベルに該当する社員の目標人数を設定する。その上で、目標人数の達成に向けた育成体系を、各能力の性質やレベルに応じて策定する。さらに、各社員の能力レベルを定期的にモニタリングする仕組みを計画段階で構築しておく。これが人材育成計画の要諦である。

 戦略とリンクした人材育成計画を作成するための5ステップ(1)
 戦略とリンクした人材育成計画を作成するための5ステップ(2)

 人材育成計画は事業戦略の内容から論理的に導かれるものであり、さらにPDCAサイクルを回せるような仕掛けを計画段階で組み込んでおくことが重要だという、言ってしまえば至極当たり前のことなのだが、実際にはすんなりといかないことも多いように思える。あまりうまく機能しない人材育成計画は、以下の4つの落とし穴にはまっている。

(1)現状を見ながら足りない能力を洗い出してしまう
 人材要件は戦略の内容からトップダウンで導かれるものだが、往々にして現状の社員を見ながら、「営業の提案力が足りない」、「若手社員にコミュニケーション能力が必要」、「ミドルマネジャーにリーダーシップを発揮してもらいたい」といった具合に、感覚的に能力を洗い出そうとすることがある。もちろん、議論の取っ掛かりとしてボトムアップのアイデアベースで始めることが悪いとは言わないものの、それだけで能力定義を終わらせると、非常に浅い分析に終わる。

 ボトムアップで議論を進めると、能力を抽象化しすぎてしまう傾向がある。「営業の提案力が足りない」と言った場合、どのような提案力を指しているのか?SIerを例に取れば、
 
 ・顧客企業の業務に対する深い理解を武器にし、現状プロセスの詳細な分析を通じた提案を行うのか
 ・顧客企業の中長期的な戦略やビジョンに基づいて、IT戦略の立案も支援するのか
 ・コンサルティング会社のように、IT以外のソリューションも包括的に提案するのか
 ・自社製品の差別化要因を全面に打ち出した提案を行うのか(よほど自社製品が市場で強くなければ難しいが…)
 ・(あるいはちょっと違う視点で、)顧客企業内の利害関係者とのリレーション構築を重視し、RFPが出る前に提案の機会をもらうことを目指すのか

 などのように、様々な提案力が考えうる。これらのうち、いったいどれのことを提案力と言っているのかを明確にしなければ、議論は先に進まない。

 同様に、若手社員のコミュニケーション能力やミドルマネジャーのリーダーシップについても、それらの能力の向上によって何を目指しているのかを明らかにする必要がある。顧客との関係の改善・強化を志向しているのか、社内業務の課題発見と改善を促すのか、後輩や部下の能力開発をうまく行うことを期待しているのか、あるいは会社が戦略的に取り組んでいる部門横断型プロジェクトで高い成果を上げることを求めているのか?この点がクリアになって初めて、能力が定義できたと言える。そして当然、こうした分析は、将来的に実現したい戦略との関係の中で行われるべきなのである。

(2)個々の社員の能力レベルを考慮しない学習プログラムを強制
 ビジネスマナーや基礎的なPCスキルのように、全社員が必ず身につけるべき能力については、単一の学習プログラムで能力を平準化することは何の問題もない。だが、たいていの能力にはレベルの高低が存在し、各社員の能力レベルもまちまちである。こうしたレベルのばらつきを考慮せずに画一的な学習プログラムを強制したり、特定の社員にとって難しすぎる、あるいは逆に易しすぎるトレーニングを企画したりすることも、よく見られる過ちである。

 私が前の会社でプログラマーをしていた頃の話だが、人事部がシステム開発のプロジェクトマネジメント研修を導入したことがあった。この研修は全社員を対象とした必須研修であり、いわゆるウォーターフォール型のシステム開発プロジェクトをマネジメントするスキルの習得を目的としていた。

 しかし、私や私の同期がこの研修を受けた(受けさせられた)のは入社1年目のことである。当時、アジャイル開発などが登場し始めていた頃だったから、「何でいまさらウォーターフォール型なんだ?」という疑問がそもそもあった。まぁ、百歩譲ってウォーターフォール型は許すとしても、入社1年目で詳細設計書からプログラムを起こすことをメイン業務としていた人間が、要件定義や業務プロセス分析のスキルをすっ飛ばして、プロジェクトのプランニングやリソース調達、顧客企業とのネゴシエーションについて学習させられたら、「何のこっちゃ解らん!」と不満たらたらになるのは想像に難くないだろう。

 (その2へ続く)

おススメの書籍

トラックバックURL

このエントリーのトラックバックURL:

コメントする