ブログ

プロジェクト管理:要員管理とは~能力と配置計画の進め方とツール・事例~

  • このエントリーをはてなブックマークに追加

能力の見える化と配置計画によって要員管理力をアップ!

プロジェクトの成否は、スタッフ(要員)の能力によって左右されると言っても過言ではありません。
ベテランぞろいのスタッフでプロジェクトを遂行できることはありません。新人、ベテランなど能力差があるスタッフでプロジェクトを進めなければならないのです。
偏りやバラツキがあるスタッフの能力を把握しバランスよく配置してプロジェクトを遂行するための要員管理の方法をツールと事例を交えてご紹介します。

 ・個人の能力と組織の能力
 ・プロジェクトメンバーに必要な能力
 ・人材の能力の見える化
 ・経験の見える化
 ・開発プロセスと手順の標準化
 ・業務担当範囲の見える化
 ・ペア制でマルチスキル化
 ・定期ローテーションで標準化とマルチスキル化
 ・担当別開発からチーム開発への配置
 ・業務の割り当ての見える化

個人の能力と組織の能力

最初に、能力について考えてみましょう。
能力には、個人の能力と組織の能力があります。
個人の能力が集まったモノが組織の能力だと考える人もたくさんいますが、はたして、それだけでしょうか?
サッカーの例で考えてみましょう。
個人の能力は、選手、一人ひとりが持っている能力です。
味方にパスを的確に回す能力。
味方や敵の次の動きを先読みして、次の攻撃に向けたパスを正確に打つ能力。
敵よりも速く走り、優位な位置に移動する能力。
どんな無理な体勢からでも瞬時にシュートできる能力。
このような高い能力を持っている選手を試合に投入すれば、試合に勝てるのでしょうか?
能力を寄せ集めただけでは、試合には勝てません。
どのようにすれば試合に勝てるのでしょうか?
パスを回して、スペースをつくり、空いたスペースへ先読みして、パスを打つ、同時に空いたスペースに、敵よりも速く入り込んで、瞬時にシュートする。
このような一連の連携したプレーがシュートにつながり、ゴールして、試合に勝てます。
ただ、能力を集めただけでは、シュートにつながりません。
連携したプレーが組織の能力です。
組織の能力は、個人の能力に加えて、能力を適材適所に配置し、組み合わせて、相乗効果を発揮させる力のことです。能力を共有し、補い合い、時に刺激し合って高め合う力のことです。
能力の高い個人を集めても、それをうまく活かせる力がなければ、宝の持ち腐れです。
活かされない個人の能力は、衰退するだけです。

プロジェクトメンバーに必要な能力

マーケティングや企画・開発などを行うプロジェクトチームのメンバーに必要な能力について整理してみましょう。
プロジェクトチームには、様々な役割を持った人がいます。
役割が変われば、必要とする能力も異なります。
例えば、新人、中堅、プロジェクトリーダー、プロジェクトマネージャーの、それぞれに求められる能力の違いはどのようなものでしょうか?
必要な能力には、開発などをするために必要なテクニカル・スキル、チーム開発をするために必要なヒューマン・スキル、プロジェクトを管理するために必要なコンセプチュアル・スキルがあります。
役割に応じて、持つべきスキルの割合は異なります。
プロジェクト管理では、どのような仕事、どのような役割に、どのような能力が必要か明確にしなければなりません。
次に、必要な能力を持った人を適材適所に配置し、組み合わせて、相乗効果を発揮させる配置をしなければなりません。

人材の能力の見える化

適切な配置をするためには、誰がどのような能力を持っているのか把握しなければなりません。
そのためには、保有能力をアセスメントなどによって調査します。
アセスメント結果は、単に保有能力の評価だけをするのでなく、今後の能力開発の方向性などを明確にしたキャリア・プランとしてまとめます。
継続して高めていくべき能力も明確にしなければなりません。
把握した能力は、スキルマップなどによって、必要とする開発作業などと関連づけて「見える化」します。
チーム全体としての能力の分布や偏り、過不足を「見える化」して、偏りや過不足を是正する対策を行います。
スキルマップなどで能力を高めるべき作業と人を特定して、必要な教育を行います。
教育指導者も「見える化」することで、指導の責任を明確にして、教育が後回しにならないようにします。

経験の見える化

能力は、教育をしただけで高まるモノではありません。
実務経験によって深まるものです。
能力を管理する上で、経験を「見える化」することは重要です。
しかし、経験が「ある」、「無し」だけでは、能力があるのか、無いのか、わかりません。
どのようなことを経験したのかが、重要です。
成功や解決、壁を乗り越えた経験を見える化し、共有することに有効な手法に「ピースボード」があります。
個人が成し遂げた成功経験を書き出し、互いに賞賛し、認め合うためのボードです。
自分の成功経験を過小評価する人、忘れている人もいます。
思い出して、書き出して、周りからの客観的評価を受けるのです。
「ピースボード」によって有効で価値ある経験を「見える化」することができます。
逆に、失敗経験も「見える化」することも必要です。
「チェンジボード」は、失敗したことを書き出し、互いに原因や解決策を検討し、忘れないようにするためのボードです。
失敗を忘れてしまう人、失敗を振り返らない人もいます。
失敗から学ぶ姿勢を醸成し、失敗を糧に、より良い仕事を考えさせるようにします。
失敗は、成功からは得られない学びを与えてくれます。
大きなリスクのある開発には、失敗を経験した者の参加が不可欠です。
「チェンジボード」によってリスクに向き合った経験を「見える化」することができます。

開発プロセスと手順の標準化

能力を管理するときに忘れてはいけないのが標準化です。
開発プロセスや手順が標準化されていないとどうなるでしょうか?
標準化されてない部分は、担当する個人の知識や経験に依存します。
標準化の程度によって、個人能力への依存度は変わり、個人の能力レベルに開発は大きく左右されてしまいます。
個人能力に左右されず、一定の開発レベルを維持するためには、標準化が不可欠です。
プロジェクトの能力管理は、開発業務の標準化を進め、人の能力レベルに左右されない領域を増やすことをめざします。
人の能力レベルに左右される領域が少ないことが、要員配置の自由度を大きくし、配置計画をし易くします。

業務担当範囲の見える化

要員の配置管理では、最初に業務の担当範囲を明確にします。
通常は、製品やテーマ単位で担当を決めます。
製品やテーマ単位の担当割り当ては、責任範囲が明確になり、管理もし易くなりますが、担当外の製品やテーマに対して知識も経験も高まらず、互いに助け合うことができないため、個の集団となってしまいます。
個の集団では、開発ボリュームの変動への対応ができず、開発力が個人の能力の枠を超えることはありません。
チームとしての開発能力は高くありません。
チームとしての開発能力を高めるためには、個々の能力が絡み合い、協業する関係となるようにして、個の集団から脱却する必要があります。
そのためには、業務の担当配置を、製品・テーマ別配置から、製品・テーマ・プロセスのマトリックス配置に変えます。
マトリックス配置にすることで、製品・テーマの経験範囲が広がるだけでなく、隣り合ったプロセス間で協業が発生して、チームとして助け合い、開発ボリュームの変動にも対応できるようになります。
開発力は、個人の能力の枠を超えたものとなります。
製品・テーマ別配置を、製品・テーマ・プロセスのマトリックス配置に変えて、担当していなかった製品やテーマの開発をさせようとしても、それは、すぐにはできません。
各担当のマルチ・スキル化を行わなければなりません。

ペア制でマルチスキル化

製品・テーマ別担当制では、開発を通じて、それぞれの担当が自分流のやり方を作り上げてしまいます。
この自分流のやり方が担当制の溝をさらに深いものにしてしまい、相互の知恵を共有したり、協業する事を阻む最大の原因となります。
まず、この自分流のやり方を崩して、相互に理解でき、助け合えるやり方に転換させなければなりません。
そのためには、自分流のやり方が通用しない環境を作り上げてしまうのです。
組織の最小単位は、二人です。
この最小単位の二人で開発を行う体制を導入して、組織の基礎をつくりあげていきます。
開発をペア制にします。
二人で、顧客や製品を担当させるのです。
ペアの中で、さらに顧客や製品別に担当を分ける事は禁止します。
二人の中では担当はなく、二人で1つという体制にします。
ペア制によって開発の標準化もできあがっていきます。
開発を手伝ったり、交代しながら行うことで、最小単位の協業が始まります。
ペア制によって、マトリックス配置に向けた標準化と協業化ができるようになります。

定期ローテーションで標準化とマルチスキル化

長い間、同じ製品やテーマを担当し続けることで開発に精通して、任せて安心のベテランが育っていきます。
担当も開発に自信を持ち愛着を持つようになり、会社としても開発の品質や生産性が高まりベテランづくりは良いこととされています。
しかし、長い担当期間は、ノウハウが個人にどんどん蓄積され、周りからはまったく見えない状態になっていきます。
開発と人を固着させ、異質なモノを嫌い、新たなモノを取り入れて進化する事を阻みます。
自分流も強固なものとなり、標準化をまったく受け付けなくなってしまいます。
これが個の集団からの打破をより難しくしています。
このような膠着した状態を打破するにはどうすればよいでしょうか?
最大の原因は、長い間、担当が変わらない事です。
担当を替えない事で開発が安定しています。替える事は恐怖です。
しかし、この恐怖を乗り越えて、担当を替えなければ、この状態を打破する事はできません。
担当の定期ローテーションが、開発の共通化、共有、協業体制を強化して、より一層の組織の戦力化を進める方法です。
定期ローテーションは、その名の通り、定期的に、強制的に配置替えをします。
3年を目処に配置替えをしていきます。
職場では、任せて安心のベテランが交代してしまう事に抵抗します。
管理者は、担当を替える事での問題や難しさを訴えてきます。
しかし、その抵抗を押し切ってローテーションします。
問答無用にローテーションをするとわかっていれば、管理者は事前に、開発の標準化やペア制などを行い、担当替えに備えるようになります。
担当替えの問題や難しさを訴える管理者は、開発の標準化や協業体制といった手を打ってこなかった管理者です。
ローテーションは管理者の意識改革にもつながります。
ローテーションによって、お互いの開発の理解が進み自分本位ではなく、組織全体としての視点で考えることのできる人材が育っていきます。
ローテーションを通じて、他の人との絆ができて人的ネットワークが形成されていき、協力意識が高まって協業が進むようになります。

担当別開発からチーム開発への配置

チーム開発へ開発体制を変えることも開発力を高めるのに有効です。
製品・テーマの開発を担当に割り当てた「担当別開発」では、各製品の開発を同時並行で行います。
各担当者が企画・計画から順に、設計、試作、試験評価を実施していきます。
同じ時期に同じ業務が行われ、最後に集中的に完了します。
同時進行であるために、開発システムや試験機などが、同じ時期に必要となり、取り合いになります。
開発は進行途中であるため、それぞれの開発経験は相互に活かすことはできません。
特に、試作や試験評価などから学んだ実践的ノウハウを活かすことができないのです。
チーム開発は、チーム全員で、1つの製品を担当して開発をしていきます。
製品を順に開発していくため、開発システム・機器を取り合うことはありません。
リードタイムは短くなり、先行する開発経験が、次の製品開発に活かされて、開発品質や生産性は高まります。

業務の割り当ての見える化

配置管理では、日々の業務の割り当ても管理しなければなりません。
担当別ストアボードは、日々の業務を誰に割り当てるのか「見える化」します。
業務を作業カードに書き出して、配置マップに基づいて、各担当に割り当てます。
協業となる業務は、朝会などで担当を調整します。
業務負荷が偏ったりした場合も朝会などで調整して、負荷の平準化を行います。

  • このエントリーをはてなブックマークに追加

関連記事

ページ上部へ戻る