パスワードを忘れた? アカウント作成
15163625 story
法廷

不等号の向きを変えるコード書き換えで業務妨害に問われた裁判、無罪判決が出る 93

ストーリー by nagazou
無罪 部門より
香川県で勤務先の輸入雑貨販売会社から、商品管理のプログラムを書き換えて業務を妨害したとして2019年10月に逮捕された人物が、初公判から約1年後の今年1月12日に無罪判決を勝ち取った。検察側は控訴しなかったため無罪が確定している(毎日新聞NHK東京新聞)。

タレコミによると、この人物は8月2日に商品発送に使う簡易プログラムの保守管理を忘れないように9月1日に停止するようにブログラムを書き換えた。しかし、書き換え後に経営者との関係が悪化、逮捕された人物はプログラムを書き換えた状態のまま休業状態に入ってしまったようだ。その後にシステムが停止してしまったことから、経営者側は業務妨害の意図があった判断し、警察に被害届を出したという流れであった模様。

裁判で裁判官は、ソースコードの不等号の向きを変えてシステムが停止するように処理していただけで、容易に復旧可能な書き換えであったことから「保守管理が目的だった」とする被告の供述は信用できるとした。書き換えは「業務が遅延するとは考えがたく通常業務の範囲内」だったと指摘したとしている。
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 報道 (スコア:5, 興味深い)

    by Anonymous Coward on 2021年02月04日 8時37分 (#3971959)

    どの報道でも無罪になった被告の名前を報道しているのに、訴えた側の輸入雑貨販売会社名を報道しないんですね

    • Re: (スコア:0, 興味深い)

      by Anonymous Coward

      報道するなら、無能な検察の名前かな。あと逮捕状を出した裁判官。
      22日も拘留したのな。

      • by Anonymous Coward on 2021年02月04日 11時07分 (#3972061)

        なぜそこで検察と裁判官が出てくるのだろう。
        結果的に無罪だったら検察や逮捕状出した人の方に罪を負わせるべきってことなのか。
        それとも検察に何か決定的な落ち度があったということなのか。

        親コメント
        • by Anonymous Coward on 2021年02月04日 11時20分 (#3972066)

          罪を認めないから,検察は勾留を伸ばして被疑者を追い詰めようとしたんでしょ.それに加担した裁判官.

          そろそろ逮捕勾留は当たり前,追い詰めて自白を待つのは当たり前の風潮は止めた方が良い.

          # 横から失礼

          親コメント
          • by Anonymous Coward

            でもゴーンを釈放した裁判官名は報道されてないんだよね。

  • とかならワンチャンあったかも・・・

    # いやね~よ

  • 「簡易プログラム」とあるので、手作業でやってたのをマクロで自動化したレベルのものでしょう。
    小さい会社だとパソコンの先生的な従業員が自分用ツールとしてこしらえて、知らず知らずのうちに部署全体で使われるようになっていたという話はよくあるものです。

    作った本人は自分で作った個人的ツールなので、自分だけがわかるようにメンテナンスしがちなものです。他者に読めるようドキュメントを整備しても、複数人が関与できるようにプロジェクトを管理しても、誰も読んだり触ったりしようとはしないでしょうから無駄だと思うのも無理はありません。
    2019年9月といえば翌月に消費税増税が控えているタイミングで、10月になっても表立った異変もないまま消費税8%で計算して売上計上し続けると恐ろしいことになります。本来業務の片手間で改訂作業をするなら、いくらなんでも1ヶ月前には着手してないとマズいわけで、非常ブレーキとして動作が止まる仕掛けを簡易的に仕込んでおきたい気持ちは理解できます。

    作った従業員は「自分だけのために独りで作った」と思っていますし、会社は「(導入の経緯ははっきりしないけど)自社業務の一部をなすもの」と大まかにとらえています。
    従業員と経営者の関係が悪化するタイミングがこの上なくマズい時期だったことが、本件最大の不幸なのでしょう。

    警察はガチで逮捕してしまいましたし、検察官も成績とかメンツ的なものもあって後には引けず正式裁判までたどりついてしまったのでしょうが、時系列を追ったりすると被告の主張に矛盾がないとわかったのでしょう。
    大変な話です。

  • by Anonymous Coward on 2021年02月04日 8時33分 (#3971956)

    自分宛にチケット切ればいいだけのような。
    書き換えたのを単独でコミットすれば細かくコメント付けられるしすぐrevertできる。
    github禁止とかいう前にちゃんとリテラシ身に着けようよ。
    # だいたい、止まるように書き換えたら気が付くのはなんか問題出た後だろ。

    • by Anonymous Coward on 2021年02月04日 8時41分 (#3971962)

      「保守管理を忘れないように停止する」ってのは違和感ある。

      5chにこんなのがあった。

      ・退職前にプログラムを書き換えた
      ・一定期間が来るとメンテしないと動かなくなる仕様にした
      ・理由はメンテせずに動き続けるようにするとセキュリティ上危険だからという主張
      ・退職後にメンテのための費用を会社に請求したが決裂
      ・一定期間が経ったのでプログラムは動かなくなった
      ・会社は莫大な損失となった

      ググってみたが裏は取れなかった。

      親コメント
      • by Anonymous Coward

        保守管理のありがたみを忘れないように停止する、の間違いかな。
        それなら控訴されても不思議じゃないが。

      • by Anonymous Coward

        刑事裁判だと無罪に、なんだろうけど。
        民事裁判だと損害賠償を食らいそうね。

        • by Anonymous Coward

          プログラムの書き換えは普通の業務の範囲でやってたといことだから、損賠賠償はあり得ないよ。

          • by Anonymous Coward

            問題は「・一定期間が来るとメンテしないと動かなくなる仕様にした」の部分だと思う
            クライアントが周知している仕様ならいいが、開発者内部だけが知っている仕様だとさすがにアウトじゃね?
            #クライアントがメンテのこと知らないってことは後者のような気がする

            • by Anonymous Coward on 2021年02月04日 10時30分 (#3972033)

              通常業務の範囲内だった訳で、意図的じゃないことが確定した。
              つまり民事責任は輸入雑貨販売会社が全部被ることになる。

              > 裁判で裁判官は、ソースコードの不等号の向きを変えてシステムが停止するように処理していただけで、
              > 容易に復旧可能な書き換えであったことから「保守管理が目的だった」とする被告の供述は信用できるとした。
              > 書き換えは「業務が遅延するとは考えがたく通常業務の範囲内」だったと指摘したとしている。

              親コメント
            • by Anonymous Coward

              巫女さんヱ…

            • by Anonymous Coward

              クライアントが知らないと言っていても仕様上にはしっかり明記されていたりすることも有るから、それだけでは何とも。

          • by Anonymous Coward

            仮に民事(損賠請求)訴訟を提起していれば、刑事とは違う判断が出ることはありうる。

            • by Anonymous Coward

              全くないとは言えないが、あまり現実的じゃない気がする。
              賠償勝ち取るためには、意図的に業務を妨害したことを証明する必要があるが。
              その為には検察が持ってる以上の証拠を集めなきゃならないぞ。

      • by Anonymous Coward

        モヒカンぶった極論厨がネタで言ってるだけだと思ってたけど
        この手のランサム保守って実際どのくらいのあるある案件なんだろ

        • by Anonymous Coward

          定期的に手動運用が必要で運用手順をその人しか知らない、なんてのまでランサム保守に含めると、
          コカ・コーラの自販機くらいありふれてそう

        • by Anonymous Coward

          ランサム保守ってのも言い過ぎやろ。

          メンテしないシステムが危険だというのは正しいし、
          商品発送みたいな個人情報を扱うシステムを放置したらとんでもない損害が出る可能性が高いし被害者は顧客。
          おれみたいなクズは退職後にどうなろうと知ったことかと思ってしまうが、根がまじめで安全側に倒すことにしたのかもしれない。
          もしかするとメンテを請け負う約束してたけど反故にされてこじれた上に訴えられたまで妄想できる。

          まーなんにせよ、裁判記録見ないとさっぱりわからんな。

          • by Anonymous Coward

            停止日は2019年9月1日でしょ?2019年10月1日に消費税が8→10%への改定が有ったから、未対応版を動かないように仕込んでおくのは適切だった可能性が有る。
            9月中に上げる案件でも10月発送予定だったら、消費税を10%にしておかないとダメだもの。

            8月中~下旬に消費税対応版を配布予定だったなら話はそうおかしくない。
            Excel/Accessだと手順書無視して、勝手にコピった古い版をずっと使うおバカさんとか出るから、それで旧消費税で計算したら被害が大きいし。

    • by Anonymous Coward on 2021年02月04日 8時53分 (#3971971)

      この行動が単なる間抜けや勤勉な無能によるものか、恋によるものか判別するのが難しいってことじゃね?

      親コメント
    • by Anonymous Coward

      バージョン管理システムとかバグトラッキングシステムとか使ってなかったんじゃ?

      • by Anonymous Coward

        なんで使わないの?
        ・変更は必ずチケットに基づいて行う(自己発行も可)。
        ・同一のファイルに対する変更でも別のチケットによるものは別コミットにする
        このルールを作るだけで恋(ウケたw)によるものか経営側にも証拠が残ったのに。

        • by Anonymous Coward on 2021年02月04日 9時35分 (#3972000)

          時々いるよね、自分が今与えられてる環境が他のどんな環境でも同様に所与のものであるという前提の人。

          そりゃ当然そんな仕組みがあれば証拠になるし、業務分析もできるし、リマインドもできるだろうし、いいこと尽くめですよ。
          でも導入もランニングもコスト0ではないし、
          開発の組織が小規模だとほとんどの場合そのコストをペイしない(と考える)
          単に開発者の怠慢だとしても、「きちんとした開発者に任せる」のは比較したときおそらくコスト増になるわけで。

          世の中には人も予算も恐ろしいほど絞られてる開発というのが現に存在してるのですよ。

          店頭販売で現金しか扱ってない八百屋にPOSレジ導入すれば管理や分析もできるしキャッシュレス対応もできるのに、
          とか言うようなもん。

          親コメント
        • by Anonymous Coward

          バージョン管理システムやバグトラッキングシステムを管理する手間がかかるからだな。

          • by Anonymous Coward on 2021年02月04日 10時18分 (#3972025)

            一人情シスとして意気揚々と転職してまずやったのが、余りもののPCでRedmineとDrupalの構築。
            問い合わせや作業メモをきっちり記録。よく見とけこれが一流の情シスの仕事だ。フハハハハハ。

            1年経たずに更新しなくなった。そして昼間からスラドw

            親コメント
          • by Anonymous Coward

            でも、そうしなかったから業務に損害が出て、裁判なんて非常に手間のかかることをやらなきゃいけないはめになったんだよね?
            そこの因果が結びついてないことろが日本のITが遅れてる理由だと思うよ。
            ちなみに、githubならただで全部ある。

            • by Anonymous Coward on 2021年02月04日 12時56分 (#3972139)

              SMBCのコード流出でも湧いてたけど、
              問題を観測してから事後に神の視点で「こうしておけばよかったのに」っていうのって誰にでもできて良い気持ちになれるエンターテイメントなんだな。

              似たような状況の開発PJなんか世界中にごまんとあるから、そういう仕組の導入でコンサルするよって売り込みにいきなよ。
              1000円で諸々の環境構築とサポートやってくれるならお願いしますって言ってくれるとこはあるかもしれない。

              親コメント
            • by Anonymous Coward

              そういうことを裁判するハメになった社長さんに言ってあげて

        • by Anonymous Coward

          コミット時刻が定時内になるようにしないといけないから大変なんだよ!

        • by Anonymous Coward

          おそらくこの人しかコード触れないんでしょ。
          本人が必要ないと思えば使う必要もない。
          他の人はそんなの知ったこっちゃないし。動くものさえ作ってもらえれば。
          コード見ても直せない人ばっかりだろうし、バージョン管理の意味や存在も知らないはず。

          • by Anonymous Coward

            「簡易プログラム」ってことはExcelのVBA程度だったかもしれませんね。
            1人だけちょっとVBA書ける程度とか、小さな会社ではありそうな話。

        • by Anonymous Coward

          「管理職が使い方を分からない」という組織はあったよ。
          ちゃんと細かく報告書いてあるのに、読めない、読んでも意味が分からないだもの。
          チケットを作成したりプロジェクトを管理するなんて夢のまた夢。
          「そんな上司がいるわけないでしょ?」と言いたくなる気持ちも分かるが本当にいたんだ。

          そういう上司なら、導入には徹底的に反対するかもね。
          導入したら自分の無能が白日の下にさらされるんだもの。

    • by Anonymous Coward

      それとコレとは話が別なような。

      時として他の仕事をぶっ込まれて謀殺されることもあるようなクソ組織ならば、
      チケットを確認して修正する前にそのX-DAYが来てシステムのデータが間違った
      まま上書きされて復旧困難になる場合もあるし。

      「忘れなければ良い」というのは、「バグを出さなければデバッグ不要」みたいな話で、
      机上の空論。「忘れないように注意しましょう」と心がけるのはあまり賢くなくて、
      より良いのは忘れても問題が起きない仕組みを作りこむこと。

      たしかに決してエレガントなやり方ではないけどね。

      そしてもし業務妨害が目的なら、商品の在庫を「水増しする」とか、
      「数字をランダムに書き換える」とかの方が怖いんだよなあ。
      「Excelファイルの数値を少しずつ書き換えるウイルス」というのも昔聞いたことがあるような。

  • by Anonymous Coward on 2021年02月04日 9時13分 (#3971984)

    ので読みたいのだけれど、高松地裁に行けば読めるのかな?

    • by Anonymous Coward

      ほんとそれ。
      「商品発送に使う簡易プログラム」が我々の思うようなプログラムなのかというレベルで気になる。
      ExcelマクロならまだしもExcelの数式とかの可能性もありそう。

    • by Anonymous Coward

      野次馬の好奇心以上の事由と疑義があるなら開示を申請してみては?

  • by Anonymous Coward on 2021年02月04日 9時33分 (#3971999)

    よくあるバグのひとつがこういう不等号のミスだよね。
    挙動によっては発見簡単だけどなかなか見つからないことの方が多い。
    コメント書いていたかなどにもよるけど一か月も経ったら「あれはどこだったっけ?」なんてなるかもしれないし。

    #止めるだけならassert(false)みたいなのやメッセージボックス程度がいい。

  • by Anonymous Coward on 2021年02月04日 10時31分 (#3972035)

    なんか話を聞いてると一人開発的な状況の感じがあるし、この経営者もこの開発者の感覚がよく分かってなさそう。
    情報共有は開発者にも責務があるけど、全部ひっくるめた責務が最終的に帰るのは経営者であって、
    活動が止まる前に何らかの手を打つ役割は会社組織上はより上位の裁量を持つ者が務める必要がある。
    その意味でこの事故の事件性は軽微に見積もられるように見える。経営者としてもっとやる事あったんじゃないかっていう。

    • by Anonymous Coward

      止まる処理入れずに9月からも保守されない状態で使ってたら正常に発送業務が回ったのか気になる。

      • by Anonymous Coward

        そのうち動かなくなって、結局訴えられることになりそう…。

      • by Anonymous Coward

        消費税8%のままで誤請求やらかしてた可能性がありそう。

  • by Anonymous Coward on 2021年02月04日 10時52分 (#3972050)

    プログラマーだけで話すならありだとは思います。
    ただ経営者や一般従業員からすると
    UIとしてメニューで判別/操作ができないことに
    理解不能の非合理性を感じてしまうのではないでしょうか

    プログラマーからすると難癖ですが
    組織としてみると意図的な属人性による妨害
    と認識してしまうのも致し方ないかと

    ・判断が必要なら判断に必要なチェックリストUIを作る
    ・チェックリストがオールクリアなら実行ボタンを押せるように成る
    ・標準時期で実行が必要になるなら前日にはアラートが表示される
    等々
    ソースを解読して弄らなくてもいいように
    システムを構築できなくもない
    というか
    現代ならそうすべきかと

    そういう意味では
    業務妨害ではないが
    業務怠慢もしくは適正技能がない
    という線で攻めれば
    結果は変わったかもしれません

    まぁこういうケースは大にして
    判断に必要なチェックリストがどんぶり勘定だったりする
    ってのが原因かと思われます

    その原因が
    被告だった方なのか
    被告に申し送りできる能力のない原告側だったのか
    審議すべきは本来そこじゃないのか
    って感じてしまいますね

    適正な業務を主題とせずに
    感情論を主題としたら
    経営者側に勝ち目はないでしょう
    社会的な資本/利権の圧力でもない限り

    # まぁその判断をできない原告側だからこんな事になってるんだろうけれど

    • by Anonymous Coward

      ソース書き換えたあとに関係が悪くなったというところから、

      経営者が「システム改修おわったからあんた用無しね。継続メンテナンスとか不要」と言い出して仕様書も報告書も見出し以外なにも読んでいないに1ペリカ

typodupeerror

普通のやつらの下を行け -- バッドノウハウ専門家

読み込み中...