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

» 2015年03月23日 18時00分公開

[ITプロセスコンサルタント細川義洋，＠IT]

前のページへ 1|2 　　　　　　

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

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

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

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

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

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

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

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

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

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

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

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

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

ソクラテス再び

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

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

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

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

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

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

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

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

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

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

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

細川義洋

東京地方裁判所民事調停委員（IT事件担当）兼 IT専門委員　東京高等裁判所 IT専門委員

NECソフトで金融業向け情報システムおよびネットワークシステムの開発・運用に従事した後、日本アイ・ビー・エムでシステム開発・運用の品質向上を中心に、多くのITベンダーおよびITユーザー企業に対するプロセス改善コンサルティング業務を行う。

2007年、世界的にも季少な存在であり、日本国内にも数十名しかいない、IT事件担当の民事調停委員に推薦され着任。現在に至るまで数多くのIT紛争事件の解決に寄与する。

ITmedia オルタナティブブログ「IT紛争のあれこれ」

美人弁護士有栖川塔子のIT事件簿

書籍紹介

「IT専門調停委員」が教えるモメないプロジェクト管理77の鉄則

細川義洋著　日本実業出版社　2160円（税込み）

提案見積り、要件定義、契約、プロジェクト体制、プロジェクト計画と管理、各種開発方式から保守に至るまで、PMが悩み、かつトラブルになりやすい77のトピックを厳選し、現実的なアドバイスを贈る。

なぜ、システム開発は必ずモメるのか？

細川義洋著　日本実業出版社　2160円（税込み）

約7割が失敗するといわれるコンピューターシステムの開発プロジェクト。その最悪の結末であるIT訴訟の事例を参考に、ベンダーvsユーザーのトラブル解決策を、IT案件専門の美人弁護士「塔子」が伝授する。

「ジェイコム株誤発注事件」に見るシステムの瑕疵判断とその対応（前編）
東京高等裁判所 IT専門委員として数々のIT訴訟に携わってきた細川義洋氏が、実際のIT訴訟事例を例にとり、トラブルの予防策と対処法を解説する
「ジェイコム株誤発注事件」に見るシステムの瑕疵判断とその対応（後編）
ジェイコム株誤発注事件では、原告請求416億円を大幅に下回る107億円を損害賠償額として被告に請求する判決が下された。東京高等裁判所はどのような判断基準で判決に当たったのだろうか
ベンダーよ、シェルパの屍を越えていけ～　細川義洋×山本一郎「なぜ、システム開発は必ずモメるのか？」
リスペクトなきプロジェクトには死が待っている――山本一郎さん（やまもといちろう a.k.a.切込隊長）と、東京地方裁判所民事調停委員細川義洋さんによるDevelopers Summit 2014の最終セッションは、雪の寒さとは違う意味で会場を震え上がらせた。