不等号の向きを変えるコード書き換えで業務妨害に問われた裁判、無罪判決が出る 93
ストーリー by nagazou
無罪 部門より
無罪 部門より
香川県で勤務先の輸入雑貨販売会社から、商品管理のプログラムを書き換えて業務を妨害したとして2019年10月に逮捕された人物が、初公判から約1年後の今年1月12日に無罪判決を勝ち取った。検察側は控訴しなかったため無罪が確定している（毎日新聞、NHK、東京新聞）。
タレコミによると、この人物は8月2日に商品発送に使う簡易プログラムの保守管理を忘れないように9月1日に停止するようにブログラムを書き換えた。しかし、書き換え後に経営者との関係が悪化、逮捕された人物はプログラムを書き換えた状態のまま休業状態に入ってしまったようだ。その後にシステムが停止してしまったことから、経営者側は業務妨害の意図があった判断し、警察に被害届を出したという流れであった模様。
裁判で裁判官は、ソースコードの不等号の向きを変えてシステムが停止するように処理していただけで、容易に復旧可能な書き換えであったことから「保守管理が目的だった」とする被告の供述は信用できるとした。書き換えは「業務が遅延するとは考えがたく通常業務の範囲内」だったと指摘したとしている。
タレコミによると、この人物は8月2日に商品発送に使う簡易プログラムの保守管理を忘れないように9月1日に停止するようにブログラムを書き換えた。しかし、書き換え後に経営者との関係が悪化、逮捕された人物はプログラムを書き換えた状態のまま休業状態に入ってしまったようだ。その後にシステムが停止してしまったことから、経営者側は業務妨害の意図があった判断し、警察に被害届を出したという流れであった模様。
裁判で裁判官は、ソースコードの不等号の向きを変えてシステムが停止するように処理していただけで、容易に復旧可能な書き換えであったことから「保守管理が目的だった」とする被告の供述は信用できるとした。書き換えは「業務が遅延するとは考えがたく通常業務の範囲内」だったと指摘したとしている。
報道 (スコア:5, 興味深い)
どの報道でも無罪になった被告の名前を報道しているのに、訴えた側の輸入雑貨販売会社名を報道しないんですね
Re: (スコア:0, 興味深い)
報道するなら、無能な検察の名前かな。あと逮捕状を出した裁判官。
２２日も拘留したのな。
Re:報道 (スコア:1)
なぜそこで検察と裁判官が出てくるのだろう。
結果的に無罪だったら検察や逮捕状出した人の方に罪を負わせるべきってことなのか。
それとも検察に何か決定的な落ち度があったということなのか。
Re:報道 (スコア:1)
罪を認めないから，検察は勾留を伸ばして被疑者を追い詰めようとしたんでしょ．それに加担した裁判官．
そろそろ逮捕勾留は当たり前，追い詰めて自白を待つのは当たり前の風潮は止めた方が良い．
# 横から失礼
Re: (スコア:0)
でもゴーンを釈放した裁判官名は報道されてないんだよね。
不等号を「く」に書き換えた (スコア:3)
とかならワンチャンあったかも・・・
# いやね～よ
身につまされる話ではある (スコア:1)
「簡易プログラム」とあるので、手作業でやってたのをマクロで自動化したレベルのものでしょう。
小さい会社だとパソコンの先生的な従業員が自分用ツールとしてこしらえて、知らず知らずのうちに部署全体で使われるようになっていたという話はよくあるものです。
作った本人は自分で作った個人的ツールなので、自分だけがわかるようにメンテナンスしがちなものです。他者に読めるようドキュメントを整備しても、複数人が関与できるようにプロジェクトを管理しても、誰も読んだり触ったりしようとはしないでしょうから無駄だと思うのも無理はありません。
2019年9月といえば翌月に消費税増税が控えているタイミングで、10月になっても表立った異変もないまま消費税8%で計算して売上計上し続けると恐ろしいことになります。本来業務の片手間で改訂作業をするなら、いくらなんでも1ヶ月前には着手してないとマズいわけで、非常ブレーキとして動作が止まる仕掛けを簡易的に仕込んでおきたい気持ちは理解できます。
作った従業員は「自分だけのために独りで作った」と思っていますし、会社は「（導入の経緯ははっきりしないけど）自社業務の一部をなすもの」と大まかにとらえています。
従業員と経営者の関係が悪化するタイミングがこの上なくマズい時期だったことが、本件最大の不幸なのでしょう。
警察はガチで逮捕してしまいましたし、検察官も成績とかメンツ的なものもあって後には引けず正式裁判までたどりついてしまったのでしょうが、時系列を追ったりすると被告の主張に矛盾がないとわかったのでしょう。
大変な話です。
他にやりようなかったのか (スコア:0)
自分宛にチケット切ればいいだけのような。
書き換えたのを単独でコミットすれば細かくコメント付けられるしすぐrevertできる。
github禁止とかいう前にちゃんとリテラシ身に着けようよ。
# だいたい、止まるように書き換えたら気が付くのはなんか問題出た後だろ。
Re:他にやりようなかったのか (スコア:3, 興味深い)
「保守管理を忘れないように停止する」ってのは違和感ある。
5chにこんなのがあった。
・退職前にプログラムを書き換えた
・一定期間が来るとメンテしないと動かなくなる仕様にした
・理由はメンテせずに動き続けるようにするとセキュリティ上危険だからという主張
・退職後にメンテのための費用を会社に請求したが決裂
・一定期間が経ったのでプログラムは動かなくなった
・会社は莫大な損失となった
ググってみたが裏は取れなかった。
Re: (スコア:0)
保守管理のありがたみを忘れないように停止する、の間違いかな。
それなら控訴されても不思議じゃないが。
Re: (スコア:0)
刑事裁判だと無罪に、なんだろうけど。
民事裁判だと損害賠償を食らいそうね。
Re: (スコア:0)
プログラムの書き換えは普通の業務の範囲でやってたといことだから、損賠賠償はあり得ないよ。
Re: (スコア:0)
問題は「・一定期間が来るとメンテしないと動かなくなる仕様にした」の部分だと思う
クライアントが周知している仕様ならいいが、開発者内部だけが知っている仕様だとさすがにアウトじゃね？
＃クライアントがメンテのこと知らないってことは後者のような気がする
Re:他にやりようなかったのか (スコア:1)
通常業務の範囲内だった訳で、意図的じゃないことが確定した。
つまり民事責任は輸入雑貨販売会社が全部被ることになる。
> 裁判で裁判官は、ソースコードの不等号の向きを変えてシステムが停止するように処理していただけで、
> 容易に復旧可能な書き換えであったことから「保守管理が目的だった」とする被告の供述は信用できるとした。
> 書き換えは「業務が遅延するとは考えがたく通常業務の範囲内」だったと指摘したとしている。
Re: (スコア:0)
巫女さんヱ…
Re: (スコア:0)
クライアントが知らないと言っていても仕様上にはしっかり明記されていたりすることも有るから、それだけでは何とも。
Re: (スコア:0)
仮に民事（損賠請求）訴訟を提起していれば、刑事とは違う判断が出ることはありうる。
Re: (スコア:0)
全くないとは言えないが、あまり現実的じゃない気がする。
賠償勝ち取るためには、意図的に業務を妨害したことを証明する必要があるが。
その為には検察が持ってる以上の証拠を集めなきゃならないぞ。
Re: (スコア:0)
モヒカンぶった極論厨がネタで言ってるだけだと思ってたけど
この手のランサム保守って実際どのくらいのあるある案件なんだろ
Re: (スコア:0)
定期的に手動運用が必要で運用手順をその人しか知らない、なんてのまでランサム保守に含めると、
コカ・コーラの自販機くらいありふれてそう
Re: (スコア:0)
ランサム保守ってのも言い過ぎやろ。
メンテしないシステムが危険だというのは正しいし、
商品発送みたいな個人情報を扱うシステムを放置したらとんでもない損害が出る可能性が高いし被害者は顧客。
おれみたいなクズは退職後にどうなろうと知ったことかと思ってしまうが、根がまじめで安全側に倒すことにしたのかもしれない。
もしかするとメンテを請け負う約束してたけど反故にされてこじれた上に訴えられたまで妄想できる。
まーなんにせよ、裁判記録見ないとさっぱりわからんな。
Re: (スコア:0)
停止日は2019年9月1日でしょ？2019年10月1日に消費税が8→10%への改定が有ったから、未対応版を動かないように仕込んでおくのは適切だった可能性が有る。
9月中に上げる案件でも10月発送予定だったら、消費税を10%にしておかないとダメだもの。
8月中～下旬に消費税対応版を配布予定だったなら話はそうおかしくない。
Excel/Accessだと手順書無視して、勝手にコピった古い版をずっと使うおバカさんとか出るから、それで旧消費税で計算したら被害が大きいし。
Re:他にやりようなかったのか (スコア:1)
この行動が単なる間抜けや勤勉な無能によるものか、恋によるものか判別するのが難しいってことじゃね?
Re:他にやりようなかったのか (スコア:2)
「痴情のもつれでプログラムを動かなくした」で何か馬鹿話が1つ作れないか??と云う発想が脳裏に……。
Re:他にやりようなかったのか (スコア:1)
なるほど、そこでスマート貞操帯の話につながるわけですね。
#つながりません
Re:他にやりようなかったのか (スコア:1)
恋は盲目だからな
Re: (スコア:0)
うどん脳によるものかも
Re: (スコア:0)
バージョン管理システムとかバグトラッキングシステムとか使ってなかったんじゃ？
Re: (スコア:0)
なんで使わないの？
・変更は必ずチケットに基づいて行う(自己発行も可)。
・同一のファイルに対する変更でも別のチケットによるものは別コミットにする
このルールを作るだけで恋(ウケたｗ)によるものか経営側にも証拠が残ったのに。
Re:他にやりようなかったのか (スコア:1)
時々いるよね、自分が今与えられてる環境が他のどんな環境でも同様に所与のものであるという前提の人。
そりゃ当然そんな仕組みがあれば証拠になるし、業務分析もできるし、リマインドもできるだろうし、いいこと尽くめですよ。
でも導入もランニングもコスト0ではないし、
開発の組織が小規模だとほとんどの場合そのコストをペイしない(と考える)
単に開発者の怠慢だとしても、「きちんとした開発者に任せる」のは比較したときおそらくコスト増になるわけで。
世の中には人も予算も恐ろしいほど絞られてる開発というのが現に存在してるのですよ。
店頭販売で現金しか扱ってない八百屋にPOSレジ導入すれば管理や分析もできるしキャッシュレス対応もできるのに、
とか言うようなもん。
Re: (スコア:0)
バージョン管理システムやバグトラッキングシステムを管理する手間がかかるからだな。
Re:他にやりようなかったのか (スコア:5, おもしろおかしい)
一人情シスとして意気揚々と転職してまずやったのが、余りもののPCでRedmineとDrupalの構築。
問い合わせや作業メモをきっちり記録。よく見とけこれが一流の情シスの仕事だ。ﾌﾊﾊﾊﾊﾊ。
1年経たずに更新しなくなった。そして昼間からスラドｗ
Re: (スコア:0)
でも、そうしなかったから業務に損害が出て、裁判なんて非常に手間のかかることをやらなきゃいけないはめになったんだよね？
そこの因果が結びついてないことろが日本のITが遅れてる理由だと思うよ。
ちなみに、githubならただで全部ある。
Re:他にやりようなかったのか (スコア:1)
SMBCのコード流出でも湧いてたけど、
問題を観測してから事後に神の視点で「こうしておけばよかったのに」っていうのって誰にでもできて良い気持ちになれるエンターテイメントなんだな。
似たような状況の開発PJなんか世界中にごまんとあるから、そういう仕組の導入でコンサルするよって売り込みにいきなよ。
1000円で諸々の環境構築とサポートやってくれるならお願いしますって言ってくれるとこはあるかもしれない。
Re: (スコア:0)
そういうことを裁判するハメになった社長さんに言ってあげて
Re: (スコア:0)
コミット時刻が定時内になるようにしないといけないから大変なんだよ！
Re: (スコア:0)
おそらくこの人しかコード触れないんでしょ。
本人が必要ないと思えば使う必要もない。
他の人はそんなの知ったこっちゃないし。動くものさえ作ってもらえれば。
コード見ても直せない人ばっかりだろうし、バージョン管理の意味や存在も知らないはず。
Re: (スコア:0)
「簡易プログラム」ってことはExcelのVBA程度だったかもしれませんね。
１人だけちょっとVBA書ける程度とか、小さな会社ではありそうな話。
Re: (スコア:0)
「管理職が使い方を分からない」という組織はあったよ。
ちゃんと細かく報告書いてあるのに、読めない、読んでも意味が分からないだもの。
チケットを作成したりプロジェクトを管理するなんて夢のまた夢。
「そんな上司がいるわけないでしょ？」と言いたくなる気持ちも分かるが本当にいたんだ。
そういう上司なら、導入には徹底的に反対するかもね。
導入したら自分の無能が白日の下にさらされるんだもの。
Re: (スコア:0)
それとコレとは話が別なような。
時として他の仕事をぶっ込まれて謀殺されることもあるようなクソ組織ならば、
チケットを確認して修正する前にそのX-DAYが来てシステムのデータが間違った
まま上書きされて復旧困難になる場合もあるし。
「忘れなければ良い」というのは、「バグを出さなければデバッグ不要」みたいな話で、
机上の空論。「忘れないように注意しましょう」と心がけるのはあまり賢くなくて、
より良いのは忘れても問題が起きない仕組みを作りこむこと。
たしかに決してエレガントなやり方ではないけどね。
そしてもし業務妨害が目的なら、商品の在庫を「水増しする」とか、
「数字をランダムに書き換える」とかの方が怖いんだよなあ。
「Excelファイルの数値を少しずつ書き換えるウイルス」というのも昔聞いたことがあるような。
コードを読まないとなんとも言えない (スコア:0)
ので読みたいのだけれど、高松地裁に行けば読めるのかな？
Re: (スコア:0)
ほんとそれ。
「商品発送に使う簡易プログラム」が我々の思うようなプログラムなのかというレベルで気になる。
ExcelマクロならまだしもExcelの数式とかの可能性もありそう。
Re: (スコア:0)
野次馬の好奇心以上の事由と疑義があるなら開示を申請してみては？
直すのは簡単だけど見つけるのは難しい妨害 (スコア:0)
よくあるバグのひとつがこういう不等号のミスだよね。
挙動によっては発見簡単だけどなかなか見つからないことの方が多い。
コメント書いていたかなどにもよるけど一か月も経ったら「あれはどこだったっけ？」なんてなるかもしれないし。
＃止めるだけならassert(false)みたいなのやメッセージボックス程度がいい。
コードの問題ではないかも (スコア:0)
なんか話を聞いてると一人開発的な状況の感じがあるし、この経営者もこの開発者の感覚がよく分かってなさそう。
情報共有は開発者にも責務があるけど、全部ひっくるめた責務が最終的に帰るのは経営者であって、
活動が止まる前に何らかの手を打つ役割は会社組織上はより上位の裁量を持つ者が務める必要がある。
その意味でこの事故の事件性は軽微に見積もられるように見える。経営者としてもっとやる事あったんじゃないかっていう。
Re: (スコア:0)
止まる処理入れずに9月からも保守されない状態で使ってたら正常に発送業務が回ったのか気になる。
Re: (スコア:0)
そのうち動かなくなって、結局訴えられることになりそう…。
Re: (スコア:0)
消費税8%のままで誤請求やらかしてた可能性がありそう。
意図的に属人性をどうみるか (スコア:0)
プログラマーだけで話すならありだとは思います。
ただ経営者や一般従業員からすると
UIとしてメニューで判別/操作ができないことに
理解不能の非合理性を感じてしまうのではないでしょうか
プログラマーからすると難癖ですが
組織としてみると意図的な属人性による妨害
と認識してしまうのも致し方ないかと
・判断が必要なら判断に必要なチェックリストUIを作る
・チェックリストがオールクリアなら実行ボタンを押せるように成る
・標準時期で実行が必要になるなら前日にはアラートが表示される
等々
ソースを解読して弄らなくてもいいように
システムを構築できなくもない
というか
現代ならそうすべきかと
そういう意味では
業務妨害ではないが
業務怠慢もしくは適正技能がない
という線で攻めれば
結果は変わったかもしれません
まぁこういうケースは大にして
判断に必要なチェックリストがどんぶり勘定だったりする
ってのが原因かと思われます
その原因が
被告だった方なのか
被告に申し送りできる能力のない原告側だったのか
審議すべきは本来そこじゃないのか
って感じてしまいますね
適正な業務を主題とせずに
感情論を主題としたら
経営者側に勝ち目はないでしょう
社会的な資本/利権の圧力でもない限り
# まぁその判断をできない原告側だからこんな事になってるんだろうけれど
Re: (スコア:0)
ソース書き換えたあとに関係が悪くなったというところから、
経営者が「システム改修おわったからあんた用無しね。継続メンテナンスとか不要」と言い出して仕様書も報告書も見出し以外なにも読んでいないに１ペリカ