皮肉なことに、プロジェクトと失敗とは相性がよい。納期どおりにできなかった、要求どおりにできないことが多い、機能を削減することが多いなど、もともとの目的、スコープから、後退したプロジェクトの経験を持つITエンジニアは多いに違いない。なぜ目的どおりにいかないのか。どこを改善したらいいかを本連載で明らかにし、処方せんを示していきたい。
プロジェクトの失敗を防ぐために、契約段階で打てる手はいろいろある。しかし、プロジェクトの失敗で責任を取らされるプロジェクトマネージャが契約段階に絡んでいない会社が非常に多い。この契約を、プロジェクトの結果に責任を取らない営業任せにしておくことは、非常に危険である。ほとんどの場合、彼らはひな型どおりの契約をするだけである。
第4回 デフォルトの契約内容は、失敗への招待状
本来は、そのプロジェクトで発生するリスクを想定して、そのリスクを防ぐための条項を契約に盛り込んでおくべきであるが、そこまで考える営業はほとんどいないであろう。
また、標準のひな型が不十分な内容になっている例も多い。A4で3枚ぐらいの簡単な契約書で済ませている会社も多いのではないだろうか。
なぜ、こんな簡単な契約書になっているかというと、日本の契約書は基本的に「性善説」に立っているからである。面倒なことはあまり記述せず、記載されていない事態が発生した場合には、「お互いに誠意を持って話し合う」という条項を入れて済ましているのである。御社でも、そんな条項が入っていないだろうか。
契約書というのは本来トラブルが発生したときを想定して作るべきものである。なぜなら、プロジェクトがうまくいっているときは、契約書を引っ張り出して文句をいう必要はない。プロジェクトで何か顧客ともめたときに、自分の立場を守るために使用するのが契約書であると考えるべきである。そうであれば、顧客と何か行き違いが発生した場合を想定して、契約書を作らないといけない。
欧米に比べて日本の契約書は薄いとよくいわれる。欧米では、何か契約を結ぼうとすると、電話帳のような分厚い契約書が送られることがよくある。この違いは、性悪説の文化と性善説の文化の違いであろう。
しかし、日本も次第に訴訟ざたになることが多くなっている。ITに限らないが、全体の訴訟件数については、裁判所の資料を参考にしてほしい(リンク先はPDFファイル)。いまや残念ながら性善説なんて甘いことをいっていられる時代ではなくなってきているのである。自分たちのリスクを防ぐために、契約書の中に盛り込む内容をよく吟味する必要がある。
経済産業省の情報システムの信頼性向上のための取引慣行・契約に関する研究会が発表した「情報システム・モデル取引・契約書」最終報告書は、システム開発の基本契約書だけで、解説も含めて51ページになっている。解説部分を除いても、17ページぐらいにはなるであろう。本来、システム開発の請負契約書はこのくらいの量は必要なはずである。
日本においては、システム開発にまつわる訴訟の多くが結審に至らず、最終的には和解で終わるケースが多い。この背景として、契約があいまいで裁判でとことん争う根拠が乏しいことが挙げられる。弁護士も争う根拠が不足しているために、早くから和解を進める傾向が強い。このようないざというときに役に立たない契約書でなく、争ったときにしっかりとした根拠を提供できる契約書を作成すべきである。
多くの企業が保持している契約書のひな型は、必要な項目が網羅されていないと思われる。経済産業省の「情報システム・モデル取引・契約書」などを参考に、以下のような項目が網羅されているかチェックする必要がある。
(あ)システム化の範囲(スコープ)が明確に定義されているか
システム化の範囲の認識が異なることがないように明確に定義されていなければならない。通常、このシステム化の範囲は、契約書の中だけで定義することは難しいので、何らかの文書を参照することになる場合が多い。この場合は、いつ作成されたどのようなタイトルの文書かを明記して、解釈が異ならないようにする必要がある。この文書としては、提案書、要件定義書などがある。
(い)要件や設計内容に承認を与える権限者は明確に定義されているか
顧客との打ち合わせに基づいてシステムを開発しても、後から社長が出てきて、それまで打ち合せで合意してきた内容がひっくり返るなんてことはよくある話である。顧客の社長は「契約書に印を押したのは私だ」と主張するであろう。
このような事態を防ぐためには、契約書で打ち合わせなどでの決定事項に承認を与える権限者を明確にしておくことである。打ち合わせの結果を議事録にして、その権限者の承認をもらうことを契約書で明記して、そのとおりに実行すれば、打ち合わせ内容がひっくり返るリスクを回避することができるのである。
(う)要件定義確定時の料金の見直し
本来であれば、要件定義とその後の開発工程は分離した契約にすることが好ましいが、これを一緒にして1つの契約にせざるを得ないことも多い。この場合には、要件定義作業の結果、そのスコープが当初決めた範囲を超えている場合には、料金の見直しができることを明記しておく必要がある。
このほか、チェックすべき項目はまだまだたくさんあるが、「情報システム・モデル取引・契約書」などをきちんと参考にしてほしい。
プロジェクトが異なれば、そこで予測されるリスクも異なってくる。契約書はリスクヘッジの手段でもあるので、契約書の内容もリスクの内容によって異なって当然である。
最初にプロジェクトで発生が予想されるリスクを洗い出し、そのリスクのうち契約書を変更したり、項目を追加することによってリスクヘッジできるものがあれば、ひな型の契約書を変更すべきである。
例えば、顧客から新製品のネットワーク機器を使用したシステムの構築を依頼されたような場合だ。その機器の仕様は、今後公開される予定であり、構築作業がその仕様に依存するとする。このような場合には、その機器の仕様の公開が遅れた場合には、システム開発の納期を延長できることを契約書に明記しておけば、仕様公開の遅れによるスケジュール遅れのリスクを回避することができるのである。
このようにプロジェクトのリスクは、契約書である程度回避または軽減できることを覚えていてほしい。
落合和雄
1953年生まれ。1977年東京大学卒業後、新日鉄情報通信システム(現新日鉄ソリューションズ)などを経て、現在経営コンサルタント、システムコンサルタント、税理士として活動中。経営計画立案、企業再建などの経営指導、プロジェクトマネジメント、システム監査などのIT関係を中心に、コンサルティング・講演・執筆など、幅広い活動を展開している。主な著書に、『ITエンジニアのための【法律】がわかる本』(翔泳社)、『実践ナビゲーション経営』(同友館)、『情報処理教科書システム監査技術者』(翔泳社)などがある。そのほか、PMI公式認定のネットラーニングのeラーニング講座「ITプロジェクト・マネジメント」「PMBOK第3版要説」の執筆・監修も手掛けている。
Copyright © ITmedia, Inc. All Rights Reserved.