良い案件を見つけるには!

良い案件を見つけるうえで最も重要なことは、良い案件をたくさん持っている派遣会社に登録して、担当者に良い案件情報をたくさん流してもらう事です。

良い案件とはどんな案件でしょう?
これは人によって様々ですが、これから書く4つの条件を満たしている案件が、良い案件と言えるのではないでしょうか。

1 スケジュールに余裕がある
  ※カツカツだったり、炎上しない

2 単価が高く、残業代がしっかり出る

3 希望の勤務地

4 案件がやりたい分野

このような好条件の案件なんて、ほぼないよと思うのは間違いです。好条件の案件は、実はすごくたくさんありますが、単純に好条件の案件を持っている派遣会社との接点がない為、なかなか見つからないのです。

まず好条件の案件をたくさん持っている派遣会社はどこか?
それは下記の会社です。
条件1は、元受けに近いほどスケジュールに余裕があります。好条件の案件は決まりやすいので二次受け、三次受けになればなるほどなくなります。


スケジュールと言うムリゲー

システム開発におけるスケジュールは、エンド=リリース日は決まっており、スケジュール変更とはエンドを変更せず基本設計、詳細設計、開発、単体テスト、結合テスト、総合テストなどのスケジュールの後工程の日数を減らす事を指します。

当然、必要な日数を減らすのでムリゲーになります。
品質低下、予算超過、納期遅延の悪循環になります。


ムリゲーをさせる

元受けに派遣されれば、工程間の調整に意見が反映されやすく、開発の進捗や状態を把握しやすいため、問題案件だった場合、離脱するタイミングもとりやすいです。

ムリゲーを避けるためには、元受け案件を選ぶことが重要です。


派遣会社は大きい方がいい!

3 勤務地が近い、4 案件がやりたい分野である は、たくさんの案件を持っている派遣会社の方が当然、希望条件に合った案件がたくさんあります。


やってはいけない派遣案件!

契約書がない案件、契約書を要求してもなかなか出てこない案件は、とても危険です。

こういう案件でお金が支払われない事はほとんどありませんが、契約書が出てこないのは金額や残業条件、プロジェクトのエンドが不明確で契約書を作れない事が多いのです。

しっかり発注事業者にものを言える派遣会社は管理もしっかりしており、契約書は早い時期に必ず出てきます。

契約書が出てこず、スケジュールに問題がある開発は、経験的に75%以上は炎上案件ですので、タイミングを見て早めに離脱しましょう。


やった方が絶対良い派遣案件!

元請けへの派遣で、元請けが概念設計(※要件定義より上のフェーズ)から要件定義、基本設計、詳細設計、開発、単体、結合、総合テスト、運用までの全工程を担う案件はとてもおすすめだ。

上流フェーズに入ることが出来れば、エンドユーザーの現場、つまり発注主のシステム担当部署と一緒に、発注主の現場(そのシステムを企画したり、使う人々)と直接コミュニケーションをとり、要件を聞き、要件定義のフェーズを進めるチャンスがあるためです。

このフェーズに携わる事は、システム開発で最も重要な要件定義のフェーズが出来る事と、システム開発全体を見る事ができ、その後のフェーズにも携わっていく事になります。

また、エンドユーザーとの接点ができる為、良い結果を残せれば、運用フェーズに入ってからもプロジェクトを続けることが出来ます。

システムを最初に開発してから、機能の改善やユーザーの業務が変わって、仕様変更は絶えず行われます。

多くの派遣エンジニアは、開発が終ったら次の案件に行ってしまいますが、エンドユーザーに近いところで長い1つのプロジェクトを行う事は、スキルも大きく向上し、単価も上がりやすく、勤務条件も好条件で働ける案件になると言えます。



2014年11月1日の、Java、PHPの案件について調査したところ、リクルート ジャフィーゴでは、

件数 Java 176件、PHP 67件 で、

平均単価(時給)は、Java 2421円、PHP 2404円 でした。

テンプスタッフは、件数 Java 210件、PHP 97件 でした。

Java の案件は、PHPの 約2倍強、平均単価は、ほぼ変わらずといった状況です。一般公開されている案件だけの集計ですので、リクルート、テンプともに、未公開の案件数は4~5倍はあると考えてよいでしょう。

11月1日 集計

リクルート ジャフィーゴ http://japheego.jp/

Max Min Avg 件数

Java 3000 1700 2421 176

PHP 3100 1700 2404 67

テンプスタッフ https://www.jobcheckit.com/

Max Min Avg 件数

Java 未調査 未調査 未調査 210

PHP 未調査 未調査 未調査 97

というのはよく聞く話ではあるが、それはどういう根拠に基づくものなのかというのは、なかなか解らなかった。
だがこの現場でやってみて、35歳定年説の意味はあっさり分かった。


35歳で定年するのはSE(システムエンジニア)ではなく派遣 PG(プログラマ)。


日本のIT業界では労務上の都合で、設計者も派遣プログラマもテスターもインテグレーターも運用者も管理者も、みんなひっくるめてエンジニアという扱いになっているから分かり難いが、肩書き上SEになっている人の半分以上は、実質は派遣 PG。


派遣 PGは、他の工程からもらう設計書に基づいてプログラムを作るのが仕事。
だから、顧客と直接話したり、業務内容を把握することは仕事のうちに入っていない。
設計書に書いてあることを実現するプログラムを作ることが派遣 PGの仕事であり、それ以上でもそれ以下でもない。

エンジニアが言葉の字面の通りに、システムの構築を上から下まで把握してエンジニアリングする立場であるなら、SEの仕事の範囲は、顧客からの要件のヒアリングや、エンドユーザーへの操作方法の教育、実環境に導入するためのサーバー機やネットワーク環境の調整まで仕事に含まれてくる。


派遣 PGは、言われたとおり(設計書どおり)に作業するのが仕事だが、SEは状況から判断して、自分で作業の内容を決めなければならない。
なので、派遣 PGは使われる人だが、SEは自ら動く人であり、人を使える人でなければいけない。


自ら動いて仕事を作っていけるレベルの人ならば、その人には実質的な定年はないと言っていい。
サラリーマンであるならば制度上の定年はあるが、仕事の内容としては、やろうと思えばいくらでもやることは出てくるから、やる仕事がなくなってしまったから定年ですということはないだろう。体力の限界が来るまで、現役で働き続けることは出来るはず。


PGは、仕事をもらわないと仕事がないから、仕事をくれる人がいなくなったら、それはもう定年が来たといっていいだろう。
自分で仕事の内容を決めて動けるレベルや立場ではないということは、ある意味アルバイトと同じようなものなので、そういうレベルの労働力ならば、単価が安い方が使う側としては便利。


仕事の内容がアルバイトレベルならば、単価の高いベテランはごく少数しか必要なく、大半は若くて活きが良い方が使いやすい。
ならばPGは30~35歳ぐらいまでが、コスト的に見合う上限の年齢ということになるだろう。


実際、いい年こいて自分の作業内容を決められなくて、手取り足取り指示を与えないといけない人というのは、実に使い難い。
使い難くて、かつコスト的にも高くつくのであれば、それは雇用者側としては雇えないだろう。


SEとして動けるレベルの人ならば、40歳であれ50歳であれ使っていけると思うが、やれる作業の内容がPG工程だけで、年齢が35以上だとしたら、その人は採用面接で通すべきではないのだろう。


実際にはPG工程しかやれない人であっても、経歴書にはSEとしての肩書きで10年以上のキャリアが書いてあったりするのが普通だから、書類での選考はほとんど意味はない。
直接の面通しをして、リアルタイムでのレスポンスを見てみないといけない。


人間の管理ってのは、実に手間がかかって大変なことだから、管理職の給料が高いってのは、そりゃまあ当然のことなんだろう。
ちゃんと給料分の仕事をしていればの話ではあるが。

サブコンテンツ
  • エンジニア派遣

このページの先頭へ