（事例付き）選ばれないスキルシート
案件ガチャ…先達て、SIerガチャのエントリを書いたが…気のせいか。
それはさておき、スキルシートを引用している画像のように書くと選ばれるのだそうだ。
確かに、よくあるスキルシートよりはわかりやすい。
参考にならないと思うが、採用されるスキルシートを採用側はどう見ているか。
失礼かもしれないが、引用画像に印を入れてどこに気を引かれるかを説明する。
- 人は上から下へ、左から右に読む。経験年数は気にしないが、経歴上の記載に疑問があると年齢を見ることもある。あと、採用のポジションとして中堅が欲しいか、ポテンシャル採用を前提として若手が欲しいか、プロフェッショナルが欲しいならシニアでもいいとかで、参考にすることもあるがプライオリティは低い。
- 1年半超のプロジェクトのプロマネをやったんだな、と見る。プロマネも専任とプレイングマネージャのプロマネがいる。どちらかを全体から見るがここでは、プロマネなんだな、というところまで。
- 項番2の説明でオフショアはいかにもウォーターフォールなのに、チーム構成でスクラム体制と出てくる。ここでちょっとおかしいと気づく。その上、プロダクトオーナである。ちょっと待て、チーム構成は案件概要の直下に20人と記載がある。一体どういうことか。さらに、担当箇所でヒヤリング、ユーザストーリ、UIとある。仕様だけスクラムチームで決めて、実装はオフショアか。とても違和感がある。どこがスクラム体制なのだろうか。
- ツール類はプロジェクトで採用したものが列挙してあるのだな、しか思わない。これを全部使えるとは思えない。アーキテクトやSEリーダならまだしも、プロマネで、担当箇所が要件決めしかやっていないから、そう見る。あと、エディタはteratermか。いま風にawsとかゴリゴリ使うプロジェクトで…。
- 2件目の案件は、一担当のエンジニアで、そのあと１件目でいきなりオフショアのプロジェクトをスクラム体制でやったのかと、気づく。ありえないでしょう。エディタはteratermか。
いくら架空のスキルシートだとしても、整合性は取って欲しい。それに、オフショアはウォーターフォールでオンサイトはスクラム体制とは一体どんな理由でそうしたかを興味津々で聞くだろう。プロジェクトマネージャやプロダクトオーナなら答えられないハズは無い。
- 欲しいエンジニアのポストの技術や採用するチーム全般の技術との重なり（＝業務のカバー）
- スキルシートの内容（整合性）と技術の深さ、広さ
スキルシートからはこの辺りを中心に見たり、実際にあってヒヤリングする。その上で、何点か一緒に働いていけるかを見極めるために質問をする。あと、課題をお願いすることもある。
以上から、架空のスキルシートのエンジニアの方は、カジュアル面談をするかもしれないが、その場の受け答えが記載通りであれば選ばれないだろう。
1つ褒めると、プロジェクトでのロールを記載しているところ。ここは抜けやすいので例示のようにスキルシートに書いて欲しい。
