Oracle ERP無罪、犯人はExcel職人だった
英国の現場で起きた「給与データが約3分の1ずれる」問題の原因が、システムではなくユーザーが分を100で割って時間にしようとした算数ミスだった話を、テックメディアThe Registerが報じた。
英国の現場で起きた「給与データが約3分の1ずれる」問題の原因が、システムではなくユーザーが分を100で割って時間にしようとした算数ミスだった話を、テックメディアThe Registerが報じた。
「珍しくOracle ERPは問題ではなかった」
英国のテックメディアThe Registerが、毎週金曜に読者からのテックサポート逸話を募って掲載するコラム「On Call」の最新回で、地味だが妙に印象に残る一件を紹介している。

サブタイトルが何より雄弁だ。
今回は、Oracle ERPが原因ではなかった。
ここ数年、英国の自治体が次々とOracle ERP導入で泥沼化している。バーミンガム市は当初1900万ポンドの見積もりが1億3100万ポンドまで膨れ上がり、ウェスト・サセックス州議会も予算が10倍以上に跳ね上がって庁舎の売却益で穴を埋めている始末だ。「ERPの炎上=Oracleが悪い」という前提が、英国の業界読者にはほとんど反射神経として染み付いている。だからこそ、このサブタイトルは効く。
そう言い切れる事案、それ自体がニュースとして成立する空気。ここにこの記事の骨がある。
「約3分の1ずれている」謎のチケット
主人公は、北イングランドにあるフランス系コンサル会社の現地拠点で働いていたソフトウェアエンジニア「アルバート」(仮名)。Oracle ERPまわりの連携を担当していた。
担当案件のひとつが、Oracle社(業界では赤を象徴色とすることから「ビッグ・レッド」とも呼ばれる)の給与アプリから、Excelファイルにデータを流し込む処理だった。1年以上、何の問題もなく回っていた。
ある日、緊急チケットが飛んでくる。従業員の請求可能時間(billable hours)の計算が、突然おかしな値を出すようになったという。ずれは約3分の1。
アルバートは、その「約3分の1」という比率がどうにも引っかかったという。何かを示唆している気がする。だが手がかりがない。
ファイルを開いて確認すると、確かに合計値が違う。連携が壊れたのだろうと当たりをつけ、データベース側に潜って長大なPL/SQL(Oracle Database用の手続き型言語)関数を何時間もかけて読み込んだ。論理に異常はない。さらに困惑したのは、自分の手元で生成したファイルだと数値が正しく出ることだった。
データを取り出す前段で複雑な計算をかけるなら、ここに不具合が紛れ込んでいると考えるのが筋になる。だがそこに不具合はなかった。
ユーザーが「数字が大きすぎる」と勝手に100で割っていた
謎が解けたのは、チケットを起票した本人と話したときだった。
ユーザーが使っていたのは、システムから出力された標準のファイルではなかった。仕様上、請求可能時間は分単位で出力される設計になっている。それをユーザーは見て、こう判断した。
数字が大きすぎる。時間で見たい。よし、100で割ろう。
そう、勝手にファイルを書き換え、全行を100で割っていた。アルバートのコラムには、その後の顛末がこう書かれている。
ユーザーには、請求可能時間を時間単位にしたいなら100ではなく60で割らないとダメだと説明する羽目になった。これがズレが約3分の1だった理由だ。
1時間は60分。120分なら2時間。120÷100=1.2と出る計算と、120÷60=2と出る計算では、確かに4割ほど少なくなる。「約3分の1」というのは英語の「about a third」(およそ3分の1)の意訳で、実際の差は40%ほど。日常会話では「3分の1ぐらい少ない」とラフに言う、そのレンジの話だ。
アルバートが冒頭で感じた「妙に意味ありげな比率」の正体は、現場のユーザーが頭の中で行った乱暴な変換のクセそのものだった、というオチである。
「自分で直す」現場の悪意なき独走
技術的にはほぼ何も起きていない事件だ。だが、笑いごとで済ませてしまうにはやや惜しい構造がある。
ひとつは、システムのアウトプットをユーザーが「見やすく直して」しまう文化が、英語圏の現場でも普通に存在しているという事実だ。日本ではしばしば「Excel職人」という言い方で揶揄される現象だが、それは決して日本特有の問題ではない。仕様書には「分」と書いてあっても、画面で大きい数字が並んでいたら直したくなる人がいる。直す権限と編集できるファイルがあれば、直してしまう。
もうひとつは、サポート担当者の最初の疑いが必ずシステム側に向くという構造だ。アルバートはまずデータベースを疑い、何時間もPL/SQLを追いかけた。1年以上問題なく動いていた連携を、最初に「ユーザーが勝手に値をいじったのでは」と疑える人は、おそらくほとんどいない。性善説と職業倫理が、技術者の時間を浪費させた格好になる。
なぜ「Oracle ERPは無罪」が記事になるのか
The Registerの「On Call」コラムは長年、IT現場の哀感とブラックユーモアを集めてきた媒体だ。今回の話のオチ自体は、あえて言うなら「ユーザーが算数を間違えただけ」の一行で終わる。
それでも記事になっているのは、ERPプロジェクトが燃え続けるこの数年の文脈で、「珍しくシステムは無罪」という構図そのものが読者にとって新鮮に映るからだろう。
そしてそれは、皮肉でもある。本来であればソフトウェアの不具合か、PL/SQLのバグか、Oracle ERPの仕様か── そうした「ありうる嫌な答え」を片端から潰していった先で、ようやく見つかる答えが「ユーザーが100で割っていた」だったとき、技術者は笑うべきなのか、嘆くべきなのか。
仕様通りに動くシステムでも、現場のユーザーが「これ、見にくいから」と上書きすればすべてが崩れる。
Oracle ERPの炎上案件が立て続けに報じられるなか、On Callが今回示したのは、ERP導入で本当に難しいのは技術ではなく、現場の数えきれない小さな自己流が積み重なった先にある、という古くて新しい事実だった。Oracle ERPの肩を持つ気はないが、今回ばかりは無罪。そう書いておくのが妥当だろう。
参照元
関連記事
- Oracleの玉座が静かに崩れる、DBMS市場15年の軌跡
- IT技術者がメキシコで逮捕——会社は救出後すぐ再派遣した
- Stargate骨抜き、OpenAIが自前所有を諦めた
- OpenAI目標未達でAI株動揺、6000億ドル投資の前提が揺らぐ
- Nemotron Nano Omni公開、視覚音声言語を統合
- AIエージェントが9秒で本番DBを消した、Cursor+Railwayの構造問題
- Meta・Microsoft大量レイオフ、AIは本当の犯人か
- Rust製DB「redb 4.1」、Claudeが性能改善のコミットを書いた
- 17年前のExcel脆弱性が現役、CISAが異例の短期警告
- AIエージェントの責任は誰が取る?ベンダーの沈黙が語る不都合な真実