2016年の外注失敗談：システム会社の「できます」は鵜呑みにしない
“できます”を信じて半年待った結果、返ってきたのは『できません』だった
概要（この記事でわかること）
「Accessでは動いていた業務システム」をWeb化しようとして失敗した、伊藤の原体験をもとに、
なぜ外注が“できると言ってできない”のかを構造で解説します。
机上の空論ではなく、社長が同じ地雷を踏まないための記事です。
2016年、私は“Accessで回る会社”を作っていた
当時、私はリユース会社の現場にいました。
社内では、Microsoft Accessで、
- 販売管理
- 受注管理
- 入金照合（自動消し込み）
- CSV連携（ヤフオク、銀行、配送ラベル）
みたいなことを、私が現場で回せるように作っていました。
正直、今思っても結構作り込んでいたと思います。
そして、私はこう考えました。
「この仕組みをWeb化すれば、もっと強い基幹になる」
ここで外注に踏み切ります。
外注側はこう言った。「できます」
システム会社は要件定義書を出してきました。
そして言います。
- 「できます」
- 「半年あれば納品できます」
- 「この通り進めれば問題ありません」
当時の私は、要件定義書を見ても正直よくわからなかった。
でもAccessがある。
だからこう思ったんです。
「Accessでできるなら、Webでもできるだろう」
これが、地雷の入口でした。
半年待った。結果、「できませんでした」
結論から言うと、半年以上待って出てきた答えはこうです。
「すみません、できませんでした」
そしてさらに地獄なのはここ。
すでにお金は払っていた。
だから返金を求めた。
でも返ってきた言葉がこれです。
「これは工数の契約なので、完成とは関係ありません」
私は当時こう思いました。
「詐欺じゃねえか」
でも、これが “システム開発の世界では起こり得る” んです。
なぜ起きたのか？「Access→Web」で失敗しやすい3つの理由
ここからは冷静に、構造で整理します。
理由①：Accessは“個人最適”で成立する
Accessは強いです。
ただし強いのは、
- 1人〜少人数
- 同じPC/同じネットワーク
- 例外対応を作った本人が吸収できる
この条件が揃っているとき。
つまり、Accessは「暗黙知」が回りやすい。
その暗黙知を、現場で吸収して成り立つ。
理由②：Webは“全員が同じ手順”で動かないと死ぬ
Webシステムは、
- 複数人が同時に触る
- 権限が必要
- ログが必要
- 例外対応が必ず発生する
Accessで“なんとなく吸収してた例外”を、全部ルールにしないといけない。
つまり、Web化は 「暗黙知の言語化」 が本丸なんです。
理由③：要件定義書は“現場の手触り”を伝えられない
Accessの画面を触ってる現場が欲しいのは、
- クリック数
- 入力の手間
- 例外処理の導線
- ミスが起きない設計
でも要件定義書に書かれているのは、
- 機能一覧
- データ項目
- 大枠のフロー
つまり、現場の苦しさが書類に乗らない。
結果、Web化が「できる/できない」というより、
“現場で使える形”にならない んです。
じゃあ、同じ失敗を防ぐには？
私が今やっている答えはシンプルです。
① 要件定義書で合意しない
要件定義書は“内部資料”でOK。
社長が見るべきは、動くもの。
② まず3日で触れる形を出す
触ればズレが出ます。
ズレが出れば、修正できます。
半年後にズレが出るのが最悪です。
③ 成果責任で進める
工数契約は、発注側が負けやすい。
- “できません”でも請求される
- “使えません”でも納品扱い
だから成果責任に寄せる。
ここを変えるだけで、外注の地獄はかなり減ります。
最後に：この失敗は、今の私の芯になっている
「机上の空論じゃない」って言えるのは、
私が実際にやられてきたからです。
- 待たされた
- できなかった
- お金は戻らなかった
- 現場は救われなかった
だからこそ、私は今「動くもの」で潰す。
社長が、同じ地雷を踏まないために。