ソクラテスになれ――無知なユーザーとの仕事の進め方（後編）：「訴えてやる！」の前に読む IT訴訟徹底解説（13）（2/2 ページ）

» 2015年02月19日 18時00分公開

ユーザーに要件変更を繰り返させぬようベンダーができること

　プロジェクト成功のために、ベンダーがユーザーに対してできる協力には、この判決に見られる要件定義以外にも、プロジェクト実施中の管理や受入テストなどあるが、今回は、要件定義にポイントを絞りたい。何といっても、失敗したときの損失が他の工程や管理よりもはるかに大きいからだ。

1　ユーザーの業務知識不足と意見不統一への対応

　まず、ユーザーの知識不足についてだ。システム化しようとする業務がどのようなものであり、業務用語としてはどのようなものがあるのか、さらに、現状の何が不満で、どこを変えたいのか、これらの知識が不足していては、まともな要件定義はできない。また、人によって、これらについての知識や意見が異なることもよくあるが、そうした場合も、よく似た結果が出る。後になって要件がひっくり返されたり、役に立たないシステムを作ったりする、ということだ。

　こうした危険を防止するためにベンダーに求められる態度、それは「ソクラテスになること」だ。

　ソクラテス本人のように「ギリシャの広場で誰かれ構わず捕まえて」とまではいかないが、ユーザー内部のさまざまな人に、業務プロセスや用語、システムに求める機能についてしつこく聞いて回り、少しでも分からないことがあれば、分かるまで食い下がる。要件定義といえば、ユーザーが内部でとりまとめたものを一本化された窓口から責任を持って伝えるのが正論だが、今回の例のようなユーザーの場合は、そうもいかない。自分で聞いて回り、それを基に仮で作成した業務フロー、データフロー、用語集を持ってまた回る。

　こうしたアクションを繰り返すことにより、ベンダー自身も知識を蓄えられるが、問いに答えるユーザーも、自分の分からないことや知らないこと、他人と意見が合わないことに徐々に気付いていく。「無知の知（己の無知に気付くこと）」というわけだ。

　その後、話を聞いた人を一か所に集めて、全体でレビューをしてもらう。表面上はレビューだが、実際はユーザーに認識の不統一や知識不足に気付いてもらう会議だ。「えっ、そうなの？これって、そのためにやるんだ」「じゃあ、この要件はやっぱり必要だね」とユーザー同士で会話をするうちに、ユーザー内部の意見と知識、認識を統一できる。

　もちろん、こうした作業を行えば、通常より多くの時間や労力がかかる。しかし、後続工程での手戻りを考えれば、必ずメリットがあるはずだ。

2　ユーザー担当者の退職、異動と引き継ぎ不足への対応

　プロジェクト中にユーザーの主要メンバーが退職あるいは異動でいなくなってしまうこともよくある。ユーザー内部で要件や前提条件、制約事項や、その経緯などを引き継ぎしてもらわないと、今回の判例のケースのように、もう一度要件検討が始まり、それまでに決まったことや作ったものを全てひっくり返されることにもなりかねない。

　鍵を握るのは「プロジェクト承認者」だ。プロジェクトの目的を把握し、予算を握り、場合によっては要件やスケジュールの変更を承認できる存在で、最悪の場合プロジェクトの中止を判断できる立場でもある。

　皆さんのプロジェクトにはユーザー側にこうした人がいるだろうか。いないようであれば、それ自体がリスクである。

　去っていく人間は当事者意識が薄れる。引き継ぎも、取りあえず後任者が困らない最低限の知識にとどめることが多く、自分と全く同じ知識や認識を持ってもらうことまでは考えないし、現実的にそれは無理だ。

　一方、後任者はどうしても知識が不足する。今回の判決例では、後任者がそれまでの要件を理解せず、納得もできなかったため、新たに要件を検討した。ベンダーにとっては、「いい迷惑」と言わざるを得ないだろう。

　ベンダーはこれらに備え、決まった要件やその経緯について、プロジェクト承認者に当たる人間に常時伝え、その承認を得ておくべきだ。

　プロジェクト承認者がいれば、突然ユーザー側担当者が交代しても、主要要件やその決定経緯などについて後任者に伝えられる。また、後任者にやってほしいことや、やってはいけないことも、承認者の権限を持って指示できる。少なくとも、後任者が勝手にそれまでの経緯を無視して要件検討をやり直す、などという愚は起きないはずだ。

　もちろん、通常は上級管理職がプロジェクト承認者の任に当たり、詳細な要件や設計までは把握していないことも多いだろう。しかし、主要な上位要件とその経緯、システム化の目的や前提条件、制約条件くらいは把握できているはずだ。後任者にこれらをしっかりと示せれば、後のことは後任者自身が勉強するはずである。

　ベンダーは、プロジェクト計画の段階から、ユーザーにアドバイスし、プロジェクト承認者を立ててもらい、自ら要件検討の経過や結果を伝達して承認をもらう活動をし続ける必要がある。

　今回は少々テクニック論に偏ってしまったが、いずれも、私や私の周りの人が現実のプロジェクトで実施し、それなりに効果を挙げたやり方である。

　もちろん、そのまままねる必要はないし、全てのプロジェクトにうまく当てはまるとも限らない。要はユーザーに自分の無知を気付いてもらうことだ。業務知識にしても、上級管理職の責任にしても、ベンダーが何も言わなければ、ユーザーはその欠如に気付かない。それを気付いてもらうことが、ベンダーの専門家責任の最たるものであり、気付きさえすれば「後はユーザー次第である」と胸を張って言えるのだ。

「「訴えてやる！」の前に読む 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の最終セッションは、雪の寒さとは違う意味で会場を震え上がらせた。