民事調停委員と専門委員の仕事
――著書『紛争事例に学ぶ、ITユーザの心得【契約・費用・法律編】』『【提案・開発・プロジェクト管理編】』はEnterpriseZineの連載をまとめたもので、普段の読者であれば細川さんのことを知っている方も多いと思いますが、改めて自己紹介をお願いできますか？
細川：私は大学を卒業してすぐに日本電気ソフトウェア（現：NECソリューションイノベータ）に入社しました。その後日本電気に出向し、金融関係のシステム開発に携わりました。いわゆるシステムエンジニアですね。16、7年在籍していろいろな仕事をしてきましたが、基本的には金融機関向けのシステム開発をしてきたと言えます。
40歳くらいのとき、IBMビジネスコンサルティングサービス（のち日本アイ・ビー・エムと経営統合）に転職して、IT戦略やIT開発の品質向上のためのコンサルティングを手がけるようになりました。その期間にある人から声がかかって、東京地方裁判所でIT紛争の民事調停委員と専門委員を務めることになったんです。
日本アイ・ビー・エムを退職したあとは当時のクライアント企業に入社して、現在は経済産業省で政府CIO補佐官を務めています。仕事としては、政府のIT対応に対する技術的な支援をしたり、経済政策への助言をしたりしています。
――民事調停委員、専門委員というのはどういう仕事をするんでしょうか。
細川：たとえば、要件定義がうまくいかずプロジェクトが失敗すると、損失が出ますよね。ユーザ側は「こんなものにお金は払わない」と言います。しかし、ベンダ側は「要件定義に不備があるから支払え」と主張する。両者では解決できないということで、調停や裁判が発生します。
民事調停委員は両者の間に立って落としどころを探り、解決に導くのが仕事です。ユーザとベンダ、どちらがどういう責任を負うべきなのか、法律や決まりきった判断基準がない中で一般的な常識を考慮しながら、裁判官と一緒に両者を説得するんです。
調停が笑顔で終わることはほとんどありません。お互いが我慢できないところをしょうがない、どうしようもないから歯を食いしばって「わかりました」と判を押すことになります。4、5年かかることもざらですから、両者ともに疲れてきて「これぐらいで手を打とう」となることが多いですね。
一方、専門委員は実際の裁判や証拠を整理する弁論準備に関わります。IT技術やITプロジェクトについて裁判官に助言して、裁判の手伝いをします。実際には弁論準備室で原告と被告の話を聞いて、できれば調停で和解できないかと説得することもありますね。場が違うだけで、やっていることは調停委員とあまり変わりません。
――調停委員と専門委員は訴える側と訴えられる側、どちらかの立場に立つわけではないんですか？
細川：もちろん中立でないといけません。ただ、ユーザとベンダに個別で話をする際は、ベンダ側の視点やユーザ側の視点で話すことはあります。
――IT関連の調停や裁判は多いんでしょうか。
細川：ものすごく多いわけではないですが、東京地方裁判所では年間数十件ほどではないかと思います。とはいえ、1件を解決するまで何年もかかるので、同時並行で進んでいる件数は多くなりますね。20人ほどの調停委員が分担して、最初から最後まで担当します。
IT紛争からもたらされる知見を共有していくために
――紛争に至るのはどんなITプロジェクトですか？
細川：圧倒的に多いのが、要件定義の不備に関する案件ですね。たとえば、ユーザが顧客情報を登録するシステムを要件定義して、ベンダが本当に登録するだけの、更新や修正のできないシステムを作ってしまって揉めた案件がありました。
常識的に考えれば、登録システムには更新や修正の機能はあって当然です。でも、たしかに要件定義には書かれていない。要件定義がどちらにも都合よく見えてしまうわけです。
また、プロジェクトのリスクを管理できないこともトラブルにつながりがちです。当初の予定どおりに進むことは稀で、要件定義があとから変更されることも往々にしてあります。テスト段階になってユーザが要件の追加を持ち出し、ベンダがそれに対応できずプロジェクトが壊れることもありますね。
あと、ベンダ側も実際に取りかかってみて技術的に難しいことがわかった、あるいは当てにしていた開発者があまり関われなかった、といった理由で開発をどんどん延期していくことがありますよね。それをユーザに公にせず、内部で頑張ろうとするうちにどうにもならなくなったという案件もありました。
調停や裁判に至る原因が単一であることは少なく、たいていは複数の原因の合わせ技で大変なことになる場合が多いです。
――紛争はどういう結末を迎えることが多いんでしょうか。
細川：最後は損害賠償ですね。あるプロジェクトが頓挫したら、それまでに支払ったコスト、従業員の賃金や設備費用をお互いに算定します。そこにはシステムがスケジュールどおりにでき上がっていたら生まれたはずの売上、つまり機会損失も含まれます。
そしてそれぞれの責任を勘案し、どちらがどちらにどれくらい支払うのかを決定します。裁判の場合は責任の所在が0:10になることもあるんですが、調停の場合はほとんどありません。というのは、調停は和解することが目標ですから、ある程度両者に責任があることにしないと交渉がうまくいかないんです。
さらに、どちらかの会社を潰す判断もできませんので、いくらまでなら払えそうかを見極めて対応する必要があります。「どうしても払えないから、なんとかこれで呑んでくれ」と説得することもありますね。
紋切り型で決着させるのではなく、現実を見て判断するのが大事です。
――そういった紛争の知見は、IT業界で共有されているんでしょうか。
細川：私が連載を始めたのはまさにそれが理由で、こうした細々とした発信があるくらいです。先日本書の刊行記念で講演する機会があり、ある紛争事例を挙げたんですが、この事例は5年ほど前から様々な場でお話ししています。ところが、いつどこで話しても新鮮に受け止められてしまうんです。
その事例というのは、IT紛争の中では有名な裁判の話です。ユーザが要件定義を次々に変えていってしまった。しかし、ベンダがプロジェクト管理義務を怠ったからベンダに責任がある、という判決に至った裁判で、当時非常に話題になりました。
知っている人は増えているように思いますが、こうした知見はまだまだ共有はできていないと痛感しています。
自分自身、ITプロジェクトをどう進めるべきか提案する仕事をしてきました。要件定義や課題管理、構成管理についての助言です。ですが、実際に調停や裁判に携わると、やっぱりそれらがトラブルの原因になっているんですよね。
だからこそ、紛争事例からもっと学んで業界で共有しないといけないと思っています。
「お任せしていました」から脱して
――連載の反響はどうでしたか？
細川：ユーザ側はベンダに任せればそれでいいと思っていた、と感想をもらったことがあります。そんな人は多いかもしれませんが、ユーザは要件を細かく定義してリスクや課題を管理して共有し、テストにも協力しないといけないんですよ。でも、お金を払っているから任せきりでいいと思ってしまうんです。お金を払ったうえで、まだまだやることがあるんですね。
ベンダ側でも、開発自体には熱心でもプロジェクト管理義務についての意識が低かった、という人がいました。思ったよりベンダ側の責任が重いことに驚いた、という声もありましたね。
――連載、また本書では「ユーザの協力義務」が何度かテーマに挙げられています。
細川：情報システム部門に何十人何百人といる企業であれば、ユーザの協力義務の意識は根づいています。自分たちがある程度やらないとプロジェクトは成功しない、と思っているんですね。ベンダにはリスクでも何でも開示してほしいと言うんです。
リスクを共有する、協力してほしいことを伝える。そういう関係があってこそのパートナーで、それがないならただの出入り業者です。
とはいえ、それくらい意識の高い企業は少なく、ほとんどのユーザがお任せ体質です。それを象徴するかのように、ユーザ側の訴状や準備書面には「お任せしていました」「信頼していました」という言い分が常套句のように使われます。弁護士が効果的だと考えて入れさせているのかもしれませんが、それにしても本当に多くて……。よく「丸投げ」と言われますが、それではうまくいかないんですよ。
――訴状に「お任せしていました」と書いておけばユーザ側に有利になるんですか？
細川：被害者意識を強調しておきたいんだと思います。しかし、正直裁判の結果に影響はありません。裁判官もそのへんは冷静ですからね。
ITプロジェクトではシステム開発の案件が多いと思いますが、そのシステムをどんな業務に使うのかは企業によって様々です。つまり、ベンダの仕事はユーザの業務がまったくわからないところから始まります。業務だけでなく技術、風習、組織体制、社内の力関係もわかりません。なので、いつも冒険なんです。だからこそユーザ側の協力が不可欠なんですよ。
ベンダはユーザの業務を把握しておかないといけない
――これまでで特に印象的だった事例はありますか？
細川：ある旅行会社で、航空機の発券システムを作るプロジェクトがありました。チケットの情報を格納しているデータベースにオペレーターが直接アクセスする機能が必要だったんですが、旅行会社にしてみればあって当たり前の機能なので、わざわざ要件として定義しなかったんです。
しかし、ベンダ側は普通のオペレーターがデータベースを触るのは危険だからと考え、その機能を盛り込まずに発券システムを作りました。当然、テスト段階で旅行会社はその機能がないことに気づき、注文をつけます。両者に言い分があったため、裁判になりました。
判決としては、ユーザ側に有利なものでした。そもそもデータベースにリモートでアクセスする機能は旅行会社の発券システムには不可欠で、さらにベンダは旅行会社の業務に精通しているから選ばれた、と判断されたからです。
ベンダはユーザが業務を効率化することが目的だとわかっていたのだから、その業務を把握し、現状がどうなっているかを理解し、どんな機能が必要かどうかを判断してシステムを作らないといけないと。
ここで重要なのは、ベンダが契約の目的、つまりユーザのIT導入による業務の効率化を果たせていないと考えられるときは、要件定義に書かれていなくてもベンダ側に不利になる、という考え方ですね。
また別の事例で、大学の履修登録システムの開発プロジェクトがありました。履修登録は何万人もいる大学生がある一時期に集中して行いますが、でき上がったシステムではその数を捌ききれず、元請けが下請けを訴えました。
元請けは性能の定義をしていなかったんですが、結果としては下請けに不利な判決となりました。要件定義にはなくても、大学生が何万人もいること、履修登録が一時期に集中することはわかりきっています。だとすれば、必要な性能は推測できます。契約の目的、業務を考えたときに当然に推測されることは開発する側が対応したり確認したりしなくてはならないわけです。
もちろん、要件定義がなされていなかったことでユーザの責任が重くなる案件もあります。とはいえ、ベンダはユーザの業務を把握しておく必要があるでしょう。この二つの事例は印象的でした。
――細川さんはその判断をどう捉えましたか？
細川：正直、理想論だと感じました。エンジニアをやっていたからこそ、要件定義にないことを対応するのが難しいことは知っています。もちろん、要件定義を抜け漏れなく作ることも難しい。
ただ、そこを埋める努力はできるので、ユーザとベンダはきめ細かくウォークスルーを行う、異常系も含めて確認する、こういった地味な作業が必要だと思います。
通常考えられる要件定義よりも時間と工数がかかりますが、トラブルを避けるには欠かせないですね。今まで自分がやってきた仕事も、実は抜けが多かったんだなと改めて考えさせられました。
ベンダ側にも責任があるとはいえ、ユーザ側もシステムの機能だけでなく、目的や意図が何なのかを伝えることですね。そのシステムがあることで誰がどう幸せになるのか、そのイメージを共有することが大事です。
アジャイル開発がITプロジェクトの成功率を高めた？
――ユーザの協力や目的の共有といったことがITプロジェクトを成功に導くとのことですが、他にはどんなことをすればいいのでしょうか。
細川：本書にもありますが、2000年代前半のITプロジェクトの成功率は3割ほどでした。これが2014年になると7割ほどの成功率に上がります（日経コンピュータ 2014年10月16日号）。何が原因なのかと何人かに訊いたところ、推測ですが、アジャイル開発が大きいのではないかという話になりました。
ユーザとベンダが、エンドユーザも一緒になって実際の業務を想定しながらああでもないこうでもないと開発を進めるプロジェクトが増えたので、ウォークスルーが自然と行われるようになったんでしょうね。そうしたやり方はウォーターフォールだと難しいと思います。
――要件定義もアジャイル的にやったほうがいいですか？
細川：主要な要件は最初に決めるとしても、細かいところや異常系についてはアジャイルの中で見つけていくのがいいですね。けっこう泥くさいですが、それはそれでうまくいくみたいです。いきなり完成品を作るのではなく、早めにものを見せるテストファーストという考え方も必要です。
このようにアジャイル開発はITプロジェクトを成功させる方法の一つだと思いますが、より重要なことは、ユーザだから、ベンダだからといった立場に囚われず、バッジを外して話し合うことです。
要件定義をするとき、あるいはリスクや課題が見つかったとき、一つのテーブルに出してみんなで話し合う。そして、それぞれが何をやるべきかを明確にします。責任の所在と役割分担は別なんですね。課題解決には誰が適任なのかは都度検討する必要があります。
要件の不備、技術的に困難、外的な要因など、問題は必ず出てくるでしょう。しかし、全員で話し合う場があれば、何らかの次善策が生まれるはずです。「やばいやばい」と隠し合っていると絶対にあとで紛糾してしまいます。
また、プロジェクトを中止するといった、現場では判断できない大きな問題の解決方法についてもステアリングコミッティ（運営委員会）を設置して対策しておきましょう。ユーザ側はプロジェクトの生殺与奪を判断できる人、ベンダ側は仕事を続けるかどうか経営的な判断のできる人が出てきてくれるといいですね。重大な問題が起きたら、その人たち同士で話し合ってもらうんです。
そしてもう一つ、リスクへのアンテナを立てておくことです。問題が起きたとき管理するのは当たり前ですが、起きる前に予兆をリスクとして管理しておくんです。
たとえばベンダ側が、ユーザ側の中心人物が定例会に出席しなくなってきたことに気づいたとしましょう。もしかしたら肝心なときに出席してくれないかもしれません。そんなとき、ベンダはユーザにきちんと状況を確認します。「最近忙しくて」と言われたら、代わりの人を立ててもらわないといけません。
あるいは、開発現場の空気が悪くなってきたと感じたときも要注意です。とあるIT会社の品質管理担当者は、毎日職場で出る空のペットボトルを数えていたそうです。通常は5、6本で、プロジェクトが進むと数十本になっていたと。これはメンバーが疲れてきている証拠なんですね。だとすれば、納期が遅れる可能性があるかもしれません。
プロジェクトの進捗に関しては、ファイル更新の時間帯をプロットすることでリスクを見つけ出すこともできます。ファイル更新が深夜に多かったり、ある時間帯に集中していたりすると危ないですね。前者は残業しているからですし、後者はやっつけで一気にやっている可能性が考えられます。
定量的な部分はもちろん、雰囲気を察知することも含めて、リスクに対する感度を上げておいてほしいですね。杞憂に終わることはありますが、問題が起きてからでは遅いですから。
諦めている人へ
――最後に、本書はどんな人に読んでもらいたいですか？
細川：一言で言うと、「諦めている人」。ITプロジェクトなんてこんなもんだ、失敗して当たり前、ユーザとして責任を果たしきれない、要件定義にないから作らなくていい――そんなふうに諦めてしまっている人たちに読んでもらいたいです。
本書を読むと、諦めたら大変なことになると、嫌というほどわかると思います。I紛争事例の紹介だけでなく、そこから何が学べるかも詳しく書いていますから、自分たちの側でどれくらいのことができるか検討してみてください。
教科書どおりにはできません。ただ、全部はできないとしても、最低限どこまでやればいいのかの参考になるはずです。
