Ключевые моменты проверки контракта при выполнении системной разработки в формате полупредставительства

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

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

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

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

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

Что такое системная разработка и договор о полномочиях

Что такое договор о полномочиях

Договор о полномочиях регулируется в гражданском кодексе, применяя положения договора о представительстве.

Раздел 10. Представительство
Статья 643. Представительство возникает, когда одна из сторон поручает другой стороне совершить юридический акт, и последняя принимает это поручение.
Статья 656. Положения этого раздела применяются к поручениям, не являющимся юридическими актами.

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

Различия с договором подряда

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

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

https://monolith.law/corporate/checkpoints-for-contracts-of-system-development[ja]

Модельные положения по типу доверительного управления и контрольные точки

Поддержка в создании определения требований

(Реализация поддержки в создании определения требований)
Статья №. По договору, указанному в статье №, Подрядчик предоставляет услуги по поддержке в создании определения требований (далее – “поддержка в создании определения требований”), основываясь на концепции информационной системы, плане систематизации и т.д., созданных Заказчиком.

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

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

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

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

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

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

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

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

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

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

3. Если в результате исправления, указанного в пункте 1, возникает необходимость изменить условия отдельного договора, такие как срок выполнения работ и плата за услуги, это делается в соответствии с процедурой, указанной в статье №.

Определение требований – это фаза, в которой пользователь получает предложение о приблизительной оценке от поставщика и определяет требования, необходимые для выполнения системного проектирования и т.д. Если требования остаются неясными, поставщику будет трудно дать точную оценку, и в последующей фазе разработки могут возникнуть проблемы. Эта статья предусматривает процедуру подтверждения определения требований, которое является основой для последующих работ по разработке, путем проверки его пользователем и поставщиком и подтверждения его путем подписания и печати руководителями. В процессе проверки для утверждения определения требований может потребоваться корректировка, поэтому в пункте 1 предусмотрена процедура для этого случая.

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

(Завершение работы и подтверждение)
Статья №. В течение ○ дней после утверждения определения требований, указанного в предыдущей статье, Подрядчик составляет отчет о завершении работы и представляет его Заказчику.

2. Заказчик проверяет данный отчет о завершении работы в течение периода, указанного в отдельном договоре (далее – “период проверки завершения поддержки в создании определения требований”).

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

4. Если в течение периода проверки завершения поддержки в создании определения требований Заказчик не выразил в письменной форме конкретные причины возражения, то по истечении периода проверки завершения поддержки в создании определения требований считается, что Заказчик подтвердил завершение работы.

Поскольку этот процесс является полномочием, эта статья предусматривает процедуру проверки того, была ли поддержка в создании определения требований должным образом выполнена Подрядчиком на основе обязанности добросовестного управления, с использованием отчета о завершении работы, в котором записаны результаты работы.
Пункт 1 предусматривает обязанность по представлению отчета о завершении работы.
Пункт 2 ясно указывает период проверки отчета, чтобы избежать задержек в проверке отчета.
Пункт 3 предусматривает подтверждение завершения поддержки в создании определения требований путем подписания и печати Заказчика на подтверждении завершения работы.
Пункт 4 предусматривает предположение о подтверждении завершения работы, если в течение периода проверки завершения поддержки в создании определения требований Заказчик не выразил возражения в письменной форме. Это предусмотрено с учетом того, что если Заказчик по какой-либо причине не проводит процедуру подтверждения вовремя, это может привести к задержке последующей работы или началу последующей работы без ясного подтверждения, что может сделать неясной ответственность между Заказчиком и Подрядчиком.

Создание внешнего дизайнерского документа

(Проведение работы по поддержке создания внешнего дизайнерского документа)
Статья 〇. По договору, определенному в статье 〇, Исполнитель предоставляет Заказчику услуги по поддержке создания внешнего дизайнерского документа (далее – “работа по поддержке создания внешнего дизайнерского документа”).

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

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

(Заключение отдельного договора о работе по поддержке создания внешнего дизайнерского документа)
Статья 〇. Заказчик и Исполнитель определяют условия сделки, указанные в пункте 1 статьи 4, посредством переговоров и заключают отдельный договор о работе по поддержке создания внешнего дизайнерского документа.

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

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

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

3. Если Заказчик намерен изменить содержание документа с определением требований на основе обсуждений на собраниях по обсуждению внешнего дизайнерского документа и это приведет к изменению условий отдельного договора, таких как сроки выполнения работ и плата за услуги, то это должно быть выполнено в соответствии с процедурой, предусмотренной в статье 〇 (Изменение содержания настоящего договора и отдельного договора).

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

(Утверждение внешнего дизайнерского документа)
Статья 〇. Когда Заказчик завершает создание внешнего дизайнерского документа, Заказчик и Исполнитель проверяют, соответствует ли внешний дизайнерский документ утвержденному документу с определением требований в соответствии со статьей 〇 и решениям, принятым на собраниях по обсуждению внешнего дизайнерского документа, указанным в предыдущей статье, в течение периода, определенного в отдельном договоре (далее – “период проверки внешнего дизайнерского документа”), и подписывают и ставят печать на внешнем дизайнерском документе в качестве подтверждения соответствия. Однако, если в результате проверки обнаружено, что внешний дизайнерский документ не соответствует утвержденному документу с определением требований в соответствии со статьей 〇 и решениям, принятым на собраниях по обсуждению внешнего дизайнерского документа, Заказчик создает исправленную версию в течение согласованного периода, и Заказчик и Исполнитель снова проводят вышеупомянутую проверку и процедуру подтверждения.

2. Внешний дизайнерский документ считается утвержденным после подтверждения обеими сторонами в соответствии с предыдущим пунктом.

3. Если в результате исправлений, указанных в пункте 1, возникает необходимость изменить условия отдельного договора, такие как сроки выполнения работ и плата за услуги, это должно быть выполнено в соответствии с процедурой, предусмотренной в статье 〇 (Изменение содержания настоящего договора и отдельного договора).

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

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

(Завершение работы и подтверждение)
Статья 〇. В течение ○ дней после утверждения внешнего дизайнерского документа, указанного в предыдущей статье, Исполнитель создает отчет о завершении работы и представляет его Заказчику.

2. Заказчик проверяет данный отчет о завершении работы в течение периода, указанного в отдельном договоре (далее – “период проверки завершения работы по поддержке создания внешнего дизайнерского документа”).

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

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

Поскольку этот процесс является доверительным, эта статья предусматривает процедуру проверки того, была ли работа по поддержке должным образом выполнена Исполнителем на основе обязанности заботы о хорошем управлении, с использованием отчета о завершении работы, в котором записаны результаты работы.
Пункт 2 ясно указывает период проверки, чтобы избежать задержек в проверке отчета.
Пункт 3 предусматривает подтверждение завершения работы по поддержке создания внешнего дизайнерского документа путем подписания и печати Заказчиком документа, подтверждающего завершение работы.
Пункт 4 предусматривает предполагаемое подтверждение завершения, если Заказчик не выразил возражений в письменной форме в течение периода проверки завершения работы. Это предусмотрено с учетом того, что если Заказчик по какой-либо причине не проводит процедуру подтверждения вовремя, это может привести к задержке последующей работы или началу последующей работы без ясного подтверждения, что может сделать неясными отношения ответственности между Заказчиком и Исполнителем.

Услуги по разработке программного обеспечения

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

https://monolith.law/corporate/checkpoints-for-contracts-of-system-development[ja]

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

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

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

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

(Завершение работы и проверка)
Статья 32. Сторона Б обязуется в течение ○ дней после завершения работы по поддержке в подготовке и переходе на использование программного обеспечения подготовить отчет о завершении работы и представить его Стороне А.

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

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

4. Если в течение периода проверки завершения работы Сторона А не выразит в письменной форме конкретные возражения, то по истечении периода проверки завершения работы считается, что работа была подтверждена как завершенная.

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

Определение характера договора

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