迷惑メールでの募集広告に 面白そうな案件を発見 応募
> 「スキルシート」を送ってください
< 決まった書式があったら教えてください
> 書式はありません エクセルかワードで作ってください
いい加減な募集会社であることを知る
|
|
 |
|
「スキルシート」 募集技術者に求められる職務経歴書 ＩＴ業界用語か 上品な言葉を知りませんでした |
|
●募集開始 技術者を集めたい会社は、要員手配のための募集営業を介して募集をかける。 募集営業から、案件に合わせてスキルシートが送られてくる。 会社の現場責任者は送られてきたスキルシートと金額を確認し、案件とスキルシートから読み取れるエンジニアのスキルがマッチしているか、もしくは完全にマッチしていなくても、何らかの形で現場の力になることを判断して面談するか どかを決める。 |
|
●いい加減な募集営業 会社要望に添った「スキルシート」書式があれば便利 面談の判断 おなじ物差しで見比べられれば効率が良い 単なる募集情報のバラマキ会社 これが一般的な応対なら業界のお先は暗らそう システムを作る人間を集めるシステム不備 |
|
●季節労働者 確かにいい加減な業界です 必要な時だけの季節労働者 システムが完成すれば失業します |
 |
|
●スキルシートの書き方
1 ●スキルシートの書き方1つで、年収が50万円以上変わる スキルシートはあなたのブランディングツールとなります。例えば、同じ仕事でも、大手と中小企業がやるのでは価格が違うように、単にささっと書いたスキルシートと、作り込んだスキルシートではブランディング力に大きな差があり、受注できる単価にも大きな差が出るのです。せっかく、スキルと経験を持っていても、読みやすく、見ているだけでも、この人は出来そうな人だと思われるようなスキルシートを書くことができなければ、受注単価は、下がってしまいます。 ●どこまで細かく書けば良いのか？ プロジェクトの内容、チーム体制、ミドルウェアなど、どこまで書けば良いのか、細かく書きすぎるとまとまりがないように見えてしまうし、簡単に書きすぎるとアピールが弱く見えてしまう・・・ ここでは、スキルシートの書き方を深堀して見ていきましょう。 ●プロフィール 名前、住所、最寄駅、年齢、学歴、資格などを記載します。また、経験のある言語、サーバーOS、DB、ネットワーク、ミドルウェアを全てを記載する項目も作りましょう。 ●自己PR 案件ごとに使い回しをするのではなく、案件毎にアピールする内容は変える必要ががあります。 ●プロジェクト期間 開始年月と終了年月、また、そのプロジェクト期間が何ヶ月(又は何年)だったかを記載します。同じ期間に複数のプロジェクトに携わっていた場合は、1つの期間の中に複数のプロジェクトを書くのではなく、複数のプロジェクトに分けて書くようにしましょう。 ●業務内容 RFPの作成、設計書の作成、テストケース作成などの細かい部分まで書くようにすることが大切です。 例えば、単に、「サーバーの運用」をやりました。と書かれていても、企業担当者は、どこまでの範囲をやったのかが見えません。運用と言っても、「24時間、365日の運用監視」なのか。その場合は、何人のチームメンバー中で、どのような立ち回りだったのか。 障害発生頻度は、どのくらいだったのか。障害発生後は、どのように障害を切り分け、復旧をしてきたのか。障害対応後は、運用方法をを変えたのか、変えたのであれば、その後の障害発生率は下がったのか、などまで書くことが必要です。 ●チーム体制/役割 プロジェクト全体の人数、自身の所属チームの人数、役割(リーダー、PL、PMなど)、マネジメントをしていたのであればその人数(直下と、外注の人数)を記載します。 ●システム環境 言語、サーバーOS、DB、ミドルウェア、ネットワーク機器など全て記載をする必要があります。サーバーエンジニアの方であれば、スクリプト作成に何を使っていたかなどまで書く必要があります。案件獲得においては、この部分をどこまで細かく書けるかがポイントとなります。 ●担当工程 前述しましたが、インフラ系と開発系では、工程の書き方が異なります。インフラ系であれば、要件定義、設計、構築、運用・保守の4つは最低限必要な項目です。また、開発系であれば、要件定義、基本設計、詳細設計、開発、テストの5つの項目は必要となります。 ●面接には別途プレゼン資料を持参 スキルシートは、経験したプロジェクト詳細や、成果が見えづらいものです。よって、面接には、スキルシート以外別途、自身の強みをアピールできる2〜3ページの資料を持参しましょう。例えば、web系のエンジニアであれば、webにおけるマーケティングの知識(SEO、LPO、EFO、アフィリエイト、動画広告)や、オープンソースのCMSなどの知識などをアピールできるような資料があると強力なアピール材料となります。また、マネジメント経験をアピールしたい場合は、PMBOKに沿ったマネジメト手法を行ってきた点や、コストを削減した経験などをアピールしましょう。 ●業務以外での活動をアピール 企業担当者が、フリーエンジニアに仕事を依頼する上での懸念点は、コミュニケーション能力はあるのか、しっかりと仕事をしてくれるのか・・・などのポイントです。スキルも重要なのですが、それ以上に人物像や性格を心配しているのです。面接というのは、実は、スキルチェックよりも、この点を確認する為の作業なのです。つまり、この人物像を事前にアピールできれば、面接が入る可能性は高まり、案件を獲得できる可能性も高まるのです。その為に、最適なツールが、FaceBook、Blog、Twitterなどのソーシャルネットワークです。 例えば、ITやネットについて書かれているBlogを運営していたり、FaceBookで繋がっている知人・友人がエンジニアであったり、また、Twitterにおいていろいろな人とやり取りしている様子が分かったりすると、企業担当者は安心するでしょう。さらに、自身で作った簡単なアプリやガジェットを公開していたりするとプラスとなります。プロエンジニアに登録しているエンジニアの中には、BlogやFacebook以外にも、オープンソースプロジェクトに参加をしておりその活動をアピールしていたり、技術系の本を自費出版していたりと上手くパーソナルブランディングをしている方々もいるのです。 ●リファレンス貰ってますか？ リファレンスとは、いわば推薦状です。正社員として働いた経験がある方は、前職の上司から、あなたの働きを評価してもらえるような推薦状をWordに5〜10行程度で良いので書いてもらいましょう。また、各プロジェクトにおいても、顧客企業、元請企業と親しくなった場合は、必ずレファレンスをお願いしましょう。これがあるだけで、単価UPや、案件獲得率が大幅に上がります。 |
 |
|
●職務経歴書・スキルシートの書き方
2 経歴書(又は、スキルシート)を提出する際、「スキルが見えにくい」と言われてしまうことがあります。一番悪い例のは、プロジェクト、担当内容・工程などを箇条書きにしてしまう経歴書です。企業担当者が、エンジニアの経歴書を見る場合は、ほとんどが、「プロジェクトシート」のような形で、経歴書を見ています。よって、箇条書き形式の経歴書は、間違いなくＮＧとなります。最低でも、プロジェクト期間、メンバー数、自身の役割、システム環境、担当工程は入れるようにしましょう。 また、業務の詳細内容として、RFPの作成、設計書の作成、テストケース作成などの細かい部分まで書くようにすることが大切です。 例えば、単に、「サーバーの運用」をやりました。と書かれていても、企業担当者は、どこまでの範囲をやったのかが見えません。運用と言っても、「24時間、365日の運用監視」なのか。その場合は、何人のチームメンバー中で、どのような立ち回りだったのか。 障害発生頻度は、どのくらいだったのか。障害発生後は、どのように障害を切り分け、復旧をしてきたのか。障害対応後は、運用方法をを変えたのか、変えたのであれば、その後の障害発生率は下がったのか、など。最低でも、これくらいは、職務経歴書に書くようにしましょう。 |
|
●エンジニアの職務経歴書
どんなに素晴らしいスキルを持っていても、どんなに経験が豊富でも、それを上手く伝えられなければあなた評価は低いままです。エンジニアの職務経歴書を書く上での注意点 6か条 ●読みやすいか 最低限、下記の項目は必要です。 ●エクセル形式は嫌われるので、必ずWord形式に ●だらだらと長い文章は書かないこと ●業務内容は、プロジェクトシートにまとめること ●誤字・脱字はNG ●職務経歴要約はまとまっているか 職務経歴書のトップでは、職務経歴要約(概要)を3〜5行で書きます。出だしで、だらだらと長い文章が書かれている場合は、即NGに。自身の経験が応募企業へマッチしていることをアピールしましょう。 ●スキルの箇条書きは上部に書く 職務経歴要約の下には、必ず、スキルの要約(箇条書き)を書くようにしましょう。これにより、人事担当者は、人目であなたが、スキル面でマッチしているかどうかが判断できます。 ●転職理由と一貫性 履歴書・職務経歴書には必ず、転職理由を書くようにしましょう。一貫性がないと思われると、どんなにスキル・経験がマッチしていても書類でNGとなってしまいます。 ●自己ＰＲはマッチしているか マッチしているとは、「あなた=企業が欲しい人材」です。この点を勘違いしてしまうと、「求めているスキルが違う」、「求めている人物像と異なる」、「オーバースペック」、「目指している方向が異なる」などでNGとなってしまいます。 ●プロジェクトの担当業務は明確か プロジェクトシート内の担当業務に、例えば「運用」とだけ書いてあっても、運用の設計をしたのか、運用手順書を作ったのかが見えません。しっかりと、、担当業務の詳細まで書くようにしましょう。 |
|
長い文章は嫌われます。職務経歴書の中では、できる限り簡潔に書く事が大事です。文章を短くできれば出来るほど良いのです。
●経歴概要 ●自己アピール ●各プロジェクトの詳細/ 各企業での業務詳細 などにおいて、文章が、何行も続くのはNGです。選考のハードルが低い会社であれば、ダラダラと長い文章でも、問題になることは少ないのですが、大手、人気、コンサル企業であれば、基本的に、人事担当者が、書類を見た瞬間にNGとなります。以下 良い例と悪い例です。 |
|
●各会社での業務詳細 【悪い例】
会社名：株式会社ABCD ポジション： PM、アーキテクト、デベロッパー 期間：2006/06 – 2007/07 1) Webアプリケーション Java, PHP, Javascript, Linux(CentOS), MySQL - システム全体の設計を実装(PHPとJava)口コミ、Twitter、ブログ、FaceBook、RSSなど - Seasar2の設計思想を元にした、サーバサイドの設計と実装 - サーバ管理。HTTP(apache)、メール(qmail)、SFTP(openssl)、OS(CentOS) - MySQLデータベースのデータ設計とトランザクション設計 Webアプリケーション、口コミマーケティングをベースととしたマーケティングツールの開発を行いました。開発者は2人。私はサービス企画、PM、アーキテクト、デベロッパという全てを任され、要件定義、アーキテクチャ分析設計、実装、テスト、運用の全ての工程を担当しました。 また、CentOS、apacheのインストール、パラメーター設定から、冗長化(HotStandby)設計、監視(Cacti)設計も担当しました。DBはMySQL、言語はPHP、Javaにて実装しました。 1)BtoBとはいえ、24時間365日停止できない機能を提供を目指し、2人で1年間という期間でサービスのローンチまで持って行く事に成功しました。機能としては、口コミを誘発するマーケティング機能ということで、アフィリエイトのASPをベースとしたトラッキング機能を用いて、Facebook、ブログ、Twitterなどと連携しつつ、SEO対策もできる多機能な仕様となっています。 2)共通部分の再利用、機能追加・改修をニーズに合わせて対応できるようにする為に、フレームワークを作成しております。各機能ごとにコンポーネント化することで、各機能が影響範囲を独自で持ち疎結合、新機能の追加の容易性を実現しました。 3)サーバ管理も全て行いました。apache、sendmailなどの設定管理をCentOS(Linux)上で行いました。また、冗長化設定や、サーバーを複数台持ち、24時間365日停止できないサービスだった為に、監視ツールを導入し、アラートは私の携帯に飛ばすという形の運用方法を取っておりました。 ●この書き方の悪い点 ●とにかく長く読む気がなくなる ●同じ事を繰り返し書いている ●段落番号の振り方が意味不明 ●プロジェクト概要、担当業務、システム環境、チーム体制などが、まとまっていない |
|
●各会社での業務詳細 【良い例】
会社名：株式会社ABCD 期間：2006/06 – 2007/07 ●プロジェクト概要 概要：口コミマーケティングをベースととしたマーケティングツールの開発 機能：Facebook・ブログ・Twitterなどと連携、 SEO機能 運用：24時間365日 顧客：ECサイト運営事業者30社程度 ●システム環境 言語： Java, PHP, Javascript, OS：Linux(CentOS), DB：MySQL その他： Seasar2、apache、qmail、openssl、Cacti ●担当 ポジション： PM、アーキテクト、デベロッパー 体制：2名 開発：プロジェクト管理、企画、要件定義、設計、開発、運用 DB：設計、構築、運用 サーバ：OS・ミドルウェアのインストール、設計、構築、運用 ●この書き方の良い点 ●箇条書きで読みやすい ●プロジェクト概要、システム環境、担当とまとめている ●必要以上に横文字が多い |
|
●まとめ
経歴書・スキルシートの書く際には、「読み手(=人事担当者)」を意識 することが大切です。読み手に取っては、「何ができるの？」という部分しか、興味がないので、自分はこんなに凄いプロジェクトをこんなに頑張ったということを書きたい気持ちではなく、「実績・スキル」を書くようにしましょう。どうしても、自分の思いを書きたい場合は、自己アピール部分に、1〜3行程度書くだけにしましょう。 |
 |
|
●スキルシートでいったい何が分かるのか
本連載はプロジェクトの成否を握る大きな要素「人とチーム」の関係に焦点を当てます。開発プロジェクトが成功するか失敗するかは結局、開発チームを構成するそれぞれのスタッフの力量にかかっているといってもいいかもしれません。 |
 ●ITプロジェクトの人集めって何だろう？ ●システム構築と「人集め」 プロジェクトを遂行するとき、マネージャとアーキテクチャの大切な仕事の中に「チームづくり」があります。プロジェクトの成否・効率は「人選び」によって左右されるといっても過言ではありません。 この「人選び」にも大きく分けて2種類あります。1つは「プロジェクトの命運を握る人」という意味での人選びです。「マネージャ」「アーキテクチャ」といった中心的な役割を果たす1、2名がこれに当たります。もう1つは、そういった「命運を握る人」が一連托生(いちれんたくしょう)として選ぶ「プロジェクトメンバー」です。 無論、人選をはじめとする「人繰り」はマネージャの主任務です。しかし、実際には「技術頭」あるいはプロジェクト参謀としてのアーキテクトも、多くの場合このメンバー選定をマネージャと共同で行ったり、さらには、細かい実装・設計のロールを割り振ったりします。 そこで、今回は、このプロジェクトの成否を握る大きな要素の1つである「人とチーム」に焦点を当ててみたいと思います。皆さんと一緒に「人とチーム」について検討を重ね、その「プロセスの構築」をこの場をお借りして行ってみたいと考えています。 「開発現場の天国と地獄」と同じ手法で検討してみましょう。 まず「実際にあった記録」を検証・確認します。その記録を分析して共通する問題点の洗い出しを行い、「メンバー選び」の選定基準・手法について迫っていきたいと思います。 その際にあえて今回は、大上段にプロセスやマネジメントの観点から実感の少ない考察を行いません。単純に「プロジェクトにいたAさん」というミクロの視点から逆に、プロセス全般にかかわるマクロの問題を浮き彫りにしていきたいと考えています。 ●大切なのは適材適所 例えば、「ロールの割り当て」は重要な要素です。ロールそのものの扱いについては、多くのプロセスで検討されていますが、そもそもどのロールにどういった人を割り当てるべきかということが真剣に検討され、実施されているでしょうか？ 「高額で実績ある人を呼んだのに……」というボヤキをよく耳にします。その多くが「能力に問題があった」わけではなく、「使いどころを誤った」という「ロールの不一致」という問題です。しかし、多くの開発プロセスではこういった問題の解決方法、回避方法について、あまり検討されていません。 そこで最初に、業界でまず人を判定するのに使われる「スキルシート」に焦点を当ててみます。スキルシートでいったい何が分かるのか」です。 |
 ●スキルシートで何が分かる？……スキルシートは取り方ひとつ ●あまり吟味されないスキルシートの中身 40歳代後半のベテランエンジニアとして、協力会社から呼ばれたEさんの例です。案件は、最近よく見られるホストのシステムのマイグレーションでした。そのため、Eさんは「十分な現場経験があり、ホストのCOBOL言語と新しい技術の双方が理解できる」という内容で選ばれ、スキルシートもそのような内容になっていました。 スキルシート上の記述では、14年にわたるホスト系のCOBOLの経験が中心でした(表)。ここ1年は転向し、クライアント／サーバのシステム構築に携わってきた……という内容です。今回本案件では、クライアント／サーバでのマイグレーションが主任務です。 [スキルシート上の記述] このスキルシート上も、後から思えば「同じシステムのPG、SEを10年近くもやっている」という危険要素があったのも事実です。Eさんがどうしてそこに10年張り付かねばならなかったのか？ それほど顧客に買われていたのか、あるいはほかに案件がなかったのか？ 会社が異動させるのを忘れていたのか？ など、想像の域を出ませんが、何らかの事情があったのでしょう。ただし、Eさんの場合「採用する側の判定」としては、以下の理由で十分な評価がありました。 ●十分な業界経験がある ●技術的にマッチしている(ホストの事情も分かり、クライアント／サーバシステムの事情も分かる) ●設計や実装、リーダーを経験している 基本的に所属している会社・組織の評価を前提に「通す方向」で検討しているのですから、褒め言葉が並ばざるを得ないでしょう。 ●不適切なロールが呼ぶ不幸 果たしてEさんが置かれたのはどんな状況だったのでしょう？ プロジェクト的にはいわゆる追い込みの真っただ中で、すでに一部はテストに入り始めていました。その中でEさんは、稼働までのヘルプと、本番稼働後の開発保守まで対応するための要員として呼ばれました。うまくいけば、大きくて長い現場が得意である彼にとっては、「幸せな現場」になれたかもしれません。 方向としては、テストを手伝ったり修正を手伝ったりしながら仕様を理解してもらい、徐々にリーダー＋SEの立場になってもらう、手数が足りない分は自分でも直せる、というプランとしては悪くない内容でした。 しかし、最初の綻(ほころ)びは、「取りあえず簡単な修正をお願いする」ところから始まりました。「簡単な修正」ということで、修正個所も特定し、コードを印刷し赤ペンで「どう直したらいいのか」を書き込んで手渡したのです。もしわずかでも経験があれば、ここまでのガイド付きであればすぐに修正をしてテストをしてリリースをしたでしょう。規模のあるプロジェクトだったので、すべては手順化されており現にほかに入った2名は特に問題なく作業をしていました。 しかし、1つ目の不幸は、彼にはレガシー言語以外の実装作業経験が5カ月程度と不足していたことでした。また14年も同じ現場にいたため、そこ以外の手順にも慣れていなかったのです。 人間は習熟していないことを要求された場合、どうしても自信がなく、何事もハタから見ていて「挙動不審気味」に見えてしまうものです。しかし多くの場合「その不安」を解消するために「他人に聞く」「学ぶ」という行動を取ります。 ところが、2つ目に不幸だったのは、彼は容易に聞くことができなかったのです。 カベとなるのは「スキルシート」です。スキルシートには「経験があり、分かる」ことが記述され、またその記述を前提にチームに採用されています。そのため、彼は容易に聞くことができません。また「聞く」にも最低限のスキルは必要です。「分からないところも分からない」という状況ではどうにもなりませんでした。 ●不幸は増幅される この場合、多くの人が取る典型的な行動があります。「独り言」です。自分が分からない状況であることを人に伝えようとするのです。要するに「Help Me」をいえないので「HELP ME」に代わる内容で訴えようとします。それは他人に聞こえる独り言であり、しかもその内容は「僕が分からないわけではないが、どうもおかしな部分がある」というものです。 具体的には「あれー」「○○になっているはずなのになー」「おっかしいなー」という内容の連発になります。私もよく独り言をいいますが、この種の独り言には以下のような特徴があるようです。 ●その独り言が他人に聞かせるものであること ●何かの問題……それも自分のせいではない問題があって作業がうまくいかないことを訴える内容であること Eさんもやたらと首をかしげて、1人で自問自答する日が続きます。 ちなみにある程度の規模のプロジェクトを観察していると必ずこういう人を1、2名見つけてしまいます。無論「そういった人＝問題がある人」ではありませんが、少なくとも「他人に訴えたいが訴えられない状況」「外部環境の問題をしきりに口にして自分が作業を進まない理由を周りに宣伝している状況」を考えると、「順調に活躍中」でないことは容易に想像できます。 初日から、彼の作業スケジュールは担当者が当初予想していたよりはるかに遅れ始めます。いろいろな理由があって全く作業が進まないことを説明する日々が続きます。独り言で述べている理由を定例会のたびに伝えます。しかし、Eさんの作業効率は一向に上がることがありません。すると次第にプロジェクトメンバーのEさんに対する風当たりも強くなっていきます。そしてEさんの独り言も増えていく悪循環……。 ●間違った窮余の策 決定打は、それでも2カ月ほどEさんが屈辱と不安に耐え、周りの人も同じだけ独り言や作業内容に我慢した後、ある日の朝に起きました。 前の日の夜、Eさんがリリースした修正が原因でした。とにかく作業効率が悪く、問題視していたマネージャは「簡単な修正なので明日の朝まででお願いします」と厳しく期限を切っていました。あるいは間に合わないのを理由にそろそろ対策を打とうと考えていたのかもしれません。 彼も「PCの問題が多くて明日まで間に合わないかもしれない」と独り言で述べながら該当するPGを印刷し読み始めました(彼はまず、印刷してからPGを見る「机上デバッグ」をするようにしていました)。しかし、厳しくいい渡された期限までに終わる見込みは一向に立ちません。悩んだ末に彼が打った方法は、「エラー処理を修正し、問題のエラーを無視するようにした」というものでした。 修正結果のチェックは二重にしていましたが、多くの人が簡単な修正と認識していたためにチェックの項目もそれほど多くなく、問題は正しく修正されたと認識され、リリースされてしまいました。またすべて修正を完全にチェックし直すにはリソースも不足し過ぎていました。 こうして、そのプログラムはリリースされ、深夜稼働し……、はるか後続のバッチ処理で別の開発会社の担当者が早朝4時に起こされることとなりました。 プロジェクトは並行稼働の段階に来ており、事実上の本番稼働と同じレベルでテストや障害時の運用が行われていました。データも本番のものです。すでに、問題は非常に大きくなっていました。エラーを無視して素通しするように直してしまったために、不完全な勘定が発生し処理され、後続の機能でそれが処理できないものになってしまっていたのです。始発電車で全員が集められてリカバリー作業です。始発で早朝から集められたメンバーはすぐに修復作業に取り掛かりました。その中で責任範囲をまだ持たされていないEさんは事情も知らずに定時に来ます。 ●悲しい結末 取りあえず、メールを読みながら周りの様子をうかがっています。毎朝行っている朝会の時間になっても誰も席を立ちません。そのうちに聞こえてくる会話の端々に自分への悪意ある言葉が多く含まれていることが分かってきます。大体事情は察したのでしょうか？それでも、あえてEさんは気付かないフリをして、リーダーに今日の作業を聞きに行きます。 「朝会は？」「今日はいいです」「……。私の作業は？」「今日はいいです」「……」「じゃあほかの人を手伝いますね」「そうしててください」「……」 所在なさげにメールやネットニュースを読むEさん。だんだんと最早、遠慮なく単なる悪口というような内容まで飛び交います。とうとういたたまれなくなったのでしょうか。彼は荷物を片付けていなくなってしまいました。 結局彼はその後も来ず、後に文書で扱いが不当であったためにこのような事態に至ったことを伝えてきました。 そのときに決裁者が象徴的な言葉を述べていました。「なぜ、すぐに切らなかったって？ 彼を切るにも、われわれは顧客に彼の2人月が意味のないものであったとは説明できない。人月でお金を計算しているこの業界では、払ってしまった工数に意味がなかったという説明はできないのだ」 |
 ●スキルシートの内容を見直す ●実は足りないスキルシートの情報 さて、ここで彼が不幸になった原因を考えてみましょう。もともと、彼はスキルシートと所属する「仲介業者」の推薦でプロジェクトに参画しました。プロジェクトに参画してしまった理由……。採用理由である「スキルシートで人を集めること」を考えてみます。 まずはそのために、プロジェクトを遂行するのに必要な能力と、スキルシートから分かる能力を対比してみました。スキルシートといえば大体こんな表ですね。 ここから分かるものといえば、名前や年齢、通勤距離といった基本的な個人情報。また、技術経歴の羅列……。つまり、どんなプロジェクトを、どんなロールでどのくらい経験しているかを「品質を問わず」記載しているだけです。さて、その要素を比較してみましょう。 (1)システムを作るための重要ファクター ●論理思考性 ●ロールごとの経験(年数) ●経験(業務的) ●多様性(業務的) ●経験(技術的) ●多様性(技術的) ●SE的センス ●PG的センス ●MG的センス ●営業的センス ●コンサルティングセンス ●技術的先進性 ●健康(体力) ●やる気 ●やられる気 (2)スキルシートで分かるもの ●ロールごとの経験(年数) ●経験(業務的多様性) ●経験(技術的多様性) (3)面談で分かるもの ●やる気 ●やられる気 ●センス少々 以上のように、実はプロジェクトに必要な多くの情報を、スキルシートからは得ることができません。われわれはいかにいいかげんなもので人を「売り買い」しているか分かるでしょう。もしかしたら面接のプロは「営業的センス」などさらに多くの情報を得ることができるのかもしれません。でも、プロジェクトマネージャを任命する決裁権者の方、考え直してみてください。あなたは「人を見る目の素晴らしさ」でプロジェクトマネージャを任命されましたか？ 社内の所属や地位、「本人の似たようなプロジェクト経験」で決定しませんでしたか？ いやそのことが問題だといっているのではありません。もし、「人を見る目の素晴らしさ」で選んでいないのであれば、別の方法で「人の選別に手を貸す必要」がありませんか？ ●判断を誤らせる「業界の事情」 今回の例でいえば、ロールや技術の種類や経歴の長さは評価の対象になっていますが、品質については何も情報を得ていません。 しかしそれ以前に、スキルシートと実際の能力の乖離に関して、判別を誤った大きな理由があります。それは、協力会社とプロジェクト元請け側の会社対会社の関係があります。簡単にいってしまえば、「業界は常に人不足」です。その状況で元請けも人集めに関しては「無理をいって1カ月で集めてもらう」といった状況になりがちです。特にこういった「佳境の増員」は得てして上記のようなシチェーションにある場合が非常に多いのです。 そうなると、マネージャもリーダーも「選別」などしていられません。「協力会社に無理をいって集めてもらった」状況ではなかなか「スキル的に不安なので別の人を……」といい出しにくい状況になってしまいます。また元請け自身も工数予定表に割り当てられた作業員が一向に現れないのでは顧客に説明ができなかったりもします。 スキルシートの情報量の少なさに加えて、こういった「基本は通す方向で検討しなければならない」現場の苦労も加味され、「適材適所」はますます現実離れしたものとなっていきます。 今後、何回かの連載を通して、さまざまな事例からこういった業界自体の課題を含めた「問題点」を洗い出していきたいと思います。またそのうえで、「問題点を回避する手法」を皆さんと編み出していければと思います。 ●そもそも協力会社にも元請けにも「取りあえず通す」しかない現場の事情がある ●スキルシートでは実力の20％程度しか分からない ●切るのも簡単ではない ●環境など自身以外の問題をブロードキャスト的にチーム全体に訴え続ける人は危険 ●極端に長い単一プロジェクト経験は、環境即応性や環境要素に対する経験のバラエティを奪っている恐れがある ●不適材不適所になってしまったらプロジェクトに居続けるのは難しい |
 |
|
●スキルシートの認識
仕事柄、数々のエンジニアのスキルシートを見ているが、営業や現場マネージャーでもなければ、なかなか他人のスキルシートを見かけることは無いだろう。エンジニアの方たちは、このスキルシートについてどのように認識しているだろうか。 技術者を集めたい募集側は、要員手配のために募集をかけると、このスキルシートが案件に合わせて営業経由で出回り始める。現場責任者はこの送られてきたスキルシートと金額を確認し、まずは案件とスキルシートから読み取れるエンジニアのスキルがマッチしているか、もしくは完全にマッチしていなくても、何らかの形で現場の力になることを判断して面談するかを決める。 ここでポイントなのは、 面談する側からすると、 可及的速やかになんでもいいので手が動く要員を調達しなければいけないという火吹き現場でもない限りは、採用するエンジニアについてはしっかりと検討したい点である。 しかしSESの場合、顔写真や詳細な経歴書がなく、名前すらもイニシャルにして伏せられることが多い。また、就職の面接ではないので、基本的には面談は1回のみである(商流によって面談回数が多い話は、またいつか・・・)。つまり、一度会って、その面談内容のみで決めなければならない。だが、現場責任者はだいたいミーティングでスケジュールがびっしり埋まっていて忙しく、応募者全員と面談しようという方など、ほとんどいない。ということは、面談するかはスキルシートで判断するしかないのだ。 よくアホな営業さんが、要員提案のEメールで、 備考：コミュニケーション良好：勤怠大丈夫です。 という文章を付け加えているが、こんなものは当たり前なので止めて欲しい。はっきり言って何にも参考にならない。 となると、エンジニアにとっては、スキルシートは面談に進むための唯一のアピールポイントであり、プレゼンテーションの一部なのだ。 スキルシートが重要なアピールポイントである、ということを理解していないと、大きな機会損失になる。 実際私は、「スキルシートからスキルが読みにくい」という理由で見送られているエンジニアを何人も見てきた。確かによくわからないというか、簡潔すぎて、深さが計り知れないものであった。 参考例をあげよう。 [こちらと / こちら] どちらがわかりやすいであろうか。 年代や個人的な嗜好もあるのかもしれないが、一つ目の方が、パッと見でわかりやすいかと思う。ちなみに見送られたのは2つ目の方である。実際、スキルシートを見る時間は本当に数分である。3分もかからないかと思う。ほぼ第一印象で決めるというのがほとんどだ。その短い時間で判断するのに、2つ目のスキルシートのように、いちいち「えーっと、Aってなんだ？あー要件定義か。なるほどねー」などと一つ一つ見てくれる人などほどんどいない。 パッと見て、良さそうか無いかを判断して、後は面談で考えよう、というのがほとんどだ。このほんの一瞬の出来ことではあるが、ここで、人生の1/200とか1/100の期間を費やす案件が決まるのだ。だったら、せっかくなので相手に見やすいスキルシートを作って、より条件の良い案件に入り、充実した期間を過ごせるようにした方が良いのは、間違いないのではないだろうか。 |
 |
2014/2
