SEにとって顧客の現場は見えているようで見えないものです。
顧客の業務内容を理解したと思い、彼らの望んだ機能を盛り込んだはずのシステムが思いもよらない扱いを受けていたなんてことがあります。
私の経験した恥ずかしい事例。
事例
紙ベースの業務を、データベースを使った一般的な倉庫管理システムとしたネジ問屋さんの例
最初は利用する業者がFAXや郵送で送ってきた思い思いのフォーマットの伝票を毎回マスタメンテしつつデータ入力していたが、あまりの大変さに入力担当者が音を上げて持ち込む伝票のフォーマットを指定したため、利用する業者が減ってしまいました。
結局、フォーマットは元の自由な形式に戻し、入力担当者を増やすこととなりました。
レジのレシートから売上管理システムへ変更した小売店の例
レジ入力で毎日のレシートをファイルして税理士へ委託していたものを、データベースを使った売上入力、集計システムへ変更。
レシートデータの従業員名を従業員マスタに連結していたため、辞めたスタッフの上に新しく入ったスタッフの情報で上書きして利用していたため、過去のレシートデータの従業員が元々誰だったのかわからず、過去の万引きや精算改ざんのスタッフ特定ができなくなり、結局レシートベースの売上情報のファイリングを併用して運用されていました。
原価計算を行いたいという飲食店の例
メニューに使われている材料の使用量計算を行い原価予測を行うためにシステムを導入。
しかし季節ごとに変化するメニュー１つ１つに材料を入力する暇もなく、結局、売上10万円あたりの原価率を材料ごとに設定して、例年の売上を打ち込めばすべての材料の使用量予測を立てるというExcelマクロを別途購入し使用されていました。
営業ではなく開発者こそ現場意識を
- ネジ問屋さんの場合、発注・入荷・棚卸・出庫などのいわゆる一般的な倉庫管理システムをそのまま使うには小規模すぎました。少ないオペレーターでも使いやすいユーザビリティや簡略化できる合理的な仕組みを考えるべきでした。
- 小売店の例では従業員マスタを上書きして利用するなど、SE視点ではあまり考えない運用方法を予測できなかったこと、トランザクションデータを紙ベースのようにその日時の証拠としてマスタと連結しないようにすべきでした。
- 飲食店の場合は、そもそもそれほど正確な原価計算や予測は不必要で、煩雑なデータ入力を行う時間や人件費を割けないということを理解していませんでした。
なぜこいういった事が起きてしまうのか？問題は開発者の現場意識の低さです。
独学プログラマー出身の私は、長年社内開発のプログラマーとして過ごし、営業が取ってきた仕事を仕様書に起こして淡々と糞システムを組むだけで、あまりこういった顧客の立場でシステムを考えることはありませんでした。
独立してから、実際に顧客と顔を合わせてシステムを組むようになってからは、現場を知ることの重要さ、PC知識の無い使用者にも優しいユーザビリティの大切さを痛感しています。
お金も時間も足りないのにがんばる社長さんの笑顔、現場で働くパートのおばちゃん達の笑顔。
そんな現場を知れば、２度とこんな問題は起こしたくないと思います。
懺悔
当時はいっぱい糞システム組んでご迷惑おかけしました。
クリレポいじるのが楽しすぎて帳票に凝りすぎて、ユーザビリティほったらかしでした。ごめんなさい。
正規化に凝りすぎて、文字列データほとんどマスタから引っ張ってました。ごめんなさい。
原価計算のことググってから初めて理解したとか内緒です。ごめんなさい。