「予算を抑えて、現場の業務をスマートにシステム化したい」 「実績のあるシステム会社が『やれます！大丈夫です！』って言ってくれたから安心」
もしあなたが、会社のIT担当やDX推進担当に任命されて、そんな風に考えているなら……今すぐその甘い考えを捨ててください。 さもないと、私と同じように、担当者が失踪し、最終的にシステム会社が倒産するという「リアルな地獄」を見ることになります。
これは、まだ世の中に「DX（デジタルトランスフォーメーション）」という言葉が出始めた頃、右も左も分からない状態から社内システムの構築に挑み、現場とシステム会社の板挟みになりながら泥沼の交渉を駆け抜けた、私の血と涙の初仕事の記録です。
1. すべては「横着精神」から始まった。DX推進とバーコードとの出会い
右も左も分からないDX推進チームへの抜擢
当時、会社で「これからはDXの時代だ」と大号令がかかり、私は部門の代表チームとして、DX推進業務に参加するメンバーに選ばれました。 とはいえ、当時はチームの全員が「DXって何？」という状態。毎日毎日、ネットや本でDX推進の情報を探っては「ふーん……」と頭をひねる、そんな手探りの日々を過ごしていました。
会社全体の困りごとや、システム化できそうな「ネタ」を社内で調査していく段階で、現場からはたくさんのニーズが上がってきました。しかし、それらのほとんどは「AIが全部自動でやってくれる」みたいな、当時の技術からすれば、まるで近未来のおとぎ話のような現実味のないことばかりだったのです。
「2人確認のムダ」とコンビニのバーコードリーダー
そんな中、私はある「地味だけど確実な課題」に目をつけました。 自分で言うのもなんですが、私は昔からかなりの「横着者」です。「嫌な仕事、面倒な作業は1秒でもやりたくない」という精神が人一倍強い。その横着センサーがピンと反応したのが、現場で行われていた「原料仕込みの際、作業員が2人がかりで、目視で内容を確認する作業」でした。
「これ、人間が2人でじーっと見て確認するの、めちゃくちゃ非効率やん。絶対に自動化できるわ……」
そう考えて情報を漁っていたときに行き着いたのが、「バーコードリーダー」というデバイスでした。コンビニのレジで店員さんが当たり前のように使っているアレです。「これを使って、原料の品名やロットをピッと読み込ませれば、1人で、しかもし一瞬で正確に確認が終わるんちゃうか！？」
これだ！と思った私は、すぐに動き出しました。ここまでは、最高にワクワクする効率化の始まりだったのです。
2. 相見積もりと1冊の本。『システムを外注するときに読む本』の予言
デバイスメーカーからの紹介と、一番安い会社への発注
何せ初めてのシステム開発です。右も左も分からない私は、とりあえずバーコードリーダーのメーカーに連絡し、デバイスの実物を見せてもらうことにしました。そのついでに「これを使った在庫・仕込み管理のシステムを作りたいので、どこか良いシステム会社を紹介してくれませんか？」と頼み込んだのです。
メーカー側としては、自社のデバイスさえ契約して買ってくれれば御の字です。すぐに2つのシステム会社を紹介してくれました。（※ちなみにメーカー自体は、最後までしっかりとお守り・サポートをしてくれました。感謝しています！）
紹介された2社から相見積もりをとったのですが……悲しいかな、こっちはシステムのことなんて1ミリも分からない初心者です。
「そりゃあ、安い方で始めるよね」
今思えば、それがすべての引き金でした。
警戒していたのに…本に書いてある通りのルートへ
ただ、私も完全に無防備で突っ込んだわけではありません。発注する前後に、必死で勉強するために1冊の本を読み込んでいました。
それが、細川義洋さんの著書『システムを外注するときに読む本』です。
システム外注における発注側と開発側のズレ、要件定義の罠、泥沼化するプロセスがリアルに書かれた名著です。私はその本をデスクに置き、「よし、ここに書いてあるような失敗だけは絶対に避けるぞ！」と、教科書にする勢いで警戒していました。
しかし、結果から言うと……私のプロジェクトは、見事なまでにこの本に書かれている「大爆死ルート」をそのまま一歩一歩トレースしていくことになるのです。
警戒していたはずなのに、なぜ防げなかったのか。それは、実際の「現場」という怪物が、机上の空論を遥かに超える理不尽さを持っていたからでした――。
3. 「今の現場のままシステム化しろ！」牙を向く現場と、それを飲んだ職人たち
「要件定義？何それ？」状態のスタート
いよいよ実際のシステム開発がスタートしました。相手は「町のシステム会社」ってレベルの規模でしたが、とにかく物腰が柔らかく、こちらの話をよく聞いてくれる会社でした。「御社の望む進め方で良いですよ！」と言ってくれて、初心者の私たちは「良い会社に当たったなぁ」と安心しきっていたのです。
当時の私たちは「要件定義？なんじゃそれ？？」という状態。ただ、私は昔から業務のシーケンス（手順図）などの作成はしていたので、その要領で「現場は今こういう流れで動いていて、こういうことをやりたいんです」と一所懸命に伝えました。
最初、システム会社が持ってきた提案書は、私のイメージと少し違う程度でした。私個人としては「まぁ最初だしこんなもんか。ここから始めて、触りながらブラッシュアップしていけばいいや」と軽く考えていたのです。
現場作業員の頑固な抵抗と、システム会社の致命的な「イエス」
しかし、実際に現場の作業員を巻き込み始めると、状況は一変しました。現場のメンバーから猛烈な拒絶反応が返ってきたのです。
「新しくシステム化するんだから、今の現場の作業手順を『そのまんま』システムに組み込め！変えるのは無理だ！！」
現場からすれば、慣れ親しんだ職人技のような仕込み作業を、システムの都合で変えられたくない。まさに頑固一徹の立ち位置でした。本来なら、ここでシステムに合わせて業務を変える「業務改革」をすべきだったのですが、紹介されたシステム会社のエンジニアたちもまた「職人」でした。彼らは、あろうことか現場のこの無理難題を、プロのプライド（あるいは単なるお人好し）ですべて丸呑みにしてしまったのです。
こうなると、間に入っていた私にはもうコントロールできません。主役は「現場メンバー」と「システム会社」になり、実際の原料仕込みの超細かい例外処理や手順を巡って、数十回以上も要件定義を詰めるという、終わりの見えない泥沼のやり取りが始まってしまいました。
4. 担当者の失踪、激怒する社長。そして崩壊していくプロジェクト
「担当が変わります」の裏に隠された退職劇
毎週のように不毛な打ち合わせを繰り返し、スケジュールがズルズルと遅れ始めていた頃、システム会社から「担当者が変わる」という連絡が入りました。
「なんだ？不穏な空気だな……」
嫌な予感は確信に変わりました。なんと、現場と揉めまくって板挟みになり、限界を迎えた先方の管理担当者が、本当にそのまま会社を辞めて（飛んで）しまったのです。 当然、今までの細かいやり取りの引き継ぎなんてまともにされていません。しかし、納期は刻一刻と迫ってくる。ここから、プロジェクトは本当の崩壊の危機へと突入しました。
システム会社社長の直談判「こんなのは無理だ！」
ある日、ついに相手の会社の社長が直々に我が社に現れました。 「最初の要件と違いすぎる！現場の細かい要望を全部聞いてたら、こんなの作れるわけがない！もう無理だ、追加の金を払ってくれ！！」
引き継ぎ不足と現場の暴走で首が回らなくなったシステム会社が、こちらに泣きついてきたわけです。当時は本当に胃がキリキリと痛みました。しかし、ここが私の踏ん張りどころです。 「最初の『要件定義』が決定して締め切られていない以上、現場が要望を出し続けるのは当然です。そちらが飲むと言ったのだから、今さら破綻したからとお金を上乗せしろというのは筋が通りません！」 私は断固として折れませんでした。
ですが、彼らだけを責めてプロジェクトが頓挫したら元も子もありません。さすがに可哀想という気持ちもあったので、「現状、お互いに話が合意できているところまでで、きっちりと要件定義のハンコを押して、一旦ここで仕様を締めましょう」と、間をとった現実的な対応を提案しました。
激しい交渉の修羅場をくぐり抜ける中で、気づけば「要件定義とは何たるか」というイメージが、私の頭の中に完璧に出来上がっていました。
5. 【結論】要件定義には計画の半分を費やしても良い。机上論を超える現場のリアル
その後、社内に対して「なぜ追加予算が必要なのか」の費用対効果をロジカルに説明し、無事に追加予算をいただくことで、なんとかシステムを導入し、試験運用までこぎつけることができました。
この一連の壮絶な経験を経て、私は一つの確固たる持論を持つようになりました。
「システム作成や要件定義においては、プロジェクト全体の計画の半分を費やしても良い」
現場のニーズ、日々の作業、それに伴う現場の環境（デバイスが置かれる場所や、作業員の動線）によって、システムの成否はすべて変わります。 要件定義の机の上で詰め切れるところと、実際にテスト機を現場に持ち込んで「試運用」してみないと絶対に分からないところがある。おそらく、システムの失敗のほとんどは、この「現場で経験してみないと分からないこと」を、事前の机上論でどれだけリアルに議論できるか、にかかっています。
アプリの仕様だけでなく、使用するバーコードリーダーの読み取り感度やボタンの押しやすさ、現場の粉塵や明かりの環境も含めて、検討すべき項目は文字通り「膨大」にあるのです。
これからの時代、こうした人間の泥臭い経験や現場の知見を、現代の「AI」や「システム」を使ってどのように補い、事前にシミュレーションしていくかを考えるのは、非常に面白い挑戦だと考えています。そういう意味では、これからはより一層「データ解析の時代」に入っていくのでしょうね。
エピローグ：システム会社は消えた。そして次なる僕の野望
紆余曲折を経て動き出した在庫管理システムですが、その後、なんとそのシステム会社は本当に倒産してしまいました。 現在は、全く別のシステム会社が「お守り（最低限の保守）」だけをしてくれている状態で、システムはかろうじて生き残っています。
しかし、私の戦いはこれで終わりではありません。 数々の修羅場をくぐり抜け、要件定義の重要性を知り、今やAIツールやローカルでの開発環境を自分で見据えている私には、次なる野望があります。
それは、この倒産した会社が残していったシステムを、現在の自社に最適化した「ランニングコスト0」の自社内製システム（Power Appsなど）へ、自分の手で完全に置き換える（リプレイスする）ことです。
あの時の失敗と、担当者が飛んだ絶望のデータは、すべて私の頭の中に蓄積されています。今度は外注のトラブルに怯えることなく、小さく作って、現場で即テストして、爆速で改善していく。
システム会社が倒産したという「最悪の結末」は、私にとって、エンジニア・ITコンサルタントとしての牙を研ぐための、最高のプロローグだったのです。
コメント