「パワハラされてリストラされたので、転職サイトに書き込んでやりました」の追い解説：「訴えてやる！」の前に読む IT訴訟 徹底解説（104）（1/2 ページ） 連載目次 2023年、あけましておめでとうございます。 おかげさまでこの連載も旧年中に100回を超え、読者の皆さまへの感謝の念に耐えない。新年を迎えこの連載が長く続けられるよう、筆者としても精進を欠かさぬよう決意を新たにしているところである。 本連載はそもそも、ITに関わる裁判が実は反面教師として実際の現場に有効な知見を与えてくれるのでは、と思い立って始めたものである。以来、途中で投げ出したくなるとか参考になる裁判例に困るとかいったことは一切なかった。しかし、書き続けるには、それなりに“元気”が必要なことも確かだった。 筆者に元気を与えてくれるのは、やはり読者の皆さまからの反応やコメントである。編集担当に送られるコメントや指摘は筆者で

EnterpriseZine（エンタープライズジン）編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

EnterpriseZine（エンタープライズジン）編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

公正取引委員会は6月29日、ソフトウェア関連企業の下請取引などに関する実態調査報告書を公開した。資本金3億円以下のソフトウェア関連企業2万1000社を対象にアンケート調査などを行ったところ、違反行為が多重下請け構造によって連鎖していることを確認したという。そのため、多重下請構造の下で生じる問題への対応を強化する方針を示した。 下請代金を巡っては、エンドユーザーや上流発注者からの買いたたきや減額、支払遅延などの違反行為を確認。ソフト開発の取引では「使いやすい機能」などのオーダーが発注者ごとに異なり、当事者間の共通認識を形成しづらい。そのため不当な給付内容の変更、やり直しなどが起こっている。これらの行為が業界の多重下請構造によって、サプライチェーン上で連鎖していたと分かった。

関係者が増え、複雑化するシステム開発の現場 昨今、システムの導入においてクラウドサービスやソフトウェアの利用が主流となり、プロジェクトに関わる人物の数も増えてきました。昔であれば、発注者であるユーザーと、プログラム開発を担当するシステムエンジニアやプログラマー、それにハードウェアを提供するハードウェアベンダーなどが、それぞれ責任を分担をして取り組んでいました。 それぞれの責任も、要件の不備ならユーザー、ソフトウェアの欠陥ならシステムエンジニア、プログラマー、機械の故障ならハードウェアベンダーというように、責任の所在がはっきりしていました。しかし今は、それらステークホルダーに加えて、クラウドベンダーやパッケージソフトウェアベンダーがそれぞれ複数社参加する場合もあります。そして何かの不具合が発生した場合、その責任を技術面、契約面、法律面等で切り分けるのが非常に複雑になってきています。 関与して

業務をパッケージに合わせると言ったけど、めんどくさいからやっぱりやめた：「訴えてやる！」の前に読む IT訴訟 徹底解説（99）（1/3 ページ） 連載目次 システム開発契約に大切なのは、「要件」と「目的」と……？ システム開発契約において、その中核をなすものは言うまでもなく、システムにどのような機能や性能などを具備するかという「要件」であろう。受注者であるベンダーは、この要件を実現することで代金を支払ってもらえる。つまり要件は契約上の「債務」の中核であり、いくら欠陥のないシステムを納品しても、要件を満たさないシステムは「債務の不履行」となり、費用の支払いを得られないばかりか、場合によっては損害賠償の請求までされてしまう。 もっとも、ここでいう「要件」とは、要件定義書に明記されたものだけを指すわけではない。たとえ文書化されておらず要件として定義されていなくても、システム開発契約の目的に照らし

連載：Q＆A　社労士に聞く、現場のギモン 働き方に対する現場の疑問を、社労士がQ＆A形式で回答します。回答を見るには、会員登録が必要です。「ITmediaビジネスオンライン 総務・人事通信」と合わせてお読みください。 Q：　当社はコンピュータ関連企業を営んでおり、いわゆるシステムエンジニア（SE）の業務を行う従業員がいます。SEであれば残業代の支払いが不要となる制度があると聞いたことがあるのですが、そのような制度はあるのでしょうか？ 関連記事 幹部候補か、“万年ヒラ”か　キャリアの分かれ目「30代以降の配置」を、人事はどう決めている？ 「育成」の観点から異動配置させる20代が過ぎると、多くの企業は「幹部候補の優秀人材」と「それ以外」の社員を選別します。人事は、そうした異動配置をどのように決めているのでしょうか。年代層別の異動配置のロジックをみていきます。 「優秀でも残念でもない、普通社員」

裁判結果が話題　「会社に貢献できない人はクビ」と主張する外資企業のウソ・ホント：裁判から「解雇」の誤解を紐解く（1/5 ページ） これまで、わが国の雇用慣行においてまことしやかに語られていた俗説がある。それは、 「日本企業は、給料は安いが、クビにはならない」 「外資系企業は、高給が得られるが、あっさりクビになる」 というものだ。 しかし、外資系企業といえども日本国内で営業している以上、安易な解雇を禁止している日本の労働基準法が適用されるはず。なのに「外資系はクビになりやすい」というのは、よく考えたらおかしなことだ。「外資系企業は治外法権なのか」と疑問に思われたことがある方も多いかもしれない。 この「外資系企業に日本の労働法は適用されるのか問題」について明確な判断を示す判決が2021年12月、東京地裁においてなされた。結論は「外資系といえども安易なクビは無効である」というもの。この判決にまつ

意外と難しい著作権侵害の判断 今回は久しぶりにプログラムの著作権の問題についてお話をしたいと思います。 当たり前のことですが、誰かが作ったプログラムをコピーして自分自身のプログラムに加えてしまうことは、簡単にできます。 実際、昨今の開発はGit-Hubのようなインターネット上の公開サイトからプログラムをダウンロードし、そのプログラムを改造して作ることが、むしろ主流になっています。そして過去に、あるお客さんに向けて作ったプログラムを、別のお客さん向けに作るプログラムに利用したりなども当たり前に行われています。 むしろそうしたことがすべて禁止されたら、開発にかかる期間や工数は何倍にも何十倍にもなってしまう可能性があります。今の時代、プログラムのコピーはソフトウェア開発における必須作業と言ってもよいでしょう。 では、プログラムを誰もが勝手にコピーをして使ってよいのかといえば、もちろんそんなことは

請負契約と準委任契約 今回はシステム開発でよく見られる「請負契約のような準委任契約」について取り上げます。 この連載の読者の方であれば、この二つの契約の違いについては、もう十分にご存知かもしれませんが、請負契約というのは、なんらかの成果物（目的物）を約束した納期どおりに作成したり、提供したりすることを“請け負う”ことです。 請負人（ソフトウェア開発では多くの場合ITベンダー側）は、期日通りに約束した品質をともなう成果物を完成させて納品する必要がある契約です。 一方の準委任契約は、本来なら発注者がやるべきことを、専門家である受注者が代わりにやってあげるというイメージに近いでしょう。同じように情報システムを作っていたとしても、受注者に求められるのは、専門的な技量を十分に発揮して、真摯に作業を行うことであり、多くの場合は働いた時間に応じて支払いがなされ、原則的には請負にあるような“約束した品質を

お任せしたのですから、契約の範囲外でも対応してください：「訴えてやる！」の前に読む IT訴訟 徹底解説（90）（1/2 ページ） ユーザーが持ち込んだソフトウェアにセキュリティの不備があった。「知らんがな」と言いたいところだが、訴えられてしまったら仕方がない。戦いましょう！ 連載目次 ソフトウェアの開発契約には時々、ポテンヒットのような抜け漏れがある。発注者と受注者の役割分担を考える際に一通りの作業を網羅したのに、データ移行やテストデータの作成などをどちらが行うのか判然とせずにもめてしまい、結果、紛争にまでなってしまう例が実は珍しくない。 今回取り上げるのも、セキュリティに関するポテンヒットの例だ。発注者が第三者と契約をして提供を受けたソフトウェアにセキュリティ上の不備があった。受注者はその設定とインストールを請け負ってはいたが、当然、ソフトウェアそのものの品質やセキュリティには責任がない

連載目次 納品したシステムにSQLインジェクションなどの既によく知られた脆弱（ぜいじゃく）性がある場合、たとえその対応策が要件として定義されていなくても、ITの専門家であるベンダーには、そのことに気付き、ユーザー企業に注意喚起し、提案する責任がある。この問題を「ユーザーvs.ベンダー」という構図で見た場合の裁判所の考え方は、これまでの例を見る限り、ある程度の一致を見ているようにも思われる。 同じ問題を「ベンダーという企業vs.そこで働くエンジニアという個人」という図式で見た場合はどうだろうか。顧客に納品したシステムにセキュリティ上の不備があった場合、その責任はシステムを構築したエンジニアにあるのか、そのエンジニアを選任し、作業を監督する責任のあるベンダーにあるのか。 不備の責任は企業と従業員のどちらが取るべきか？ 「従業員は会社内部で責められることはあっても、対外的には会社が責任を持つべき

私が決めた要件通りにシステムを作ってもらいましたが、使えないので訴えます：「訴えてやる！」の前に読む IT訴訟 徹底解説（88）（1/5 ページ） 連載目次 この連載を始めて、7年になる。長くご愛読いただいている読者の皆さまに感謝の念が絶えない。このように長くIT紛争を見続けていると、同じような問題、同じような言葉に何度となくぶつかることがある。街中にある主要な交差点のように、気が付くとその場に立っていて「さて今日はどの方向へ曲がればいいか」と考える場所。そんな言葉である。 「契約の目的とシステムの要件」――IT紛争の勉強や著述などをしていると、いつもこの言葉にぶつかる。「定義されていない要件であっても、それなしには契約の目的を達成できないものであれば、事実上定義されていたと考えなければならない」「たとえ要件通りでも、契約の目的に資することのないシステムを作れば、債務不履行に問われる危険も

増えてきたベンチャー企業への発注 最近のシステム開発は、様々なクラウドサービスやツール類を駆使することで工数を圧縮して行うことが可能になりました。以前なら一つの画面を作り上げるのに丸一ヵ月かかっていたものが、テストまで含めても数十分で終わってしまうなどというケースも少なくありません。 昔は千行程度のプログラムを一行一行書き足し、一つひとつの条件分岐や設定毎に単体テストを行っていました。現在は最初からある程度できあがっている画面の設定を変え、部分的にスクリプトを加えたものを自動テストツールなどで、サラッとテストをすれば、実際の業務に使えるものができてくるわけですから随分と便利になったものです。 そこまで簡単ではなくても、やはりシステム開発においてコードを書く量は随分と減ってきました。それと比例するように、開発の委託先も大手のベンダーではなく、ほんの数名で運営するベンチャー企業や、個人となるケ

悪いのはベンダー！　「わび状」という証拠もあります！：「訴えてやる！」の前に読む IT訴訟 徹底解説（87）（1/4 ページ） ユーザー企業が契約範囲外の作業を行わせたり、不合理な方針変更をしたりして頓挫したプロジェクト。だがユーザー企業は、責任はベンダーにあるとして、20億円の支払いを要求した。 連載目次 この度は、弊社のプロジェクト管理および品質保証の不備により、システム開発の進捗（しんちょく）が著しく遅延していること、誠に申し訳なく、心より謝罪を申し上げます。今後は体制の見直し強化、メンバーへの教育の徹底を行い、お客さまにご迷惑をおかけすることのないよう責任をもって対応させていただきますので…… 皆さんは、ベンダーがユーザーに出すこうした文章を目にしたこと、あるいは自分で書いたことはあるだろうか。進捗が著しく遅れたり、ソフトウェアに重大な欠陥があったり、作業に大きなミスがあったりした

不合格通知をもらわなかったから、検収合格ですよね：「訴えてやる！」の前に読む IT訴訟 徹底解説（86）（1/3 ページ） 納品物のデキが悪いからと発注者が検収を放棄。合否が伝えられないまま「みなし検収」の期間を過ぎたシステムの開発費用を、ベンダーは支払ってもらえるのか――？ 連載目次 IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回は、以前取り上げた判例を、別の争点から論じる。今回のテーマは「みなし検収」だ。 みなし検収とは、「納品された成果物を、検収すべき発注者が、何らかの理由で行わず検収期間を過ぎてしまった場合、自動的に検収に合格したと見なし、発注者に支払いの義務が生じる」ものである。 請負契約において、発注者が正当な理由なく成果物の受け取りを拒んだり、検収を行わなかったりすることは原則として許されない。みなし検収は、発注者が意図的にこうした行為を行って受注者が

連載目次 IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回は、今やソフトウェア業界においては、当たり前のように行われるようになった「裁量労働制」にまつわる紛争事例を取り上げる。 裁量労働制とは、労働時間が労働者の裁量に委ねられている労働契約である。 社員は約束した価値を創出すれば1日8時間（※）働く必要はなく、自らの裁量で実際に働く時間を決められる。約束しただけの価値とは、営業職ならば売上高かもしれないし、システムエンジニアならば予定された分量の設計や分析ドキュメントかもしれない。 とにかく「期日まで」に「しかるべき品質の成果物」を「しかるべき量」アウトプットすればよく、効率良く作業をすれば1日の労働が4時間であっても構わないということになる。労働者にとっては、効率良く作業をすれば、時間的にも体力的にもメリットが出る制度ではある。 ※1日8時間：法定時間（1日8時間、

「なんとか商談を成立させたい……」営業職の焦り 私はかつてITベンダーの営業職に従事していた経験があります。当時はまだWindowsやインターネットが世に知られるようになったばかりで、こうした新しい技術を利用したシステムのセールスには、ある程度技術的な知見のある人間も必要でした。 それまで属していたシステム開発部門から、営業部門に異動させられてのことでしたが、実際にやってみると、営業職はなかなか苦労も多く、顧客企業に財布のヒモを緩めてもらう難しさに悩む日々を過ごしました。 正確に顧客企業の課題を把握し、それを解決するシステムや技術を検討し、顧客企業側の担当者の中から正しい相手を見つけて説得する。価格については社内外に様々な依頼と交渉をしてなんとか引き下げてもらい、ようやく見積もりを出せる。そこまでして正しいシステムの提案をしても、顧客企業の財務状態が悪ければ商談は成立しませんし、うまくいき

ユーザが協力義務を果たすためには IT開発プロジェクトが序盤から遅れに遅れて、結局、完成しなかった。その原因は、ユーザがシステムの構想や要件をまとめきれなかったことにあるのですが、それはユーザの協力義務違反でしょうか。それとも、それをうまくリードできなかったベンダのプロジェクト管理責任でしょうか。 今回はそのポイントを考えるとともに、そもそもユーザが協力義務を果たすためには、何をしておくのが良いのか。それについて私なりの考えも、お話したいと思います。まずは事件の概要から見ていくことにしましょう。 要件の取りまとめが遅れて破綻したプロジェクト （東京高等裁判所 令和2年1月16日判決より） あるユーザが自社の新基幹システム（問題となったのは、顧客管理，請求・入金管理，決済管理，店舗管理等）の開発をITベンダに委託した。しかし、プロジェクトはユーザによるシステムの構想が途中で変わったこと、画面

Q. 会社（上司）とのトラブルで先月に退職しました。その後、担当していた業務のことで連絡が2回ありました。もう会社に関わりたくありません。連絡先を含め勤務時の社員情報を全て削除するように会社にクレームを入れましたがとりあってくれません。 連絡しないでほしいというクレームは正論です。質問者はトラブル退職なのでよけいに腹が立つのでしょう。退職者に在職時の業務のことで連絡するのはいただけません。引き継ぎは在職中に行っておくべきです。 一方で、質問者も社員情報の削除については一定の譲歩が必要です。退職者を含め社員の情報はデータや書類で会社内のサーバや書庫に保管されています。結論から言えば労働基準法や税法などで保存が義務付けられている情報については、退職者が要求しても削除できません。 社員に関する書類の保存期間は 社員情報には、氏名・住所・生年月日などの基本的な情報以外にも多々あります。例えば、勤怠