役割分担表では「問い合わせ対応」のみですが、実際は全面協力してくださいね。ベンダーなんだから:「訴えてやる!」の前に読む IT訴訟 徹底解説(34)(3/3 ページ)
IT紛争解決の専門家 細川義洋氏が、IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回は、ユーザーとベンダーの間で交わした「役割分担表」にまつわる訴訟を解説する。
裁判所は「備考欄」に注目した
判決の続きを見てみよう。
東京地方裁判所 平成22年12月28日判決から(続き)
(1) 本件「プロジェクト計画書」および本件「要件確認書」には、「システムテスト」の項目において、ユーザーの担当の欄には主担当を意味する「◎」印が記載されているのに対し、ベンダーの担当の欄には「○」印が記載されており、また、備考欄に「お客さまに実施していただきます」「ベンダーはテスト実施における問い合わせ対応」「システムテスト:1日」「本番リハーサル:2日」と記載されていることが認められ、これらの事実に照らせば、システムテスト・本番リハーサルはユーザーが主担当として行うべき作業であって、かつ、合計3日程度で終了する作業であったこと
(2)ベンダーは、(中略)ユーザーからテストシナリオを受領し、確認するとともに、(中略)ユーザーがテストを実施したことを確認し、ベンダーは、ユーザーのシステムテストの問合せ対応を(中略)行ったことが認められ、これらの事情に鑑みれば、ベンダーが本件導入支援業務契約上担当する作業は一応終了したものといえるから、システムテスト・本番リハーサルが終了していないとしても、当初予定された最後の工程まで一応終了したものといえる。
裁判所は役割分担表の備考欄を吟味した上で、ベンダーに有利な判決を下した。
たとえ備考欄であっても、「具体的な作業」と「日数」を明示していたことが、ベンダーを救ったのだ。役割分担表の「支援」が「何を意味するものなのか」まで書いたのが功を奏したということだ。
双方が都合の良い解釈をしない役割分担表の書き方
1ページ目で例示した役割分担表の備考欄に「あまり良くない例」と書いたが、それはこの表の中に「支援」という言葉を使っているからだ。「支援」という言葉を使ってしまうと、双方が都合よく解釈し、後になって内容を巡って争う原因になってしまう。
では、どのように書くべきなのか。
答えは、そう難しいものではない。「支援」と言う言葉を使わず、おのおのが行うべき「具体的な作業」「成果物」「期限」を明記すればよいのだ。
また、タスクを分解し、それぞれに責任を明記することもおススメする。1つのドキュメントをお互いが協力して作成する場合だったら、「作成」「レビュー」「修正」を別の作業として書くのだ。サンプルを示そう。
作業大項目 | 作業 | 成果物 | 担当 | 期限 |
---|---|---|---|---|
要件定義書作成 | エンドユーザーへの要望ヒアリング | 要望一覧書 | ユーザー鈴木 | 2017/1/31 |
要件定義書 1章記述 | 1章 ver0.1 | ユーザー今野 | 2017/2/14 | |
要件定義書 2、3章記述 | 2、3章 ver0.1 | ベンダー山本 | 2017/2/14 | |
要件定義書レビュー | レビューシート | ユーザー鈴木 | 2017/2/21 | |
要件定義書修正・統合 | 要件定義書ver0.2 | ベンダー山本 | 2017/2/28 |
このように「成果物を軸」に「担当者名」も加えると、役割と責任がハッキリする。少なくとも、今回の事件のように支援という言葉をユーザーが都合よく判断するようなことはなくなるはずだ。ベンダーの都合の良い判断もできなくなるが。
このような記述をプロジェクトの工程計画を立てる時点(プロジェクトの開始時点や前工程の終了時点)で書き出すことには別の効果もある。
1つ1つの作業と担当を具体的にしていく中で、「作業者に必要なスキルや時間があるのか」「工数のバランスは良いか」などを確認できるのだ。ユーザーとベンダーが具体的な作業と成果物をイメージしながら役割分担表を作ることは、プロジェクトの「品質向上」に寄与するのだ。
「準備7割」という言葉がある。「物事を始める前に準備が完璧に整っていれば、作業の7割方は済んだようなものだ」という意味だ。
プロジェクト開始時点、工程の開始時点では詳細な作業をイメージできず、つい大まかな作業のみ定義しがちだが、この例のような表を作り「皆」で見直すことはプロジェクトを成功に近づける秘訣(ひけつ)といえよう。
細川義洋
ITコンサルタント
NECソフトで金融業向け情報システムおよびネットワークシステムの開発・運用に従事した後、日本アイ・ビー・エムでシステム開発・運用の品質向上を中心に、多くのITベンダーおよびITユーザー企業に対するプロセス改善コンサルティング業務を行う。
2007年、世界的にも希少な存在であり、日本国内にも数十名しかいない、IT事件担当の民事調停委員に推薦され着任。現在に至るまで数多くのIT紛争事件の解決に寄与する。
書籍紹介
プロジェクトの失敗はだれのせい? 紛争解決特別法務室“トッポ―"中林麻衣の事件簿
細川義洋著 技術評論社 1814円(税込み)
紛争の処理を担う特別法務部、通称「トッポ―」の部員である中林麻衣が数多くの問題に当たる中で目の当たりにするプロジェクト失敗の本質、そして成功の極意とは?
「IT専門調停委員」が教える モメないプロジェクト管理77の鉄則
細川義洋著 日本実業出版社 2160円(税込み)
提案見積もり、要件定義、契約、プロジェクト体制、プロジェクト計画と管理、各種開発方式から保守に至るまで、PMが悩み、かつトラブルになりやすい77のトピックを厳選し、現実的なアドバイスを贈る。
細川義洋著 日本実業出版社 2160円(税込み)
約7割が失敗するといわれるコンピュータシステムの開発プロジェクト。その最悪の結末であるIT訴訟の事例を参考に、ベンダーvsユーザーのトラブル解決策を、IT案件専門の美人弁護士「塔子」が伝授する。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- 契約では「設計以降」をお願いしていますが「要件定義」もやってくださいね。下請けなんだから
東京高等裁判所 IT専門委員の細川義洋氏が、IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回はパッケージソフトを使った開発のトラブルを解説する。契約にない「要件定義」をパッケージベンダーはするべきなのか? - 定形外業務も自主的に調べるのがベンダーの努めです
今回は、契約内容に盛り込まれていない「オペレーターがデータベースを直接操作する機能」が実装されていないと支払いを拒否されたベンダーが起こした裁判を解説する - ベンダーはどこまでプロジェクト管理義務を負うべきか
プロジェクトを円滑に推進し完遂するために、ベンダーはどのような活動を行う義務があるのか。ある裁判の判決を例に取り、IT専門調停委員が解説する - 検収後に発覚した不具合の補修責任はどこまであるのか
ユーザー検収後に発覚したシステム不具合を補修をめぐる争いで、裁判所が1724万円の支払いを命じたのは、ユーザー、ベンダーどちらだったのか? - 最低限の知識も理解もないユーザーと渡り合うには?
「出荷管理をシステムを発注したにもかかわらず、勘定科目を把握していない」「意見を社内でまとめず、五月雨式に投げてくる」「モックを本番と勘違い」――こんなユーザー、あなたならどうする?
関連リンク
- 美人弁護士 有栖川塔子のIT事件簿 バックナンバー一覧
要件定義が固まっていない、途中で追加や変更が頻発して大混乱――開発プロジェクトで起こりがちなトラブル事例の対応法を、IT訴訟専門の美人弁護士「塔子」がビシビシと伝授します。 - @IT自分戦略研究所 FBページ
- @IT自分戦略研究所 Twitter
- @ITのメールマガジン