Может ли контракт на разработку системы быть заключен без договора?

В области разработки систем часто встречается ситуация, когда разработчики начинают работу до составления контракта. Однако такой подход на практике является “опасным”. Если контракт не составлен, то в случае возникновения проблем впоследствии, заказчик может заявить, что “контракт еще не заключен, и, следовательно, нет необходимости платить вознаграждение”, что создает риск для разработчика. В реальных спорах, связанных с разработкой систем, не редко возникают споры о самом факте заключения контракта, и часто решения принимаются в ущерб разработчику. Разработчики рискуют не получить оплату, если заказчик прекратит проект или перейдет к другому поставщику. Кроме того, как будет описано ниже, даже если контракт составлен, его заключение может быть отвергнуто.

Здесь мы объясним, как определить, был ли заключен контракт на разработку системы, и какова правовая структура для требования оплаты в случае, если заключение контракта не признается.

Заключение договора

Договор, как правило, заключается при согласии обеих сторон по элементам договора (совпадение волеизъявлений о предложении и принятии).

После заключения договора обе стороны обязаны его соблюдать, и если одна из сторон не выполняет условия договора, другая сторона может принудить к исполнению через суд или требовать компенсацию за неисполнение. “Элементы договора” должны быть определены или конкретны до такой степени, что они могут быть принудительно исполнены и признаны неисполненными.

Заключение договора на разработку системы

Сущность договора на разработку системы в основном заключается в договоре подряда и договоре поручения. Договор подряда обещает выполнение работы и оплату за нее. Договор поручения обещает выполнение работы и оплату за нее.

Поэтому, если между сторонами есть соглашение о “содержании работы или задачи” и “сумме оплаты”, которые являются элементами договора, договор считается заключенным.

Кстати, договор может быть заключен даже при простом устном соглашении, и не требуется письменного договора.

Требование денег в случае прекращения после заключения договора на разработку системы

Если договор на разработку системы был заключен и пользователь односторонне заявляет о его прекращении, юридически это считается уведомлением о расторжении договора.

Если договор подряда был заключен, поставщик может быть расторгнут пользователем в любое время до завершения работы, но при этом предусмотрено, что он имеет право на компенсацию за ущерб (статья 641 Японского гражданского кодекса). Поэтому, если пользователь не компенсировал ущерб, поставщик может требовать компенсацию за “ущерб”, равный сумме затрат, понесенных поставщиком до этого момента, и сумме вознаграждения, которую он мог бы получить, за вычетом суммы, которую он смог бы сэкономить, избежав завершения системы.

Кроме того, если был заключен договор поручения, при прекращении исполнения в середине процесса, принимающая сторона может требовать оплату в соответствии с долей выполнения (пункт 3 статьи 648 Измененного гражданского кодекса Японии). Поэтому поставщик может требовать оплату за уже выполненную работу.

Успех или неудача контракта на разработку системы

Специфичность содержания системы

Обычно, в деловых отношениях между компаниями, особенно при заключении крупных контрактов, используются письменные документы. Если контракт составлен, его заключение легко признается.

Система, которая является объектом разработки, постепенно конкретизируется через различные этапы. Считается, что специфичность содержания системы, которая является элементом контракта на подряд, достаточна, если известны общие рамки и контуры системы, которую планируется создать.

В судебной практике не было споров о заключении основного контракта и соглашения о неразглашении. В основном контракте указано, что “техническая поддержка электронной коммерции, поддержка создания веб-сайтов и сопутствующие услуги” будут поручены, но конкретное содержание электронной коммерции, область порученных услуг и область разработки и проектирования системы не были ясно указаны. В этом случае, заключение контракта было отклонено.

Даже если вы создали основной контракт на разработку системы, работа или содержание работы слишком абстрактны и не могут быть определены, и заключение контракта вряд ли будет признано. Заключение контракта может быть признано, если содержание работы или услуги и сумма вознаграждения указаны в контракте или другом документе с достаточной конкретностью, чтобы стать основанием для принуждения к исполнению и признания неисполнения.

Подробнее о том, на что следует обратить внимание при заключении контракта между индивидуальным инженером и корпорацией, см. в статье ниже.

Поставщик представляет смету и техническое задание, а пользователь одобряет и размещает заказ

Обычно, в деловых отношениях между компаниями используются письменные документы, поэтому если контракт не составлен, его заключение вряд ли будет признано. В разработке систем часто начинают работать до составления контракта. Как же в этом случае рассматривается вопрос о заключении контракта?

В судебном решении (решение Нагояского окружного суда от 28 января 2004 года (2004 год по григорианскому календарю)) по вопросу о заключении контракта на подряд на разработку системы говорится следующее:

• После переговоров между поставщиком и пользователем по уточнению спецификаций и т.д.,
• Поставщик представляет техническое задание и смету,
• Пользователь одобряет их и размещает заказ, тем самым заключая контракт.

В этом судебном решении поставщик получил от пользователя, который является муниципалитетом, заказ на внедрение системы финансового учета и т.д. Поставщику был представлен RFP с заголовком “О представлении предложения по внедрению интегрированной информационной системы управления (запрос)”, на который поставщик ответил, представив предложение и смету, а от пользователя было получено “уведомление о принятии”. Поставщик не провел достаточного обсуждения с пользователем по вопросам, связанным с работой пользователя и т.д., и не было установлено, что внутри пользователя были конкретно обсуждены содержание настройки и стоимость. Содержание предложения поставщика также не было конкретным, и не было ясно, что именно одобрил пользователь, поэтому заключение контракта не было признано.

Я дополнительно объясню о заключении контракта, упомянутом в судебном решении, учитывая другие судебные решения и т.д.

После переговоров между поставщиком и пользователем по уточнению спецификаций и т.д.

Из фразы “после переговоров” следует, что если вопросы, связанные с содержанием системы и суммой вознаграждения, которые являются элементами контракта, находятся “в процессе переговоров”, то соглашение еще не достигнуто, и заключение контракта вряд ли будет признано.

Однако, в контракте на подряд можно определить плату по рыночной цене, поэтому есть судебные решения, в которых признается, что контракт на подряд был заключен по справедливой рыночной цене, если пользователь одобрил содержание системы и “примерную” сумму вознаграждения.

Чтобы можно было сказать, что “переговоры прошли”, поставщик должен провести обсуждение с пользователем по вопросам, связанным с работой пользователя, содержанием системы и т.д., и тщательно их изучить. Это можно записать в электронной почте или протоколе собрания.

Поставщик представляет техническое задание и смету, а пользователь одобряет их и размещает заказ

• Если пользователь выдает заказ или заказную книжку, заключение контракта легко признается. Если поставщик представляет заявку или работает на основе заказа и т.д., то “согласие” будет более вероятным, и заключение контракта будет легче признать.
• Внутренние документы пользователя часто содержат информацию о предстоящем заключении контракта, и заключение контракта вряд ли будет признано. Однако, если нет такого замечания и в документе указаны как можно более конкретные сведения о содержании разработки системы и сумме вознаграждения, которые являются элементами контракта, это будет способствовать признанию заключения контракта.
• Если меморандум, соглашение, подтверждающий документ предполагают последующее заключение контракта или содержат абстрактную информацию, заключение контракта вряд ли будет признано.
• Если на проекте контракта нет печати, то печать означает заключение, и заключение контракта вряд ли будет признано.
• Смета служит доказательством согласованной между сторонами суммы вознаграждения.

Подробнее о том, можно ли в случае, когда в процессе разработки системы достигнут определенный этап и требуется изменение спецификации или добавление функции, взимать дополнительную плату сверх предварительной сметы, см. в статье ниже.

Соглашение о расчетах

Если работа выполняется по указанию пользователя с предположением заключения контракта, при прекращении работы может быть признано “соглашение о расчетах” за выполненную работу. Чтобы это соглашение было легче признать, рекомендуется получить от пользователя запись в документе, таком как внутренний документ, о методе расчета вознаграждения в случае, если контракт не будет заключен, или получить одобрение от уполномоченного лица пользователя на документ, составленный поставщиком.

Юридическая структура для требования денежных средств в случае, если договор не был признан заключенным

Небрежность при заключении договора

Когда начинаются переговоры о заключении договора, стороны обязуются не нарушать имущество друг друга в соответствии с принципом добросовестности (статья 1, пункт 2 Японского гражданского кодекса). Если договор не был заключен, сторона может требовать компенсацию за ущерб, если были объективные обстоятельства, которые заставили другую сторону ожидать заключение договора, и если была вина. Это называется небрежностью при заключении договора.

Введем примеры случаев, когда суд признал небрежность при заключении договора.

• Поставщик завершил определение требований по запросу пользователя и выполнил часть основного и детального проектирования. Пользователю было объяснено, что действия по приглашению других компаний к участию в тендере являются формальностью для получения одобрения президента, но непосредственно перед заключением договора была выбрана другая компания, и договор не был заключен.
• Поставщик продолжал работу по требованию пользователя соблюдать сроки, и дата заключения договора была уже близка. Внутри компании-пользователя продолжались подготовительные работы для собственной разработки, но это было скрыто, и договор не был заключен.
• Поставщик был уведомлен пользователем о выборе подрядчика для строительства, не было высказано никаких сомнений по поводу сметы, и на основе встреч с пользователем были выполнены работы по уточнению спецификаций. Пользователь был осведомлен о расходах, но договор был отклонен по причине несогласия с суммой сметы.

С другой стороны, существуют примеры судебных решений, в которых небрежность при заключении договора не была признана, например, когда была ясно указана возможность выбора другой компании или условия для заключения договора.

Если работа была продолжена в ответ на требование пользователя, и возможность выбора другой компании или условия согласия не были ясно указаны, и по этим причинам переговоры о договоре были неожиданно прерваны, может быть признано право на требование компенсации за ущерб.

В этом случае нет спора о том, что в “ущерб” включаются расходы, понесенные до этого момента. Кроме того, существуют судебные решения, в которых указывается, что в “ущерб” включается прибыль от фактически выполненной работы. Кроме того, если вы можете представить доказательства того, что вы понесли ущерб в размере прибыли, которую вы могли бы получить, если бы продолжили работу после отказа от предложения другой компании, это также может быть включено.

Статья 512 Японского коммерческого кодекса

Если поставщик выполнил действия, связанные с разработкой системы для пользователя, он может требовать справедливую оплату на основании статьи 512 Японского коммерческого кодекса.

Когда вы начинаете переговоры о разработке системы, важно сохранить доказательства того, что обе стороны признали содержание системы и сумму вознаграждения, используя электронную почту или протоколы совещаний, и что обстоятельства, которые заставляют думать, что заключение договора является определенным, и элементы договора были конкретизированы.

Даже если вам отказывают в оплате по причине того, что вы не заключили договор, вы все равно можете требовать денежные средства, как указано выше.

Вывод

Таким образом, суды склонны делать “негативные” суждения о контрактных отношениях в случае отсутствия контракта, особенно по сравнению с восприятием этого со стороны компании-подрядчика. С точки зрения компании-подрядчика, они хотели бы заявить, что “должны были начать работать сначала, а контракт должен был быть заключен позже, и сам контракт уже был заключен”. Однако, это утверждение не всегда признается.

Кроме того, если контракт не признается заключенным, как указано выше, есть случаи, когда можно требовать денежные средства на основе юридической структуры, такой как небрежность при заключении контракта или статья 512 Японского коммерческого кодекса (Japanese Commercial Code), но это также не “надежный” вариант.

Если вы вынуждены начать работу до заключения контракта, вам нужно:

• Сначала понимать, что это действие сопряжено с риском, и принимать решение о том, стоит ли тратить время на этот проект, учитывая этот риск (особенно для малых и средних предприятий или стартапов, если они принимают проект от крупной компании, они могут быть вынуждены принять решение о “действии вперед”, чтобы получить опыт сделок с этой крупной компанией. Если риск учтен, это может быть возможным решением.)
• Рассмотреть возможность заключения соглашения о ликвидации в случае, если контракт не будет заключен

Можно сказать, что вам нужно провести такую мыслительную работу.