Tbpgr Blog

Employee Experience Engineer tbpgr(てぃーびー) のブログ

peopleware | 人材を揃える

概要

人材を揃える

人材の選び方について

書籍

標準的な人材を採用し、標準基底に準じて作業させることを重視してはいけない。
優秀な技術者は標準的ではなく、標準基底にはめ込むと生産性を落とす。
人材の育成、規定・標準化等などによる生産性向上分よりもどれだけ良い人材を採用するかのほうが重要。
良い人材を雇えば管理者が大した努力をせずとも成功が待っている。
技術者は接客、営業などとは外見に対する重要度の比重が異なるので同じ基準で採用しないこと。

現実

標準と生産性に関しては他の書籍にも多くあったが、標準化による利益を得るのは
あくまで平均以下。アドリブがきく暗黙知を蓄えたドレイファスモデルでいうところの
達人・上級プログラマーを標準に当てはめることは足かせを付けることにしかならない。

以前チームメンバーにいた若手天才プログラマーは型にはめずに出来るだけ自由にやってもらったが
相当なパフォーマンスを発揮してくれた。

また別の現場では高レベルな開発者を低レベルな開発手順を守らざるを得なかった。
結果、生産性は低く抑えられ、開発が終わると高レベルな開発者は全員去っていった。

人材の育成よりも採用が重要という件ついては同意。
いくら教えても覚えるつもりのない開発者や、自主的に学習・復習しない開発者は
そうではない開発者と比べて圧倒的に差がある。仮にその時点で差がなくても明らかに
差はできてくる。
やる気のない社員に教育費用をつぎ込んだところで、効果はたかが知れている。
学ぶ気のない開発者には手順を伝え、詳細に指示し、標準にそって作業をしてもらいます。
学ぶ気のある・熱意のある開発者にはノウハウを伝え、逆にノウハウを教えてもらい、自発的に作業をすすめてもらい、
ペアプロやアイデアフラッシュで相乗効果を狙います。

採用時に留意すべきこと

書籍

技術者の履歴書、職務経歴書と面接だけを行っても意味が無い。
理想は過去の作品を見せてもらうこと。
技術者の採用にも関わらず技術力を見ないのはサーカス団員の採用時に
サーカスの腕前を見ないで話だけを聞いて採用するようなもの。

また、開発はチームで行うものであるためコミュニケーション能力を見ることも重要。
コミュニケーション能力やチームへの適性を見る一例としてオーディション形式にして、
採用担当者だけではなく将来同僚となる人たちも含めて判断する方法がある。

現実

機密などにより、過去の業務の作品が見れない場合(ほとんどそうだろうが)
1・ペアプロによる面接
2・自発的に学習・公開しているコード
3・事前課題(穴埋め問題のようなテストではなく、何か目的を持ったもので
明確な1本道の正解があるわけではないようなものがよい)
などが良いと思う。1については人物・技術双方をよく理解出来る良い方法だと思う。
2についてはその人がどれだけシステム開発に熱意を持っているかが明らかになるし、
少なくともほっておいても自分で成長してくれる人であることが分かる。
要は出来るだけ、業務に近い形でその人の技術的思考・人間性を見ることが重要に思える。

反対に現実の失敗例。(自分が採用担当だったわけではないが)
・技術に詳しくない担当者が人事権を持っているために、新たな社員・協力会社の
開発者の多くが全く開発力の無い「はずれ開発者」だったりする。
職務経歴で列挙した内容が今回の案件の条件に近いかどうかだけを見て
最低限のマナーがありそうなら採用する、というのが下請け型開発現場の採用で
よくあるパターン。
Java歴10年でまともにJavaのコードを書けない開発者なんてしょっちゅういます。

エンドユーザーの手前、頻繁にチームメンバーを入れ替えるわけにもいかず
何かの区切りがあるまでは戦力にならない人材もそのまま在籍させる。
結果、人数的にはリソースは足りているが実際は有能な開発者数名が作業している
ような状況になり作業が遅延していく。

退職のコスト

書籍

退職のコストを甘く見ない。
退職が多い企業では長期的視点が欠ける。
退職が多い企業では開発者へ提供する環境が劣悪。(もしくは開発者の求める環境を理解していない)
退職者が多くなる要因をきちんと分析し、状況を改善すること。

現実

退職に関しては書籍の記載に同意。
下請けを利用している場合は、下請けを使い捨てるような会社も多々あるが
そういった会社は下請けの各開発者間ですぐに噂になるため長期的には
いい開発者が近寄らなくなる可能性が上がる。
システム開発の世間は狭いので噂はすぐ伝わる。
劣悪な現場が多い分、良い環境を提供出来れば良い開発者が長くとどまってくれる。