スキルシートでいったい何が分かるのか：開発チームを作ろう（1）（3/3 ページ）

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

スキルシートの内容を見直す

実は足りないスキルシートの情報

　さて、ここで彼が不幸になった原因を考えてみましょう。もともと、彼はスキルシートと所属する「仲介業者」の推薦でプロジェクトに参画しました。プロジェクトに参画してしまった理由……。採用理由である「スキルシートで人を集めること」を考えてみます。

　まずはそのために、プロジェクトを遂行するのに必要な能力と、スキルシートから分かる能力を対比してみました。スキルシートといえば大体こんな表ですね。

スキルシートのイメージ（クリックすると拡大）

　ここから分かるものといえば、名前や年齢、通勤距離といった基本的な個人情報。また、技術経歴の羅列……。つまり、どんなプロジェクトを、どんなロールでどのくらい経験しているかを「品質を問わず」記載しているだけです。さて、その要素を比較してみましょう。

（1）システムを作るための重要ファクター

• 論理思考性
• ロールごとの経験（年数）
• 経験（業務的）
• 多様性（業務的）
• 経験（技術的）
• 多様性（技術的）
• SE的センス
• PG的センス
• MG的センス
• 営業的センス
• コンサルティングセンス
• 技術的先進性
• 健康（体力）
• やる気
• やられる気

（2）スキルシートで分かるもの

• ロールごとの経験（年数）
• 経験（業務的多様性）
• 経験（技術的多様性）

（3）面談で分かるもの

• やる気
• やられる気
• センス少々

　以上のように、実はプロジェクトに必要な多くの情報を、スキルシートからは得ることができません。われわれはいかにいいかげんなもので人を「売り買い」しているか分かるでしょう。もしかしたら面接のプロは「営業的センス」などさらに多くの情報を得ることができるのかもしれません。でも、プロジェクトマネージャを任命する決裁権者の方、考え直してみてください。あなたは「人を見る目の素晴らしさ」でプロジェクトマネージャを任命されましたか？ 社内の所属や地位、「本人の似たようなプロジェクト経験」で決定しませんでしたか？

　いやそのことが問題だといっているのではありません。もし、「人を見る目の素晴らしさ」で選んでいないのであれば、別の方法で「人の選別に手を貸す必要」がありませんか？

判断を誤らせる「業界の事情」

　今回の例でいえば、ロールや技術の種類や経歴の長さは評価の対象になっていますが、品質については何も情報を得ていません。

　しかしそれ以前に、スキルシートと実際の能力の乖離に関して、判別を誤った大きな理由があります。それは、協力会社とプロジェクト元請け側の会社対会社の関係があります。簡単にいってしまえば、「業界は常に人不足」です。その状況で元請けも人集めに関しては「無理をいって1カ月で集めてもらう」といった状況になりがちです。特にこういった「佳境の増員」は得てして上記のようなシチェーションにある場合が非常に多いのです。

図4 会社同士の関係

　そうなると、マネージャもリーダーも「選別」などしていられません。「協力会社に無理をいって集めてもらった」状況ではなかなか「スキル的に不安なので別の人を……」といい出しにくい状況になってしまいます。また元請け自身も工数予定表に割り当てられた作業員が一向に現れないのでは顧客に説明ができなかったりもします。

　スキルシートの情報量の少なさに加えて、こういった「基本は通す方向で検討しなければならない」現場の苦労も加味され、「適材適所」はますます現実離れしたものとなっていきます。

---

　今後、何回かの連載を通して、さまざまな事例からこういった業界自体の課題を含めた「問題点」を洗い出していきたいと思います。またそのうえで、「問題点を回避する手法」を皆さんと編み出していければと思います。

• そもそも協力会社にも元請けにも「取りあえず通す」しかない現場の事情がある
• スキルシートでは実力の20％程度しか分からない
• 切るのも簡単ではない
• 環境など自身以外の問題をブロードキャスト的にチーム全体に訴え続ける人は危険
• 極端に長い単一プロジェクト経験は、環境即応性や環境要素に対する経験のバラエティを奪っている恐れがある
• 不適材不適所になってしまったらプロジェクトに居続けるのは難しい

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

• スキルシートと単金だけで開発チームは作れない
• 良い顧客が良いITプロジェクトを作る
• すごい技術者はすごいマネージャになれるか？
• エンジニアにとっての本当の「顧客」は誰？！
• エンジニアのやる気は報酬だけじゃ維持できない
• スキルシートでいったい何が分かるのか