メディア

スキルシートと単金だけで開発チームは作れない：開発チームを作ろう（6）（3/3 ページ）

» 2008年01月22日 12時00分公開

[佐藤大輔，オープントーン]

チームメンバーを選定・評価する本当の指標

　ここまでの5回の連載の分析からが5つのケースから抽出されました。

生産性
必要性
技術力
調整力
責任感

　さて、最初に述べたようにITプロジェクトの基礎はQCD以前に「人」です。そして、すでにお話したようにITプロジェクトは複雑すぎて単純にマニュアル化することは不可能です。ゆえに、「マニュアルがなくても成功するチームを作ればいい」「チームを作るマニュアルがあれば“黄金のリンゴの木への地図になる”」というのが連載の最初で述べた論旨でした。以降、「いいチームを作るマニュアルは？」という視点で5つのファクターをピックアップしました。すると下の図のようにチームメンバーの選定と割り当てるロールの検討……、つまり開発チームを作るときの新しい指標が見えてきます。

　マネージャの方は、メンバーを集める際に、コストが高い安い、人手不足だから……という前に一度これらのファクターで測り直してみてはいかがでしょうか？技術力だけがあるメンバーをいくら集めても、ITプロジェクトがいい形で達成されるとは限らないということです。振り返ってメンバーの方はいかがでしょう。自分が技術力以外の上記の部分で欠けているものはないか、それが自分自身の評価の足を引っ張っていないかを考え直してみてはいかがでしょうか？

指標評価の例

	1	2	3	4	5
	著しく劣っている	劣っている	普通	優れている	著しく優れている
生産性	ほかのメンバーの助けが定常的に必要である	1日0.8～0.9程度の効率である。ほかのメンバーの助けがしばしば必要である	普通	10％から20％程度優れている。自分の分担範囲を早く済ますことができる	他人の分担範囲を支援できる
必要性	引き継ぎが2日以下でも、交替が可能である。金額さえ調整すれば交代が容易に用意できる	プロジェクトに1作業員以上の貢献はない。代替が比較的短期間の引き継ぎで可能である	普通	積極的に他の人の仕事を支援するなどして、必要とする人が多い。細かく地道な作業などを丁寧にこなすなどして、重宝がられている	ほかに変える人材がない。顧客・開発組織（自社）・チームメンバのすべてのステークホルダーが必要としている
技術力	著しく劣っている。もしくはまったく経験がない	学習した程度はある。類似した技術経験がある	普通	チーム内に教えることができる。自身でも学習をしている	執筆なども可能である。他社にコンサルティングができる
調整力	自身あるいは、チーム内の利害しか調整できない	見える範囲の利害しか調整できない。直接契約している相手のみを満たすことができる	普通	直接利害関係にあるステークホルダーの満足が得られる。顧客の顧客や他ベンダなど2次的な利害関係者から不満を持たれない	すべてのステークホルダーをバランスよく満たせる。説得力があり、論理的に説明をし、満足を得られる
責任感	自分の責任分担範囲を明らかに狭い範囲で固定している。複数の第三者からみて、責任感が欠如している	責任が自分の分担範囲にとどまる。意図的に分担範囲を広げないようにしている	普通	他人の仕事に気遣いができる。アドバイス程度であれば惜しみなく行う	他者・他社の心配までできる。プロジェクト全体を見通して、その責任の一部を負うことができる

「天国」プロジェクトの条件

　さて、各回ごとにアンケートを取ったわけですが、まずその回ごとに貴重なご意見をいただいた皆さまに感謝を申し上げます。1人1人のご意見に私が会議室上でお答えするのもなんでしたので、まとめてブログか何かで答えさせていただきます。

　アンケートを出す時点で、ある程度結果を予測して（次の記事の内容も視野に入れて）出させていただきました。書き込みの意見では素晴らしいものも多く、しばしば記事の内容を変更せざるを得なくなっていたことを付け加えておきます。

1．経験が長いが生産性が悪いメンバーがチームに入り成果が挙げられないのは1．経験が長いが生産性が悪いメンバーがチームに入り成果が挙げられないのは

スキルシートで売り買いする業界の体質
教育などのプロセスがない開発プロセス

2．もっとも技術者としてモチべーションが上がるのは2．もっとも技術者としてモチべーションが上がるのは

金銭的報酬
顧客の評価

3．ITプロジェクトの運営で最も重要なことは3．ITプロジェクトの運営で最も重要なことは

メンバーのスキル
マネージャのスキル

4．見積もりで？システムの規模の次に最も影響するのは4．見積もりで？システムの規模の次に最も影響するのは

営業的事情
チームのスキル

5．顧客に最も理解してほしいのは5．顧客に最も理解してほしいのは

概念仕様への理解

　無理やりですが、これをつなげますと、業界の体質的な元請け下請けの構造がなく金銭的な報酬が十分に得られて、メンバーのスキルがよく、営業的な事情がよく、顧客が仕様を理解しているプロジェクトがこの世で最良の「天国」プロジェクトでしょうか。

　皆さまの周りはいかがでしょうか？

筆者プロフィール

佐藤大輔（さとうだいすけ）

「開発チームを作ろう」バックナンバー

前のページへ 1|2|3 　　　　　　