システム開発の契約の流れ ～ 現場目線で超ざっくり解説します

「契約」と聞くと、ちょっと堅苦しく感じるかもしれません。
でも、システム開発の現場では、契約手続きもプロジェクトをスムーズに進めるための大切なプロセスです。

この記事では、これまで外注を経験したことのない発注者の方はもちろん、
契約手続きに関わったことがないエンジニアの方にとっても参考になるように、基本的な流れやポイントを紹介します。

実は、こうした「取引の流れ」を理解しておくことも、ビジネスマンとしてステップアップするうえでの重要な要素だと思っています。
ですので、契約手続きをしたことのないエンジニアの方も「開発だけわかればOK！」ではなく、ぜひ「契約」「商取引」についても知っておいてほしいなと思います。

システム開発の契約手続き ～ ざっくり全体像

当社では、基本的には以下のような流れで契約手続きを進めています。
この流れがすべての企業に共通するわけではありませんが、一般的な商習慣にも沿った基本的なフローとなります。

この時点では、以下を補足しておきます。
　・NDA ： いわゆる「秘密保持契約」の略称です
　・NDAおよび基本契約書 ： 通常は2部ずつ製本し、双方がそれぞれに押印した上で、1部ずつ保管しておきます
　・請書と納品書 ： すべての取引で必ず発行しているわけではなく、取引先の運用方針等により柔軟に対応しています

NDA（秘密保持契約）～ まずはココからスタート

（発注側）「まずは話を聞いてほしい。でも社内情報を話すのはちょっと…」

そんなときに大切なのがNDA（秘密保持契約）です。
当社では、商談に入る前にお客様とNDAを締結させていただいています。

なぜか？
それは、お客様の情報を守るのはもちろん、
「安心して情報を共有し合う、具体的な話をする」
ためです。
正直に言うと、NDA締結を渋る企業様がいると、「セキュリティ意識、大丈夫かな？」と少し不安になります…。

なお、NDAや後述する基本契約書などは、発注側の契約書式ベースで契約内容を調整することもあれば、弊社の書式ベースで調整することもあります。
実際に、「書類の扱いが不慣れで…」というお声をいただくことも多く、そういった場合は書式の提供や記入例のご案内なども行っています。

開発のご相談段階では、業務上の機密事項を含むお話をすることが多くなりますので、双方の信頼関係のうえで安心して情報を共有し合えるよう、この手続きは非常に大切にしています。

基本契約書 ～ 土台をしっかり固める

NDAを交わし、商談が進みそうであれば、次は基本契約書を締結します。
これは、今後の取引をスムーズに進めるための「土台」となる契約です。

• 取引の基本ルール（支払い条件、納品や検収の定義など）
• 損害賠償や契約解除などのリスク対応
• 知的財産の帰属

など様々な条項を事前に明文化しておきます。

基本契約の締結時に「御社のひな形でお願いします」と言われることもありますが、実際には、どちらの雛形であっても、法務部のチェックが入ることが多いかと思います。
特に「損害賠償」については、お互いのリスクに直結するので時間をかけて慎重に調整していく必要があります。

正直、大きな事業に関わる場合など
「この内容ではウチ、責任負いきれません（倒産しちゃいます…）」
みたいなケースも多いに起こり得ることがあるため、数回の“法務ラリー”が発生するのは「あるある」なのではないでしょうか。
でもそれだけに、きちんと事前合意することが、信頼関係のスタートでもあります。

なお、NDAと基本契約書は初回取引時に締結するのが一般的で、その後の取引では省略することができます。
ただし、企業の状況や時代の変化、法改正等により、契約内容の見直しが必要になる場合があります。
その際は、必要に応じて新たな契約内容で再締結を行うこともあります。

見積書

商談が順調に進み、提案可能な段階になったら、次は（提案書と）見積書のご提示です。
「この内容なら、このくらいの費用でできますよ」
と伝えるための書類です。
システム開発は、やることによって手間も金額も大きく変わるので、お互いの認識を合わせるためにもとても大切です。
松竹梅と複数パタンの見積書を発行することもあります。

要件が固まっていない段階では、システム開発全体の費用を算出できないため「要件定義フェーズのみ」の見積書を先にご提示するケースもよくあります。
また、お客様側で予算が決まっている場合は、その範囲で実現できる内容をご提案したり、優先順位をつけた段階的な要件整理を行うことも可能です。
あらかじめご予算の目安をお伝えいただけると、より現実的で価値ある提案につなげることができます。

注文書と請書

ご発注の際は、注文書を発行していただきます。
「この見積もり内容で正式にお願いします！」
という意思を、発注側が書面で伝えるものです。

この注文書は、受注側にとってはとても重要な書類です。
なぜなら、注文書を受領してはじめて、正式に着手できる、からです。

注文書の書式についてもこちらで用意することは可能です。

またこのとき、請書（注文請書）をご希望される場合には当社から返送します。
ただし、すべてのお客様が請書を求めるわけではないため、「特に要望がなければ発行しない」という運用にしております。

なお、取引先の意向により「注文書」ではなく「個別契約書」という書類を交わすこともあります。

システム会社への発注のポイントが知りたい方はこちらをご覧ください。

納品書

「約束したモノを確かにお届けしましたよ」という書類です。
が、当社では「納品書」は基本的に発行しておりません。
他の書類（検収書等）や手続き（発注側のクラウド上に成果物を管理している等）で代替できるためです。
もちろん、発注側に要望された場合は発行しています。

検収書 ～ とっても大事

納品後は、お客さまには納品物に問題ないことを検収（確認）していただきます。
お客様内にて、納品物の漏れや内容・動作確認をしていただき、問題がないようであれば検収書を発行していただきます。
検収書は、納品された成果物に対して、発注側が「内容確認しました。問題ありません。」とOKを出す書類となります。
この受け渡しがあることで、納品の事実と、お客様の確認完了が明確になります。

ただ、プロジェクト（ビジネス）としては、スタートラインに立った状況であることは忘れないでください。

請求書 ～ 検収が終わらないと発行できない

検収が終わったら、受注側から発注側に対して「お支払いをお願いします」と出す書類が請求書です。
あまり説明する必要ないかなと思います。
「検収が終わらないと請求ができない！」
ということだけは頭に入れておいてください。

それと支払いサイトは企業ごとに異なるため、事前に確認しておいてください。
「支払いサイト」とは、請求書を発行してから実際にお金が支払われるまでの期間のことです。
たとえば
「月末締め・翌月末払い」
であれば、月末に請求書を出して、翌月の末日に支払いがされる（＝30日サイト）ということになります。

まとめ

契約や書類の流れは、営業担当や事務担当だけが押さえておけばいいものではないと思っています。
プロジェクトに関わるすべての人にとって重要な位置づけとなるものです。

特に開発現場に立つエンジニアにとっては、
「なぜ着手できないのか」
「なぜ検収が必要なのか」
など、契約の流れを理解していれば、こうした状況も理解できるかと思います。

また、エンジニアにとっては、こうしたビジネス上の流れを理解していることが、視野を広げる一歩になります。
技術力だけでなく、状況の把握や提案力といった「ビジネスの基礎力」を伸ばす上でも、大きな意味を持つはずです。

そして発注者の方々にも、こうした契約書類の流れを一通りご理解いただけると、受注側の動きや制約にもご理解いただけるのではないでしょうか。
「なぜこの書類が必要なのか？」
などが共有できれば、スムーズにやりとりできますし
お互いの立場やリスクを尊重しながら、しっかりと土台を整えておくことで、その後のプロジェクトも安心して進めることができます。

「契約は難しそう」「書類は面倒そう」――そう感じていた方こそ、まずは今回ご紹介した流れを知ることから始めてみてはいかがでしょうか。

さいごまでご覧いただきありがとうございました。