【ソフトウェア開発契約書】中小企業やStartupの法務担当者のための注意点｜弁護士監修

中小企業やスタートアップがソフトウェア開発を外部のベンダーに委託する際、契約書をしっかりとチェックすることは非常に重要です。特に、ソフトウェア開発に関する専門的な知識がない場合、どの点に注意すべきかが分かりづらいことがあります。なかでも、最も注意が必要なのは「仕様書」の合意形成です。本記事では、仕様書の合意形成の難しさに注目し、ソフトウェア開発契約書を作成・確認する際に法務担当者が留意すべきポイントについて、契約書自動チェックサービス”Collabo Tips”[コラボ・ティップス]を監修するメリットパートナーズ法律事務所の弁護士が解説します。

ソフトウェア開発の基本的な流れ

ソフトウェア開発は、企業の業務を支援するためのプログラムやアプリケーションを作成する一連のプロセスです。ソフトウェア開発の基本的な流れは以下の3つの段階で進行します。

①システム設計段階（現状分析を含む）：何を開発するか（「仕様」）を決定します。
②プログラミング段階（実装）：①で決めた「仕様」に基づいてプログラミングを行います。
③テスト・移行段階：②で作成したプログラムをテストし、委託者の業務に実装します。

そして、開発が終了した後には、④保守・運用のフェーズが続きます。

ソフトウェア開発の流れ：

①システム設計　→ ②プログラミング　→③テスト・移行　→ ④保守・運用  

重要なポイント:ソフトウェア開発のプロセスの中で、最も重要かつ時間とリソースがかかるのは「①システム設計段階」です。この段階を上流工程と呼びます。上流工程で設計が不適切だと、後々のプログラミングやテスト、運用に大きな影響を与えます。実際、ソフトウェア開発におけるトラブルや裁判に発展する多くのケースは、このシステム設計段階での不適切な設計が原因であると言っても過言ではありません。

システム設計段階の「仕様書」決定の重要性とリスク

「①システム設計段階」で最も重要なことは、「仕様書」の内容を明確に定義し、開発前に委託者と受託者が合意することです。しかし、仕様書の作成はしばしば難しく、認識の齟齬が生じやすいため注意が必要です。

仕様決定が難しい理由

ソフトウェア開発において、仕様決定が非常に難しい理由は以下の通りです：

1. 要件が抽象的
   中小企業やスタートアップでは、業務効率化や改善を目的に開発を依頼することが多く、具体的な機能や要件を明文化するのが難しいことがあります。
2. 業務の変化（時間の経過が原因）
   ビジネス環境や業務フローは常に変化するため、最初に固めた仕様が後々変更されることがあります。
3. 技術的な理解不足
   依頼者が技術的なバックグラウンドを持っていない場合、適切な技術選定や実現可能性を理解できず、仕様に対する誤解が生まれることがあります。

これらの理由により、仕様書作成の際は非常に慎重に行う必要があります。また、仕様変更が発生した場合に契約上でトラブルが起きないよう、仕様変更に関するルールを事前に契約書に盛り込むことが重要です。

仕様決定の齟齬を防ぐための対策：開発方法の工夫

システム設計段階での仕様の齟齬を防ぐためには、開発方式の選択と契約書の記載が大きなポイントになります。特に、「一括請負方式」（全体の仕様を一度に決定し、その後の変更が難しい方式）では、仕様確定後の変更が困難になり、後々問題が発生しやすくなります。このため、契約書段階で仕様に関する詳細な取り決めを行うことが重要です。そこで、一括請負方式を採用する場合の契約書に盛り込むべき項目と、もし一括請負方式が適切でない場合の代替開発方式について解説します。

一括請負方式のソフトウェア開発契約書に盛り込む視点

一括請負方式では、仕様書が最初に確定した後、変更が難しくなるため、契約書において以下の点をしっかりと明記することが重要です。請負契約であるため、受託者は、納期までに仕事の完成義務を負うという点でリスクが大きいといえます。

仕様書の作成・承認プロセスの明記

仕様書を単に「提出する」と記載するのではなく、具体的に「作成」「レビュー」「承認」の過程を明記しておくことが必要です。例えば、依頼者（委託者）がどのタイミングでフィードバックを行い、最終的に承認するのかを契約書に明確に記載することで、認識のズレを防ぐことができます。ただし、これは「言うは易く行うは難し」です。

モックアップ等を活用する

契約締結時点で仕様書を全て決定することは難しい場合が殆どです。そこで、例えば、仕様書決定の前にワイヤーフレームやモックアップ等を作成することが有効です。

• ワイヤーフレーム: Webアプリケーションやモバイルアプリの画面構成を画面遷移を簡素に示したものです。デザインの詳細を省略し、ページや画面のレイアウトや構造、機能の配置を確認するためのものです。
• モックアップ: ワイヤーフレームの進化版であり、システムの外観やユーザーインターフェース（UI）を確認するためのビジュアル的な手段で、デザインに対する認識のズレを減らすのに役立ちます。
• プロトタイプ:プロトタイプは、実際に動作するシステムの一部を簡単に実装したものです。これにより、顧客は「どう動作するか」を体験し、インターフェースや機能に対するフィードバックをリアルタイムで提供できます。

モックアップやプロトタイプは、そのソフトウェアが解決しようとする基本的な機能がどのように動作するかを確認するための手段です。たとえば、会計ソフトであれば仕訳の入力や計算機能、銀行システムであれば振込・決済機能、ゲームであればゲームのルールや進行方法など、ソフトウェアの根幹となる機能（「機能要件」）を視覚的に確認することができます。
契約書でも、モックアップ等を作成し、依頼者にその確認・承認を求めるプロセスを盛り込むと良いでしょう。

非機能要件まで盛り込む

ところで、モックアップやワイヤーフレーム、プロトタイプでは「機能要件」を確認することができますが、「非機能要件」の確認は難しいことが多いです。非機能要件とは、ソフトウェアの種類に関わらず、システムの動作や品質に関する共通の要件で、可用性（年間稼働率、障害発生時の復旧時間など）、性能（同時接続数、データ処理能力など）、又はセキュリティなど、システムの信頼性やパフォーマンス、運用体制に関わる重要な要素を含みます。これらはどのようなソフトウェアにも求められます。この非機能要件まで契約書の仕様として盛り込む必要があります。ただし、非機能要件は、その抽象性、測定の難しさ、優先順位の調整の難しさのため、仕様決定時に当事者間で合意を得るのが一層難しくなることが多いと言えます。

変更管理の取り決め

契約書で「仕様」を決定・合意できたとしても、開発の時間の経過とともに、仕様変更や追加要求が生じることが多いです。そこで、これに対応するための変更管理プロセスを契約書に盛り込みます。すなわち、変更が発生した場合、影響を受ける納期や費用について事前に合意しておくことが大切です。例えば、追加料金、スケジュールの延長、途中解約時の清算条件などを明文化します。

一括請負方式とは別の開発方式の選択

契約書で仕様書の決定が難しい場合や、仕様が流動的な場合、または変更が想定される場合には、一括請負方式ではなく、以下のような別の開発方式を検討することが有効です。

段階的な開発アプローチの採用

開発プロジェクトを複数の段階に分けて進行する方式があります。これをウォーターフォール方式と呼ぶことが一般的です。各段階での成果物を明確にしておき、その基準を満たさない場合には、開発方針の変更や中断を調整しやすくなります。一括請負方式で最初に全体の仕様を固めることが難しい場合に有効です。

ウォーターフォール方式は、開発の各段階（例えば、要求定義→設計→実装→テスト）を順番に進めることが特徴です。そして、同じように開発の各段階を、プロジェクトの進捗をマイルストーンと呼ばれる重要な成果物や期限で管理する場合もあり、これをマイルストーン方式と呼びます。いずれも進行状況を評価しやすくなります。

プロトタイプ型開発の採用

一括請負方式と段階的な開発アプローチの中間的なアプローチとして、システムの機能やインターフェースを部分的に実装した試作品（プロトタイプ）を作成し、ユーザーからのフィードバックをもとに仕様を改善していく方法があります。このアプローチは、ユーザーの要求（希望する仕様）が流動的である場合に特に有効です。プロトタイプを作成した後に正式なシステムを作成するため、多段階の開発アプローチの一種として位置づけられます。

プロトタイプ型開発は、小規模・中規模システム開発においてよく採用されますが、ユーザーからのフィードバックを早期に得たい場合には、大規模システムにも適用可能です。

アジャイル開発の選択

アジャイル開発は、反復的な開発を行い、ユーザーやステークホルダーからのフィードバックを反映しながら進行します。最初にMVP（Minimum Viable Product／最小実行可能製品）を作成し、早期に市場に投入してフィードバックを基に改善を重ねます。MVPを活用することで、開発初期段階でリスクを抑え、ユーザーのニーズに即した製品を迅速に提供できます。開発スピードを重視するため、「スプリント」と呼ばれる短期間（通常は１～４週間）で開発し、各スプリントで実装や改善を行います。一括請負方式とは異なり、契約の性質が、プロセスを重視した（仕事の完成義務を負わない）準委任契約のことが多いです。

まとめ

システム開発における「仕様書」決定の齟齬を防ぐためには、開発方式や契約方式の選択が非常に重要です。一括請負方式では、仕様書の作成・承認プロセスや変更管理を契約書にしっかりと盛り込むことが後のトラブルを防ぐために不可欠です。特に、モックアップやPoCの活用が有効です。一方で、仕様が流動的で変更が予想される場合には、アジャイル開発やプロトタイプ型開発、段階的な開発アプローチを検討することで、柔軟に対応できます。契約書でリスクを事前に明確にし、適切な管理方法を規定することで、円滑なプロジェクト進行が実現します。