ベンダー社員過労死の遠因はユーザー企業にもあるのか：「訴えてやる！」の前に読む IT訴訟徹底解説（111）（2/2 ページ）

仕様確定が遅れ、プログラム数が大幅に増え、スケジュールが2カ月以上遅れ、しかも納期順守を求められたプロジェクト。そこに従事するエンジニアがある日、遺体で見つかった――。

[ITプロセスコンサルタント細川義洋，＠IT] PC用表示関連情報

LINE

Hatena

前のページへ | 　　　　　　

本当に悪いのは誰か？

　裁判の結果は、社員Aの死と業務の関係を否定するベンダーの主張が一蹴され、遺族の勝訴といっていい内容であった。いきさつを見る限り、当然の判断といえよう。

　ただ、単にベンダーの労務管理の不備だけを追及しても同じような悲劇を防止するには至らないのではないか、と私は思う。ベンダーは、昔々の『蟹工船』や『女工哀史』のように、上司が部下の作業の全てを制御するような職場ではない。それはベンダーにおける「定時退社日」の実態を見ても分かる。

　「定時退社日」を設定している企業は多いだろう。私が以前働いていたベンダーでも、毎週水曜日は原則17時20分の退社が定められ、課長職は部下の残業を抑制するよう命じられていた。これは、経営層も労働組合もその意思を同じくするところであった。

　ただ多くの社員（特にシステムエンジニアやプロジェクトマネジャーなど）からすれば、こうした制度や上司からの呼び掛けは、ワークライフバランス改善や健康の促進に効果的ではなかったように思う。

　いくら上司が「早く帰れ」と言ってくれても、今、目の前に山積みとなっている仕事の量が減るわけでもないし、期限が延びるわけでもない。誰かが代わりにやってくれるものでもないのだ。今日早く帰ったところで明日以降の仕事が増えるだけだし、そもそも明日が期限の作業もある。「定時退社日」は作業計画を狂わせるだけのうっとうしいものにすぎない、と考える社員が私の周囲には多かった。

　突き詰めれば、ベンダー社員の仕事量や心理的な負担を増やすのは、ユーザー企業、あるいはユーザー企業との約束事である。無論、プロジェクトマネジャーは各メンバーの作業効率や各種の事情を考慮して仕事を割り振るし、管理職は苦しいプロジェクトに追加の要員を投入するなどはできる。しかし、それらが社員の負担を減らすことには限界がある。結局は仕事の量が期限に対して多過ぎることが、社員の心身の疲労や過労の原因となっている。

　しかしユーザー企業には、ベンダーの社員がどの程度の負担を負っているのかは分からないし、責任もない。「いつまでにこれだけの作業をやってほしい、作ってほしい」と要望し、ベンダーが受ければ、ベンダー社員の作業量や負担についてはベンダーに任せるのが現状である。

　そうなると、時間的、あるいは技術的に無理のある仕事を引き受けたベンダーが責任を負うべきともいえるが、ITの開発というものはベンダーにとっても予測のつきにくいものである。想定よりも作業量が多かった、技術的に難しかったとして技術者たちに想定外の長時間労働をさせざるを得ない事態は避けられない。

　無論、そうしたことを恐れてベンダーが開発の受注を抑えれば経営が成り立たない。今回のような技術者の過労死には、ベンダーの管理職だけでは解決できない、構造的といってもいい問題が内在していると私は思う。

ベンダーとユーザー企業は、労務管理の意味でも1チームとなるべき

　大切なのは、社員の健全な作業のために、ITベンダーがいかにユーザー企業の協力を取り付けられるかという問題だ。この辺りはユーザー企業にもある種のマインドチェンジが必要である。ユーザー企業もベンダーの社員に対して、自社の社員と同じく過度な負担を制限したり、心身の健康を気遣ったりすることが必要となる。

　「客の立場でそんなことまで気にするのか？」とお考えの方もいるだろう。しかし、ベンダーの社員がパフォーマンスを落とせば、それは開発プロジェクトの危機であり、ユーザー企業の業務や経営にも悪影響を及ぼす。その意味ではユーザー企業もベンダーの社員の作業には気を使わざるを得ないはずである。

　考えてみれば、ユーザー企業とベンダーはお金のやりとりを除けば、同じ目的の下で共に汗をかく“仲間”である。ベンダー社員の作業がタイトであれば、ユーザー企業が一部作業を手伝うことが必要になるかもしれないし、場合によっては要件やスケジュールの変更にも応じなければならない。

　もちろん金銭的な補償なども必要かもしれないが、それは別に話し合うとして、プロジェクトを成功させる、あるいはセカンドベストに持っていくためには、そうした歩み寄りが必要だ。そうしなければ、誰も満足しない結果に終わってしまう。

　ベンダーの管理職に役割があるとするなら、よくよくユーザー企業と話し合い、依頼することはすべきということであろう。ユーザー企業サイドには迷惑かもしれないが、本事件のように死者まで出す事態となったプロジェクトは、ユーザー企業サイドにも大きな悔恨や後悔が残るはずである。今後開発を請け負ってくれるベンダーがなくなってしまう可能性すらある。

　繰り返すが、ベンダー社員の疲労、病気そして死亡といった悲劇は、ベンダーの管理職の努力だけでどうこうなる問題ではない。構造的な問題である。システムを作るということは、良いチームを維持することと同義であり、そのチームにはベンダーもユーザー企業も関係なく、1つの目的を持った仲間が集まっているはずである。

細川義洋

ITプロセスコンサルタント。元・政府CIO補佐官、東京地方裁判所民事調停委員・IT専門委員、東京高等裁判所IT専門委員

NECソフト（現NECソリューションイノベータ）にて金融機関の勘定系システム開発など多くのITプロジェクトに携わる。その後、日本アイ・ビー・エムにて、システム開発・運用の品質向上を中心に、多くのITベンダーと発注者企業に対するプロセス改善とプロジェクトマネジメントのコンサルティング業務を担当。

独立後は、プロセス改善やIT紛争の防止に向けたコンサルティングを行う一方、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を担当する。これまでかかわったプロジェクトは70以上。調停委員時代、トラブルを裁判に発展させず解決に導いた確率は9割を超える。システム開発に潜む地雷を知り尽くした「トラブル解決請負人」。

2016年より政府CIO補佐官に抜てきされ、政府系機関システムのアドバイザー業務に携わった

個人サイト：CNI IT Advisory LLC