ここで、細川氏が「トホホな事例」として「自社の業務を知らないにもほどがあるだろう」(細川氏)というものを1つ紹介してくれた。
ある飲料メーカーで、生産管理システムと在庫管理システムを導入することになった。しかしその会社は、本社と工場の間で互いの業務についての知識共有が全くなされておらず、経費勘定の補助項目も全く違っていた。
「風通しがものすごく悪い会社ってありますけど、ここまでくるとシステム屋がどうこうとかいう問題ではないですね」と思わず苦笑する山本氏。
一例を挙げると、工場には「マイナス在庫」という言葉があった。在庫数より発注数が多いのでマイナスとして管理している便宜上の数字だ。ベンダーは工場側の担当者と「それならマイナス在庫を管理しなければいけませんね」という話をし、その後本社へ。
しかし本社で「マイナス在庫というものがありまして」と切り出すと、本社側の担当者に「マイナス在庫って何?」と問い返された。「いや、工場で聞いたんですけど……」と言うと「そんなのいるの?」と聞かれてしまう始末。工場は工場で「本社でこう言われまして……」と伝えると、「いいんじゃない、こっちで使うんだから」。
そこでベンダーが「じゃあ、本社に了解を取って……」と言うと「いや、別に(了解を取らなくても)いいんじゃない?」と言われてしまう。
すったもんだがあって、結局要件定義が遅れに遅れてプロジェクトは破綻。ベンダーが「これはアカン」となって契約を解除した。ところがユーザー側は、あろうことか「それは債務不履行だ」として、支払った金額の返還のみならず、発注額の1.5倍の損害賠償を請求したという。
「これには、さすがに裁判所もあきれざるを得ない。全面的にユーザー側が悪いという判決が出ました」(細川氏)
先の例は極端なケースとしても、ユーザーが分からないところは、ベンダーがサポートしなければならない。裁判ではこの点をどのように判断されるのか、細川氏に山本氏が尋ねた。
「そうはいっても、ベンダーができることって限られているじゃないですか」(細川氏)
細川氏によると、要件の大本である「趣旨」(裁判では「契約の目的」と呼ぶ)のとりまとめは、やはりユーザーが全部やるしかないという。もちろんベンダーによっては「金融業に精通している」「製造・物流分野の知見がある」という会社もあるし、過去の経験で得たノウハウを生かして「こういう風にできます」と提案できるかもしれない。しかし、限界はある。
「ベンダーにできるのは『機能要件を定義する際は、こういうところを落としがちだから気を付けましょう』とか『機能を漏れなく洗い出すためには、こんなやり方がありますよ』と助言する程度です」(細川氏)
ユーザー企業の業務フローを最もよく知っているのは、当然ながらユーザー企業自身。ベンダーのアドバイスに従って、しっかりと要件を詰めていくのはユーザー企業の責任なのだ。
「『あんたがた、それぞれのプロなんだから、互いにできることをちゃんとやって、システム開発をしなさい』ということですね」(山本氏)
とはいえ、「ジョブフローが管理できていない」「仕事の進め方を明文化したことがない」といった企業もある。急成長中の企業では「本当はやらなければいけない」と思いつつも、立ち止まり振り返る機会が得られないという事情もあるだろう。
「責任者同士の意思疎通ができていないケースは多いですね。飲み会を何回かやれば解決できていたかもしれない。でも、それをやらずに、全てベンダーに押し付けちゃう(だから後でもめる)」(細川氏)
Copyright © ITmedia, Inc. All Rights Reserved.