2018年8月10日金曜日
Qualcomm、「Snapdragon 670」を発表 AIエンジンやCPUなどが向上
「Snapdragon 660」と比較し、AIエンジンの性能は最大1.8倍、「Kryo 360 CPU」の性能は最大15%、「Adreno 615 GPU」のグラフィクスレンダリング性能は最大25%向上。ISP(イメージシグナルプロセッサ)は「Spectra 250 ISP」を搭載し、25MPのシングルカメラと16MPのデュアルカメラをサポート。通信速度は下り最大600Mbps、上り最大150Mbpsを実現する。
2018年8月9日木曜日
大阪ガスにおけるデータ分析専門組織の運営法 ——「見つける力」「解く力」「使わせる力」を兼ね備えたフォワード型分析者集団を目指す
データ分析専門組織の運営は完全な独立採算制
——まずは河本さんが率いる大阪ガスのビジネスアナリシスセンターについて、ご紹介をいただけますか。
河本 ビジネスアナリシスセンターはデータ分析の専門組織で、位置づけとしてはIT部門(情報通信部)の内部組織となります。私を含めた9名のメンバーで、年間30近いプロジェクトを手掛けています。最大の特徴は独立採算制で活動していることです。
——所属するIT部門の予算で動いているわけではないのですか。
河本 はい。予算はまったくのゼロ。自分たちの人件費さえ確保されていません。
——冒頭から衝撃的なお話が飛び出しましたね。企業内のデータ分析組織ということで、多くの企業の間接部門と同じように計画的な予算の中で活動しているのだろうという先入観をもっていました。では、自分たちの"食い扶持"は自ら稼いでいるのですか。
河本 そうです。大阪ガスのすべての組織や関係会社が私たちにとってのお客様であり、たとえば営業部門が顧客ターゲットの絞り込みで困っている場合、私たちが「単価〇〇円×〇人月の費用で、こんな分析をしてみませんか」と提案します。交渉が成立すればプロジェクトがスタートしますし、立ち消えになることもあります。
——なぜそのような独立採算制をとっているのでしょうか。
河本 そのデータ分析を本当に行う価値があるかどうか、判断するのは非常に難しいですよね。あとから効果を測定することさえ困難なのに、事前に効果を定量的に評価するなどまさに至難の業です。では、だれがその判断を下して責任を取るかというと、データ分析の結果を必要としている当事者である事業部にほかなりません。データ分析は「なんとなく」やっても意味のある結果は得られず、事業部側とデータ分析専門組織のシビアな関係性を維持するためにも、大阪ガスではあえて独立採算制をとっています。
——ビジネスアナリシスセンターを牽引していくお立場として、苦労するのはどんなところですか。
河本 データ分析専門組織というと、たとえば保険会社のアクチュアリーチーム、製薬会社の臨床データ管理チーム、あるいは自治体の統計課などをまず思い浮かべるのではないでしょうか。ところが大阪ガスをはじめとする一般企業のデータ分析専門組織は、それとはかなり内実が違っています。
——具体的にどんな違いがあるのですか。
河本 保険会社のアクチュアリーチームや製薬会社の臨床データ管理チームは、それぞれの企業のビジネスにとって必然性があり、専門性も持っており、おのずと他の部門との分業が成り立っていると思います。
ところが大阪ガスのような一般企業にとってデータ分析専門組織は、仮に今日なくなったとしても当面困ることはありません。統計解析や機械学習といった分析手法の専門性だけで存在意義を発揮できるわけでもありません。すなわち企業にとって、必要不可欠な組織ではないのです。組織間の役割区分も明確ではなく、実際に私たちは各事業部と一体となってプロジェクトにあたっています。このような必然性を示すことが難しい組織をマネージメントしていくのはやはり大変です。
問題を「解く」ことだけが分析者の仕事ではない
——さまざまな課題も抱える中でビジネスアナリシスセンターが価値を発揮し、存在感を高めていくために、どんなことを目指して心掛けているのでしょうか。
河本 端的に言えば、事業部の信頼を勝ち取ることです。ビジネスアナリシスセンターでは自らのミッションを「企業の全組織、全業務、全サービスにおいてデータ分析の活用機会を発掘し、分析力で新たな価値を創造する」と定めています。ここで示す新たな価値とは何かというと「データ分析で終わらず、業務改革まで担う」ことで、そこに貢献してこそ事業部の信頼を得られると考えています。
——データ分析専門組織と言いつつ、事業部に提供すべき本来の価値はデータ分析のその先にあるというわけですね。
河本 はい。これは私自身の経験でもあるのですが、往々にして分析者は与えられた問題を「解く」ことが自分の仕事と思いがちです。ところが現実には、事業部門から「このデータを分析してほしい」と直球で依頼されるような案件は、実際には解決すべきビジネス課題が何なのかも十分に煮詰め切れていないケースが少なくありません。目的が明確でないのに、求められるままに分析を行っても効果は得られません。
特に大阪ガスのような一般企業のデータ分析専門組織のメンバーは、単に問題を解くだけの「バックオフィス型分析者」であってはなりません。ビジネスの課題がどこにあるのかを「見つける力」、そこから明らかになった分析問題の「解き方を考える力」、そして得られた知見や知識を依頼者である事業部門の意思決定につないでいく「使わせる力」、この3つの力を兼ね備えた「フォワード型分析者」でなければならないと考えています。
——なるほど。先に挙げていただいた保険会社のアクチュアリーチームや製薬会社の臨床データ管理チームのようにビジネスの生い立ちから自然な流れで分業が成り立っている組織とは違い、一般企業のデータ分析専門組織はある意味で「解く」ことへのこだわりを捨てる必要があるのかもしれませんね。
河本 実際、ビジネスアナリシスセンターでもメンバーの活動時間の大半が「解く」で費やされていました。内訳を詳しく調べてみると、独創的な分析を行っている時間は全体の活動時間の3分の1くらいしかありませんでした。残りの大半の時間が、過去にも似たような問題を解いたことのある定型的な分析、あるいは後で振り返ればやる必要のなかった無意味な分析などに費やされていたのです。このように「解く」ことにばかり時間を重ねていたのでは、「見つける」「使わせる」といったところで力を発揮することができません。
——課題を"持ち帰る"という姿勢で臨むと、どうしてもある程度まとまった結果を返さなければならないと意識が働き、「解く」ことのみに向いてしまいます。そうではなく依頼者と頻繁なやりとりを繰り返しながら分析を進めていくことが重要なのでしょうね。
河本 そのとおりです。プロジェクトの最初の段階から依頼者の意図を完全に理解できるわけではなく、課題に対する勘違いもしばしば起こります。おっしゃるようなアジャイルな姿勢で常に依頼者とやりとりを行っていかないと、あとで壮絶な手戻りが発生することになってしまいます。これは事業部側にとっても私たちにとっても不幸なことです。
定型的な分析はアウトソーシングする
——問題を「解く」ことへの偏重をなくし、ひいてはデータ分析の手戻りを減らすために、どんな施策を打っているのですか。
河本 繰り返しますが、ビジネスアナリシスセンターにとって最も重要なのは分析ではなくビジネスであり、そのコアは「見つける」+「解き方を考える」+「使わせる」であるという価値観をメンバー全員で共有し、徹底する必要があります。そこで、過去にやったことがあり定型化できるデータ分析はアウトソーシングするという方針をとっています。
——アウトソーシングのパートナー探しにも苦労されたのではないですか。
河本 そこは大阪ガスの幸運ともいえるところで、オージス総研という優れた技術力をもつIT子会社があるのです。グループ企業ということもあって顧客データの共有なども比較的やりやすく、データ分析のアウトソーシングではこれ以上ないパートナーです。
——オージス総研には具体的にどんな形で業務を委託しているのですか。
河本 毎年1〜2名の人材に出向してもらっています。おかげで社内メンバーは独創的な分析に専念するとともに、「見つける」「使わせる」といった部分により多くの時間を割けるようになり、活動全体のバランスはかなり良くなったと思います。
また、オージス総研からの出向者にもさまざまなプロジェクトを通じて、IBM SPSSを活用したデータ分析の方法論をしっかり学んでもらいます。オージス総研に帰ってからもビジネスアナリシスセンターでの経験から得たノウハウを活かし、外販のお客様に向けてデータ分析ソリューションをワンストップで提供していく担い手になります。
——今後、ビジネスアナリシスセンターをフォワード型分析者集団としてさらに発展させていくためには、どんな取り組みが必要ですか。
河本 私たちは基本的に縁の下の力持ちですが、ずっと縁の下にいるだけではだれからも評価されません。そこで積極的に講演会を行ったり、メディアに出たり、ビジネスアナリシスセンターの知名度を外部から高めることにも意識して取り組んでいます。
もうひとつメンバーのモチベーションを高めるために重要なことは、一人ひとりの幸せを勝ち取ることだと考えています。メンバーの大半は理系の大学院を卒業した人たちですが、専門は化学や電気、環境、資源などバラバラで、統計学などまったく学んでいない人もいます。実のところ「アナリストやデータサイエンティストになりたい」と望んでビジネスアナリシスセンターに配属されてきたわけではないのです。そんな彼らだからこそずっと縁の下に置かれたのでは報われません。そこで「成長の道を示す」「成長できる仕事をアサインする」、そして個人のブランド価値を高めるなど「サラリーマンとして幸せにする」ことを目指しています。また、メンバーの「やりたいこと」「やるべきこと」「やれること」を増やして、組織としてのフロンティアを広げられるように努力しています。新入社員に「自分もビジネスアナリシスセンターに配属されたい」と思ってもらえる憧れの組織になることが、さらなる発展の条件と考えています。
——では、これから入ってくる若手社員をどのように育成していきますか。
河本 その答えは現在も今後も変わらず明確で、崖から落として育てます(笑)。あえて困難なプロジェクトを一気通貫で任せるのです。「その数字に責任を取れるか?」「その数字から何が分かったか?」「意思決定にどのように使えるか?」「ビジネスにどれほど役立ったか?」という4つの問いを常に突き付け、規律を守らせます。もちろん分析結果をビジネス現場で使ってくれたなど、成果を上げた際には正しくほめてモチベーションを高めます。そうした中で現場の知恵や責任の重さに対する敬意を払い、「知らないこと」を聞き続ける謙虚さを学ぶとともに、主張すべきことは主張する媚びない姿勢を身に付けてほしいと思います。
——本日のお話を伺って、�ビジネスアナリシスセンターにとって、データ分析は問題を解く「手段」であって、目的ではなく、データ分析で得られた知見をビジネスの現場で役立てて業務改革を実現することで価値が生まれること、�定型的な分析は外部に委託したり、自動化することで、ビジネスアナリシスセンターのメンバーが「見つける」「使わせる」のステップに集中できる環境を整えること、�分析組織のリーダーとして、常にメンバーのモチベーションを維持するための働きかけを続けることで、組織としての分析力を高めること、という企業内のデータ分析専門組織が担っていくべきミッションと意義を非常によく理解できました。本日は貴重なお話をありがとうございました。
年収が高いプログラミング言語は「Go」——「Scala」と「Python」が続く
ビズリーチは2018年8月7日、同社が運営する求人検索エンジン「スタンバイ」で、「プログラミング言語別年収ランキング2018」を発表した。
スタンバイに掲載されている約324万件の正社員求人情報を基に、6月30日時点で各プログラミング言語名が含まれる求人情報の提示年収の中央値を集計したもの。
1位は「Go」で提示年収の中央値が600万円、2位は「Scala」で同じく600万円、3位は「Python」で575.1万円だった。上位にはスクリプト言語が多く入っており、求人数ではRuby、Python、Cが際立っている。
プログラミング言語別年収ランキング(出典:ビズリーチ、スタンバイ)
1位のGoは、C言語のような静的型付けのコンパイル型言語でありながら、ガベージコレクションやメモリの安全性などを備えており、Dockerなどの基盤ソフトウェア開発の他、ツールの開発やWebサーバなどで利用されている。
Goは世界でも人気のある言語で、質問サイトStack Overflowの年次レポート(2018年)では、最も愛されるプログラミング言語、スクリプト言語、マークアップ言語の5位に入った。2017年はスタンバイで求人数が少なくランキングに入らなかったが、2018年の求人数は2017年に比べて1.9倍に増えた。ビズリーチでは今後も注目されるだろうと予想している。最大提示年収は1600万円、求人数は2202件だった。
2位のScalaは、オブジェクト指向言語と関数型言語の特徴を併せ持った言語。TwitterやLinkedInなどが利用していることで知られている。国内でもインターネット企業を中心に採用が増えていることに対して、扱える人材が少ないことから、ビズリーチでは提示年収が高い言語だとしている。最大提示年収は1300万円、求人数は1489件だった。
3位のPythonは、機械学習や統計分析向けのライブラリが充実していることなどから、研究機関の研究者やデータサイエンティストに利用されている。最近では機械学習や統計分析の活用が進んでおり、さらに需要が高まると見られる。ビズリーチによると、Pythonの求人数は2017年比で1.7倍に増加した。最大提示年収は1499万円、求人数は9344件だった。
3位以降は「Kotlin」「TypeScript」「R」が続く
4位は「Kotlin」で、年収の中央値は575万円、最大年収は1200万円だった。求人数は961件で、2017年比5.3倍に増加した。2017年5月にGoogleがAndroidアプリ開発の公式言語として追加すると発表したことでニーズが急上昇したためだと、ビズリーチは分析している。
同社によると、KotlinはWebサービスの開発でも採用事例が増えてきており、さらにJavaの既存ライブラリを利用できるため、Javaに代わる言語としてさらに需要が高まると見られる。
5位は「TypeScript」で、年収の中央値は575万円、最大年収は1200万円、求人数は667件。同言語はJavaScriptを拡張したもので、TypeScriptのソースコードはJavaScriptのコードに変換(トランスパイル)して実行される。
ビズリーチによると、TypeScriptは機能を分割しやすいため大規模アプリケーションのチーム開発に適しており、Webサービスのフロントエンドなどで広く利用されているという。2017年4月にGoogle社内の標準言語の1つとして採用されたことから導入する企業が増えており、求人数は2017年の3.2倍に増加した。
6位は「R」で、年収の中央値は574.8万円、最大年収は1000万円、求人数は220件。7位は「Ruby」で、年収の中央値は550万円、最大年収は1200万円。Rubyは求人数が1万1676人と10位以内では最も多かった。
2018年8月6日月曜日
SESで働いているけど、客先から直接指示を受けています。これって違法ですか?
詳細な作業や成果物を契約時点では決め切れないアジャイル開発やITの保守、運用作業では、「わが社の技術者を、お客さまの指示で使ってください」という形態は、実際のところ便利で、ある意味合理的でもあったのだ。
※参考リンク:「(旧)特定労働者派遣事業」は行えなくなります!(厚生労働省)
特定労働者派遣廃止後、この形態を便利に使ってきたITユーザー(発注者)とベンダー(受注者)が今まで通りに作業を行おうとして犯しそうな間違いが、「偽装請負」である。
契約上は「請負」でありながら、実際には受注側メンバーが発注側担当者から直接指示を受ける、勤務時間や残業を管理される、契約外の作業もさせられるなどは、受注者側に「最大1年の懲役もしくは100万円の罰金」という刑事罰が適応される違法行為である。
しかし、今まで通りの作業を契約書のお題目だけ変えて実施しようとする企業が発生する可能性は否めない。
IT訴訟事例を例にとり、システム開発にまつわるトラブルの予防と対策法を解説する本連載、今回は少し趣旨を変えて、「請負」「派遣」「SES契約」の違い、そして「偽装請負」について考える。
偽装請負扱いされると困るから、俺が直接指示したことは黙っていてくれ(画像はイメージです)
契約は請負、実態は派遣
2014年3月の国会で、以下の問題が取り上げられた。
2014年3月26日 参議院消費者特別委員会 日本共産党大門紀史議員質問から
大手ITベンダー系コンサルティング会社の上級コンサルタントが、あるメガバンクのシステム開発プロジェクト(請負契約)に参加したところ、そこでは発注者であるメガバンクの担当者が、そこに常駐するコンサルタントや、他のITベンダーの作業者に直接作業指示を出していた他、勤務時間の管理も行っており、また、このコンサルタントに対しても、データ入力やコピー取りなど請負契約で定められた以外の作業が命じられた。
これについて、コンサルタントが、この作業の実態は請負ではなく派遣ではないかとメガバンクの担当者に疑問を呈したところ、コンサルタントはプロジェクトメンバーから外された。
この問題は既に、厚生労働者東京労働局から偽装請負であるとして派遣元のコンサルティング会社とメガバンクの両方に是正指示が出されている。
実際のところ、こうした偽装請負はIT産業以外でも散見され、中には派遣元企業に業務停止命令が出たケース(※)などもある。
※参考リンク:偽装請負、企業に一罰百戒 最大手クリスタルに厚生労働省がメス(日経ビジネス 2006年10月17日)
このように各所で耳にする「偽装請負」だが、それが違法行為であることに当事者たちが気付いていない例も多い。少し古い話だが、かく申す私自身がそうだった。
知らず知らずのうちに偽装請負の犠牲者になる例も
ある金融機関のシステム更改プロジェクトのため、客先に「請負契約」で常駐していた私は、本来の業務とは関係のないPCの操作に迷う客先担当者に操作法を教えたり、トラブル対応などを行ったりしていた。誰から言われるでもなく、単に善意で行っていたのだ。
その様子を見た客先の担当者が、社内で起きるさまざまなITトラブルに関する相談を私に持ち掛け、私は対応に忙殺されるようになった。作業の中には小さいながらも全く新しいプログラムの作成などもあり、納期が変わることのなかった本業にも対応しなければならないため、深夜まで残業することもしばしばだった。
プロジェクトマネジャーは状況を知っていたにもかかわらず、私に「本業の納期は守るように」と言うだけだった。客先担当者は何の罪の意識もなく、「本当に助かる」と私に作業を依頼してきた。そして、当の私自身、「お客さまに喜んでもらえて自分のプレゼンスが上がる」と、むしろ積極的に、こうした契約外作業に取り組んでいた。誰も不満を持たず、不審にも思わない中、私はズルズルと「偽装請負」の被害者になっていたのだ。
誰にもこれが違法行為だという意識はなかった。しかし、こうした作業の仕方には明らかにリスクがあり、大きな問題にならなかったのは、私が単に運が良かっただけなのだ。
「契約外作業」の「直接指示」がまん延すると、受注側の作業者は、五月雨式にやってくる契約外作業の対応に追われながら、本来の業務もどんな苦労をしてでも完遂しなければならなくなる。発注側担当者から深夜残業や休日出勤を命じられるかもしれないし、体調不良で休んでも、「では、回復後の残業で取り返せ」などと言われるかもしれない(実際、そうした例を私は幾つも見てきた)。
それでも請負契約なので追加の費用は認められず、作業が遅れれば減額や支払い拒否を言い渡されるし、瑕疵(かし)担保責任まで付いてきてしまう。こうした状況を、大した罪の意識もなく発注者と受注者が作り出してしまうのが「システム開発、運用・保守における偽装請負」の一形態である。
もっとハッキリと悪意を持った偽装請負なら、作業者の勇気次第で解決への道筋もつきそうだが、こうしたケースの場合には、そもそも問題にすらならない例も多い。
キープレイヤーはプロジェクトマネジャー「の上司」
しかし、悪意の有無にかかわらず、「偽装請負」は立派な犯罪である。
偽装請負ではないが、かつて発注側担当者の高圧的な態度が一因となって、受注者のプロジェクトマネジャーが健康を損ねたケース(東京地方裁判所 平成19年12月4日判決)がある。
判決で裁判所が「その責任はベンダー側(受注者)の労務管理にある」と判断したことを考えると、偽装請負により作業員が被る被害の責任は受注者に求められる可能性が想定される。受注者は、これをよくよく心に刻んでおかねばなるまい。
そもそも、発注者は「請負」をどの程度認識しているのかは分からない。発注者は、ある意味無邪気に、契約範囲外の作業も含めた作業指示を出しているのかもしれない。受注者は、そうしたことからメンバーを守る義務がある。
キープレーヤーは、受注者のプロジェクトマネジャー"の上司"だ。
多くの場合、偽装請負が行われる現場は常駐している客先である。本来なら、常駐先の責任者である受注側のプロジェクトマネジャーが、「発注側担当者がメンバーに直接指示をしていないか、作業時間などを縛り付けていないか、契約外の作業を行っていないか」をチェックする。
しかし、プロジェクトマネジャー自身も常駐者である。客先との人間関係を忖度(そんたく)したり、偽装請負作業に神経がマヒして気付かなかったりしていることがある。
そういう場合は、客観的に作業の状態を判断できて、何か問題があれば客先にモノを言えるプロジェクトマネジャー"の上司"が、小まめに常駐先を訪問して、メンバーにヒアリングを行いながら情報を集めることが必要だ。
「お客さま」に対してモノを言うのは気の引ける部分もあるが、ことが発覚すれば重大な問題に発展しかねないし、上司の責任も強く糾弾される。発注側の担当者は、そもそも偽装請負を知らないケースもあるので、「言うべきことはしっかりと言う」という姿勢が必要だ。
ちゃんと見張っています
SES契約の危険
ここまでで紹介した事例は、「請負契約だったはずが、実際には派遣労働と変わらなかった」というものだったが、同じような危険を持つ契約の形態に「SES」(System Engineering Service システムエンジニアリングサービス)契約がある。
SESは、正しく運用されていれば違法行為ではない。しかし、受注者が作業範囲を超えた作業をさせられたり、請負契約でもないのに成果物の完成や品質に責任を持たされ、瑕疵担保責任まで負わされたりすれば、立派な法律違反だ。
「請負」「派遣」「SES契約」の特徴
まず、「請負」「派遣」「SES」の特徴を簡単に整理する。
請負
請負契約は、受注者は発注者の望む「成果物の完成」を求められる。
一方、その作業方法や人員、作業時間など、完成に至る「方法」は、受注者の裁量に任される。例えば、洋服をオーダーメイドで作成する場合、客は、期日までに注文したものが、見積もり通りの価格で出来上がっていれば、誰が、いつ、どのような作業方法で服を作ったかについて関知しないし、できない。契約書で約束した「モノ」とその「数量」がそろっていればいいのだ。
請負契約には、通常「瑕疵担保責任」が付けられる。いったん納品した成果物であっても、受け取り時点では気付かなかった欠陥(ソフトウェアにおいてはバグなど)に発注者が後で気付いた場合、民法の定めでは「納品後1年以内であれば、無償で修補を求める」ことができる。
関連記事
請負契約(うけおいけいやく)
瑕疵担保責任(かしたんぽせきにん)
派遣
請負と全く逆の性質を持つのが派遣契約だ。顧客が買うのは、派遣される要員の「労働力」であり、働く「時間」によって金額が決まる。「1時間当たり1000円の労働力を月に160時間買うから、16万円支払う」という契約だ。
派遣されたメンバーは、派遣先の指揮命令、作業管理の下、作業を行う。どのような作業を、どのように実行するのかも、派遣先の指示に従って行う。
請負と違って、その成果物に責任は負わない。(実際の運用においては微妙なところだが)作ったソフトウェアにバグが残存して使い物にならなかったとしても、定められた時間、真摯に作業に取り組んでいれば、その責任を派遣されたメンバーが負うことはない。
関連記事
人材派遣の仕組み
派遣業と請負業の違い
SES
近頃よく耳にするSESは「準委任契約」に分類される。
本来、発注者が自身で行うべきITに関する作業を、一定の能力を持ったメンバーが「代わりにやってあげる」という解釈が妥当かと思う。
「客先で作業を行うのが一般的」という点は派遣とよく似ている。異なるのは、その「指揮命令系統」だ。
発注者は直接、受注者のメンバーに指示を出すことはできないし、勤怠管理を行うこともできない。それらは受注者の責任者を通して行わなければならない。
受注者が成果物の完成に責任を持つこともない。作業の手段などは受注者に任され、代わりに受注者は報告書を提出する。
関連記事
準委任契約(じゅんいにんけいやく)
それぞれの特徴を表にまとめよう。
形態
提供するサービス
手段
指揮命令/勤怠管理
備考
請負成果物 受注者の裁量に任せる 受注者 瑕疵担保責任あり
派遣労働力 発注者の指示に従う 発注者 成果物に責任を負わない
SES(準委任)労働力 受注者の裁量に任せる 受注者 報告書を提出する
実に曖昧なSES契約
SESは受注者にある程度の裁量が任されていながら、成果物の責任を負わない契約のはずだが、実際の現場では、こうしたルールを無視した運用がかなり行われているように思われる。
発注者が受注側作業責任者を通さずに、受注者のメンバーに「明日の朝までに、このプログラムを修正して」と言うことなど日常茶飯事だ。
受注者は作業管理は行われないはずなのに、指定した時間分働いたことを証明するために出退勤の時刻の報告を求められたり、遅刻や早退をするのに発注者の許可が必要なケースも多いと聞く。
さらに、請負ではないのに、プログラムにバグがあれば時間を超えてでも修正することを要求され、作業期間終了後に発生した問題に対応させられることも珍しくはない。
最大の問題は、受注側管理者が現場におらず、こうした契約の逸脱行為が行われていても実態を把握できないケースがあることだ。
受注者は最悪、発注者の命令に基づいてモノが出来上がるまで拘束され、ときには契約外の作業も依頼される一方、出退勤や勤務態度まで縛られる割に、支払われる費用は定額で動かず、成果物について瑕疵担保ともとれる責任を負わされる危険があるのだ。
こうした実態が明らかになると、受注企業は、偽装請負を行ったとして1年以下の懲役か100万円以下の罰金を受ける場合がある。こうした刑罰以上に、会社としての信用も地に落ちることになるので、よくよく注意されたい。
参考リンク:労働者派遣・請負を適正に行うためのガイド(厚生労働省)
偽装請負チェックリスト
最後に、システム開発の現場で「偽装請負」に当たると考えられる行為をまとめてみた。参考にしていただければ幸いである。
請負の場合
* 発注側担当者が受注側メンバーに対して直接、指揮命令を行う
* 発注側担当者が受注側メンバーに対して作業時間の指示や管理を行う
* 発注側担当者が受注側メンバーに対して時間外労働を指示する
* 発注側担当者が受注側メンバーの評価を行い、それに応じた価格変更を行う
* 発注側担当者が受注側メンバーに対して契約上定められていない服務上の規律に関する事項についての指示、その他の管理を自ら行う
* 発注側担当者が受注側メンバーの役割分担や責任、配置について指示する
* 発注側担当者が請負の対象外となる作業を受注側メンバーに命じる
派遣の場合
* 成果物の責任を負わされる
SESの場合
* 発注側担当者が受注側メンバーに対して直接、指揮・命令を行う
* 発注側担当者が受注側メンバーに対して作業時間の指示や管理を行う
* 発注側担当者が受注側メンバーに対して時間外労働を指示する
* 発注側担当者が受注側メンバーの評価を行い、それに応じた価格変更を行う
* 発注側担当者が受注側メンバーに対して契約上定められていない服務上の規律に関する事項についての指示、その他の管理を自ら行う
* 発注側担当者が受注側メンバーの役割分担や責任、配置について指示する
* 成果物の責任を負わされる
次期iPhoneにも影響? 半導体受託大手TSMCがウイルスで工場停止
TSMCは、米国のApple、AMD、NVIDIA、Qualcommなどから半導体製造を請け負っている。AppleはiOS製品のメインプロセッサ「A12」の製造をTSMCに発注したと報じられている。
TSMCは発表文では具体的な顧客への影響には言及していないが、納品スケジュールで顧客と緊密に協力しており、「第3四半期(7~9月)の収益への影響を約3%と見積もっている。第3四半期の遅れは、第4四半期に取り戻せると確信する」としている。
Appleは例年、9月前後にiPhoneの新モデルを発表・発売しており、初期出荷への今回の工場停止の影響が懸念される。
このウイルス被害は、サイバー攻撃によるものではなく、工場への新しいツールのソフトウェアインストールプロセス中の操作ミスによるとTSMCは説明する。その新しいツールを全社ネットワークに接続したことで、ウイルスが拡散した。機密情報には影響はないという。同社は今後、セキュリティ対策を強化していくとしている。