エンジニアの同一労働同一賃金はおかしい！
同一労働同一賃金とは、性別、雇用形態（正社員、契約社員、派遣社員など）、国籍などに関係なく、同一の職種に従事する労働者に対して同一の賃金を支払う賃金政策のことらしいのですが、
わたしは雇用形態によって賃金を変えるべきだと思います。
同一労働、つまり同じ付加価値を会社に提供しているのであれば、非正規雇用者に対して 会社はリスクを回避している分多く支払う必要があると思うのです。
わたしはＩＴエンジニアの人材サービスに関わっておりますので、このモデルでの説明となりますが、顧客へ100の価値を提供し100の対価を得たとした場合、下図でいうと
正社員・・・「1,労働対価」のみを労働者へ分配、残り全ては会社。
契約社員・・「1,労働対価」「終身雇用リスク」「福利厚生」を労働者への分配、残りが会社。
フリーランスの場合は「5.労基法対応」分もエンジニア側となりますね。
☆→労働者取り分 ●→会社取り分
| 正社員 | 契約社員 | フリー | ||
| 1,労働対価 | 労働対価 | ☆ | ☆ | ☆ |
| 2.終身雇用リスク | 65歳定年までの雇用リスク | ● | ☆ | ☆ |
| 3.福利厚生 | 教育/支援制度/フォローアップ | ● | ●or☆ | ☆ |
| 4.法定福利 | 社会保険/労働保険 | ● | ● | ☆ |
| 5.労基法対応 | 有給付与/安全衛生/勤怠管理 | ● | ● | ☆ |
| 6.マーケティング・営業 | 市場調査/事業企画/顧客開拓/顧客との関係維持/案件開拓 | ● | ● | ● |
| 7.組織維持・管理 | オフィス/経理/財務会計/税務/訴訟リスク | ● | ● | ● |
【インフラエンジニアの将来】 東京オリンピックまでがキャリアアップのチャンス!!
いまキャリアアップのチャンスだと思うのですよね〜
このところ、アベノミクス好景況によりリーマンショック以降抑えられてきた企業のIT投資が回復し、業界は人手不足に陥っています。一部では2015年問題（マイナンバーやみずほ銀の大型案件によるIT技術者不足とその後の人余り）も囁かれていますが、 2020年東京オリンピックまでは人手不足は続くだろうという見方が強いように思います。
そして、この人手不足はエンジニアにとってキャリアアップに最適な時期だと思います。
何故なら、人余りの時期は調達側は理想とする経験・スキル保有者を吟味し選別しますが、調達が困難な時期は選別する余裕がありません。多少の経験・スキル不足でも採用に踏み切ることが多くあります。
このようなパターンで転職に成功した人や、希望する案件に就いた人は多いのではないかと思います。（少なくとも私の回りでは多いデス）
ただし、多少の経験・スキル不足でも採用に踏み切ることが多くあります.
と前述しましたが、人手不足だからといって何でもかんでも採用されるわけではありませんね。ｗ
では、どのようなエンジニアであればキャリアアップに成功するでしょうか？
まずは、こんな記事がありましたのでご覧ください。
「30代・下請け」という状況から上流工程を目指し、見事成功した木下さんの勝因として、下記のようなことが挙げられます。
- 「上流工程に携わりたい」という転職テーマを明確に持っていた
- 複数の強みを自覚できていた
- 非公開求人に応募できた
- 準備（適切なレジュメを作成し、積極的な面接指導を受けたなど）を怠らなかった
- 面接時、経験が少ないことで弱気にならず、信念・迫力を持って強みを的確にアピールできた
アデコ 人材紹介サービス部 コンサルタントの方が、30代上流工程経験なしの、通常では困難だと言える転職を成功させた事例から、上流へ転換するのに何が必要か？綴られた記事です。
私もおおむね同感です。
わたしの経験上も「○○したい！」という思いの強い人が、伸びています。（それも勝手に）
ただ、全てのエンジニアがそういう強い思いがあるかといえば、そうでないほうが多くを占めると思います。
漠然と「要件定義・設計に興味はあるけど」「上流工程にいきたいけど」と思いながら特に行動には移さない人たちです。
そういう人には、上司（人材サービス系の会社であれば担当営業・コーディネーター）に思い切って相談してみることをお勧めしたいですね。
「わたし！ ○○したいと思っているんデス！ (｀ー´)／」
と、強めの意思表示をして向かう方向を共有する（関係者に知ってもらう）のです。
そうすることで、例えば、どこかで希望するポジションの人員が不足した時に白羽の矢が立つことになります。
（そんな当たり前のことどこでもやってるよ！と指摘されそうですが、出来てないところもありますので）
そして必要な準備は何なのかを明確にし、着々と準備を進めるのです。
足りない知識を座学で補い」、職務経歴書を整え そして、
「経験はありませんが、○○の知識は座学で習得出来ております。」
「そして、○○に関連した業務がしたいという強い想いが御座います！」
と相手にアピール出来れば、採用間違いなしだと思います。
【インフラエンジニアの将来】 上流工程を仕事にする為に必要な思考癖
以前、 【インフラエンジニアの将来】 キャリアアップするために
で、インテグレーションに関わるエンジニアのキャリアアップには、これまで以上に “上流” を目指すことが重要なのでは！ という意見を綴りました。
“上流”の対義語は“下流”ですが両者の大きな違いは、仕事の成果である価値を生み出すために上流工程は、思考と知識が、より必要になることだと思います。
例えばサーバ構築を例にいうと、設計するのと、設計書を基に構築するのとでは、前者は「何故その値にするのか？」「何故その手順にしたのか？」などの根拠を言える必要があり多くの知識と思考とが必要となりますが、後者はそのやり方を知っていればよいでしょう。
今回、この“思考”することについて共感するブログ記事に出くわしたので紹介したいと思います。
たとえば、エンジニアなら、過去に自分が開発したシステムにおいて、
なぜ、そのフレームワーク、ツール、ライブラリ、DBを使ったのか？
他に、どのようなフレームワーク、ツール、ライブラリ、DBが候補として上げられたのか？
他の選択肢と比べて、どの様な短所と長所があるのか？
なぜ、他の選択肢ではなく、それを選んだのか？
使う前に、どのように性能評価・検証したのか？
なぜ、ある部分を汎用的に作り、別の部分をハードコーディングしたのか？なぜ、その設計だと、生産性が高く、トラブルのリスクやメンテナンスコストが低くなるのか？
もっと低くできる余地として、どのようなものが考えられ、なぜ、それを作り込まなかったのか？実際に、どのようなトラブルが起こり、それにどのように対処したのか？おもしろいことに、有能な人というのは、そういう具体的な行動を聞き出すと、細部まで鮮明に覚えていて、スラスラ答えます。
徹底的に細部まで、なぜその行動を取ったのか？と問い詰めていくと、打てば響くように答え、持論を展開します。
一方で、無能な人というのは、まずそもそも、細部を覚えていません。理由を問い詰めても、曖昧な答えしか返ってきません。
なぜ、そのとき、そのPCサイトのケータイ版を作らなかったのか？
なぜ、ターゲット顧客を、中高年の男性に絞った商品にしたのか？
なぜ、その設計で、セキュリティー上問題ないと言えるのか？
なぜ、そのとき、普通のファイルシステムを使わずに、RDBをわざわざ使ったのか？要するに、仕事というのは、意志決定の連続であり、どれだけ質の高い意志決定ができるかで、仕事の質が決まります。
わたし自身、少し耳の痛い内容でもありましたが、日々の仕事の細部まで「Why？」と自分に問いかけることは上流工程の仕事にする為に必要であり、それが深まれば仕事の質を高めることに繋がるのだ！、と共感した次第です。
常に「Why？」と問いかける思考癖を身に付けたいものです。
クラウドに向かないシステム
クラウド（Public IaaS）に向かないシステムはどのようなものか考えて見ました。
- DBなど膨大なI/Oを発生させるシステム
これはクラウドの “仮想レイヤ” “シェア” がパフォーマンス低下の要因になってします。
この問題に対してIBMが買収したSoftLayer等のプロバイダは、ベアメタルサーバ（専有物理サーバ）が選択できるようになっています。
http://techtarget.itmedia.co.jp/tt/news/1309/12/news02.html - ミッションクリティカルなシステム
ダウンしては困るシステム。じゃ~自前でクラウドプロバイダ以上に堅牢な仕組みを構築・維持できるのか？という問題もありますが、OS以下がブラックボックス（SLAだけ）では不安。理解しておきたい。分からないのであれば選択出来ない！というのは分るような気がします。
また、メンテナンス時間などプロバイダの都合に合わせざるを得ないのもネックになりますね。 - 予算管理の強い組織のシステム
特に官公庁など予算の影響が強い組織では従量課金は不都合が発生する場合があるでしょうね。また従量課金は、携帯電話の「パケ死」のように知らないうちに異常な通信かなんかが発生し膨大な請求が来るんじゃないか？的な心配を抱くユーザーもいるのではないでしょうか？ - 人が余っている組織のシステム
言うまでもなく、配置換えや解雇も出来ずシステム運用要員が余っている組織では、自分たちでやったほうが良いでしょう。ただ、この理由でクラウドに移行できないのであれば、余った要員の転用について考えた方が良いとは思いますが。。。
先日、AWSのインテグレーションを本筋にしている知人が「クラウドと余剰人材転身案とをセットで提案すれば必ず売れる」ってマジメな顔で言っていましたｗ
IT業界の多重下請構造は問題なの？③
初回の、SI業界の多重下請構造は問題なの？① では、以下のような
「多重下請構造における問題点」を洗い出しました。
●健康保護の問題
●間接業務の増幅
●不当な利益
●人材マネジメント不全
●価格から抱く期待とのズレ
また、SI業界の多重下請構造は問題なの？② では、
「何故こんな構造になっているのか？」について考えてみたところ
「日本の現労働法下で必然的に作り上げられた人材供給システム」
ではないのか、という一つの答えを導き出しました。
次は、
「理想の構造とは？」
「では、何をどのようにすれば良いの？」
について考えてみたいと思います。
■理想の構造とは？
やはり理想は多重ではないシンプルな構造が何かと良いですね。
・[大手Ａ社]に[下請けA社]が間を挟まずに “派遣契約” で人を出す。
※派遣法では派遣先である[大手Ａ社]にも労務管理義務が発生するため。
・[大手Ａ社]から[下請けA社]が案件の一部を間を挟まずに “請負契約” で請負う。
※[下請けA社]のエンジニアの労務管理は[下請けA社]が実施する。
※さらに、必要であれば[下請けA社]に[孫請けA社]が “派遣契約” で人を出す。
どちらか、もしくは両方で問題点はすべて解決されまーす！
と、、ここまで来て気がついたのですが、ここまで考えたことは、おそらく既知の事柄で、労働局は、この状態にしたくて “2重派遣の禁止” や “偽装請負撲滅” 等の運動に勤しんでいるのでしょう。。。
しかし・・・・状況は改善されていませんね・・・
それではということで、解決に向け少し大胆に考えてみました。自分で見聞したわけではないのですが、アメリカのエンジニアは主にユーザー企業に雇われており、新システム構築などの山場（沢山のエンジニアが一時的に必要）を終えると、次の現場へと雇用されていくとききます。もしこれが本当なら理想のモデルと言えるのではないでしょうか？
「会社はプロジェクトが終了すればエンジニアを解雇でき、エンジニアは不満や、不安なく解雇を受け入れ、次のプロジェクトは比較的簡単に見つかる。エンジニアはそんなワークスタイルを良しとしている。」このアメリカ型モデルが実在すると仮定すると、日本との相違点は次の3点だと思います。
・労働法の解雇規制が緩い。
・エンジニアは次の仕事が見つかる。
・組織への所属欲求が低い。
さて、このようになるには何が必要なのでしょうか？
まず、エンジニアを①解雇可能な労働法が必要でしょう。但し経営の怠慢は牽制されるようなバランスのとれた法律でなければならないのはいわずもがなですが。。つぎに、エンジニアが「次のプロジェクトにもありつけるだろう！」という安心感がを醸成できるようなような②包括的なジョブマッチングの仕組み。があれば良いのではないでしょうか？
（最後に）
以上、妄言をつらつらと書きましたが、「労働者は会社に従属するもので、会社は社会からの落伍者を出さないよう教育訓練など義務を負うといった、これまでの構造が、産業が複雑になったことや、働く側の価値観が多様化していることから、合わなくなってきているような気がします。
現在も、労働者に関する問題においては、ハローワークや職位業訓練などにおいて、国策として多大なリソース（人・物・金）が割り当てられています。 また、前述したように、派遣法に関する議論や、 “2重派遣の禁止” や “偽装請負撲滅”など、労働法という根本原因を無視した表層的な問題是正の取り組みがなされているように感じます。一度、ゼロベースで考えてみる必要があると思います。（そのような専門委員会があるのか分かって言ってる訳ではありませんがｗ）
・仕事と労働者を効率的且つ包括的にマッチング可能な情報システム。
・産業や働き方の多様性も十分考慮された関連法規。
・社会からの落伍者を出さないセフティーネット。
これらのあり方について、また今度、自分なりに考えてみたいと思いました。
IT業界の多重下請構造は問題なの？ ②
前回、IT業界の多重下請構造は問題なの？① では、
多重下請け構造の問題点を洗い出してみました。つぎは、
「何故こんな構造になっているのか？」
「理想の構造とは？」
「では、何をどのようにすれば良いの？」
を順をおって考えてみたいと思います。
■何故こんな構造になっているのか？
多重下請構造は、大きな会社から、従業員数名の小さな会社まで、数多の会社が商流上で関連している状態です。ここには「①大手に一括して発注される」「②請負元エンジニアだけでは足りない」といった特徴があるように思います。
①については、ユーザー企業のシステム部門にプロジェクトを統括するマネジメント力・技術力がないことが要因だと思います。あるデータでは、アメリカと日本ではエンジニアの所属先の比率が正反対だということを示しています。
ユーザー企業 ベンダー
アメリカ 7割 3割
日 本 3割 7割
つまり、ユーザー企業は十分な技術者を抱えられていないことから、望むシステムをワンストップで、そして責任をもって一括請負い可能なベンダーを必要としているといえるかと思います。
次に②についてですが、一括受注した案件のなかには自社リソースでは提供不可能なもの（例えば顧客がIBMのハードを希望しているが当該ハードウェアのノウハウを持っていないなど）と、もう一方で、提供可能だが要員不足で対応できないものとがあります。
後者については、注文を受けて初めて生産を始める受注産業であるシステムインテグレーションは、大勢のエンジニアを抱えていると経営上のリスクになります。案件が無い時に人件費が負担になるということですね。
また逆に案件を多く受注したときに不足するエンジニアを調達するためにも、エンジニアを外部調達する仕組みが必要だと言えると思います。
また逆に案件を多く受注したときに不足するエンジニアを調達するためにも、エンジニアを外部調達する仕組みが必要だと言えると思います。
健全な経営をしようと思ったら非稼働率が10%（10人のエンジニアが在籍する会社であれば1名が空いている状態）くらいが適当かと思います。それを前提に考えると数十人単位で人を集めるには沢山の会社が関係することになるのは当然といえますね。
つまり、この多重下請け構造は、日本の現労働法下で必然的に作り上げられた人材供給システムであるといえるかと思います。
この仕組みのおかげで、必要な時に必要な数の人員が調達可能となり、エンジニアも仕事にありつけるという効用を業界にもたらしているといっても過言ではないのではないでしょうか？
また、エンジニアが独立するのに、低資本で開業可能な為、簡単にスピンアウト出来ることも会社を多くしている要因の一つだと思います。
※特定派遣の廃止が濃厚のようです。この下請構造に蔓延る一部のよろしくない会社の排除が趣旨とみましたが、根本である雇用制度を無視して廃止を行っても偽装請負に形をかえるだけのような気がします。また、偽装請負撲滅も同時に敢行した場合は、日本企業のＩＴ化への悪影響、また一部のＩＴエンジニアに仕事が回らずＩＴ業界を去るといったマイナスも考えられると思います。
この件については、またどこかで考えを整理し意見を述べたいと思いますが、産業の特性に応じた雇用制度の多様性も検討したほうが良いように思えます。
次は「理想の構造は？」について考えてみました。
IT業界の多重下請構造は問題なの？ ①
ことあるごとに「多重下請」が批判的に論じられていますが、一体何が問題で、どうあるべきなのか？について自分なりの意見を纏めてみました。
最初に今の構造の問題点を洗い出し、その後にその原因について考察してみたいと思います。
■問題点
仮に日本にいる全てのエンジニアが200人だとし、大手2社に50人ずつ、その他10社に10人ずつ所属する【下請け構造】をモデルに考えてみます。
【下請構造】
[大手Ａ社]－50人
┗[下請けA社]ー10人
┗[孫請けA社]ー10人
・
・
[大手Ｂ社]－50人
┗[下請けB社]ー10人
┗[孫請けB社]ー10人
・
・
①安全衛生の問題
通常、所属会社の違うエンジニアが集ってプロジェクトチームが出来ます。その状態では往々にして会社を跨いだ指示命令系統が出来る。つまり、[大手Ａ社]のPMが、[下請けA社]のエンジニアに直接指示命令するケースがあるが、これは法令違反です。（労働基準法）
エンジニアの健康保護の責任はその所属会社にあるので、勤務時間と切っては切り離せない指示命令は所属会社の上司がするものです。
しかしながらプロジェクトの現場では実質不可能に近い。
つまり、労働者の健康保護を目的とした機能が不完全になることがあるということです。
②間接業務の増幅
単純に会社数が増えれば、間接要素（オフィス、税務・会計、システム、エンジニア以外の人件費...）も増える。会社の数が少なければ少ないほど統合メリットが出て効率は良いと言えると思う。
・
③不当な利益
通常、報酬（売上）は価値に見合っているべきだと思いますが、例えば、[大手Ａ社]の仕事を[下請けA社]が受注し[孫請けA社]のエンジニアが作業するようなケースがある。
この場合[下請けA社]が問題となる。ただ、[下請けA社]は価値を生み出していないというのは言い過ぎで、[孫請けA社]より営業工数を掛けて営業しているから[孫請けA社]には取れない仕事が受注できたともいえると思う。また[下請けA社]は契約上のリスクも負っている。しかし直接的な業務といえば伝票を起こしているだけと言っても過言ではない。この位置の会社がマージン取り過ぎということが往々にして起こっているように感じる。
④人材マネジメント不全
例えば[孫請けB社]のエンジニアが、現場で困っているとしよう、現場で相談出来るよ内容であれば問題ないのですが、中には[大手Ｂ社]のプロマネからのパワハラ、不明確な指示など直接言えない内容で困ることも多くある。通常は所属会社の営業が問題の種を早期発見し未然に沈静化する。しかし下請け構造が多重で複雑になると、時間がかかったり、話しの要旨が伝わらなかったりでコミュニケーション不全に陥り問題が悪化することがある。突然「やってられませーん！」と言って離反するメンバーが出ることも。。
⑤価格から抱く期待とのズレ
[ユーザー企業]→[大手Ｂ社]→[下請けB社]→[孫請けB社]→[ひ孫請けB社]のような多重構造を想像してほしい。それぞれの会社が20%の粗利をとると[ひ孫請けB社]へは50万しか入ってこない。もちろん[ひ孫請けB社]も粗利をとるため全額エンジニアには渡らない。[ユーザー企業]は100万の価値を期待する。しかし実際には[孫請けB社]は50万そこそこの価値しか提供できない。といった構図が出来あがりしばしば顧客不満足につながることがある。
私が感じる問題点は以上となります。
次は、「何故こんな構造になっているのか？」について考察してみたいと思います(^^)/
※何かお気付きの点やご意見など御座いましたらコメント頂けると幸いです。
（メールでも結構です！ masahito.tomimoto@gmail.com）
また、宣伝になっちゃいますが、
2014年6月よりIT系無料勉強会を開催しております。
2014年6月よりIT系無料勉強会を開催しております。
開催した勉強会は、無料動画として配信し「時間」「場所」に制限されず学べるようにしたいと思っています。
以下のページの「申し込む」ボタンから、当Communityのイベント案内メールが配信されるようになります。
~ITエンジニア勉強会~ engineer'sLearning･Vesper | Doorkeeper
是非、ご登録を(^^)/
