数百万円、ときには数千万円かけて開発したシステムが、リリースから半年後には使われなくなり、現場はいつの間にかExcelと口頭連絡に戻っている。システム開発に関わったことのある人なら、一度は見たことのある光景ではないでしょうか。
作った側の手抜きでこうなることは、実はあまりありません。仕様書どおりに、まじめに作られたシステムでも使われなくなる。この記事では、その構造的な原因と、私たちがどう防いでいるかを書きます。
原因1：要件にした時点で、現場の実態が抜け落ちる
システム開発は通常、現場の困りごとを誰かが「要件」に翻訳するところから始まります。問題は、この翻訳が非常に難しいことです。
現場の人は業務のプロですが、業務をシステムの言葉で説明するプロではありません。情報システム部門や外部コンサルが間に入っても、又聞きで書かれた要件には現場の機微——「この欄は手書きメモで運用している」「この承認は実際には事後report」——が乗りません。そして開発会社は、その要件書だけを正として作ります。仕様書どおりで、実態と違うものができあがる構造です。
原因2：例外ケースこそが業務の本体だった
要件定義では、業務の「正常系」が中心に語られます。しかし現場の仕事の大変さは、たいてい例外処理にあります。フォーマットの違う注文書、急ぎの電話対応、月末だけ発生する特殊な処理。
正常系しか扱えないシステムは、例外が発生するたびに「システム外」での対応を強います。例外のたびにExcelに書き、あとでシステムに転記する——この二重管理が始まった時点で、システムは現場にとって「仕事を増やす存在」になります。使われなくなるのは時間の問題です。
原因3：納品された瞬間から、業務とシステムがずれ始める
開発に1年かければ、要件定義時点の業務と納品時点の業務はすでに別物です。さらにその後も業務は変わり続けますが、納品で契約が終わるモデルでは、システムは止まったままです。改修には都度見積もり・稟議・発注が必要で、現場は「直してもらうより我慢するか、使うのをやめるか」を選びます。
どう防ぐか：翻訳をなくし、小さく当て、育て続ける
私たちがForward Deployed Engineer（FDE）というスタイルを取っているのは、まさにこの3つの原因に対する答えです。FDEについて詳しくはこちらの記事に書きましたが、要点は3つです。
翻訳をなくす。 エンジニア自身が現場に入り、業務を直接見ます。要件書を介さないので、翻訳ロスが構造的に起きません。例外処理も「実際に起きているもの」を見て設計に織り込みます。
小さく作って、現場に当てる。 完成品を1年後に納品するのではなく、数週間で動くプロトタイプを作って現場に使ってもらいます。「実態と違う」は、作り込む前に発見されれば安く直せます。
納品で終わらせない。 業務が変わり続ける以上、システムも変わり続ける前提で関わります。リリースは完成ではなくスタートです。
まとめ
システムが使われなくなるのは、現場の怠慢でも開発会社の手抜きでもなく、「要件書を介した分業」という構造の問題です。構造の問題は、構造を変えないと解決しません。
心当たりのある方——使われていないシステムをお持ちの方も、これから作る方も——お問い合わせからお気軽にご相談ください。