京都某ＩＴ会社事件の判決文
先月末に、塩見卓也弁護士が、ついった上で
http://twitter.com/#!/roubenshiomi/status/130875404641763328
>本日、過労死ライン以上働かされ耐えられずに退職を申し出たところ、会社から損害賠償請求すると言われ、退職したら本当に２０００万円を請求する訴訟を起こされた件の判決がありました。会社の請求は全部棄却。こちらの反訴請求は、未払残業代と付加金を併せて１１００万円以上が認容されました。
とつぶやいていた事件の判決文が、さっそく最高裁のHPにアップされました。
それだけの値打ちのある判決だと思われたわけですね。
これです。
http://www.courts.go.jp/hanrei/pdf/20111129185940.pdf
会社側が、この労働者に「2000万円払え！」と訴えた甲事件については、
>本件においては，被告ＢあるいはＣチームの従業員のミスもあり，Ｃ社からの不良改善要求に応えることができず，受注が減ったという経過は前記認定のとおりであるが，被告Ｂにおいてそれについて故意又は重過失があったとは証拠上認められないこと，原告が損害であると主張する売上減少，ノルマ未達などは，ある程度予想できるところであり，報償責任・危険責任の観点から本来的に使用者が負担すべきリスクであると考えられること，原告の主張する損害額は２０００万円を超えるものであり，被告Ｂの受領してきた賃金額に比しあまりにも高額であり，労働者が負担すべきものとは考えがたいことなどからすると，原告が主張するような損害は，結局は取引関係にある企業同士で通常に有り得るトラブルなのであって，それを労働者個人に負担させることは相当ではなく，原告の損害賠償請求は認められないというべきである。
そらまあ、常識で言うたらそうでしょう。こういうブラックな会社がまかり通ったらあきまへん。
一方、労働者側の反撃で、専門型裁量労働制の適用を争ったところについては、「情報処理システム（電子計算機を使用して行う情報処理を目的として複数の要素が組み合わされた体系であってプログラムの設計の基本となるものをいう。）の分析又は設計の業務」には、
>プログラミングについては，その性質上，裁量性の高い業務ではないので，専門業務型裁量労働制の対象業務に含まれないと解される。
と判断しています。
これは、かなり大きな影響を与えるところなので、詳しく見ていきましょう。裁判所のロジックによると、
>本来プログラムの分析又は設計業務について裁量労働制が許容されるのは，システム設計というものが，システム全体を設計する技術者にとって，どこから手をつけ，どのように進行させるのかにつき裁量性が認められるからであると解される。しかるに，Ｃ社は，下請である原告に対しシステム設計の一部しか発注していないのであり，しかもその業務につきかなりタイトな納期を設定していたことからすると，下請にて業務に従事する者にとっては，裁量労働制が適用されるべき業務遂行の裁量性はかなりなくなっていたということができる。また，原告において，被告Ｂに対し専門業務型裁量労働制に含まれないプログラミング業務につき未達が生じるほどのノルマを課していたことは，原告がそれを損害として請求していることからも明らかである。さらに，原告は，前記認定のとおり，Ｆ部長からＣ社の業務の掘り起こしをするように指示を受けて，Ｃ社を訪問し，もっと発注してほしいという依頼をしており，営業活動にも従事していたということができる（原告は，原告とＣ社との間で毎月１０００時間相当の発注をすることの合意ができていた旨主張するが，目安という程度のものであったことは前記認定のとおりであり，営業活動を不要とするようなものではなかったといえる。）。
以上からすると，被告Ｂが行っていた業務は，労働基準法３８条の３，同法施行規則２４条の２の２第２項２号にいう「情報処理システムの分析又は設計の業務」であったということはできず，専門業務型裁量労働制の要件を満たしていると認めることはできない。
このロジックからすると、受託開発型、労働集約型、多重下請構造、顧客従属型で特徴づけられる日本の情報サービス産業で働く労働者の大部分には、専門業務型裁量労働制は適用できないことになりませんかね。
それとも、本件では、専門業務型裁量制といいながら、達成できないほどのノルマを課していたというのが効いているのかな。でも、そういうのもこの業界には結構ありそう。
けっこうインパクトの大きい判決ではないかと思われます。甲事件の方の会社の要求があまりにもトンデモなのですが、この乙事件の方は、上まであげて判断をしてもらう必要があるように思われます。
わたくしからすると、裁量労働制であっても野放図な長時間労働は許されず、自ずから制約があるという話に進んで欲しいのですが、現状ではこういう方向で歯止めをかけるしかないのでしょうか。
(追記)
ちなみに、この会社のＨＰを覗いてみたら、
http://www.addev.co.jp/aboutus/
「事業内容」として、
>コンピュータ技術者の出向による開発業務 (業務請負)
いやぁ、出向しちゃったら請負にならないでしょう。
仮に派遣という意味だったとしても、（商法上の労務請負ではあっても）やっぱり業務請負にはならないでしょう。
てか、そういう法律用語を書いてるわけではないんでしょうけど。
« 若者賃金引下げ論＠スウェーデン | トップページ | 行方不明原発作業員の探索 »
コメント
トラックバック
この記事へのトラックバック一覧です： 京都某ＩＴ会社事件の判決文:
» [ブラック企業][IT業界][ホワイトカラーエグゼンプション][プログラミング] プログラマは専門家ではありません（キリッ） [カレーなる辛口Javaな転職日記]
http://eulabourlaw.cocolog-nifty.com/blog/2011/11/post-9c85.html 極めて興味深い判例なのでメモ． 本日、過労死ライン以上働かされ耐えられずに退職を申し出たところ、会社から損害賠償請求すると言われ、退職したら本当に２０００万円を請求する訴訟を起こされた件の判... [続きを読む]
» 吉田所長と芦田愛菜、そして天皇の定年制 [山階宮透の日記]
東電福島第一原発所長で病名はわからないが入院ということで所長を退任された吉田氏。病名については当日記でも書いているけど病名が伏せられている以上推測、憶測が飛び交ってはいるが吉田氏自身が、仕事とはいえ命をかけて仕事をしたということは誰しも認めるところだろう。もち... [続きを読む]
濱口先生、取り上げていただいてありがとうございます。塩見です。プログラミング業務はＳＥ業務に含まれないとの判断ですが、この点は厚労省の通達にはっきり書いてあるところです。裁判所は、この点行政通達に従ったということです。
投稿: 塩見卓也 | 2011年11月30日 (水) 22時57分
この通達のこの部分ですね。
http://wwwhourei.mhlw.go.jp/cgi-bin/t_docframe.cgi?MODE=tsuchi&DMODE=CONTENTS&SMODE=NORMAL&KEYWORD=&EFSNO=7184">http://wwwhourei.mhlw.go.jp/cgi-bin/t_docframe.cgi?MODE=tsuchi&DMODE=CONTENTS&SMODE=NORMAL&KEYWORD=&EFSNO=7184
>４ 裁量労働に関するみなし労働時間制の対象業務
(２) 対象業務
② 則第二四条の二第六項第二号の業務「情報処理システム(電子計算機を使用して行う情報処理を目的として複数の要素が組み合わされた体系であつてプログラムの設計の基本となるものをいう。)の分析又は設計の業務」
「情報処理システム」とは、情報の整理、加工、蓄積、検索等の処理を目的として、コンピュータのハードウェア、ソフトウェア、通信ネットワーク、データを処理するプログラム等が構成要素として組み合わされた体系をいうものであること。
「情報処理システムの分析又は設計の業務」とは、(ⅰ)ニーズの把握、ユーザーの業務分析等に基づいた最適な業務処理方法の決定及びその方法に適合する機種の選定、(ⅱ)入出力設計、処理手順の設計等アプリケーション・システムの設計、機械構成の細部の決定、ソフトウェアの決定等、(ⅲ)システム稼働後のシステムの評価、問題点の発見、その解決のための改善等の業務をいうものであること。プログラムの設計又は作成を行うプログラマーは含まれないものであること。
実際のソフト開発の現場で、どの程度このとおりにやっているのか、あるいはそもそもSEとプログラマーがどこまで異なっていてどこまで同じなのか、といったことも、私はよく分からないのですが、Wikiなどをみると、こういう記述もあったりして、
http://ja.wikipedia.org/wiki/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2">http://ja.wikipedia.org/wiki/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2
>日本では、システムエンジニアがプログラム仕様を作成し、それに基づいてプログラマがプログラミングを行うという分業が行われることが多かった。しかし、プログラミング環境が進化した現代のシステム構築では、システムエンジニアがプログラマを兼任することも多くなっている。 [3] この傾向は小規模プロジェクトで顕著である。逆に、プログラマが要求定義や設計など従来システムエンジニアの職分とされていた職域に進出することも増えており、境界は曖昧化している。 [4]
最近では、プログラマ／システムエンジニアという区別をせず、ソフトウェア技術者(Software Engineer)やソフトウェア開発者(Software Developer)などと呼ぶ企業も増えてきている。
なお、日本のソフトウェア受託開発業では、システムエンジニアと呼ぶ方が上級技術者らしく聞こえて高い単価を要求できるため、能力や適性が伴わなくても、ある程度の年齢になると、システムエンジニアと名乗らせることが多い。
こういう状況を前提とすると、上記通達の文言をどう理解すべきなのかも、いろいろと考えるべきことがありそうに思います。
まあ、しかし、改めて判決文を読むと、ひどい会社ですね。
投稿: hamachan | 2011年11月30日 (水) 23時19分