私はなぜ、部下を退職に追い込んでしまったのか：準委任かつ請負かつ派遣な契約（1/3 ページ）

ワタシには無理でした――つらいひとことを残して去っていった女性エンジニア。IT“業界”解説シリーズ、第8弾は準委任の仮面をかぶった請負かつ派遣な契約で部下を退職に追い込んでしまった男の悔恨の告白です。

[ITプロセスコンサルタント 細川義洋，＠IT]

　複雑怪奇なIT“業界”を解説する本連載、第1弾はIT業界にまん延する多重下請け構造と偽装請負について、第2弾は多重下請け構造が起こる仕組みについて、第3弾はシステム開発プロジェクトには複数の契約形態が混在することを、第4弾はユーザーはなぜプロジェクトに協力したらがらないのか、第5弾は「案件ガチャ」が起こるメカニズム、第6弾はベンダーの営業が安請け合いする理由、第7弾ではエンジニアの年収が上がらない理由を説明しました。

　今回は、IT訴訟解説でもおなじみの細川氏が、請負契約と準委任契約の違いを解説する。若かりし日の反省も込めて――。

ジュンイニンって何ですか？

　準委任契約なのに成果物に責任を持ち、完成までエンジニアが拘束される。逆に請負契約なのに、お客さまからの指示に基づいて成果物完成につながらない作業を強いられる。どちらの契約形態をとっても、エンジニアはお客さまの都合の良いように使い倒されるだけ――。

　システム開発プロジェクトの曖昧でお客さまご都合主義の契約は、昨日今日に始まったものではなく、昭和の昔から延々と続き、いまだに解決しない問題です。

　私が請負や準委任という言葉を初めて意識したのは、大手SIerに入社して2年目、平成が始まったばかりのころでした。先輩のプロジェクトマネジャーが商談で、「準委任と請負のどっちにしますか？」とお客さんに問われ、「準委任でお願いします」と答えていたことを覚えています。

　帰り道、「ジュンイニンって何ですか？」と尋ねる私に、先輩は「成果物を定めてそれを納期通りに作るのが請負で、本来はお客さんがやるべき作業を一定期間手伝ってあげるのが準委任。手伝ってあげるっていっても、実質はこっちで全部作るんだけどね」と答えました。

　私が「ということは、契約期間が終わったら、開発途中でも仕事は終わりなんですか？」と聞くと、先輩は「んなワケあるかいな。システムが完成しないとお金はもらえないよ、実際にはね」と答えます。

　「じゃあ請負の方がいいじゃないですか。」とさらに尋ねる私に先輩は「請負は社内処理が面倒なんだよ。プロジェクトの開始が遅れちゃう」と苦笑いを浮かべ、「まあ、その辺の契約形態って結構適当なんだよね」と付け加えました。

IT業界の歴史と共にある「請負」「準委任」問題

　契約は準委任だが実際には請負――こんな形態は当時でも当たり前でしたから、昭和の、恐らくわが国のシステム開発の歴史が始まったころから変わらない問題なのでしょう。

　契約形態が実情と合致していなくても、発注者と受注者にとって公平なものであれば問題はないのかもしれません。名前だけ準委任であっても、きちんとした成果物を納めさえすれば、後は何をしようと文句は言われないし、余計な仕事を押し付けられることもない。お客さまからの作業指示や勤怠管理もされずに、とにかく納期通りにモノができれば構わない。そうした契約なら、むしろ契約の呼び方など、どうでもいいことかもしれません。

　しかし実際は、こうした曖昧な契約は発注者に都合の良い方に実態が捻じ曲げられることが多く、準委任のように時間を縛られ派遣のように発注者が作業指示をするのに、請負のように成果物の責任を負わされて、モノが出来上がるまで受注者のエンジニアは解放されない。そんなプロジェクトが多々見られます。

　この問題の厄介なところは、それでもプロジェクトが無事に済んでしまえば、問題が明るみに出ないどころか、当事者たちが問題を意識せずに終わってしまう点です。予定された工数で、まあまあの品質のモノができてしまえば、「準委任なのに追加料金なしで残業して不具合対応なんておかしいじゃないか！」とクレームを付けたところで、発注者はもちろん受注側でさえ、「何をいまさら」と問題提起を歯牙にもかけないでしょう。