定まらない要件、ユーザーからのむちゃな要求：システム開発プロジェクトの現場から（4）（1/2 ページ）

きっかけは食中毒事件

　7年ほど前、ある食品メーカーの乳製品が原因で大規模な食中毒事件が発生しました。皆さんの記憶にも新しいことと思います。

　このとき世間では、「食の安全」への関心が非常に高まりました。当時の私たちのクライアントは酒類メーカーでしたが、同じく食品を製造する企業としてこの事件を重く受け止め、品質リスクへの対策を強化することになりました。

　一般的には、予防策を十分に講じても、不良品の発生を完全に防ぐことは不可能です。このメーカーでも、ラベルの印刷がずれているといった軽微なものから、工場の窓から侵入した虫が内容物に混入するといったものまで、さまざまな製品不良が発生していました。

　不良品が出荷されてしまった場合、メーカーは出荷先への広報や、製品の回収を迅速に行わなければなりません。そのためには不良品の所在を、ロットナンバー単位でいち早く把握する必要があります。

　これらの背景から、ロットレベルで製品の所在を把握するシステムが導入されることになり、プロジェクトとして予算化されることになりました。

「本当に役に立つシステムなのか？」

　予算がついたとはいうものの、対象が基幹業務ではないので金額はそれほど大きくなく、コストを抑えた仕組みにすることが前提でした。

　システムの基本的な仕組みは、既存の物流システムから入出庫時の履歴データをインターフェイスしてもらい、その移動履歴を照会する機能を提供するというものです。

　しかし、ここには大きな制約がありました。ロットナンバーを保持しているのは工場倉庫を管轄する物流システムだけで、全国各地の自社倉庫を管轄している基幹システムは保持していなかったのです。つまり、工場から出荷された時点では製品をロットレベルで把握できるものの、その先は品番レベルでしか把握できないのです。この制約にどう対応するか。この時点で具体的なアイデアはありませんでした。

　私たちは予算がついた時点で内々に仕事の依頼をいただいており、実質的にプロジェクトはスタートしていました。

　しかし、正式な契約を結ぶ前にクライアント側に人事異動があり、このプロジェクトの発注部門の責任者である部長が交代してしまいました。後任としてやってきた新しい部長は、上記のような制約などから、着任早々このシステムの意義に疑問を呈しました。「本当にこのシステムに予算を投入する価値があるのか？ 私が納得できなければ、契約書にはサインしない」と宣言したのです。

　すでにこちらは作業を始めています。発注をキャンセルされてしまうと、その影響は小さくありません。仕事を確保するためには、その部長に何とか納得してもらう以外にありません。

　私たちは仕事を頼まれた立場でありながら、発注者にその意義を説明するという、奇妙な構図に置かれることになってしまいました。

システムの意義をあらためて発注者に説明

　こうして私たちは、システム化のメリットをあらためて整理することになりました。

　過去の移動履歴データを調査し、概要レベルで設計イメージを考えてみました。その結果、すべての移動履歴にロットナンバーがなくても、工場からの出荷データとその時点の該当拠点の在庫数、その日以降の該当拠点からの出荷データを組み合わせることで、対象ロットの所在をかなり限定できるめどが立ちました。

　従来は不良品が出荷されてしまった場合、ローラー作戦的にすべての拠点に問い合わせていたので、それに比べれば十分に効率的といえます。

　しかしこのシステムの場合、対象が定常業務ではないので、事務コストの削減はメリットになり得ません。そこで、調査にかかる時間を短縮することで不良品の拡散を抑えることができるという「時間の利益」を主張することにしました。

　これらの趣旨を資料に取りまとめてプレゼンテーションをした結果、どうにかこの部長にも首を縦に振ってもらうことができました。