契約書はコミュニケーションのためのプロトコル

提案では、

「営業が主体的に顧客に要件を伺い、提案支援をするエンジニアが技術的な要件から提案仕様、前提条件の列挙と工数を弾き出し、利益を勘案して営業が値付けをし、顧客と契約する。」

というのが乱暴だけどSIビジネスにおける契約プロセスの概要と言って良いと思いますけどんなもんでしょうね。各社の営業体制でだいぶ違うかもしれませんけど。

このプロセスを見たとき違和感がなければ、それは今まで幸せだったか、若しくはずっと騙されているかのどちらかではないか、と。何に違和感、いや、危機感を持たないといけないのかというと、エンジニアが作成する資料は営業に挟まれていて、最終的に顧客と取り交わす契約書は契約した後でないと見る機会がないかもしれないという点なんですが。

「え？営業が作成する契約の内容は営業マターだろう？」とか「なんで営業を疑わないといけないの？」って思ったら、だから、先に書いたように「今まで幸せだった」か「ずっと騙されていたか」なんですよ。

実際、見積もり前提を勝手に書き換えられたことがあるもの。そればかりが原因ではないけれど、大分苦労しました。

契約書は誰でも最初はわからないから
「契約書」と聞くと「難しそう」とかエンジニアには「関係がない」なんていう人もいるかもしれないけれど、「難しくはない」し、エンジニアに「関係がないなんてない」し。

だって、技術仕様とか前提条件とかは大抵エンジニアが書くか、そのネタを渡しているんですから。まぁ、エンジニアから営業になった人もいるからそうすると営業が書くかもしれないけれど、エンジニアのアセスを受けないとかありえないでしょうし。あったら怖い。

契約書が「難しい」と思っている人こそ、一度、ちゃんと「契約書」がどんなものか読ませてもらおう。1つ2つ読んでもわからない言葉が多いかもしれないけれど、わからない言葉は、周りの人に教えてもらったり、ネットでも調べよう。

契約書は戦うためにあるのか
契約書と聞くと「裁判」でもするのか？って思うかもしれないけど、それは最後の手段。先ず契約書に書いてあることをザックリ並べてみると、

契約者
金額
契約形態
契約内容
契約条件

てところ。エンジニアが気にするのは契約形態、契約内容、契約条件の3つ。契約形態は、準委任契約や請負契約などの契約の形態を明示的に示すもの。契約内容には、SIなら提案するシステム仕様など。契約条件は、提案するシステム仕様の前提としていることや工数を見積もったときの制約などの条件が書いてあるんだね。

3つを気にしないといけないのは、自分達エンジニアが顧客から契約したお金をもらうために実現しないといけない仕事のことが書いてあるから、なんだね。だから、知っていないといけないわけで。約束を守る「約束」そのもの。それを知らずして何を作るというのか、って思っちゃいます。いやいや、「プロマネだけが知っていればいい。」って思うかもしれないけど、そんなことないよ。開示していい範囲には開示すべき情報の範疇だと思う。だって、直接顧客から要望を聴くのはエンジニア自身なのだから。

だから、提案した契約内容からプロジェクトを進めていくと実は違ったものが欲しかったとか、そんな要望は見積もりの中に入っていない、とか相互に思いがずれていくことがある、というかずれていくのは子細を詰めていけばいくほど出来上がるものが具体化されイメージアップされるから。

そのとき、揉めるのではなくて今の契約条件はコレコレだけど、ここまで来て変えるならこれからコレだけ費用が掛かります、とか、前提とする仕様条件と違うのでサーバが足りなくまります、とか、あーだこーだと話し合いの席に着くため顧客とSIerのプロトコルなんだと。そう思うと、プロトコルだと思うとエンジニアとしては知っておかないと。で、顧客と「契約した当時の『私たち』はこう約束したんでしたね。」と。

契約書は、コミュニケーションのためのプロトコルの一面を持つんですねぇ。