【第12回】疲弊するIT部門（5）〜「気付きのスパイラル」戦略：三方一両得のIT論 IT部門がもう一度「力」をつける時（1/2 ページ）

企業システムのあちこちでおこるIT部門とユーザー部門の見解の相違。立場も言い分も真っ向からぶつかる。しかし、これからのシステムを考えるとき、システムと業務のギャップを埋めることから糸口を切り開かなければならない。

[岡政次（ウイングアーク テクノロジーズ），ITmedia]

「ムダ撲滅運動」から気づいたもの

　わたしがシステムと業務のギャップが起こる原因といえるものに気付いたのは、4年ほど前のプロジェクトである。工場のTQC（Total Quality Control）運動の一環で進められていた「ムダ撲滅運動」から上がってきた提案がきっかけだった。

提案の内容：

新製品を生産するときに「製品コード」をシステムに登録しなければならないが、この作業が非常に煩雑である。5つのシステムを個別に製品コード登録しなければならない。そのため、製品コードの登録漏れや登録ミスが発生し製品の倉入れ、出荷、輸出などの業務が滞ることが年に何度か発生する。これを、一括登録できるように改善してほしい。

　この原因は根が深い。このようなマスター管理はどこの企業でも重要課題の上位にランクされているものだ。

マスターのはんらんをもたらした理由

　少し蛇足であるが、どうしてマスター管理が企業システムの重要課題になっているかを考えてみたい。ホスト全盛のころのシステム構築は、システム構造をシンプルにしてシステム開発や運用の負担を軽減する代わりに、不足する部分は業務の現場で埋めるという考え方であった。このころに開発された業務システムはすべてシステムごとに個別にマスターを持っている。

　どれが「正」でどれが「副」というのではなく、すべてのマスターが「正」なのである。例えば、新製品を生産するときはすべてのシステムに個別にマスター登録するというのが当り前の運用だった。

　少しでも現場の運用効率を上げるための工夫として登録原票を5枚複写にして、登録原票を１枚書いて、その複写を各マスターの登録部門に回付すれば登録できるようにするというのがせいぜいだった。これは、システムが不出来のために現場の仕事量が5倍にも10倍にも増えてしまった悪い事例だ。現在のシステム統合、マスター統合の流れからは考えられない構築手法であるが、当時の縦割りのシステム開発環境では、この手法がベストとされていた。

臭い物には結局、フタ

　話は戻って、この製品マスター登録システムの「ムダ撲滅」の対応をどうするかであるが、実はわたしが担当する前に一度失敗しており、ユーザー部門もかなり怒っていた。どうもユーザーニーズとシステム化提案がかみ合わず暗礁に乗り上げて、仕切り直しになったテーマだったのだ。なぜか、わたしにはいつも「はずれ」のテーマが回ってくる。

　そのシステム化提案が受け入れられなかった原因には、システム側がユーザーの課題を正しくキャッチアップできなかったことが大きい。マスター登録という業務を俯瞰（ふかん）的にとらえていなかったのである。

　どの企業でも、システムにはオーナーがいる。例えば、経理システムのオーナーは経理部門、購買システムは購買部門というように、システムの構築や改修はオーナー部門が起案し費用を負担する。しかし、それぞれのシステムの利用者はというと、オーナー部門以外の工場のスタッフ部門であったり、販売会社のスタッフ部門であることが大半である。このため利用部門が使いにくいとか、登録作業が煩雑だと苦情を言ってもオーナー部門は痛くもかゆくもないから改善しようとしない。

　主要なシステムのオーナーはほとんど本社部門である。彼らには「親方日の丸」的な考え方が定着していて、生産現場や営業現場のことよりも社長や副社長の支持をすばやく実行することに最優先に考えている。これは、当然なのかもしれないが、これではいつまで経っても「ムダ撲滅」は実現できない。

　そこで腹をくくった現場部門が協力して自分たちで費用を捻出（ねんしゅつ）し、システムを改善しようと考えた。ユーザー部門に言わせると「10年以上前から何度となく改善要望を出しても対応してもらえない、こうなったら自分たちで直すしかない」というわけだ。

　数年前のブームでサプライチェーンマネージメント（SCM）システム構築の着手を機に、マスターの乱立に正面から立ち向かおうとしたプロジェクトもあったが、その複雑さの現実を見てそっとフタをしてしまった。少し違うかもしれないが、社会保険庁の年金問題の加入者の名寄せと同じぐらいの難しさである。

　結局、現行のマスター乱立問題は手付かずのままで、サプライチェーン用のコンバージョン（読み替え）テーブルを登録する道を選んだ。しかし、これではさらに個別管理のマスターを増やすことになり、さらに複雑化させたことになる。

　このSCMプロジェクトのプロジェクトマネジャー（PM）の状況判断は正しいと指示された。しかし、傷口を大きくするだけで、実はなんの解決にもならっていない。どうしてもITという側面でしか考えられず、実現性とリスクを秤（はかり）にかけて方向を決めてしまうのか。