定形外業務も自主的に調べるのがベンダーの努めです：「訴えてやる！」の前に読む IT訴訟徹底解説（14）（2/2 ページ）

東京高等裁判所 IT専門委員として数々のIT訴訟に携わってきた細川義洋氏が、IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回は、契約内容に盛り込まれていない「オペレーターがデータベースを直接操作する機能」が実装されていないと支払いを拒否されたベンダーが起こした裁判を解説する。

[ITプロセスコンサルタント細川義洋，＠IT] PC用表示関連情報

LINE

Hatena

前のページへ | 　　　　　　

ベンダーは定型外業務にも対応する義務がある

　しかし、裁判所の出した判決は逆だった。

【事件の概要】（東京地裁平成16年6月23日判決より抜粋して要約）＜つづき＞

　ベンダーの請求を棄却し、ユーザーの請求（損害賠償）2570万円を認める。

　遠隔操作機能は旅行商品販売業務を行う上では不可欠の機能であり、遠隔操作機能は契約内容に含まれていたと考えるべき。

　もし筆者が専門委員や調停委員としてこの紛争に参加していたら、これと同じような助言を裁判官に行っただろうかと、正直に言えば疑問ではある。

　しかし裁判所は、他の判例と同じく「コンピューターシステムはユーザーの業務に寄与するために開発するものであり、明示的に定義されていなくても、業務に不可欠なものは立派な要件である」と言っている。その意味で裁判所の考え方は一貫している。「旅行業務に遠隔操作は不可欠であり、ベンダーもそのことは知っているべき」と裁判所は判断したのだ。

　筆者は旅行業のシステム開発を行った経験がなかったので、業界に詳しい知人に聞いてみた。知人によると航空券に関する業務は、通常のプロセスだけでは成り立たないそうだ。

　購入した航空券が搭乗間際にキャンセルされたり、そこに別の注文を急きょ押しこんだり、座席の入れ替えをしたり、などの操作が頻繁に発生することを考えると、「通常の画面を使った業務プロセスを飛ばして直接データベースを操作する必要も生じてくるだろう」とのことだ。

　この話を聞いて、ある大手PCメーカーの引当処理のことを思い出した。このPCメーカーは、最盛期にはPCの注文を受けてから出荷までに6カ月を要することもあった。これから生産される予定のPCに注文情報を対応付け（引き当て）して管理するシステムには、大量の注文情報が並び、注文順にPCの引き当てが行われる。

　しかし、重要なユーザーから緊急の出荷依頼が来ることがある。そうしたときは「すでに別の注文に引き当てられていたPCを引きはがし、緊急の依頼に振り向ける」という処理が行われる。

　これらは定型外作業であり、通常の業務プロセスでは処理できない。そこで引当担当者は、引当用データベースに「直接」アクセスして処理を行うのだ。随分と無理やりではあるが、そうしなければ業務が回らなくなる。この判決の航空券システムも、ほぼ同じことを行うために「遠隔操作機能」が必要だったのだろう。

　「正式なプロセスではなくても、対応しなければ仕事にならない業務」というものが世の中にたくさんあり、システムやソフトウエアを開発する際には、業務手順書やプロセスフローにはないこれらの処理にも対応しなければならない。それが現実なのだ。

ソクラテス再び

　現実的に考えて「定型外業務にまで思いをはせるべき」というのは、ベンダーにとって酷な話だ。しかし判決を下した裁判所を恨むのは筋違いだ。現にシステムは使用に耐えず、プロジェクトは失敗したのだ。

　では、ベンダーはどうすれば良いのか。

　やはり、ユーザー各層に対するきめ細かい情報収集しかない。通常、システムの要件は、ユーザーの担当者（多くは、ユーザー企業のシステム部門のメンバー）が、社内の関係者にヒアリングを行い、内部で意見を取りまとめてベンダーに提示する。

　しかし例示したような定型外の処理は、ユーザー企業の担当者も知らない場合が多く、そうなると当然、ベンダーまで要件は伝わらない。

　ならばベンダーが、ユーザーのオペレーターやその上司、その他システムに関わる人々に、実際の業務を細かくヒアリングするしかない。「出社してシステムを立ち上げてから帰宅するまで、どのような作業を行うのか」「正式な業務手順にないような処理がないか」、これらを「ストーリー仕立て」でヒアリングするのが効果的だ。もちろん、決算期など特別な業務が行われる時期のことも考慮が必要だ。

　筆者の経験からいえるのは、「現場の意見（ときには愚痴）には、業務の担当者でなければ分からない業務や注意事項が含まれている」ということだ。それらはユーザーのシステム担当者を通しては、なかなか聞き出せない。

　対象となる業務に関するシステムを開発した経験がないのならば、ベンダーはこうした活動を行うべきだ。確かにこんなことをしていたら、要件定義に時間がかかる。しかし、たとえそのとき非効率に思えても、こうした活動が後続工程での手戻りや重大なトラブルを減少させるのは、読者の皆さんも経験上ご存じだろう。

ヒアリングの際には、ユーザーのシステム担当者に同行してもらうこと。ベンダーだけで現場の話を聞くと、現場の声に押されて、それこそシステム化の目的に合致しない要件を定義してしまう危険がある

　現場の業務というものは、コンピューターとは異なるアナログなものであり、正論だけではうまくいかない。前回の記事で「ソクラテスのように聞きまわれ」と書いた意図はここにある。

　提示された業務フローや手順書だけを信じて作ったシステムでは、ユーザーの業務の半分しか賄えない。数多くの似たような紛争を見てきた経験から、筆者は考える。「いつ？」「誰が？」「何を？」「なぜ？」「どうするの？」「他には？」「もしかして？」といった言葉を繰り返し、周囲から「しつこい！」と思われても聞きまわる。そうした姿勢こそが、ユーザーの真の信頼をベンダーが勝ち取るコツだ。

「「訴えてやる！」の前に読む IT訴訟徹底解説」バックナンバー