60代のリアル｜第２幕、第15話【実録・無謀な事務仕事】1年延期は再生か？破滅への助走か？泥沼化するシステムリプレイス
前回までのあらすじ
スピード開発を優先し、システムリプレイスに「ノーコード」を採用した我が社。パートという立場から一歩引いて静観していた私でしたが、やがて届いた第一弾のプロトタイプによって、現場に大きな困惑が広がることになります。
手渡されたのは、びっしりと指示が並んだテスト仕様書。実際に触ってみると、画面の遷移やクリック数は以前より増え、明らかに操作性が悪化していました。
さらに、コンサルタント会社や自社のシステム担当者が開発会社へ最初から丁寧に説明し、議事録にも残っていたはずの要件定義が、基本設計の段階でごっそりと抜け落ちていることまで発覚します。
「ノーコードで早く作る」という会社側の都合と、泥臭い現場のリアル。両者の間にある決定的な溝が、プロトタイプという形をとって静かに浮かび上がり始めていました。
入金消込のリアル——「取引先コード」で解決できるという机上の空論
2025年～
プロトタイプの検証が進む中で、私が思わず「はあ！？」
と声を上げそうになるほど強い怒りと呆れを覚えたのが、システム側の提案した「入金消込」の仕組みでした。
新しいシステムでは、
「振込時に取引先コードを相手に入力してもらえば、全自動で消込ができますよ」
とドヤ顔で書かれていたのです。
……いやいや、ちょっと待ってください。
日々現場で泥臭く入金データと格闘している身からすれば、それは甘いどころか
「一度でも経理の実務をやったことがあるんですか！？」
と問い詰めたくなるような、ただの机上の空論でした。
実際の現場がどれだけカオスか、開発側はまるで分かっていないのです。
例えば、取引先名に「旭総合」と「あさひ綜合」という漢字違いの2社があったとします。
これが銀行の振込名義になると、どちらも一律で「アサヒソウゴウ（カ」というカタカナ表記になって返ってきます。
取引先コード以前に、名義だけで自動判別することすら危ういのが現実なのです。
さらに決定的なのが、「請求」と「入金」のタイミングのズレです。現場の実態を完全に無視した設計に、怒りすら湧いてきます。
当社の請求書はあくまで「納品ベース」で発行します。しかし、取引先が振り込んでくるのは「相手方の検品が完了した分だけ」なのです。つまり、請求した金額と実際に振り込まれる金額がぴったり一致することなんて、むしろ珍しいくらいなのです。
画像を見ていただければ、その理不尽さが一目瞭然だと思います。
こちらが請求した金額は16,000円なのに、相手が検品を済ませて振り込んできたのは7,500円。
しかも困ったことに、親切に「どの商品の分か」という明細を送ってくれる会社もあれば、金額だけをポーンと振り込んでくる会社もあります。
明細すらない状態で、パズルのように「どの商品の代金なのか」を手作業で特定・紐づけしていく作業がどれほど骨の折れることか……！
万が一、消込を間違えて「未入金だ」と勘違いし、
誤って相手に督促の連絡なんて入れようものなら、
取引先から「払ってるだろ！」と大クレームになり、
会社の信用問題に関わります。
現場の事務員は、毎回胃が痛くなるような思いで冷や汗をかきながら、確認作業を重ねているのです。
それなのに「取引先コードを相手に入れさせれば解決します」だなんて、よく言えたものです。
そもそも、すべての取引先がこちらの都合に合わせて振り込み名義欄にコードを入れてくれるわけがありませんし、仮にコードが入っていたところで、この「検品ベースの金額のズレ」は何ひとつ解決しないのですから。
「システムでスマートに自動化できます」というカッコいい言葉の裏で、現場の泥臭い苦労やリスクは完全に無視され、ポイと置き去りにされている——。
プロトタイプを触れば触るほど、あまりの現場無視っぷりに呆れ果て、こみ上げてくる怒りを抑えることができませんでした。
崩れた計画——「2027年夏」から「2028年夏」への大幅延期
入金消込の件に限らず、プロトタイプを検証すればするほど、
「現場の運用」と「システム開発側が作ろうとしているもの」
との間に、埋めようのない巨大な溝があることが誰の目にも明らかになっていきました。
私が見ていたのは入金消込など業務の一部でしたが、システム全体に目を向ければ、あちこちで不具合や設計ミスが噴出していたのです。
何より胸が痛んだのは、正社員の方々の姿でした。
連日のように残業を重ね、疲労を顔に滲ませながらも、
「これで業務が楽になる」
「理想のシステムができるはずだ」
と信じて必死に検証作業に食らいついていたのです。
それなのに上がってきたのは、現場を無視した扱いづらいプロトタイプと、重要要件の数々の抜け漏れ……。
「あんなに残業してまで対応したのに、このありさまは何なんだ！」
面と向かって口に出さずとも、正社員の方々の怒りは間違いなく頂点（怒り新党）に達していました。
心身ともに疲労がピークを迎える中で叩きつけられた残酷な現実に、社内の空気は重く冷え切っていきます。
当然、この状態で開発を強行できるはずもありません。落ちていた要件の再検討や設計のやり直し作業が山積みとなり、プロジェクトは完全に暗転しました。
そしてついに、会社として重い決断が下されることになります。
当初、経営陣が威勢よく掲げていた「2027年夏」というリリース目標。 それが静かに撤回され、スケジュールは「2028年夏」へと、丸1年も大幅に延期されることが決定したのです。
「1年遅らせます」
と言われても、誰一人として素直に安心することはできませんでした。
「たった1年の延期で、本当にこの惨状を立て直せるの……？」
「これまでの遅れや根本的な設計ミスを、あと1年でどうやって取り戻すつもりなの……？」
疲弊しきった正社員の方々の瞳に浮かんでいたのは、怒りだけでなく、ぬかるみに足をとられたような深い不安でした。
「ノーコードでスピード開発」を売りにしてスタートしたプロジェクトは、こうして大きな課題と不信感を抱えたまま、迷走の泥沼へとハマり込んでいったのです。
🌿次回予告
プロトタイプがもたらした激震と、泥沼化するプロジェクト。 正社員たちの疲弊と怒りを飲み込んだまま、膨らむ不安と共に時は過ぎていきました。
そして——物語は、すべての始まりであり結末でもある「あの日」へと戻ります。
2026年7月17日、金曜日の夕方。 静まり返る事務所で、課長が口を開いたその瞬間、止まっていた時計が動き出します。
次回——「2026年7月17日（金）夕方——システムリプレイス、突然の幕引き」
迷走を続けたプロジェクトが迎えた、あまりにも呆気ない結末とは。
つづく
▼ 第16話はこちらです。
▼ 第２幕の最初から読みたい方はこちらからどうぞ
