未契約のまま進めたプロジェクトが途中で頓挫。「お金は払いません」は通用するのか
システム開発のプロジェクト活動は、言ってみれば長い長い距離を走るマラソンのようなものです。
しかし本物のマラソンは選手が１人でゴールを目指し、ペースを上げるも落とすも、あるいは体調に異常を来して途中でレースをやめてしまうも、全て走っている本人が判断できます。
けれどもシステム開発においては、ユーザーとベンダーが協力してゴールを目指すため、マラソンと言うよりは
お客さまとの間では「二人三脚」
メンバー間の中では「ムカデ競争」
のようなとても大変な関係を築くものになっています。どちらかが勝手にペースを変えたりレースをやめたりしてしまうわけにはいきません（まぁ、自分たちの都合でコロコロ変えようとするのは、ユーザー側だけでなくベンダー側にもあることですが）。
ゴールを目指して一生懸命足を動かし続けているにもかかわらず、一緒に走っているパートナーが突然足を止めたら、走り続ける選手は転ぶかもしれません。二人三脚やムカデ競争を思い起こしてください。容易に想像できるはずです。
場合によっては大ケガをすることもあるでしょう。
同様に、システムの完成を目指して一生懸命作業をしていたベンダーに、ユーザーが突然プロジェクトの中止を申し入れると、ベンダーは財務的な痛手を被ることがあります。と言うか、大抵タダではすみません。
このとき、ユーザーとベンダーの間に正式な契約があれば、ベンダーはユーザーの一方的なプロジェクト中断を糾弾し、損害賠償の請求などを求めることができます。
しかし、正式な合意がない場合は、どうなるのでしょう。
システム開発プロジェクトはしばしば、正式な契約を後回しにして作業を先行させてしまうことがあります。
以前在籍していた会社でも「先行受決」と言って、受注が確定していないけれども契約を発行し、リスクを負いながらもプロジェクトを開始することがありました。その前にいた会社でも、呼び方は違えど「プレオーダー」と呼んで受注確定前に（内示も受け取っていない状態で）開発を開始することがありました。
もしも、そのプロジェクトが途中で頓挫してしまったら、ベンダーはユーザーに何らかの補償を求められるのでしょうか。以下は、ユーザー上層部の指示で開発が突然中止になった事件です。
事件の争点は「基本設計フェーズ2の契約が成立していたか」になります。
司法は、「法」を元に裁可を下しますので、この場合ですと民法632条を中心に話が進むことになります。
契約書こそ交わされていませんが、ユーザーとベンダーの間に「実質的な合意があった」と認められれば、ユーザーに代金の支払いが命じられるかもしれません。
そもそも「親会社の承認が得られない」という理由は、ベンダーには到底納得できないものであり、契約準備段階の不備ともいえます。
ただ一方で、「契約書がない」ことも事実であるため、決して強気に「うちは悪くない」とも言えません。
両者は「作業内容」についてはおおむね合意している。
しかしユーザーは「作業着手」には合意したものの、「費用」については合意がなく、実質的に契約があったとまではいえない状況だった。
契約がなければ、債務を履行する（代金を支払う）理由はない
――ユーザーは、こう主張をして支払いを拒んだと言います。事件の経緯だけを追うと、ベンダーの主張の筋が通っているように思えます。
しかしユーザーは、ベンダーが作業に着手する前に契約には親会社の承認が必要であることを伝えていました。現場での会話では次フェーズの契約を拒まれることなど感じられなかったのかもしれませんが、それでも「親会社」というキーワードが出てきた際には、何らかのリスクがあることを考慮しておくべきだったかもしれません。
少なくとも『リスク対策を怠った』分については、ユーザー側への情状酌量が与えられることになるでしょう。
では、判決はと言うと、
裁判所はベンダーの主張を認め、ユーザーに支払いを命じた形となりました。至極まっとうな判決だと感じます。
いくら正式な書面がなくても、
現場で次のフェーズを期待させる「言動」がなされ、
実際、ベンダーが作業をしているのを「認容」、
つまり作業をしていることを知りながら、これを「黙認」していた
と言うのであれば、突然のプロジェクトの中止はユーザーの信義則違反であり、損害賠償の対象となるのは当然と考えてしまいます。
裁判所における他の判決を見ても、この
「作業をしているのを知りながら、これを黙認している」
というユーザーの行動は、事実上の発注と捉えられる
可能性が非常に高いことがわかります。一度判例として認知されたためか、「突然中止すれば信義則違反となる」という考え方は司法の世界では珍しくなくなっています。
実際には、ベンダー側は請求額の７割程度しか回収できませんでした。
やはり、リスク対策が万全ではなかったからです。
裁判所は判決文で、
「正式な発注がないのであれば、それを求めたり
作業を中止したりするなどの損害防止策をとるべきだった」
と言っています。そうしたことをしていなかった、いわば「不作為の代償」が「３割」の回収不可という結末だったといえるでしょう。ちょっとリスク対策を怠れば、それだけで3000万…そこそこの家が建つ額を失うことになるのです。
リスク対策がどれだけの額に、どれだけの人に影響を与えるのか、よくわかります。だからリスク対策をナメてかかる人は信用できないんですよね。
実際「発注はまだか」と“お客さま”に申し入れても、「稟議が……」「手続きが……」となかなか進めてくれないことは多いものです。そうしている間にも納期が迫ってくるので、作業を止めるわけにもいきません。
ましてプロジェクトを中止するなど、現場の判断でそうそうできるわけではありません。かと言ってそのまま続けていたら、会社の上役から「契約はまだか」と突かれるわけです。
こういう板挟みになった時は、本当に神経を削ります。
ならば、どうすればいいのか。
第一に、
「案件を受注するとき、契約書を取り交わすまでは、
必ず「複数のルート」でユーザーの発注意志を確認しておくこと」
です。一般的には内示書をいただいておくというものですが、正式な書面でなくてもかまいません。信義則違反を侵された場合に問いただせるエビデンスであればいいのです。
たとえば、メールであってもいいでしょう。
今回のケースでもそうですが、ユーザーの現場は本気で発注をするつもりでも、経営層や他の関連部門がネガティブなケースというのはままあることです。
問題の本質は、ユーザー企業内でしっかりと合意形成を図る段取りが行われていないまま、勝手に暴走している現場担当者にこそ原因があるのでしょうが、それがきっかけでプロジェクトが中断してしまうことは少なくありません。
むしろ、そういうケースは私たちベンダー側の人間としては、「当然、想定しうる可能性」として上位にランクインしていなくてはおかしいと言うモノです。
企業にもよりますが、こうした確認は営業の役割となっていることが多いでしょう。
現場のエンジニアも、ユーザーのできるだけ多くのルートから発注意志に関する情報を集める姿勢が必要となります。ですが、エンジニアは「プログラミング」を主体とした技術さえあれば一人前だと思っているし、そこから叩き上げで育ってきたマネージャーにこうした契約を挟んだ各企業間の思惑や背景に注意しろと言っても、なかなか難しいものです。
会社として正しく教育・育成ができないのであれば、１度目の失敗（何千万、何億の赤字になるかわかりませんが）は目をつぶるくらいの覚悟が必要かもしれません。
第二は、
「ステアリングコミッティを組成すること」
です。『ステアリングコミッティ』とはなかなか聞きなれない言葉かもしれませんが、要するにプロジェクトの運営を行う運営委員会のことです。
前述した通り、プロジェクトの中断は現場のプロジェクトマネージャーには判断できません。そうした際に発生する損失を受け入れられるか、あるいは損失が出ないように相手側の経営陣と交渉ができる人間（多くは自社経営層）を立て、ユーザーのしかるべき人間といつでも話し合える体制を作っておくことが重要です。
第三は、
「多段階契約を結ぶこと」
です。私が過去に経験してきた中でも、大規模なプロジェクトでは特に問題があったわけでもないのに、１つのプロジェクトが複数の契約に分かれていることがありました。
これは、双方の被害額を大幅に抑えるための施策と言っていいでしょう。
今回の事件についても、工程ごとにフェーズを設ける多段階契約を結んでいたため、ベンダーの被害額がある程度抑えられたといっていいのではないでしょうか。
もしこれが一本の契約になっていたら、第1フェーズからの作業費用全てを回収できなかったかもしれません。
私が記憶する中でよくやっていたのは
①仕様が確定（凍結）するまでをSES（準委任）契約
②仕様が確定してから結合テストまでを請負契約
③システムテスト以降をSES契約
としていました。今でこそIPA（一昔前は経産省だったかな？）で定義されている契約モデルでもそうすることが推奨されていますよね。ひょっとすると私が経験した90年代後期の頃には、まだ国からのそういった指定は無かったかもしれません。
多くの大手IT企業でも同じ方法をとっていると思いますが、大手IT企業の場合は
①～要件定義までをSES（準委任）契約
②基本設計～結合テストまでを請負契約
③システムテスト以降をSES契約
とするのが一般ではないでしょうか。
私の場合は、①から②への境界線を『工程』ではなく『仕様の確定度合い』で区切るようにしていました。必ずしもすべてが確定している必要はありませんが、課題管理上でも管理されないようなふわっとした状態では当然ダメですし、仮に課題管理に載っていても規模感がすぐに変わりそうなものは
・暫定で仕様を仮確定し、規模を算出する
・暫定内容を変更する場合は「変更依頼管理」上で統制する
を行わない限りなかなか請負には進みませんでした。…まぁ、そういうことを知らないし、教えられもしない状態で色々と苦労したことがあるからこそ自分なりに気づき、編み出していった方法なんですけどね。
第四は、
「『正式な契約の前』に、発注書や覚書あるいは議事録などで、
「ある時期までに契約が成立できなければ、
そこまでの費用をいったん精算して、再度仕切り直す」よう
取り決めておくこと」
です。
いったん揉めだしてからでは手遅れです。プロジェクトに着手する「前」にしておくことがポイントで、そこにしかチャンスはありません。もちろんこれらをやる以前に、正式な契約を結べるよう全力を尽くし、それがない限りそもそも作業着手はしないというのが、最もあるべき姿です。
契約とは、発注側にも受注側にも等しく強制力と義務を付加します。
そして、資本主義の基本は、契約によって取り交わされることになっています。契約もしないままに、早々に着手すること自体がイレギュラーな状況と言う感覚まで麻痺させてはいけません。
こうした話をすると、必ず「そうは言っても……」という人が出てきます。
気持ちは分かってあげられますが、だからと言って「何もしなくて不利益を被ることはありませんよ」とは口が裂けても言えません。何もしなければ、不利益を被るリスクが跳ね上がるだけで、それとわかって何もしないのであれば、それはもう自業自得です。外部の人に助けを求める資格すら失うと言うことです。最初から諦めていたのでは何も変わりません。
まずは、理想の姿を目指して最善を尽くすこと。
リスクを踏まえて、それでも問題が起きないように考えられうるすべての手を打っておくことが重要です。誰に向かって言い訳したところで、失敗する事実も、大トラブルになる事実も、大赤字になってしまう事実も、それらを自分の誤った判断によって引き起こしてしまう事実も、何も変わらないのですから。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。