« 【補助線】問題はなかったことにしよう | メイン | 【補助線】人だけが成長し、組織が成長しないと、人はジレンマに陥る »

2007年6月 9日 (土)

【補助線】メンバーのスキルの低いチームをどう運営していくか

チームをマネジメントするとはどういうこと?

の中で、僕自身、このテーマは後で書くといったことをすっかり忘れていた。コメントを貰って思い出した。ありがとうございました。

この話は本質的な解決というのはないと思っている。それは多くの人が感じていることだろう。ぼくが言いたいのは、パラダイム(ものの見方)を変えようということだ。

たまたま、昨日、「問題はなかったことにしよう」という記事を書いたが、実は、メンバーのスキルの問題もここから始まる。多くの人がプロジェクトには問題がないと思いたい。だから、スキルの低いメンバーなどいるはずはないし、いたとしてもそれは一時的なことであって、変わっていくと考えたい。こういう話になる。

このような問題を直面しないままにこの問題を考えてみても、解決策はおろか、問題への応急処置をして前に進んでいくことすら難しくなる。

まず、最初にすべきことは、それを問題としてみるのではなく、現実として認識することである。その人はそれだけのスキルかないと認め、スキルそのものを想定に近づけようとは思わないことだ。

つまり、想定している生産性で仕事が進むことなどありえないと考える。ここが受け入れられるかどうかが最大のポイント。そして、育成は別の問題だと考える。

これがパラダイム転換。

念のために言っておくが、想定納期ではできないとステークホルダに対して開き直れといっているわけではない。この現実を認めた瞬間に、想定納期は「ストレッチされた目標」になる。これをスキルの低い人に責任をおっかぶせるではなく、チームとして計画的に対処する方法を考える。これがマネジメント。

すると、仕事の進め方が変わってくる。PMBOKで、WBSOBSでフォーメーションを設計し、RAMで統制するという考え方はリソースの能力が均質で、スキルセットが揃っていることが前提になっている。ゆえに、スキルセットが揃っていなかったり、能力にでこぼこがあるとすれば、このようなスキームは使えない。

工数見積もり(生産性の調整)でカバーできると思う人がいると思うが、もし、できるならそれでOK。パフォーマンスの違いは生産性で調整できても、スキルセットのギャップは調整できないケースが多いので、みんなが頭を悩ましている。

スキルの低い人がいることを前提として考えると、仕事の分解の際に仕事そのものにグレードをつける必要がある。例えば、スキルレベルをA、B、Cとすれば、生産性ではなく、仕事の内容で、Aランクの仕事、Bランクの仕事、Cランクの仕事とする。

ITであれば、テスト、コーディング、プログラム設計、システム設計といった業務セグメントの難易度ランクはすでにあり、この範囲ではスキルレベルを調整している(現実には人手不足でできていないとしても、そういう考え方になっている)。

ここでさらに、それぞれの仕事の中を分解して、グレードをつける。例えば、テストであれば、テストのロジック設計をする人、テストのドキュメントを書く人、実際のテストをする人、環境設定をする人といったグレーディングをする。そして、グレードにあった人を割り振っていく。スキルレベルが揃っていれば縦割りの分担をするが、それを横割りにして分担をする。

こういう風に仕事を分解すると、実は、技術的な意味での専門性が必要になるのは、各セグメントでトップ、あるいは、2番目くらいまでのグレードである。それ以下のグレードは、技術的な専門性よりも、ドキュメントを書けるとか、正確に仕事をできるとかいったコンピテンシーの方が重要である。

ということは、セグメントに横断的に人材を活用できる。これにより、Bランクや、Cランクの仕事の一部を経験しながら、いろいろな仕事を見ることができる。これがひとつ、育成的視点からは重要なところだ。単に技術を覚えさせるだけではなく、仕事をするというのがどういうことかについて多様な経験をする機会になる。

技術的なスキルについては、そのような仕事をしながら、アシスタント的な仕事をする中で覚えさせればよい。これを下手に、専門性などで担当を決めて、設計者の仕事は設計をすることであって、ドキュメントを作ったりすることではないなどとやっていると、ロクな人材が育たない。下積みとして、自分の仕事に関連することを全て経験するというのは、日本型経営の優れた点だと思うし、今後も維持し続けるべき点だと思う。

こういう工夫をしているプロジェクトは結構ある。うまく行っているところも多い。繰り替えになるが、日本の組織というのはかつてはこういうやり方をしていたのだ。それをもう一度、プロジェクトマネジメントの枠組みを使って、体系的に実行してみようという話だ。

【補足】(2007.06.11)

多くの生産型プロジェクトにおいては、人のパフォーマンスを向上させることは、チームのパフォーマンスを向上させるためのひとつの手段に過ぎない。チームの目標を達成するために人のパフォーマンスをあげるのであって、個人の目標を達成するためではない。

これは、WBSのように目標のブレークダウンをする方法を使って全体をコントロールしていても本質的には変わらない。

この範囲で、個人の目標を達成することはチームの目標を達成するための最有力な方法である。しかし、それがすべての方法ではない。

特に、目標がストレッチされた目標である場合には注意を要する。例えば、チーム10人で15の仕事をしなくてはならない。このときに、各人に15を10等分して1.5ずつを割り振ってしまうと、まず、できない。おそらく、潜在的に1.5の能力をもつメンバーにおいてもその目標は達成できないだろう。

10人で15の仕事をやるには、15のままで扱い、10人が助け合いながらやっていくことが必要だ。PM的に言えば、おそらく、0.7~0.8を分けておき、残りの20~30%の時間をチーム作業として吸い上げ、指揮していくことが必要である。これがチームワークというものだ。

トラックバック

このページのトラックバックURL:
http://bb.lekumo.jp/t/trackback/605869/31148623

【補助線】メンバーのスキルの低いチームをどう運営していくかを参照しているブログ:

» スキルとプロジェクト (SAP BWなど経営分析システム導入のナレッジイールド)
最近よく読む、好川氏のBLOG メンバーのスキルの低いチームをどう運営していくか [続きを読む]

コメント

コメントを投稿

PMstyle 2024年5月~8月Zoom公開セミナー(★:開催決定)

カテゴリ

Googleメニュー

  • スポンサーリンク
  • サイト内検索
    Google

最近のトラックバック

Powered by Six Apart

プロフィール

フォトアルバム

好川哲人

技術経営のコンサルタントとして、数々の新規事業開発や商品開発プロジェクトを支援、イノベーティブリーダーのトレーニングを手掛ける。「自分に適したマネジメントスタイルの確立」をコンセプトにしたサービスブランド「PMstyle」を立上げ、「本質を学ぶ」を売りにしたトレーニングの提供をしている。