業務システムは大抵従業員にハックされる。ここでの「ハック」は、いわゆる「ライフハック」的な意味でのハックだ。SIなどで業務システムを設計・開発している人や、情報システム部などで自社の業務システムに携わっている人からすれば、ごくごく当たり前の周知の事実ではないかと思う。
例えば、ある工場の倉庫の在庫・入出庫管理システムの話だが、そのシステムは営業部門の受注管理システムと連動していて、受注に応じて自動的に倉庫からの出庫指示（製品Xを、棚A-B-Cから、Yケース取り出し、顧客Zに発送せよ）が生成されるようになっていた。
システムには出庫指示に応じて発送先ごとに荷札を印刷する機能があった。荷札には発送先と発送数（ケース数）が印刷された。荷札はケース数分だけ印刷され、個々のケースに貼り付けられた。ケース数は現場で変動することがあったため、印刷前に修正できた。ケース数を修正すると、連動して印刷される枚数も増減した。
ところでその倉庫では、発送先ごとの出庫数の差が大きかった。ある発送先には数ケースだけ出庫する一方で、別の発送先には1度に1000ケース出庫することもあった。
1000ケース出庫するとなると、出庫作業をする側としては、ケースをバラバラに出庫するよりも、パレットに数十ケースまとめてあるものをそのまま出してしまう方が楽だし、運送業者が途中で2〜3ケースだけ紛失してしまうようなトラブルの防止にもなる。この場合は、個々のケースに荷札を貼る必要はない（せいぜいパレットごとに4方に1枚ずつ貼る程度でよい）ので、ケース数分だけ荷札が印刷されるのは色々と無駄だった。
また荷札印刷用のプリンタが旧式で、低速で、しかもしばしば用紙（ラベル）がずれてしまうため、印刷中は誰か1人をすぐ側に張りつけておく必要があった。しかし忙しい出庫作業中に、不要な荷札の印刷のために、1人とはいえ長々とプリンタの側に拘束しておくだけの余裕はなかった。
現場としては、発送数が多い場合には、必要な枚数だけ荷札を印刷したかった。だが残念なことに、荷札印刷機能にはケース数を訂正する機能はあっても、印刷数のみを変更する機能はなかった。
では、どうしていたか？ 荷札印刷機能は単独のAccessアプリで、ある方法で内部に隠してあるはずのテーブルやクエリを見ることができた。クエリ上では、荷札に印刷されるケース数と、荷札の印刷枚数は分かれていた。そこで、印刷枚数だけその場で訂正してから、印刷を開始するように運用していた。これはマニュアルには書かれていない、非公式な運用だった。
これは一例で、他にもハックがあった。そのいずれも、現場なりにシステムの特性を見切った上で、それを逆手に取って運用するケースばかりだった。
この手のハックは、業務システムと現状との間に乖離があり、それが問題となるケースがあるが、諸事情により業務システムが改修・改良されない場合に、何とか業務を回そうとする現場の従業員によって編み出される。大抵の場合は個々の現場にて暗黙知として伝わっていて、ドキュメント化はされていない。情報システム部のような部署／担当者も把握していない可能性がある。
問題は、業務システムの全面改修（リプレース）時に起きる。新システム導入の担当者は、大抵は現場のハックの存在を知らない所から計画立案を開始する。ここで、計画初期の関係部署へのヒアリングや、現状の業務分析の一環としての現場観察などで、現場でのハックに気がつくことができたならば、まだ何とかなるだろう。ここで気がつく場合は、大抵はハックが常態化している場合なので、分析をやり直したり現場とのヒアリングを密にして徹底的に現状を洗い出す必要があるなど、当初の想定にはなかった苦労をするかもしれない。だがしかし、まだ何とかなるはずだ。
大変なのは、通常はハックなど不要であるが、繁忙時や緊急時などの偶に発生するケースにてハックが行われる場合だ。この場合、ヒアリングの段階で現場担当者がついついハックの存在を失念していたり、現場観察の時に「繁忙時や緊急時」が起きなかったりして、ハックの存在を知ることの無いまま設計・開発が行われてしまう。そして、開発終盤や旧システムとの並行期間になり、ハックがないと現場がうまくのり切れないような事態が発生し、お祭り騒ぎとなる。
あと最近はアウトソーシングの影響で、現場の正社員は数人で他は全員パートや派遣／契約社員であったり、もしくは現場作業は完全に請負業者が行う（業務システムは借りている）ケースも多い。このような環境では、現場の正社員が忙しすぎて新システム導入に十二分にコミットする余裕がなかったり、現場の人間関係・政治力学の影響を強く受けたりする*1ことで、ヒアリングに失敗する可能性もある。この場合も、現場のハックに気づかずに物事が進んでしまい、後で問題となる。
この問題に解決策はない。システム開発の分野は開発の基盤となる技術の変遷が異常に速いがために*2、開発者はどうしても分析・設計・実装の技術の習得に重点を置きがちだ。現場の業務に通ずる余裕があまりない上に、そもそも業務プロセスは会社によって異なる。一方で、実際に業務に関わっている人は、それはそれで忙しいし、そもそもコンピュータの特性を知らないことも多く、どこか他人事（「これよろしく」と丸投げ状態）であることも少なくない。
理想を言えば、ある程度開発もできて、現場の事情にも通じている人が、比較的変更を行いやすい要素技術を用いて、システムを構築する――つまりシステム内製なら、多少は好転するかもしれない。もっとも、「情報システム部」と人材をひとまとめにしてしまうと同じ社内なのに現場と乖離してしまう可能性があるし、さりとて各現場に散らばった状態では全体のまとまりに欠けてしまう。それに中小企業では、システム開発も問題なくできる人材を見つけることも、確保し続けることも、色々と難しいだろう。
*1:実は、現場に密着したシステムにおいては、監督者である正社員よりもパート／派遣・契約社員／請負元の作業員の方が詳しいことがあるのだが、ヒアリングに呼ばれるのは常に正社員である。仮にパート／派遣・契約社員／請負元の作業員がヒアリングに呼ばれたとしても、暗黙の力関係（彼らは弱い立場にある）が存在するため、忌憚のない意見を得られる可能性は低くなりやすい。
*2:10年前にVisual Basic 6.0でコードを書いていた頃、10年後にC#でラムダ式とLINQを使いつつJava（Android）とObjective-C（iOS）を触っていようだなんて想像できた？ Access 2013でADPが使えなくなるだなんて、64bit WindowsでDAOの参照先が変わるだなんて、気づいていた？
